Доброго дня. Возможно я изобретаю колесо, но требуется создать сервис для сбора
и обработки частых событий. События прибывают REST/POST запросом и несут в себе
немного данных в JSON. Периодически группа рабочих задач бежит по собранным
событиям и строит свои расчеты.
Требуется некий сервис/БД, оптимизированная под запись логов. В идеале такой
сервис должен представлять собой большое полотно, на котором размещены два
курсора. Один курсор только пишет, позади него курсор только читает. Казалось
бы, это простейшая работа с файлом, но есть требования:
* Курсор на запись должен писать крайне быстро, желательно без реального I/O,
сразу возвращая управление. Редкая потеря событий не проблема. Некоторым
асинхронным способом база должна регулярно сбрасывать накопленное на диск.
* В буквальном смысле сотни процессов могут одновременно писать события.
Т.к. база пишется только на добавление, никакие блокировки не допустимы.
* Чтение выполняется большими блоками и сразу после чтения данные
автоматически удаляются. Читают не более десятка процессов одновременно.
Один процесс всегда читает один блок или должен быть механизм, согласно
которому два процесса могут узнать, что прочли пересекающиеся данные.
* Данных может быть очень много. С точки зрения будущего, если такой сервис
можно собрать в кластер, то было бы совсем идеально. Иначе придется читать
чаще.
* Так как данных много, то их совсем не за чем держать в памяти попусту,
кроме как для буфера записи.
Может кто–то сталкивался с подобной задачей и может посоветовать как/куда
сбрасывать полотно с логами?
elasticsearch + logstash.
При количестве сообщений больше 10к в секунду - желательно спереди поставить очередь.
Плюсы: эластик - поисковый индекс поверх апачевской люсины, с соответствующими возможностями поиска и фильтрации. logstash - сервис, позволяющий фильтровать проходящие через него данных по динамически генерируемому набору фильтров. очень удобно для обогащения / обеднения сообщений
Не плохо, но задача несколько проще. Не требуется хранить отдельные записи или искать в них, используются только результаты процессов-аггрегаторов. С другой стороны, необходимо обеспечить ~нулевое время задержки на запись события. Собственно искомый сервис это быстрое на запись временное хранилище для событий.
Можно, но это не входит в задачу. Одно событие живет не дольше, чем будет прочитано аггрегатором. Постройка индекса это не нужные накладные расходы, а сам индекс никогда не будет использоваться. Само сообщение это немного данных в JSON и не предназначено для чтения человеком. Но возьму logstash на вооружение, хороший фильтр логов. Спасибо.
Можно, но хотелось бы готовое решение. Главная проблема - это обеспечить одновременную запись с большого множества процессов без блокировок. Может приходить 50к сообщений в секунду, в пиковые моменты много больше. При этом сами сообщения не надо выстраивать в каком либо порядке и редкие потери не страшны. Главное очень краткое О(1) время записи.
Riak хороший key-value store. Использовал его для хранения пользовательских картинок и документов - хорошо он бинарные данные хранит и отдает. Он больше ориентирован на надежность с его шустрой репликацией и кворумом. Но на запись он все таки не самый быстрый (вполне ожидаемо), проверил на своем опыте. Также как и любой key-value store нет явной последовательности ключей (лог, FIFO). В общем писать большие бинарные документы не шибко часто с высокой надежностью и быстрым доступом на чтение - Riak хорош. В качестве лога, не очень.
Хочется, таки, уточнить - у вас был опыт работы с кластером и через PB или с одной машиной и через REST? Не скажу про все версии, но во второй уже можно делать явную последовательность ключей. В моём понимании бинарные документы стоит хранить на диске - лишний оверхед ни к чему, называйся он Риаком или Посгресом.
Кластер из 3 машин, PB, клиент и приложение на питоне. Бинарные документы стоит хранить в кластере ради надежности и доступности. К примеру магазин (bodyenfitshop.nl), покупка создает снимок всех объектов (продукты, скидки, часть правил логики и т.д.) на тот момент в JSON. Снимок позволяет просматривать фактуру и пересчитывать статистику в любое время позже, не переживая, что один из десятков связанных объектов мог измениться (классическая проблема молодых магазинов). Снимок сливается в Riak. В итоге он надежно доступен (репликация) и доступен с любого из app. серверов практически мгновенно. Можно, конечно, сливать все на диск и синхронизировать rsync'ом между машинами (!задержка), или примонтировать общий диск (!задержка, не надежно), но появляется проблема с блокировками (на NFS вообще труба), IO, медленной работой ОС с директориями в сотни тысяч файлов и т.д. Короче, Riak.
Замечательная вещь для разного рода кешей, счетчиков и прочего. Но оно in-memory для быстрого доступа. Мне же требуется быстрая запись, а чтение временем не ограничено. Если мне нужен in-memory быстрая БД, то как обычно Memcached (если это кеш) -> Redis (если persistent кеш) -> MongoDB (если persistent кеш с (geo)индексами).
Кстати, MySQL с его in-memory движком тоже супер быстрая вещь, если нужна вся мощь SQL, вместо простого доступа по ключу. Поэтому хорошо знать о tarantool, но не вижу чем он лучше проверенных решений (не вижу его нишы).
