2013-03-23 4 views
20

Schemaless - это термин, который в настоящее время плавает в мире NoSql.Что означает отсутствие схемы для базы данных NoSQL?

  1. Что это значит?
  2. У меня есть документ с 3 свойствами сегодня, и я перехожу к производству с ним, то что происходит с моими данными, когда мне нужно добавить еще 2 свойства в мой документ?
  3. Является ли это проблемой исключительно для миграции, когда мне нужно управлять миграцией данных или может ли база данных NoSql создавать столько трений, как RDBMS или сделать ее проще?

ответ

16

схемы менее это немного неправильно, то лучше думать о нем, как:

  • SQL = Schema навязанного РСУБД на Write
  • NoSQL = Частичная схема применяются в СУБД на Пиши, PLUS схемы полностью навязанный заявка на Read (экспортированная схема)

Таким образом, хотя предполагается схема менее NoSQL данных магазин будет теоретически позволяет хранить любые данные, которые вы любите (Typica lly key value, в документе) без предварительного знания ключей или типов данных, это будет бессмысленно, если у вас нет механизма для извлечения и использования данных. Поэтому, по существу, схема частично перемещается из РСУБД в код приложения. Я говорю частично, поскольку вы добавили индексы для документирования коллекций и/или секционировали данные для производительности, поэтому СУБД NoSQL будет иметь частичную схему, определенную локально, и, возможно, принудительно с помощью ограничений Unique.

Что касается добавления дополнительных атрибутов к документу/объекту в хранилище. В зависимости от того, сколько отступов вокруг документа (неиспользуемое пространство), в его физическом блоке данных, добавление нескольких пар значений в документы может привести к физическому перемещению документа в более крупный непрерывный блок хранения, и связанные индексы перестроены. Если вы планируете использовать новые ключи в часто используемом запросе, вы также захотите добавить подходящий новый индекс, который, очевидно, потребует некоторого физического хранилища, потребуется некоторое время для первоначальной сборки и, возможно, приведет вас к тому, чтобы спросить системного администратора выделять больше памяти в СУБД, чтобы можно было кэшировать новый индекс (ы).

+0

Хороший вопрос о распределении пространства. Но специально для пунктов 2 и 3, как мне управлять данными w.r.t для переноса данных? Является ли продукт NoSQl достаточно умным, чтобы обнаруживать изменения, которые являются инкрементальными и неразрывными нарушениями v/s? –

+2

Зависит от продукта, но, как правило, если вы хотите добавить дополнительные атрибуты/ключи в документ, все, что вам нужно сделать, это изменить код приложения для хранения/использования новых пар ключей. СУБД не заботится о том, что хранится в документе, если оно не должно быть проиндексировано, и полагая, что для каждого документа выделено достаточно места, так что СУБД не должны реструктурировать ее заднюю часть. – arober11

+0

Итак, нам нужно учитывать возможное увеличение размера документа перед началом работы? –

2

Немного поздновато, но при поиске по теме снова я нашел эту статью

http://tech.pro/tutorial/1189/basics-of-ravendb-nosql

Обратитесь к разделу 3 в статье, я буду цитировать его снова для удобства.

Добавление и изменение моделей данных в RavenDB не может быть проще. С это база данных NoSQL, она может обрабатывать дополнения и удаления на ваши модели очень просто. Если свойство добавлено в ваш класс, оно будет , установленное по умолчанию для этого типа. Если свойство удалено, то при десериализации это значение будет проигнорировано. Не более futzing с SQL Scripts.

Это, кажется, логический ответ для RavenDB.