В дискуссиях о базах данных NoSQL против SQL я иногда слышал, что компании предпочитают использовать базы данных NoSQL без схемы, поскольку перенос схемы на новую версию проблематичен. Но действительно ли это большая проблема при обновлении? Реляционные базы данных вредны для таких операций?
Я прочитал этот пост в блоге MongoDB: Почему Schemaless?
Ответы:
Тот факт, что ваша база данных NoSql не имеет схемы в традиционном смысле, не означает, что нет логической схемы, с которой вам придется иметь дело при ее изменении. В случае типичного приложения, использующего MongoDb, скорее всего, ваш код ожидает, что определенные поля объекта json будут вести себя определенным образом. Если вы измените поведение, то, возможно, вы захотите обновить уже существующие данные в базе данных. Теперь, с традиционными RDBMS это было в значительной степени решенной проблемой - вам просто нужно было изменить базовые таблицы. Но с этими новомодными базами данных NoSQL у вас есть решение - вы пишете сценарий для munge и обновления всех ваших объектов? Или вы добавляете код для преобразования между версиями на лету? Если да, то как долго вы поддерживаете объекты v1? Навсегда? До v3?
Я добавлю, что пример, используемый в блоге MongoDb, немного упрощен и очень прост для рассмотрения, если у вас есть достойный процесс обновления, независимо от того, что такое RDBMS; добавление поля редко причиняет боль. Это когда вы решили разделить свое Nameполе, FirstNameи LastNameвсе становится захватывающим.
Но действительно ли это большая проблема при обновлении?
Может быть.
Некоторые организации - хорошо дезорганизованы и очень плохо выполняют миграцию схем.
«Миграционные выходные». Остановите серверы. Резервное копирование и экспорт всех данных. Создайте новую схему (часто изменяя существующую схему). Перезагрузите данные или попытайтесь реструктурировать на месте.
«Непрерывная настройка». Изменяйте таблицы в пределах, разрешенных SQL. Без отслеживания последовательности выполнения ALTER. Без возможности вернуться к предыдущей версии схемы. При необходимости создайте новые таблицы из существующих таблиц, надеясь настроить все приложения на использование новых таблиц. Но - отсутствие хорошего контроля качества - оставление старых таблиц на месте «на всякий случай».
"Полная паника". Просто предотвратите изменения схемы. Сделайте большую вонь. Утверждают, что риск слишком высок. Заблокируйте все усилия в этом направлении. Берите схему в заложники, пока не будете вынуждены принять более разумный подход.
Реляционные базы данных вредны для таких операций?
Любая схема - это боль для миграции.
Самая большая проблема не техническая.
Это семантика.
Одна из основных причин изменения схемы состоит в том, что предыдущая схема не очень хорошо соответствует проблемной области. Поскольку семантика изменилась, базу данных (и приложения) необходимо изменить. Иногда это глубокие изменения, которые требуют переосмысления того, как приложения работают с данными.
Пересмотр семантики базы данных может быть очень сложным.
То, что люди делают вместо изменений схемы, просто неправильно использует физическую схему. Они начинают загружать неправильные данные в существующие поля, потому что они могут. Поле «комментарий» внезапно начинает содержать важную часть информации об управлении клиентами, после которой следует «//», за которым следует реальный комментарий. Это растет для фрагментов данных "поле 1 - поле 2 // комментарий". У пользователей есть электронная таблица, которая извлекает эти дополнительные данные из поля комментариев, потому что у «настоящего» прикладного программного обеспечения была сложная схема, которую ИТ-специалисты отказались изменить.
Мы обновляем производственные базы данных, добавляя таблицы и (обнуляемые) столбцы без проблем. Предыдущие версии приложения прекрасно работают с обновленной базой данных, они просто не ссылаются на новые вещи. Мы избегаем удаления таблиц или столбцов или изменения способа хранения существующих данных, хотя, когда это необходимо, мы создаем подходящие сценарии преобразования. Независимо от того, имеет ли ваша база данных безопасную схему объявленного типа, изменения в структуре данных требуют преобразования данных и обновления приложений для взаимодействия с новой структурой.
По-разному.
Во-первых, если у вас действительно большая база данных, охватывающая несколько компьютеров, тогда все (не только обновление базы данных) будет болезненным. (независимо от того, сколько вы запланировали заранее).
Во-вторых, обновление базы данных - это не просто вопрос базы данных - это также зависит от большей системы, частью которой является БД. Сюда также входит развертывание базы данных (множество серверов баз данных, несколько центров обработки данных, настройки главный-подчиненный и т. Д.)
Эта боль может быть облегчена за счет того, что компоненты вашей системы построены таким образом, что все они имеют своего рода «осведомленность» о событии изменения схемы БД. Это означает, что вся система должна быть терпимой к изменениям схемы и может реагировать на нее «вменяемым» образом.
Вы можете проверить утилиту, разработанную Facebook, для решения обновлений схемы MySQL.
Кроме того, существуют стандартные рекомендации, такие как превращение мастера в режим «только для чтения», внесение изменений в подчиненные устройства или в разработку, и т. Д.
В любом случае наличие полной резервной копии и обширного набора тестов ОБЯЗАТЕЛЬНО. Только тогда вы можете делать любые изменения уверенно и безопасно.