Он тупой

Он балансирует исключительно по числу чанков

а как тогда решается?

вручную?

Вручную что?

перемещать

ну там moveChunk

Тут общие советы не работают

В общем случае решается уменьшением размера чанков

Но все зависит от шард ключа и документов

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

И паттернов записи. И чтения

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

Ахахахаха. :)

Чанк — запись в коллекции chunks на конфиг сервере

У него считай нет размера.

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

а как монга узнает что пора сплитить чанк?

тоже делает подобные запрсоы7

Там на mongod свой механизм для этого дела

https://github.com/mongodb/mongo/wiki/Sharding-Internals

спасибо почитаю

https://github.com/mongodb/mongo/blob/r3.4.2-rc0/src/mongo/s/chunk_manager.cpp#L270

Сорян, в походу в mongos

Привет. Есть объект с полем location и radius. Хочется вытянуть все такие объекты которые находятся на расстоянии своего radius а от заданной позиции используя геоиндексы. Есть следующая наработка: model.find({ location: { $near: { $geometry: { type: "Point", coordinates: [ -73.9667, 40.78 ] }, $minDistance: 0, $maxDistance: 5000, }, } } Но как задать radius объекта в $maxDistance?

Никак.

А, это не в индексе

"$radius"?

хотя я не уверен что так можно

прикол в том, что надо получить значение radius из документа

как следствие эффективность индекса будет нулевая, так как поиск по индексу будет требовать чтения всех документов

тебе нужно конвернуть координаты + радиус в полигон

и искать по $geoWithin

но afaik в geojs нет возможности задать окружность, так что придётся делать аппроксимацию

В любом случае, ответ: никак :|

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

Парни, кто-то знает редис? Повесил его перед запросом в монгу. Данные успешно кеширует, и если нужного запроса нет, то лезет в монгу. Но проблема - если я обновлю данные в монге, то редис по прежнему возвращает свои значения по этому же ключу, так как думает что у него все есть и не лезет в монгу. Как подцепить сюда логику, чтоб после апдейта монги, данные в редисе тоже обновлялись? Сервер на ноде.

с редисом не работал, но думаю помогут ключевые слова write through

Парни, кто-то знает редис? Повесил его перед запросом в монгу. Данные успешно кеширует, и если нужного запроса нет, то лезет в монгу. Но проблема - если я обновлю данные в монге, то редис по прежнему возвращает свои значения по этому же ключу, так как думает что у него все есть и не лезет в монгу. Как подцепить сюда логику, чтоб после апдейта монги, данные в редисе тоже обновлялись? Сервер на ноде.

После апдейта в монге инвалидируй ключ в редисе

кстати а редис только из приложухи обновлять или там существуют какиенить адаптеры для БД, чтобы как раз делать read/write through?

После апдейта в монге инвалидируй ключ в редисе

This.

кстати а редис только из приложухи обновлять или там существуют какиенить адаптеры для БД, чтобы как раз делать read/write through?

Хоспаде, обнови из приклада, одну строчку добавь )

а консистентность?

между обновлением в кеш и в базе может пройти куча времени

нет готовых решений (насколько я знаю), чтобы к монге прицепить редис вот так по щелчку пальцев

пиши отдельный слой приложения, который рулит кешем

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

После апдейта в монге инвалидируй ключ в редисе

Как это связывать?

Это вне приложения настраивать?

просто я использую ignite в связке с pg и там у меня сделано через адаптер -это дает полноценный read/write through. было интересно узнать есть подобное в редисе

Насчёт инвадидации после апдейта монги. У меня ключ в редисе это роут апи сервера. Непонятно как это с монгой увязать

Т.е. редис кеширует данные которые возвращает сервер. А сервер уже в свою очередь запрашивает из монги

Разве что обнулять, если например будут изменения в коллекции любые например. Ну в принципе ок

Почитаю, спс

Буду благодарен за ссылку по теме

Путаешь http-кеширование с кешированием entity

Из быстрых решений: можешь при апдейте в монге составить такой же ключ (роут) и по нему удалить в редисе

но это костыль, конечно же

А зачем там вообще редис нужен?

А зачем там вообще редис нужен?

ты спрашиваешь зачем он нужен в принципе?

Зачем он в этом случае нужен. В 90% проектов это первое что надо выпиливать.

А зачем там вообще редис нужен?

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

Ну вот придет 1000 человек по этому роуту. Чтоб не лезть в бд каждый раз, отдавать из памяти

...

За тем, что субд для этого и придумана.

Выкинь редис и живи спокойно.

Думаю, что mongo и сам умеет кэшировать в памяти

Но это не точно

в коммерческой версии да.

в коммерческой версии да.

Кэш WT только в коммерческой версии? ?

Кэш WT только в коммерческой версии? ?

:)

Кэш WT?

Кэш WT?

Да.

"Горячая" область кэшируется.

Что да. Я спрашиваю что за хрень)))

Что да. Я спрашиваю что за хрень)))

В движке WiredTiger предусмотрено кэширование. https://docs.mongodb.com/manual/core/wiredtiger/ With WiredTiger, MongoDB utilizes both the WiredTiger internal cache and the filesystem cache. Starting in 3.4, the WiredTiger internal cache, by default, will use the larger of either: 50% of RAM minus 1 GB, or 256 MB.

Этим кэшем нельзя управлять. Нельзя задать eviction policy для объектов. И этот кэш не будет распределенным. Потому мне кажется, что вы не совсем то советуете человеку.

Этим кэшем нельзя управлять. Нельзя задать eviction policy для объектов. И этот кэш не будет распределенным. Потому мне кажется, что вы не совсем то советуете человеку.

Если я правильно понял, он просто запоминает результаты в Redis, чтобы не дёргать базу.

Redis хранит ключи в оперативке.

Кэш WiredTiger - тоже.

То есть по сути это лишняя прослойка получается.

Если задача - просто кэшировать результаты.

Этим кэшем нельзя управлять. Нельзя задать eviction policy для объектов. И этот кэш не будет распределенным. Потому мне кажется, что вы не совсем то советуете человеку.

Человеку советуют не заниматься предварительной оптимизацией. Кешировние — одна из самых сложных задач. Зачем тратить на неё время, если проблемы не существует.