Хранение большого количества небольших записей для поиска с задержкой менее миллисекунды
У меня есть вариант использования, когда мне нужно получить документ (~ 1,5 КБ) из некоторого хранилища с задержкой <1 мс, если это возможно. В хранилище будет не менее 2-3 миллионов таких документов.
Образец документа
{"name": "NameOfTheItem", "city": "Seattle", "state": "WA", "postCode": "99332", "country": "USA"}
Шаблон доступа
- Все мои поиски будут основываться строго на поле
name. - Мне не нужна высокопроизводительная запись
Вопросы
- Имеет ли смысл документ такого размера сжимать документ перед сохранением и распаковывать его при извлечении?
- Имеет ли значение формат данных (YAML, JSON, PARQUET и т. д.) для документа такого размера? если да, есть ли у вас какие-либо ссылки, которые могут помочь мне определить правильный формат?
- Какие у меня есть варианты для магазина, которые помогут мне получить субмиссию?
Ответы 1
Для очень быстрого доступа вы хотите хранить данные в памяти и в структуре данных, подобной HashMap, для сложности чтения O (1). Я просто подсчитал, что в сумме речь идет о 4-5 Гб документов. Некоторые считают, что разумная установка должна быть в состоянии удерживать память.
Не думайте о сжатии. Он оптимизируется только по размеру хранилища, но по стоимости времени доступа для распаковки. И, как видно из расчета (количество документов x средний размер), не должно быть проблем с хранением всего в памяти без сжатия.
Я ожидаю, что вам также понадобится постоянство, поэтому вы должны хранить свои данные также на диске (например, в базе данных) и в кеше памяти.
Чрезмерно широкий и, вероятно, основанный на мнении. Если вы напишете какой-нибудь код, протестируете его, а затем попросите улучшения на основе тестовых (временных) данных, вы будете в гораздо лучшей форме. Я думаю, что для сжатия больших данных может быть важно, и я бы использовал хэш-карту для хранения каждой строки. Два-три миллиона объектов на самом деле не так уж и много.