Anonymous
Джоб сделайте, который будет периодически обновлять
Anonymous
В том то и вопрос - как сопоставить ту коллекцию, что у нас в базе с той инфой, что у нас пришла.
yopp
Это задача синхронизации данных. Тут нет каких-то универсальных рецептов
Anonymous
😢
yopp
Вы можете делать или полную замену или вычислять дельты
Nick
получил док по апи, взял id, вытащил из базы, обновил состояние, запихнул назад. и так для каждого дока. либо тоже самое с помощью апдейтов
yopp
Лучше всего посмотреть не умеет ли API возвращать обновления с некоторой точки
Anonymous
Nick
в том что первый вариант используется во вских ОРМ, а второй треубет ручками все делать
Anonymous
Либо перезаписывайте, либо вычисляйте дельту и обновляйте на нее
brammator
ответ апи не содержит временной метки о том, когда менялась инфа о товаре?
yopp
ответ апи не содержит временной метки о том, когда менялась инфа о товаре?
Это уже способ вычисления дельты
brammator
если нет, то можно дубовым образом вычислить хеш полученного документа, и если он не совпадает с ранее записанным в базе, то обновлять весь документ (и хеш, конечно, тоже)
yopp
Можно вообще не вычислять дельты
Nick
еще не забудьте нужно ли вам определят ьчто данные удалились и их нужно так же удалить из вашей базы
brammator
всё равно весь документ с апи магазина уже выкачан, скорее всего узким местом будет его получение, а не запись в базу.
yopp
Берем временную метку начала синхронизации. Вытаскиваем все документы. Добавляем временную метку ко всем документам в виде индексируемого поля _v и записываем в монгу. По завершению синхронизации записываем временную метку в отдельный документ в отдельной коллекции. Дальше когда мы делаем запрос в каталог, мы читаем самую последнюю метку из коллекции меток и добавляем ее ко всем запросам.
yopp
Это простейшее версионирование. Вы дальше уже сами у себя можете считать дельты и вообще делать все вещи которые позволяет делать версионирование.
Anonymous
Nick
а приходит всегда полный актуальный список?
Nick
т.е. условно можно будет очистить коллекцию и заново наполнить (никогда так не делайте)
Anonymous
приходит да, актуальный на текущий момент
Anonymous
т.е. условно можно будет очистить коллекцию и заново наполнить (никогда так не делайте)
вот да, не хочу так делать
Nick
тогда как выше указал yopp вам необходимы метки времени, чтобы после обновления списка удалять все со старой меткой времени
Nick
ну и апдейт просто по _id с переписыванием всех полей, это наверняка будет дешевле чем на каждый док делайть сначала ваборку и потом уже решать надо ли обновлять
Nick
ну и чистые апдейты позволят использовать bulk, может какой профит и поулчите
Anonymous
хорошо. это всё понятно, советы дельные.
Anonymous
сейчас поясню вопрос
yopp
ну и апдейт просто по _id с переписыванием всех полей, это наверняка будет дешевле чем на каждый док делайть сначала ваборку и потом уже решать надо ли обновлять
Дешевле всего просто вставить новую версию
yopp
Апдейт всегда дороже вставки :)
Nick
хм, интересный ход
Anonymous
Если у нас эта коллекция под нагрузкой в 100к в секунду запросов, с ней ничего не будет?
Anonymous
если методом удалить всё и вставить по-новой
Nick
а ведь да и просто потом предыдущую версию потереть, если не нужна. тут наверное вопрос в том какие данные и как они используются
Anonymous
используются только на чтение
Nick
100к в секунду
Nick
тут смысл такой, что через удаление есть момент когда данных в коллекции нет, и в это время туда полетят запросы, то нормально будет что ничего не вернется?
yopp
Если у нас эта коллекция под нагрузкой в 100к в секунду запросов, с ней ничего не будет?
Ничего не будет, если сделаете как я написал
yopp
У вас кеш быстро перебалансируется. Если места под новые документы хватит без сброса на диск, то возможно клиенты даже ничего не заметят
yopp
Плюс вы можете не сразу всем клиентам версию сменить, а плавно менять
Anonymous
Ничего не будет, если сделаете как я написал
Я не очень пока понял этот метод. Это получается апдейт просто с финтами,верно?
yopp
Чтоб дать кешу перестроиться
Старый
https://db-engines.com/en/system/Cassandra%3BHBase%3BMongoDB
@dd_bb на сколько эта таблица ещё соответствует действительности
yopp
Anonymous
Без апдейтов
Вчитался. понял. Идея хорошая. Тогда нужен какой-то джоб по подчищению старых меток
Anonymous
удаление старых записей, я имею ввиду.
Старый
selectable replication factor Master-slave replication особенно интересно
Старый
просто оч странно что в 2018 до сих пор мастер слейв
yopp
просто оч странно что в 2018 до сих пор мастер слейв
Ничего странного. Master master имеет свои минусы
Старый
Ничего странного. Master master имеет свои минусы
ну вот например, у меня 3 ноды, все 3 мастеры, какие минусы перед тем, чтобы был 1 мастер и 2 слейва?
yopp
В том, что в монге тоже можно в три мастера. Это шардинг и есть
Старый
В том, что в монге тоже можно в три мастера. Это шардинг и есть
ну тогда вот такой сет, 9 машин, по 3 в дц
yopp
Ну, шард с зонами
Старый
Ну, шард с зонами
разница в том, что когда заходишь в доку и читаешь про репликацию, про это сразу не написано, и честно сказать, если надо в голове держать ещё 5-6 субд, в голове это может не отложится
yopp
Так репликация это просто один из механизмов. :)
yopp
Она скорее не о масштабировании хранилища, а о его устойчивости.
yopp
Более того, документация в монге явно говорит о том, что так масштабировать не стоит
Старый
Она скорее не о масштабировании хранилища, а о его устойчивости.
я завтра пойду общаться на тему того, что людти хотят hbase и mongodb в openshift и в 8 сильно разрозненных географией местах
yopp
Все три вместе?
Старый
точнее это будет одна из тем, там и оракл будет и постгре, и ci\cd
yopp
Интересно. А что за индустрия?
Старый
телеком
yopp
Биллинг?
Старый
да
yopp
👍🤟
yopp
Очень интересно!
yopp
А монга как хранилище чего выступает?
Старый
пока безпонятия
Старый
я знаю что там oracle под счета и тп, постгрес под личные кабинеты, hbase под олапы
Старый
но у них ещё где то кассандра и монга
Старый
а ещё там сейчас идея всё в openshift запихать
yopp
Держите в курсе, прямо очень интересно
yopp
Я про openshift вообще толком ничего не знаю