Sergey
"priseGraph": [
{
"uv": 3.8726395761729204,
"date": "2018-10-09T13:01:13.536Z"
},
{
"uv": 3.873669297632242,
"date": "2018-10-09T13:00:14.516Z"
},
]
Sergey
массив выглядит вот так
Sergey
вот кусок группировки
Sergey
{
$group: {
_id: "$token",
marketCap: { $first: "$marketCap" },
wallets: { $first: "$wallets" },
investors: { $first: "$investors" },
price: { $first: "$price" },
priceNSU: { $first: "$priceNSU" },
priseArr: { $push: "$price" },
priseGraph: { $push: { uv: "$price", date: "$createdAt" } },
id: { $first: "$_id" }
}
},
Sergey
мне ниже нужно еще одну группировку сделать?
Nick
нужно группироват ьпо дате просто
Nick
если вам нужно среднее на срезе token-date то указываете их в _id, если нет, то то на чем нужен срез
Sergey
да, мне нужен срез на токен
Nick
тогда зачем вы спрашиваете как сделат ьего по дням?
Nick
у вас после этой агрегации уже не останется инфомрациии о дате
Joseph
Вечер добрый , подскажите в чем может быть косяк, post hook на save не работает
LogSchema.post('save', (doc) => {
console.log('post save 2');
});
// вот собственно так создаю логи
exports.creatLog = log => new LogModel(log).save();
Алексей
Парни кто конектился к mlab. Такая проблема получается "failed to connect to server [ds247330.mlab.com:47330] on first connect [MongoNetworkError: connection 0 to ds247330.mlab.com:47330 timed out]",
"stack": "MongoNetworkError: failed to connect to server [ds247330.mlab.com:47330] on first connect
AstraSerg
telnet ds247330.mlab.com 47330 пройдет?
Oleg
лучше не светить айпи с портами, логины/пароли и прочее :)
Lev
Всем привет
Lev
У меня такая хрень: есть ну очень жирная база данных с кучей коллекций по 60к документов. Иногда необходимо целиком обновлять её, и как мне кажется самым быстрым способом было бы создание второй бд во время обновления а затем подмена основной на свежую с выпилом всех старых данных
Lev
Как бы вы такое реализовали?
Lev
там вычленять каждый документ для проверки на признак обновления информации было бы слишком долго как по мне
Lev
У меня такая хрень: есть ну очень жирная база данных с кучей коллекций по 60к документов. Иногда необходимо целиком обновлять её, и как мне кажется самым быстрым способом было бы создание второй бд во время обновления а затем подмена основной на свежую с выпилом всех старых данных
ну и обновленная бд мне прилетает от вторых лиц. никак повлиять на выдачу нельзя, говорят вот тебе новая бд с новыми данными и делай что хочешь с этим но необновленных документов быть не должно
Nick
60к доков - не жирная база, если тебе дают дамп - то прост дроп старой - заливка новой. опять же если позволяется простой в работе бд
Sergey
Если процент реально обновлённых документов невысок (цифра с потолка — меньше 10%), то стоит извлечь документ, сравнить и, если требуется, обновить.
Идея с наливкой новой базы хорошая. Особенно если к базе идёт большое количество запросов от пользователей, т. к. массовая наливка однозначно повлияет на качество обслуживания чтений.
Lev
вот хотелось бы не нарушать доступность. менять имена бд нельзя, это уже знаем
Lev
вдруг какая житейская хитрость есть
Nick
вот вы и ответили на свой вопрос про - залить в новую бд, еслинельзя простой - нельзя новую бд
Lev
костыльненько
Nick
ваша задача - костыль
Nick
реально
Lev
да не говори, реально жесть из 1999
Sergey
вот вы и ответили на свой вопрос про - залить в новую бд, еслинельзя простой - нельзя новую бд
Почему нельзя-то? Пока наливаем новую, ходим в старую. Как перелили переключаемся на новую.
Nick
Почему нельзя-то? Пока наливаем новую, ходим в старую. Как перелили переключаемся на новую.
а перключение мгновенное?
Nick
я такого еще нигде не видел
Nick
тогда проще
Sergey
а перключение мгновенное?
Нет, конечно. Но оно и не должно быть мгновенным для availability. Ну, при условии, что данные помимо переливки не модифицируются
Nick
создаете у всех доков поле по типу updatedAt и загоняете новые данные и обновляя время заливки. потом удаляете все что старше времени начала заливки
Lev
хмм...ну типа примерно понял. иметь 2 активных монгоклиента. каждый раз при обращении проверять есть ли там в коллекции хоть что-то. если коллекция пустая - переключаемся на второй монгоклиент
Lev
и так бесконеееееееееееееееееееееее
Nick
создание новых проблем - это так себе решение текущей
Lev
Nick
если у вас вдруг 4 монга и уже ест ьтранзакции, то это даже можно сделать атомарно
Lev
только тогда не updatedAt а по обжектайди вычленять время создания
Lev
и всё что старше 1 минуты удалять к хренам
Lev
точно
Nick
не используйте objectid кроме как id
Nick
забудьте что гдето там есть время
Lev
Почему это? о_О
Nick
в общем случае вы не сможете уверенно привязать его ко времени насервере приложения
Lev
звучит как вызов
Nick
ну и оно не меняется при апдейте, в вашем случае оно так и вообще не подходит
Lev
так если я буду не апдейтить поля а заливать новые документы поверх, а потом удалять старые...да, лучше по $lt удалять, тогда поле сделаю
Lev
спасибо
yopp
Nick
Нет, конечно. Но оно и не должно быть мгновенным для availability. Ну, при условии, что данные помимо переливки не модифицируются
конечно мое высказывание слегка категоричное и все зависит от приложения и как оно работает с данными и какие требования предъявляются. можно хоть и вообще очищать таблицу перед обновлением
yopp
Мы тут это уже обсуждали
yopp
Время можно использовать как версию, при условии что оно будет одинаковое для всех документов из одной выгрузки
yopp
Заводите поле version, делаете по нему индекс и заливаете все новые документы с одной версией. В приложении ко всем запросам добавляете это поле. После завершения загрузки новой выгрузки, делаете так, чтоб приложение использовало новую версию в запросе. Можно для этого завести отдельную коллекцию с версиями
yopp
У вас небольшой объём данных, это самый оптимальный способ. И не будет простоя
Lev
little big
всем привет. Ребят, есть архитектурный вопрос. Имеется маленький блокчейн, который я пытаюсь спарсить. В блокчейне есть операции, которые собираются в транзакции, которые собираются в блоки. Я подумал, что было бы неплохо выделить одну коллекцию под блоки, в которой каждый объект был бы представлен как информация о блоке + массив ObjectID транзакций в этом блоке. Далее в моделе для транзакций я подумал хранить объекты, содержащие информацию по транзакции + массив ObjectID, операций, входящих в эту транзакцию + ссылку на блок, к которому эта транзакция привязана. И на каждуо операцию я сделал отдельную коллекцию.
Я подумал, что если мне, например, нужно вытащить список определенных операции по определенному аккаунту (допустим "лайки", которые поставил этот пользователь), я просто пробегусь по модели с лайками и вытащу все, которые относятся к этому пользователю.
А вот как всё это сделать красиво и по уму я чот не знаю. Если есть советы и предложения, то пожалуйста. Любая помощь приветствуется
little big
как лучше сделать для максимизации скорости на чтение и лёгкости в написании запросов?
Іван 🤙
Приветули!)
Подскажите плиз, у меня есть список пользователей, для каждого нужно сохранять и обновлять задачи которые приходят:
есть коллекция users, в которой есть поле "tasks":
{'_id':123456,
'phone': 0202020202,
'tasks':[{'_id': 12345,
'name': 'задача1'},
{'_id': 54321,
'name': 'задача2'}]
Мне нужно добавлять\удалять\изменять новые словари в этом поле ("tasks")
Просто суть в том, что одна задача может быть у нескольких пользоваетелей, и по каждому пользователю нужно вести свой учёт (выполнил ли задачу, отменил, и тд.)
Можно ли это делать методом db.coll.update() ??
Или лучше создать еще одну коллекцию для задач?
Lev
Я бы коллекцию для задач сделал и отмечал бы там сотрудников которые выполнили задачку каким-нибудь флагом, + рефу на обжАйди сотрудника там же хранил бы. И сотруднику закинул бы рефу на задачу
Іван 🤙
Я бы коллекцию для задач сделал и отмечал бы там сотрудников которые выполнили задачку каким-нибудь флагом, + рефу на обжАйди сотрудника там же хранил бы. И сотруднику закинул бы рефу на задачу
тобишь в самой задаче хранить список сотрудников кому она открыта + флаг тому кто выполнил?
можно ли как то обновлять\удалять\добавлять словари в ключ??
просто я так понимаю метод .update - работает по ключу, а мне нужно в этом ключе найти и апдейтнуть один из словарей😅
Lev
тобишь в самой задаче хранить список сотрудников кому она открыта + флаг тому кто выполнил?
можно ли как то обновлять\удалять\добавлять словари в ключ??
просто я так понимаю метод .update - работает по ключу, а мне нужно в этом ключе найти и апдейтнуть один из словарей😅
Кажется только если весь аррэй менять и полностью обновлять. Надо методы смотреть, я на обеде сорян)
Іван 🤙
Кажется только если весь аррэй менять и полностью обновлять. Надо методы смотреть, я на обеде сорян)
вот, мне тоже кажется что нужно грубо говоря работать со всем списком словарей, (достать — обновить— залить в бд)
Vova
Іван 🤙
Операторы почитай
но оператором я смогу сделать выборку, но не вижу варианта апдейтнуть 1 словарь из списка словарей в одном ключе
так понимаю что апдейтнуть можно только перезаписав весь ключ(а мне нужно только 1 словарь из списка)
Petro
Запущена mongodb на ubuntu на aws, случайно удалил колекцию…. можно ли востановить данные?
倫太郎
No
Іван 🤙
Constantin
Если tasks — это массив — то, $ для проекции. $pull — для удаления, $push для добавления
Вот тут подробно все операторы, которые вам нужны https://docs.mongodb.com/manual/reference/operator/update-array/
Іван 🤙
Судя по всему tasks — все же массив
Спасибо)
да, массив))
но оно ведь всеравно будет перезаписывать весь ключ?
Anonymous
подскажите, как организовать данные в случае "комментариев к комментариям"?
AstraSerg
Спасибо)
да, массив))
но оно ведь всеравно будет перезаписывать весь ключ?
Если массив, поправьте пример. Там должны быть [] в валью для ключа tasks
AstraSerg
подскажите, как организовать данные в случае "комментариев к комментариям"?
Влаженные массивы если короткие, или ссылки на другую коллекцию
Anonymous
вложенные массивы в каком виде?