DjonDB суббота, марта 09, 2013

Здравствуйте!
Я бы хотел рассказать о своём опыте использования DjonDB, о том с какой задачей я столкнулся, почему решил использовать NoSQL решение и почему использовал DjonDB.

Мы занимаемся внедрением услуги IPTV, надо было организовать сервер мониторинга качества сигнала с серверов IPTV. На серверах стояла программа, которая могла отправлять статистику о сигнале и каждом канале на сервер мониторинга в формате JSON.
Были, конечно, и syslog сообщения. Но действительно информативные сообщения, получали именно в формате JSON. Вот, например:


{"stream":"Stream#1",
"type":"channel",
"bitrate":935936,
"output":"udp:\/\/@239.255.1.2:1014",
"server":"iptv",
"ready":true,
"channel":"Channel2",
"time":1361696024}

{"stream":"Stream#1",
"adapter":1,
"type":"dvb",
"bitrate":14710784,
"lock":true,
"server":"iptv",
"unc":0,
"snr":59,
"ber":0,
"time":1361695904}

И другие подобные...

Итак, нужно хранилище, нужно распарсить JSON, определить соотношения таблиц, предупредить изменение формата сообщений, так как софт постоянно меняется, формат сообщений может измениться, могут появиться дополнительные поля и сообщения.
Также, могут добавлены dvb адаптеры или количество каналов, а это не связано с обновлением софта.

Надо ли парсить JSON? Удобно ли с ним работать на клиентской стороне? Лучше использовать базу с нативной поддержкой JSON :) Таким образом мы можем решить проблемы и с изменяющимся форматом сообщений: сообщения как есть попадут в базу.
Это правда не отменяет работу по выборке новых сообщений, но зато работы в 2 раза меньше: теперь надо только дополнить интерфейс к ним.

Есть много NoSQL решений, но как оказалось не все нам подходят. MongoDB ограничена объемом в 4ГБ для 32-битных систем, и не устойчива к падениям, CouchDB предполагает знания о содержании сообщений. Мы моглибы использовать Redis, но нам показалось гораздо удобнее именно DjonDB :) Устойчива к падениям, не требовательна к архитектуре, быстро работает, позволяет совершать выборку по любым полям и простая в использовании.
Всё в одном.

И действительно мы не проиграли! Интуитивно понятный язык запросов Djondb и нативная работа с JSON документами сделала работу над мониторингом максимально прозрачной. Я сделал интерактивные графики отображения качества сигнала с помощью morris.js. Работа над ними была дествительно прозрачна. Я просто запрашивал документы и отдавал morris в браузере:
Пример на php:

$hret=$this->djc->find('astra', 'astralog'.$lastday, '$"stream","$"unc",$"ber",$"snr",$"time"', '$"stream"=="Stream#1" and $"type"=="dvb" and $"time">'.$lasthour);
for ($i = 0; $i < $hret->size(); $i++) {
if ($i!=0){
$result.=',';
}
$result.=$hret->get($i)->toChar();
}
$result.=']';


Конечно, здесь возможны атаки типа "injection", но в нашем случае сервер мониторинга знает откуда могут приходить сообщения и им доверяет. В идеальном случае нужно, конечно фильтровать данные на предмет ожидаемого типа данных.

Juan Pablo Crossley подсказал решение проблемы, которая начинала появляться: быстрая очистка логов. Решение оказалось простым как и всё гениальное :). Мы стали использовать разные пространства имён, для сохранения данных в разные месяцы, для последующего удаления устаревших.

Пока я вёл разработку у меня возникали вопросы и сложные ситуации, но коммьюнити мне очень помогало. Проект DjonDB продвигается очень быстро, имеет колосальную поддержку!

На очереди следующий проект и я готовлюсь снова использовать DjonDB. Присоединяйтесь!

Ярлыки

Популярные сообщения