yopp
не слушайте что говорят, меряйте для себя
yopp
если у вас images это несколько десятков uuid то вот это «быстрее» это ложь
λ
Ну бывает до нескольких сотен
yopp
это совершенно нерелевантно
yopp
всё что меньше порядков десятков килобайт вообще не имеет никакой разницы, только в сети
yopp
а сетевой оверхед решается через project
yopp
потому что страница памяти и блок на диске это 4кб, а значит физически меньше запросить тупо нельзя
yopp
а даже если будет несколько страниц, они скорее всего будут лежать попорядку и вы никогда не увидите разницы
yopp
только если не будете ездить по всему объёму данных постоянно
λ
Ну вот одна выглядит приблизительно так (в будущем будет расширение):
{
"_id" : UUID("2773407a-89f6-466d-8fa7-b9a2ed188e54"),
"order" : 1,
"hidden" : false,
"new" : false,
"manual" : true,
"size" : 210517,
"format" : "JPEG",
"width": 800,
"height": 640,
"hash": "e17e93d702454e0b2c3e2dc2584d",
"group": "groupName",
"objects": ["table"],
"creationDate" : ISODate("2019-08-26T12:09:48.482Z")
},
λ
*100 — это разве не много?
yopp
много это относительное понятие
yopp
как я уже говорил, вы можете выборочно денормализировать и хранить в articles только нужную для articles часть документа из images
yopp
т.е. сейчас наиболее эффективная стратегия одна коллекцтя
yopp
если вдруг наступит тот день, когда у вас структура доростёт до той, которую вы планируете И это будет явной проблемой, которая будет потдвержаться метриками, то тогда можно будет подумать о том чтоб частично нормализовать документ
yopp
предварительная оптимизация это чёрная дыра
yopp
оптимизировать надо реальные проблемы, когда они стоят денег
Anonymous
5 млн записей в одной коллекции, в поле теги массив из айдишников из соседней коллекции. понадобилось заменить эти массивы айдишников самими названиями тегов. получил весь список тегов (300+), прохожусь циклом по каждому тегу и делаю updateMany. сейчас 140 тегов обработано, прошло 40 минут. есть быстрее варианты? почему блин так долго?
yopp
140*5M = 700M апдейтов
yopp
а курсором пройтись по всем документам и сделать один update на каждый документ это 5M апдейтов
yopp
а зачем тег вместо id?
Anonymous
а курсором пройтись по всем документам и сделать один update на каждый документ это 5M апдейтов
да я ж когда делал обратную задачу - подменял названия тегов на айдишники вы тут же мне советовали делать updateMany. я тогда как раз проходился по очереди по каждоу документу. вы посоветовали updateMany, потому что оно апдейтит за 1 раз
Anonymous
в чем тогда смысл updateMany
yopp
updateMany позволяет одним запросом обновить множество документов
yopp
но это не отменяет того факта что все попавшие в выборку документы надо обновить
yopp
математика очень простая, я её выше привёл. У вас 140 тегов и 5М документов. В худшем случае если во всех документах есть по каждому из 140 тегов у вас выходит 700М обновлений документов
yopp
если пройтись курсором, ваша задача в решается за 5М обновлений документов
Anonymous
ну так он же не будет обновлять те документы которые не попали в выборку. какая тогда разница
yopp
не попали в выборку это нижняя граница
yopp
и она тоже лежит на 5М
yopp
грубо посчитать можно количество тегов в документе и сколько документов на каждый тег
yopp
но это скорее всего всё равно будет больше 5М
yopp
так что в вашем случае эффективнее обновить все теги и сделать один запрос на один документ
Anonymous
ну да, он же так один и тот же документ будет несколько раз обновлять, если у него несколько тегов
Anonymous
ок, попробую. спс
Anonymous
а вот еще интересно - почему монга после окончания сложных операций не очищает память? вот например после таких, выжирает 90% памяти. после окончания скрипта память по прежнему занята, помогает только перезапуск монги
yopp
потому что выделение памяти очень дорогая и медленная операция
yopp
базы данных обычно не отдают память назад
yopp
и правильно делают
Anonymous
ухтблин)))
yopp
в целом, свободная память == деньги на ветер
yopp
по этому на самом деле память никогда не свободная, а операционная система использует её для всяких целей. например как кеш для дисковых операций
yopp
её показывают как «свободную», потому что операционная система может сводобно сбросить кеш и выдать память тому, кому она потребовалась
Anonymous
мое опасение что монга выжирает память на пиках, и потом для другого приложения его не хватает, при том что самой монге в тот момент она уже не нужна
yopp
базы данных не нужно размещать с другими приложениями
yopp
это плохо кончится для обоих
Anonymous
ну это в идеале, а когда это группа небольших сайтов, то себе дороже усложнять все
yopp
нет, не в идеале
Anonymous
а так поднял впску за 30 баксов и оно там крутится
yopp
потому что обычно увеличение нагрузки на приложение, ведёт к увеличению нагрузки на базу данных
yopp
и когда они все на одном хосте, то это заканчивается тем, что ни приложение, не база не будут нормально работать из-за вечной борьбы за ресурсы
yopp
если сильно хочется, то нужны или контейнеры с квотами, или виртуализация
yopp
так чтоб чётко поделить ресурсы и установить приоритеты
Alex
Всем привет.
Подскажите как сделать схему.
Например есть две схемы User, Courses
У User есть поле courses типа массив с курсами на которые он подписан. Но кроме объекта самого курса нужно как-то хранить доп информацию, типа дату подписки, прогресс на курсе..... и т.п.
yopp
скорее всего у вас подписка на курс это отдельная сущность, со своими изолированными свойствами
Alex
скорее всего у вас подписка на курс это отдельная сущность, со своими изолированными свойствами
А если что-то вроде такого?
const userSchema = new Schema({
name: { type: String },
courses: [
course: { type: ObjectId, ref: 'Courses' },
startedDate: { type: Date },
progress: { type: Number }
]
});
yopp
Я плохо разбираюсь в монгусе. Вам нужна вложенная модель типа Assigment, вместо голых атрибутов.
yopp
И уже в ней связь с курсом и всё остальное
Anonymous
Приветствую.
В админке MLab можно удалить часть коллекции, не всю?
Nick
Приветствую.
В админке MLab можно удалить часть коллекции, не всю?
Что значит "часть коллекции"?
Anonymous
Из 300 документов оставить 100.
Arisha Khanzhova
всем привет!
Подскажите, плз, как пользоваться фильтром?
Такая коллекция:
[{
"_id" : "000000000000000000000",
"store" : [
{
"parameter" : "st.md.fe.n18",
"value" : 6
},
{
"parameter" : "st.md.fe.n22",
"value" : 9
},
{
"parameter" : "st.md.fe.n46",
"value" : 13
},
{
"parameter" : "st.md.fe.n222",
"value" : 14
},
{
"parameter" : "st.md.fe.n29",
"value" : 16
},
{
"parameter" : "st.md.fe.n30",
"value" : 17
},
{
"parameter" : "st.md.fe.n32",
"value" : 19
},
{
"parameter" : "st.md.fe.n33",
"value" : 20
},
{
"parameter" : "st.ext.useShiftTask",
"value" : true
},
{
"parameter" : "st.ext.PermalinkHandling",
"value" : true
},
{
"parameter" : "st.ext.SUPromo",
"value" : true
},
{
"parameter" : "st.md.defaultRuleSet",
"value" : "cof"
},
{
"parameter" : "st.mg.sentry",
"value" : ""
},
{
"parameter" : "st.mg.dkkk",
"value" : 1
}
]
}
]
Хочу в ней оставить только то, что удовлетворяет
"parameter" like «%st.md.fe%»
Arisha Khanzhova
https://play.db-ai.co/m/Xc0LomjklgABiNjw
Arisha Khanzhova
Заранее спасибо )
Dmitry
лол думал чат по джс, не то написал
Bohdan
отчасти это чат по js)
yopp
https://play.db-ai.co/m/Xc0LomjklgABiNjw
https://docs.mongodb.com/manual/reference/operator/aggregation/regexMatch/
4.2+
yopp
На плейграунде ещё 4.0
Arisha Khanzhova
https://docs.mongodb.com/manual/reference/operator/aggregation/regexMatch/
4.2+
https://play.db-ai.co/m/Xc0LomjklgABiNjw
Arisha Khanzhova
Блин не работает (
yopp
Блин не работает (
Вы пропустили $ в названии оператора. Но на плейграунде оно и не сработает, там 4.0 и этот оператор там не поддерживается
Arisha Khanzhova
Вы пропустили $ в названии оператора. Но на плейграунде оно и не сработает, там 4.0 и этот оператор там не поддерживается
в таком случае у меня локально запрос выдает ошибку:
'Unrecognized expression '$regexMatch'' on server
yopp
Arisha Khanzhova
А какая у вас версия монги?
4.0.0 - он не поддерживает эту команду? какой тогда обходить?
yopp
Увы, никакой.
Только если сделать $unwind, а потом $match c $regexp, а потом $group
yopp
Но в таком случае проще на клиенте отфильтровать
Arisha Khanzhova