Daevaorn
Двумя пожалуйста

А как двумя? По запросу на каждый диапазон, а затем руками слить две выборки?

zheromo
Если несложно, можно привести пример когда использование startkey/limit неприменимо.

Элементарно. Когда нужно отсортировать документы по двум полям, НО первое поле по возрастанию, а второе по спаданию.

Проблема в том, что ключи в CouchDB можно сортировать только в одну сторону - либо ASC, либо DESC.

zheromo
map:

function(hdd) {
  if (hdd.capacity>= 250 && hdd.capacity<=1000 && hdd.cost>=50 && hdd.cost<=150)
    emit(hdd);
}

Daevaorn прав, от такого запроса мало-мальски большая база загнется.
я активно использую map-reduce, и знаю что эта штука сравнимо медленная, map-reduce нужен для других целей, его нужно выполнять только на подготовленных/отсеянных данных.

в данном запросе на каждый объект будет выполняться эта ф-ия, в настоящее время js не быстрее python'a, и в итоге время выполнения этого запроса будет примерно равна тому: если извлечь все объекты из базы и вручную питоном их профильтровать. (это при условии что бд не распределенная и находиться локально)

zheromo
В таком случае лучше использовать ORM, например типа Django ORM (под Couch он есть). Когда его не хватит написать вьюшку. С реляционными базами поступают точно также обычно.

Да, мы избавимся от одного недостатка и наткнемся на второй. Реляционные дают 2 возможности: ОРМ с известным ограничением по скорости или native библиотеки. Couch заведомо предлагает более медленный способ работы с базой.
Конечно, на небольших базах на эти нюансы можно не обращать внимания, но обсуждение идет в этой теме как раз по теме больших баз.

zheromo
Пользы от притягивания абстракций реляционный модели к документо-ориентированной практически нет, это просто разные подходы. Соответственно и архитектура приложения будет разной.

Я прекрасно понимаю разницу. В том числе, между моделями использования. Просто сейчас сложилась ситуация, когда для NoSQL СУБД требуются некоторые возможности SQL СУБД, в основном, касающиеся выборки данных.

zheromo
А что - бывает какойто другой непрямой вид доступа?

Для систем, доступных из Интернет,- обычное дело: фронт - БД. Сервер БД расположен в локальной сети и доступен для фронта (и других систем, если это не ограничено политикой безопасности), снаружи он не виден.

o7412369815963

zheromo
map:

function(hdd) {
  if (hdd.capacity>= 250 && hdd.capacity<=1000 && hdd.cost>=50 && hdd.cost<=150)
    emit(hdd);
}

Daevaorn прав, от такого запроса мало-мальски большая база загнется.
я активно использую map-reduce, и знаю что эта штука сравнимо медленная, map-reduce нужен для других целей, его нужно выполнять только на подготовленных/отсеянных данных.

в данном запросе на каждый объект будет выполняться эта ф-ия, в настоящее время js не быстрее python'a, и в итоге время выполнения этого запроса будет примерно равна тому: если извлечь все объекты из базы и вручную питоном их профильтровать. (это при условии что бд не распределенная и находиться локально)

Он имел в виду использование временных вьюх - котрые действительно работают очень медленно и нужны только для разработки. При использовании постоянной вьюхи ничего плохого не произойдет, так как функция выполняется только при вставке или модификации документа. Тотже mysql тоже создает и обновляет индексы. Кстати, никто не мешает писать вьюхи на Python или на C++.

По этому поводу ссылка на бенчмарк
http://metalelf0dev.blogspot.com/2008/09/mysql-couchdb-performance-comparison.html

Особо интересен слайд 6 - видим что при втором и далее запросах времена чтения одинаковы, это и понятно - BTree деревья везде одинковые.
Еще не учитывалось что на один документ Couch-a может приходится несколько записей в MySQL.

Daevaorn
Вы лукавите, делать подобного рода запрос через временную вьюшку равносильно самоубийству на мало-мальски большой базе. А статически вы просто не сможете сгенерировать ключи по которым можно было бы выбрать нужные документы оним запросом (конечно, если мы говорим о ситуации когда границы задаются динамически). Двумя пожалуйста.

Кстати, для подобного рода запросов более эффективно использовать couchdb-lucene.

Естественно вьюха должна быть постоянная. Для динамических диапазонов полностью согласен - ключ должен быть один - для одного запроса. Есть конечно варианты привидения нескольких ключей к одному - например то же geohash. Также ситуация упрощается если часть ключей перечислима полностью - например марки товаров, их цвета, те же варианты объема винтов, диагонали мониторов и т.д. Тогда тоже можно уложиться в один запрос.

zheromo
Кстати, никто не мешает писать вьюхи на Python или на C++.

Это практически никак не скажется на производительности.

Самое накладное в текущей схеме индексирования в CouchDB – это энкодинг/декодинг JSON'а.

Это проблему может только отчасти решить написание вьюх на самом эрланге, но это очень неудобно из-за языка.

dimabest

zheromo
Если несложно, можно привести пример когда использование startkey/limit неприменимо.

Элементарно. Когда нужно отсортировать документы по двум полям, НО первое поле по возрастанию, а второе по спаданию.

Проблема в том, что ключи в CouchDB можно сортировать только в одну сторону - либо ASC, либо DESC.

Это не совсем так
см. https://issues.apache.org/jira/browse/COUCHDB-158

Т.е. можно сортировать по элементам составного ключа.

zheromo
Это не совсем так
см. https://issues.apache.org/jira/browse/COUCHDB-158

Т.е. можно сортировать по элементам составного ключа.

Нет. Этот тикет тоже не разрезолвлен.

Daevaorn

zheromo
Это не совсем так
см. https://issues.apache.org/jira/browse/COUCHDB-158

Т.е. можно сортировать по элементам составного ключа.

Нет. Этот тикет тоже не разрезолвлен.

Как я понял, существует патч, который решает данный вопрос. А в официальном коде его нет.
Разработчики считают что кому нужен данный функционал - применят патч сами.

Также есть например еще и
http://github.com/assembly/couchdb-footrest