Обновление приложения в среде с высокой степенью доступности

Ответ 1

С NoSQL - и, в частности, ориентированной на документ базой данных - вы можете выполнить это с версией.

Рассмотрим MongoDB, который хранит все как документы.

MongoDB позволяет вам иметь коллекцию (группу документов), где схема для каждого документа может быть разной.

Скажем, у вас есть этот документ для пользователя:

{ "_id" : 100, "firstName" : "John", "lastName" : "Smith" }

Вы также можете использовать это как документ в той же коллекции:

{ "_id" : 123, "firstName" : "John", "lastName" : "Smith", "hasFoo" : false }

Различные схемы, но и в одной коллекции. Очевидно, что это сильно отличается от традиционной реляционной базы данных.

Тогда решение должно добавить поле к каждому документу, имеющему версию схемы. Затем у вас есть приложение, которое ищет эту версию с каждым запросом.

Запрос MongoDB может выглядеть следующим образом:

users.find({ "version" : 3 }).limit(10);

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

Ответ 2

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

Построение распределенной системы означает, что вы делаете некоторые варианты. Выберите 2 из:

• Прочность
• Наличие
• Сильная непротиворечивость

Системы, подобные S3, выбрали 1 и 2 и заплатили цену, жертвуя # 3 в пользу "Eventual Consistancy". Там отличная бумага на S3 вы можете прочитать. Другие решения для баз данных, такие как DynamoDB, выбрали различные компромиссы.

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

Делать то, что вы описываете, очень сложно. Фактически, я бы сказал, что это почти невозможная проблема для одного разработчика.

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

Ответ 3

Если предприятие может инвестировать в географическое распределение базы данных. Подобно отказоустойчивости; это звучит традиционно, но репликация данных (или репликация хранилища данных) не будет проблемой для маршрутизации трафика.

Вариант 2: - использование кеширования (индивидуальная разработка) и цикличность. ex: с 1:00 до 2:00 использовать моментальный снимок 1 базы данных (скажем, server1/data center 1) 1:59 am server2/data center 2 состоит из новой архитектуры базы данных (новые поля, новые таблицы и т.д.) И @2am весь трафик трафика через центр обработки данных 2.

Обход, основанный на снимке, может быть рассмотрен.

Ответ 4

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

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

Конечно, есть наивные подходы, такие как создание точной копии базы данных перед обновлением, переключение приложения на копирование, обновление и последующее переключение.

Кроме этого, я не могу думать ни о чем другом.

Ответ 5

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

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

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

Третий шаг изменить приложение для чтения только нового поля, развернуть его

Четвертый шаг удалить старые значения полей

Пятый шаг удалите запись старых значений поля из кода, разверните его.

Ответ 6

Единственный возможный случай, когда это может быть достигнуто, - это если у вас есть приложение без апатии. Термин "без гражданства" включает как данные приложения, так и структуру приложения. Помните, что обновление может включать изменение определения бизнес-объектов в дополнение к данным. Учитывая, что такое приложение без гражданства нецелесообразно по очевидным причинам, нет практического способа добиться нулевого времени простоя для общих обновлений. Любое приложение, которое не является апатридом, будет иметь кэширование живых пользователей (в среднесрочных) определения бизнес-объектов и бизнес-данных. Обновление может гарантировать не только новые бизнес-данные, но и новые определения бизнес-объектов. Данные кэширования пользователями в реальном времени всегда могут вызывать потенциальные несоответствия с новой схемой. Таким образом, живых пользователей нельзя переносить, если вы не можете перенести данные и метаданные (бизнес-определения), кэшированные в середине уровня. Если вы сбрасываете кеш среднего уровня, пострадают живые пользователи. Вы можете подумать о том, чтобы позволить живым пользователям продолжать работать под старым db и переносить/сносить любые изменения данных в новый db позже. Но это сложная проблема. Теперь можно ограничить то, что разрешено при обновлении с нулевым временем простоя, не затрагивая живых пользователей, или следить за тем, чтобы после обновления базы данных живые пользователи просто стали пользователями только для чтения, если они не выходят из системы и не возвращаются к новой схеме.