Mysql на другом сервере

Конечно будет. А ты думал в сказке живешь?

Если в той же стойке, что у основной сервер, то минимально, но будет

вынеси, да проверь

В том то и дело, что в этой же стойке проблема найти, нашел у другого провайдера конфигурацию. Допустим средний запрос 0.1 сек, а ping до того сервера 28 ms, то есть запрос будет 100 ms + 28 ms? Что вполне устраивает, если это так

Не в сказке ) Понимаю что на сетевые операции нужно время. Хочу понять так вообще делают и насколько критично будет. Проверить в реальной ситуации не могу, нужно сначала сервер заказать и базу перенести

Во-первых думаю ещё делать такую схему или нет, потом сайт рабочий проверять как то не охота, хочу узнать у тех кто делал такое

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

rj45

А ты думал в сказке живешь?

+1

Ну кэш это отдельная история, сейчас тяжелые запросы кешируются уже и так, но все равно мощей не хватает в час пик, проц на 100% бывает загружен по минуте. Я просто читал на https://ruhighload.com/ что БД нужно обязательно на отдельный сервер выносить ) А на сколько процентов вырастит отклик? Понимаю вопросы общие, хочу узнать хотя бы примерно

Вырастет отклик чего?

Гоню.

Зависит от того за сколько хопов сидит сикель от бекенда и от ширины канала. Цифр тебе никто не даст.

Будет ли влиять отклик(ping) на удаленный сервер где будет лежать база?

Конечно будет.

Допустим средний запрос 0.1 сек, а ping до того сервера 28 ms, то есть запрос будет 100 ms + 28 ms?

Да. Но есть нюанс. БД «там» может работать быстрее, а может медленнее.

Сейчас проц Xeon E3-1245 V2 @ 3.40GHz(8 core), 16 гигов ОЗУ, диск SATA 2x1TB(тормозной). Планирую переносить на Xeon E3-1230 v3(4 core) с SSD 2×120 GB, 32 ОЗУ. Думаю SSD спасет да и памяти под буфер можно больше дать

А ширина разве влияет, там вроде небольшой трафик. А вообще 500gbps ширина

И ширина тоже влияет — не известно же сколько в неё накачали чужих данных.

В данный момент смотрю nload lo показывает ~50mbps

Ты не понял — вот когда упрёшься в бутылочное горлышко, тогда циферки и расчехляй. А сейчас тебе это не нужно — смело выноси сикель на другую машину и не переживай. А может «завтра» ты придешь еще про реплики спрашивать...

Я один не понимаю, зачем ты масштабируешься горизонтально и ищешь себе проблем, когда ты с лёгкостью можешь ещё вырасти вертикально? У тебя реально нагружены все 8мь ядер на 100%? Если так, ну возьми двух головый сервер. Но меня прямо сильное сомнение гложит... - Ты реально упираешься в диски? Статистика wa большая? Какой loadaverage в пиках? Ну замути SSD, если это реально так.

Пинг показывает совсем другое. Запрос данных надо сформировать, отправить, на другой стороне расчехлить, направить на базу, сделать запрос, если данных много, долго их паковать, идти 1000 строк из базы будут тоже дольше чем пинг, потом это все расчехлить, привести в читаемый вид и выдать бэкенду. Если все это на яве, то умножай еще на тысячу :)

Я так никогда не делал, но с работы часто делаю запросы на удаленный mysql сервер руками. Задержка не просто заметна, она раздражительно велика.

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

+1

Понял, спасибо. А вообще лучший вариант чтобы в одной стойке были или ДЦ?

Лучший вариант далдон сказал. Но, мы тут полагаем что ты уже уперся в лимиты одной машины. Это так?

Но, твоя приложуха должна уметь в мастеры-слейвы сикеля из коробки. И она должна даже на одной машине работать «думая» что база уже размазана. Когда ты упрешься в лимиты, то переход на размазывание по горизонтали пройдет безболезненно.

Всегда стараюсь вынести субд на отдельную машину/вм. Проще тюнить, проще мониторить, проще админить.

Ну у меня не про HA, да.

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

Допустим средний запрос 0.1 сек, а ping до того сервера 28 ms, то есть запрос будет 100 ms + 28 ms?

Не верная математика. Рассматривать надо отдельно 1. время на передачу самого запроса 2. время выполнения запроса - это сколько времени на его обработку потратила СУБД 3. время на получение результата. В вашем случае увеличивается время пунктов 1 и 3, и если вы увеличиваете мощность сервера то уменьшается время пункта 2.
В моей практике встречалось когда бутылочным горлышком оказывался именно сервак СУБД.
Т.е. однозначно ответить на ваш вопрос без реального тестирования нельзя.

ЗЫ Еще видел вариант просто эпичнейшего говнокода. Чувак писал where fieldname in ( а дальше километровая простыня. Обнаружилось когда уткнулось в ограничение на размер самого запроса :)

Ну субд на отдельной машине это как раз правильно. Только у ТС нюанс эта отдельная машина планируется «далеко» :)

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

Не понял, автор пытается решить проблему производительности ? Но тогда сначала надо сделать профилирование, настройку индексов, подкрутить конфиг mysql. И только когда вариантов не остается выделять отдельную машину

Если не хватает места есть у mysql row format compressed

Если не хватает проца, это проблема софта, а не mysql, а точнее того идиота, кто написал кривые запросы

Что касается оперативы то при большой базе mysql все равно будет скакать по диску, тут надо движки пробовать, myisam innodb

Если у тебя сайт с десятками или даже сотнями запросов на страницу, то пинг 28мс будет полная жопа.

Допустим средний запрос 0.1 сек, а ping до того сервера 28 ms, то есть запрос будет 100 ms + 28 ms? Что вполне устраивает, если это так

Если запрос один, то да. Но так бывает редко. Десяток запросов и у тебя к 100 мс сайта добавится 280 мс. задержек MySQL. Итого уже 380 мс. Почти четырёхкратное замедление и переход из категории «мгновенно» к «заметная задержка открытия».

Понимаю что на сетевые операции нужно время. Хочу понять так вообще делают и насколько критично будет.

Если нужно разгрузить БД разнесением на разные машины, то надо делать две БД с master-slave или master-master репликацией. И с каждой машины обращаться к своей БД.