Добрый вечер дорогие друзья. Как всегда рад почерпнуть ценный опыт от каждого из вас. В последнее время рутина разработки бизнес-приложения заставило меня задуматься над общей оптимизацией скорости работы системы. Компания для которой разрабатываем систему управления предприятием, орендует сервер в Германии с очень неплохими параметрами. На эту машину поставили ISPManager и радуемся жизни. Но... Бываю некоторые случаи когда класс имеет очень тяжелые методы. Вот например: Есть у нас таблица в MySQL (InnoDB с выставлеными индексами и т.д.). Она в себе наличует например 200 000 договоров. Каждый договор имеет поле СУММА и также идентификатор месяца (чтоб понимать отчетный период). Так же у нас есть 20 региональных подразделений. Как уже становиться понятным, 200 000 договоров деляться на количество подразделений с разным удельным весом. А теперь собственно трабл. Вытягиваем из БД в массив регионы, в цикле к каждому региону делаем запрос в таблицу договоров типа SELECT SUM(price) WHERE region = id_regiona , ну а далее математика пошла. В чем же ж проблема?! Да в том что страница которая вмещает в себе общую стоимость договоров и стоимость договоров по каждому подразделению за некий отчетный месяц (в общем около 70 000-100 000 договоров) загружаеться около 40-70 секунд. Хотелось бы услышать правильные советы с аргументами. Благодарю заранее
Я так понял на выходе надо получить оборот каждого регионального представительства за период времени? может что то типа такого SELECT id_region, SUM(price) AS price FROM table GROUP BY id_region как раз неделю назад делал всевозможную статистику из похожей таблички)) что то похожее делал)
Помимо указанных рекомендаций, советую посмотреть в сторону форка Percona вместо стандартного мускула.
В конкретном случае то без разницы: и Mariadb бы подошла, но для бизнес-приложений предпочитаю percona использовать. По производительности, судя по фидбекам она не отличается от perconы особо, и также успешно решает проблемы мускула. Но для бизнеса обычно разворачиваются реплики, в моем случае с мультимастером, и вот тут у percona все есть из коробки. С позиции преимуществ Percona перед родным мускулем, думаю ты в курсе (переписаный сторадж как таковой - XtraDB, вместо InnoDB в мускуле. Профит на своих запросах видел 10-15% после переезда. В манах пишут что едва ли не на 25% быстрее может быть, но это конкретные кейсы имхо). С позиции масштабирования однозначно бы брал Percona ну или галеру, если вообще устраивает "масштабирование" мускула. Это всё только пенка, нюансов которые привели к её выбору много и описывать всё лень. Могу только насоветовать материал)
Насоветуй, буду признателен. Главное, чтобы эти все форки не забросились в ближайшее время.. Этого вот опасаюсь подсознательно.
Percona связь с разработкой мускула гораздо ближе чем у марии, это не поделка любителей. Из первых уст всегда лучше: http://percona.com А по большим масштабируемым приложениям на пыхе из разряда "бест практис" по конфигурированию инфраструктуры источников много. (зависит от того что конкретно интересно). Мне импонировало вот это чтиво: Stephen Corona. Scaling PHP Applications. Особо полезно будет тем кто тут на форуме мерил производительность стеков с apache и nginx чтобы осознать насколько забавно это выглядит . Дотошно разбираются все шестеренки инфраструктуры под масштабируемые проекты на пыхе.