Как стать автором
Обновить
21
-1
Василий Куценко @servarius

User

Отправить сообщение

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

Я идейно с вами согласен. Парсинг очень хочется. Только вот, написание такого функционала - долго и дорого (во всяком случае, для меня). Ну и, чем больше СУБД (читай, диалектов SQL) тем еще сложнее.

Я в статье описал ролевой состав. Можете прикинуть количество людей=) Наш подход к разработке и автоматизации наоборот построен на принципе "разработчик ЛУЧШЕ знает, что он хочет". Ограничения мы вводим только там, где без них нельзя обойтись.

Касательно смены движка - для нас это просто еще один драйвер. Основной кост на смену движка в освоении нового диалекта и нюансов СУБД разработчиком.

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

К данным, я так понимаю, вопрос к DML, т.е. к конкретным значениям. Естественно мы не храним инсертов на 6,5ПБ в гите - это было бы странно. Мы храним DDL и DML в качестве датафиксов, либо инициализирующий загрузки таблицы. В гите у нас так же обвязка - в виде ETL. Это все к тому: 1) Откат для нас = накат нового альтера. Этот сценарий разработчик может приложить к поставке. 2) При откатах мы откатываем всю обвязку в т.ч. ETL (который знает про структуру таблицы нужной версии).

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

Я надеюсь, ответил на вопрос. Если нет - можем продолжить тут или в телеге по желанию.

Для кластера — да.
Сейчас таких планов нет. Анонсировать что-то не возьмусь т.к. со временем как всегда.
Видимо, я не так понял суть, прошу прощения. В данном кейсе мой комментарий действительно смысла не имеет.
Только вот получается, что установить владельца фото — задача тривиальная. И какая разница первое ли это интимное фото или пятнадцатое…
Много моральной боли и все, я думаю. Факапы у всех случаются.
На оба вопроса — пока нет. Но upscale есть в планах. Думаю, что проблемы будут с балансировщиком между masters, т.к. в конфигурации single master его нет.
На то они и минимальные требования. Для посмотреть и разработки есть вариант из Getting Started в готовом контейнере.
У меня пока там не очень много приложений крутится. Не замечал. Но обращу внимание, спасибо. У Вас есть готовое решение как с этим справится?
Не за что, обращайтесь ;)
Еще дополню, раз в планах есть — fabric8. Деплоится на OpenShift, kubernetes и miniShift. Разворачиваются нэймспейсы с набором утилит cd-pipeline, сразу три окружения типа test-staging-prod.
А не пробовали смотреть в сторону кластеризации/оркестрации типа kubernetes и openshift? Не нужно было бы заморачиваться с вводом новых ВМ, сетью на уровне docker. Для каждого дева свой namespace, поддомен и т.д. да и деплой из Гита есть из коробки.
Я бы использовал #du -sm, Он на большинстве версий *nix работает одинаково. Только HP-UX отличается. Зато даже на AIX показывает в мегабайтах.
Было бы отлично с текстовой расшифровкой хотя бы в упрощенном виде.

Информация

В рейтинге
Не участвует
Работает в
Дата рождения
Зарегистрирован
Активность