« Rev
@mongodb_ru   294
Fwd »


AstraSerg
с монго раньше не работал просто
да я и сам не то что бы спец большой, так, учусь понемногу...
A
Привет всем, такой вопрос, насколько функция remove быстрая? Просто получается такая ситуация, что у меня есть функция, которая запускает кроном каждые 5 минут: 1) достает из базы все данные 2)ремувит данные в таблице с помощью remove 3)меняет достаные данные чутка относительно новой инфы 4)инсертит эти же данные в таблицу
A
Я начал замечать, что информации в таблице очень мало и как-то не так работает инсерт
A
но еще позже увидел, что иногда ремув срабаывает позже инсерта(хотя все должно быть наоборот)(по логам)
A
причем может быть раз в 10 минут, а может раз в 100 минут
Yurii
но еще позже увидел, что иногда ремув срабаывает позже инсерта(хотя все должно быть наоборот)(по логам)
асинхронность? в монге есть expire индекс, который сам будет удалять документы
A
Видимо самым простым вариантом будет делать инсерт после кэлбэка ремува
A
асинхронность? в монге есть expire индекс, который сам будет удалять документы
предлагаешь им просто дать цикл жизни? но ведь есть шанс промахнуться относительно инсерта
A
удалить данные раньше
Yurii
удалить данные раньше
а у тебя они пересекаются? сделай unique индекс, пока данные есть он ещё раз их не вставит, потом удалит по индексу и ты вставишь
A
да, они считай самазаменяющиеся, просто каждый вызов функции добавляет данные из сторонней апихи, но в будущем в базе будет столько записей, что проще достать их из базы, фором добавить в массив один объект и сделать insertMany
V
ребят а тут говорили что в монго правильно настроить шардинг как можно раньше но там какие то проблемы с бекапами и управлением можете просветить?
A
А на сколько плох вариант с инсертом после каллбэка ремова
A
?
A
увы, но пока что нет, если же монга допилит массовый апдейт в бд с разными данными(а не то, как это есть сейчас, где на разные записи в таблице по сути можно только статус поменять один и тот же)
A
потому что получается так, что у меня у каждой записи есть массив и в этот массив каждые 5 минут надо добавлять новый объект
A
и потенциально таких записей может быть 1000-5000
A
и делать апдейт каждые 5 минут на столько записей весьма хардкорно по производительности
A
ну, я пошел тут из принципа меньшего количества запросов к бд)
A
Старая привычка от ментора)
AstraSerg
ну, я пошел тут из принципа меньшего количества запросов к бд)
а, то есть одним запросом всю 1000 доков не получится проапдейтить? тогда да, это плохой вариант...
A
по крайне мере пока что нет)
A
так как там полностью разные объекты
A
относительно каждой записи
A
если бы они были одинаковые, то да, updateMany и вперед
A
я так со статусами делаю, просто массив айдишников
A
и in
AstraSerg
как альтернативу вы хотите сделать один файнд всего, изменение в апликации, ремув всего и инсерт изменённых данных. Верно я понимю?
A
ну как самый сбалансированный вариант в моей ситуации(по моему мнению) - это достать все записи из базы, ремувнуть таблицу, допилить это данные как мне нужно и заинсертить опять в базу
A
оно так и работает уже отсноительно долго
A
но только сейчас я заметил
A
что данные не накапливаются
A
а потом логами заметил фичу, что ремув иногда(без особой логики) срабатывает после инсерта
A
а не до, как это прописано кодом
A
хотфиксом сейчас решил эту проблему вызово инсерта от resolve ремува
A
почему? я делаю 3 запрос за 5 минут, вместо n запросов относительно количество данных в базе
AstraSerg
> делаю 3 запроса относительно файнд и ремув - согласен, а вот инсерт множества документов, чет сомнения меня гнетут...
A
ну дык insertMany же по сути один запрос идет
A
нет?
A
просто пихаю массив с кучей объектов
A
один раз
AstraSerg
ну дык insertMany же по сути один запрос идет
как про суть я и сомневаюсь :) Соединение, безусловно один раз, а вот как оно внутри сделано, хз, не исключено, что тот же самый перебор документов и вставка по очереди
A
возможно так и есть, но ведь есть делать просто update, то это каждый раз новое соединение, нет?
A
я думаю есть разница между тем, как постучать в дверь и отдать сразу коробку писем
A
или же стучаться каждый раз давая новое письмо)
A
тогда(чисто теоретически) это получается тот же самый апдейт(но мы этого не узнаем), но с чутка меньшим количеством кода
A
монга конечно приятнее sql(имхо), но подставить тоже умеет)
AstraSerg
тогда(чисто теоретически) это получается тот же самый апдейт(но мы этого не узнаем), но с чутка меньшим количеством кода
да, узнать это сложно. > монга конечно приятнее sql(имхо) у меня тоже такое ощущение, хотя большинство назвали бы это садомаза :)
A
ну вот из бд, я сначала весьма долго был на монге
A
и вот только не так давно попробовал sql
A
поначалу было дико больно
A
но потом привык
A
но все равно монго ван лав
A
ну, считай я в целом с бд познакомился именно на монге)
AstraSerg
ну, считай я в целом с бд познакомился именно на монге)
Круть, дамал, такого не может быть...
yopp
Журналы, версионирование
Stepan
хотфиксом сейчас решил эту проблему вызово инсерта от resolve ремува
я не очень понял проблему. а как по другому работать с асинхронностью, если не после исполнения предидущий операции?
yopp
Если вам важна скорость синхронизации, то версионирование будет наиболее быстрым способом
yopp
Вам необходимо добавить одно поле, в котором будет указана «версия» данных. Это может быть любой сквозной идентификатор, например время «выгрузки», хеш архива или просто случайный идентификатор. Вы заводите коллекцию с «версиями». При поступлении новых данных, вы вставляете их в соотвествующие коллекции, добавляя поле с «версией». После окончания вставки добавляете документ в коллекцию с «версиями». При чтении данных, перед первым запросом вы читаете «последнюю версию».
yopp
Это имеет множество бонусов: возможность отката, практические мгновенное переключение, возможность «размазывать» вставку во времени
yopp
Удалять старые данные тоже не сложно, просто удаляете все документы с конкретной версией
yopp
Из минусов: сложнее индексы
yopp
Уникальные индексы будут требовать включения поля версии, что может наложить какие-то ограничения
antofa
Операторы сравнения дат работают как над строками? 2018-07-20T00:00:00Z < 2018-07-21T00:00:00Z
antofa
Пытаюсь сделать запрос http://dpaste.com/3NTVT8E. Но с gt и lt всегда выдает пустой массив.\
antofa
Данные такие - http://dpaste.com/1348P8X
yopp
https://docs.mongodb.com/manual/reference/operator/aggregation/dateFromString/
antofa
Нет
неправильно составил запрос?
yopp
Даты можно сравнивать когда они хранятся как даты. Как строки их сравнивать нельзя
antofa
Мб проще тогда для всех записей конвертнуть дату в строку/число (timestamp)?
« Rev
@mongodb_ru   294
Fwd »