Вообще задача - периодически снимать с внешней базы данные и переносить в локальную с удалением из внешней базы. Пишу свой скрипт потому что mongodump не подходит - не может мержить коллекции на сколько я понял. Если есть решение лучше и стандартными инструментами буду рад узнать об этом.

Берем временную метку начала синхронизации. Вытаскиваем все документы. Добавляем временную метку ко всем документам в виде индексируемого поля _v и записываем в монгу. По завершению синхронизации записываем временную метку в отдельный документ в отдельной коллекции. Дальше когда мы делаем запрос в каталог, мы читаем самую последнюю метку из коллекции меток и добавляем ее ко всем запросам.

Читайте это тред

Мержить очень дорого. Если во внешнем источнике полный набор даных, то вставка с версионированим — самый дешевый вариант.

Логика такая: База А База Б Имееют одинаковый набор данных кроме одной коллекции. Эту коллекцию нужно перенести с А на Б с удалением с А. Делать это периодически. Правильно ли я понял что нужно: 1. В начале переноса обновить все документы проставив им, условно говоря поле sync: true 2. Перенести все документы на Б 3. Удалить все документы с установленным полем sync: true В это время будут добавлятся документы без поля и они не будут удалены. Так?

Нет, sync плохая идея. Потому что потом этом его ещё раз придётся обновлять.

Любое поле которое может выступать как версия. Либо в документе, либо префиксом в _id

Но зачем удалять и переносить?

Мне нужно как-то идентифицировать документ для удаления. Проблема в том что _id меняется почему-то

Места мало

Деваться не куда надо удалять и переносить =)

Шардируйте

Выделите новое блочное устройство

Это все понятно, пока что таким путем не получится пойти. Надо костылить.

И потом смотрите в system.profile

спасибо! попробую это тоже

Это все понятно, пока что таким путем не получится пойти. Надо костылить.

Не получится по какой причине?

Заказчик не выделит дополнительные деньги на данный момент, а может и никогда.

Но при этом он выделяет денег на ваше время?

Ваше время дешевле чем хранилище?

Да выделяет. Предлагаю сконцентрируемся на проблеме. На сколько я понял на данный момент: 1. Решения стандартными средставами нет и нужно писать скрипт 2. Документы прилетают с изменившимеся ID и на них плагаться нельзя Может выгребать тупо по created за какой-то период и все?

не могу догнать, ну вы же куда их копируете, значит там место есть, так чего бы не использовать?

Да в том то и дело что тупость все это на данный момент. Но надо вот такой вариант сделать и если сервис вырастет то там будет уже другое железо и наверняка найдут спеца по монге чтобы он ей рулил. Выгружать на локальный комп надо там более или менее нормально с железом и копиться данные могут какое-то разумное время.

Короче делаю пока вариант с {sync: true} если есть идеи лучше для бомжей - велкам.

данных сколько в штуках и собственно объеме?

каков прирост, какая дельта по размеру должна вычищаться?

Да делайте дампы и все. Зачем их разворачивать?

Данные вам явно не нужны

Да выделяет. Предлагаю сконцентрируемся на проблеме. На сколько я понял на данный момент: 1. Решения стандартными средставами нет и нужно писать скрипт 2. Документы прилетают с изменившимеся ID и на них плагаться нельзя Может выгребать тупо по created за какой-то период и все?

Так купить ещё места будет скорее всего дешевле чем вас платить. Плюс попробуйте включить zlib компрессию на макаималках

Если вы старые данные удаляете, а они повторно создаются, то айдищники конечно будут новыми.

Сделать надежную считалку дельт, это месяцок работы

за месяцок работы простого прогера можно смело десяток тб докупить, хот ьи медленных

Если вы старые данные удаляете, а они повторно создаются, то айдищники конечно будут новыми.

1. запрашиваю документ из базы 2. смотрю _id этого документа в данных программы во время выполнения 3. смотрю _id этого документа в базе источнике они разные.

1. запрашиваю документ из базы 2. смотрю _id этого документа в данных программы во время выполнения 3. смотрю _id этого документа в базе источнике они разные.

Да

Вы из оригинальной базы уделяете документы же

каков прирост, какая дельта по размеру должна вычищаться?

где-то 100 - 150 мб в сутки, это около 40 000 документов в моем случае дельта - весь объем коллекции.

Вы из оригинальной базы уделяете документы же

не удаляю. Удалять собираюсь при успешной записи локально.

а как вы опредилил что у документа изменился ид? есть другой уникальный ключ для идентификации?

Притом не гуглится проблема а это значит что я где-то ошибся, видимо. Но где не понятно.

Я вам рекомендую остановиться на простых дампах

а как вы опредилил что у документа изменился ид? есть другой уникальный ключ для идентификации?

да есть, но он не всегда уникальный, просто нашелся документ подходящий

Когда вам потребуется их смержить, тогда и будете думать.

Мне уже сейчас надо их смержить.

Зачем?

тонее лучше спросить а что вы делаете с тем что кудато там скопировали?

Чтобы другие люди могли свои выборки по ним делать.

тонее лучше спросить а что вы делаете с тем что кудато там скопировали?

не понял вопроса

Короче. Ответ на ваш вопрос: встроенных инструментов нет. Разницу между двумя коллекциями вам надо высчитывать руками. Как — вопрос к вашим данным.

ну вот у вас два хранилища, зачем используется первое откуда вы данные тягаете, и для чего второе?

что мешает сразу использовать второе

Вы выбрали убыточную стратегию. 4.5гб в месяц это буквально даже в атласе смешные деньги.

Особенно если с этим данным работают

что мешает сразу использовать второе

Второе это десктоп сотрудника, первое это vps для постоянной выгрузки данных.

Ну было бы круто если бы можно было бы ни куда ни чего не таскать а записывать и хранить. Эх!

Ну было бы круто если бы можно было бы ни куда ни чего не таскать а записывать и хранить. Эх!

Возьмите и дайте клиенту расчеты

Купить 50гб в год будут дешевле чем вам делать синхронизацию

скажите начальству что по вашим данным обеспечить целостность данных при копирования в таком режиме пиздец как сложно и их статистика будет всегда кривая

Это реально баксов сто

В год!

Короче ребзя спасибо за инфу =) Есть над чем подумать в другой раз.

если прям горит, то на ваших данных и через флаг синка можно работать, но эт пиздец если честно, в один прекрасный момент вы не вывезете количество пришедших данных и ваш "прод" помрет от нехватки места

do_some_thing, слушайте парней, и делайте именно так. или доводите до сведения владельцев проекта, что попытка скроить сто баксов в год принесёт дикий кошмар. я вот этого кошмара нахватался, и не могу понять, зачем было экономить копейки и потерять миллион

А тем временем - подкскажите, при шардированном кластере и primary shard в виде MSA, есть возможность запредить secondary становиться мастером? то есть, если мастер вдруг сдохнет - я хочу, чтобы репликасет/шард был полностью оффлайн или read-only. или только своими скриптами както?

do_some_thing, слушайте парней, и делайте именно так. или доводите до сведения владельцев проекта, что попытка скроить сто баксов в год принесёт дикий кошмар. я вот этого кошмара нахватался, и не могу понять, зачем было экономить копейки и потерять миллион

а можно историю про то как потеряли лям?

do_some_thing, слушайте парней, и делайте именно так. или доводите до сведения владельцев проекта, что попытка скроить сто баксов в год принесёт дикий кошмар. я вот этого кошмара нахватался, и не могу понять, зачем было экономить копейки и потерять миллион

Спасибо за совет. Я уже говорил что это костыль и что если решили обрабатывать большие данные, то надо железо под них. Пока что надо сделать так.

а можно историю про то как потеряли лям?

ну это условно лям никто не терял, но в процентном соотношении - всё так.

кроилово ведёт к попадалову.

внутреннюю кухню вытаскивать на свет не буду, но вечный replica lag в праймари реплика сете привел к проблеме: - сдох праймари - секондари отставал на ~15 часов. И он после креша секондари стал праймари. дальше продолжать? :)

а данные для бизнеса на сколько критичные были?

ну как сказать... "все пропало", "как такое могло случиться", "делайте что хотите, только верните" и вот это вот всё.

выразить в финансовом виде не могу не знаю.

А тем временем - подкскажите, при шардированном кластере и primary shard в виде MSA, есть возможность запредить secondary становиться мастером? то есть, если мастер вдруг сдохнет - я хочу, чтобы репликасет/шард был полностью оффлайн или read-only. или только своими скриптами както?

Приоритет в 0 выставить

если примитивно посчитать месячный доход и умножить на часы "потери" данных - ну, около 5 нулей.

Приоритет в 0 выставить

и она прям тогда вообще никогда primary не станет? спасибо, я обмажу это скриптами.

Да. Сломалось все-же?

и она прям тогда вообще никогда primary не станет? спасибо, я обмажу это скриптами.

https://docs.mongodb.com/manual/core/replica-set-priority-0-member/

Да. Сломалось все-же?

да. ну и дальше классика - 1 день (!!!) работы одного программера и проблемы решились. вплоть до того, что за 1 час времени прям сейчас реплика догоняется на 2 часа. это кактойто дикий восторг, который не могли родить уже пару лет.

А что сделали?

наврал - 1 час. но всё равно восторг. сегодня утром при добавлении реплики был рассинхрон 15+ часов, сейчас уже около трёх.

А что сделали?

две вещи. 1. уменьшили поток данных на запись на ~50% тесты тут еще не делал - буду делать после того как пожар потухнет. 2. поменяли логику работы консумеров, которые из mq очереди пихают данные в монгу. раньше было, что всовывание документа приводило к апдейту документа в соседней коллекции (инкремент). сейчас этот инкремент не делается, а данные пихаются в aerospike. дальше раз в N минут данные в аэроспайке схлопываются и результат едет в монгу.

в общем всё очевидно и примитивно, но гораздо важнее было, чтобы программеры переименовывали "колонки" и меняли цвет иконок. а когда петух клюнул - все засуетились.

Делать надо то, что приносит денег. Иногда и петух-driven-development экономически целесообразен ;)