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