Стратегия аналитической панели - PullRequest
0 голосов
/ 12 октября 2011

В настоящее время мы разрабатываем API и хотим предоставить аналитическую панель для наших клиентов, чтобы просматривать показатели своих звонков в месяц / день / час.

Текущая стратегия, о которой мы думали, заключается в том, чтобы сохранять каждый вызов в отдельной таблице клиента (например, звонки_ {client_id}) по историческим причинам и иметь сводную таблицу (например, звонки_суммы), содержащую количество вызовов за данный час день для каждого клиента.

Затем каждый день задание cron будет создавать xml-файл со сводкой вызовов за последний день для каждого клиента, и панель мониторинга будет использовать их вместо базы данных. Таким образом, единственной аналитической задачей, которая будет использовать базу данных, будет задание cron.

Для инфраструктуры мы рассматриваем репликацию MySQL, а ведомое - как базу данных аналитики.

Является ли эта стратегия полезной и действительной для реальной веб-статистики? Можете ли вы предложить какой-либо тюнинг на этом или даже совершенно другой?

Ответы [ 2 ]

1 голос
/ 12 октября 2011

сохранить каждый вызов в отдельной таблице клиента (например, call_ {client_id}) по историческим причинам

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

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

Любая предварительная консолидация данных в другую таблицу (при условии, что вы получаете сокращение числа строк не менее чем на 95%). Но не пытайтесь преобразовать его в XML до тех пор, пока вам не понадобятся данные в этом формате.

Что касается предварительной консолидации .... либо используйте консолидацию на основе периодов (например, сверните по дате), либо используйте пометки для записи, какие записи уже были консолидированы.

Чем реже вы выполняете консолидацию, тем больше влияние на производительность. Но запускайте его слишком часто, и у вас будут проблемы с конфликтами / блокировками.

Не зная много о структуре и объеме данных или ограничениях с точки зрения бюджета, доступности и своевременности, трудно найти оптимальное решение. Но если бы я был, я бы, вероятно, пошел с 3-мя уровнями mysqld - один обеспечивает средство транзакционной записи, один реплицирует эти данные и генерирует консолидированные данные, а другой обеспечивает доступ для чтения консолидированных данных (master <-> master <- > раб)

0 голосов
/ 12 октября 2011

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

client: id, name, address, ...
call: id, client_id, created_at, duration, ...
calls_summary: id, client_id, date_start, date_end, nb_calls

Теперь, если вы хотите получить все вызовы клиента, вы идете так:

SELECT * FROM client
LEFT JOIN call ON call.client_id = client.id
WHERE client.id = 42

Или:

SELECT * FROM call where client_id = 42

Я не вижу причин для использования xml, ваш cron может просто обновлять таблицу Call_Summary.

...