Должен получится один из самых быстрых вариантов на чтение, т.к. по по одному значению вытаскивается вся информация по товару, не бегая по индексу и шардам.
Попробуйте указать сортировку:
db.obj.find({}).sort({_id: 1}).skip(500000).limit(1)
без сортировки запрос работал без индекса (просто перебор), с сортировкой гораздо быстрее.
Так же можно разбить коллекцию на несколько, например по 10к в каждой, тогда получать будет посложнее, но быстрее.
Так же можно "вешать метки" на документы или делать на них ссылки в отдельной коллекции, например "помечать" каждый 1000-ый документ, и для запроса быстро находить нужную тысячу и для неё делать запрос.
ни в чем, просто это почти тоже самое что с монгой, тот же лаг (период) опроса и "ддос" сервера.
А забирать эти данные должен клиент, спамить ajax запросам flask? или как в предлагаете?
Вопрос в том, что если продолжать писать данные в диапазон заполненной ноды?
> нода осталась как read/delete only.
т.е. ES перестает работать (на запись)?
Это не важно, получается что пакеты от клиента до vs2 долетают через vs1 (с пом. 1-го правила), а vs2 отвечает не обратно через vs1, а куда-то в 3-ее место, которое не знает куда пакет отправлять и он дропается, поэтому и не получается достучатся до сервера.
в теории если это 3-ее место будет правильно отправлять пакет клиенту (с src адресом = внешнему vs1), то такой крюк может заработать.
На внешнем сервере можно сделать просто проброс на локальный сервер с сохранением src адреса (iptables -t nat -A PREROUTING ... -j DNAT --to-destination ...), если на локальном сервере шлюз=этот внешний сервер, то ответный пакет прилетит обратно - на внешний сервер, где останется только подменить src этого сервера (что происходит автоматом) и переправить в инет.
Опущу проблемы самого языка JS, у самого асинхронного подхода есть "проблема", разработчиков прет от асинхрона первые пару лет, но если делать на нем все подряд, то уже через несколько лет от этого начнет "тошнить", и вот тогда разработчик начинает использовать асинхрон тогда когда нужно, а не везде подряд. И без разницы node.js там или async.io. Это что-то из разряда "сложности" в разработке, что тяжело доказать, это нужно пережить.
GIL тут совсем ни причем, зависание из за сети, из за того что сервер не шлет данные.
Воркерам нужно давать задачи не поровну а по мере их освобождения воркеров, что-бы воркеры не простаивали, тогда общее время выполнения будет меньше.
Для подобных задачи, где много открытых коннектов, эффективно использовать асинхронные фреймворки, для py2.7 есть tornado, а вот пример www.py-my.ru/post/4f278211bbddbd0322000000
KuzmenkoArtem: возможно не в ту базу логинитесь (use dbname перед db.auth), в любом случае, если такая ошибка выходит, значит ошибка в имени базы (база не та или сервер), логине или пароле.
db.col.update({ product: {...} }, {$set: {'price1.cost': 20, 'price1.amount': 100}})