RavenDB 租户加载缓慢

Question

我们在 Multi-Tenancy 环境中使用 RavenDB，用户可以在那里创建自己的租户并创建自己的应用程序。

然而，问题是他们的数据库时不时地闲置(当然是在验收中，但在生产中也会发生)，并且由于某种原因需要超过 40 秒才能重新加载它。但是我们只有大约 1000 个文档和大约 300 个索引(这是应用程序的蓝图，一旦投入生产就应该包含更多文档)，并且所有索引都有一个 Map 和一个 TransformResults-子句。

版本:2.0.2230 和 2.0.2261(撰写本文时的最新稳定版)

一般统计

 ...
TransactionalStorageSize:26222592,
TransactionalStorageSizeHumaneSize:"25.01 MBytes",
IndexStorageSize:376263,
IndexStorageHumaneSize:"367.44 KBytes",
TotalDatabaseSize:26598855,
TotalDatabaseHumaneSize:"25.37 MBytes",
CountOfDocuments:975,
...

数据库统计

CountOfIndexes:305,
InMemoryIndexingQueueSize:0,
ApproximateTaskCount:0,
CountOfDocuments:975,
StaleIndexes:[],
CurrentNumberOfItemsToIndexInSingleBatch:256,
CurrentNumberOfItemsToReduceInSingleBatch:128,
DatabaseTransactionVersionSizeInMB:0.02,
....
Errors:[],
....

编辑

我们正在谈论的应用程序有两个组件，一个设计器和一个运行时。在 ravendb 中，我们存储设计和在运行时创建/使用的数据。每个租户都是一个应用程序。

我们有这么多索引，因为对于您在设计模式中创建的每个查询，我们都会在 ravendb 中创建一个索引。

索引的形式为:Map from ... [from...|let...] [where ... ] select ... 调用 LoadDocument 加载所需的关联给定 lucene 查询的文档和类似的 TransfromResults 以所需形式塑造文档。

我将调查是否可以放松查询和索引之间的一对一耦合。

问:是拥有一些巨大的索引更好，比如为我们查询的每个实体创建一个索引，还是找到一些中间地带？

问:目前我们的实体设计中不允许有“复杂”的实体，即只有值属性或对其他文档的引用，如果我们有更少或更大的实体，这是否会产生影响文档，因此必须减少对 LoadDocument(...) 的调用？

这需要这么长时间(40 秒)吗？任何减轻这种情况的可能方法将不胜感激。

Answer 1

回答此问题的 1 个子问题:

Q: Is it better to have a few gigantic indexes, lets say one for each Entity on which we query, or to find some middleground?

在正常情况下，每个实体类型永远不需要超过 1 个索引。

如果你有几十种实体类型，你很可能掉进了将 RDBMS 模型设计应用到非关系设计的坑中。换句话说，我们有一个功能丰富的系统，它建立在总共 8 个聚合根之上。拥有2-3个配套基础设施实体。

我们共有 17 个索引。 8 个 Map、5 个 Multi-map 和 5 个 map-reduce。如您所见，我们有 1:1 的 Map:Aggregate Root 索引比率。使用额外的索引来支持聚合搜索和 map/reduce 以获取自定义结果。