chore: format title in markdown

cloud-native-db.md

@@ -7,7 +7,7 @@ tags: ['Database']
 ---
 
 
-##引言
+## 引言
 
 最近几年，随着云计算相关技术的发展，各种不同类型的云层出不穷，服务越来越多不同类型的企业业务，传统企业也渐渐开始探索上云的道路。在云上，作为业务最核心的数据库，相比之前的传统方案会有哪些变化呢？在正式聊云时代的数据库特点之前，我们需要了解一下目前云时代架构发生的变化。
 
@@ -35,9 +35,9 @@ Docker 提供的隔离型和可移植性，与微服务是一种天然的契合
 
 由此可见，云计算时代系统的架构发生了巨大的变化，这一方面为用户提供了更优秀的特性，另一方面也对云计算的组件提出了更高的要求。数据库作为云计算最基础的组件之一，也需要适应这种架构的变化。（这里我们主要关注 SQL 数据库，云时代的数据库以下简称云数据库。）
 
-##那么云数据库主要有一些什么样的特点呢？我认为主要有以下几点。
+## 那么云数据库主要有一些什么样的特点呢？我认为主要有以下几点。
 
-###弹性伸缩
+### 弹性伸缩
 
 传统的数据库方案，常见的会选用 Oracle，MySQL，PostgreSQL。在云时代，数据量的规模有爆发性的增长，传统的数据库很容易遇到单机的存储瓶颈，不得不选用一些集群方案，常见的比如 Oracle RAC、 MySQL Sharding 等，而这些集群方案或多或少都有一些不令人满意的地方。
 
@@ -47,18 +47,18 @@ Docker 提供的隔离型和可移植性，与微服务是一种天然的契合
 
 在云时代，理想中所有的资源都是根据用户业务需求按需分配的，服务器资源，应用容器资源，当然也包括数据库资源。添加或者减少新的数据库资源，完全就像日常吃饭那样稀疏平常，甚至用户基本感知不到。比如作为一个电商用户，在双 11 促销活动之前，可以通过增加数据库节点的方式，扩大更多的资源池，用来部署相应的容器服务，当活动结束之后，再将多余的资源移除去支持其他的服务，这样可以极大地提高资源的利用率，同样可以弹性地支撑各种峰值业务。
 
-###高可用
+### 高可用
 
 传统的 MySQL 方案，数据复制的时候默认采用异步的方式，对于一个写入的请求，主库写入成功后就会返回成功信息给客户端，但是这个时候数据可能还没有同步给从库，一旦主库这个时候挂掉了，启动从库的时候就会有丢失数据的风险。当然，也有人会选择半同步的复制方式，这种方式在正常情况下是同步的，但是在遇到数据压力比较大的时候，依然会退化为异步的方式，所以本质上来说，同样有丢失数据的风险。其他也有一些多主的同步方案，比如在应用层做数据同步，但是这种方式一是需要应用层的配合，二是在对网络超时的处理非常复杂，增加心智负担。
 
 在云时代，因为所有的数据库资源都是分布式存储的，每个数据库节点出现问题都是很正常的事情，所以就必须有一种可以实现数据一致性的数据复制方式来保证服务的高可用，业界给出的答案就是：Paxos/Raft（关于 Paxos 和 Raft 的实现细节我们不在这里展开）。PingCAP 在做的 TiDB 就是选择了 Raft 协议，Raft 协议看起来更像是一个多副本的自适应的主从复制协议，对于每次写请求，Raft 都会保证大多数写成功才会返回客户端，即使 Raft Group的Leader 挂掉了，在一个有限的时间范围内，会很快地选出一个新的 Leader 出来，继续提供服务。同样，对于一个 3 副本的 Raft Group，只要 2 个写入成功，就可以保证成功，而大多数情况下，最先写入成功的往往是与 Leader 网络情况最好的那个副本，所以这种 Majority 写的方式，可以很自然地选择速度最快的副本进行数据同步复制。另外，Raft 协议本身支持 Config Change，增加一个新的节点，可以很容易地做副本数据分布的变更，而不需要停止任何服务。
 
 同样，在云时代，数据库的 DDL 操作也会是一个非常有趣的事情。以一个常见的 Add Column 操作为例，在表规模已经很大的情况下，在传统的实现方案中，比较有参考意义的是，通过一些工具，创建类似表级别的触发器，将原表的数据同步到一个新的临时表中，当数据追平的时候，再进行一个锁表操作，将临时表命名为原表，这样一个 Add Column 操作就完成了。但是在云时代，分布式的数据存储方式决定了这种方案很难实现，因为每个数据库节点很难保证 Schema 状态变更的一致性，而且当数据规模增长到几十亿，几百亿甚至更多的时候，很短的阻塞时间都有可能会导致很大的负载压力变化，所以 DDL 操作必须是保证无阻塞的在线操作。值得欣慰的是，Google 的 F1 给我们提供了很好的实现参考，TiDB 即是根据 F1 的启发进行的研发，感兴趣的同学可以看下相关的内容。
 
-###易用透明
+### 易用透明
 我们可以将云数据库想象成一个提供无限大容量的数据库，传统数据库遇到单机数据存储瓶颈的问题将不复存在。已有的程序基本上不怎么需要修改已有的代码，就可以很自然地接入到云数据库中来获得无限 Scale 的能力。增减数据库节点，或者节点的故障恢复，对于应用层来说完全透明。另外，云数据库的监控、运维、部署、备份等等操作都可以在云端通过高效的自动化工具来自动完成，极大地降低了运维成本。
 
-###多租户
+### 多租户
 云数据库本身应该是可以弹性伸缩的，所以很自然的，从资源利用率的角度来考虑，多个不同用户的数据库服务底层会跑在一个共享的云数据库中。因此多租户技术会成为云数据库的标配。但是这里面就有一个不得不面对的问题，如何做到不同用户的隔离性？用户数据隔离是相对比较容易的，比如还是以电商用户（这里说的是电商企业，不是顾客客户）为例，每个用户都有一个唯一的 ID，这样在云数据库的底层存储中，可以保证每个用户数据都带有自己 ID 前缀，用户登陆进来的时候可以根据这个前缀规则，获取他对应的数据，同时他看不到其他用户的数据。
 
 在一个真实的多租户环境下面，纯粹的数据隔离往往是不够的，你还需要做到资源公平性的隔离。比如有的用户写一个 SQL，这个 SQL 没有做优化，主要做的事情是一个全表描扫，这个表的数据量特别特别大，这样他会吃掉很多的 CPU、Memory、IO 等资源，导致其他用户很轻量级的 SQL 操作都可能会变得很慢，影响到其他用户实际的体验。那么针对这种情况怎么做隔离？与此类似的还有，网络带宽怎么做隔离？大家都是跑在一个云数据库上面的，如果一个用户存放的数据特别大，他把带宽都吃掉了，别人就显得非常慢了。
@@ -73,27 +73,27 @@ Docker 提供的隔离型和可移植性，与微服务是一种天然的契合
 
 调度算法一直是整个分布式系统领域很困难的一个问题，如何做到隔离性和公平调度也是未来云数据库非常有挑战的一个事情。
 
-###低成本
+### 低成本
 低成本应该是云时代基础设施最明显的特点。首先，云数据库的高可用和容错能力，使得我们不再需要昂贵的硬件设备，只需要普通的 X86 服务器就可以提供服务。然后，受益于 Docker 的虚拟化技术，使得不同类型的应用容器可以跑在同一个物理机上，这样可以极大地提高资源的利用率。其次，多租户的支持，使得不同的用户可以共用一套底层的数据库存储系统，在数据库层面再一次提高了资源的利用效率。再次，云数据库的自动化运维工具，降低了整个核心数据库的运维成本。最后，云数据库资源是按需分配的，用户完全可以根据自身的业务特点，选购合适的服务资源。
 
-###高吞吐
+### 高吞吐
 
 云数据库虽然可以做到弹性扩容，但是本身是分布式存储的，虽然可以通过 Batch Write、Pipeline 和 Router Cache 等方式加快访问 SQL 请求的数据，但是相对传统单机的数据库来说，在数据访问链路上至少也要多走一次网络，所以大部分并发量不大的小数据量请求，都会比单机延迟要高一些。也就是说，当没有足够高的并发 SQL 访问的话，其实不能完全体现云数据库的性能优势，所以这也是我们在选用云数据库的时候需要认识到的问题，云数据库更多的是追求高吞吐，而不是低延迟。当并发大到一定规模，云数据库高吞吐特性就显现出来了，即使在很高的并发下，依然可以维持相当稳定的延迟，而不会像单机数据库那样，延迟线性增长。当然，延迟的问题，在合理的架构设计方案下，可以通过缓存的方式得到极大的缓解。
 
-###数据安全
+### 数据安全
 云数据库的物理服务器分布在多个机房，这就为跨数据库中心的数据安全提供了最基础的硬件支持。谈到金融业务，大家耳熟能详的可能就是两地三中心，比如北京有两个机房，上海有一个。未来一切服务都跑在云上，金融类的业务当然也不例外。相比其他业务，金融类业务对数据安全要求就要高得多。当然，每个公司内部都有核心的业务，所以如果上云的话，也会有同样的强烈需要。这样，对云数据库来说，数据的一致性、分布式事务、跨数据中心的数据安全等更高端的需求有可能会日益强烈。常见的数据备份也有可能会被其他新的模式所取代或者弱化，比如基于 Paxos/Raft 的多副本方案，本身就保证了会有多份备份。
 
-###自动负载平衡
+### 自动负载平衡
 对于云数据库来说，负载平衡是一个很重要的问题，它直接决定了整个云数据库系统性能的好坏，如果一个数据库节点的数据访问过热的话，就需要考虑把数据迁移到其他的数据库节点来分担负载，不然就很容易出现性能瓶颈。整个负载平衡是一个动态的过程，调度算法需要保证资源配比的最大平衡，还有保证数据迁移的过程对系统整体的负载影响最小。这在未来也是云数据库需要解决的一个核心问题。
 
-##小结
+## 小结
 从目前已有的 SQL 数据库实现方案来看，NewSQL 应该是最贴近于云数据库理念的实现。NewSQL 本身具有 SQL、ACID 和 Scale 的能力，天然就具备了云数据库的一些特点。但是，从 NewSQL 到云数据库，依然有很多需要挑战的难题，比如多租户、性能等。
 
 上面提到的一些云数据库的特点，也是 PingCAP 目前在着力实现的部分，TiDB 作为国内第一个 NewSQL 的开源项目，在与社区的共同努力下，我们在上月底刚刚发布了 Beta 版本，欢迎各位上 GitHub 了解我们。
 
 随着整个社区技术水平的发展和云时代新的业务需求的驱动，除了 PingCAP 的 TiDB，相信会有更多的团队在这方面进行探索， 期待早日看到云数据库成熟的那一天。
 
-##Q&A
+## Q&A
 **问：由于客户数据环境复杂多样，在迁移到云端的时候怎么怎么做规划，以便后期统一运维管理？或者说，怎么把用户 SQL Server 或者 MongoDB 逐渐迁移到 TiDB 之类的分布式数据库？**
 **崔秋**：因为每个业务场景都不太相同，所以在选用云端服务的时候，首先要了解自身业务和云服务具体的优缺点。
 如果你的业务本身比较简单，比如你之前用的 MongoDB，现在很多云服务厂商都会提供云端的 MongoDB 服务。这个时候你就要根据业务特点来做判断，如果 MongoDB 本身容量不大，远期的业务数据不会增长过快的话，这个时候其实你可以直接使用 MongoDB 的服务的。但是如果你本身的数据量比较大，或者数据增长比较快的话，就可能要考虑数据的扩容问题，MongoDB 在这方面做的不是太好。