для меня хорошо

python3 вообще няшка и сплошной разлевной каваи

доброго дня, подскажите есть ли средство сравнения двух баз и создания разности их для наката на отставшую базу

или дифференциальный дамп нужен

Для сравнения средств много. А миграции автоматически вам ни одно средство на 100% корректно не сгенерирует.

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

репликацией?

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

Это только если прога кривая. В расширеннной US раскладке программе все вводится элементарно: Alt+e и буква - будет буква удариением, Alt+n затем n - будет ñ. Если нужно часто вводить, то можно поставить родную испанскую раскладку - там  ñ вводится одним нажатием, а ударения - 2 - т.е. не проблема.

доброго дня, подскажите есть ли средство сравнения двух баз и создания разности их для наката на отставшую базу

Полно. Я когда-то давно юзал pg_diff - такая хрень на Java. Все равно все диффы надо вычитывать и местами править. Например, чтобы она сразу добавила поле со значением, или наоборот, сделала его NULL, и не пыталась сделать ему default.

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

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

а через миграции это как?

это если миграции есть

и можно сравнить их версии и накатить недостоющее.

а если нету то ой

в как вы базу версионифицируте? как понять откуда какое изменение пришло? для какой задачи делалось? Или что выросло - то выросло?

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

вместе с данными ? О_О

да конечно

мы в докер пакуем, вместе с данными :)

Если данные - часть обновления, т.е. без чего оно небуедт работать, то да. вместе с ними надо.

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

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

С докерами тут проще будет

в таком случае

Мы очень долго боролись за однородность сред, чтобы изменений практически не было.

С докерами тут проще будет

А как вы его обновляете? Если например, версия меняется?

Это вот у Дорофея лучше спросите. Я обычно миграциями все накатываю, или какими то ETL внятными

А как вы его обновляете? Если например, версия меняется?

целиком контейнером и заменяем

А преобразование самих данных? Или разворачиваете новый, делаете ем новую базу, туда репликацию (Чем? Слонами?) и потом заменяете?

Я так понимаю заворачивают вместе с данными и прям так и разворачивают потом и не надо данные никуда гонять

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

"тулчейн на девелоперской машине" это как-то по хипстерски сильно

а данные накопившиеся за это время в проде?

а они в очень персистентную mq пишутся

мне больше интересно как они на прод катятся потом

каждый раз данные на прод перенакатывают ? :)

да, их там не очень много

как мне это развидеть...

это не совпадает с тем, что у вас в книжке написано? :)

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

это даунтайм у них такой =)

или "время появления данных в базе"

это не совпадает с тем, что у вас в книжке написано? :)

У меня дамп прода разворачивается 14 часов. Вот я и думаю - надо мне сайт выключать на неделю или нет для обновления :) Хочется какой-то более "онлайн" метод :)

в той базе - агрегации статистики, терять данные можно :)

это не совпадает с тем, что у вас в книжке написано? :)

Я не считаю такой подход сильно правильным

А зачем терять данные ?

взяли бы тогда уж монгу, веб скейл все дела ? :)

У меня дамп прода разворачивается 14 часов. Вот я и думаю - надо мне сайт выключать на неделю или нет для обновления :) Хочется какой-то более "онлайн" метод :)

а вам его в том числе на запись нужно?

взяли бы тогда уж монгу, веб скейл все дела ? :)

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

в итоге логика считается хранимками в постгресе в ro и пишется в монгу приложением

Просто кто-то не научился готовить постгрес.

"тулчейн на девелоперской машине" это как-то по хипстерски сильно

не люблю слово "хипстер", мне кажется оно тут не к месту.

не люблю слово "хипстер", мне кажется оно тут не к месту.

А как ? :) модные мальчики с модными тулчейнами =)

Просто кто-то не научился готовить постгрес.

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

Череда уязвлений!

Просто кто-то не научился готовить постгрес.

100k upsert/s на одной машине в студию! :)

А как ? :) модные мальчики с модными тулчейнами =)

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

100k upsert/s на одной машине в студию! :)

а что за машина? :)

а любая из амазоновых

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

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

а любая из амазоновых

а postgres небось 9.4?

постгрес в амазоне так себе затея =)

я бы для этих задач взял бы Redis - было бы ещё быстрее.

а вам его в том числе на запись нужно?

не очень понял вопрос. Во время обновления мне нужно обновлять данные, чтобы все работало.

я бы для этих задач взял бы Redis - было бы ещё быстрее.

редис однопоточный, его шардить внутри машины надо по количеству cpu - боль

ERROR: S client not available

постгрес в амазоне так себе затея =)

куча народа так делает... у Gett Taxi всё в amazon

постгрес в амазоне так себе затея =)

а в чём? нам датацентр, может, ещё построить прикажете? :)

редис однопоточный, его шардить внутри машины надо по количеству cpu - боль

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

куча народа так делает... у Gett Taxi всё в amazon

У меня сейчас тоже всё в azure и amazone и я на пг дей спрашивал, народ как вам живется в облаках, на что зал ответил тишиной или "нормально живется только падает всё чаще" (ц) за точность цитаты не ручаюсь, но смысл приблизительно был таков.

У меня сейчас тоже всё в azure и amazone и я на пг дей спрашивал, народ как вам живется в облаках, на что зал ответил тишиной или "нормально живется только падает всё чаще" (ц) за точность цитаты не ручаюсь, но смысл приблизительно был таков.

с этим никто не спорит, но тут же trade of... может но хуже зато гораздо легче с обслуживанием железа и софта.

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

ну падает и падает, пусть себе падает суть же не в том, чтобы сделать, чтобы не падало, а чтобы быстро поднималось, независимо от того, как упало :)

если оно упало и поднялось внутри реквеста в mq, то никто и не заметит

у меня требования 100.0% доступности по возможности.

миф конечно но 99.9 получается достичь.

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

если вы компания которая занимаетесь технологиями то скорее всего вы сами купите тачки и поставите в дата центр, если же вы далеки от этого и ИТ это просто инструмент для вашей конторы то тогда Amazon, Google сильно выручают, особенно при масштабировании.

у меня требования 100.0% доступности по возможности.

ну вот у всех разные требования

если вы компания которая занимаетесь технологиями то скорее всего вы сами купите тачки и поставите в дата центр, если же вы далеки от этого и ИТ это просто инструмент для вашей конторы то тогда Amazon, Google сильно выручают, особенно при масштабировании.

У нас просто заказчики подвержены модным течениям и влияниям. Свой ДЦ это было бы просто и идеально =)

100% availabiity системы или инстанса?

системы

понятное дело что инстанс может умереть совсем и наглухо

в облаке чаще дохнут инстансы, но рестарт и их замена значительно дешевле

тут скорее вопрос инфраструктурных решений

а если во время разбора сообщения из mq грохнется инстанс, его просто заберёт следующий на второй ретрай, и никто ничего не заметит

Gett вроде был тоже технологическая компания

У нас просто заказчики подвержены модным течениям и влияниям. Свой ДЦ это было бы просто и идеально =)

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

типа попробуй заюзать VRRP протокол между ДЦ в разных частях страны

и потом оказывается что азуровский инстанс не дает назначить еще один virtual IP И прочие "приятные мелочи"

Gett вроде был тоже технологическая компания

Но они не продают ПО или технологии, они продают сервис.

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

если отбросить дилетантов и совсем новичков, то эти люди хорошо умеют считать. И у них получается, что построить с 0 админскую службу которая обеспечит 24/7 аптайм сервера гораздо дороже чем купить инстанс в облаке.

Им по факту интересен PaaS - готовая платформа для работы их кода.

Но они не продают ПО или технологии, они продают сервис.

Имхо, не важно, что ты продаешь, важно какого оно качества.

а Postgres XC\XL\X2 не особо готовы для продакшена?

в докладе на хайлоад говорили что их даже в китайских банках используют уже

а Postgres XC\XL\X2 не особо готовы для продакшена?

Не стОит :)

не стОит для чего именно?