关于后端:架构设计数据库篇

大家好，我是易安！

之前咱们讲过架构设计的一些准则，和架构设计的方法论，明天咱们谈谈高性能数据库集群的设计与利用。

读写拆散原理

读写拆散的基本原理是将数据库读写操作扩散到不同的节点上，上面是其根本架构图。

读写拆散的根本实现是：

• 数据库服务器搭建主从集群，一主一从、一主多从都能够。
• 数据库主机负责读写操作，从机只负责读操作。
• 数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据。
• 业务服务器将写操作发给数据库主机，将读操作发给数据库从机。

须要留神的是，这里用的是“主从集群”，而不是“主备集群”。“从机”的“从”能够了解为“仆从”，仆从是要帮主人干活的，“从机”是须要提供读数据的性能的；而“备机”个别被认为仅仅提供备份性能，不提供拜访性能。所以应用“主从”还是“主备”，是要看场景的，这两个词并不是齐全等同的。

读写拆散的实现逻辑并不简单，但有两个细节点将引入设计复杂度：主从复制提早 和 分配机制。

复制提早

以 MySQL 为例，主从复制提早可能达到 1 秒，如果有大量数据同步，提早 1 分钟也是有可能的。主从复制提早会带来一个问题：如果业务服务器将数据写入到数据库主服务器后立即（1 秒内）进行读取，此时读操作拜访的是从机，主机还没有将数据复制过去，到从机读取数据是读不到最新数据的，业务上就可能呈现问题。例如，用户刚注册完后立即登录，业务服务器会提醒他“你还没有注册”，而用户明明方才曾经注册胜利了。

解决主从复制提早有几种常见的办法：

1. 写操作后的读操作指定发给数据库主服务器

例如，注册账号实现后，登录时读取账号的读操作也发给数据库主服务器。这种形式和业务强绑定，对业务的侵入和影响较大，如果哪个新来的程序员不晓得这样写代码，就会导致一个 bug。

2. 读从机失败后再读一次主机

这就是通常所说的“二次读取”，二次读取和业务无绑定，只须要对底层数据库拜访的 API 进行封装即可，实现代价较小，不足之处在于如果有很多二次读取，将大大增加主机的读操作压力。例如，黑客暴力破解账号，会导致大量的二次读取操作，主机可能顶不住读操作的压力从而解体。

3. 要害业务读写操作全副指向主机，非关键业务采纳读写拆散

例如，对于一个用户管理系统来说，注册 + 登录的业务读写操作全副拜访主机，用户的介绍、喜好、等级等业务，能够采纳读写拆散，因为即便用户改了本人的自我介绍，在查问时却看到了自我介绍还是旧的，业务影响与不能登录相比就小很多，还能够忍耐。

分配机制

将读写操作辨别开来，而后拜访不同的数据库服务器，个别有两种形式：程序代码封装 和 中间件封装。

1. 程序代码封装

程序代码封装指在代码中形象一个数据拜访层（所以有的文章也称这种形式为“中间层封装”），实现读写操作拆散和数据库服务器连贯的治理。例如，基于 Hibernate 进行简略封装，就能够实现读写拆散，根本架构是：

程序代码封装的形式具备几个特点：

• 实现简略，而且能够依据业务做较多定制化的性能。
• 每个编程语言都须要本人实现一次，无奈通用，如果一个业务蕴含多个编程语言写的多个子系统，则反复开发的工作量比拟大。
• 故障状况下，如果主从产生切换，则可能须要所有零碎都批改配置并重启。

目前开源的实现计划中，淘宝的 TDDL（Taobao Distributed Data Layer，外号: 头都大了）是比拟有名的。它是一个通用数据拜访层，所有性能封装在 jar 包中提供给业务代码调用。其基本原理是一个基于集中式配置的 jdbc datasource 实现，具备主备、读写拆散、动静数据库配置等性能，根本架构是：

2. 中间件封装

中间件封装指的是独立一套零碎进去，实现读写操作拆散和数据库服务器连贯的治理。中间件对业务服务器提供 SQL 兼容的协定，业务服务器毋庸本人进行读写拆散。对于业务服务器来说，拜访中间件和拜访数据库没有区别，事实上在业务服务器看来，中间件就是一个数据库服务器。其根本架构是：

数据库中间件的形式具备的特点是：

• 可能反对多种编程语言，因为数据库中间件对业务服务器提供的是规范 SQL 接口。
• 数据库中间件要反对残缺的 SQL 语法和数据库服务器的协定（例如，MySQL 客户端和服务器的连贯协定），实现比较复杂，细节特地多，很容易呈现 bug，须要较长的工夫能力稳固。
• 数据库中间件本人不执行真正的读写操作，但所有的数据库操作申请都要通过中间件，中间件的性能要求也很高。
• 数据库主从切换对业务服务器无感知，数据库中间件能够探测数据库服务器的主从状态。例如，向某个测试表写入一条数据，胜利的就是主机，失败的就是从机。

因为数据库中间件的复杂度要比程序代码封装高出一个数量级，个别状况下倡议采纳程序语言封装的形式，或者应用成熟的开源数据库中间件。如果是大公司，能够投入人力去实现数据库中间件，因为这个零碎一旦做好，接入的业务零碎越多，节俭的程序开发投入就越多，价值也越大。

目前的开源数据库中间件计划中，MySQL 官网先是提供了 MySQL Proxy，但 MySQL Proxy 始终没有正式 GA，当初 MySQL 官网举荐 MySQL Router。MySQL Router 的次要性能有读写拆散、故障主动切换、负载平衡、连接池等，其根本架构如下：

奇虎 360 公司也开源了本人的数据库中间件 Atlas，Atlas 是基于 MySQL Proxy 实现的，根本架构如下：

以下是官网介绍，更多内容你能够参考 这里。

Atlas 是一个位于应用程序与 MySQL 之间中间件。在后端 DB 看来，Atlas 相当于连贯它的客户端，在前端利用看来，Atlas 相当于一个 DB。Atlas 作为服务端与应用程序通信，它实现了 MySQL 的客户端和服务端协定，同时作为客户端与 MySQL 通信。它对应用程序屏蔽了 DB 的细节，同时为了升高 MySQL 累赘，它还保护了连接池。

方才咱们讲了“读写拆散”，读写拆散扩散了数据库读写操作的压力，但没有扩散存储压力，当数据量达到千万甚至上亿条的时候，单台数据库服务器的存储能力会成为零碎的瓶颈，次要体现在这几个方面：

• 数据量太大，读写的性能会降落，即便有索引，索引也会变得很大，性能同样会降落。
• 数据文件会变得很大，数据库备份和复原须要消耗很长时间。
• 数据文件越大，极其状况下失落数据的危险越高（例如，机房火灾导致数据库主备机都产生故障）。

基于上述起因，单个数据库服务器存储的数据量不能太大，须要管制在肯定的范畴内。为了满足业务数据存储的需要，就须要将存储扩散到多台数据库服务器上。

业务分库

业务分库指的是依照业务模块将数据扩散到不同的数据库服务器。 例如，一个简略的电商网站，包含用户、商品、订单三个业务模块，咱们能够将用户数据、商品数据、订单数据离开放到三台不同的数据库服务器上，而不是将所有数据都放在一台数据库服务器上。

尽管业务分库可能扩散存储和拜访压力，但同时也带来了新的问题，接下来我进行详细分析。

1.join 操作问题

业务分库后，本来在同一个数据库中的表扩散到不同数据库中，导致无奈应用 SQL 的 join 查问。

例如：“查问购买了化妆品的用户中女性用户的列表”这个性能，尽管订单数据中有用户的 ID 信息，然而用户的性别数据在用户数据库中，如果在同一个库中，简略的 join 查问就能实现；但当初数据扩散在两个不同的数据库中，无奈做 join 查问，只能采取先从订单数据库中查问购买了化妆品的用户 ID 列表，而后再到用户数据库中查问这批用户 ID 中的女性用户列表，这样实现就比简略的 join 查问要简单一些。

2. 事务问题

本来在同一个数据库中不同的表能够在同一个事务中批改，业务分库后，表扩散到不同的数据库中，无奈通过事务对立批改。尽管数据库厂商提供了一些分布式事务的解决方案（例如，MySQL 的 XA），但性能切实太低，与高性能存储的指标是相违反的。

例如，用户下订单的时候须要扣商品库存，如果订单数据和商品数据在同一个数据库中，咱们能够应用事务来保障扣减商品库存和生成订单的操作要么都胜利要么都失败，但分库后就无奈应用数据库事务了，须要业务程序本人来模仿实现事务的性能。例如，先扣商品库存，扣胜利后生成订单，如果因为订单数据库异样导致生成订单失败，业务程序又须要将商品库存加上；而如果因为业务程序本人异样导致生成订单失败，则商品库存就无奈复原了，须要人工通过日志等形式来手工修复库存异样。

3. 老本问题

业务分库同时也带来了老本的代价，原本 1 台服务器搞定的事件，当初要 3 台，如果思考备份，那就是 2 台变成了 6 台。

基于上述起因，对于小公司初创业务，并不倡议一开始就这样拆分，次要有几个起因：

• 初创业务存在很大的不确定性，业务不肯定能倒退起来，业务开始的时候并没有真正的存储和拜访压力，业务分库并不能为业务带来价值。
• 业务分库后，表之间的 join 查问、数据库事务无奈简略实现了。
• 业务分库后，因为不同的数据要读写不同的数据库，代码中须要减少依据数据类型映射到不同数据库的逻辑，减少了工作量。而业务初创期间最重要的是疾速实现、疾速验证，业务分库会拖慢业务节奏。

有的架构师可能会想：如果业务真的倒退很快，岂不是很快就又要进行业务分库了？那为何不一开始就设计好呢？

首先，这里的“如果”事实上产生的概率比拟低，做 10 个业务有 1 个业务能活下去就很不错了，更何况疾速倒退，和中彩票的概率差不多。如果咱们每个业务上来就依照淘宝、微信的规模去做架构设计，岂但会累死本人，还会害死业务。

其次，如果业务真的倒退很快，前面进行业务分库也不迟。因为业务倒退好，相应的资源投入就会加大，能够投入更多的人和更多的钱，那业务分库带来的代码和业务简单的问题就能够通过减少人来解决，老本问题也能够通过减少资金来解决。

再者，单台数据库服务器的性能其实也没有设想的那么弱，一般来说，单台数据库服务器可能撑持 10 万用户量量级的业务，初创业务从 0 倒退到 10 万级用户，并不是设想得那么快。

而对于业界成熟的大公司来说，因为曾经有了业务分库的成熟解决方案，并且即便是尝试性的新业务，用户规模也是海量的，这与后面提到的初创业务的小公司有本质区别，因而最好在业务开始设计时就思考业务分库。例如，在淘宝上做一个新的业务，因为曾经有成熟的数据库解决方案，用户量也很大，须要在一开始就设计业务分库甚至接下来介绍的分表计划。

分表

将不同业务数据扩散存储到不同的数据库服务器，可能撑持百万甚至千万用户规模的业务，但如果业务持续倒退，同一业务的单表数据也会达到单台数据库服务器的解决瓶颈。例如，淘宝的几亿用户数据，如果全副寄存在一台数据库服务器的一张表中，必定是无奈满足性能要求的，此时就须要对单表数据进行拆分。

单表数据拆分有两种形式：垂直分表 和 程度分表。示意图如下：

为了形象地了解垂直拆分和程度拆分的区别，能够设想你手里拿着一把刀，面对一个蛋糕切一刀：

• 从上往下切就是垂直切分，因为刀的运行轨迹与蛋糕是垂直的，这样能够把蛋糕切成高度相等（面积能够相等也能够不相等）的两局部，对应到表的切分就是表记录数雷同但蕴含不同的列。例如，示意图中的垂直切分，会把表切分为两个表，一个表蕴含 ID、name、age、sex 列，另外一个表蕴含 ID、nickname、description 列。
• 从左往右切就是程度切分，因为刀的运行轨迹与蛋糕是平行的，这样能够把蛋糕切成面积相等（高度能够相等也能够不相等）的两局部，对应到表的切分就是表的列雷同但蕴含不同的行数据。例如，示意图中的程度切分，会把表分为两个表，两个表都蕴含 ID、name、age、sex、nickname、description 列，然而一个表蕴含的是 ID 从 1 到 999999 的行数据，另一个表蕴含的是 ID 从 1000000 到 9999999 的行数据。

下面这个示例比较简单，只思考了一次切分的状况，理论架构设计过程中并不局限切分的次数，能够切两次，也能够切很屡次，就像切蛋糕一样，能够切很多刀。

单表进行切分后，是否要将切分后的多个表扩散在不同的数据库服务器中，能够依据理论的切分成果来确定，并不强制要求单表切分为多表后肯定要扩散到不同数据库中。起因在于单表切分为多表后，新的表即便在同一个数据库服务器中，也可能带来可观的性能晋升，如果性能可能满足业务要求，是能够不拆分到多台数据库服务器的，毕竟咱们在下面业务分库的内容看到业务分库也会引入很多复杂性的问题；如果单表拆分为多表后，单台服务器仍然无奈满足性能要求，那就不得不再次进行业务分库的设计了。

分表可能无效地扩散存储压力和带来性能晋升，但和分库一样，也会引入各种复杂性。

1. 垂直分表

垂直分表适宜将表中某些不罕用且占了大量空间的列拆分进来。例如，后面示意图中的 nickname 和 description 字段，假如咱们是一个婚恋网站，用户在筛选其余用户的时候，次要是用 age 和 sex 两个字段进行查问，而 nickname 和 description 两个字段次要用于展现，个别不会在业务查问中用到。description 自身又比拟长，因而咱们能够将这两个字段独立到另外一张表中，这样在查问 age 和 sex 时，就能带来肯定的性能晋升。

垂直分表引入的复杂性次要体现在表操作的数量要减少。例如，原来只有一次查问就能够获取 name、age、sex、nickname、description，当初须要两次查问，一次查问获取 name、age、sex，另外一次查问获取 nickname、description。

不过相比接下来要讲的程度分表，这个复杂性就是小巫见大巫了。

2. 程度分表

程度分表适宜表行数特地大的表，有的公司要求单表行数超过 5000 万就必须进行分表，这个数字能够作为参考，但并不是相对规范，要害还是要看表的拜访性能。对于一些比较复杂的表，可能超过 1000 万就要分表了；而对于一些简略的表，即便存储数据超过 1 亿行，也能够不分表。但不管怎样，当看到表的数据量达到千万级别时，作为架构师就要警惕起来，因为这很可能是架构的性能瓶颈或者隐患。

程度分表相比垂直分表，会引入更多的复杂性，次要体现在上面几个方面：

• 路由

程度分表后，某条数据具体属于哪个切分后的子表，须要减少路由算法进行计算，这个算法会引入肯定的复杂性。

常见的路由算法有：

范畴路由： 选取有序的数据列（例如，整形、工夫戳等）作为路由的条件，不同分段扩散到不同的数据库表中。以最常见的用户 ID 为例，路由算法能够依照 1000000 的范畴大小进行分段，1 ~ 999999 放到数据库 1 的表中，1000000 ~ 1999999 放到数据库 2 的表中，以此类推。

范畴路由设计的简单点次要体现在分段大小的选取上，分段太小会导致切分后子表数量过多，减少保护复杂度；分段太大可能会导致单表仍然存在性能问题，个别倡议分段大小在 100 万至 2000 万之间，具体须要依据业务选取适合的分段大小。

范畴路由的长处是能够随着数据的减少平滑地裁减新的表。例如，当初的用户是 100 万，如果减少到 1000 万，只须要减少新的表就能够了，原有的数据不须要动。

范畴路由的一个比拟隐含的毛病是散布不平均，如果依照 1000 万来进行分表，有可能某个分段理论存储的数据量只有 1000 条，而另外一个分段理论存储的数据量有 900 万条。

Hash 路由： 选取某个列（或者某几个列组合也能够）的值进行 Hash 运算，而后依据 Hash 后果扩散到不同的数据库表中。同样以用户 ID 为例，如果咱们一开始就布局了 10 个数据库表，路由算法能够简略地用 user\_id % 10 的值来示意数据所属的数据库表编号，ID 为 985 的用户放到编号为 5 的子表中，ID 为 10086 的用户放到编号为 6 的字表中。

Hash 路由设计的简单点次要体现在初始表数量的选取上，表数量太多保护比拟麻烦，表数量太少又可能导致单表性能存在问题。而用了 Hash 路由后，减少子表数量是十分麻烦的，所有数据都要重散布。

Hash 路由的优缺点和范畴路由根本相同，Hash 路由的长处是表散布比拟平均，毛病是裁减新的表很麻烦，所有数据都要重散布。

配置路由： 配置路由就是路由表，用一张独立的表来记录路由信息。同样以用户 ID 为例，咱们新增一张 user\_router 表，这个表蕴含 user\_id 和 table\_id 两列，依据 user\_id 就能够查问对应的 table\_id。

配置路由设计简略，应用起来非常灵活，尤其是在裁减表的时候，只须要迁徙指定的数据，而后批改路由表就能够了。

配置路由的毛病就是必须多查问一次，会影响整体性能；而且路由表自身如果太大（例如，几亿条数据），性能同样可能成为瓶颈，如果咱们再次将路由表分库分表，则又面临一个死循环式的路由算法抉择问题。

• join 操作

程度分表后，数据扩散在多个表中，如果须要与其余表进行 join 查问，须要在业务代码或者数据库中间件中进行屡次 join 查问，而后将后果合并。

• count()操作

程度分表后，尽管物理上数据扩散到多个表中，但某些业务逻辑上还是会将这些表当作一个表来解决。例如，获取记录总数用于分页或者展现，程度分表前用一个 count()就能实现的操作，在分表后就没那么简略了。常见的解决形式有上面两种：

count()相加： 具体做法是在业务代码或者数据库中间件中对每个表进行 count()操作，而后将后果相加。这种形式实现简略，毛病就是性能比拟低。例如，程度分表后切分为 20 张表，则要进行 20 次 count(*)操作，如果串行的话，可能须要几秒钟能力失去后果。

记录数表： 具体做法是新建一张表，如果表名为“记录数表”，蕴含 table\_name、row\_count 两个字段，每次插入或者删除子表数据胜利后，都更新“记录数表”。

这种形式获取表记录数的性能要大大优于 count()相加的形式，因为只须要一次简略查问就能够获取数据。毛病是复杂度减少不少，对子表的操作要同步操作“记录数表”，如果有一个业务逻辑脱漏了，数据就会不统一；且针对“记录数表”的操作和针对子表的操作无奈放在同一事务中进行解决，异样的状况下会呈现操作子表胜利了而操作记录数表失败，同样会导致数据不统一。

此外，记录数表的形式也减少了数据库的写压力，因为每次针对子表的 insert 和 delete 操作都要 update 记录数表，所以对于一些不要求记录数实时放弃准确的业务，也能够通过后盾定时更新记录数表。定时更新实际上就是“count()相加”和“记录数表”的联合，即定时通过 count()相加计算表的记录数，而后更新记录数表中的数据。

• order by 操作

程度分表后，数据扩散到多个子表中，排序操作无奈在数据库中实现，只能由业务代码或者数据库中间件别离查问每个子表中的数据，而后汇总进行排序。

实现办法

和数据库读写拆散相似，分库分表具体的实现形式也是“程序代码封装”和“中间件封装”，但实现会更简单。读写拆散实现时只有辨认 SQL 操作是读操作还是写操作，通过简略的判断 SELECT、UPDATE、INSERT、DELETE 几个关键字就能够做到，而分库分表的实现除了要判断操作类型外，还要判断 SQL 中具体须要操作的表、操作函数（例如 count 函数)、order by、group by 操作等，而后再依据不同的操作进行不同的解决。例如 order by 操作，须要先从多个库查问到各个库的数据，而后再从新 order by 能力失去最终的后果。

高性能 No SQL

关系数据库通过几十年的倒退后曾经十分成熟，弱小的 SQL 性能和 ACID 的属性，使得关系数据库广泛应用于各式各样的零碎中，但这并不意味着关系数据库是完满的，关系数据库存在如下毛病。

• 关系数据库存储的是行记录，无奈存储数据结构

以微博的关注关系为例，“我关注的人”是一个用户 ID 列表，应用关系数据库存储只能将列表拆成多行，而后再查问进去组装，无奈间接存储一个列表。

• 关系数据库的 schema 扩大很不不便

关系数据库的表构造 schema 是强束缚，操作不存在的列会报错，业务变动时裁减列也比拟麻烦，须要执行 DDL（data definition language，如 CREATE、ALTER、DROP 等）语句批改，而且批改时可能会长工夫锁表（例如，MySQL 可能将表锁住 1 个小时）。

• 关系数据库在大数据场景下 I / O 较高

如果对一些大量数据的表进行统计之类的运算，关系数据库的 I / O 会很高，因为即便只针对其中某一列进行运算，关系数据库也会将整行数据从存储设备读入内存。

• 关系数据库的全文搜寻性能比拟弱

关系数据库的全文搜寻只能应用 like 进行整表扫描匹配，性能非常低，在互联网这种搜寻简单的场景下无奈满足业务要求。

针对上述问题，别离诞生了不同的 NoSQL 解决方案，这些计划与关系数据库相比，在某些利用场景下体现更好。但世上没有收费的午餐，NoSQL 计划带来的劣势，实质上是就义 ACID 中的某个或者某几个个性，因而咱们不能自觉地科学 NoSQL 是银弹，而应该将 NoSQL 作为 SQL 的一个无力补充，NoSQL != No SQL，而是 NoSQL = Not Only SQL。

常见的 NoSQL 计划分为 4 类。

• K- V 存储：解决关系数据库无奈存储数据结构的问题，以 Redis 为代表。
• 文档数据库：解决关系数据库强 schema 束缚的问题，以 MongoDB 为代表。
• 列式数据库：解决关系数据库大数据场景下的 I / O 问题，以 HBase 为代表。
• 全文搜索引擎：解决关系数据库的全文搜寻性能问题，以 Elasticsearch 为代表。

上面，我介绍一下各种高性能 NoSQL 计划的典型特色和利用场景。

K- V 存储

K- V 存储的全称是 Key-Value 存储，其中 Key 是数据的标识，和关系数据库中的主键含意一样，Value 就是具体的数据。

Redis 是 K - V 存储的典型代表，它是一款开源（基于 BSD 许可）的高性能 K - V 缓存和存储系统。Redis 的 Value 是具体的数据结构，包含 string、hash、list、set、sorted set、bitmap 和 hyperloglog，所以经常被称为数据结构服务器。

以 List 数据结构为例，Redis 提供了上面这些典型的操作（更多请参考链接：http://redis.cn/commands.html#list）：

• LPOP key 从队列的右边出队一个元素。
• LINDEX key index 获取一个元素，通过其索引列表。
• LLEN key 取得队列（List）的长度。
• RPOP key 从队列的左边出队一个元素。

以上这些性能，如果用关系数据库来实现，就会变得很简单。例如，LPOP 操作是移除并返回 key 对应的 list 的第一个元素。如果用关系数据库来存储，为了达到同样目标，须要进行上面的操作：

• 每条数据除了数据编号（例如，行 ID），还要有地位编号，否则没有方法判断哪条数据是第一条。留神这里不能用行 ID 作为地位编号，因为咱们会往列表头部插入数据。
• 查问出第一条数据。
• 删除第一条数据。
• 更新从第二条开始的所有数据的地位编号。

能够看出关系数据库的实现很麻烦，而且须要进行屡次 SQL 操作，性能很低。

Redis 的毛病次要体现在并不反对残缺的 ACID 事务，Redis 尽管提供事务性能，但 Redis 的事务和关系数据库的事务不可同日而语，Redis 的事务只能保障隔离性和一致性（I 和 C），无奈保障原子性和持久性（A 和 D）。

尽管 Redis 并没有严格遵循 ACID 准则，但实际上大部分业务也不须要严格遵循 ACID 准则。以下面的微博关注操作为例，即便零碎没有将 A 退出 B 的粉丝列表，其实业务影响也十分小，因而咱们在设计方案时，须要依据业务个性和要求来确定是否能够用 Redis，而不能因为 Redis 不遵循 ACID 准则就间接放弃。

文档数据库

为了解决关系数据库 schema 带来的问题，文档数据库应运而生。文档数据库最大的特点就是 no-schema，能够存储和读取任意的数据。目前绝大部分文档数据库存储的数据格式是 JSON（或者 BSON），因为 JSON 数据是自描述的，毋庸在应用前定义字段，读取一个 JSON 中不存在的字段也不会导致 SQL 那样的语法错误。

文档数据库的 no-schema 个性，给业务开发带来了几个显著的劣势。

1. 新增字段简略

业务上减少新的字段，无须再像关系数据库一样要先执行 DDL 语句批改表构造，程序代码间接读写即可。

2. 历史数据不会出错

对于历史数据，即便没有新增的字段，也不会导致谬误，只会返回空值，此时代码进行兼容解决即可。

3. 能够很容易存储简单数据

JSON 是一种弱小的描述语言，可能形容简单的数据结构。例如，咱们设计一个用户管理系统，用户的信息有 ID、姓名、性别、喜好、邮箱、地址、学历信息。其中喜好是列表（因为能够有多个喜好）；地址是一个构造，包含省市区楼盘地址；学历包含学校、业余、退学毕业年份信息等。如果咱们用关系数据库来存储，须要设计多张表，包含根本信息（列：ID、姓名、性别、邮箱）、喜好（列：ID、喜好）、地址（列：省、市、区、具体地址）、学历（列：退学工夫、毕业工夫、学校名称、业余），而应用文档数据库，一个 JSON 就能够全副形容。

 {
    "id": 10000,
    "name": "James",
    "sex": "male",
    "hobbies": [
        "football",
        "playing",
        "singing"
    ],
    "email": "user@google.com",
    "address": {
        "province": "GuangDong",
        "city": "GuangZhou",
        "district": "Tianhe",
        "detail": "PingYun Road 163"
    },
    "education": [
        {
            "begin": "2000-09-01",
            "end": "2004-07-01",
            "school": "UESTC",
            "major": "Computer Science & Technology"
        },
        {
            "begin": "2004-09-01",
            "end": "2007-07-01",
            "school": "SCUT",
            "major": "Computer Science & Technology"
        }
    ]
 }

通过这个样例咱们看到，应用 JSON 来形容数据，比应用关系型数据库表来形容数据不便和容易得多，而且更加容易了解。

文档数据库的这个特点，特地适宜电商和游戏这类的业务场景。以电商为例，不同商品的属性差别很大。例如，冰箱的属性和笔记本电脑的属性差别十分大，如下图所示。

即便是同类商品也有不同的属性。例如，LCD 和 LED 显示器，两者有不同的参数指标。这种业务场景如果应用关系数据库来存储数据，就会很麻烦，而应用文档数据库，会简略、不便许多，扩大新的属性也更加容易。

文档数据库 no-schema 的个性带来的这些劣势也是有代价的，最次要的代价就是不反对事务。例如，应用 MongoDB 来存储商品库存，零碎创立订单的时候首先须要减扣库存，而后再创立订单。这是一个事务操作，用关系数据库来实现就很简略，但如果用 MongoDB 来实现，就无奈做到事务性。异常情况下可能呈现库存被扣减了，但订单没有创立的状况。因而某些对事务要求严格的业务场景是不能应用文档数据库的。

文档数据库另外一个毛病就是无奈实现关系数据库的 join 操作。例如，咱们有一个用户信息表和一个订单表，订单表中有买家用户 id。如果要查问“购买了苹果笔记本用户中的女性用户”，用关系数据库来实现，一个简略的 join 操作就搞定了；而用文档数据库是无奈进行 join 查问的，须要查两次：一次查问订单表中购买了苹果笔记本的用户，而后再查问这些用户哪些是女性用户。

列式数据库

顾名思义，列式数据库就是依照列来存储数据的数据库，与之对应的传统关系数据库被称为“行式数据库”，因为关系数据库是依照行来存储数据的。

关系数据库依照行式来存储数据，次要有以下几个劣势：

• 业务同时读取多个列时效率高，因为这些列都是按行存储在一起的，一次磁盘操作就可能把一行数据中的各个列都读取到内存中。
• 可能一次性实现对一行中的多个列的写操作，保障了针对行数据写操作的原子性和一致性；否则如果采纳列存储，可能会呈现某次写操作，有的列胜利了，有的列失败了，导致数据不统一。

咱们能够看到，行式存储的劣势是在特定的业务场景下能力体现，如果不存在这样的业务场景，那么行式存储的劣势也将不复存在，甚至成为劣势，典型的场景就是海量数据进行统计。例如，计算某个城市体重超重的人员数据，实际上只须要读取每个人的体重这一列并进行统计即可，而行式存储即便最终只应用一列，也会将所有行数据都读取进去。如果单行用户信息有 1KB，其中体重只有 4 个字节，行式存储还是会将整行 1KB 数据全副读取到内存中，这是显著的节约。而如果采纳列式存储，每个用户只须要读取 4 字节的体重数据即可，I/ O 将大大减少。

除了节俭 I /O，列式存储还具备更高的存储压缩比，可能节俭更多的存储空间。一般的行式数据库个别压缩率在 3:1 到 5:1 左右，而列式数据库的压缩率个别在 8:1 到 30:1 左右，因为单个列的数据类似度相比行来说更高，可能达到更高的压缩率。

同样，如果场景发生变化，列式存储的劣势又会变成劣势。典型的场景是须要频繁地更新多个列。因为列式存储将不同列存储在磁盘上不间断的空间，导致更新多个列时磁盘是随机写操作；而行式存储时同一行多个列都存储在间断的空间，一次磁盘写操作就能够实现，列式存储的随机写效率要远远低于行式存储的写效率。此外，列式存储高压缩率在更新场景下也会成为劣势，因为更新时须要将存储数据解压后更新，而后再压缩，最初写入磁盘。

基于上述列式存储的优缺点，个别将列式存储利用在离线的大数据分析和统计场景中，因为这种场景次要是针对局部列单列进行操作，且数据写入后就无须再更新删除。

全文搜索引擎

传统的关系型数据库通过索引来达到疾速查问的目标，然而在全文搜寻的业务场景下，索引也无能为力，次要体现在：

• 全文搜寻的条件能够随便排列组合，如果通过索引来满足，则索引的数量会十分多。
• 全文搜寻的含糊匹配形式，索引无奈满足，只能用 like 查问，而 like 查问是整表扫描，效率非常低。

我举一个具体的例子来看看关系型数据库为何无奈满足全文搜寻的要求。假如咱们做一个婚恋网站，其次要目标是帮忙程序员找敌人，但模式与传统婚恋网站不同，是“程序员公布本人的信息，用户来搜寻程序员”。程序员的信息表设计如下：

咱们来看一下这个简略业务的搜寻场景：

• 美女 1：据说 PHP 是世界上最好的语言，那么 PHP 的程序员必定是钱最多的，而且我妈肯定要我找一个上海的。

美女 1 的搜寻条件是“性别 + PHP + 上海”，其中“PHP”要用含糊匹配查问“语言”列，“上海”要查问“地点”列，如果用索引撑持，则须要建设“地点”这个索引。

• 美女 2：我好崇拜这些技术哥哥啊，要是能找一个鹅厂技术哥哥陪我游览就更好了。

美女 2 的搜寻条件是“性别 + 鹅厂 + 游览”，其中“游览”要用含糊匹配查问“喜好”列，“鹅厂”须要查问“单位”列，如果要用索引撑持，则须要建设“单位”索引。

• 美女 3：我是一个“女程序员”，想在北京找一个猫厂的 Java 技术专家。

美女 3 的搜寻条件是“性别 + 猫厂 + 北京 + Java + 技术专家”，其中“猫厂 + 北京”能够通过索引来查问，但“Java”“技术专家”都只能通过含糊匹配来查问。

• 帅哥 4：程序员妹子有没有丑陋的呢？试试看看。

帅哥 4 的搜寻条件是“性别 + 漂亮 + 美女”，只能通过含糊匹配搜寻“自我介绍”列。

以上只是简略举个例子，实际上搜寻条件是无奈列举齐全的，各种排列组合十分多，通过这个简略的样例咱们就能够看出关系数据库在撑持全文搜寻时的有余。

1. 全文搜寻基本原理

全文搜索引擎的技术原理被称为“倒排索引”（Inverted index），也常被称为反向索引、置入档案或反向档案，是一种索引办法，其基本原理是建设单词到文档的索引。之所以被称为“倒排”索引，是和“正排“索引绝对的，“正排索引”的基本原理是建设文档到单词的索引。咱们通过一个简略的样例来阐明这两种索引的差别。

假如咱们有一个技术文章的网站，外面收集了各种技术文章，用户能够在网站浏览或者搜寻文章。

正排索引示例：

正排索引实用于依据文档名称来查问文档内容。例如，用户在网站上单击了“面向对象葵花宝典是什么”，网站依据文章题目查问文章的内容展现给用户。

倒排索引示例：

倒排索引实用于依据关键词来查问文档内容。例如，用户只是想看“设计”相干的文章，网站须要将文章内容中蕴含“设计”一词的文章都搜寻进去展现给用户。

2. 全文搜寻的应用形式

全文搜索引擎的索引对象是单词和文档，而关系数据库的索引对象是键和行，两者的术语差别很大，不能简略地等同起来。因而，为了让全文搜索引擎反对关系型数据的全文搜寻，须要做一些转换操作，行将关系型数据转换为文档数据。

目前罕用的转换形式是将关系型数据依照对象的模式转换为 JSON 文档，而后将 JSON 文档输出全文搜索引擎进行索引。我同样以程序员的根本信息表为例，看看如何转换。

将后面样例中的程序员表格转换为 JSON 文档，能够失去 3 个程序员信息相干的文档，我以程序员 1 为例：

 {
  "id": 1,
  "姓名": "多隆",
  "性别": "男",
  "地点": "北京",
  "单位": "猫厂",
  "喜好": "写代码，游览，马拉松",
  "语言": "Java、C++、PHP",
  "自我介绍": "技术专家，简略，为人激情"
 }

全文搜索引擎可能基于 JSON 文档建设全文索引，而后疾速进行全文搜寻。以 Elasticsearch 为例，其索引基本原理如下：

Elastcisearch 是分布式的文档存储形式。它能存储和检索简单的数据结构——序列化成为 JSON 文档——以实时的形式。

在 Elasticsearch 中，每个字段的所有数据都是默认被索引的。即每个字段都有为了疾速检索设置的专用倒排索引。而且，不像其余少数的数据库，它能在雷同的查问中应用所有倒排索引，并以惊人的速度返回后果。

总结

明天我讲了读写拆散形式的原理，以及两个设计复杂度：复制提早和分配机制，紧接着讲了高性能数据库集群的分库分表架构，包含业务分库产生的问题和分表的两种形式及其带来的复杂度，最初谈了谈为了补救关系型数据库缺点而产生的 NoSQL 技术。如果本文对你有帮忙的话，欢送点赞分享，这对我持续分享 & 创作优质文章十分重要。感激！

本文由 mdnice 多平台公布