Комментарии 10
Почему-то на протяжении всей статьи думал о стандартной функции Windows — «След указателя мыши» :)
Интересная функция, похожа на очередь, но ей не является, а жаль.
Почему же не является? Вполне себе очередь. Выборка всех документов с сортировкой по стандартному, встроенному _id с хвостовым курсором -самая настоящая очередь. Потому-что обработка скриптом будет осуществлена по порядку прибытия новых документов.
что будет если создать ограниченную коллекцию на 10 элементов, и записать туда 100 элементов?
Я вижу, как минимум, 4 варианта решения этой проблемы.
1. Самый естественный. Увеличить размер буфера, которым выступает capped коллекция, до максимально возможного исходя из количества «одновременных» записей.
2. Создать буфер на запись в коллекцию со стороны приложения, который имел бы тайминг на каждую запись или чанк записей (исходя из размера коллекции), примерно равный скорости выполнения однократной доставки документов нашим хвостовым курсором.
3. Увеличить у хвостового курсора batch size, который говорит драйверу о максимальном количестве документов вытаскиваемых за раз из коллекции. Правда здесь есть внутреннее ограничение в 16 мегабайт.
4. Потратить чуть больше времени на анализ приложения и возможных пиковых загрузок и вывести гибкую формулу из представленных выше вариантов.
И конечно же это решение не будет универсальным. Ну и претендовать на таковое не могло. Фича сырая)
Прочел вот в википедии про очередь И стала ясна проблема реализации.
Получается, что мы пытаемся на Очередь с реализацией по типу массивов (что являет собою capped коллекция) навешать реализацию «Связного списка» при помощи «Двух Стеков» :)
1. Самый естественный. Увеличить размер буфера, которым выступает capped коллекция, до максимально возможного исходя из количества «одновременных» записей.
2. Создать буфер на запись в коллекцию со стороны приложения, который имел бы тайминг на каждую запись или чанк записей (исходя из размера коллекции), примерно равный скорости выполнения однократной доставки документов нашим хвостовым курсором.
3. Увеличить у хвостового курсора batch size, который говорит драйверу о максимальном количестве документов вытаскиваемых за раз из коллекции. Правда здесь есть внутреннее ограничение в 16 мегабайт.
4. Потратить чуть больше времени на анализ приложения и возможных пиковых загрузок и вывести гибкую формулу из представленных выше вариантов.
И конечно же это решение не будет универсальным. Ну и претендовать на таковое не могло. Фича сырая)
Прочел вот в википедии про очередь И стала ясна проблема реализации.
Получается, что мы пытаемся на Очередь с реализацией по типу массивов (что являет собою capped коллекция) навешать реализацию «Связного списка» при помощи «Двух Стеков» :)
Возможно наши требования и не обоснованы, но было бы очень удобно. Сейчас приходится использовать RabbitMQ, но он мне не нравится, да и ставить что-то дополнительно тоже не хочется.
Я так же думал сперва вам посоветовать RabbitMQ, из-за «не профильного» (пока-что) применения capped. Но, в последнее время, нагромождение технологий на проектах поднимает волосы дыбом на затылке. Остается надеяться, что претензия 10gen на универсальность MongoDB станет явью.
А чем не нравится раббит, если не секрет? Использую его для очередей — весьма удобная штука.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Следим за коллекцией. Tailable cursors