Привет,

я здесь как-то поднимал тему

Автор: pva
Дата: 05.06.19

по выбору движка для временных рядов с прорехами, но ни к чему не пришли по итогу и приходится продолжать есть кактус.
Возникшие проблемы с MongoDB и может кто подскажет как их решить.
Предпосылки:
одна БД в которой много коллекций "время=значение" (размер записи порядка 64 байт);
типовые сценарии:
— выборка небольшого объема по [startTime; endTime)
— выборка по всем данным

Задачи:
с ростом нагрузки (объема данных) обеспечить горизонтальное масштабирование;
по возможности, уплотнить хранение данных с минимизацией потери в скорости вставки/выборки.

Проблемы:
Сделал шард-кластер. Ключем является время : hashed. Все хорошо ровно до старта балансера.
Балансер отжирает 100% ЦПУ на шарде, с которого происходит миграция.
При этом он обрабатывает порядка 1.5к документов в секунду что для чанков в сотни тысяч и миллионов в коллекции — пустое место.
На этом этапе начинают расти входные очереди и вся система просто ложится.

Вопрос 1: если у нас hashed ключ шардинга предполагаю что должно быть равномерное распределение по шардам без всякой ребалансировки.
Допустимо ли работать с монго с полностью отключенным балансером? Или он сначала пишет все данные на один шард, а потом ребалансирует?

Вопрос 2: в реплика сете запись идет сначала на мастер и затем копируется на реплики. Это происходит при "ребалансировке" реплики или там "сквозная" запись на все доступные узлы множества с отложенной синхронизацией?
У меня сейчас в каждой шард реплике по одному серверу. Хотелось бы понять не ляжет ли мастер при добавлении серверов в реплику. А также будет ли балансировка происходить с реплик или все так же грузить мастер?

Вопрос 3: недорогие "живые" альтернативы монго, умеющие масштабироваться вширь. Меня устроило бы даже масштабирование на уровне коллекции.
При этом поддерживающие SSL/TLS и желательно "encryption in rest".