Есть ли способ испускать данные вложения в виде couchdb

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

Обновление Основной недостаток (не описанный в принятом ответе) на использование BLOBS внутри самого документа, а не вложений, заключается в том, что при обновлении документа вы должны ПОЛУЧИТЬ весь документ, а затем ОТЧЕТИТЬ его обратно. Если вы не используете вложения, вы должны получить все эти двоичные данные, а вложения у вас нет. Если вы будете выполнять обновления ваших документов, использование вложений действительно является единственным разумным способом создания двоичных данных.

Ответы

Ответ 1

Вы столкнулись с большим вопросом!

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

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

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

Итак, что такое привязанность? Для меня рабочее определение вложений - это данные, которые недоступны в представлениях, отображаются и перечислены. Это оптимизация. Вы теряете доступ к нему с сервера Javascript; однако вы получаете скорость, потому что CouchDB не должен кодировать и декодировать огромное количество данных.

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

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

Множественные выборки

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

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

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

Получение HTTP-ресурса одновременно работает по-разному на каждом языке. В Javascript это очень просто, требуя несколько строк кода с 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!')
})