История изменений

Не подскажешь, насколько «сильно жрут» память и диск? Прямо сейчас перевожу свой проект на RabbitMQ с хранимыми очередями и «ручным» подтверждением

Раббит жрёт пропорционально длине автогенерируемых ключей. Ключи там имеют длину порядка 15-20 байт (наверно! я точно не знаю). И плюс всякий RAM оверхед на индексы для мгновенного поиска. Ручное подтверждение особо не влияет на прожорливость, ибо память в эрланге вычищается не резко. Влияет именно длина очереди и характер её разгрузки. Для замера можешь загрузить 10000 элементов в очередь и прикинуть расходы RAM на более длинные очереди.

Я использовал раббит на задаче «очередь ссылок для одного кравлера», т.е. когда очередь растет резко и скачками, а потом мееедленно спадает. Уже не помню точных величин очередей, но там были десятки очередей с сотнями тысяч элементов. И раббит успешно лёг на отдельном сервере с 64 Гб RAM. Когда он лёг на такой RAM, его уже не поднять (см. далее).

Ещё одна проблема с длинными очередями - у раббита многое храниться в мнезии. А мнезия на диске - это dets (file-based kv-хранилище). А жирные файлы dets означают, что после перезапуска кролика будешь долго ждать, пока эрланг прочитает все файлы dets и выстроит ключи мнезии в RAM (а это реально медленный процесс на базе от 1-2Гб). Т.е. если упадет от жирности, то уже не поднимешь - банально не дождёшься или он грохнется снова на пол-пути.

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

В раббите вообще нет возможности добавлять в начало очереди. Бывает, что есть элемент, который нужно обработать ASAP и нет времени ждать ещё 10к элементов. Для такой приоритезации надо поднимать две очереди (например: «my_queue.1», «my_queue.2»), и AMQP-клиенты будут поочередно опрашивать две очереди: сначала почти всегда пустую my_queue.1 и почти всегда полную «my_queue.2». Это неудобно, напряжно, лишние такты cpu, лишний траффик, лишний код и т.д.

НЕ советую использовать раббит именно как менеджер очередей. Это брокер сообщений, который может поддерживать гарантию и очередность доставки. Если ожидается длинная очередь, которая будет расти в будущем, то могу посоветовать группировать по 200-300 элементов в сегмент, сегмент сжимать в gzip и сохранять в нумерованный файл на диске :D

Не подскажешь, насколько «сильно жрут» память и диск? Прямо сейчас перевожу свой проект на RabbitMQ с хранимыми очередями и «ручным» подтверждением

Раббит жрёт пропорционально длине автогенерируемых ключей. Ключи там имеют длину порядка 15-20 байт (наверно! я точно не знаю). И плюс всякий RAM оверхед на индексы для мгновенного поиска. Ручное подтверждение особо не влияет на прожорливость, ибо память в эрланге вычищается не резко. Влияет именно длина очереди и характер её разгрузки. Для замера можешь загрузить 10000 элементов в очередь и прикинуть расходы RAM на более длинные очереди.

Я использовал раббит на задаче «очередь ссылок для одного кравлера», т.е. когда очередь растет резко и скачками, а потом мееедленно спадает. Уже не помню точных величин очередей, но там были десятки очередей с сотнями тысяч элементов. И раббит успешно лёг на отдельном сервере с 64 Гб RAM. Когда он лёг на такой RAM, его уже не поднять (см. далее).

Ещё одна проблема с длинными очередями - у раббита многое храниться в мнезии. А мнезия на диске - это dets (file-based kv-хранилище). А жирные файлы dets означают, что после перезапуска кролика будешь долго ждать, пока эрланг прочитает все файлы dets и выстроит ключи мнезии в RAM (а это реально медленный процесс на базе от 1-2Гб). Т.е. если упадет от жирности, то уже не поднимешь - банально не дождёшься или он грохнется снова на пол-пути.

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

Если длинная очередь, то в раббите вообще нет возможности добавлять в начало очереди. Бывает, что есть элемент, который нужно обработать ASAP. Для такой приоритезации надо поднимать две очереди (например: «my_queue.1», «my_queue.2»), и AMQP-клиенты будут поочередно опрашивать две очереди: сначала почти всегда пустую my_queue.1 и почти всегда полную «my_queue.2». Это неудобно, напряжно, лишние такты cpu, лишний траффик, лишний код и т.д.

НЕ советую использовать раббит именно как менеджер очередей. Это брокер сообщений, который может поддерживать гарантию и очередность доставки. Если ожидается длинная очередь, которая будет расти в будущем, то могу посоветовать группировать по 200-300 элементов в сегмент, сегмент сжимать в gzip и сохранять в нумерованный файл на диске :D

Не подскажешь, насколько «сильно жрут» память и диск? Прямо сейчас перевожу свой проект на RabbitMQ с хранимыми очередями и «ручным» подтверждением

Раббит жрёт пропорционально длине автогенерируемых ключей. Ключи там имеют длину порядка 15-20 байт (наверно! я точно не знаю). И плюс всякий RAM оверхед на индексы для мгновенного поиска. Ручное подтверждение особо не влияет на прожорливость, ибо память в эрланге вычищается не резко. Влияет именно длина очереди и характер её разгрузки. Для замера можешь загрузить 10000 элементов в очередь и прикинуть расходы RAM на более длинные очереди.

Я использовал раббит на задаче «очередь ссылок для одного кравлера», т.е. когда очередь растет резко и скачками, а потом мееедленно спадает. Уже не помню точных величин очередей, но там были десятки очередей с сотнями тысяч элементов. И раббит успешно лёг на отдельном сервере с 64 Гб RAM. Когда он лёг на такой RAM, его уже не поднять (см. далее).

Ещё одна проблема с длинными очередями - у раббита многое храниться в мнезии. А мнезия на диске - это dets (file-based kv-хранилище). А жирные файлы dets означают, что после перезапуска кролика будешь долго ждать, пока эрланг прочитает все файлы dets и выстроит ключи мнезии в RAM (а это реально медленный процесс на базе от 1-2Гб). Т.е. если упадет от жирности, то уже не поднимешь.

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

Если длинная очередь, то в раббите вообще нет возможности добавлять в начало очереди. Бывает, что есть элемент, который нужно обработать ASAP. Для такой приоритезации надо поднимать две очереди (например: «my_queue.1», «my_queue.2»), и AMQP-клиенты будут поочередно опрашивать две очереди: сначала почти всегда пустую my_queue.1 и почти всегда полную «my_queue.2». Это неудобно, напряжно, лишние такты cpu, лишний траффик, лишний код и т.д.

НЕ советую использовать раббит именно как менеджер очередей. Это брокер сообщений, который может поддерживать гарантию и очередность доставки. Если ожидается длинная очередь, которая будет расти в будущем, то могу посоветовать группировать по 200-300 элементов в сегмент, сегмент сжимать в gzip и сохранять в нумерованный файл на диске :D

Не подскажешь, насколько «сильно жрут» память и диск? Прямо сейчас перевожу свой проект на RabbitMQ с хранимыми очередями и «ручным» подтверждением

Раббит жрёт пропорционально длине автогенерируемых ключей. Ключи там имеют длину порядка 15-20 байт. И плюс всякий RAM оверхед на индексы для мгновенного поиска. Ручное подтверждение особо не влияет на прожорливость, ибо память в эрланге вычищается не резко. Влияет именно длина очереди и характер её разгрузки. Для замера можешь загрузить 10000 элементов в очередь и прикинуть расходы RAM на более длинные очереди.

Я использовал раббит на задаче «очередь ссылок для одного кравлера», т.е. когда очередь растет резко и скачками, а потом мееедленно спадает. Уже не помню точных величин очередей, но там были десятки очередей с сотнями тысяч элементов. И раббит успешно лёг на отдельном сервере с 64 Гб RAM. Когда он лёг на такой RAM, его уже не поднять (см. далее).

Ещё одна проблема с длинными очередями - у раббита многое храниться в мнезии. А мнезия на диске - это dets (file-based kv-хранилище). А жирные файлы dets означают, что после перезапуска кролика будешь долго ждать, пока эрланг прочитает все файлы dets и выстроит ключи мнезии в RAM (а это реально медленный процесс на базе от 1-2Гб). Т.е. если упадет от жирности, то уже не поднимешь.

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

Если длинная очередь, то в раббите вообще нет возможности добавлять в начало очереди. Бывает, что есть элемент, который нужно обработать ASAP. Для такой приоритезации надо поднимать две очереди (например: «my_queue.1», «my_queue.2»), и AMQP-клиенты будут поочередно опрашивать две очереди: сначала почти всегда пустую my_queue.1 и почти всегда полную «my_queue.2». Это неудобно, напряжно, лишние такты cpu, лишний траффик, лишний код и т.д.

НЕ советую использовать раббит именно как менеджер очередей. Это брокер сообщений, который может поддерживать гарантию и очередность доставки. Если ожидается длинная очередь, которая будет расти в будущем, то могу посоветовать группировать по 200-300 элементов в сегмент, сегмент сжимать в gzip и сохранять в нумерованный файл на диске :D