В чем польза шардирования БД при наличии индексов?

Question

[footballer]

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

Если у нас таблица в миллионы записей и для поиска в ней конкретных данных конкретного пользователя мы делаем перебор всех данных всех пользователей (если нет индексов), то да - разбиение таблицы и хранение данных для каждого отдельного пользователя на разных серверах имеет смысл. Но если у нас есть индексы по полю-идентификатору пользователя (а индексы в больших таблицах есть всегда), то мы итак не будем перебирать все данные всех пользователей - тогда чем такое раздельное хранение данных на разных серверах для каждого пользователя нам помогает?
Разве что при апдейте\инсерте данных для одного пользователя нам нужно обновить индекс данных только этого пользователя, а не общий индекс для всех (но и тут не очевиден выигрыш - т.к. хоть индекс стал меньше и обновляется быстрее, зато при каждом запросе нам нужно дополнительно разруливать, с какого шарда брать данные для данного юзера).
В общем, в чем конкретно выигрыш от шардирования?

Answer 1

[Melkij]

Пока у вас всего лишь миллионы записей - то вам ни шардирование ни даже партицирование не нужно.

В общем, в чем конкретно выигрыш от шардирования?

Масштабирование операций записи когда более производительные диски и уже не поставить.

Answer 2

[Иван Шумов]

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

Answer 3

[Vitsliputsli]

В общем, в чем конкретно выигрыш от шардирования?

Шардирование не предназначено для ускорения доступа к данным, поэтому нет смысла сравнивать с индексами, во всяком случае не в таком контексте как вы описали. Шаридирование - это вариант горизонтального масштабирования. Когда вы не сможете больше увеличивать мощность одного сервера СУБД под возросшие потребности, то придется задуматься о нескольких серверах СУБД, т.е. о горизонтальном масштабировании, а шардирование один из его вариантов.

Comments

[footballer]

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

[Vitsliputsli]

footballer, смотря какую проблему таким образом решали и как решали. Вероятнее всего таким образом распределяли нагрузку на несколько СУБД, т.к. одна уже не справлялась. Таким образом СУБД разгружается и сможет отвечать быстрее. В таком контексте да, но не в том контексте, что заменяем индексы на шарды и получаем больший выигрыш. Т.е. индексы позволяют СУБД перелопачивать меньше данных по запросу, а шарды позволяют распределить нагрузку на несколько серверов - это совсем разные направления.

Answer 4

[Владимир Коротенко]

Допустим у вас диск в 100 гигабайт

Данные пользователя 1 мегабайт

Итого 102400 пользователя. Куда будем девать остальных?

Answer 5

[unfilled]

к выше сказанному можно добавить, что шардирование уместно использовать, когда вы данные пользователей из России должны хранить в России, а данные пользователей ЕС в ЕС, например. Кроме того, шардирование может быть полезно в плане общей "устойчивости" системы - отвалился шард - большая часть пользователей остаётся доступной.
Т.е. шардирование - это больше не про скорость доступа к данным, а про управление ими.