持久化HashMap最有效的方法是什么？
我有一个哈希映射（文本和布尔值之间的多对一关系）：
name flag
---------------------
"abc" TRUE
"cde 12" TRUE
"foo" FALSE
"some text" TRUE
etc...
我需要在 Java 应用程序中保留此结构。这个结构将会被扩展，但不会改变。这意味着我将向其中添加新记录，但永远不会删除或更改现有记录。极其重要的是搜索速度（我提供名称，它返回标志）。它的大小可能非常大（数百万条记录）。我考虑了多种选择：1) 具有一个表和一个索引的关系数据库，2) 平面文件，3) 纯 JVM 数据库..您有什么建议？
I have a Hash Map (many-to-one relationship between texts and boolean values):
name flag
---------------------
"abc" TRUE
"cde 12" TRUE
"foo" FALSE
"some text" TRUE
etc...
I need to persist this structure in Java application. This structure will be extended, but never changed. It means that I will add new records to it but never delete nor change existing ones. What is extremely important is the speed of search (I provide a name and it returns the flag). It may be really big in size (millions of records). There are a number of options I consider: 1) relational database with one table and one index, 2) flat file(s), 3) pure JVM database.. What would you suggest?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我推荐 JDBM3 库，它提供了磁盘支持的 HashMap 和 TreeMap 实现。它快速、可扩展且易于使用。阿帕奇 2 许可证。
摘自网站：
JDBM性能突出；它每秒可以插入一百万条记录，并且读取速度更快I'd recommend JDBM3 library which provides a disk backed HashMap and TreeMap implementations. Its fast, scalable and easy to use. Apache 2 license.
From the site:
JDBM has outstanding performance; it can insert a million records per second and read them even faster考虑到记录的数量，我将使用以名称为键的关系数据库。
但如果没有找到名字，这意味着什么呢？
如果未找到相当于您的布尔值之一（例如 TRUE），则您有一个白名单（或黑名单，具体取决于上下文），在这种情况下，我倾向于从数据库中删除标志列并将名称缓存在哈希集中。
如果未找到是一个单独的值，那么如果您有足够的可用内存，您可以尝试在哈希映射中缓存整个表。
Given then number of records I would go with a relational db keyed on the name.
But what should it mean if a name is not found?
If not found is equivalent to one of your boolean values (say TRUE) then you have a whitelist (or blacklist depending on context) in which case I would be inclined to drop the flag column from the database and cache the names in a hash set.
If not found is a separate value then if you have sufficient available memory you might try caching the whole table in a hash map.
几百万？我们有一个包含 500 万条记录的数组的案例，我们将它们全部吸收到内存中，以便使用二分搜索快速获得结果，这是带有经度、纬度数据的 geoloc 数据，如果您有很多地址，则 DB 搜索将花费相当长的时间来查找。
如果您有大量内存，请使用内存数组，如果没有的话，请使用小型数据库 sqlite 或 mysql。
sqlite 也可以处理大量数据，并且如果没有很多线程客户端来更新您的结构，则不需要额外的服务器。
关于 sqlite 的限制 -
SQLite 可以处理 9000 万条记录吗？
How many millions? We had a case with an array of 5mil records and we had 'em all in memory sucked up to get fast results using binary search it was the geoloc data with longitutes, latitiudes data and the DB search was taking quite awhile if you had many addresses to lookup.
If you have lots of memory use in-memory array if not - use a small DB either sqlite or mysql.
sqlite can handle large amounts of data too and doesn't require an extra server if there not many threads clients which will update your structure.
about sqlite's limits -
Can SQLite handle 90 million records?