чанк это просто диапазон твоего shard key. это само по себе не является данными!

зачем ? будь носителем уникального знания ;)

больше людей знают про шардинг, больше данных, чаще нужен я!

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

шучу конеш

так все-таки, для разделения записи на разные шарды уместнее использовать условный client_id. Правильно я понимаю?

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

эта числовая прямая начинает разбиваться на отрезки при выполнении определённого условия (превышение предела размера чанка)

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

у отрезка есть «место» где он хранится

вот этот отрезок и есть чанк

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

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

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

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

теперь простая математика

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

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

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

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

но нужно понимать что ключ просто их client_id — опасен

у тебя может получится так, что у какого-то клиента так много данных, что в итоге у тебя чанк будет состоять из 1 значения client_id

и будет джомбо чанк

так как числа натуральные, монга не сможет условный 4242 поделить на (4241.0, 4241.5], [4242.5, 4243)

или наоборот скобки, не помню уже

плюс толку это иметь не будет, потому что у тебя айдишник один

так что выбирать ключ надо исходя из этих ограничений

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

и уже от этого будет зависеть выбор шрад-ключа

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

нет

не надо крутить размер чанка

нужно ключ выбирать нормальный

например {client_id, date}

а..то есть можно сделать составной?

можно

это уже лучше

но это требует изменения сознания. потому что у тебя получается отрезок внутри которого ещё один отрезок

на одно значение client_id у тебя будет уникальный диапазон date

у этого есть очень большой downside: операционная сложность

мне понравилось у Zalando как делиться по шардам. побитово.

там правд не монга :)

так. и какие от этого последствия? что принесет с собой операционная сложность?

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

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

третья сложность: невозможно делать некоторые вещи

например в 90% случаев нужность данных падает во времени

т.е. держать все данные на дорогом железе — бессмыслено

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

с {client_id, date} этого не сделать

а с {date, client_id} у тебя получается монотонно возрастающий ключ

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

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

не надо чтоб он менялся

в смысле с позиции бизнес-логики это так себе решение

ну и я про то же...

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

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

как теги обновлять и вот это всё

так. хорошо. А все-таки, если clien_id будет меняться, возрастая, раз скажем в какой-то период, то тогда такая проблема как минималный диапазон 4241-4241 уходит? так же?

нет, не уходит

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

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

нужно либо делать составной ключ, либо делать свой собственный

например текстовый

правда с текстовым ключом с дапазонами вообще тяжко будет

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

ну вот сколько данных можешь создать один клиент

можно ли взять ещё какое поле для того чтоб сделать по нему compound key

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

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

ну вот видишь, «за год»

всё, алес, включайте дату в ключ

либо конечно не дату, а не знаю, какую-то ещё пежню

просто номер какой-то

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

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

Встречал рекомендации делать шардкей самому.

И писать готовым

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

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

вопрос что ты потом с этими данными делать собираешься

с этого надо начинать всегда

а jombo чанк уже никуда не поедет? он не балансируется?

в чем как бы проблема jombo чанка?

нет, не поедет

во всём

понятно. то есть их не должно быть...

да, потому что они всю идею шардинга на нет сводят

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

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

не бывает идеального поля для всех

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

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

вот например как выглядит неравномерное распредление чанков при записи. сначала всё шло хорошо (слева ровно) и данные равномерно попадали на разные шарды. а потом вылезло говно, которое называется «алгоритм балансировки» и из-за того что балансировщик тупой, данные начали попадать чаще на одни шарды, чем на другие https://yopp.in/13lg

и вот так вот просела производительность кластера на вставку https://yopp.in/13mZ

на графике сети пики это примерно 300мбит/с

кстати, можно иначе посмотреть

а у меня на каждый инсерт еще четыре апдейта приходит

а какой у тебя iowait на такую запись?