Вопрос по mobile – Есть ли способ передать данные вложения в представлении couchdb

12

Я считаю очень полезным использовать вложения CouchDB при отображении данных на веб-сайте. Однако когда я копирую базу данных в мобильную среду, очень неэффективно запускать представление, а затем приходится циклически просматривать документы, чтобы получить доступ к их вложениям. На платформе iOS / Android гораздо эффективнее хранить данные как обычные BLOB-объекты и иметь доступ ко всем двоичным данным с помощью всего одного запроса представления, в первую очередь запроса представления, который генерирует все данные документа. Есть ли способ прочитать вложения DATA в моей функции карты, и включить его в оператор emit. Я вижу, что есть информация о вложении, доступная через _attachments, но это не дает доступа к данным.

Update Основной недостаток (не детализированный в принятом ответе) использования BLOBS в самом документе, а не вложениях, заключается в том, что при обновлении документа необходимо получить весь документ, а затем отправить его обратно. Если вы не используете вложения, вы должны получить все эти двоичные данные с вложениями, которые вы не используете. Если вы будете выполнять обновления своих документов, использование вложений - действительно единственный разумный способ разработки двоичных данных.

Ваш Ответ

1   ответ
14

Что такое вложение?

Это двоичные данные? Ну, вы можете кодировать данные Base64 и сохранять их непосредственно в документе (аналогичноURI данных). И вы можете, конечно, иметь текстовые или приложения / JSON приложения. Так что это не так.

Это прямые загрузки? На самом деле, нет.Показать и перечислить функции Позвольте вам обслуживать любую часть документа напрямую (или создавать новый контент на основе данных документа).

И чтоis приложение? Для меня рабочее определение вложений,data which is not accessible in views, shows, and lists, Это оптимизация. Вы теряете доступ к нему из серверного Javascript; однако вы получаете скорость, потому что CouchDB не нужно кодировать и декодировать огромное количество данных.

Иногда я тоже думаю об этом, как указатели Си. Работать с указателями очень быстро. Это небольшой, простой тип данных. Тем не менее, это дополнительные затраты на программирование, потому что они должны быть разыменованы для доступа к данным. У вас всегда есть дополнительный шаг. Это стоимость скорости. Приложения CouchDB похожи.

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

Multiple fetches

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

Программисты инстинктивно считают это нежелательным. И, да, это может быть нарушителем соглашения. Однако во многих случаях это хороший компромисс. Дональд Кнут говорит, что «преждевременная оптимизация - корень всего зла». Это убьет нас, чтобы сделать 21 всего выборок с локального сервера, поддерживаемого SSD?

Во многих случаях это просто нормально сделать 20 запросов. Ключ состоит в том, чтобы сделать их все одновременно. CouchDB (и мобильный couchbase) оптимизирован для одновременных запросов. Вы обнаружите, что получение 20 изображений занимает в основном то же время, что и получение одного.

Получение ресурса HTTP одновременно работает по-разному на каждом языке. В JavaScript этоvery легко, требуя несколько строк кода сasync.js.

// Assuming fetch_image(), and images = ['alice.png', 'bob.png',  etc.]
async.forEach(images, fetch_image, function(er) {
  if(er) throw er
  console.log('Fetched 20 images!')
})
Error: User Rate Limit ExceedednotError: User Rate Limit Exceeded
Error: User Rate Limit Exceeded deepwinter

Похожие вопросы