Я собираюсь настроить отдельный сервер базы данных для одного из моих приложений, приложение в настоящее время работает на 3 серверах; 1 интерфейсный сервер и 2 сервера приложений / баз данных. Но по соображениям производительности я хочу переместить базу данных на ее собственные машины.
Итак, все сводится к следующему: не лучше ли мне получить два сервера и настроить их как копии друг друга. Или всего один сервер, но сделать его вдвое мощнее?
Вещи, о которых я думал до сих пор;
С одним сервером:
С двумя серверами:
Некоторые технические детали, характерные для моей ситуации;
Серверы будут работать в облачной службе под названием StormOnDemand, поэтому у нас действительно не будет слишком много проблем с надежностью оборудования. Мы также можем масштабировать по вертикали вверх и вниз по мере необходимости.
Мы используем 4 разные системы баз данных; Postgresql, MongoDB, Redis и Memcached *
В прошлый раз, когда я проверял, мы в среднем чуть более 2 миллионов транзакций в день на Postgres, около 2,5 миллионов на Mongo, не уверен в Redis и Memcached, но мы используем их оба для кеширования, поэтому я могу предположить, что это примерно то же самое.
Все серверы подключены через локальную сеть со скоростью 1 ГБ / с.
Базы данных, я бы сказал, среднего размера (Postgresql: 32 ГБ, MongoDB: 16 ГБ, Redis и Memcached используют память для хранения, но я думаю, что в настоящее время они работают с Redis: 12 ГБ и 4 ГБ)
Серверы, которые я хотел бы получить, будут иметь эфир 8 ЦП и 30 ГБ ОЗУ для одного сервера или 4 ЦП и 8 ГБ ОЗУ для двух серверов.
Что касается избыточности, это веб-приложение, и подавляющее большинство наших посетителей перекликаются, поэтому, хотя мы не хотим простоев, мы были бы довольны парой часов в месяц для экономии средств, которую мы получили бы от одного сервера. . За 6 месяцев работы с SOD у нас ни разу не было простоев, но это не значит, что этого не произойдет в будущем.
Если я исключил какие-либо подробности, которые были бы полезны, я с радостью их предоставлю, но я постарался включить как можно больше.
* Memcached продолжит работать на серверах приложений, мы используем его как своего рода «локальный кеш», поэтому он не реплицируется / не разделяется между серверами, используя Redis в качестве распределенного кеша.
Я должен сказать все, что, по вашему мнению, может сойти с рук, так как риск потери данных минимален. Вы говорите об использовании облачного хранилища, и, на мой взгляд, это было бы более практично для одного сервера. Вы также упомянули стоимость несколько раз, поэтому я так понимаю, что деньги трудно достать, и гораздо проще увеличить характеристики одной системы, чем получить точное соответствие другой, менее мощной системы. Всегда спрашивайте себя: «А мне это действительно нужно?» и вы никогда не ошибетесь.
Обычно базы данных выигрывают от большого железа. Как правило, добавление дополнительных блоков повышает производительность веб-серверов и серверов приложений, но для баз данных ответ таков: обычно чтобы получить более крупную и быструю машину.
Но обратная сторона этого состоит в том, что наличие большего количества эквивалентных узлов всегда улучшает доступность, а также производительность - подумайте, если вы потратите 3000 долларов на блестящий сервер, вероятность отказа в течение его жизненного цикла может составлять (скажем) 1%. Или вы можете купить 2 машины базовой комплектации с вероятностью отказа 5%. Вам лучше потратить деньги на блестящую коробку? Если вы посмотрите на вероятность отказа ОБЕИХ базовых машин, она намного меньше - 0,05 * 0,05 * 100 = 0,25%, т.е. в 4 раза надежнее.
Но очень многое зависит от СУБД, которую вы используете. Базы данных NoSQL предназначены для масштабирования на большом количестве серверов. Репликация MySQL относительно надежна и эффективна. Но базы данных как mysql, так и nosql, как правило, не реплицируются в реальном времени. Если вам нужна согласованность во всем кластере, вам понадобится что-то вроде Oracle RAC для нескольких узлов - и IME, он генерирует огромные объемы межузлового обмена - в этом сценарии вам лучше купить более крупный блок.
Таким образом, в вашем случае mongoDB и Redis определенно предпочтут многоузловое решение. Мои знания о кластеризации PostGreSQL ограничены, но, учитывая его поддержку согласованности в запросах, я ожидал, что он будет вести себя больше как Oracle (т. Е. Завышенное количество локального диска и сетевого ввода-вывода).
Я бы сказал, что ваши наборы данных маловаты - на самом деле, я очень обеспокоен тем, что вы используете 4 разных субстрата для управления своими данными, - и настоятельно рекомендую объединить их.