Python-сообщество

Daevaorn

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

Например когда вьюха может генерировать одинаковые ключи. Для паджинации в данном случае требуется использование ещё и startkey_docid, но это тоже не будет работать если одинаковые ключи может порождать один документ.

Не думаю, что сложно добиться уникальности ключей. Например включением в него id документа.

zheromo
а чем коуч лучше монги?

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

Можно подробнее в чем это выражается.

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

По поводу больших баз в данном случае мы имеем такие прелести как распределенность, инкрементную двунаправленную репликацию и т.д.

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

Спасибо, я понял что вы имели в виду. Couch по умолчанию слушает только localhost. Поэтому извне, даже из локальной сети на него не попадешь.

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

Это бред. Откуда вы знаете что считают разработчики по поводу этого заброшенного патча?:-) Мы тут говорим о том что продукт может, а не что с ним можно сделать накатив кучу патчей.

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

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

o7412369815963
а чем коуч лучше монги?

а чем яблоки лучше апельсинов?

o7412369815963
zheromo
а чем коуч лучше монги?

Выскажу сугобо мое личное мнение.

По теории
Для любой базы данных можно выбрать любые два из трех свойств
C Consistency - все клиенты получают неразличающиеся данные в один и тот же момент времени.
A Availability - все клиенты могут одновременно читать и писать.
P Partition tolerance - грубо говоря - хорошая распределнность.

см. например тут http://blog.nahurst.com/visual-guide-to-nosql-systems

У Couch мы имеем AP, у Mongo - CP.

Для моих задач луше подходит AP.

Также мне кажется что коуч использует более строгий архитектурный подход - REST.

Также он более надежен - данные точно никуда не пропадут. У монго же лично под виндовс наблюдал картину когда после перезагрузки компьютера (нормальной) часть последних добавленных данных пропадала, или вообще ломалась база. Мне это не понравилось.

Также лично мне мешало наличие огромного числа реляционных возможностей использование которых рано или поздно (может по привычке) приводило к нормализации базы (почти к пятой нормальной форме :) и соответственно к джойнам и прочим проблемам, т.к. понятно ссылочной целостности в привычном виде там нет.

Daevaorn

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

Это бред. Откуда вы знаете что считают разработчики по поводу этого заброшенного патча?:-) Мы тут говорим о том что продукт может, а не что с ним можно сделать накатив кучу патчей.

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

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

Согласен, не добавляет.

По разработчикам - сам читал, ссылку привести к сожалению не могу.

zheromo понесло :)

Столько слов… а как сделать выборку по двум диапазонам - я так и не увидел. Необязательно одним запросом - можно хоть двумя десятками.

Отредактировано (Окт. 4, 2010 02:19:34)

zheromo
Можно подробнее в чем это выражается.

Мой собственный опыт оптимизации больших систем полностью подтверждается опытом действительно больших систем: http://www.insight-it.ru/highload, по сравнению с которыми мои работы - это просто муравьи на подоконнике. В двух словах, основные архитектурные проблемы (не путать с проблемами чисто аппаратными, например, disk IO) кроются в запросах к БД. Поэтому использование медленных интерфейсов к БД - табу для высоконагруженных систем.

zheromo
По поводу больших баз в данном случае мы имеем такие прелести как распределенность, инкрементную двунаправленную репликацию и т.д.

… которые тоже используют тот же “медленный” интерфейс доступа к данным.
Ну вот скажите, зачем городить между двумя базами промежуточный слой в виде вэб-сервера для обслуживания REST API? А ведь его не выкинешь, он вшит в СУБД!

zheromo
Couch по умолчанию слушает только localhost. Поэтому извне, даже из локальной сети на него не попадешь.

Я не к тому, что у Couch плохая модель безопасности. Нет, я имею ввиду то, что наличие встроенного в Couch DB вэб-сервера (а также встроенный механизм обслуживания пиковых нагрузок) легко позволяет ей быть открытой для доступа извне. Но круг задач, которые требуют именно такой реализации доступа очень мал.
Таким образом, такие полезные фичи Couch DB являются одновременно недостатками.

zheromo
A Availability - все клиенты могут одновременно читать и писать.

всмысле?