伯克利数据库中Map<Number、Map<Number、Number>>的建模

Question

我正在考虑使用Berkeley DB作为高度并发移动应用程序后端的一部分。对于我的应用程序来说，使用Queue进行记录级别锁定是理想的，但是，正如标题中所述，我需要查询和更新像Map<Number,Map<Number,Number>>这样的概念性建模的数据。

外部键将引用唯一的Item，内部键将引用Item的度量之一。内部值将是我需要原子递增的计数器，可能非常频繁。因此，为什么记录级别锁定在这里是一个可取的特性。理想情况下，记录级别将类似于数据模型中的Item级别。

这些数据将以以下两种方式使用：

1. 添加<Number,Map<Number,Number>>条目

- Relatively infrequent

​

1. 原子地，在数据库中，给出一个Item id和一个度量id列表的~15度量的批处理增量 然后，得到Item的米制地图。

- Very frequent

​

内部Map应该能够增长，但不会超过200个条目。

就是这样。

你认为Berkeley DB适合这个应用吗？

更新：

显然，我的数据模式不够清晰，所以我将进一步分解它。

Item__，有许多度量标准，每个指标都有一个计数器，即一对一(多对一)即<Number,Map<Number,Number>>。

但是我有很多Item_s，所以我需要一个Map<Number,Map<Number,Number>>

Answer 1

我认为伯克利DB将是一个不错的选择，并对您选择如何布局数据提出一些警告。但是，您可能也想考虑其他键值存储 -例如，LMDB应该比BDB更容易使用。

乍一看，系统中的一个记录(“key/value”中的“值”)可能是您的内部Map<Number, Number>。queue访问方法(或btree，FWIW)提供外部Map<Number, Record>。

Berkeley DB没有为访问记录中的内容提供太多(实际上是任何)帮助。因此，您仍然必须以允许随机访问和修改其内容的方式表示您的内部地图。根据Map<Number, Number>中第一个数字的大小，您可以执行一个简单的C样式数组。您可以使用一个JSON对象，或者一个protobuf，或者，任何你能想到的东西。

这种布局只有在外部Map>中有许多条目时才有意义，而与您提到的200多个条目相比，内部地图的大小是合理的。记录级别锁定适用于整个内部Map，因为这是您的记录。

另一种技术是从模式中的前两个Number中创建一个复合键。也就是说，Map<NumberX, Map<NumberY, NumberZ>成为一个具有键NumberX_NumberY和值NumberZ的数据库。这将使您可以快速随机访问内部地图中的任何特定条目，但您必须使用游标来检索整个内部映射中的所有条目。