Шардирование баз данных: проблемы, альтернативы, практические рекомендации

[cordova07]

Единственное, чего не хватило это схем и визуализаций. Даже простая диаграмма hash ring или lookup table помогла бы новичкам. Было бы интересно почитать продолжение например, кейсы из реальных проектов или сравнение инструментов типо Vitess, ShardingSphere, Spanner и т. д. Спасибо, крутая работа!

[fo_otman]

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

[mirwide]

или покупки сервера помощнее уже не помогают (или стоят как крыло от самолета)

Мне кажется, этот подход уже немного устарел. Благодаря AMD и чиплетам, больше нет экспоненциального роста цены процессора при увеличении количества ядер. В некоторых случаях CPU с большим количеством ядер даже дешевле в пересчете на ядро и производительность.

Если БД хватает 200-300 ядер и пропускной способности памяти одного сервера, экономически шардировать не имеет смысла.

Накидывал по Zen 4, цены не актуальные, но суть понятна

[dyadyaSerezha]

экономически шардировать не имеет смысла.

Так не об этом ли дважды упоминается в статье? С кем вы спорите?

[mirwide]

Иногда комментарии это дополнение, а не спор

[dyadyaSerezha]

Вы видите слово "устарел" в самом начале? А в результате утверждается ровно то же самое, что и в статье.

[mirwide]

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

[dyadyaSerezha]

"или стоит, как крыло". Слово "или" видите?

[titan_pc]

Статья полезная +-. Не хватило объяснения сути и принципиальной разницы между шардом и репликой. Что реплика, что шард требуют дополнительных мощностей. Реплика может решить добрую половину если не больше проблем с перегрузками. И конечно же есть то самое, когда пора делать шарды. Когда реплика уже не помогает. И оно там что-то наверное связано с объёмом хранимых данных и упором на дисковую память, которая не бесконечна.

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

Что шарды - это про хранение как таковое. И в первую очередь про запись данных. А масштабировать чтение через шарды - это как раз экзотика в виде геораспределенки. Потому что, когда мне хватает диска - я отмасштабирую чтение репликами и буду прав. Если у меня данные вмещаются на 1 nvme диск - шардить смысла особого нет. Преимущества перед репликами не будет. Шило на мыло.

Другая сторона - у меня перекос операций записи не знаю ×10 по отношению к чтению. Тогда я сразу беру шардинг, потому что балансировка операций записи в разные диски/шарды будет работать быстрее. И себя окупит. А вот реплика в этом случае будет замедлять систему.

Вобщем я отчасти согласен с Вашим рецептом про индексы и другие способы оптимизации чтения. Но Шарды это всегда больше про оптимизацию записи и увеличение общего объёма хранилища, чем про оптимизацию чтения. Да, через шардинг можно и чтение оптимизировать, но опять же жертвуя железки на этот самый шардинг. То есть не оптимизировать, а масштабировать горизонтально. При условии что мы точно не ошиблись и не воткнули шард туда, где была нужна реплика. А ещё как Вы правильно сказали надо с ключём и функцией шардирования не ошибиться.

Но всё же в первую очередь выбор шардить или нет он начинается не с того, что нам индексов не хватает. А с того, какой объём данных мы собрались хранить. И с того какое у нас соотношение между чтением и записью. Если мы 100 раз в секунду пишем и 1 раз в минуту читаем - то мы будем шардить сразу. Реплицировать тоже будем, но чисто для обеспечения отказоустойчивости. Чтение там будет уже на вторых, если не третьих ролях