Случайно нашел интерестное программное решение. Q4M — иммитация сервера очереди сообщений посредством MySQL сервера (начиная с версии 5.1). Написано что fast, robust и flexible (интерестно, бывает что-нибудь одно?). Однако, дозволяются условные выборки из очереди, несмотря на то, что в limitations указано, - индексы при этом не используются.
Вообще, довольно трудно представить себе где бы могла мне пригодится такая очередь сообщений. Cуществует куча бесплатных специализированных решений, которые создавались специально для обработки очередей сообщений. Взять хотя бы ActiveMQ или JBossMQ. Поддержка транзакционности, оптимизирована для быстрой вставки (в принципе, как и любая другая MQ система), поддержка практически всех популярных скриптовых языков посредством STOMP, встроенный message router, поддержка репликации, поддержка forward on demand bridge и куча еще чего. Учитывая то, что MQ системы обычно применяются либо при интеграции приложений либо в целях масштабируемости приложений (что говорит о больших обьемах данных), непонятно зачем нужно решение подобное Q4M. Рано или поздно вы упретесь в пропускную способность sql-сервера по чтению, добавите slave серверов, а затем упретесь в ту же пропускную способность, но уже по записи. И тут уже никакая репликация не спасет.
Справедливости ради надо отметить, что Q4M предоставлят возможности, которых в других mq системах нет. Например, conditional consuming и join’ы очередей с обыкновенными таблицами! В принципе, кому-то может пригодится. Ebay, если верить некоторым источникам1, использует самописный messaging стек, который поддерживает conditional consuming. Это упрощает использование очереди, да и EIP2 была бы раза в два тоньше. Вот только за все приходится платить, и за удобство использования тоже. Особенно, когда за очередью прячется реляционная база данных. В данном случае платить придется производительностью, failover’ом и масштабирумостью.