想扩展你的数据库吗？那么先学习一下I/O

    诚然，一个好的索引方式还不足够，如果是一个OLTP应用，那么所有的查询从本质上讲都是点查询（因为他们只是检索极少的文件），即使使用一个完全适合的索引，用户还是会出现I/O的瓶颈问题。在这种情况下，硬件的解决方案就是必要的。

    当然，增加索引也意味着增加插入的成本，因为每个插入操作都要保证索引的及时更新，但是写优化的数据库可以减少一定的成本。这也是我一直强调我们需要理解应用的原因所在，对于某些应用来说，一个可行的解决方案，并不代表也适用于其他的应用。

    问题：修改或者删除导致过多的I/O

    解决方案：整合以上所有的解决方案

    修改和删除之所以复杂是因为这是查询和插入的一个整合。提升它们的性能要求对操作开销有一个很好的理解。哪部分操作会涉及到I/O？是查询？如果这样，我们就提升索引。是写操作？还是兼而有之？简单来讲，就是哪部分操作牵涉到I/O问题，我们就应用对应的解决方案。

    一个很常见的错误就是：当我们使用一个写优化的数据库（像TokuMX），在不改变任何索引的情况下，就希望它能够消除修改或者删除的I/O瓶颈问题。毕竟，写优化的数据库还是不足够的，在修改/删除过程中的隐含的查询也必须进行处理。

    可行的硬件解决方案

    就像上文提到的那样，当软件解决方案不能够解决问题的时候，我们就需要寻求硬件的解决方案。我们先分析一下硬件的优势和劣势：

    购买尽可能多的内存，即使难以做到，也要把工作集放到内存中

    使用SSD来增加IOPS

    购买更多的服务器，并使用一个可扩展的解决方案，其中包括

    通过副本进行读扩展

    分片

    购买更多的内存

    RAM是很昂贵的，而且在一台机器上可扩展的内存也是有限的。如果数据太大，都保存在RAM中也不是一个可行的选择。这种解决方案可能适于用大多数的应用，但我们更关注那些这种方案解决不了的应用。

    使用SSD存储

    不可否认，如果存储设备使用SSD提升吞吐量，这绝对是一个很实用的解决方案。如果I/O成为应用的限制性因素，那么增加IOPS（每秒的I/O操作）理所当然地能够增加吞吐量，简单且使用。

    然而，SSD的成本和硬盘的成本也不一样，SSD绝对可以显著地提升I/O的吞吐量，虽然成本也不便宜，但是更轻、容量更大，速率也更快。那么为了降低成本，数据压缩就是一个关键。 其实，虽然硬件成本增加了，但这并不意味着管理成本也会增加：

[page]    通过副本进行读扩展

    当查询操作成为应用的瓶颈，那么通过副本进行读扩展就是一个非常有效的解决方案。想法如下：

    使用备份功能，将多个数据拷贝到相互独立的机器上

    分布地在不同的机器上进行读取，这样将会提升读的吞吐量

    如果在单一的机器上进行读操作而且传输出来，这样会出现很大的瓶颈。如果有多个副本的话，应用将有更多的资源可用，因此读写方面都将有很大的提升。

    如果是插入、修改或者是删除过程存在瓶颈，那么副本可能就不会那么的高效。这是因为写操作需要将数据备份到所有的服务器的副本集上，机器在数据的输入过程中也面临同样的瓶颈问题。

    分片

    基于shard key，分片片将数据切分到不同的副本集，集群中不同副本集负责相应范围的值。所以，可以通过将写操作分配给集群中不同的副本集来提升应用程序的写吞吐量。对于写负载高的应用，分片可以非常有效的。

    在shard key空间中将数据按范围划分，使用shard key横跨多个副本做范围查询可以非常有效。如果将shard key哈希，那么所有范围查询必须运行在集群中的所有分片，但是在shard key上的点查询只运行在一个分片上。shard key哈希，据结构模型并且不支持join，分片用起来非常的高效且简单。如果上述的方案都不足以解决应用的瓶颈问，那么你可以在分片上多下工夫了。

    无论如何，分片都是一个重量级的解决方案，而且成本非常之高。对初入者来说，你的硬件投入预算需要增加好几倍。不仅仅需要为分片设置增加服务器，还需要增加一整套副本集。你还需要增加和管理配置服务器，考虑到成本问题，用户需要慎重考虑分片是不是很必要。通常来讲，上面所有方案都比这个节省成本。

    另外一个很大的挑战就是选择一个shard key，一个好的shard key有以下特点：

    大多数（如果不是全部）的查询都使用shard key，任何查询（没有使用shard key）必须运行在所有的分片上。这点可能比较麻烦。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!