{ _id: ObjectId(“1”), subItem: { field1: 123, } } { _id: ObjectId(“2”), duplicateOf: ObjectId(“1”), subItem: { field5: “string”, } }

{ _id: ObjectId(“1”), subItem: { field1: 123, } } { _id: ObjectId(“2”), duplicateOf: ObjectId(“1”), subItem: { field5: “string”, } }

Какую сущность описывает этот объект?

продукт

И у разных видов продуктов разные поля?

Поищите от чего у вас шард нагибается. Вероятно это праймари шард и ему не хватает ресурсов

С этим проблем нет. Мы словили неприятный баг с балансировкой, который приводил к зависанию части запросов на одной из реплик в одном из шардов. Эти запросы тупо забили весь пул. Хотя там даже не primary реплика была. https://jira.mongodb.org/browse/SERVER-42737, очень ждём релиза 4.0.14 с фиксом. Были ещё случаи, когда неосторожные действия в продакшене приводила к перегрузке одной из secondary с аналогичным результатом.

да. у каких-то есть duplicateOf, у каких-то есть subitem.field5

Передо мной сейчас стоит вопрос, стоит ли упарываться в сторону устойчивости сервиса при подобных проблемах. Или ограничиться исправлением первопричин и мерами вроде увеличения пулов.

Первопричины и пулы

да. у каких-то есть duplicateOf, у каких-то есть subitem.field5

для продуктов эффективнее использовать Attribute Type паттерн products: { _id: ..., <common_fields>, attrs: [ {type: ObjectId(...), value: "foo"}, {type: ObjectId(...), value: "bar"}, {type: ObjectId(...), value: 53}, ] } attribute_types: { _id: ObjectId(...), value_type: "String", name: "Color" }

а вот duplicateOf это сложный вопрос

может как один из атрибутов?

зависит от вашей бизнес-логики

хотя выборка по ней опять же вряд ли будет эффективной…

если duplicateOf это просто признак, то это одна история если это механизм наследования, то это другая

ну чаще всего я использую { duplicateOf: { $exists: false } } как первый шаг агрегации для отсеивания ненужных.

а зачем и какая логика у duplicateOf?

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

@dd_bb, а что если duplicateOf будет одним из атрибутов?

ах, тогда наверное поиск по конкретному значению будет не очень эффективным...

ребят в каком формате лучше хранить html в mongodb?

есть выбор между мнемоникой и json или же обычным html

ребят в каком формате лучше хранить html в mongodb?

не хранить html в базе а хранить ссылку на cdn

не хранить html в базе а хранить ссылку на cdn

непонял

непонял

ну html это статика, а хорошая практика статику класть в cdn (например amazon s3, или самому захостить опенсорсный аналог)

ну html это статика, а хорошая практика статику класть в cdn (например amazon s3, или самому захостить опенсорсный аналог)

хз геморой я хочу у себя в базе

у тебя в базе будут лежать прямые url на эти файлы

у тебя в базе будут лежать прямые url на эти файлы

я понял, а хранить html в базе это безопасно?

@dd_bb, а что если duplicateOf будет одним из атрибутов?

какая логика у duplicateOf и какую задачу вы решаете черещ $exists: true?

ребят в каком формате лучше хранить html в mongodb?

в виде gridfs документа

какая логика у duplicateOf и какую задачу вы решаете черещ $exists: true?

спасибо но решил вопрос по другому, у редактора есть кроме html формат json. я его просто через strinify буду добовлять а вытаскивать через parse и через htmlparser добовлять

какая логика у duplicateOf и какую задачу вы решаете черещ $exists: true?

1) https://t.me/MongoDBRussian/64540 2) https://t.me/MongoDBRussian/64542

а, exists: false. а почему именно так?

ну, чтобы отсеить группу ненужных объектов в выборке

а почему они ненужные?

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

а сколько у вас документов сейчас?

~80000

сделайте индекс и не парьтесь пока

он есть

тогда не парьтесь

😐

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

что говорит explain?

explain({executionStats: 1})

{ "stage" : "IXSCAN", "keyPattern" : { "duplicateOf" : 1 }, "indexName" : "duplicateOf_1", "isMultiKey" : false, "multiKeyPaths" : { "duplicateOf" : [] }, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "duplicateOf" : [ "[MinKey, MaxKey]" ] } }

{ "executionSuccess" : true, "nReturned" : 23768, "executionTimeMillis" : 756, "totalKeysExamined" : 85047, "totalDocsExamined" : 85047, "executionStages" : { "stage" : "FETCH", "filter" : { "duplicateOf" : { "$exists" : true } }, "nReturned" : 23768, "executionTimeMillisEstimate" : 314, "works" : 85048, "advanced" : 23768, "needTime" : 61279, "needYield" : 0, "saveState" : 664, "restoreState" : 664, "isEOF" : 1, "invalidates" : 0, "docsExamined" : 85047, "alreadyHasObj" : 0, "inputStage" : { "stage" : "IXSCAN", "nReturned" : 85047, "executionTimeMillisEstimate" : 106, "works" : 85048, "advanced" : 85047, "needTime" : 0, "needYield" : 0, "saveState" : 664, "restoreState" : 664, "isEOF" : 1, "invalidates" : 0, "keyPattern" : { "duplicateOf" : 1 }, "indexName" : "duplicateOf_1", "isMultiKey" : false, "multiKeyPaths" : { "duplicateOf" : [] }, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "duplicateOf" : [ "[MinKey, MaxKey]" ] }, "keysExamined" : 85047, "seeks" : 1, "dupsTested" : 0, "dupsDropped" : 0, "seenInvalidated" : 0 } }, "allPlansExecution" : [] }

а что дальше в пайплайне?

а что дальше в пайплайне?

ничего. это db.items.find( { "duplicateOf": { $exists: true } } )

"nReturned" : 85047, "keysExamined" : 85047, а дальше вы читаете 85к документов

0.01ms на документ, вполне ничего

мне кажется 700 мс на 85000 документов это уже слишком много

и что-то явно не так

всё абсолютно так

попробуйте сделать covered query

db.items.find( { "duplicateOf": { $exists: true } }, {_id: 0, duplicateOf: 1})

~800 ms

а что explain показывает?

а какая у вас версия монги?

4.0.10

winning plan: { "stage" : "PROJECTION", "transformBy" : { "_id" : 0.0, "duplicateOf" : 1.0 }, "inputStage" : { "stage" : "FETCH", "filter" : { "duplicateOf" : { "$exists" : true } }, "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "duplicateOf" : 1 }, "indexName" : "duplicateOf_1", "isMultiKey" : false, "multiKeyPaths" : { "duplicateOf" : [] }, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "duplicateOf" : [ "[MinKey, MaxKey]" ] } } } }

{ "stage" : "PROJECTION", "nReturned" : 23768, "executionTimeMillisEstimate" : 435, "works" : 85048, "advanced" : 23768, "needTime" : 61279, "needYield" : 0, "saveState" : 665, "restoreState" : 665, "isEOF" : 1, "invalidates" : 0, "transformBy" : { "_id" : 0.0, "duplicateOf" : 1.0 }, "inputStage" : { "stage" : "FETCH", "filter" : { "duplicateOf" : { "$exists" : true } }, "nReturned" : 23768, "executionTimeMillisEstimate" : 416, "works" : 85048, "advanced" : 23768, "needTime" : 61279, "needYield" : 0, "saveState" : 665, "restoreState" : 665, "isEOF" : 1, "invalidates" : 0, "docsExamined" : 85047, "alreadyHasObj" : 0, "inputStage" : { "stage" : "IXSCAN", "nReturned" : 85047, "executionTimeMillisEstimate" : 148, "works" : 85048, "advanced" : 85047, "needTime" : 0, "needYield" : 0, "saveState" : 665, "restoreState" : 665, "isEOF" : 1, "invalidates" : 0, "keyPattern" : { "duplicateOf" : 1 }, "indexName" : "duplicateOf_1", "isMultiKey" : false, "multiKeyPaths" : { "duplicateOf" : [] }, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "duplicateOf" : [ "[MinKey, MaxKey]" ] }, "keysExamined" : 85047, "seeks" : 1, "dupsTested" : 0, "dupsDropped" : 0, "seenInvalidated" : 0 } } }

попробуйте сделать sparse индекс по $exists: true

индекс по $exists?

https://docs.mongodb.com/manual/core/index-partial/#create-a-partial-index

да, $exists: true

у вас тут shape запроса [minkey, maxkey], а это получается весь индекс попадает в fetch

/report

Да когдаж вы бота поставите

Как работает regex, точнее поиск. Интересует выборка без учета регистра, это перебор возможных вариантов ? То есть [ /^ foo /i), это поиск : FOO, FOo, Foo, foo, FoO, foO и т.д. ? или нет? Если это перебор, то лучше завести поле <Field1UpperCase> ? и не делать выборку без учета регистра? А если индекс составной, то он получается массив массивов ? В таком случае может имеет место создать поле <FieldUpperCast> = <Field1toUpper> + <Field2toUpper> + ….. И делать поиск по нему ?

Как работает regex, точнее поиск. Интересует выборка без учета регистра, это перебор возможных вариантов ? То есть [ /^ foo /i), это поиск : FOO, FOo, Foo, foo, FoO, foO и т.д. ? или нет? Если это перебор, то лучше завести поле <Field1UpperCase> ? и не делать выборку без учета регистра? А если индекс составной, то он получается массив массивов ? В таком случае может имеет место создать поле <FieldUpperCast> = <Field1toUpper> + <Field2toUpper> + ….. И делать поиск по нему ?

Регулярки работают как и везде к значению поля применяется регулярка. Если же регулярка содержит символ начала строки, то там в некоторых случаях может быть использован индекс. В общем случае регулярки это зло и лучше поменять подход к хранению данных если это возможно

Как работает regex, точнее поиск. Интересует выборка без учета регистра, это перебор возможных вариантов ? То есть [ /^ foo /i), это поиск : FOO, FOo, Foo, foo, FoO, foO и т.д. ? или нет? Если это перебор, то лучше завести поле <Field1UpperCase> ? и не делать выборку без учета регистра? А если индекс составной, то он получается массив массивов ? В таком случае может имеет место создать поле <FieldUpperCast> = <Field1toUpper> + <Field2toUpper> + ….. И делать поиск по нему ?

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

Вопрос по созданию архитектуры(модели). Какие есть альтернативы поиска по части текста ? Только { $text: { $search: "foo"}}

Вопрос по созданию архитектуры(модели). Какие есть альтернативы поиска по части текста ? Только { $text: { $search: "foo"}}

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

Альтернатив встроенных нет

@yatoba Спам приехал ^

@yatoba Спам приехал ^

Done

Done

может вопросник при входе в группу ? как думаете?

может вопросник при входе в группу ? как думаете?

Такие вопросы к @dd_bb, но его позиция это как раз то как сделано сейчас

Коллеги, привет! Подскажите пожалуйста, где ошибка(

лишняя закрывающая скобка перед запятой