Какая NOSQL СУБД максимально быстрая с вертикальным масштабированием для многотерабайтной базы?

Здравствуйте!

Как известно подавляющее большинство NOSQL СУБД предполагают горизонтальное масштабирование - увелечением количества узлов.

Прошу посоветовать СУБД в которую можно на одном сервере быстро загрузить несколько терабайт данных/десятки миллиардов записей, СХД не быстрое, обычные диски в RAID10. ОЗУ 64ГБ. Ядер 12. Хотелось бы получить скорость хотя бы 100к вставок в секунду на всём диапазоне.

ElasticSearch очень медленный, даже в начале нет 100к.

Lucene тоже.

Есть опыт работы с Монго, но что-то медленно у неё получается. Начинает бодро - с 100к/сек, но уже на 300млн записей скорость быстро снижается до 10к и ниже.

Пробовал индексы не создавать - скорость загрузки отличная, 120-200к на всём диапазоне. Но создание индекса на 2ТБ базе с 10млрд документов просто бесконечно медленное.

Данные не key value, а четыре отдельные строки, по каждой нужен четкий поиск.
  • Вопрос задан
  • 863 просмотра
Решения вопроса 1
mspain, вот некоторые мысли:
  1. не рассматривали возможность разделения возможностей хранения и поиска по разным БД? Очевидно, что накладные расходы по поддержанию работы двух БД приведут к понижению производительности. Но это в случае синхронной работы. Если характер нагрузки на БД хранения не равномерна, то выставив приоритетность (не только CPU, но и RAM, ...) на хранение, добьемся высокой производительности сохранения записей. Менее приоритетная индексация будет совершаться при снижении нагрузки на основное хранилище. Из плюсов: высокая скорость загрузки, использование специализированного БД для поиска с его плюсами. Из минусов: отложенная индексация из за сравнительно низкой производительности индексации, система распределения нагрузки в ОС или отдельная всегда имеет некоторую интерность в жизни -> будет не так идеально как я описал, но приближенно
  2. Индексация по расписанию. Если в работе допустимо отставание индексов поиска, то во время пониженной нагрузки (ночью, ранее утро, выходные, ...) производить индексацию в единственном БД или в БД для поиска.
  3. Eventual consistency. Если людские ресурсы и компетенция позволяет, то можно собрать конвеер по сглаживанию нагрузки на основе системы очередей. Использование очереди в памяти, и запись в БД в воркерах. По настоящему отличной производительности можно добиться, если добавить логику по выставлению приоритетов запросам, использования паковки схожих запросов, а так же предварительной обработки запросов бизнес логикой. Не подойдет, если характер загрузки данных это пакетный импорт (batch import) огромных данных, а при неравномерной нагрузке будет отлично работать. Минусы, конечно есть: это очередь в памяти и его надежность. Т.е. durability.

Первое решение может быть и не рабочим, покажет только профилирование. Второе однозначно рабочее, но может не подойти, а третье подойдет при некоторых условиях и при наличии компетентности.

--------- UPDATE ---------------
Почитал комментарии и Ваши ответы.
4 связанные строки. Поиск по любой из четырёх должен возвращать остальные три. В Монге это выглядит как

"k" : [ "string1", "string2", "string3" ], "v" : "string4",

Может и key-value СУБД так умеют?

1. Это выглядит странно. Вы на каждую строку ведете 16 вариантов записи в Mongo?
Если да, то не нужно этого делать. В Mongo есть мульти индексы. Т.е. можно так:
> db.col1.save({'data': ['string1','string2','string3','string4']})
> db.col1.ensureIndex({'colors':1})
> db.col1.find({'data': {$in: 'string3'}})
{ "_id" : ObjectId("63cc78f97cf77dc2a2e54e18"), "data" : ["string1", "string2", "string3", "string4"] }
Это по поводу формата данных.
2. Будет хорошее улучшение в способе загрузки:
https://www.khalidalnajjar.com/insert-200-million-...
Почитал комментарии и Ваши ответы.
4 связанные строки. Поиск по любой из четырёх должен возвращать остальные три. В Монге это выглядит как

"k" : [ "string1", "string2", "string3" ], "v" : "string4",

Может и key-value СУБД так умеют?

1. Это выглядит странно. Вы на каждую строку ведете 16 вариантов записи в Mongo?
Если да, то не нужно этого делать. В Mongo есть мульти индексы. Т.е. можно так:
> db.col1.save({'data': ['string1','string2','string3','string4']})
> db.col1.ensureIndex({'colors':1})
> db.col1.find({'data': {$in: 'string3'}})
{ "_id" : ObjectId("63cc78f97cf77dc2a2e54e18"), "data" : ["string1", "string2", "string3", "string4"] }
Это по поводу формата данных
2. Будет хорошее улучшение в способе загрузки:
https://www.khalidalnajjar.com/insert-200-million-...
Предлагаю Вам, считывать Ваш файл и в Unix pipe форматировать в CSV или TSV далее в mongoimport.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы