Какой выбрать сервер для бд MySQL?

Question

[Евгений Карпов]

Онлайн на сайте около 50к и постепенно возникает необходимость в выносе бд на отдельный сервер, дамп бд составляет порядка 15гб. Посоветуйте пожалуйста оптимальные варианты по требованиям к серву. Будет ВДС. То есть скоростной жесткий диск, объемом под 100гб, какой канал между сервером сайта и бд, какая озу. Сайт на MODX.

Comments

[Akina]

онлайн на сайте около 50к

Это ни о чём. Серверу БД пофиг, что юзер, подключившись, сидит и пялится в загруженную страницу. Сколько запросов в секунду? распределение по типам? поток "тяжёлых" запросов? объём выборок (поток трафика от сервера)?

[Виктор Таран]

учти что выделенный сервер под бд это подключение через TCP\IP тем самым ты потеряешь ощутимо по скорости

[Евгений Карпов]

Akina, ну судя по основной странице исходит до 140 запросов, из них тяжелых около 50

[Евгений Карпов]

Виктор Таран, ну а если использовать между серверами 10гб/с канал?

[Виктор Таран]

Евгений Карпов,
Без разницы
ты понимаешь разничу между сокетом и задействованием сетевой карты?
разница будет и будет очень приличной.
И даже если сервера стоят в одной стойке то все-равно разница будет.
Мало того она будет даже при подключение к твоей же базе через внешний айпи с этого же компьютера ( правда уже не столь фатальной)
Можешь потестировать конечно но реально просадка будет в разы.

Так же учти что базе не сильно важно количество процессоров чем их часота
К примеру 64 ядра по 2.2 GHz будут меоденней отдавать запросы чем 2 ядра по 5GHz
А вот при ддосе они проживут чутка подольше, хотя учитывая что очередь все-равно встанет не шибко много.

Answer 1

[ThunderCat]

Евгений Карпов,

ну а если использовать между серверами 10гб/с канал?

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

судя по основной странице исходит до 140 запросов, из них тяжелых около 50

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

Comments

[Евгений Карпов]

Я к сожалению, не спец в бд, поэтому собираю информацию у профи. Сервер в 48гб озу и 12 ядер, я понимаю, что это все абстрактно, но тем не менее, загрузка в 400 онлайн юзеров чоздает нагрузку на цп в 300 400%%

[ThunderCat]

Евгений Карпов,

Я к сожалению, не спец в бд,

Есть количественный показатель - rps, реквест пер секонд, от него большей частью отталкиваются при построении плана по апгрейду. Просто тыкнуть пальцем в небо конечно классно, но нифига не эффективно. В вашем случае, если не получается посчитать нагрузку, идите по пути подбора - возьмите средний доступный сервер, проверьте как на нем ведет себя приложение, если нужно - докупаете мощность. В конце концов - заходите на фриланс, даете задачу подобрать и настроить сервер под ваши нагрузки, платите за работу и готово. Гадать по примерным возможным параметрам - будет примерно возможное качество в итоге.

[Евгений Карпов]

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

[ThunderCat]

Vitsliputsli, да, оговорочка, поправил

[ThunderCat]

Евгений Карпов,

с учетом того что таблицы занимают сотни тысяч записей.

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

есть одна большая особенность - сайт реализован на modx и тут нужен настоящий гуру, который смог бы переписать все сложные запросы к бд

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

[Евгений Карпов]

ThunderCat, ну я уже не в том возрасте чтобы освоить мускуль до уровня, на котором вертятся профы. Тем более на это предусмотрен бюджет.

Answer 2

[rPman]

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

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

В облаке можно на лету подобрать параметры сервера, например у Амазона можно выбирать профессор по быстрее или медленнее, а не просто увеличивать количество ядер... И уже проведя эксперименты и подобрав количество памяти можно принимать решение по железу.