Ресурсы для разделения и разбиения базы данных
Я работаю со схемой базы данных, которая сталкивается с проблемами масштабируемости. Одна из таблиц в схеме выросла до примерно 10 миллионов строк, и я изучаю варианты разделения и сегментирования, чтобы позволить этой схеме масштабироваться до гораздо больших наборов данных (скажем, от 1 до 100 миллиардов строк). Наше приложение также должно быть развернуто на нескольких продуктах баз данных, включая, помимо прочего, Oracle, MS SQL Server и MySQL.
В общем, это большая проблема, и я хотел бы узнать, какие варианты доступны. Какие есть ресурсы (книги, технические документы, веб-сайты) для стратегий разделения и разделения баз данных?
4 ответа
Я согласен с другими ответами о том, что вы должны посмотреть на свою схему и индексы, прежде чем прибегать к шардингу. 10 миллионов строк вполне соответствуют возможностям любого из основных движков баз данных.
Однако, если вам нужны ресурсы для изучения предмета шардинга, попробуйте следующее:
Я согласен с замечанием Майка Вудхауса о том, что текущий размер не должен быть проблемой - и тот, кто задает вопрос, соглашается.
Большинство коммерческих СУБД обеспечивают поддержку фрагментированных таблиц в той или иной форме, под одним именем или несколькими другими. Один из ключевых вопросов заключается в том, существует ли разумный способ разделения данных на фрагменты. Один из распространенных способов - сделать это на основе даты, чтобы все значения, скажем, для ноября 2008 года, входили в один фрагмент, значения для октября 2008 года - в другой, и так далее. Это имеет преимущества, когда приходит время удалять старые данные. Вероятно, вы можете удалить фрагмент, содержащий данные за октябрь 2001 года (семь лет хранения данных), не затрагивая другие фрагменты. Этот вид фрагментации также может помочь с "устранением фрагментов"; если запрос явно не должен считывать данные из данного фрагмента, он останется непрочитанным, что может дать вам великолепное преимущество в производительности. (Например, если оптимизатор знает, что запрос предназначен для даты в октябре 2008 года, он будет игнорировать все фрагменты, кроме того, который содержит данные за октябрь 2008 года.)
Существуют и другие методы фрагментации - циклический перебор распределяет нагрузку по нескольким дискам, но означает, что вы не можете извлечь выгоду из удаления фрагментов.
10 миллионов строк действительно невелики с точки зрения СУБД, и я бы сначала посмотрел на мои планы индексирования и запросов, прежде чем начинать планировать физическое распределение данных с использованием сегментов или разделов, что в действительности не требуется, пока ваша таблица не будет увеличена пара порядков величины.
Все ИМХО, конечно.
По моему опыту, большие таблицы всегда бьют вас со стороны ввода / вывода. Самым дешевым решением является добавление достаточного количества многоколоночных индексов, чтобы все ваши запросы могли получать данные непосредственно из индекса, не загружая основные страницы данных. Это делает ваши вставки и обновления более интенсивными, но это может быть нормально. Следующий простой вариант - максимальное использование оперативной памяти на вашем сервере. Нет причин иметь меньше 32 ГБ, если ваша база данных большая. Но, в конце концов, вы все равно окажетесь связанными с вводом / выводом, и вы будете смотреть на покупку большого количества жестких дисков и поддержание сложной схемы разбиения, которая стоит целое состояние между оборудованием и рабочей силой. Я надеюсь, что в наши дни есть лучшая альтернатива - перенести базу данных с вращающихся жестких дисков на твердотельные диски SLC - это должно сделать ваши случайные операции чтения и записи в сто раз быстрее, чем верхние линейные диски SAS, и удалить ввод-вывод горлышко бутылки. Твердотельные накопители стоят от 10 долларов за гигабайт, так что вы потратите несколько штук, но это все же намного дешевле, чем SAN и т. Д.