RavenDB3.0新特性：索引后端

RavenDB 索引绝对不是简单的对 key/value 进行存储, 其功能要强大的多. 就像3.0版本的其他特性一样, 是汗水与智慧的结晶。本文我

RavenDB 索引绝对不是简单的对 key/value 进行存储, 其功能要强大的多. 就像3.0版本的其他特性一样, 是汗水与智慧的结晶。本文我主要介绍索引在后端都有哪些变动, 使它变得更快， 更稳定， 性能更好。 至于那些用户能看得到的新特性, 会在下一篇文章中提到。

内存中的索引. 历史一次又一次地证明, 只有从硬盘着手, 我们才能跟系统优化工具说再见。 为了提高创建新索引的数据读写速度, 2.5版本中开始引入只在内存中创建新索引的新概念. 而在3.0中, 这一功能得到了进一步完善. 索引数据由原来的频繁地对硬盘读写, 改为存进内存缓冲区. 只有在一些特殊情况下(如：内存不足等), 才会将索引数据写入硬盘.

通过这种方式, 可以大量减少读写索引数据的时间, 以及维护和优化硬盘的时间. 摆脱这些束缚, 即使在高负荷的情况下, 也能保持极好的性能. 而在日常使用中, 负荷的偶尔波动也不会导致硬盘出现问题.

异步删除索引. RavenDB 中的索引包含两部分, 实际数据跟元数据. 一般情况下, 元数据的要比实际数据少. 但是对于 map/reduce 索引来说, 情况刚好相反, 因为它的元数据包含了许多中间步骤相关的数据. 如果你在大规模数据库中使用LoadDocument, 我们还需要维护文档的引用,这需要大量的存储空间. 结果导致在 RavenDB 2.5 中删除索引的过程变得极其缓慢.

到了 RavenDB 3.0, 随着异步删除索引的出现, 你可迅速删除索引. 表面上看, 索引被删除了, 其实删掉的是索引名称, 其他清理工作则留给后台异步处理. 别担心如果你需要中途重启数据库, 那么在数据库启动后, 那些未完成的清理工作仍然会在后台继续. 这种异步删除方式使维护和删除包含大量数据的索引变得相当简便.

异步删除索引. RavenDB 中的索引包含两部分, 实际数据跟元数据. 一般情况下, 元数据的要比实际数据少. 但是对于 map/reduce 索引来说, 情况刚好相反, 因为它的元数据包含了许多中间步骤相关的数据. 如果你在大规模数据库中使用LoadDocument, 我们还需要维护文档的引用,这需要大量的存储空间. 结果导致在 RavenDB 2.5 中删除索引的过程变得极其缓慢.

到了 RavenDB 3.0, 随着异步删除索引的出现, 你可迅速删除索引. 表面上看, 索引被删除了, 其实删掉的是索引名称, 其他清理工作则留给后台异步处理. 别担心如果你需要中途重启数据库, 那么在数据库启动后, 那些未完成的清理工作仍然会在后台继续. 这种异步删除方式使维护和删除包含大量数据的索引变得相当简便.

索引跟任务交替执行. 任务这个词对于 RavenDB来说, 基本上指清理索引数据. 如: 清理那些已经被删除的索引记录, 或者是对已经发生改变的引用文档重新索引. 在 2.5 版本中, 这些任务会排成长队, 在队列表中等待执行, 导致许多索引任务没有及时执行. 例如:每天都有一大堆删除索引的任务在队列中排队等待, 每执行一个这样的任务又很耗时间. 在 3.0 中, 我们做了些调整, 索引跟任务的执行交替进行, 不管队列排的多满, 都不会对索引带来太大影响.

大文档索引. RavenDB 对文档大小没有限制, 这对用户来说是好事, 但是如果 RavenDB 要对这些文档索引, 那就亚历山大了. 假如我们要对一大堆文档进行索引. 那么我们会加大每一批索引的数量. 随着系统跟文档变得越来越大, 问题就开始出现了. 许多文档在索引更新后会变得变原来的文件要大的多. 比方说, 每一批处理 128K 个文档, 每个文档 250Kb, 那就意味着每一批要索引 31GB 的文档.

这么大的数据要从磁盘读出来, 需要一定的时间, 这还不包括对内存的读写时间.而用户通常都会对大数据件压缩处理. 这会导致问题变得更加严重. 因为 RavenDB只会读取文档在磁盘上的文件大小, 也就是压缩以后的文件大小. 结果可想而知. 在 3.0 中, 对这个问题采我们采取了一些预防措施. 首先是计算在内容中的文档大小，，同时也能更好的限制每次批量操作内存的数量。

被I/O限制的批量索引. RavenDB的一个核心方案是在云服务器上运行. 但实际上, 我们的客户所用的服务器各式各样. 从i2.8xlarge EC2 (32 核, 244GB 内存, 8 x 800 GB SSD 硬盘) 到 A0 Azure (共享的 CPU, 768 MB 内存, 硬盘无力吐槽, 泪奔) 都有. 由于我们实际只使用了服务器上1/4左右的可用资源. 客户老是抱怨为什么没有把剩下的资源也用上. 问题是他们用来计算可用资源的算法跟 RavenDB 的不一样, 性能方面没什么可抱怨的, 就把火发在 RavenDB 没有“有效”利用资源上.

看起来很搞笑, 其实不然. 低端的云服务器速度慢, 性能差. 尤其是I/O 的传输速率相当慢. 如果你在这样一台服务器上给一个已经在使用中的数据库创建索引, 你会发现大部分的时间都是用来等I/O操作. 久而久之, 这个问题就会越来越严重. RavenDB一开始会从硬盘读取少量数据进行批量索引(比如花个半秒钟从硬盘上读出数据). 然后下一批, 再下一批, 就这样一批接一批的处理. 当 RavenDB 发现要处理的数据太多了, 它就会增加每一批处理的数量. 结果导致等待数据从硬盘读出来的时间变得越来越久. 在网管看来, RavenDB 基本上就是卡死在那, 什么都没做.

在 RavenDB 3.0 中, 我们不再纠结I/O的速度问题. 先从硬盘读取一部分数据, 如果在一段合理的时间段内依然无法读取足够的数据, 那我们会先将已读到的数据索引, 与此同时把读取数据的任务放到后台继续执行. 等到索引执行完后, 又可以对后台读取出来的那部分数据进行索引. 这样做可以很大程度上提高性能. (客户能看到索引跟读写操作在同事进行, 不会埋怨我们的软件无所事事)

总结 – 基本上这几个新特性都是在后台运行, 用户在前台是看不到变化的. 但是他们能协调合作, 给大家带来更好的用户体验.

英文原文：What is New in RavenDB 3.0: Indexing Backend