ищите что с тонелем

а при первичной вставке?

а чем первичная отличается от всего рестора? типа речь про самое начало рестора?

да

я так понимаю что проблема с jubmo чанками у вас возникает сразу после первичной вставки

уже нет логов) надо заново начинать. погляжу когда буду повторять

а значит чанки не смогли поделится при вставке

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

а значит чанки не смогли поделится при вставке

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

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

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

ааа, если у вас есть ситуации когда диапазон уже некуда поделить, то всё объяснимо :)

ааа, если у вас есть ситуации когда диапазон уже некуда поделить, то всё объяснимо :)

да, ситуации есть. даже гигабайт иногда не может поделить...

я имею ввиду ключ сам не делится

ну или не хочет. потому что если руками по одному store_id я делаю сплит - то не уходит в джамбо

т.е. если у вас есть ситуация когда чанк будет равен ровно одному значению account_id:, store_id и туда попадает больше документов, чем размер чанка, то это объясняет ситуацию

ага

тут видно что мельче уже некуда

да, по этому этот чанк уже не разбить

это проблема с выбором ключа

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

только даташтампы

попробовать добавить даташтамп в индекс?

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

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

с п.2 всё будет зависеть от запросов и распределения данных

с п.2 всё будет зависеть от запросов и распределения данных

ну исходя из того что 90% запросов по account_id + store_id+ datetime - нормально?

зависит от

в самом деле вопрос фундаментальный - насколько корректно datetime использовать в ключе шардирования.

в суффиксе смысла особого нет

как мне кажется

в каком суффиксе?

в суффиксе шард ключа

в конце короче :)

типа того что забить на эти джамбы?

распределилось и пофиг?)

нет, это не штатная ситуация и с этим будут проблемы

ну и чанки размером по гигабайту меня смущают тоже

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

и оставшиеся 10% запросов какого рода?

есть ли запросы без account_id/store_id в принцпе?

и оставшиеся 10% запросов какого рода?

ну просто количество посчитать с группировкой по месяцам

есть ли запросы без account_id/store_id в принцпе?

нет, не должно быть

а без store_id?

а без store_id?

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

ну просто количество посчитать с группировкой по месяцам

за всё время?

ну за ~год

врядли дальше ктото полезет

и это очень редкие запросы

тут есть две крайности :)

ок, давайте исходить из того что ВСЕ запросы содержат поля account_id + store_id+ datetime

дата неплохой кандидат, но с ней получается две крайности 1) если поставить её в конец шард ключа, то появится возможность настроить зоны таким образом, чтоб сбалансировать отдельных клиентов/магазины на отдельный шард. это позволит контролитровать «эффект джастина бибера». 2) если поставить в начало ключа, то появится возможность с минимальными затратами поделить на холодные, тёплые и горячие по дате, так как данные со временем теряют свою актуальность и как вы заметили, выбирать архивные данные будут редко и это два взаимоисключающих подхода :)

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

в данном случае это не query tiers, а storage tiers

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

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

как следствие масштабирование будет дешевле

но если придёт толстый клиент то будет грустно :)

разумно, но до такого уровня еще надо дорасти)

но там где «если» это вобщем-то предварительная оптимизация

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

а что именно смущает в datetime?

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

а что именно смущает в datetime?

низкая кардиналити. много разноорбразных значений

в вашем случае это даже хорошо

ну да ну да)

а про то что постоянно будет рубилово, то ничего страшного в принципе в этом нет

а про то что постоянно будет рубилово, то ничего страшного в принципе в этом нет

спасибо, буду пробовать

так как у вас дата не в начале, рубилово вобщем-то будет вполне валидное

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

в смысле магазин с большим потоком чеков

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

это вполне нормально

усредненный шардинг по аккаунту - вполне равномерен

Господа есть разница в перформансе когда в find указывать не все поля а конкретные. Документы довольно большие ~200кб db.collection.find ({id:<id>, weigth{$gte: 500}}) и db.collection.find ({id:<id>, weigth{$gte: 500}},{lastName:1, firstNme:1})

Господа есть разница в перформансе когда в find указывать не все поля а конкретные. Документы довольно большие ~200кб db.collection.find ({id:<id>, weigth{$gte: 500}}) и db.collection.find ({id:<id>, weigth{$gte: 500}},{lastName:1, firstNme:1})

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

Так что зависит от того где ботелнек

Получается, со стороны монги будет больше работы.

Не всегда, но да

Ботлнек диски. Чтение.

На диски не повлияет, так как всё равно документ надо целиком прочитать