Постоянство на основе файлов очереди - WebSphere MQ против очереди SQLite (WAL) - PullRequest
1 голос
/ 04 февраля 2012

Я использую Websphere MQ, и он поставляется по умолчанию с «файловой очередью».Таким образом, каждая очередь обычно имеет ОДИН физический файл на диске.

Так что, скажем, для этой очереди Websphere MQ у нас есть несколько читателей и писателей .... Я предполагаю, что между чтением и записью будут некоторые издержки "блокировки в миллисекундах"Тем не менее, я гарантирую, что это все равно будет быстрее, чем использование полной базы данных, такой как DB2 и т. д.

Теперь я реализовал очередь, используя SQLite, и она успешно работает в режиме производства в режиме WAL.

Мой вопросВы действительно думаете, что в SPEED существует огромная разница между файловой очередью, используемой такими продуктами, как WebSphere MQ или SQLite?В конце концов, оба они основаны на файлах, и тот факт, что SQLIte является чистым ANSI C, делает это хорошо для скорости.

SQLIte действительно предлагает некоторые дополнительные функции, такие как «зацепки обновления» и т. Д .... и многие другие.

Полагаю, мне хотелось бы знать, собираетесь ли вы реализовать высокоскоростную постоянную очередь в C, сделаете ли вы это аналогично WebSphere MQ и получите сообщения с разными смещениями и т. Д. В одном файле илиВы используете SQLIte в режиме WAL?

Спасибо за помощь; -)

Ответы [ 2 ]

0 голосов
/ 09 февраля 2012

Чем больше ограничений вы накладываете на пример, тем больше вы, вероятно, сможете сделать числа похожими на те, которые вы хотели. Одна очередь с одним приложением? Если это ваше единственное требование, то у вас есть много вариантов.

Но взгляните на некоторые ограничения режима WAL. Контрольные пункты ждут читателей, чтобы закончить. Поэтому чем больше у вас читателей, тем сложнее проходить контрольную точку, и тем более разрушительной становится контрольная точка. Если размер файла WAL становится большим, производительность чтения снижается, поэтому вы не можете выполнять ленивые контрольные точки в занятой системе и сохранять производительность.

Итак, вопрос ", если вы собираетесь реализовать высокоскоростную постоянную очередь в C, сделаете ли вы это аналогично Websphere MQ и получите сообщения с разными смещениями и т. Д. В одном файле, или вы бы использовали SQLIte в режиме WAL?"не учитывает все требования или соображения. По мере масштабирования числа одновременно работающих пользователей архитектура процессов начинает затмевать различия в подходах хранения, о которых вы спрашиваете. WMQ может обрабатывать тысячи одновременно работающих считывателей и писателей с очень большими файлами журналов с довольно плоскими кривыми производительности, тогда как в документах WAL утверждается, что производительность пропорциональна размеру файла WAL, то есть кривые производительности снижаются по мере увеличения WAL.

Если бы I собирался реализовать высокоскоростную очередь в C? Если вы имеете в виду, какой продукт выбрать, я бы выбрал тот, который имел двадцать лет настройки и оптимизации с миллионами долларов на НИОКР, вложенные каждый из этих лет и который ориентирован исключительно на организацию очередей. Если под «внедрением» вы имеете в виду, как бы я это сделал, если бы писал новый движок очередей с нуля, то на меня бы сильно повлияли продукты, которые в течение долгого времени были сосредоточены на организации очередей, и попытался бы повторно использовать их решения. к нетривиальным проблемам. Базы данных и механизмы очередей не попали в соответствующие архитектуры хранения случайно. Один оптимизирован для очередей, а другой оптимизирован для семантики базы данных, и если вы расширяете область действия, чтобы включить базы данных и механизмы организации очередей, отличные от WMQ и SQLite, это в целом верно для всех категорий.

Полное раскрытие: я работал с WMQ большую часть двадцати лет, в течение которых он существует, и недавно присоединился к его команде по управлению продуктами в IBM. Я могу быть немного предвзятым, но я попытался сосредоточиться на технологии здесь, а не на коленях «мой продукт лучше, чем ваш продукт». Не стесняйтесь подписать соглашение с положительными голосами, несогласие с отрицательными голосами. Я заберу ответ, если он получит слишком много отрицательных голосов.

0 голосов
/ 07 февраля 2012

При наличии одного производителя сообщений WMQ 7 с параметрами ведения журнала по умолчанию (двойное или тройное циклическое ведение журнала) будет хранить примерно 300-400 постоянных сообщений в секунду на жестком диске моего ноутбука 7200 с использованием API-интерфейса mqjms при использовании настолько быстрого кода jms, насколько это реально возможноожидаемый (один сеанс, один производитель сообщений, буферизация на каналах) и небольшой размер сообщения (байтовое сообщение с размером полезной нагрузки <1k).В этом случае жесткий диск является узким местом. </p>

Вы получите более высокую скорость, используя меньшее количество входов в систему на стороне QM.Это масштабируется довольно линейно.Также помогает использование непостоянных сообщений.

Другая распространенная проблема - сетевой уровень.Обмен сообщениями обычно заключается в отправке небольших сообщений размером не более нескольких килобайт.Используя общий сетевой код (открытое соединение / открытый сеанс / открытый производитель / и обратно) от одного пользователя, вы столкнетесь с ограничениями TCP до того, как HDD заработает. Чтобы избежать этих проблем, WMQ позволяет пакетировать сообщения по каналам.

Я сомневаюсь, чтоХранение постоянных сообщений в WMQ с ведением журнала по умолчанию быстрее, чем вставка BLOB-объекта в DB2.Основной механизм в основном одинаков (журналы транзакций, rec / ack, ...).

Я никогда не пытался сравнивать его с SQLLite.

WMQ - это решение не для быстрой передачи сообщений,Это также не самое простое решение для управления.Таким образом, у него есть яркие стороны, и, на мой взгляд, это один из лучших продуктов.

...