Ресурсы для сегментирования и разбиения базы данных

10 миллионов строк - это действительно мало с точки зрения СУБД, и я бы сначала посмотрел на свои планы индексирования и запросов, прежде чем начинать планировать физическое распределение данных с шардами или разделами, что на самом деле не должно быть необходимо, пока ваша таблица не вырастет пара порядков.

Все ИМХО, конечно.

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

Большинство коммерческих СУБД обеспечивают поддержку фрагментированных таблиц в том или ином виде под одним или несколькими другими именами. Один из ключевых вопросов - есть ли разумный способ разбить данные на фрагменты. Один из распространенных способов - сделать это на основе даты, так что все значения, скажем, для ноября 2008 г. помещаются в один фрагмент, значения для октября 2008 г. - в другой и т. д. Это дает преимущества, когда приходит время удалять старые данные. Вероятно, вы можете отбросить фрагмент, содержащий данные за октябрь 2001 г. (семилетний срок хранения данных), не затрагивая другие фрагменты. Такая фрагментация также может помочь с «удалением фрагментов»; если для запроса явно не требуется считывать данные из данного фрагмента, он останется непрочитанным, что может дать вам великолепный выигрыш в производительности. (Например, если оптимизатор знает, что запрос относится к дате в октябре 2008 г., он проигнорирует все фрагменты, кроме того, который содержит данные за октябрь 2008 г.)

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

По моему опыту, большие таблицы всегда поражают вас со стороны ввода-вывода. Самое дешевое решение - добавить достаточное количество индексов с несколькими столбцами, чтобы все ваши запросы могли получать данные непосредственно из индекса без необходимости загружать основные страницы данных. Это делает ваши вставки и обновления более интенсивными, но это может быть нормально. Следующий простой вариант - максимально увеличить объем оперативной памяти на вашем сервере. Нет причин иметь меньше 32 ГБ, если ваша база данных большая. Но, в конце концов, вы все равно столкнетесь с ограничениями ввода-вывода, и вам придется покупать много жестких дисков и поддерживать сложную схему разбиения на разделы, что стоит целого состояния между оборудованием и рабочей силой. Я надеюсь, что в наши дни есть лучшая альтернатива - переместить базу данных с вращающихся жестких дисков на твердотельные диски SLC - это должно сделать ваши случайные чтения и записи в сто раз быстрее, чем у лучших дисков SAS, и удалить ввод-вывод. горлышко бутылки. Твердотельные накопители начинаются с 10 долларов за гигабайт, поэтому вы собираетесь потратить несколько тысяч, но это все равно намного дешевле, чем SAN и т. д.

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

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

• Рекомендации по масштабированию: уроки eBay
• Рэнди Шуп о принципах архитектуры eBay - видео и презентация
• Сайт с высокой масштабируемостью
• Мистер Мур приступает к шардингу (когда этого не следует делать)