Длительный процесс статистики - мысли о выборе языка?

Question

Я нахожусь в стеке LAMP для веб-сайта, которым я управляю. Необходимо свернуть статистику использования (различные вещи, связанные с нашим настольным продуктом).

Сначала я решил проблему с PHP (поскольку у меня уже было несколько классов для работы с данными). Все хорошо работало на моем устройстве dev, которое использовало 5.3.

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

Для майнинга баз данных MySQL, чтобы свести статистику за разные периоды и разрешения, потенциально запустив процесс, который делает это постоянно (в отличие от расписания cron), какой язык вы порекомендуете? Я смотрел на Python (я знаю это более или менее), Java (плохо знаю) или высовывал его с помощью PHP (знаю это очень хорошо).

---

Редактировать: уточнение проекта для комментатора

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

SQL Strat: Базовая статистика находится во многих разнородных схемах и таблицах. Я делаю отдельные запросы для каждой свернутой статистики по большей части, затем заполняю одну запись для вставки. Вы предлагаете вложенные подзапросы, такие как:

ВСТАВИТЬ в roll_up_stats (someval, someval, someval, ...) ЗНАЧЕНИЯ (ВЫБРАТЬ СУММУ (somestat) из someschema, ВЫБРАТЬ AVG (somestat2) из ​​someschema2)

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

Редактировать 2: Добавление некоторых встроенных ответов на вопрос

Язык был узким местом в случае 5.1 php - мне сказали, что я сделал неправильный выбор языка (хотя скрипты работали нормально на 5.3). Вы упоминаете Python, который я проверяю для этой задачи. Чтобы было ясно, я делаю инструмент управления статистикой использования настольного продукта (журналы фактически записываются сервером EJB в таблицы mysql). Я занимаюсь анализом файлов журнала Apache, а также создаю больше пользовательских веб-отчетов на веб-стороне, но этот проект является отдельным. Подход, который я использовал до сих пор, - это агрегированные таблицы. Я не уверен, что эти продукты очереди сообщений могли бы сделать для меня, я посмотрю.

Пройдем немного дальше - эти данные используются для составления графика активности на уровне службы и клиента, чтобы руководство могло понять, как используется продукт. Вы можете выбрать период времени (с 1 по 10 апреля) и получить график общего количества минут использования определенной функции с различной степенью детализации (часы, дни, месяцы и т. Д.) В зависимости от выбранного периода времени. Это, по сути, анализ использования после факта. Однако, похоже, что потребность стремиться к реальному времени (посмотрите на последний час использования)

Answer 1

В прошлом я работал над проектом, чтобы сделать подобное, поэтому у меня есть реальный опыт работы с производительностью. Вам было бы трудно преодолеть исполнение «INSERT ... SELECT» (а не «INSERT ... VALUES (SELECT ...)». Пожалуйста, смотрите http://dev.mysql.com/doc/refman/5.1/en/insert-select.html

Преимущество состоит в том, что если вы это сделаете, особенно если вы сохраняете сводный код в процедурах MySQL, то все, что вам нужно извне, - это просто работа cron, чтобы подтолкнуть БД к выполнению правильных сверток в нужное время - так же просто, как сценарий оболочки с 'mysql <correct DB arguments etc.> "CALL RollupProcedure"'

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

РЕДАКТИРОВАТЬ: почасовое разрешение в порядке - просто запустите почасовую работу cron ...

Answer 2

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

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

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

Если у вас есть тонны и тонны данных, и вам нужны таблицы агрегирования, вам следует изучить разгрузку сбора статистики (и, возможно, самой базы данных) в очередь, такую ​​как RabbitMQ или ActiveMQ. На другой стороне очереди разместите потребительский демон, который просто сидит и работает все время, обновляя данные в базе данных (и, возможно, в кэше) по мере необходимости.

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

Я сделал все это с Python (я выпустил loghetti , в частности, для работы с журналами комбинированного формата Apache), хотя я не думаю, что язык является ограничивающим фактором или узким местом. Ruby, Perl, Java, Scala или даже awk (в некоторых случаях) будут работать.

Answer 3

Если вы в основном используете команды SQL, почему бы просто не использовать MySQL и т. Д. В командной строке? Вы можете создать простую таблицу со списком агрегированных данных, а затем выполнить команду, например mysql -u[user] -p[pass] < commands.sql, для передачи SQL из файла.

Или разделите работу на более мелкие куски и запускайте их последовательно (как файлы PHP, если это проще всего).

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