Лучше всего посмотреть не умеет ли API возвращать обновления с некоторой точки

получил док по апи, взял id, вытащил из базы, обновил состояние, запихнул назад. и так для каждого дока. либо тоже самое с помощью апдейтов

в чём разница, не понял?

Лучше всего посмотреть не умеет ли API возвращать обновления с некоторой точки

не умеет.

не умеет.

Ну тогда вам нужно самостоятельно делать дельты

в том что первый вариант используется во вских ОРМ, а второй треубет ручками все делать

Либо перезаписывайте, либо вычисляйте дельту и обновляйте на нее

ответ апи не содержит временной метки о том, когда менялась инфа о товаре?

ответ апи не содержит временной метки о том, когда менялась инфа о товаре?

Это уже способ вычисления дельты

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

Можно вообще не вычислять дельты

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

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

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

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

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

конечно нужно

конечно нужно

габела тада

а приходит всегда полный актуальный список?

т.е. условно можно будет очистить коллекцию и заново наполнить (никогда так не делайте)

приходит да, актуальный на текущий момент

т.е. условно можно будет очистить коллекцию и заново наполнить (никогда так не делайте)

вот да, не хочу так делать

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

ну и апдейт просто по _id с переписыванием всех полей, это наверняка будет дешевле чем на каждый док делайть сначала ваборку и потом уже решать надо ли обновлять

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

хорошо. это всё понятно, советы дельные.

сейчас поясню вопрос

ну и апдейт просто по _id с переписыванием всех полей, это наверняка будет дешевле чем на каждый док делайть сначала ваборку и потом уже решать надо ли обновлять

Дешевле всего просто вставить новую версию

Апдейт всегда дороже вставки :)

хм, интересный ход

Если у нас эта коллекция под нагрузкой в 100к в секунду запросов, с ней ничего не будет?

если методом удалить всё и вставить по-новой

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

если методом удалить всё и вставить по-новой

развалится все нафиг

используются только на чтение

100к в секунду

развалится все нафиг

а если апдейтом делать - то не развалются, правильно?

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

Если у нас эта коллекция под нагрузкой в 100к в секунду запросов, с ней ничего не будет?

Ничего не будет, если сделаете как я написал

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

Плюс вы можете не сразу всем клиентам версию сменить, а плавно менять

Ничего не будет, если сделаете как я написал

Я не очень пока понял этот метод. Это получается апдейт просто с финтами,верно?

Чтоб дать кешу перестроиться

Я не очень пока понял этот метод. Это получается апдейт просто с финтами,верно?

Без апдейтов

https://db-engines.com/en/system/Cassandra%3BHBase%3BMongoDB @dd_bb на сколько эта таблица ещё соответствует действительности

https://db-engines.com/en/system/Cassandra%3BHBase%3BMongoDB @dd_bb на сколько эта таблица ещё соответствует действительности

??‍♂️

Без апдейтов

Вчитался. понял. Идея хорошая. Тогда нужен какой-то джоб по подчищению старых меток

удаление старых записей, я имею ввиду.

selectable replication factor Master-slave replication особенно интересно

просто оч странно что в 2018 до сих пор мастер слейв

просто оч странно что в 2018 до сих пор мастер слейв

Ничего странного. Master master имеет свои минусы

Ничего странного. Master master имеет свои минусы

ну вот например, у меня 3 ноды, все 3 мастеры, какие минусы перед тем, чтобы был 1 мастер и 2 слейва?

В том, что в монге тоже можно в три мастера. Это шардинг и есть

В том, что в монге тоже можно в три мастера. Это шардинг и есть

ну тогда вот такой сет, 9 машин, по 3 в дц

Ну, шард с зонами

Ну, шард с зонами

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

Так репликация это просто один из механизмов. :)

Она скорее не о масштабировании хранилища, а о его устойчивости.

Более того, документация в монге явно говорит о том, что так масштабировать не стоит

Она скорее не о масштабировании хранилища, а о его устойчивости.

я завтра пойду общаться на тему того, что людти хотят hbase и mongodb в openshift и в 8 сильно разрозненных географией местах

Все три вместе?

точнее это будет одна из тем, там и оракл будет и постгре, и ci\cd

Все три вместе?

в зависимости от задачи своя бд

Интересно. А что за индустрия?

телеком

Биллинг?

да

??

Очень интересно!

А монга как хранилище чего выступает?

пока безпонятия

я знаю что там oracle под счета и тп, постгрес под личные кабинеты, hbase под олапы

но у них ещё где то кассандра и монга

а ещё там сейчас идея всё в openshift запихать

Держите в курсе, прямо очень интересно

Я про openshift вообще толком ничего не знаю

Это редхат вроде?

Это редхат вроде?

да кубернетис с вебмордой

Прикольно

я бы согласился, если бы они в прод не тащили базы в контейнерах

Контейнеры поехали в ынтерпрайз по взрослому

если бы менеджент понимал их минусы

Да ладно. У меня вполне получилось собрать монгу в ранчере. Да, никаких автоматических фейловеров на уровне контейнеров, никакого гибкого стораджа.

Работает как часы

Очень удобно: кластер обновляется в три кнопки

Откатывается тоже в три

Да ладно. У меня вполне получилось собрать монгу в ранчере. Да, никаких автоматических фейловеров на уровне контейнеров, никакого гибкого стораджа.

у тебя ранчер от нагрузки не падает?

Очень удобно: кластер обновляется в три кнопки

а если завтра резко нагрузка вырастет, и 3-4 контейнера уйдут в слип?

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

у тебя ранчер от нагрузки не падает?

Я слышал про печальный опыт когда у тебя тыща хостов. У меня в худшем случае несколько десятков, хватает за глаза.

Я слышал про печальный опыт когда у тебя тыща хостов. У меня в худшем случае несколько десятков, хватает за глаза.

он умирает на 3х хостах, если просто. дать хорошую нагрузку в сами контейнеры

он начинает умирать тупо от кол-ва метрик летящих в него :)

Ну не знаю. Я заливал 5 гигабит данных в секунду в тестовый кластер, и всё было гладко :)

?мне вот интересно уже как это дело всё в контейнере мониторить нормально

А в стартапчике у нас 9 виртуальных хостов только под CI/CD было

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

Там тимсити в рабочее время кипятила три хоста без перерывов.

там cadvisor сумасходит

А вы его давно пробовали?

ладно фиг с ним, вдруг починили)

Это мне кажется в 2.0 уже починили