Всем привет, коллеги. Я к вам с вопросом, каким способом можно

организовать горизонтальное масштабирование mysql базы данных?
Есть некий сервис, который работает с mysql под windows server 2012.
В сутки он может писать в базу тысячи данных.
В общей сложности файлы таблиц формата ibd на сегодняшний день занимают около 800 ГБ дискового пространства.
Все это дело крутится на железе с 24 ядрами CPU, 144ГБ ОЗУ, на рэйде из SSD дисков.
При построении отчетов в ПО, которое работает с БД, возникают долгие задержки.
Вот и думается, а нельзя ли "размазать" данную БД на несколько хостов?
Может, кто-то подскажет иное решение возникшей задачи, буду благодарен.

Самое простое read write replica

по-русски, это репликация master-slave? Или нечто иное?

>Вот и думается, а нельзя ли "размазать" данную БД на несколько хостов? Вам -- не получится. >Может, кто-то подскажет иное решение возникшей задачи, буду благодарен. Нанять DBA.

С чего же такой вывод? ))

Да так, с мелких шэроховатостей. С того, что вы приводите довольно неинформативные, зато очевидные характеристики жэлеза -- количество ядер и ОЗУ. Если бы вы понимали, во что упираетесь -- говорили бы за пропускную способность памяти или iopsы. С "пользовательской" терминологии вроде "задержки при построении отчётов". Вместо нормальной оцэнки потоков данных для этих отчётов. У вас просто нет в голове картины таймингов и понимания наличных ресурсов, которые на них влияют. Шансы, при таких вводных, что у вас за счёт реплики что-то случайно ускорится -- невелики. Шансы, что у вас там на самом деле что-то сделано крайне неоптимально, и можно это ускорить в разы (если не в сотни раз) безо всяких реплик -- 100%.

Ну тоже вариант )

Тогда ещё подскажите, что именно можно оптимизировать, если ПО, используещее БД коммерческое и в нем ничего не изменить, типа запросов и т.д. Оптимизировать саму БД? Это я к пониманию, что должен будет делать DBA, если его нанять.

>используещее БД коммерческое и в нем ничего не изменить, типа запросов и т.д Мда. Совет нанять DBA был в предположэнии, что это таки вашэ ПО. В случае, если это не вашэ ПО -- вполне возможно во-первых, что разрабочики и так всё достаточно оптимизировали -- а что вы не понимаете, как оно работает и во что упирается -- так на это никто и не рассчитывал. Во-вторых -- шансы, что оно хотя бы заработает с горизонтальным машстабированием и без поддержки этого решэния со стороны разработчиков стремятся к нулю. В-третьих -- попытаться что-то сделать можно -- проанализировать запросы, определить, чем они занимаются, возможно, как-то им индэксы подсунуть -- но реально если у вас нет контроля за кодом -- то, опять жэ, шансы, что что-то хорошэе выйдет невелики. Самое логичное -- попытаться как-то попробовать вместе с разработчиками сформулировать вашы требования и добиться решэния от них, либо сменить разработчиков.

А где "Мда...." )

Случайно отправилось недописанное.

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

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

Кстати, нагружэнный mysql и windows server вышэ средней мощности. Зачем? Почему?? Не, достоверно я не знаю, насколько у mysql всё плохо с виндоус -- но, что-то мне кажэтся, это сильно не основная их система.

Это ставилось пакетом, там глонасс система отслеживания датчиков транспорта. Честно говоря, это зоопарк достался в наследство, я к нему не притрагивался, ибо трогать это боялись все ) А тут прилетело, мол тормоза, ахтунг, надо что-то делать, вот и начали перебирать, что ж нам с ним делать ) Я предлагал давно на Linux перенести, но как-то все мимо ушло. По-моему даже сам софт есть под линукс. Сейчас просто рассматриваем варианты, и перенести на Linux не самый плохой из них, как и нанять кого-то, кто мог бы реально оптимизировать саму БД.

Определить потребности! Реально оптимизировать чужую БД вполне можэт не выйти. Но чотко ответить -- нужно то-то (в т.ч. смена поставщика, если этот неспособен) -- должно получиться.

>По-моему даже сам софт есть под линукс. Вот, кстати, если там есть (наверняка есть) понятие app-server (основной комплекс ПО, который принимает запросы от удалённых датчиков, пишэт всё, представляет какие-то интэрфейсы) -- то вот разнести его и сервер СУБД -- это прямо вот первая мысль, которая приходит в голову. Тожэ себе такое горизонтальное масштабирование, хе-хе. Она не всегда работает хорошо, но очень и очень часто -- да. Но, конечно, в рабочей системе нужэн тэстовый стэнд для начала, чтобы это всё опробовать.

Ну это-то понятно. Виртуалку уже разворачиваем.