Ресурсы для разделения и разбиения базы данных

Question

Я работаю со схемой базы данных, которая сталкивается с проблемами масштабируемости. Одна из таблиц в схеме выросла до примерно 10 миллионов строк, и я изучаю варианты разделения и разбиения, чтобы позволить этой схеме масштабироваться до гораздо больших наборов данных (скажем, от 1 до 100 миллиардов строк). Наше приложение также должно быть развернуто на нескольких продуктах баз данных, включая, помимо прочего, Oracle, MS SQL Server и MySQL.

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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