|
|
|
Помощь в оптимизации запросов и увеличение скорости приложения
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Опыта и знаний не хватает, поэтому обращаюсь за помощью. Заранее спасибо за любую информацию! В моём проекте имеется 11 специализированных IP-видеокамер, которые считают посетителей торгового центра. Каждая из них имеет веб-морду, через которую можно скачать отчёт в виде XML-файла только за день целиком. Данные такие: вход/выход, дата и время, высота объекта. Мои PHP-скрипты раз в минуту логинятся на устройствах, выкачивают файлы со статистикой и складывают в MySQL (db_visitors_counter). Для каждого устройства создано по одной таблице типа InnoDB (deviceXX, где XX номер устройства). Структура таблиц: #ИмяТипСравнениеNullПо умолчанию1id (первичный)int(11)НетНет2iochar(6)utf8_general_ciДаNULL3datetimedatetimeДаNULL4heightchar(5) utf8_general_ciДаNULL Далее, с веб-страницы пользователь задаёт, например, день (а может и неделю), за который он хочет увидеть статистику. Статистика состоит из многих видов графиков. Через AJAX страница общается с PHP-скриптом, который ведёт работу с БД. Например, нужен почасовой график входов через центральный вход за сутки. Центральный вход - это 7 устройств (или 7 таблиц deviceXX). Делается выборка данных за первый час суток из таблицы device01, затем из device02 и т.д. до device07, например: Код: plsql 1. 2. 3. 4. 5. 6. 7. Вопросы: a. Вообще верный ли подход запросов к таблицам здесь используется? Что можно придумать для оптимизации? Или проблема вообще не в БД, а в приложении в целом? b. Правильно ли составлены таблицы? c. Правильно ли выбран тип таблиц в данном случае? d. Имеет ли смысл добавлять Index? И для какого столбца? datetime? e. Можно ли как-то оптимизировать сами SQL-запросы? Спасибо за внимание! P.S.: Немного результатов моих исследований по добавлению индекса для столбца datetime к самой тяжеловесной таблице: Таблица: device07reserve Количество строк: 3850385 Размер: 165.7МБ 1. Без индекса Запрос: Код: sql 1. Выбрано 366 строк. Выполнено за 1,0000 секунд. 2. Запрос: Код: sql 1. idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsfilteredExtra1SIMPLEdevice07reserveNULLALLNULLNULLNULLNULL38503851.11Using where 3. Запрос: Код: sql 1. 4. С индексом Запрос: Код: sql 1. Выбрано 366 строк. Выполнено за 0,0000 секунд. 5. Запрос: Код: sql 1. idselect_typetablepartitionstypekeykey_lenrefrowsfilteredExtra1SIMPLEdevice07reserveNULLrangedatetimedatetime6NULL82410.00Using index condition; Using where ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2018, 14:51 |
|
||
|
Помощь в оптимизации запросов и увеличение скорости приложения
|
|||
|---|---|---|---|
|
#18+
GlebMatveevПравильно ли составлены таблицы?Формально - нет. Должна быть одна таблица, и в ней дополнительное поле идентификатора камеры. GlebMatveevПравильно ли выбран тип таблиц в данном случае?Для ответа нужно понимать смысл полей io (вероятно, вход-выход?) и height (ну переводится как высота, а что там на самом деле - поди догадайся). Ясность внесёте? GlebMatveevИмеет ли смысл добавлять Index? И для какого столбца?Смысл добавления индекса появляется только когда есть полный список возможных запросов, чего не наблюдается. И учтите, что индекс не обязан быть по строго одному полю... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2018, 15:24 |
|
||
|
Помощь в оптимизации запросов и увеличение скорости приложения
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответ! Прошу прощения за молчание! Отправляли в командировку. Не было времени на ответ. AkinaФормально - нет. Должна быть одна таблица, и в ней дополнительное поле идентификатора камеры. Можно тогда поинтересоваться вашим мнением по таким мыслям? 1. Что, если планируется работа со 100 устройствами? Как это будет работать? Ведь если взять информацию, которая имеется сейчас по максимуму, получаем следующее: - на одно устройство приходится 5 млн. строк за год (примерно 350 МБ); - получается, что в год будем иметь 500 млн. строк (примерно 35 ГБ); - если предположить, что срок эксплуатации системы - 15 лет, получаем 7,5 млрд. строк (525 ГБ). 2. Не лучше ли будет хранить данные с устройств отдельными таблицами в таком случае? 3. Вообще способна ли MySQL обслуживать такие данные? AkinaДля ответа нужно понимать смысл полей io (вероятно, вход-выход?) и height (ну переводится как высота, а что там на самом деле - поди догадайся). Ясность внесёте? Всё верно. Поле io - вход/выход, поле height - высота объекта. AkinaСмысл добавления индекса появляется только когда есть полный список возможных запросов, чего не наблюдается. И учтите, что индекс не обязан быть по строго одному полю... Все запросы похожи и имеют вид: Код: sql 1. В будущем планируется добавление отбора по высоте объекта, т.е. что-то вроде этого: Код: sql 1. P.S.: Экспериментировал с индексами. Получил колоссальное ускорение. В последнее время один из тяжеловесных отчётов мог формироваться до 20 минут, сейчас же с добавлением индекса (io, datetime) этот же отчёт формируется за 15 секунд. Отчёт об экспериментах в скрине. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 10:54 |
|
||
|
Помощь в оптимизации запросов и увеличение скорости приложения
|
|||
|---|---|---|---|
|
#18+
GlebMatveev, почитайте про технологию секционирования таблиц . возможно, это именно то, что вам нужно... Логически - вы будете иметь всего одну таблицу. Физически - каждая секция, по сути, будет отдельной таблицей. Секции нарежьте по-камерно. Одна камера - одна секция... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 10:59 |
|
||
|
Помощь в оптимизации запросов и увеличение скорости приложения
|
|||
|---|---|---|---|
|
#18+
GlebMatveev1. Что, если планируется работа со 100 устройствами? Как это будет работать? Ведь если взять информацию, которая имеется сейчас по максимуму, получаем следующее: - на одно устройство приходится 5 млн. строк за год (примерно 350 МБ); - получается, что в год будем иметь 500 млн. строк (примерно 35 ГБ); - если предположить, что срок эксплуатации системы - 15 лет, получаем 7,5 млрд. строк (525 ГБ). Ну Анна уже ткнула пальцем в партиционирование. Хотя я бы рассмотрел скорее секционирование по дате... тем более что все образцы запросов оперируют малой дискретностью (час, сутки). Опять же такое секционирование обеспечит более равномерное распределение данных по секциям и упростит (если возникнет такая задача) перемещение секций в архив. А вот структурку я бы пересмотрел... Во-первых, мне активно не нравится CHAR(6) для io - я бы его или ословарил или конвертировал в ENUM. Во-вторых, мне толь же активно не нравится хранение в поле height (высота) явно числового значения в поле CHAR(5). Его бы я конвертировал в числовое (в зависимости от требуемой точности или в INT, или в DECIMAL). GlebMatveev3. Вообще способна ли MySQL обслуживать такие данные? Да, вполне. Полтерабайта - это вполне себе нормальный, рабочий, объём - если под сервер не использовать слишком древний десктоп, понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 11:35 |
|
||
|
Помощь в оптимизации запросов и увеличение скорости приложения
|
|||
|---|---|---|---|
|
#18+
Akina, секционирование с подсекционированием: секции нарезать по камерам, внутри камер разделить на подсекции - subpartition по дате :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 12:37 |
|
||
|
Помощь в оптимизации запросов и увеличение скорости приложения
|
|||
|---|---|---|---|
|
#18+
Щукина Анна , а смысл? секционировать помесячно, секция будет порядка 3 гектар... какой смысл резать дальше? тем более что данные статические, неизменяемые - для прошедших периодов вполне можно просчитывать и хранить уже подготовленную статистику с вменяемой дискретностью, и незачем рабочую таблицу дёргать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2018, 12:46 |
|
||
|
|

start [/forum/topic.php?fid=47&fpage=47&tid=1829604]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 250ms |
| total: | 384ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...