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

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

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

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

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

Lucene тоже.

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

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

Данные не key value, а четыре отдельные строки, по каждой нужен четкий поиск.
  • Вопрос задан
  • 777 просмотров
Решения вопроса 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.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
FunBox Ульяновск
от 120 000 руб.
FunBox Москва
от 120 000 руб.
MFMS Москва
от 150 000 до 250 000 руб.