异步删除索引. RavenDB 中的索引包含两部分, 实际数据跟元数据. 一般情况下, 元数据的要比实际数据少. 但是对于 map/reduce 索引来说, 情况刚好相反, 因为它的元数据包含了许多中间步骤相关的数据. 如果你在大规模数据库中使用LoadDocument, 我们还需要维护文档的引用,这需要大量的存储空间. 结果导致在 RavenDB 2.5 中删除索引的过程变得极其缓慢.
到了 RavenDB 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 基本上就是卡死在那, 什么都没做.
评论删除后,数据将无法恢复
评论(7)