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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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