1 简介
SequoiaDB是一个开源、高性能、可扩展、通用型的数据库。为了满足企业在线应用程序的低延迟、高性能特性，许多企业都已采用SequoiaDB来支持他们的在线应用程序。
本篇指南阐述了，想要在SequoiaDB系统中获得大规模集群的高性能，就需要从硬件、应用程序模式、模式设计和索引、磁盘I/O以及基本准则等方面着手。使用本指南的建议，您的应用程序将能避免遇到一些常见的性能问题，而且在大部分情况下，系统的性能也会得到提升。
2 硬件SequoiaDB具有优秀的水平可扩展性。区别于传统关系型数据库只能在单台昂贵的服务器上单点运行，SequoiaDB采用高性价比的PC服务器搭建集群来扩展应用程序系统。与此同时，SequoiaDB采用多副本管理来提供系统的可用性，采用自动分片技术来均衡数据分布，以及通过内存计算为用户提供高性能。下面的建议将会帮助您优化SequoiaDB系统中的硬件。
确保工作集装入内存：如果能把所有的工作集都装入内存，那么SequoiaDB的性能将会达到最佳。一般来说，影响系统性能最关键的硬件因素莫过于内存。即使当其他所有硬件都优化了，但内存不足，那么系统的性能也不会有显著地提高。而如果工作集超过了单台服务器的内存，那么可以考虑把工作集分片装入到不同的服务器。
为读多写少的应用程序使用SSD：SequoiaDB中的磁盘I/O几乎都是随机的，因此使用SSD能显著提高搭建在SequoiaDB上读多写少系统的性能。这是因为数据访问主要是受磁盘子系统寻道时间的影响，而旋转磁盘的寻道时间是5ms左右，SSD寻道时间是0.1ms左右。因此SSD的寻道时间比旋转磁盘的寻道时间快了将近50倍。
使用更高性能的CPU：数据库的处理能力除了和IO、内存有关外，还与CPU的效率息息相关。使用高性能的CPU在IO不成为瓶颈的前提下能够提升性能。
每块硬盘部署独立的数据节点：为了能减少磁盘I/O开销，SequoiaDB建议每块物理硬盘对应一个独立的数据服务进程（数据节点）。这样可以尽量避免多个数据节点访问同一块物理硬盘，造成随机I/O。
使用多个协调节点：在SequoiaDB系统中，尽可能在每一台物理机中部署协调节点。当协调节点和应用程序部署在同一台服务器上时，应用程序和协调节点就能进行本地通信；而如果协调节点与数据节点部署在同一台服务器上时，协调节点和数据节点就可以进行本地通信，减少网络开销。
3 应用程序模式
SequoiaDB不仅拥有动态数据模式和丰富的查询功能，而且还为用户提供了大量的二级索引来优化系统的查询性能。当用户为应用程序考虑选择系统时，应当首先考虑系统的灵活性和复杂性。接下来的建议将会帮助您优化应用程序模式。
使用批量操作来加载大批量数据：当写操作能通过一个写参数来指定时，批量加载数据到SequoiaDB上将会变得简单有效。
通过查找和设置操作来执行更新操作：更新字段，并不是在应用程序中检索整个文档，而是通过查找该字段、设置该字段来执行对指定字段的更新。这样做的优势有1）使用了更少的网络资源；2）减少了数据的往返次数；3）除去了不必要的索引更新。
在查询中避免使用否定词（not）：与当前大部分数据库系统类似，SequoiaDB不支持对否定字段的查询。这是由于，否定查询需要遍历结果集中的所有记录。如果，只有一个否定词的条件查询，那么所有的记录都将要被访问。
为你应用程序中的每个查询使用explain()：SequoiaDB能显示系统是如何评估查询的。这个评估过程包括，查询中使用了哪个索引，这个查询是否被覆盖了等等。来自explain()的反馈能帮助您了解查询是否有优化执行。
避免散集查询：散集查询，是指在分片系统中，不能定位到单个分片的查询。由于散集查询会涉及到多个分片，因此应当尽量避免散集查询。
使用从副本：如果你的应用程序能接受短暂不一致的数据，那么你可以从辅助副本读取数据。通常，辅助副本的数据更新会依赖于网络延迟。因此，在辅助副本上读到的数据通常会与主副本上读到的数据存在短暂的不一致。
使用来自SequoiaDB公司的最新驱动程序：SequoiaDB有支持多种语言的驱动程序，这些驱动程序是由维护数据库内核团队设计开发的。因此您应该尽可能的使用最新版的驱动程序。如果有支持您的语言驱动程序，那么请您安装原始扩展程序。
确保均匀的分片：如果系统不是均匀分片，那么单个分片的读写能力是受限的。而如果系统是均匀分片的，那么系统就不存在单分片受限问题。
尽可能采用基于哈希的分片技术：对于基于范围查询的应用程序，基于范围的分片能为该查询定位到少数几个分片，而且通常是一个分片。但是，基于范围的分片需要对你的数据与查询有一个很好的理解。而基于哈希的分片能确保一个分布均匀的读写操作，但却不能提供有效的范围查询。
4 模式设计和索引
SequoiaDB使用基于JSON标准的BSON二进制文档型数据模型。不同于关系型数据库中扁平的设计，SequoiaDB文档型数据模型与现代编程语言的对象相匹配。由于SequoiaDB把一条记录的所有数据都放入一个文档，所以SequoiaDB基本不需要复杂的事务查询以及关联。下面的建议将会帮助您，在设计模式和索引的时候做出正确的选择。
存储一条记录的所有数据到单个文档：SequoiaDB提供了文档级的原子操作。由于把整条记录都存入单个文档中，因此整条记录能有效的在一个单一的查询中检索到。但在某些例子中，存储整条记录在单一文档中是不切实际的，所以请一定要为您的应用程序做出最好的选择。
避免大文档：在SequoiaDB中，单个文档的最大容量是16MB。但在很多实际情况下，大部分文档都只有几KB或者更小。我们觉得这里的文档不像是关系型数据库中的表，而更像是关系型数据库中的行。因此不同于维护文档中的列表，而是为每条记录都生成一个文档。
避免无限文档增长：一旦文档创建，SequoiaDB就会为其分配空间。如果该文档变大，则SequoiaDB将会在一个更大的空间上重写这个文档，并且更新该文档所有的索引条目。如果文档变长的操作是必须的，那么我们应该尽可能设计文档不会无限增长。而如果考虑到文档会随着时间的变化而不断增长，则可以考虑在创建文档之初就多预留些空间以备文档的增长。
使用更短的字段名称：字段名会重复的出现在文档中。可以通过使用更小的字段名称，来减少空间的消耗，这也会使得大量的文档能够装入内存中。
避免低基数字段的索引：低基数字段查询将会返回一个很大的结果集，而我们应该尽量避免出现大的结果集。复合索引可能会包含低基数字数，但是混合字段一般都具有较高基数。
当事先有一个判断，使用复合索引：复合索引能快速定位到一个以上字段。因此使用复合索引在查询条件满足时能够更高效地定位到数据。
消除不必要的索引：索引是占用大量资源的。他们消耗内存，而且每当字段更新时，其相关索引都需要被更新，这会影响潜在重要的磁盘I/O。
删除其他索引的前缀索引：复合查询能够用来一个索引中关键字段的查询。例如关于姓氏、名字的复合查询，首先就会过滤掉只有姓氏的记录。在这个案例中，只有姓氏的额外索引是非必要的。复合索引对于姓氏查询，姓氏和名字的复合查询都是有效的。
避免正则表达式：索引是按值排序的。通常前序通配符是低效的，并可能导致全索引扫描。而当表达式中有区分大小写的前序字符的时候，后序通配符就可能很有效。
5 磁盘I/O
SequoiaDB通过内存中的数据结构进行读写操作，而且数据也会持久化到磁盘。对任何系统来说，存储系统的性能都是非常重要的。当一个系统的首要目标是高性能时，用户应该尽量采用高性能存储，而非网络存储。接下来的建议会帮助您使用最佳存储配置，包括操作系统和文件系统配置等。
使用EXT4或者XFS文件系统，而不是EXT3：EXT3是一个很古老的文件系统，而且他对于大部分数据库来说都不是最优的。例如，SequoiaDB会为数据预留分配空间，而EXT3会通过实际写来预留分配空间。相比较而言，EXT4和XFS则会通过一个逻辑操作来预留分配空间。
禁止保留访问时间：大多数的文件系统都会保留文件访问时间。通常，这个访问时间对某些应用程序来说是有意义的。但对数据库而言，每次访问数据库一个页面都需要写一条访问时间记录，这会对系统的性能和吞吐量产生很大的负面影响。
不要使用大页面：不要使用大的虚拟内存页面，SequoiaDB在正常的虚拟内存页面中能更好的执行。
使用RAID10或JBOD：在SequoiaDB中，RAID5的性能不是很理想，RAID0性能不错但却不能提供足够的容错。RAID10是提供最佳性能和容错的结合。在不能提供RAID10的情况下可以考虑JBOD，使用集群数据复制的机制保障数据的可靠性。
把日志和数据分别存放在不同的设备上：通过使用不同的存储设备来存储日志和数据文件，你将会获得更高的磁盘系统的吞吐量。由于磁盘I/O的日志文件通常是序列化的，因此SSD不会有一个实质性的改善，这时使用标准旋转磁盘应该会更有效。
6 基准的建议
通用基准测试的结果有时可能并不能完全符合项目的规范。SequoiaDB建议，用户应当根据自身应用程序的数据、查询、硬件和系统对其建立测试模型并评估。下面的建议将会帮助你开发符合您应用程序标准的基准测试框架。
为应用程序建立基准模型：在基准测试中，您测试的查询、数据、系统配置和性能目标应该能够反映生产系统的目标。如果模型不能反映你生产系统的目标，则可能会产生误导的结果。
在加载之前创建块或使用哈希分片：如果范围查询是基准测试的一部分，那么应该采用基于范围的分布，并且在加载之前创建块。而没有预分割的数据会被加载到一个分片，然后随着加载进程再到另一个分片。如果你的基准不包括范围查询，那么你最好通过使用哈希分片来确保写的均匀分布。
测试前预热系统：在SequoiaDB的真实运行环境中，经常被访问的数据是会被加载到内存的。因此为了更准确地测试性能，测试环境一定要在收集性能数据前预热系统，模拟真实环境将常用的数据装入内存。
监控全部性能KPI来定位瓶颈：对于一个基准测试来说，通过其找到系统性能瓶颈是非常重要的。依赖整个系统的任何部件的任何因素都有可能是系统性能受限因素。
7 关于 SequoiaDB
SequoiaDB作为NoSQL数据库，重新设计了数据的管理方式，并推动了大数据行业的发展。SequoiaDB数据模型的设计，使用户能够更加敏捷地开发易扩展的系统架构。SequoiaDB支持多种类型的应用，提供了良好的用户体验，加速产品发布时间，并降低企业的运营成本。
