Подскажите готовое решение для асинхронной работы с SQL БД (в частности - вставки данных), с очередью, дампом\рестором в случае падения и т.п.

Поясню.
Имеется высоконагруженный сервер (порядка M запросов\сек). Необходимо все запросы загонять в постоянное хранилище с последующими генерациями отчетов. Лучше всего для данной задачи в качестве хранилища подходит SQL БД. Но есть огромная проблема - скорость вставки в SQL БД, которая равна N, причем N много меньше M. О синхронной вставке не может быть и речи. Таким образом, необходимо реализовать очередь, причем для надежности в отдельном процессе, с постоянной памятью и дампом\восстановлением в файл и прочими наворотами в случае падения даже этого отдельного процесса.
Вопрос в следующем: есть ли какие-либо готовые решения? Конечно, можно реализовать этот велосипед самостоятельно, но нет времени, и не верится, что нет готового решения, написанного, отлаженного и выложенного в открытый доступ. Единственное ограничение - коммерческие решения не подходят.
p.s. искал много и долго, но ничего не нашел. Вообще. Как будто такой проблемы не существует.

кое-что конечно же нашлось, но к огромному удивлению - все с приставкой "windows" - ms sql service broker и azure, и то они лишь отдаленно напоминают необходимый мне инструмент.

SERG1257С этого момента поподробнее - чем занимается ваш сервер. (в хрустальном шаре я вижу некую OLTP базу с M транзакций\сек)
в данном случае неважно - пусть это будет простой echo-сервер, а в базу нужно складывать все запросы клиентов, как лог.
SERG1257Наверное некоторые запросы (типа отчет) лучше будет выполнять на отдельном сервере, так?
безусловно, отчеты будут генериться на отдельном сервере. В данном случае это тоже не важно - это уже задача репликации.
SERG1257Этот самый отчетный сервер вы хотите реализовать на базе MS SQL server, так?
нет, он не подходит из-за коммерческ. лицензий.
SERG1257У вас не получилось организовать синхронную вставку, так?
фактически да. Синхронная вставка делает ответ echo-сервера клиенту недопустимо медленным (скажем, в десятки раз).
SERG1257Почему? По религиозным соображениям или просто денег нет?
изначально так задача не стояла. Просто если такой простой механизм, как менеджер очерди, потянет за собой коммерческое хранилище и еще кучу ненужных вещей, то это вообще не то решение. И да, денег нет ).
[quote alexeyvg]Так вставляйте асинхронно в отдельном процессе./quote]
спасиб )
alexeyvgА тут нестыковочка - вам нужна отдельная СУБД для такого хранения, причём она будет работать синхронно. Соответственно, не будет-ли медленно работать уже эта другая СУБД?
тут мое упущение - важный момент. Нагрузка на мой сервер непостоянна. Т.е. за периоды "затишья" накопившаяся очередь гарантированно опустошиться. Но в периоды нагрузки - работа с постоянным хранилищем должна быть асинхронной.
alexeyvgОбычно в таких случаях делают асинхронную запись в СУБД и дополнительно запись в файлы для надёжности и восстановления на случай даунтайсма сервера.
именно изобретательством данного велосипеда я и не хочу заниматься.

Чтоб стало более понятно - gearman впринципе очень близко к тому, что мне нужно - у него и очереди хранятся в постоянной памяти (в той же SQL БД), и распараллеливание. Но судя по номеру последней версии (0.14), кол-ву багов и новизне - это не решение для продакшн системы. Пока его не удалось даже собрать с девятым постгресом. И вообще - он несколько другой направленности, в основном распареллелить задачи, хотя используя его возможности можно реализовать то что и мне нужно.

spВ последних версиях SQL сервера есть потоковая вставка данных - именно то что вам необходимо
yточните пожалyйста - какого именно сервера. Если MS - то он не подходит по описаным выше причинам. Неyжели только MS реализовал потоковю вставкy?

SERG1257Я бы направил вывод вашего сервера в текстовый файл, а затем по какому либо событию (по таймеру например и/или по достижению определенного размера) переключал лог, а свежезакрытый файл качал в СУБД. Если это велосипед, то удачи вам в поисках оптимального решения.
я дyмал об этом решении, но оно не подходит по причине ограниченности возможностей известных мне серверов. Например, необходимо вызвать несколько хранимых процедyр (раскидать данные по нескольким таблицам) внyтри основного запроса. Постгресовский COPY очень примитивен в этом плане, MYSQL-ный полyчше, но тоже недостаточно гибок. И, опять же - идет привязка к БД. Дyмаю, придется все же добивать gearman.

p.s. становится понятно, почемy так много коммерческих решений крyтятся на MS SQL, они оказывается единственные, кто реализовал реальнyю OLAP-системy. Еще есть y оракла job-ы, но она тоже стоит денег. postgres и mysql явно облажались здесь, хотя это вообще не задача БД - я как раз ищy отдельный менеждер очереди.

пока отвечу себе сам - вот интересный тест по моему вопросу:
http://bhavin.directi.com/rabbitmq-vs-apache-activemq-vs-apache-qpid/
Это, так сказать, классические решения.
Судя по объемам кода - реализовывать все это, пусть даже не так универсально, точно жесть.

Полностью реализовал все с qpid, повертел, вроде работает, но там целая эпопея с версиями (единственная рабочая версия у них лежит только в trunk-е, они там на форумах до сих пор не могут определиться как реализованы у них persistent очереди, спорят друг с другом и непонятно кто вообще пишет код в этом проекте). Итог: общее впечатление - сильно все усложнено и ненадежно. Решил теперь реализовать запись в файл и cron-ом закидывать в базу COPY (или pg_bulkload-ом). Просто и надежно.

Насколько я понял - ApacheMQ использует qpid.
А даже возможностей qpid-а для моей задачи оказалось слишком много.