RavenDB 3.0 新特性:索引后端

jopen 10年前

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


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

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


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

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


用 id 代替名称. 为了打破索引跟名称之间1:1的关联, 我们在内部结构中使用数值型的 id 代表索引. 这种做法给我们带来不少压力, 因为我们必须把旧的索引(old index Users/Search: 正在被删除的索引) 跟新的索引(new Users/Search index: 正在创建中的索引)区分开来. 

好的一面是, 我们使用的内部结构通常都能高效的处理索引操作. 读写操作和压缩磁盘使用空间的速度得到了很大的提高. 

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

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