LINUX.ORG.RU
решено ФорумTalks

[couchdb][спецам по БД]Зачем?


1

3

В очередной раз почитываю CouchDB: The Definitive Guide.

В очередной раз перечитываю те разделы, которые отвечают на вопрос «НАХРЕНА?». И звучит все это как-то неубедительно.

В случае с Документно-ориентированной моделью данных + map\reduce - некоторые запросы(как говорят интернеты) вообще хрен напишешь, а те запросы, которые не натянуть на Map\Reduce сходу, совсем не напишешь.

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

Гуглеж так же выбросил на sql.ru, где обсуждение было эпичным

-Couch не нужен

-Нужен, у него есть ниша

-какая?

-в гугл, животное!

Идем в гугл, и во многих тредах, где обсуждается ниша CouchDB, с течением времени кастуются фанаты как Postgresql, так и MongoDB, которые на крови собственных детей клянутся, что вот на их СУБД все будет выше-быстрее-сильнее.

При такой, достаточно спорной атмосфере, в какую книжку не ткни - везде CouchDB считается хорошей и нужной вещью

Собственно, может ли кто-нибудь на примере показать, в каком случае целесообразно использовать CouchDB, желательно с пояснением, почему она будет эффективнее, нежели классические СУБД(mysql, Oracle, postgresql) и другие (в бенчах часто присутствует MongoDB)NoSQL решения?

Кстати, аналогичный вопрос...

zgen ★★★★★
()

Гуглить, животные!

iZEN ★★★★★
()

ну и в лучших традициях ЛОРа - «Couch не нужен!»

bsdelnik
()

Масштабирование большой нагрузки, состоящей в основном из чтения, и терпимой к несогласованным данным.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Масштабирование большой нагрузки, состоящей в основном из чтения, и терпимой к несогласованным данным.

Уже яснее, спасибо. А пример из реальной жизни можно? В идеале ссылочку подобный проект, сервис, что-нибудь в этом роде.

mikhalich ★★
() автор топика
Ответ на: комментарий от tailgunner

>И кстати, тебе подойдет весь этот выводок недобаз от недоучек - Couch, Mongo, Cassandra.

И для чего он мне подойдет?

Ну, например,http://wiki.apache.org/couchdb/CouchDB_in_the_wild и вообще вгугль.

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

«Postgresql тут не подходит, потому что ....... , а CouchDB в данном случае имеет преимущество за счет ......, »

Всегда можно сказать «эти конторы используют CouchDB, потому что не осилили Postgresql и хотят повыпендриваться новыми инновационными онанотехнологиями».

mikhalich ★★
() автор топика
Ответ на: комментарий от mikhalich

>> И кстати, тебе подойдет весь этот выводок недобаз от недоучек - Couch, Mongo, Cassandra.

И для чего он мне подойдет?

Для понимания, нужны ли тебе недобазы такого типа.

тут есть список, но нет ответа на вопрос - почему именно CouchDB?

Ты хотел примеров из реальной жизни? По ссылке целый список таких.

Всегда можно сказать «эти конторы используют CouchDB, потому что не осилили Postgresql и хотят повыпендриваться новыми инновационными онанотехнологиями».

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

tailgunner ★★★★★
()

> Судя по тому, что там везде JS+JSON - скоростью эта штука похвастать не может.

js там, afair, для веб-интерфейса

А можно поподробнее о связи json и производительности?

n01r ★★
()
Ответ на: комментарий от tailgunner

>А если тебе нужны документы, которые обосновывали применение документной недобазы в каждом конкретном случае...

одного хватило бы.

тебе придется привести свои желания в соответствие с реальным миром.

видимо да.

lor-mode=on

Couch не нужен

mikhalich ★★
() автор топика
Ответ на: комментарий от n01r

>js там, afair, для веб-интерфейса

запросы на JS же пишутся. Не?

А можно поподробнее о связи json и производительности?

все познается в сравнении. В данном случае в сравнение можно поставить BSON, не?

mikhalich ★★
() автор топика

был у меня такой же вопрос

> а где/когда стоит непременно использовать NoSQL?

Там где не получится жестко задать свойства объектов. Например, в каталоге товаров. Книжки и пылесосы имеют разный набор атрибутов. И ведь еще фильтровать по ним надо.

Можно конечно и на реляционке такое слабать, но на носкуле будет намного проще и быстрее.

весь тред:
http://www.linux.org.ru/forum/development/5927549

Donnie_Darko
()
Ответ на: комментарий от Donnie_Darko

Большое спасибо.

Создается впечатление, что сторонники NoSQL заняты не созданием проектов, а выдумыванием ситуаций, когда NoSQL решения бы пригодились. Если с mongodb там еще кто-то где-то нашел конкретный use-case, то с остальными больше похоже на решение теоретических воображаемых проблем

mikhalich ★★
() автор топика
Ответ на: комментарий от mikhalich

Всегда можно сказать «эти конторы используют CouchDB, потому что не осилили Postgresql и хотят повыпендриваться новыми инновационными онанотехнологиями».

Конечно, сказать-то можно все, что угодно, тем более - на ЛОРе. Но когда вы это будете говорить, подумайте, что к этим же «конторам» вам придется отнести и сам Google тоже, хотя они и не используют именно Кауч - у них какое-то там свое решение. То, что лично вам не приходилось сталкиваться с дейтасетами / задачами, для которых оправдано использование таких БД (тут надо ради справедливости отметить, что мне тоже такие юс-кейсы не попадались пока), ни о чем не говорит, вы же понимаете, да?

А то получается «Не читал, но осуждаю». Ох уж эти теоретики..

shylent
()
Ответ на: комментарий от mikhalich

> запросы на JS же пишутся. Не?

Вроде хоть на curl... Было бы странно, если бы запросы действительно приходилось писать на js.

все познается в сравнении. В данном случае в сравнение можно поставить BSON, не?

Если сравнивать c BSON, то тогда уж сразу с mongodb. А это уже сравнение в контекте nosql, то есть более узкий нежели изначальный. MongoDB, емнип, считается более быстрой и немного менее стабильной.

n01r ★★
()
Ответ на: комментарий от n01r

>Вроде хоть на curl... Было бы странно, если бы запросы действительно приходилось писать на js.

Некорректно выразился - View пишутся на JS.

mikhalich ★★
() автор топика
Ответ на: комментарий от shylent

>А то получается «Не читал, но осуждаю». Ох уж эти теоретики..

Хоспади, ты стартовый пост читал? я там именно это и спросил - «КАКИЕ ЗАДАЧИ СЮДА ОТНОСЯТСЯ?», и, как обычно в NoSQL статьях, даешь классический ответ в духе капитана Очевидность - «Те задачи, в которых использование таких БД оправдано. Ваш К.О.».

mikhalich ★★
() автор топика
Ответ на: комментарий от shylent

>вам придется отнести и сам Google тоже, хотя они и не используют именно Кауч - у них какое-то там свое решение.

Аналогично twitter. Аналогично еще кто-нибудь.

Потом смотрим список NoSQL СУБД. И приходим к выводу - на каждую задачу(не класс задач, а конкретную) пишем свою NoSQL СУБД. Тогда надо открывать книжку «Разработка систем управления данными», а не «CouchDB - как сделать всем п*здато ».

mikhalich ★★
() автор топика

>Судя по тому, что там везде JS+JSON - скоростью эта штука похвастать не может.

По MongoDB:

http://balancer.ru/tech/forum/2010/07/t70507--mongodb-kto-to-uzhe-proboval.98...

http://www.linux.org.ru/forum/web-development/5139765#comment-5151828

И т.п. Правда, до многопоточного тестирования так руки и не дошли, потому что пока нет практических задач, где MongoDB было бы оправдано.

KRoN73 ★★★★★
()
Ответ на: комментарий от mikhalich

>Создается впечатление, что сторонники NoSQL заняты не созданием проектов, а выдумыванием ситуаций, когда NoSQL решения бы пригодились.

Если человек создаёт проекты под концепцию инструмента - это уже диагноз. Поэтому никто вменяемый проекты под NoSQL создавать не будет. А вот, наоборот, применение NoSQL в некоторых проектах - оптимальное решение. Вот про них речь обычно и идёт.

KRoN73 ★★★★★
()
Ответ на: комментарий от mikhalich

> Некорректно выразился - View пишутся на JS.

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

Но ведь создаются один раз (при первом запросе если не ошибаюсь), а nosql не презентовались как имеющие быструю скорость записи.

Но ведь это далеко не «везде JS».

n01r ★★
()
Ответ на: комментарий от KRoN73

>Миллион простых записей вставляется в 10(!) раз быстрее, чем в MyISAM.

скептически настроенный человечек в моей голове говорит, что согласен с вами и MySQL - тормоз, да =). И предлагает сравнить с SQLite и с Firebird.

Правда, говорят, плохо переносит повреждения. Ну, это мы ещё проверим.

а в какой задаче целостность данных не важна? Моей скудной фантазии как-то слабо хватает, если честно

mikhalich ★★
() автор топика
Ответ на: комментарий от mikhalich

> Хоспади, ты стартовый пост читал?

Читал, почему нет? Только по вашим комментариям относительно JS / JSON понятно, что бенчмарков вы не делали и вообще не пользовались этими продуктами, а просто сидите и думаете - «а нужно ли это все?» Так вот, вам - не нужно. Да и мне тоже, пока что.

Я, конечно, мог бы вам привести примеры того, как кто-нибудь там из моих знакомых использовал БД X для работы с терабайтным дейтасетом данных Y. Но зачем? Мне просто не совсем понятно было желание закопать технологию, только потому что лично вам ее сейчас не к чему применить. Мне казалось, тут - технический ресурс.

Впрочем, повторюсь, что ваши комментарии насчет javascript / json / bson меня посмешили изрядно, то есть в тред я зашел не зря.

shylent
()
Ответ на: комментарий от shylent

>Впрочем, повторюсь, что ваши комментарии насчет javascript / json / bson меня посмешили изрядно, то есть в тред я зашел не зря.

я очень рад.

Я, конечно, мог бы вам привести примеры

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

Мне казалось, тут - технический ресурс.

Вас жестоко обманули, тут Talks

Только по вашим комментариям относительно JS / JSON понятно, что бенчмарков вы не делали

А бенчмарки такая вещь, которая показывает не то, что мы хотим увидеть. Если преимущества технологии Х проявляют себя, когда мы имеем дело с распределением нагрузки на десяток машин, как я в домашних условиях бенчмарком получу аналогичный результат?

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

Я не собираюсь просто по умолчанию хоронить NoSQL, я пытаюсь понять, когда его использовать. Когда он понадобится.

btw, в ссылке из треда от Donnie_Darko(до конца еще не дочитал, но запостивший говорит, что реляционщики там крушат) реляционщики демонстрируют, что задачи вида «ЭТО ПЛОХО ЛОЖИТСЯ НА SQL ЭТО ИДЕАЛЬНО РЕШАЕТСЯ В NOSQL» во многих случаях решаются, если есть голова на плечах и способности к системному анализу. А вот когда реляционщики начинают задавать неудобные вопросы, NoSQL-фаны начинают увиливать от ответов, либо говорят, что этого нет и они не знают как это сделать.

mikhalich ★★
() автор топика
Ответ на: комментарий от mikhalich

>И предлагает сравнить с SQLite

Да он же умрёт на многопоточных обновлениях. И не масштабируется.

и с Firebird.


Вот про него ничего не скажу. Несколько лет назад бегло тестировал в тупом однопоточном режиме - результаты были ужасные. Забил и больше не возвращался.

а в какой задаче целостность данных не важна?


Например, если эти данные - кеширование, результат обработки других данных. Или если это что-то малоценное, типа френдкомментов :)

Акцент всё равно не на том. Это не задача БД умело переносить повреждения. Это задача администратора и инфраструктуры более низкого уровня. И в тех же NoSQL задача решается проще - симметричным реплицированием.

KRoN73 ★★★★★
()
Ответ на: комментарий от mikhalich

> Да вы не тушуйстесь, у нас любого в стране спроси - он столько всего мог бы, но зачем? Проходите, проходите.

Ценю ваше желание съязвить, но мне вот что-то не позволяет с умным видом рассуждать о вещах, о которых я имею исключительно поверхностное или теоретическое представление (а то и никакого вообще). Рад, что вы свободны от данного ограничения.

shylent
()

не нужны ни сабж, ни монго. авторы этих поделий просто не осилили sql

leave ★★★★★
()
Ответ на: комментарий от shylent

что мне тоже такие юс-кейсы не попадались пока), ни о чем не говорит, вы же понимаете, да?

Так вас и спрашивают, какие use case'ы?

А то получается «Не читал, но осуждаю». Ох уж эти теоретики..

А вы кто? Не читал, но одобряю?

zgen ★★★★★
()
Ответ на: комментарий от zgen

>В каких и почему?

Где требуется большое количество данных нечёткой и регулярно меняющейся структуры. Или где требуется простое двустороннее горизонтальное масштабирование.

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.