предложение хранилища ключей

Question

Мне нужно очень простое хранилище значений ключей для Java. Я начал с HashMap, но кажется, что HashMap несколько неэффективен в пространстве (я храню ~ 20 миллионов записей и, похоже, требует ~ 6 ГБ ОЗУ).

Карта - Map<Integer,String>, и поэтому я рассматриваю возможность использования GNU Trove TIntObjectHashMap<byte[]> и сохранения значения карты в виде байтового массива ascii, а не String.

В качестве альтернативы этому есть хранилище значений ключей, которое требует только добавления файлов JAR, не хранит всю карту в ОЗУ сразу и все еще достаточно быстро?

Answer 1

BabuDB

BabuDB - это встроенная нереляционная система баз данных.Его простой и простой дизайн позволяет ему постоянно хранить большое количество пар ключ-значение без дополнительных затрат и сложности подобных подходов, таких как BerkeleyDB.

Лицензия: Новая лицензия BSD, Язык: Java

JDBM2

JDBM2 предоставляет HashMap и TreeMap, которые поддерживаются дисковым хранилищем.

Лицензия: Лицензия Apache2.0, язык: Java

Banana DB

Banana DB - это автономная база данных пары ключ / значение, реализованная в Java.

Лицензия: Apache License 2.0, Язык: Java

---

Я пробовал BabuDB и JDBM2, и они отлично работают.BabuDB немного сложнее в настройке, но потенциально обеспечивает более высокую производительность, чем JDBM2.

Все эти базы данных позволяют сохранять данные на диске.Существуют также решения для хранения большой карты в памяти ( ehcache , hazelcast , ...).

Answer 2

Использование Berkeley DB .

Berkeley DB хранит графы объектов, объекты в коллекциях или данные простого двоичного ключа / значения непосредственно в btree на диске . Этот простой, высокоэффективный подход устраняет все ненужные издержки в решениях ORM. Используя Java-разработчики Direct Persistence Layer (DPL), аннотируют классы информацией о хранении, так же как и JPA. Этот подход знаком, эффективен и быстр. DPL снижает сложность хранения данных, не жертвуя скоростью.

Это определенно должно дать вам огромный прирост памяти и скорости, не увеличивая при этом сложности вашего приложения. Наслаждайтесь!

Answer 3

http://www.mapdb.org/ - это то, что вы ищете. Это потрясающе быстрая и постоянная реализация java.util.Map.

Особенности

Параллельное

MapDB имеет рекордный уровень блокировки и современный параллельный движок. Его производительность масштабируется почти линейно с количеством ядер. Данные могут быть записаны несколькими параллельными потоками.

Быстрая

MapDB обладает выдающейся производительностью, с которой могут соперничать только собственные базы данных. Это результат более чем десятилетней оптимизации и переписывания.

ACID

MapDB дополнительно поддерживает транзакции ACID с полной изоляцией MVCC. MapDB использует запись с опережением записи или хранилище только для добавления для большей надежности записи.

Гибкое

MapDB может использоваться везде: от кеша в памяти до многотерабайтной базы данных. У этого также есть много вариантов обменять длительность на производительность записи. Это позволяет очень легко настроить MapDB в соответствии с вашими потребностями.

* 1023 взломать * MapDB основана на компонентах, большинство функций (кэш экземпляра, асинхронная запись, сжатие) являются просто обертками классов. В MapDB очень легко внедрить новую функциональность или компонент. SQL, как

MapDB был разработан как более быстрая альтернатива движку SQL. Он имеет ряд функций, облегчающих переход от реляционной базы данных: вторичные индексы / коллекции, последовательный идентификатор с автоинкрементами, объединения, триггеры, составные ключи…

Низкое использование дискового пространства

MapDB имеет ряд функций (сериализация, упаковка дельта-ключей…) для минимизации использования диска его хранилищем. Он также имеет очень быстрое сжатие и пользовательские сериализаторы. Мы серьезно относимся к использованию дисков и не теряем ни одного байта.

Answer 4

Просто хотел бы сослаться на некоторые дополнительные опции с открытым исходным кодом, которые стали доступны со времени, когда этот вопрос был впервые задан.

Apache 2, BTree, попытка замены JDBM проекта каталогов Apache:

http://directory.apache.org/mavibot/

MPL2 / EPL1, RTree, MVStore, модуль хранения H2:

http://www.h2database.com/html/mvstore.html

Apache 2, среды Xodus, JetBrains YouTrack и механизм хранения Hub:

https://github.com/JetBrains/xodus

Answer 5

Рассмотрим Коллекции Колобоке , что в 2 раза быстрее, чем Trove, согласно различным тестам:

• Время - обмен памяти на примере Java Maps
• Большой обзор HashMap: JDK, FastUtil, Goldman Sachs, HPPC, Koloboke, Trove

, если настроено использовать ту же память, что и Trove. Или же вы можете подумать, что он потребляет значительно меньше памяти, если настроен так же быстро, чтобы Trove.

---

Если вы хотите сохранить карту между запусками JVM с очень быстрой начальной загрузкой, вас также может заинтересовать Chronicle-Map , которая по умолчанию хранит String s в UTF-8 (так что вам не следует t преобразования с String <-> byte[], как с Koloboke / Trove). Chronicle-Map является сверхбыстрой для постоянного хранения значений ключей, но немного медленнее, чем Koloboke и даже Trove.

Answer 6

Карта - это Map, и поэтому я рассматриваю возможность использования GNU Trove TIntObjectHashMap и сохранения значения карты в виде байтового массива ascii вместо String.

Это не совсемимеет смысл, потому что TIntObjectHashMap не Map.Тем не менее, подход является разумным.

---

Знаете ли вы, какую экономию пространства я могу ожидать по сравнению с HashMap для Trove?

Лучший ответ - попробоватьэто из.

Но вот некоторые приблизительные оценки (в предположении 32-битной JVM):

• Ключи HashMap должны быть экземплярами Integer.Они будут занимать ~ 18 байт на экземпляр + 4 байта на ссылку.Всего 24 байта.

• Ключи Trove будут иметь 4 байта int значения.

• Строковые значения будут 20 байтов + 12 байтов + 2* количество "символов".

• Значения байтового массива будут 12 байтов + 1 * количество "символов".

• У меня нет 't проверил детали соответствующих структур данных внутренней хеш-таблицы.

Это, вероятно, составляет около 50% экономии памяти, хотя это критически зависит от средней длины значения "строк".(Чем дольше они, тем больше они будут доминировать в использовании пространства.)

FWIW, Trove публикует свои собственные тесты здесь .Они выглядят не очень убедительно, но вы должны быть в состоянии выкопать их тестовый код и изменить его, чтобы лучше соответствовать вашему варианту использования.