深入浅出大型网站架构设计：数据库

数据库的选择

所有的关系数据库都有一个模式（schema），模式是指数据库的逻辑设计，通俗地说，就是数据库表的定义。SQL在对数据库进行操作时，整个过程被称为一个事务。

关系数据库在完成数据操作时始终保持一致，而不会因为一些操作的错误或者先后顺序问题让某些请求读到一些过时或者不正确的数据。这一般也被简称为关系数据库的数据一致性。

对于如下的需求或者应用场景，关系数据库是非常合适的。

• 经常要对数据进行非常复杂或者繁琐的操作的业务。
• 对数据操作的安全性和可靠性要求极高的业务。

非关系数据库中新记录的键值对可以自由输入，即如果该非关系数据库没有特殊定义的话，新记录中可以缺失旧记录中的键值对，也可以有旧记录中所没有的键值对。但关系数据库则不同，虽然在值可以为空的前提下，新记录也可以缺失某些字段，但是要添加新的字段，却远比非关系数据库麻烦，因为模式定义需要先被更新，并且还需要注意向后兼容，以及与其他被关联的表的问题。

数据库优化：分库分表

数据库从广义上说是一台服务器，或者服务器集群，因此，当数据存量或者数据的吞吐量增大时，服务器的负担就会逐渐增加以至于影响读／写的性能和成功率。这时，就需要将数据库进行切分。如果将数据分散到多台数据库服务器，则称为分库；如果将一台数据库服务器上的数据用多张表表示，则称为分表。

数据量太大时，数据库的性能会受到影响。数据量大有两个方面：一是数据的吞吐量很大，即每次存储或读取的数据都很复杂或者很大；二是数据库本身保存的数据很多。

当数据的吞吐量很大时，主要会影响数据库读／写的延时，因为每次经过网络传输的数据都很多，当数据库是关系数据库时，由于其在一般情况下操作比非关系数据库更为复杂、涉及的验证和安全操作更多，所以消耗的时间和资源会更多。因此，出现这种情况时，需要网站开发者通过对数据语义和业务逻辑具体情况的分析，将数据库进行分库或者分表。

垂直分库分表适用于如下场景：

• 表的列数过多。
• 表中的信息明显属于多个业务逻辑模块。
• 表中的信息重要程度差异明显。
• 表中的字段大小差异明显。
• 表中的字段访问频率差异明显。

分表之后，所有分出来的表都依然和原来的表共享唯一的ID。

水平分库分表适用于如下场景：

• 当前单库或单表的数据行数过大，已经导致单库或者单表的读／写出现了性能下降。
• 尚未出现性能瓶颈，但业务特征导致数据库规模（行数）

分库分表带来的问题

• 全局唯一ID
  • 当表或者库只有一个时，可以利用数据库本身的主键生成逻辑，为每一条新数据生成一个全局唯一的ID，但是如果数据被切分到多个库或者多张表中，显然单靠数据库本身就不能保证生成的码是唯一的了，而是要通过应用层的逻辑去保证。
• 关系数据库的部分操作
  • 分库分表之后会影响关系数据库的部分操作的有效性和效率。这些操作无法在多个库之间进行，而是依然要使用应用层的逻辑，让网站开发者使用编程语言手动实现这些操作。
  • 数据库的类似功能是经过数据库的专业开发者千锤百炼并用了很多复杂算法优化的，而普通网站的开发者一般只会使用一些简单、直接的逻辑和数据结构去实现，当数据量很大时，这些开发者自行编写的查询代码的运行性能也会差于能达到同样目的的原生的数据库操作的性能，消耗的系统资源也会更多。