В наличии коллекция справочных данных с 1.6 миллиона записей. В системе есть пользователи, их не миллионы, но тоже достаточно . Каждый пользователь из справочных данных может выбрать несколько "любимых". Надо организовать поиск справочных данных так, чтобы каждый пользователь видел сначала свои "любимые" справочные данные, а потом все остальные.

Навскидку есть пара решений, но все они выглядят весьма корявыми

Поиск - по текстовому полю + гео-поиск с geoJSON

Peter Shved: как в mongodb проверить есть ли значение в массиве пример: { _id : 1, list : [{ num: [4,6] }, { num: [3,8] }, { num: [6,1] }] } делал $filter: { input: '$list', as : 'item', cond : { $eq: ['$$item.num', 3] } } не работает -_-

Я просто проверял существование нулевого элемента

Или речь про вхождение элемента, а не пустой массив?

Тогда $in просто

https://github.com/torodb/torodb

Интересненько

хоть и баян, но в тему

делаю эксплейн агрегацию по дням: db.docs.explain().aggregate({ $group:{ _id:{ year:"$value.meta.year", month:"$value.meta.month", day:"$value.meta.day" }, totalCount:{$sum:1} } }) причем есть индекс { "value.meta.year" : 1, "value.meta.month" : 1, "value.meta.day" : 1 } однако план не использует индекс: { "stages" : [ { "$cursor" : { "query" : {}, "fields" : { "value.meta.day" : 1, "value.meta.month" : 1, "value.meta.year" : 1, "_id" : 0 }, "queryPlanner" : { "plannerVersion" : 1, "namespace" : "mydb.docs", "indexFilterSet" : false, "parsedQuery" : {}, "winningPlan" : { "stage" : "COLLSCAN", "direction" : "forward" }, "rejectedPlans" : [] } } }, { "$group" : { "_id" : { "year" : "$value.meta.year", "month" : "$value.meta.month", "day" : "$value.meta.day" }, "totalCount" : { "$sum" : { "$const" : 1.0 } } } } ], "ok" : 1.0 }

почему не используется индекс?

ещё один

выстрели в лицо тому, кто предложил тебе такой _id

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

1) у _id лимит на 1024 байта 2) индекс на весь _id работате только для ПОЛНОГО ТОЧНОГО СОВПАДЕНИЯ

как и для любого индекса по целиком вложенного документа

такой _id — грубейшая ошибка проектирования

я ещё уверен что там кроме year/month/date ещё поля есть

само собой есть, это же документ. _id у доков монговский

мне же надо агрегацию сделать по данным а не по ключу

так, кажется я ебусь в глаза

да, ебусь. окей!

согласен

сорян ;)

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

я не туда посмотрел

почему не используется индекс?

а почему он должен использоваться?

ну типа же есть покрывающий индекс, в котором ест ьвсе данные

ммм

уже не в первый раз сталкиваюсь и мне не ясна логика монги как она строит планы

1) у тебя там вложенный документ. запросы по вложенным документам не могут быть index-only by design

монге один фиг надо пойти в сторадж и достать весь документ

(по крайней мере до 3.4 так было, в 3.4 не смотрел ещё, но скорее всего ничего не изменилось)

т.е. для нормального использования покрывающего индекса в агрегации мне надо вытащить нужные мне поля на самы верхний уровень дока?

или все еще хуже и только match и sort могут юзать индексы?

или все еще хуже и только match и sort могут юзать индексы?

ещё хуже, да

только $match

afaik sort в AF никак вообще индексы не умеет

но опять-же, данные немного устаревшие, может уже поправили. они в 3.4 нормально там всего починили

печаль

более того, планировщик не все оптимизации может к AF применить

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

в доке всё есть, начни с неё

хоть и баян, но в тему

а что монга так плоха?

а что монга так плоха?

Ты не понял суть.

Ты не понял суть.

не ну я понял что зоопарк непонятно чего

наверное да, таки не понял :)

Это нормально, что я не могу за несколько часов локально поднять службу mongod? Сначала один код ошибки - гуглишь, решаешшь. Затем второй - гуглишь, решаешь. И так пару раз, пока круг не замыкается...

Службу? Виндовс чтоли?

service. Нет, убунту 16.04

Ставится с пакетов на раз

ну это же не постгрес, где всё просто и логично =)

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

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

Место на диске есть? 😄

Вангую банальное неумение читать.

Не могу инициализировать replica set. Добавил в mongod.conf вот это: replication: replSetName: "001-rs". Сейчас выдает вообще 14 ошибку. А вообще я пытаюсь поднять rocket chat

Вангую банальное неумение читать.

короче, забейте :/

рили

А разве не пишется что-то кроме кода ошибки? Это же не венда.

Это нормально, что я не могу за несколько часов локально поднять службу mongod? Сначала один код ошибки - гуглишь, решаешшь. Затем второй - гуглишь, решаешь. И так пару раз, пока круг не замыкается...

Ни разу за весь опыт его не поднимал - он у меня никогда не работает.

Запускаю сам через mongod с параметрами.

У меня все серверы на Debian, так что есть вероятность, что с сервисом из пакетов в Ubuntu тоже что-то не так.

У меня все серверы на Debian, так что есть вероятность, что с сервисом из пакетов в Ubuntu тоже что-то не так.

Пакеты из реп монги или дебиана? Или вообще самосборные?

Пакеты из реп монги или дебиана? Или вообще самосборные?

apt-get

Никогда из репотиториев не вставал нормально.

apt-get

Это не ответ на мой вопрос

Это не ответ на мой вопрос

Прости, проглядел.

Репозитории MongoDB всегда подключал.

Странно, с ними никогда проблем не замечал. Если только они не ставились поверх стандартных из реп debian/ubuntu, тогда может быть все что угодно.

а канал по redis есть?

где почитать как корректно поднять кластер из трех нод на 2.6 ?

где почитать как корректно поднять кластер из трех нод на 2.6 ?

на 2.6 не надо ничего делать уже

всё что нужно сделать — обновить до 3.4

это к сожалению не в моей компетенции

Не повезло.

это к сожалению не в моей компетенции

может не в твоих полномочиях? иначе звучит очень самокритично

это к сожалению не в моей компетенции

тебе репликасет нужен?

в любом случае, вот тебе ссылка: https://docs.mongodb.com/v2.6/tutorial/deploy-replica-set/

но на 2.6 ты там наешься по мелочи. особенно с wt