Использование ChronicleMap в качестве базы данных "ключ-значение"

Я хочу использовать ChronicleMap в качестве памяти база данных с сопоставлением пар "ключ-значение" (от String до byte[]). Он должен быть в состоянии вместить порядка 100 миллионов записей. Чтение/получение будет происходить гораздо чаще, чем запись/вставка, с ожидаемой скоростью записи менее 10 записей в секунду. Хотя ключи будут одинаковой длины, длина значения может сильно различаться: от нескольких байтов до десятков мегабайт. Тем не менее, большинство значений будут иметь длину от 500 до 1000 байт.

Прочитав немного о ChronicleMap, я поражен его возможностями и задаюсь вопросом, почему я не могу найти статьи, описывающие его использование в качестве общей базы данных "ключ-значение". Мне кажется, что у использования ChronicleMap для этой цели есть много преимуществ. Что мне здесь не хватает?

Каковы недостатки использования ChronicleMap для заданных граничных условий?


chronicle chronicle-map
person xpages-noob    schedule 02.01.2018    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я проголосовал за закрытие этого вопроса, потому что любые «недостатки» будут относительными.

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

Ограничение текущей реализации заключается в том, что вам необходимо заранее указать количество элементов, которые будут храниться на карте, и если фактическое количество не близко к указанному, вы будете чрезмерно использовать память и диск ( не очень серьезно, хотя в системах Linux), но если фактическое количество записей превышает указанное число примерно на 20% или более, производительность операции начинает ухудшаться, и падение производительности линейно растет с дальнейшим увеличением количества записей. См. https://github.com/OpenHFT/Chronicle-Map/issues/105

person leventov    schedule 02.01.2018
comment
Спасибо за Ваш ответ. (1) Карта просто необходима для получения значения по ключу. Я не буду перебирать его, и мне не нужно его сортировать. (2) Я думал, что в Linux с файловой системой ext4 вы теоретически можете предоставить любой размер до доступного дискового пространства для отображаемого в память файла. Первоначально этот файл будет небольшим и будет увеличиваться по мере заполнения данными. Я планировал инициализировать карту большим количеством записей (500 м) и установить средний размер ValueSize таким образом, чтобы рассчитанный максимальный размер файла не превышал места на диске. Пожалуйста, поправьте меня, если это не так. - person xpages-noob; 02.01.2018
comment
Потери возникают из-за внутренней фрагментации (в область поиска хэшей), а не внешнюю фрагментацию, поэтому она неизбежна даже в Linux и с любой используемой файловой системой. - person leventov; 02.01.2018
comment
С вашей дисперсией размера значения я рекомендую указать actualChunkSize напрямую вместе с другими низкоуровневыми конфигурациями, т.е. е. actualChunksPerSegmentTier, actualSegment и entriesPerSegment. - person leventov; 02.01.2018
comment
Спасибо за такую ​​полезную информацию и совет. Если я знаю, что 95% всех записей будут иметь длину ‹1500 байт, а остальные 5%, вероятно, будут намного длиннее (байтовые массивы файловых данных), не лучше ли мне разделить мои данные на 2 карты с разными фрагментами? размеры, например 256б для первого случая и 4096б для второго? Или падение производительности из-за слишком большого количества фрагментов (javadoc: особенно избегайте записей, занимающих более 64 фрагментов.) незначительно, если эти записи не читаются часто? - person xpages-noob; 02.01.2018
comment
@xpages-noob Это зависит от того, что вы подразумеваете под намного длиннее. Если вы имеете в виду в 10 раз больше, это должно быть проблемой, если вы имеете в виду в 1000 раз больше, используйте другую карту. - person Peter Lawrey; 02.01.2018
comment
@xpages-noob номер 64 происходит из-за того, что мы используем набор битов для распределения пространства, и он переключается на немного более медленный алгоритм, потому что › 64 бита не соответствуют примитивному длинному значению, но не так уж ужасно. Если вам нужны записи из 100 или 1000 чанков, на самом деле с картой хроник это не имеет большого значения, правильно настроенное количество чанков на уровень / количество записей должно справиться с этим. Я бы рекомендовал указать меньше сегментов (или только 1), если вам не нужен высокий параллелизм обновлений. - person leventov; 02.01.2018
comment
Спасибо за пояснения и рекомендации. Из-за моего ограниченного опыта работы с ChronicleMap (‹24h) я в настоящее время имею лишь смутное представление о том, как все упомянутые низкоуровневые параметры конфигурации влияют на производительность на практике. Тем не менее, я рад, что существует так много вариантов настройки, и я уверен, что найду правильную конфигурацию для своих потребностей в хранении. В очередной раз благодарим за помощь. - person xpages-noob; 02.01.2018
comment
PS: я обычно жду не менее 1 дня, прежде чем принять ответ. На всякий случай, если кому-то еще есть что сказать :) - person xpages-noob; 02.01.2018
comment
@leventov Еще один вопрос: будет ли функция, которую вы указали в своем ответе (ограничение «Удалить записи ()»), будет реализована в ближайшем будущем? - person xpages-noob; 03.01.2018
comment
это маловероятно - person leventov; 03.01.2018