Доброго дня. Возможно я изобретаю колесо, но требуется создать сервис для сбора
и обработки частых событий. События прибывают REST/POST запросом и несут в себе
немного данных в JSON. Периодически группа рабочих задач бежит по собранным
событиям и строит свои расчеты.
Требуется некий сервис/БД, оптимизированная под запись логов. В идеале такой
сервис должен представлять собой большое полотно, на котором размещены два
курсора. Один курсор только пишет, позади него курсор только читает. Казалось
бы, это простейшая работа с файлом, но есть требования:
* Курсор на запись должен писать крайне быстро, желательно без реального I/O,
сразу возвращая управление. Редкая потеря событий не проблема. Некоторым
асинхронным способом база должна регулярно сбрасывать накопленное на диск.
* В буквальном смысле сотни процессов могут одновременно писать события.
Т.к. база пишется только на добавление, никакие блокировки не допустимы.
* Чтение выполняется большими блоками и сразу после чтения данные
автоматически удаляются. Читают не более десятка процессов одновременно.
Один процесс всегда читает один блок или должен быть механизм, согласно
которому два процесса могут узнать, что прочли пересекающиеся данные.
* Данных может быть очень много. С точки зрения будущего, если такой сервис
можно собрать в кластер, то было бы совсем идеально. Иначе придется читать
чаще.
* Так как данных много, то их совсем не за чем держать в памяти попусту,
кроме как для буфера записи.
Может кто–то сталкивался с подобной задачей и может посоветовать как/куда
сбрасывать полотно с логами?
Riak хороший key-value store. Использовал его для хранения пользовательских картинок и документов - хорошо он бинарные данные хранит и отдает. Он больше ориентирован на надежность с его шустрой репликацией и кворумом. Но на запись он все таки не самый быстрый (вполне ожидаемо), проверил на своем опыте. Также как и любой key-value store нет явной последовательности ключей (лог, FIFO). В общем писать большие бинарные документы не шибко часто с высокой надежностью и быстрым доступом на чтение - Riak хорош. В качестве лога, не очень.
Хочется, таки, уточнить - у вас был опыт работы с кластером и через PB или с одной машиной и через REST? Не скажу про все версии, но во второй уже можно делать явную последовательность ключей. В моём понимании бинарные документы стоит хранить на диске - лишний оверхед ни к чему, называйся он Риаком или Посгресом.
Кластер из 3 машин, PB, клиент и приложение на питоне. Бинарные документы стоит хранить в кластере ради надежности и доступности. К примеру магазин (bodyenfitshop.nl), покупка создает снимок всех объектов (продукты, скидки, часть правил логики и т.д.) на тот момент в JSON. Снимок позволяет просматривать фактуру и пересчитывать статистику в любое время позже, не переживая, что один из десятков связанных объектов мог измениться (классическая проблема молодых магазинов). Снимок сливается в Riak. В итоге он надежно доступен (репликация) и доступен с любого из app. серверов практически мгновенно. Можно, конечно, сливать все на диск и синхронизировать rsync'ом между машинами (!задержка), или примонтировать общий диск (!задержка, не надежно), но появляется проблема с блокировками (на NFS вообще труба), IO, медленной работой ОС с директориями в сотни тысяч файлов и т.д. Короче, Riak.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.