Жестко)

но вообще, к вашему фреймворку скорее всего уже что-то есть

монгоид точно умеет в локализацию

он использует title.<lang>

Вот такая штучка подойдет? https://www.npmjs.com/package/mongoose-intl

Или есть другие предложения?

¯\_(ツ)_/¯

ищите где больше звёздочек и активности

у меня от js дергается веко, я его терпеть не могу

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

Ну вот надо как-то это говницо в vuejs связать)

Так, по посчитать длину всех всех массивов в документах?

это совсем совсем плохая идея

вероятно через агрегацию, $objectToArray и потом $unwind и потом $group

сложно, медленно, много памяти

но я не уверен что $ROOT можно размотать, хотя может быть и можно

Ох ты...

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

если аттрибуты с массивами известны, то проще

Возвращаясь ко вчерашнему вопросу. Запрос: { '$expr': { '$gt': [ '$following', $divide: ['$followers', 2] ] }, parsed: true, taskIds: 5c278ce501d652520a7243c8 } В результат прилетают документы даже с такими данными: followers: 80 following: 69 Таким образом запрос не возвращает мне following в два раза больше чем followers, а возвращает странности. В чем дело?

Парни, такой вопрос. Допустим есть коллекция с индексом: db.coll.createIndex({a: 1, b:1, c:1, d: 1) Если я буду делать запрос: db.coll.find({a:1337, c:322, d: 2019}) Индекс будет фильтровать по полям c и d ? Или мне нужно писать так: db.coll.find({a:1337, b: {$gt: -2147483648}, c:322, d: 2019})

Парни, такой вопрос. Допустим есть коллекция с индексом: db.coll.createIndex({a: 1, b:1, c:1, d: 1) Если я буду делать запрос: db.coll.find({a:1337, c:322, d: 2019}) Индекс будет фильтровать по полям c и d ? Или мне нужно писать так: db.coll.find({a:1337, b: {$gt: -2147483648}, c:322, d: 2019})

может лучше без италика?

Возвращаясь ко вчерашнему вопросу. Запрос: { '$expr': { '$gt': [ '$following', $divide: ['$followers', 2] ] }, parsed: true, taskIds: 5c278ce501d652520a7243c8 } В результат прилетают документы даже с такими данными: followers: 80 following: 69 Таким образом запрос не возвращает мне following в два раза больше чем followers, а возвращает странности. В чем дело?

пока нет вариантов ни у кого? :(

пока нет вариантов ни у кого? :(

вы дайте пример данных

а каких. я же дал :(

просто Int32 два поля

у меня ничего не работает меня ругает заказчик и я плачу ;(

Парни, такой вопрос. Допустим есть коллекция с индексом: db.coll.createIndex({a: 1, b:1, c:1, d: 1) Если я буду делать запрос: db.coll.find({a:1337, c:322, d: 2019}) Индекс будет фильтровать по полям c и d ? Или мне нужно писать так: db.coll.find({a:1337, b: {$gt: -2147483648}, c:322, d: 2019})

не будет, у вас пропущен один из суфиксов. используя $gt будет получше, но всё равно будет не очень эффективно

если b опционально, то его лучше поставить в конец индекса

если b опционально, то его лучше поставить в конец индекса

В том и дело, что обычно нужно использовать все поля db.coll.find({a:1337, b:1073, c:322, d: 2019}) Но иногда нужно делать запрос без поля b: db.coll.find({a:1337, c:322, d: 2019}) Вот и подумал, что монга достаточно умна, чтобы подобрать индек сама, без написания костыля типа b:any

если вам нужно делать запрос без поля b, то поставьте его в конец

композитные индексы проще всего представить как матрешку

каждый уровень вложен в предыдущий

если вы пропускаете уровень, то вам надо обходить все вложенные матрешки

порядок полей в запросе не влияет на использование индекса. влияет состав полей

вы дайте пример данных

пример данных following 1000 followers 500 и following 500 followers 500 первый пример должен попасть в мой запрос, второй нет, то есть только те документы где подписок в 2 раза больше чем подписчиков

пример данных following 1000 followers 500 и following 500 followers 500 первый пример должен попасть в мой запрос, второй нет, то есть только те документы где подписок в 2 раза больше чем подписчиков

aggregate([ { $project: { ratio: { "$divide": ["$followers", 2] }, following: 1, match: { "$gt": [ "$following", "$ratio"] } } } ]

и отлаживайте тут

я не использовал aggregate, а использовал только начинку от него?

и просто ничего не отрабатывало?

$expr это AF в find

вы можете отлаживать запросы через aggregate

понял хорошо спасибо

порядок полей в запросе не влияет на использование индекса. влияет состав полей

Понял, спасибо

под «поставьте в конец» я имел ввиду в индексе

порядок полей при создании индекса очень важен. лучше пытаться делать порядок «уточнения», когда в каждый следующий уровень попадает меньше документов чем в предыдущий

например даты, очень часто, имеет смысл ставить первым полем

под «поставьте в конец» я имел ввиду в индексе

Ага, понял. Я вопрос неверно задал. Вернее ситуацию описал. > лучше пытаться делать порядок «уточнения», когда в каждый следующий уровень попадает меньше документов чем в предыдущий Я вот как раз об этом Скажем ситуация такая: Выборка на поле c огромная. Поэтому добовляется поле b как доп фильтр db.coll.find({a:1337, b:1073, c:322}) т.е. индекс a:1, c:1, b:1 будет неверный (b должен идти вторым, т.к. он отсекает большую часть лишних записей) Поэтому нужен индекс a:1, b:1, c:1 Но иногда поле b пустое и приходится делать запрос только по полю c db.coll.find({a:1337, с:322}) В этом случае какие у меня варианты? Я вижу только: а) Создать 2 индекса a:1,b:1,c:1 и a:1, c:1,b:1 б) При запросе мокать поле b чтобы заюзался нужнай индекс: db.coll.find({a:1337, b:any, с:322})

да, правильно видите варианты

какой размер коллекци?

есть ещё третий вариант: не делать compound индекса

сделать 4 отдельных индекса. монга умеет в пересечение

какой из вариантов выбрать покажет только тестовый стол

какой размер коллекци?

А бог его знает. Пару миллионов записей. А индекс там не из трех полей, а из 5 и поля не маленькие (что делает его огромным и в память не влазит) > сделать 4 отдельных индекса. монга умеет в пересечение Вот это интересно. Она сделает 3 запроса по a, b, c и замержит результаты ? Нужно почитать подробнее, не знал о таком

делаете список целевых запросов, составляете требования по QoS запросов и извлекаете из них список измерямых метрик, пробуете разные варианты, замеряете, сравниваете метрики

https://docs.mongodb.com/manual/core/index-intersection/

А бог его знает. Пару миллионов записей. А индекс там не из трех полей, а из 5 и поля не маленькие (что делает его огромным и в память не влазит) > сделать 4 отдельных индекса. монга умеет в пересечение Вот это интересно. Она сделает 3 запроса по a, b, c и замержит результаты ? Нужно почитать подробнее, не знал о таком

примерно, да. будет scan по bounds каждого из индексов и потом будут выбраны пересекающиеся документы,

но понять какая из стратегий будет эффективнее можно только эксперементально

примерно, да. будет scan по bounds каждого из индексов и потом будут выбраны пересекающиеся документы,

Спасибо. Вообще интересно, почему она умеет такие штуки, а скипнуть поле в индексе не умеет. Тоже должен быть ответ где-то

ох

потому что вы неверно себе представляете compound index

условно, если у вас индекс [a,b,c] на деле его можно представить как один большой индекс в котором поля смержены последовательно: a/b/c

т.е. если у вас есть три документа {a: 1, b: A, c: Z }, {a: 1, b: B, c: B } {a: 1, b: B, c: Z } то у вас будет три записи 1/A/Z 1/B/B 1/B/Z

и как вы тут «пропустите» середину? :)

в индексах нет никакого волшебства, особенно в монге. монга это key/value на стероидах

представьте что коллекция это key/value, где ключ _id. а индексы это дополнительные key/value где key это индексируемое поле, а постфикс это _id

и всё что вы можете делать это set/get/scan(range)/delete

query bound задают scan range

Тут другое, теперь вижу. Если будет {a: 1, b: any, c: 'Z'}, то не важно, индекс {a:1,b:1,c:1} или просто {a:1}. По полям 'b' и 'c' уже фильтровать не будет

если поля нет в индексе и условие не AND по этому полю с другим из индекса, то запрос и так не может быть выполнен только по индексу

т.е. индекс {a: 1} не может покрыть поля b и с :)

если у вас логическое И с полем a, то монга может сначала выбрать по индексу, а потом уже перебирать оставшиеся документы

т.е. индекс {a: 1} не может покрыть поля b и с :)

я про то, что когда я установил b: any (любое значение) в запросе {a: 1, b: any, c: 'Z'}, мой индекс {a:1, b:1, c:1} превратился для меня в {a:1}, так ?

any надо ментально заменить на [MinKey, MaxKey] и сразу станет понятно

у вас запрос останется по индексу, но внутри всех найденных a у вас будет полное сканирование постфиксов

a b c 1/A/a 1/B/b 2/A/a 2/B/a 2/C/b 3/B/Z вы знаете что a=2, но не знаете b и знаете что c = a

я про то, что когда я установил b: any (любое значение) в запросе {a: 1, b: any, c: 'Z'}, мой индекс {a:1, b:1, c:1} превратился для меня в {a:1}, так ?

да просто сипользуйте explain и увидите используется индекс или нет и если да то какой диапазон убдет

т.е. в этом случае запрос выглядит как a = 2, b = [MinKey, MaxKey], c = a a =2 оставит нам вот эту часть «дерева» 2/A/a 2/B/a 2/C/b так как b неизвестно, то монга будет сканировать все эти _ключи_

не документы

Ага, понял. Спасибо, как всегда помогли тут Пашол чекать квери... Тэк, где там мой .explain(true) ?)