Особенности масштабирования базы данных
Я заполнил приложение и исследовал среду размещения для его развертывания. Приложение довольно интенсивно обрабатывает запросы, большинство страниц моего приложения имеют несколько запросов с несколькими объединениями, а также триггеры для большинства таблиц. Пока база данных имеет достаточно оперативной памяти для пула буферов, я предполагаю, что производительность должна быть хорошей, поэтому, если я использую VPS-хост, такой как Linode, я могу просто обновить мой сервер, чтобы в базе данных было достаточно оперативной памяти. Меня беспокоит то, что происходит, когда я не могу получить больше оперативной памяти, насколько страдает производительность, когда в базе данных недостаточно оперативной памяти? Стоит ли смотреть на уменьшающуюся свободную память, как на бомбу замедленного действия? Меняет ли СУБД свои методы кэширования, чтобы по возможности избегать доступа к диску? По сути, я хочу знать, каковы умные СУБД и как они справляются до использования шардинга или репликации.
3 ответа
Позвольте мне добавить к Womble - и как кто-то, кто только что закончил работать над проектом с нетривиальной базой данных размером 21000 ГБ...... У вас есть 2 фундаментальных вопроса, которые вы должны понять.
ОЗУ относительно. Современный сервер для правильной базы данных имеет 256 и более гигабайт. VPS даже не показывается как "настоящий сервер базы данных" в этом мире.
Скорость диска также относительна. Я использую систему дома, которую вы, вероятно, считаете чрезвычайно мощной - 2 SSD, 8 Velociraptors только для данных, чтобы получить надлежащие бюджеты ввода-вывода для данных - но в моем мире это даже не появляется - последняя система, над которой я работал, имела 3 узла хранения данных каждый с флэш-памятью 768 ГБ для буфера ввода-вывода и доставляли больше данных в случайном порядке ввода-вывода, чем вы получаете последовательно с ваших дисков.
По сути, ОЗУ может быть добавлено гораздо больше, чем вы думаете, а затем в какой-то момент вы садитесь и разрабатываете СЕРВЕР базы данных, оптимизированный для ввода-вывода. Достаточно интересно, что сегодня не хватает одного элемента, где все, что виртуализация решает все проблемы и приносит мировую известность, состоит в том, что серверы баз данных связаны с вводом-выводом, и это решаемая проблема для части. Просто ожидайте получить большой касс с тоннами дисков или на самом деле SSD в эти дни. Ничто не приходит бесплатно, но это фундаментальная проблема, которую нельзя избежать, и она решаема. Это одна из причин, по которой вы можете получить хорошие 4U стойки от SUperMicro, которые содержат 72 слота для дисков. Это одна из причин, по которой SAS был разработан. Это одна из причин, по которой SSD очень нравятся для баз данных - они примерно в 100 раз быстрее (или больше), чем жесткие диски, когда говорят о вводе-выводе в секунду.
VPS просто не ходят туда;)
Меняет ли СУБД свои методы кэширования, чтобы по возможности избегать доступа к диску?
Нет. Потому что это ЕДИНСТВЕННАЯ (!) Разумная техника кеширования, с которой нужно начинать. Любая подходящая база данных в более широком мире (SQL Server, DB2, Oracle) старается использовать память, чтобы максимально избежать ввода-вывода. Читайте блоги по SQL, и многие не слишком опытные люди всегда жалуются, что SQL Server начинает использовать слишком много памяти - конечно, потому что память есть, и он пытается кэшировать как можно больше.
Это также одна из причин, по которой база данных использует журналы транзакций - это означает, что изменения в базе данных не должны записываться СЕЙЧАС, но запись может быть отложена при сохранении обновлений в журнале передачи и, следовательно, сохранении в случае сбоя.
Опять же, это "решенная проблема". У Oracle есть аппаратное обеспечение, которое идет туда - наша установка на 21000 ГБ использовала Oracel ExaData, и это была САМАЯ МАЛЕНЬКАЯ НАСТРОЙКА, КОТОРАЯ ПРОДАВАЛА
Программы, в общем, так же умны, как они запрограммированы. СУБД - это программы. Поэтому, не зная, какую СУБД вы используете, в общем, невозможно сказать, что произойдет. Таким образом, единственный правильный ответ на ваш вопрос - это голосование "не реальный вопрос" (что, я заметил, кто-то уже сделал). Однако у меня есть немного свободного времени, поэтому я напишу общую статью о масштабировании и производительности базы данных, в надежде, что это ответит на вопрос, который вы должны задать.
Поскольку вы используете термин "СУБД, который не является действительно модным", я предполагаю, что вы используете реляционную базу данных "не очень модный и более", и там все становится сложнее. Обе системы, с которыми я знаком (MySQL и PostgreSQL), имеют по миллиону ручек, сообщающих системе, какой объем ОЗУ использовать - кеширование различных вещей, рабочий набор памяти, буферы... все это очень весело. Соответствующая настройка для рабочей нагрузки и доступных системных ресурсов в основном (хотя и не полностью) сводится к сокращению дискового ввода-вывода, поскольку обычно (хотя, опять-таки, не всегда) это самый медленный и наиболее вероятный причиной узкого места компонент в физической системе.
Таким образом, когда вы не сможете увеличить объем ОЗУ дальше, ваша производительность начнет снижаться (надеюсь, постепенно), поскольку для выполнения большего количества запросов требуется больше обращений к диску. Снижение производительности при увеличении размера базы данных будет усугубляться тем, насколько низкая производительность дискового ввода-вывода.
Учитывая, насколько сложно горизонтальное масштабирование реляционной базы данных (это не невозможно, но это намного сложнее, чем горизонтальное масштабирование веб-интерфейсов), если вы намерены делать вещи в масштабе, вам нужен поставщик, который может дать вам большие машины - много оперативной памяти, но также много процессора, дискового пространства и IOPS. Кажется, самая большая виртуальная машина Linode имеет 20 ГБ, что слишком мало. В AWS есть экземпляры с объемом до 70 ГБ ОЗУ, что лучше, но когда вы можете получить физическую машину с ТБ (или более) ОЗУ... это все еще не очень умно.
Дело не в том, что виртуальная машина всегда не подходит для сервера базы данных, но в какой-то момент, когда вы перерастаете доступные параметры виртуальной машины, вам необходимо знать, что вы собираетесь делать дальше. Все чаще люди идут по пути "осколок рано, осколок часто", потому что если вы собираетесь в массовом масштабе, на Земле нет физической машины, которая вас спасет, а это значит, что вы можете бегать на чем угодно. Динки-игрушечное облако тебе нравится. Тем не менее, шардинг - это большая работа для правильного выполнения, и он несколько ограничивает ваши возможности в том, как вы моделируете свои данные и взаимодействуете с ними, поэтому я хотел бы избежать этого, если смогу. Дело в том, что физическое оборудование движется довольно устойчиво, и у вас уже есть большой запас ресурсов для роста, так что к тому времени, как вы получите базу данных, которая требует 2 ТБ ОЗУ и 30 ТБ (примерно самый большой В настоящее время технология может быть усовершенствована до такой степени, что машина с 4 ТБ ОЗУ и 100 ТБ памяти будет стоить меньше, чем вы заплатили за этого 2 ТБ монстра.
(Отказ от ответственности: я работаю в хостинг-провайдере, который выполняет множество гибридных VPS/ физических настроек от имени клиентов разных размеров, и я уверен, что это окрашивает мое мнение по этому вопросу)
Другой вариант, который не был упомянут, - это база данных как услуга. Если проблема заключается в том, что одному экземпляру БД не хватает ОЗУ, рассмотрите возможность использования службы базы данных, которая поддерживает автоматическое масштабирование пропускной способности. Этот тип сервиса автоматически масштабирует базу данных до нескольких узлов, выходя за пределы даже самой большой машины с точки зрения оперативной памяти, и, таким образом, приспосабливает дополнительную пропускную способность или соединения. Мне известны две службы, которые заявляют, что они предоставляют автоматическое масштабирование: Xeround (MySQL) и Enterprise DB (PostgreSQL).