регистриране/статистика на времеви редове - мащабируемо решение

Съвсем обичайно е да се правят заявки към база данни или регистрационни файлове за информация за времето на работа или за брой заявки за даден интервал от време.

Докато събирате все повече и повече данни, SQL заявките или обхождането на регистрационния файл стават все по-бавни и по-бавни (представете си 10 милиона реда на таблица / редове на регистрационния файл).

Типични въпроси:

  • Колко задачи обработихме през последните x месеца?
  • Каква беше наличността на нашата услуга през последния период от време X?
  • Средният брой заявки за последния час по-висок ли е от средния за последния 1 ден?

Бих искал да използвам хранилище за ключ-стойност: много кофи с различно автоматично изтичане - за да можем да разгледаме напр. 10 минути/1 час/1 ден кофи и сумирайте всички елементи там и гордо кажете „през последните 10 минути обработихме 10^6 заявки“.

Сигурен съм, че MongoDB или Redis предлагат изтичане на времето в кофи - просто съм малко притеснен дали внедряването ще бъде лесно.

Как бихте разрешили това? Знаете ли по-добри инструменти за тази задача?

(нашият проект е написан на java и python)


java nosql mongodb key-value scalability
person Martin V.    schedule 23.05.2013    source източник
comment
Първата ми мисъл беше да използвам малко AOP, за да уловя KPI данните, които искате, но с използването на python също предполагам, че няма да работи. Някои мои клиенти използват Zabbix (zabbix.com) за улавяне на KPI на Mysql и Webserver.   -  person Scary Wombat    schedule 23.05.2013

Отговори (3)


arrow_upward
0
arrow_downward

Бих предложил различен концептуален подход...

Нека си представим, че имате журнална таблица, която регистрира заявка. Ето как бих решил проблема с отчитането на данните от регистрационния файл:

  1. Започнете да съхранявате регистрационни данни в таблица.
  2. След като регистрационната таблица достигне 1 милион записа, изпращате цялата таблица в хранилище за данни. Основно „архивиране“ на данните, така че по-бавните заявки да могат да ги засегнат по-късно.
  3. Направете моментна снимка на агрегиране офлайн на данните, които току-що сте архивирали. Управлявайте работа, която получава числата, които търсите.
  4. Напишете код за обединяване на заявки в реално време и - ако е необходимо - архивирани заявки.

Идеята на голямата картина е, че данните в регистрационния файл са статични, след като е готово. Можете да извършите агрегиране на данните веднъж и те никога няма да се променят. Така че защо да го правим в реално време всеки път?

Искате да направите вашите данни в реално време много малки и бързи. По-старите данни или имат бързо търсене за известни агрегати, или обработката отнема повече време.

person ryan1234    schedule 28.05.2013

arrow_upward
0
arrow_downward

CouchDB вторичните индекси / изгледи разкриват вашите данни в O(log n) time и са лесни за внедряване и взаимодействие, тъй като всичко стои зад RESTful HTTP API. Виж това:

  • Един вторичен индекс индексира вашите регистрационни събития по кога са създадени и ги редуцира до брой, използвайки вградената _count функция за намаляване.
  • Друг вторичен индекс може да индексира само събития в регистрационния файл, показващи престой, или време на работа, или 500 секунди, или еднорози. Ключът е, че всички те са като 3-редови функции, които работят логаритмично.
  • Чрез заявки с startkey=[timestamp for X days ago] можете да преброите само записите в журнала от този момент.
  • Чрез запитване с reduce=false можете да върнете самите записи в журнала, въведени по дата на създаване.
  • Използвайте други вградени редуциращи функции като _stats, за да получите, добре, статистика за вашите регистрационни файлове.

CouchDB има клиентски библиотеки за Java и Python, но в крайна сметка е само RESTful HTTP API, така че всяка HTTP библиотека трябва да свърши работа също толкова добре.

person garbados    schedule 30.05.2013

arrow_upward
0
arrow_downward

Можете да използвате RDDTool за това. http://oss.oetiker.ch/rrdtool/ IT е много полезна библиотека за регистриране на време- серийни данни и създаване на графики с тях.

person qgicup    schedule 15.06.2013