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