Вот какой вопрос. Есть интернет-магазин, в котором довольно много заказов. Магазин написан на php, база MySQl. Заказов поступает много, поэтому база растет просто огромными шагами. Т.е. таблица заказов и все остальные связанные с ней таблицы (таблицы статусов заказов, таблицы истории изменений заказов, таблицы товаров в заказах и т.д.). В общем счет идет на сотни тысяч записей. Соответственно, сайт, а особенно админка (т.к. менеджеры работают непосредственно со списком заказов) работают все медленнее и медленнее. Особенно речь идет о загрузке списка заказов за определенный интервал времени и с применением различных фильтров. Я понимаю, что заказы четырехлетней давности фактически уже не нужны и хранятся больше для статистики и истории. Но тем не менее они лежат в таблице заказов, таблица огромна и поэтому запросы на выборку к ней происходят все медленнее и медленнее. Что принято делать в таких случаях? Просто удалить старые заказы из таблицы? Можно было бы это сделать и скорее всего этого бы никто не заметил, но с другой стороны иногда требуется сделать просмотр статистики, либо еще какие-то данные о каком-то старом заказе или клиенте найти, и вот в этом случае старые заказы могут понадобиться. Так что делать в такой ситуации, может кто сталкивался с подобной проблемой и поможет советом?
Разработать функционал архивирования заказов. Перемещать из 1 базы с текущими заказами в базу архивных заказов. хранить там. Выборку производить только по запросу архивированных данных.
профит в использовании чистой информации, ненужная хранится на полках
Как вариант еще, добавить временные таблицы статистики. Тоесть по крону создается таблица со статистикой, по определенным параметрам. Эта статистика уже выводится и фильтруется. Так работают, например, liveinternet.ru
@bumbay я уверен что если бы это было сделано проблем с производительностью на каких-то 100К записей небыло бы. С учетом того что в админке не такие сложные выборки.
@maxyc_webber да тут ни слова о Битриксе. И да - @Fesor прав! 100К записей - мало.
Роль еще может играть версия сервера, ну и движок на котором сайт написан.
Еще один совет - если в фильтре выбирается 100000 записей они никому никогда сразу не нужны - делайте обязательно постраничный режим - paging.
Я бы сначала привёл в порядок индексы таблицы, так как тот же поиск по неиндексированному полю - это очень плохо.
Далее, можно сделать аналогичную по структуре таблицу а-ля "order_archive", туда автоматически переносить все старые/выполненные/еще-по-каким-то-условиям-отобранные, короче, уже не актуальные заказы. И если нужно какую-то статистику, искать уже по ней, не трогая актуальные. Желательно этот поиск вынести с рабочего сервера, интернет-магазину ни к чему видимые пользователями лаги.
В довесок к вышеперечисленному, если хочется очень быстрых запросов в плане статистики, можно настроить Sphinx и искать по нему, он очень быстр (пробовал), или ElasticSearch (собираюсь пробовать)
Собственно менять бд и логику нет возможности, то тут делаем две простых вещи
1)Переносим базу на можный сервер с ссд и оптимизируем конфиг по максимуму.
2)Включаем slow queryies log и смотрим какие запросы можно пофиксить индексами, не сломав конечно производительности вставки излишними индексами.
Если что обращайтесь 8) имею богатый опыт оптимизации бд и интернет магазинов.
Что делать, когда растет база данных?
1. Радоваться. Растет база, значит много заказов.
2. дальше нужно смотреть план запросов. если в логике приложения не используется статистика типа "количество заказов по одному пользователю за всю историю" или что то аналогичное - то создать копию структуры БД с другим именем и переместить в нее строки старше какого то времени (1 января например)
3. если п. 2 в чистом виде невозможен менять структуру БД добавлять таблицы со статистикой, после чего - выполнить п.2
4. ну и все таки погонять explain запросов, на предмет их оптимальности и использования индексов. потому как 100к записей - это не много.
Роль еще может играть версия сервера, ну и движок на котором сайт написан.
Еще один совет - если в фильтре выбирается 100000 записей - они никому никогда сразу не нужны - делайте обязательно постраничный режим - paging.
Индексы и еще раз индексы.
Протестируйте самые долгие запросы. Если они действительно вытаскивают 1000000 записей - оптимизируйте их.
также можно для старых заказов сделать отдельную таблицу например, и туда перекидывать устаревшие заказы
можно сделать для запросов ненармализованные таблицы, например
Средний
