Что означает отсутствие схемы для базы данных NoSQL?

Question

Schemaless - это термин, который в настоящее время используется в мире NoSql.

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

Answer 1

Без схемы немного ошибочно, лучше думать об этом как:

• SQL = схема, применяемая СУБД при записи
• NoSQL = частичная схема, применяемая СУБД при записи, схема PLUS, полностью применяемая приложением при чтении (внешняя схема)

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

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

Answer 2

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

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

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

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

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