Где и как держать большую базу данных?

Привет, Тостер!
Я не имею опыта системного администрирования больших проектов. К сожалению, моя "верхушка" на данный момент – настроить LAMP по инструкциям из интернета.
Так получилось, что MySQL-база моего проекта разрослась до 1.1ТБ. Занят этот терабайт одной MyISAM-таблицей на 340 миллионов записей. Apache и MySQL сейчас живут на сервере у Kimsufi: i5-3570S, 16GB RAM, но этот сервер уже еле справляется. Средняя нагрузка – примерно 400 одновременных соединений, преимущественно INSERT. При перегрузке база падает, ибо MyISAM и table lock, соответственно. Да и мой быдлокод играет далеко не последнюю роль. Одно из последних падений, побившее 93% индексов, меня и подтолкнуло к действию.
Думаю, проект уже перерос возможности одного сервера и надо что-то предпринимать для дальнейшего роста, но вот что – ума не приложу. Рассматривал Google Cloud SQL/Amazon RDS, но получается слишком дорого. Хотелось бы уложиться в $250-300 ежемесячного бюджета, дабы проект хотя бы выходил в ноль. Полагаю, имеет смысл настроить шардинг. Каков оптимальный размер одного шарда и от каких именно характеристик сервера он зависит? Быть может, вообще имеет смысл переход на другую СУБД?
  • Вопрос задан
  • 3341 просмотр
Пригласить эксперта
Ответы на вопрос 6
а не пробовали для начала базу слегка подоптимизировать? ну там пару новых таблиц завести?
а то с таким подходом никакого железа не хватит.
Ответ написан
@lega
Все равно не достаточно информации, что у вас там в json и как вы используете данные.

Вот некоторые советы:
1) Прочитайте про партицирование, возможно вашу колонку ownerID можно вообще выкинуть, и разбить все данные на таблицы owner1, owner2..., таким образом можно сэкономить на индексах и данных, + можно будет проще размазать базу по серверам (шардинг), да и работать так будет быстрее.
2) Делайте архивирование json, это может уменьшить объем данных в 2..10 раз.
3) Складывайте старые данные в архив, например месяц прошел, делайте результирующие отчеты, кеши и т.п. что может запросить клиент, а сами данные отправляйте в архив.
4) Попробуйте другую бд: с postrgresql - можно использовать сжатый json по которому можно сделать индексы, таким образом ваши varchar'ы оптимизируются. с nosql/mongodb тоже есть плюсы, например 1 "запись" будет занимать 1 блок памяти, а не несколько как в sql базах, + тут выше скорость записи.

Так же по принципу партицирования можно делать чанки данных, например если вам данные нужно выбирать по дням и владельцу, то по окончанию дня можете паковать данные в чанки: data, ownerID, archived_json. таким образом размер индексов может уменьшится в 100 раз, данные в 10..20 раз, + скорость получения данных может вырасти до 50х раз (был у меня подобный проект).

Этими советами можно 1Тб "превратить" (например) в 10Гб - зависит от данных и использования.
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev
software engineer
Для начала, почему нельзя сделать несколько таблиц?
Если старые данные нужно просто хранить, изредка почитывая, а основная активность - инсерт и работа с последними данными, то давно следовало бы подумать, как можно разделить данные.

Можно помониторить, выяснить что именно нагружено больше всего - диск, память, сеть?
Может просто настроить репликацию, и разделить запросы на два сервера?
Ответ написан
Комментировать
shaks
@shaks
Загляни в mysql-slow.log, посмотри на тяжелые запросы, подшамань да подкрути их. там 146% есть гайки которые можно подкрутить.
Пологируй все запросы чуток. Проанализируй каждый из них на ПРАВИЛЬНОЕ использование индексов. Поубирай лишние индексы (освободишь наверное процентов 20-30 пространства). Вобщем оптимизируй. И только если оптимизировать нечего - тогда уже стоит задумываться о шардах.
Ответ написан
font
@font
В поисках самого лучшего
Крутые мужики NoSQL используют
Ответ написан
Комментировать
@sait4seo
Можно ещё глянуть в сторону форков mysql типо MariaDB и тд
А так partition by для таблиц, как писали вше.
Кэширование memcache или redis. Или вариант с mongo для отдельных таблиц или полей.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы