Приложение с обновлениями без остановки

форт лисп :)

Я же написал, эта проблема не решается языком, VM, рантаймом. Нужно делать что-то специфичное, вот и спрашиваю

Я же написал, эта проблема не решается языком, VM, рантаймом. Нужно делать что-то специфичное, вот и спрашиваю

для этого и сделали эрланг :) но и там все не так шо-ко-ладно.

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

Но в целом секрет прост: поместить весь проект в гит в разумных пределах и деплоить его за один пулл в идеале... Деплой по гиту для сайтов прекрасно адаптируется.

Это в общем с гитом и проверка на гибкость проекта. Но это не решает проблему горячая замена кода без останова. Это уже другая составляющая...

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

ну магии в ерланге нет, запускай джва инстанса, нутыпонил, реплику бд и т.д.

Есть ссылочка?

Сложно все это, представим гипотетическую ситуацию. Вот есть пользователь по средине какого-то wizard не чисто client size и с сессией, пусть даже в бд. Есть обновление кода и миграция с добавлением (или удалением) колонки в кластере БД из 10 машин и 30 application серверов и 5 серверов статики перед ними. Что делать?!?

миграция с добавлением (или удалением) колонки в кластере БД

У гугла nosql :P

Я дам ссылочку, только позже, ладно? Там, правда, ничего конкретного не написано, всё как я сказал будет.

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

- Изменения в схеме бд предпочтительно делать при помощи добавления новых таблиц, чем изменения старых, это позволит тратить меньше времени на обеспечение обратной совместимости. Для этого при проектировании схемы надо уделить достаточное внимание нормализации. А чтобы это все не тормозило, надо поверх строить слой денормализованных данных, чтобы как можно меньше джойнов;

- Лучше, если СУБД будет поддерживать транзакционность DDL-запросов. Изменения схемы накатываются вместе с обновлением последнего сервера из кластера в единой транзакции, в случае проблем с накатом не потребуется восстановления данных из бэкапа. Постгрес вот хорошо подходит, InnoDB транзакционность DDL не поддерживает, насколько я знаю;

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

У гугла nosql :P

То что у nosql нет схемы пусть хипстеры на конференциях рассказывают. Схема есть, построенная часто исключительно на договоренности или просто единственная которая поддерживается слоем доступа к данным. Выкосите из каждой сущности в nosql половину значений из записи и посмотрите как в у вас нету схемы :)

Я так понял что универсальных практик нет, но в каждом конкретном случае можно выкрутиться

Ну в принципе по делу, спасибо, но я такое и сам знаю. Я бы хотел книгу на 500 страниц

Схема есть

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

Ну это если дефолты тыкать или еще что-то. Но простое добавление столбика полного nullов не так критично, по крайней мере может быть оптимизировано.

Тормозят миграции. Некоторые люди и не мигрируют, например при переименовании лепят всякие аннотации в духе @AlsoLoad, которые если значения нет в одном столбце, то смотрят в другом. Или просто прячут геттером. Особенно это популярно в nosql чтобы не трогать старые данные

может быть оптимизировано.

Может, но вот если надо что-то удалить или поменять тип то тут проблемы. В nosql-решениях обычно схема не энфорсится и это можно и нужно использовать.

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

у нас так было. Был некий движок поиска, который умел искать данные (заданные именем) в sql, sql с blob-полем (внутри блоба - json, т.е. nosql), nosql и в файлах. Причем поиск запускался из PHP обращением к отсутствующему в классе полю (PHP умеет такое перехватывать и обрабатывать - вот в обработчике поиска отсутствующего поля и запускался поиск по БД). Для хэлловорлдов очень симпатично, но на большом проекте отлаживать ошибки и улучшать перфоманс - полный АД

Я слышал о проекте где в блобах Oracle лежала база H2

в этих книжках написаны еще более очевидные очевидности