Как перестать думать «реляционно»

Question

На работе мы недавно начали проект с использованием CouchDB (документарно-ориентированной базы данных). У меня было трудное время, не изучая все мои реляционные знания db.

Мне было интересно, как некоторые из вас преодолели это препятствие? Как вы перестали думать реляционно и начать думать документально (я извиняюсь за то, что выдумали это слово).

Любые предложения? Полезные подсказки?

Редактировать: Если это имеет значение, мы используем Ruby & CouchPotato для подключения к базе данных.

Редактировать 2: SO беспокоил меня, чтобы принять ответ. Я выбрал тот, который помог мне узнать больше всего, я думаю. Однако, я полагаю, нет реального «правильного» ответа.

Answer 1

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

RDBMSes представляют собой подход сверху вниз, где вы, разработчик базы данных, утверждаете структуру всех данных, которые будут существовать в базе данных. Вы определяете, что у человека есть первое, последнее, среднее имя и домашний адрес и т. Д. Вы можете применить это с помощью РСУБД. Если у вас нет колонки для HomePlanet Person, вам не повезет, если у вас есть другая HomePlanet, чем Земля; вам придется добавить столбец на более позднюю дату или данные не могут быть сохранены в СУБД. Большинство программистов так или иначе делают такие предположения в своих приложениях, поэтому это не глупо, а принимать и применять. Определение вещей может быть хорошим. Но если вам нужно записывать дополнительные атрибуты в будущем, вам придется добавить их. Модель отношения предполагает, что ваши атрибуты данных не будут сильно меняться.

базы данных типа «облака», использующие что-то вроде MapReduce, в вашем случае CouchDB, не делайте вышеуказанное предположение и вместо этого смотрите данные снизу вверх. Данные вводятся в документы, которые могут иметь любое количество различных атрибутов. Он предполагает, что ваши данные по самому своему определению разнообразны по типам атрибутов, которые он мог бы иметь. В нем говорится: «Я просто знаю, что у меня есть этот документ в базе данных Person, у которого есть атрибут HomePlanet« Eternium »и FirstName« Lord Nibbler », но нет LastName». Эта модель подходит для веб-страниц: все веб-страницы являются документом, но фактическое содержимое/теги/ключи документа сильно варьируются, поэтому вы не можете вместить их в жесткую структуру, с которой СУБП может справиться с высокой. Вот почему Google думает, что Mapxeduce моделирует роксеры соксеры, поскольку набор данных Google настолько разнообразен, что ему нужно строить для двусмысленности из-за выхода, и благодаря массивным наборам данных можно использовать параллельную обработку (которая MapReduce делает тривиальным) , Модель документа-базы данных предполагает, что атрибуты ваших данных могут/будут сильно изменяться или быть очень разнообразными с «пробелами» и множеством малонаселенных столбцов, которые можно найти, если данные были сохранены в реляционной базе данных. Хотя вы можете использовать RDBMS для хранения данных, подобных этому, он будет очень уродливым.

Чтобы ответить на ваш вопрос, вы не можете думать «реляционно» вообще, глядя на базу данных, использующую парадигму MapReduce. Потому что на самом деле у него нет принудительного отношения. Это концептуальный горб, который вам нужно будет преодолеть.

---

Хорошая статья, я столкнулся, что сравнивает и противопоставляет две баз данных, довольно хорошо это MapReduce: A Major Step Back, который утверждает, что MapReduce база данных парадигм являются технологическим шагом назад, и уступает RDBMSes. Я должен не согласиться с тезисами автора и представить, что разработчику базы данных просто нужно будет выбрать правильный вариант для его/ее ситуации.

Answer 2

может быть, вы должны прочитать эту http://books.couchdb.org/relax/getting-started

я сам только что услышал это и интересно, но не имеют ни малейшего представления о том, как реализуется, что в реальном приложении;)

Answer 3

Одна вещь, вы можете попробовать это получив копию firefox и firebug, и играя с map и уменьшить функции в javascript. они на самом деле очень здорово и весело, и, как представляется, является основой того, как получить вещи сделано в CouchDB

вот небольшая статья Джоэла по теме: http://www.joelonsoftware.com/items/2006/08/01.html

Answer 4

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

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

Несоответствующие/документальные данные имеют смысл при денормализации. Это не сильно изменится, или вы не заботитесь о согласованности.

Если ваш вариант использования подходит для реляционной модели, то, вероятно, не стоит сдавливать его в модель документа.

Вот хорошая статья о non relational databases.

Другой способ думать об этом - документ - это строка. Все, что касается документа, находится в этой строке, и оно относится к этому документу. Строки легко разделяются, поэтому масштабирование проще.

Answer 5

В CouchDB, как и Lotus Notes, вы действительно не должны думать о том, что документ аналогичен строке.

Вместо этого документ является отношением (таблица).

Каждый документ имеет ряд строк - значения поля:

ValueID(PK) Document ID(FK) Field Name  Field Value 
======================================================== 
92834756293 MyDocument  First Name  Richard 
92834756294 MyDocument  States Lived In TX 
92834756295 MyDocument  States Lived In KY 

Каждый View является кросс-элементный запрос, который выбирает по массивным UNION ALL-х каждого документа.

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

Answer 6

Документированные базы данных не отвергают концепцию отношений, они просто позволяют приложениям разыгрывать ссылки (CouchDB) или даже иметь прямую поддержку отношений между документами (MongoDB). Что еще более важно, так это то, что DODB не имеют схемы. В хранилищах на основе таблиц это свойство может быть достигнуто со значительными накладными расходами (см. Ответ richardtallent), но здесь это делается более эффективно. То, что мы действительно должны изучить при переключении с СУБД на DODB, - это забыть о таблицах и начать думать о данных. Это то, что овечий симулятор вызывает подход «снизу вверх».Это постоянно развивающаяся схема, а не предопределенная прокрустовая кровать. Конечно, это не означает, что схемы должны быть полностью оставлены в любой форме. Ваше приложение должно интерпретировать данные, как-то ограничивать их форму - это можно сделать, организовав документы в коллекции, создав модели с помощью методов проверки, но это теперь работа приложения.