Как точно настроить базу данных AWS R4 Aurora MySql - PullRequest
Новая
       87

Как точно настроить базу данных AWS R4 Aurora MySql

0 голосов
/ 05 декабря 2018

У меня есть база данных в настоящее время на 6,5 ГБ, но она быстро растет ...

В настоящее время на сервере R4L Aurora, 15,25 ГБ Ram, 2-ядерный ЦП

Я смотрю на покупку зарезервированногоНапример, чтобы сократить расходы, но беспокоюсь, что если база данных будет быстро расти, например, достигнет более 15 ГБ в течение года, мне потребуется сервер большего размера.

99% данных - это история транзакций, эта таблицасамый большой на сегодняшний день.Он пишется очень часто, но после записи строки он не часто меняется (хотя иногда и меняется).

Так мало вопросов ...

1) Должен ли я отключитькеш?

2) Я буду в порядке с 15G оперативной памяти, даже если сама база данных идет (скажем) 30G, или я буду видеть огромные проблемы со скоростью

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

Спасибо

Ответы [ 3 ]

0 голосов
/ 05 декабря 2018
  • "Стоит ли отключать кеш?"- В каком «кэше»?
  • «я увижу огромные проблемы со скоростью» - Нам нужно увидеть запросы и т. Д.
  • «База данных хорошо проиндексирована» - Если это означаетВы проиндексировали каждый столбец, тогда он не очень хорошо проиндексирован.Пожалуйста, покажите нам SHOW CREATE TABLE и несколько важных запросов.
  • «раздел» - за редким исключением, разделение не ускоряет работу таблиц MySQL.Опять же, нам нужны подробности.
  • "15.25G Ram" & "database ... 15G" - размер набора данных, как правило, больше, даже на намного больше, чемБАРАН.Таким образом, эту пару цифр не обязательно хорошо сравнивать друг с другом.
  • «1 миллион записей принадлежит одному пользователю» - опять детали, пожалуйста.
0 голосов
/ 05 декабря 2018

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

Если вашему приложению нужно касаться большого объема данных, тогда идеальный способсделать это будет иметь выделенные реплики для конкретных видов запросов.Таким образом, вы не будете менять действительные страницы в пользу новых запросов.Aurora теперь имеет поддержку пользовательских конечных точек, и это делает ее еще проще в управлении.

Если вам нужны более конкретные рекомендации, вам может потребоваться поделиться информацией о ваших данных, индексах, запросах и т. Д.

0 голосов
/ 05 декабря 2018

Вы должны статистически объяснить рост данных.Это можно сделать, запустив группу запросов count (*) по столбцу даты (года).Как только у вас будет количество записей в год, вы сможете понять, что происходит.

Теперь вы можете подумать о возможных решениях

  1. Вы можете удалить данные, которыебольше не актуален с точки зрения истории и ограничивает объем хранилища.
  2. Если имеется большой объем данных, например, Blob и т. д., возможно, вы можете настроить его хранение на S3 и сохранить ссылку в таблице базы данных
  3. Удалитьлюбые нежелательные таблицы.Иногда администратор базы данных создает временные таблицы резервных копий и оставляет их там после работы.Вы можете чистить такие столы.
...