)))

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

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

потому что на условном 1 гигабайте отлаживать быстрее чем на десятке терабайт %)

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

это и есть срез)))

а зачем его тогда назад сливать?

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

есть коллекция дохера большая (9млрд доков/12Тб/4шарда) решил выделить горячий сет в отдельную коллекцию (50млн/70Гб/4шарда) , попереливал часть данных. прошло полторы недели, чекаю каунтеры по базе и вот наткнулся

есть коллекция дохера большая (9млрд доков/12Тб/4шарда) решил выделить горячий сет в отдельную коллекцию (50млн/70Гб/4шарда) , попереливал часть данных. прошло полторы недели, чекаю каунтеры по базе и вот наткнулся

просто интересно. На обычных дисках лежит такая коллекция или на ssd? и сколько у нее insert, update?

на каждом шарде raid10 из обычных, 1500рпс не напрягаясь на кластер

есть коллекция дохера большая (9млрд доков/12Тб/4шарда) решил выделить горячий сет в отдельную коллекцию (50млн/70Гб/4шарда) , попереливал часть данных. прошло полторы недели, чекаю каунтеры по базе и вот наткнулся

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

зоны же есть

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

в ключе даты нет?

нет

а что в ключе есть?

некоторый индентификатор устройства

с которого идут доки

и всё?

да

пойти от обратного и выселить холодные устройства? :)

все горячие

поэтмоу и зоны не подходят

нет повести печальнее

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

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

а в чём проблема? date: { gte: MinKey, lte: MaxKey }

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

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

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

вот и у нас похожая ситуация 10 млрд 4 шарда, все в одно коллекции и ключ не позволяет дробить. и тоже идентификатор устройства

если тоже временные ряды, то вот выше

к сожалению иначе hot/cold будет сложно сделать

так можно по дате сделать зоны

и подкручивать их постепенно

у временных рядов обычно время является самым весомым аргументом в пользу «горячести»

уникальный ключ ID-K-N. id - постоянно, k меняется периодически, n номер докав пределах id-k если я делаю шард ключ ID-DATE и часть данных улетает в другую зону, то монга нормально сможет выбрать по связке ID-K-N ?

если дата в постфиксе то балансировку по дате не сделать

вот это и остановило меня

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

а какой порядок устройств?

200к

20кк событий в сутки

а что переделать?

все)

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

ну если есть возможность шард-ключ поменять, то ключ типаа {time: 1, k: 1, n: 1}

у вас горячие последние N дней?

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

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

а если ошибок нет?

то полчаса-час

т.е. горячие всего 1.6м документов?

гдето так

а какой read:write рейт?

документ прилетел и всё? или он может обновляться?

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

т.е. по сути документы потом никак не используются?

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

да

hot/warm/cold

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

дату в префикс, в постфикс какие-то нормально распределённые айдишники

которые в запросах учавствуют

cold всё что больше месяца

в hot последние несколько часов

в warm пока есть ошибки

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

:)

:)

rs3 : { "rs0" : 0, "rs3" : 73568 }

вот это "rs0" : 0 меня беспокоит, как монге сказат ьчто все ок и ей нужно дропнуть инфу

это что значит вообще?

$unset если я правильно понял что нужно

количество доков на шардах, db.runCommand({count: "aaa",

это что значит вообще?

{ "shards": { "rs2": 0, "rs3": 70119 }, "n": 70119, "ok": 1 } вот так наверное понятнее будет

тебя беспокоит что 70к документов осталось?

наоборот, что в rs2 0, т.к. данный чанк должен быть полностью на rs3

я взял count по диапазону чанка

походу понял это бага монги, она почемуто игнорит то что в $lt передается верхняя граница и она не должна включатсья в поиск

натравил балансер на эту коллекцию в логах появилась такая дичь mongod: SHARDING [conn273068] Refreshing chunks for collection docs_hot based on version 584|232||5bab860e1195cf944681375d mongod: SHARDING [CatalogCacheLoader-4511] Refresh for collection docs_hot took 3 ms and found version 584|232||5bab860e1195cf944681375d mongod: SHARDING [conn273068] can't accept new chunks because there are still 840 deletes from previous migration

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

сам сталкивался не единожды и, как обычно, очень невовремя :)

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

а как можно в монго искать сразу по 2+ коллекциям? не по связанным сущностям, а просто независимые коллекции. и там и там есть допустим поле "name" и вот по ним искать. киньте пример или ссылку в доку)

два запроса сделать

ну а если это поиск в приложении с пагинацией, то склеивать их руками?

да

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

просто на UI текстовое поле, в котором можно найти несколько типов сущностей (представленные разными коллекциями), допустим, кредит, вклад, и.т.д.

тогда да, руками склеивать

ну или сделать ещё одну коллекцию, куда складывать что-то по чему ищут и ссылку на документ

но это уже попытка поисковый движок переизобрести

просто на UI текстовое поле, в котором можно найти несколько типов сущностей (представленные разными коллекциями), допустим, кредит, вклад, и.т.д.

Или определить тип перед запросом в БД

ребята питонисты, кто пользовался асинхронным драйвером для монги??? вот нашел мотор https://github.com/mongodb/motor или мб другой посоветуете?\

ребята питонисты, кто пользовался асинхронным драйвером для монги??? вот нашел мотор https://github.com/mongodb/motor или мб другой посоветуете?\

Тут не только питонисты, не сразу понял, что речь про питон =)

Тут не только питонисты, не сразу понял, что речь про питон =)

да, сори)) ща поменяю))