Я бы использовал массовый API CouchDB, даже если вы указали, что вам нужно отправлять их в базу данных один за другим. Например, реализация простой очереди, которая отправляется каждые, скажем, 5–10 секунд посредством массового вызова документации, значительно повысит производительность вашего приложения.
В этом, очевидно, есть причуда, и вам нужно знать идентификаторы документов, которые вы хотите получить из БД. Но для ПУТов он идеален. (это не совсем так, вы можете получать диапазоны документов, используя массовую операцию, если идентификаторы, которые вы используете для своих документов, можно правильно отсортировать).
Исходя из моего опыта работы с CouchDB, я догадываюсь, что вы имеете дело с транзакционными документами, чтобы скомпилировать их в какой-то итоговый результат и соответственно действовать с этими данными (возможно, создавая следующий транзакционный документ последовательно). В этом вы можете положиться на CouchDB, используя функции сокращения в создаваемых вами представлениях. Требуется небольшая практика, чтобы заставить функцию reduce работать должным образом, и это сильно зависит от того, что вы на самом деле хотите достичь и какие данные вы готовы выдать с помощью представления, поэтому я не могу предоставить вам более подробную информацию об этом.
В итоге логика приложения будет выглядеть примерно так:
get _design/someDesign/_view/yourReducedView
calculate new transaction
add transaction to queue
onTimeout
send all in transaction queue
Если бы я понял первую часть того, почему вы неправильно используете транзакционные документы, все, что действительно изменилось бы, - это та часть, где вы получаете эти транзакционные документы в логике моего приложения.
Кроме того, прежде чем писать свою собственную функцию уменьшения, ознакомьтесь с встроенными функциями (они намного быстрее, чем что-либо, кроме движка db)
http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API
РЕДАКТИРОВАТЬ: Поскольку вы начинаете, я настоятельно рекомендую взглянуть на Полное руководство CouchDB.
ПРИМЕЧАНИЕ ПОЗЖЕ:
Вот один скрытый камень (ну, может быть, не столько скрытый камень, но в любом случае не очевидная вещь, на которую стоит обратить внимание новичку). Когда вы пишете функцию сокращения, убедитесь, что она не выдает слишком много вывода для запроса без границ. Это сильно замедлит весь просмотр, даже если вы укажете reduce = false при получении из него материала.
person
Dmitry Matveev
schedule
18.09.2014