mspain, вот некоторые мысли:
- не рассматривали возможность разделения возможностей хранения и поиска по разным БД? Очевидно, что накладные расходы по поддержанию работы двух БД приведут к понижению производительности. Но это в случае синхронной работы. Если характер нагрузки на БД хранения не равномерна, то выставив приоритетность (не только CPU, но и RAM, ...) на хранение, добьемся высокой производительности сохранения записей. Менее приоритетная индексация будет совершаться при снижении нагрузки на основное хранилище. Из плюсов: высокая скорость загрузки, использование специализированного БД для поиска с его плюсами. Из минусов: отложенная индексация из за сравнительно низкой производительности индексации, система распределения нагрузки в ОС или отдельная всегда имеет некоторую интерность в жизни -> будет не так идеально как я описал, но приближенно
- Индексация по расписанию. Если в работе допустимо отставание индексов поиска, то во время пониженной нагрузки (ночью, ранее утро, выходные, ...) производить индексацию в единственном БД или в БД для поиска.
- 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.
Сложный
