11

我目前正在开发一个基于 Android 的项目。在不涉及许多细节的情况下，该软件将在定制的设备上运行。硬件永远不会改变，永远都是一样的。这是一个明确的优势:)

话虽如此，该项目要求我们在设备上存储负载和数据负载 - 在某些表中超过 3m 行。SQLite 对我们来说很好地处理了这么多行的扫描，当我们开始进行复杂的连接以带回我们需要的所有相关数据时，问题就出现了。我们已经考虑过对数据库进行非规范化，但担心这会将数据库推到可用范围之外。

我们正在研究使用面向对象的数据库，例如 db4o 或 NeoDatis。我们希望通过存储对象，我们可以摆脱行级别的关系并将它们存储在对象上（就像 OOP 一样）。问题是我们无法找到这些 ODB 在 Android 上运行和使用的任何与性能相关的基准（至少不是最近的）。

是否有人对 Android 上的 OODB 和/或存储和访问大量数据有任何经验？如果是这样，您可以提供的任何建议将不胜感激。

- 编辑

这是我们面临的问题的一个例子。它与我们的应用程序无关（我的保密协议说我不能发布任何具体内容），但这个例子很好地代表了这个问题。

想象一下，我们正在构建一个应用程序来监控在任何给定时间在新泽西收费公路上行驶的每一辆车。对于任何给定的汽车，我们需要跟踪汽车的品牌和型号、车内有多少人以及车内人员的人口统计数据。所以基本上你最终得到的数据看起来像 -

车

编号 | 颜色 | make_id | in_toll_lane | model_id

制作

编号 | 姓名

模型

编号 | 姓名 | make_id

car_person

编号 | 年龄 | 性别 | is_driver | car_id

收费车道

编号 | car_in_line | 理想的汽车线 | 理想的住户

这些数据会经常变化。它也将变得相当庞大，因为毫无疑问，在任何特定时间都有很多人沿着 NJ Pike 行驶。

有了这些数据，我们需要能够根据需要对任何在长矛上行驶的人进行快照。我们还需要能够拍摄所有正在开车的男性或收费公路上的所有女性的快照。我们还需要能够按年龄、性别、品牌、型号等进行搜索。

现在想象一下，我们需要根据车内人数、理想乘员人数、已经排队的汽车数量以及应该排队的理想汽车数量来确定每辆车应该进入哪个收费车道.

这是一个非常简单的例子，虽然很能代表我们的问题。

-- 结束编辑

提前致谢！

4

4 回答 4

3

您并没有真正谈论您的数据访问需求或数据加载。

如果您有 3M 主行，然后是一堆较小的叶表，那么您可以通过将所有叶表缓存在 RAM 中并手动“加入”它们来做得很好。许多系统都有非常小的叶表（特别是与主数据相比），因此将它们加载到 RAM 中，然后在加载行时简单地查找它们可能是一个巨大的胜利。

显然，您不会对主要的父->子关系执行此操作，但是如果您可以消除叶连接，那么读取将成为父子和子表之间的单个连接，而不是父表、子表和叶表的半打.

即使这不适用于所有的叶表，如果它适用于绝大多数，它可能足以让你克服困难。

于 2010-12-01T02:07:28.680 回答
3

这里有一些观察，但我怀疑它不会直接帮助你。

我认为主要问题是：当事件生成或更改数据时，您是要通过应用程序运行时逻辑发现复杂的关系，还是必须将数据转储到存储中，然后通过查询发现未预料到的关系？

如果您的业务逻辑将填充模型，那么您可以轻松地为数据模型的不同切片创建基于模型的视图，例如了解所有具有男性/女性驾驶员的汽车的集合。在这种情况下，基本上，您的关系是半静态的，很少变化（而这些关系另一端的数据值可能变化很大）。如果是这种情况，那么为什么要尝试将数据存储在数据库技术中，这会迫使您不断地重新计算关系（JOIN）。这只是对 CPU 的浪费，这就是为什么随着模型变得复杂，您会看到性能不佳的原因。因此，一旦您回答了这些问题，就很清楚 ODB 还是 RDB 是最佳选择。

现在问题变成了，什么将在 Android 上运行并处理大量数据？这是我认为我无能为力的地方。我在拥有（db4o 和 Versant）ODB 的 Versant 工作。现在 db4o 将在 Android 上运行，但它确实是处理海量数据的正确选择……不。除非您有非常孤立的数据，这些数据可以位于单独的数据库中并且只能单独访问，而且在我看来这听起来不像是您的情况。我们的另一个数据库 Versant 不打算近乎实时地处理大量数据，但只有客户端是 100% Java，服务器是用 C 编写的，所以它不会在 Android 上运行。

我认为你需要做一些研究，看看谁拥有可以在 Android 上处理大量数据的 ODB。

最好的，-罗伯特

于 2010-12-01T16:57:25.940 回答
3

代表 db4o：我们在 Android 上运行所有回归测试，因为我们认为它将成为 db4o 的一个非常重要的平台。

db4o 对 300 万个数量级的对象非常有效。

我们正在对http://www.polepos.org/上的其他数据库进行基准测试，我们将很快发布新版本的基准测试，我们将在其中运行复杂的设置，也针对 SqlLite。将基准测试移植到 Android 也是一个考虑因素。

如果连接正在扼杀您的性能并且您拥有非常异构的数据，那么 db4o 可能比关系数据库工作得更好。

你的应用听起来很有趣。如果您在评估 db4o 时需要帮助，请告诉我一声。

于 2010-12-01T19:00:55.617 回答
2

Jason：要联系任何 db4o 成员，您必须使用以下模式：firstname@db4o.com 最好！

于 2010-12-02T00:33:30.360 回答