什么时候BIG，足够大的数据库？

Question

我正在开发一个以性能为核心的Java应用程序。 我有一个大约40,000个“最终”对象的列表， 即，我有40,000个向量的初始化输入数据。 整个项目的运行过程中，这些数据没有变化。

我总是针对单个ID属性执行查找以检索正确的向量。 目前我在1,000个向量的子样本上使用HashMap， 但 我不确定它会扩展到生产。

什么时候BIG，实际上足够大，可以使用DB？ 还有一件事，SQLite DB是一个可行的选择，因为不涉及并发， 所以我猜数据库使用的“门槛”可能更低。

Answer 1

我想你在询问是否有40,000个条目的HashMap是可以的。答案是肯定的 - 除非你真的没有足够的记忆，否则这应该是绝对正确的。如果您正在编写性能敏感的应用程序，那么在运行应用程序的计算机中放入大量快速内存可能是提高性能的有效方法。

每个HashMap条目的开销不会很大，所以如果你有足够的空间将对象本身存储在内存中，那么地图的开销不太可能导致问题。 / p>

你有什么理由不能用合理数量的数据来测试它吗？

如果你的要求不是：

• 在启动时读取数据
• 通过单个ID将数据放入地图中（不需要连接，针对不同字段的查询，子字符串匹配等）
• 从地图中获取数据

...然后使用一个完整的数据库将是一个巨大的过度杀伤，IMO。

Answer 2

只要您在程序开头将数据集加载到内存中并将其保留在内存中并且您没有任何复杂查询，某种序列化/反序列化似乎比完整的数据库。

Answer 3

您可以启动一个只有100（或更少）的数据库。当数据量足够大以存储在数据库中时，没有一般规则。如果你认为你应该更好地将这些数据存储在数据库中，那就更好了，如果这会给你带来任何利润（性能提升，编程更容易，用户选择更灵活）。

当收益大于实施成本时，将其放入数据库中。

Answer 4

Collection与数据库没有设置大小。它取决于您想要对数据做什么。尺寸不太重要。

您可以拥有包含十亿条目的地图。

Answer 5

没有“足够大的数据库”这样的东西。问题是使用数据库是否有足够的优势来克服成本。

话虽如此，40,000不是'大';-)除非对象很大或你有复杂的查询要求，我会从内存实现开始。但是，如果您希望随着时间的推移扩大这个数字，那么从一开始就使用数据库可能会更好。

Answer 6

您可能需要考虑的一个选项是Oracle Berkeley DB Java版库。它是一个简单的JAR文件，可以读取/写入持久存储的数据。由于它占地面积小，易于使用，因此可用于在小型到大型数据集上运行的应用程序。它被设计为链接到应用程序，因此它是嵌入式的，不需要复杂的客户端/服务器安装或协议栈。

更好的是它具有极高的可扩展性（如果最终的数据集超出预期，效果很好），速度非常快，同时支持Java Collections API和直接持久层API（类似POJO） 。因此，您可以将它与Java Collections无缝地结合使用。

Berkeley DB Java Edition专为Java应用程序开发人员而设计。它的设计易于使用，在所需资源方面重量轻，但速度快，可扩展且可靠。

您可以找到有关Oracle Berkeley DB Java版here

的更多信息

问候，

戴夫