Рекомендации по масштабированию базы данных [ closed]

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

Поскольку вы ' Если вы используете термин «СУБД», который не очень популярен, я предполагаю, что вы используете реляционную базу данных «не очень модно», и там все становится сложнее. Двигатели I ' Я знаком с (MySQL и PostgreSQL), у обоих есть миллион кнопок, чтобы сообщить системе, сколько оперативной памяти использовать - кеши различных вещей, память рабочего набора, буферы ... все это очень весело. Их настройка в соответствии с рабочей нагрузкой и доступными системными ресурсами в основном (хотя и не полностью) связана с сокращением дискового ввода-вывода, поскольку это обычно (хотя, опять же, не всегда) самое медленное и, скорее всего, станет узким местом компонент в физической системе.

Таким образом, когда вы не можете увеличить объем оперативной памяти, ваша производительность начнет ухудшаться (надеюсь, постепенно), поскольку для выполнения большего количества запросов требуется больше обращений к диску. Ухудшение производительности при увеличении размера базы данных будет усугублено тем, насколько низкая производительность дискового ввода-вывода.

Учитывая, насколько сложно горизонтально масштабировать реляционную базу данных (это ' не невозможно , но это чертовски сложнее, чем горизонтальное масштабирование интерфейсов), если вы собираетесь делать что-то в масштабе, вам нужен провайдер, который может предоставить вам большие машины - много RAM, но также много CPU, дискового пространства и IOPS. Размер самой большой виртуальной машины Linode составляет 20 ГБ, что слишком мало. AWS имеет экземпляры с объемом ОЗУ до 70 ГБ или около того, что лучше, но когда вы можете получить физический компьютер с ОЗУ (или более ТБ) ... это все равно не очень умно.

Дело не в том, что виртуальная машина всегда неверна для сервера базы данных, но в какой-то момент, когда вы перерастете доступные параметры виртуальной машины, вам нужно знать, что вы собираетесь делать дальше. Люди все чаще выбирают путь "ранний осколок, часто осколок", потому что если вы Если вы стремитесь к массовым масштабам, на Земле нет физической машины, которая вас спасет, а это значит, что вы можете работать в любом облаке из игрушечных игрушек, которое вам нравится. Однако сегментирование - это большая работа, которую нужно выполнять правильно, и она несколько ограничивает ваши возможности в том, как вы моделируете и взаимодействуете с вашими данными, поэтому я предпочитаю избегать этого, если могу. Дело в том, что физическое оборудование движется довольно стабильно, и у вас уже есть большой запас для роста, поэтому к тому времени, когда у вас будет база данных, для которой потребуется 2 ТБ ОЗУ и 30 ТБ хранилища (примерно самый большой спецификацию одной физической машины, которую я могу купить сейчас), технология, вероятно, улучшилась до такой степени, что машина с 4 ТБ ОЗУ и 100 ТБ памяти стоит меньше , чем то, что вы заплатили за этого монстра 2 ТБ.

(отказ от ответственности:

Позвольте мне добавить к Womble - и как человек, только что закончивший работу над проектом с нетривиальной базой данных размером 21000 ГБ ... ... У вас есть 2 фундаментальных вопроса, которые вам необходимо понять:

• ОЗУ относительно. Современный сервер для полноценной базы данных имеет 256 и более гигабайт. VPS даже не отображается как «настоящий сервер базы данных» в этом мире.

• Скорость диска также относительна. Я запускаю дома систему, которую вы, вероятно, сочтете чрезвычайно мощной - 2 SSD, 8 Velociraptor только для данных, чтобы получить надлежащий бюджет ввода-вывода для данных - но в моем мире это даже не проявляется - последняя система, над которой я работал, имела 3 узла хранения, каждый с флеш-памятью 768 ГБ для BUFFER IO и доставлял больше данных в случайном IO, чем вы получаете с ваших дисков последовательно.

В принципе, ОЗУ можно добавить намного больше, чем вы думаете, а затем в какой-то момент вы сидите вниз и разработать СЕРВЕР базы данных, оптимизированный для ввода-вывода. Достаточно интересно, что сегодня не хватает одного предмета, где все, что виртуализация решает все проблемы и приносит мир, заключается в том, что серверы баз данных ЯВЛЯЮТСЯ привязанными к вводу-выводу, и это частично решенная проблема, просто ожидайте, что в наши дни вы получите большую кассету с тоннами дисков или фактически SSD. Ничего не дается бесплатно, но это фундаментальная проблема, которую нельзя избежать, и она решена. Это одна из причин, по которой вы можете получить хорошие стойки 4U от SUperMicro, которые содержат 72 слота для дисков. Это одна из причин, по которой был разработан SAS. Это одна из причин, по которой SSD очень нравятся для баз данных - они примерно в 100 раз быстрее (или больше), чем жесткие диски, когда говорят о вводе-выводе в секунду.

VPS просто не идут туда;)

Меняется ли СУБД это методы кеширования, позволяющие избежать доступа к диску, когда это возможно?

Нет, это не так. Потому что это ЕДИНСТВЕННЫЙ (!) Разумный метод кеширования, с которого нужно начать. Любая надлежащая база данных в большом мире (SQL Server, DB2, Oracle) пытается использовать память, чтобы максимально избежать ввода-вывода. Читайте блоги SQL, и многие не слишком опытные люди всегда жалуются, что SQL Server начинает использовать слишком много памяти - конечно, потому что память есть, и он пытается кэшировать как можно больше.

Это также одна из причин, по которой база данных использует журналы транзакций - это означает, что изменения в базу данных не нужно записывать СЕЙЧАС, но запись может быть отложена, сохраняя обновления в журнале tx и, таким образом, сохраняя их в случае сбоя.

Опять же, это «решенная проблема». У Oracle есть оборудование, которое идет туда - наша установка 21000 ГБ использовала Oracel ExaData, и это была САМАЯ МАЛЕНЬКАЯ УСТАНОВКА, которую они продают.

Читайте блоги SQL, и многие не слишком опытные люди всегда жалуются, что SQL Server начинает использовать слишком много памяти - конечно, потому что память есть, и он пытается кэшировать как можно больше.

Это также одна из причин, по которой база данных использует журналы транзакций - это означает, что изменения в базу данных не нужно записывать СЕЙЧАС, но запись может быть отложена, сохраняя обновления в журнале tx и, таким образом, сохраняя их в случае сбоя.

Опять же, это «решенная проблема». У Oracle есть оборудование, которое идет туда - наша установка 21000 ГБ использовала Oracel ExaData, и это была САМАЯ МАЛЕНЬКАЯ УСТАНОВКА, которую они продают.

Читайте блоги SQL, и многие не слишком опытные люди всегда жалуются, что SQL Server начинает использовать слишком много памяти - конечно, потому что память есть и он пытается кэшировать как можно больше.

Это также одна из причин, по которой база данных использует журналы транзакций - это означает, что изменения в базе данных не нужно записывать СЕЙЧАС, но запись может быть отложена, сохраняя обновления в журнале tx и, таким образом, сохраняя их в случае сбоя.

Опять же, это «решенная проблема». У Oracle есть оборудование, которое идет туда - наша установка 21000 ГБ использовала Oracel ExaData, и это была САМАЯ МАЛЕНЬКАЯ УСТАНОВКА, которую они продают.

Это также одна из причин, по которой база данных использует журналы транзакций - это означает, что изменения в базе данных не нужно записывать СЕЙЧАС, но запись может быть отложена, при этом обновления в журнале tx сохраняются и, таким образом, сохраняются в случае сбоя.

. Опять же, это «решенная проблема». У Oracle есть оборудование, которое идет туда - наша установка 21000 ГБ использовала Oracel ExaData, и это была САМАЯ МАЛЕНЬКАЯ УСТАНОВКА, КОТОРАЯ ОНИ ПРОДАЕТ.

Это также одна из причин, по которой база данных использует журналы транзакций - это означает, что изменения в базе данных не нужно записывать СЕЙЧАС, но запись может быть отложена, при этом обновления в журнале tx сохраняются и, таким образом, сохраняются в случае сбоя.

. Опять же, это «решенная проблема». У Oracle есть оборудование, которое идет туда - наша установка 21000 ГБ использовала Oracel ExaData, и это была САМАЯ МАЛЕНЬКАЯ УСТАНОВКА, КОТОРАЯ ОНИ ПРОДАЕТ.

Другой вариант, который не был упомянут, - это база данных как услуга. Если проблема в том, что в одном экземпляре БД заканчивается ОЗУ, рассмотрите возможность использования службы базы данных, которая поддерживает автоматическое масштабирование пропускной способности. Этот тип службы автоматически масштабирует базу данных на несколько узлов, превышая предел даже самой большой машины с точки зрения ОЗУ, и, таким образом, обеспечивает дополнительную пропускную способность или подключения.