обеспечение производительности базы данных при увеличении объема данных

Question

Сейчас я занимаюсь настройкой производительности. Приложение интенсивно использует БД с очень небольшой логикой обработки. Настройка производительности зависит от способа выполнения вызовов БД и самой БД.

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

При меньшем объеме данных (скажем, до 100 000 записей) производительность просто фантастическая. Мой вопрос: что нужно сделать, чтобы обеспечить такую ​​хорошую производительность при больших объемах данных? Ожидается, что объем данных достигнет 10 миллионов записей.

Я могу подумать о секционировании таблиц и индексов, предлагая файловые системы, оптимизированные для хранения БД и периодического архивирования, чтобы контролировать количество строк. Я хотел бы знать, что еще можно сделать. Любые советы / стратегии / шаблоны будут очень полезны.

Answer 1

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

Тестирование. Создание фиктивных данных, чтобы у вас было 10 миллионов строк на тестовом сервере сегодня. Оценивайте запросы, которые есть в вашем приложении, и смотрите, насколько хорошо они работают как объем данные увеличиваются. Вы можете быть удивлены тем, что ломается в первую очередь, или все может пойти точно так, как предсказано. Дело в том, что вы можете узнать .

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

Исследования. Найдите лучшие журналы и блоги для используемой вами базы данных и прочитайте их (например, http://www.mysqlperformanceblog.com, если вы используете MySQL). Вы можете задать хорошие вопросы, такие как тот, который вы задаете здесь, но также прочитать то, что спрашивают другие люди, и что им советуют делать с этим. Вы можете изучить решения проблем, которых у вас еще нет, так что когда у вас есть , у вас будет несколько стратегий для использования.

Answer 2

Различные базы данных должны быть настроены по-разному. Какие СУБД вы используете?

Кроме того, как вы узнаете, приведет ли то, что вы сделали, к низкой производительности с большими наборами данных? Вы проверили свои текущие оптимизации с большим количеством тестовых данных?

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

В зависимости от РСУБД, следующий тип решения прост: получить больше, более качественное оборудование. Больше оперативной памяти, больше дисков, больше процессоров.

Answer 3

Вы на правильном пути:
1) Правильные индексы
2) Настройка параметров СУБД (кэши памяти, буферы, управление внутренними потоками и т. Д.)
3) Настройка запросов (особенно регистрация медленных запросов, а затем их настройка / перезапись)
4) Чтобы настроить запросы и индексы, вам может потребоваться изучить планы выполнения запросов
5) Мощный выделенный сервер
6) Подумайте о запросах, которые ваши клиентские приложения отправляют в базу данных. Они всегда необходимы? Вам нужны все данные, которые вы запрашиваете? Можно ли кешировать некоторые данные?

Answer 4

10 миллионов записей, вероятно, слишком мало, чтобы беспокоиться о разделении. Обычно разделение будет интересным только в том случае, если ваши объемы данных на порядок или величину больше этого.

Настройка индекса для базы данных с 100 000 строк, вероятно, даст вам 99% того, что вам нужно, с 10 миллионами строк. Следите за сканированиями таблиц или индексами в больших таблицах системы. На небольших столах они хороши, а в некоторых случаях даже оптимальны.

Может помочь архивирование старых данных, но это, вероятно, излишне для 10 миллионов строк.

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

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