Когда использовать CouchDB против RDBMS [закрыто]

Я смотрю на CouchDB, который имеет ряд привлекательных функций по сравнению с реляционными базами данных, включая:

интуитивно понятный интерфейс REST / HTTPлегкая репликацияданные хранятся в виде документов, а не нормализованных таблиц

Я ценю, что это не зрелый продукт, поэтому его следует применять с осторожностью, но мне интересно, действительно ли он является жизнеспособной заменой СУБД (несмотря на то, что на вступительной странице указано иное -http://couchdb.apache.org/docs/intro.html).

При каких обстоятельствах CouchDB будет лучшим выбором базы данных, чем RDBMS (например, MySQL), например. с точки зрения масштабируемости, дизайна + времени разработки, надежности и обслуживания.Есть ли еще случаи, когда СУБД все еще является правильным выбором?Является ли это выбором или выбором, или гибридное решение с большей вероятностью станет лучшей практикой?

Ответы на вопрос(7)

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

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

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

где CouchDB может работать против вас.

Два самых больших источника трудностей в списках рассылки Couch Users и Dev:

Сложные объединения данных.Многошаговая карта / уменьшить.

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

Комментарии других людей по этому вопросу демонстрируют некоторые из различных типов данных, которые хорошо подходят для CouchDB.

Следует помнить еще одну вещь: во многих случаях данные, которые вам могут понадобиться объединить / объединить / пересечь, будут данными, которые вы все равно будете делать автономно в базе данных RDBMS, так что вы ничего не потеряете, сделав то же самое в CouchDB.

Краткий ответ: я думаю, что в конечном итоге CouchDB сможет справиться с любой проблемой, которую вы захотите решить. Но уровень комфорта, который вы используете, может отличаться от разработчика к разработчику. Это несколько субъективно, я думаю. Мне нравится использовать полный язык Тьюринга для запросов к моим данным и сохранять больше логики на прикладном уровне. Ваш пробег может варьироваться.

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

 gabereal10 янв. 2015 г., 18:16
Вы также можете хэшировать пользователя + адрес электронной почты и использовать его в качестве ключа. Если запрос возвращает какие-либо результаты, он не уникален.
 holdenweb01 авг. 2018 г., 11:33
Ясно, что хэширование - это путь, но вы бы хотели хэшировать пользователя и электронную почту отдельно, чтобы гарантировать, что каждый из них уникален.
 Sam27 авг. 2009 г., 08:36
Рассмотрим 2 ключа: «[email protected]» и «[email protected]». Оба пользователя имеют одинаковый адрес электронной почты [email protected]
 Jeremy Wall27 авг. 2009 г., 04:34
У CouchDB есть способы обеспечить уникальность. Это все на ключевом уровне, хотя. Если вам нужно, чтобы логин и адрес электронной почты были уникальными, просто извлеките из них идентификатор документов, и вы никогда не сможете вставить дубликаты логина и адреса электронной почты в БД. Это отличается, но так же эффективно.
 Joshua Coady25 окт. 2012 г., 01:47
Выберите один, который будет «главным» уникальным ключом, и используйте его для первичного документа. Затем создайте дополнительный документ с другим в качестве ключа. Его единственными другими данными является главный ключ. Например, выбирая электронную почту в качестве главной, поэтому имя пользователя является второстепенным. Создайте документ с ключом "[email protected]" и другими данными, но без имени пользователя. Если это удастся, создайте другой документ с ключом "john" и сохраните в нем "[email protected]". Если это удастся, они оба уникальны, и вы можете обновить документ с помощью ключа "[email protected]", чтобы в качестве имени пользователя было указано "john". Если это не удается, попросите пользователя другое имя пользователя.

вот некоторые плюсы и минусы для CouchDB

Плюсы:

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

Минусы:

вам нужно создавать представления для каждого запроса, то есть, например, специальные запросы (такие как объединение динамических WHERE и SORT в SQL), запросы недоступны.у вас либо будут избыточные данные, либо вы в конечном итоге будете реализовывать логику объединения и сортировки самостоятельно на «стороне клиента» (например, сортировка отношения «многие ко многим» по нескольким полям)

Плюсы или минусы:

Создание ваших представлений не так просто, как в SQL, это больше похоже на решение головоломки. Зависит от вашего типа, если это за или против :)
 Andrew Whitehouse14 сент. 2009 г., 18:21
Задав вопрос, я изучил другие источники, и мне кажется, что основным преимуществом использования CouchDB является его представление в реальном мире данных по сравнению с нормализованной структурой данных, требуемой более традиционными СУБД. Видетьbooks.couchdb.org/relax/intro/why-couchdb для дальнейшего объяснения. Я думаю, что ответы на другие вопросы, которые я задавал, еще не доступны.

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

Ключевые моменты:

Мы накопили около 30 лет знаний об администрировании реляционных баз данных, поэтому не должны заменять их без тщательного рассмотрения; Нереляционные хранилища данных менее развиты, чем реляционные, и поэтому по своей природе принимать их более рискованноСуществуют разные типы нереляционных хранилищ данных; некоторые - хранилища значений ключа, некоторые - хранилища документов, некоторые - графические базы данныхВы можете использовать гибридный подход, например, комбинация СУБД и хранилища графических данных для сайта социального программного обеспеченияХранилища данных документов (например, CouchDB и MongoDB), вероятно, наиболее близки к реляционным базам данных и предоставляют структуру данных JSON со всеми полями, представленными иерархически, что позволяет избежать необходимости выполнять объединения таблиц, и (некоторые могут утверждать) является улучшением традиционных объектов. реляционное отображение, которое в настоящее время использует большинство приложенийНереляционные базы данных поддерживают репликацию (включая master-master); реляционные базы данных также поддерживают репликацию, но она может быть не такой всеобъемлющей, как нереляционная опцияОчень большие сайты, такие как Twitter, Digg и Facebook, используют Cassandra, которая создана с нуля для поддержки кластеризации.Реляционные базы данных, вероятно, подходят для 90% случаев.

Таким образом, консенсус, кажется, «действовать с осторожностью».

 H6.10 мая 2011 г., 14:38
Спасибо также за хорошее сообщение в блоге. Подводит итог довольно хорошие некоторые хорошие мнения.

ений», другие включают в себя старые вещи, такие какBDBвеб-ориентированные, такие какстойко, MongoDB и CouchDB, новый супер-быстрый, какMemcached (Только для оперативной памяти) иТокийский кабинети огромные магазины, такие как Hadoop и Google BigTable (MongoDB также утверждает, что находится на этом месте).

Конечно, есть место как для хранилищ ключей / значений, так и для реляционных БД. Традиционно большинство RDB считаются уровнем выше ключ / значение. Например, MySQL использовал BDB в качестве необязательного бэкэнда для таблиц. Короче говоря, ключ / значения ничего не знают о полях и отношениях, которые являются основой SQL.

Хранилища ключей / ценностей обычно легче масштабировать, что делает их привлекательным выбором при взрывном росте, как это сделал Twitter. Конечно, это означает, что любые отношения между сохраненными значениями должны управляться в вашем коде, а не просто объявлены в SQL. Подход CouchDB заключается в том, чтобы хранить большие «документы» в ценностной части, делая их (в основном) автономными, чтобы вы могли получить большую часть необходимых данных в одном запросе. Многие варианты использования подходят для этой идеи, другие нет.

Текущая тема, которую я вижу, состоит в том, что после "Rails не масштабируется !!" напугать, теперь многие люди понимают, что дело не в вашей веб-среде; но об интеллектуальном кэшировании, чтобы избежать попадания в базу данных и даже в веб-приложение, когда это возможно. Восходящая звезда там запечатлена.

Как всегда, все зависит от ваших потребностей.

 ibo.ezhe15 янв. 2013 г., 23:47
couchdb не является хранилищем ключей в традиционном понимании. И монго, и кушетка являются документно-ориентированными базами данных.
 Seun Osewa03 дек. 2010 г., 11:51
Вы обсуждали вопрос, но не пытались на него ответить.

Ваш ответ на вопрос