Вторая версия кода обновит аватар в avatar_url, а первая версия этого обновления не увидит, потому что будет смотреть на поле avatar.
да, действительно. Вероятность не очень большая, потому что записи, как правило, случаются сильно реже чтений, но для популярных нагруженных сервисов может проскочить. Спасибо что заметили!
Спасибо, понимаю ваш пойнт. Не уверен, правда, что это можно считать багом. Например, в моей любимой парадигме "Continuous Deployment" откаты в таком виде вообще не делаются. Там стратегия "всегда только вперед", то есть если нужно сделать откат, то это git revert - push в репозиторий - и опять вперед. Соответственно, в таком случае откат включал бы в себя не только возврат к прежнему коду приложения, но и скрипт для обратной миграции данных.
Разумеется, разные приложения используют разные стратегии для выкладки, да и риск связанный с миграцией данных может сильно отличаться. Для каких-то случаев предложенный вами подход наверняка был бы полезен и помог бы дополнительно подстраховаться от сбоев. Однако, я не уверен что его стоит применять строго всегда и везде.
Полностью согласен, тема нагрузки большая и затронута лишь поверхностно. Почему - во-первых, и так уже длинная простыня получилась :) Во-вторых, в этом месте уже начинаются заметные различия между БД. Как говорится, что мускулю хорошо - то постгре смерть, или наоборот. Ну и в-третьих, статья рассчитана в качестве вводной, чтобы побудить людей этим заниматься. По моим наблюдениям, на многих проектах люди просто даже не пытаются. Если они пробуют делать первые миграции без даунтайма и достигают успехов - то дальше, как правило, все получается. И решения для больших таблиц находят самостоятельно, и все такое. Главное, начать :)
Как провести миграцию базы данных в продакшене без даунтайма, на примере добавления и удаления колонки для существующей таблицы?
Если видно, что к вопросу требуется пояснение, то добавляем: представьте - вы разрабатываете новую фичу, в рамках которой добавляется новая колонка в существующую таблицу в БД, или же наоборот, удаляется. Как выложить это в продакшен так, чтобы во время выкладки приложение всегда работало, чтобы не было никаких сбоев?
Я очень рад, что для вас многое здесь является очевидным, серьезно :) Для многих разработчиков это, к сожалению, не так. У нас есть такой вопрос в техническом опроснике на собеседованиях, и после нескольких сотен проведенных собеседований могу сказать что очень редко люди на него отвечают. Что, собственно, и побудило написать эту статью.
Так что если вы хотя бы в общих чертах представляете, как мигрировать БД без даунтайма - поздравляю, вы входите в небольшой процент людей, которые хотя бы знают с чего начать. Уверен, вы сможете разобраться и дальше, и может даже напишете свой пост, покрывающий более продвинутые аспекты - будет интересно почитать.
Все решается, было бы желание. Во-первых, далеко не всегда прямо уж такая высокая активность в чате, чтобы уже можно было запутаться. Во-вторых, в зависимости от предпочтений команды, могут использоваться треды и/или несколько каналов чата. В-третьих, не чатом единым. Если идут дискуссии по какой-то конкретной задаче или документу, их бывает удобнее вести в комментариях к соответствующей задаче или документу.
Здесь первичен принцип - что все рабочие обсуждения публичны, а уж конкретные средства можно подобрать для каждой ситуации, благо тыщи их.
Аналогия с опенспейсом некорректная, потому что опенспейс - это синхронная коммуникация, а чат - асинхронная. Вот мы с вами здесь общаемся в публичном месте и это могут видеть все желающие. Разве можно сказать, что мы кричим всем этим людям на ухо?
Разумеется, мы понимаем что чтение чата занимает время, и считаем это важной частью работы. Только по опыту, это далеко не так много времени, как может показаться с непривычки. Чтение Хабра, к примеру, занимает гораздо больше времени :)
Проблема с тем "откуда взять время" она, как обычно, означает "откуда взять желание". Одни чувствуют себя в такой обстановке комфортно прям с первого дня, другим требуется адаптация, а кому-то не заходит вообще. Хочу заметить, с режимом "роутер" абсолютная такая же история - он далеко не всем по нраву.
Уведомления настраиваются. Рекомендуемая у нас настройка - уведомления включены для упоминаний человека через @ (в том числе личные сообщения) и отключены для постов в общие каналы. Таким образом, достигается баланс - канал можно и нужно читать в асинхронном режиме, открывая его когда удобно, и вся команда по умолчанию так и делает. Однако, если вопрос срочный, то всегда можно привлечь внимание нужного человека упомянув его через @.
Чат - важное средство общения, но вовсе не единственное. Хранить детали конкретных задач в чате конечно же неудобно, они легко теряются, поэтому для задач есть таск-треккеры. Таск-треккеры, кстати, часто интегрированы с чатом, чтобы в чате был виден весь поток информации. Некоторые вещи бывает удобно оформить не в виде задачи, а в виде общедоступного документа, например в Notion, Confluence, или где-то еще.
Одни и те же вопросы могут обсуждаться по нескольку раз если результаты обсуждений не записываются. Рекомендации довольно стандартные, если что-то обсуждали и что-то решили - обновите соответствующую задачу или документ. После митингов пишите резюме. Это все я отношу к выстраиванию "дисциплины коммуникации в команде". Выстроить ее с нуля бывает сложно, и поддержание дисциплины требует усилий, но если это налажено - оно реально работает.
Как часто проводить митинги каждая команда решает сама. Плановый общекомандный митинг у нас обычно раз в неделю, обсуждаем ближайшие приоритеты. Помимо этого бывают спонтанные митинги по рабочим вопросам, когда людям нужно что-то обсудить и чат для этого не очень удобен.
Я немножко погуглил, и не вижу никаких лицензионных препятствий для использования Named license в облачной виртуалке. Есть ограничения на количество устройств на которых можно использовать лицензию, ну и вроде бы все. Если что-то упустил — дайте знать.
Почитал про эту люстру, и чото не пойму пока, ни как ее применить, ни сколько это будет стоить в итоге… Там две версии:
Amazon FSx for Windows File Server — специально для винды, но не умеет синхронизироваться с S3;
Amazon FSx for Lustre — умеет синхронизироваться с S3, но кажется это для линуксов.
По поводу стоимости не совсем понятно — она указана в МБ/с за терабайт, и при этом есть baseline и burst… бррр. У вас есть опыты пользования всем этим? Как оно работает на практике? К примеру, сколько будет стоить 200ГБ диск с производительностью аналогичной Instance Store SSD?
Все верно, трафик тоже нужно учесть. Давайте посчитаем, во сколько обойдется закачивание 100ГБ через S3 на EC2 сервер в том же регионе. Цены берем из амазонского ценника для S3:
Для начала, нам нужно будет засунуть данные в S3. Это категория «Data Transfer IN To Amazon S3 From Internet», то есть $0.00 per GB;
После этого, нам нужно передать данные из S3 на EC2 сервер в том же регионе. Это описано фразой в самом начале: «You pay for all bandwidth into and out of Amazon S3, except for the following:… Data transferred from an Amazon S3 bucket to any AWS service(s) within the same AWS Region as the S3 bucket (including to a different account in the same AWS region).» Другими словами, бесплатно;
Но это конечно же еще не все, как известно, амазона берет копеечку за каждый чих и пук. Нужно еще учесть стоимость входящего трафика для EC2, который описан в соответствующем ценнике для EC2 в разделе «Data Transfer IN To Amazon EC2 From Internet» и составляет $0.00 per GB.
да, действительно. Вероятность не очень большая, потому что записи, как правило, случаются сильно реже чтений, но для популярных нагруженных сервисов может проскочить. Спасибо что заметили!
Спасибо, добавил ссылку на gh-ost в раздел про вялотекущие миграции. Ну и подумаю как можно было бы уточнить ЦА для статьи :)
Спасибо, понимаю ваш пойнт. Не уверен, правда, что это можно считать багом. Например, в моей любимой парадигме "Continuous Deployment" откаты в таком виде вообще не делаются. Там стратегия "всегда только вперед", то есть если нужно сделать откат, то это git revert - push в репозиторий - и опять вперед. Соответственно, в таком случае откат включал бы в себя не только возврат к прежнему коду приложения, но и скрипт для обратной миграции данных.
Разумеется, разные приложения используют разные стратегии для выкладки, да и риск связанный с миграцией данных может сильно отличаться. Для каких-то случаев предложенный вами подход наверняка был бы полезен и помог бы дополнительно подстраховаться от сбоев. Однако, я не уверен что его стоит применять строго всегда и везде.
Возможно, речь идет про Postgres версий 10 и раньше. Такая проблема была устранена в Postgres v11, я упоминал об этом в статье.
спасибо! Вполне возможно что есть баг, все люди ошибаются. Если подскажете где - буду признателен
Полностью согласен, тема нагрузки большая и затронута лишь поверхностно. Почему - во-первых, и так уже длинная простыня получилась :) Во-вторых, в этом месте уже начинаются заметные различия между БД. Как говорится, что мускулю хорошо - то постгре смерть, или наоборот. Ну и в-третьих, статья рассчитана в качестве вводной, чтобы побудить людей этим заниматься. По моим наблюдениям, на многих проектах люди просто даже не пытаются. Если они пробуют делать первые миграции без даунтайма и достигают успехов - то дальше, как правило, все получается. И решения для больших таблиц находят самостоятельно, и все такое. Главное, начать :)
Вопрос звучит так:
Если видно, что к вопросу требуется пояснение, то добавляем: представьте - вы разрабатываете новую фичу, в рамках которой добавляется новая колонка в существующую таблицу в БД, или же наоборот, удаляется. Как выложить это в продакшен так, чтобы во время выкладки приложение всегда работало, чтобы не было никаких сбоев?
Я очень рад, что для вас многое здесь является очевидным, серьезно :) Для многих разработчиков это, к сожалению, не так. У нас есть такой вопрос в техническом опроснике на собеседованиях, и после нескольких сотен проведенных собеседований могу сказать что очень редко люди на него отвечают. Что, собственно, и побудило написать эту статью.
Так что если вы хотя бы в общих чертах представляете, как мигрировать БД без даунтайма - поздравляю, вы входите в небольшой процент людей, которые хотя бы знают с чего начать. Уверен, вы сможете разобраться и дальше, и может даже напишете свой пост, покрывающий более продвинутые аспекты - будет интересно почитать.
Все решается, было бы желание. Во-первых, далеко не всегда прямо уж такая высокая активность в чате, чтобы уже можно было запутаться. Во-вторых, в зависимости от предпочтений команды, могут использоваться треды и/или несколько каналов чата. В-третьих, не чатом единым. Если идут дискуссии по какой-то конкретной задаче или документу, их бывает удобнее вести в комментариях к соответствующей задаче или документу.
Здесь первичен принцип - что все рабочие обсуждения публичны, а уж конкретные средства можно подобрать для каждой ситуации, благо тыщи их.
По моему опыту как раз наоборот - "загнать всех в общий чат" гораздо сложнее, если конечно при этом ставится цель обеспечить эффективную работу.
That said, это конечно мое частное мнение и мой опыт. У вас разумеется свой опыт, и наверное в вашем опыте вещи выглядят иначе.
Аналогия с опенспейсом некорректная, потому что опенспейс - это синхронная коммуникация, а чат - асинхронная. Вот мы с вами здесь общаемся в публичном месте и это могут видеть все желающие. Разве можно сказать, что мы кричим всем этим людям на ухо?
Разумеется, мы понимаем что чтение чата занимает время, и считаем это важной частью работы. Только по опыту, это далеко не так много времени, как может показаться с непривычки. Чтение Хабра, к примеру, занимает гораздо больше времени :)
Проблема с тем "откуда взять время" она, как обычно, означает "откуда взять желание". Одни чувствуют себя в такой обстановке комфортно прям с первого дня, другим требуется адаптация, а кому-то не заходит вообще. Хочу заметить, с режимом "роутер" абсолютная такая же история - он далеко не всем по нраву.
Уведомления настраиваются. Рекомендуемая у нас настройка - уведомления включены для упоминаний человека через @ (в том числе личные сообщения) и отключены для постов в общие каналы. Таким образом, достигается баланс - канал можно и нужно читать в асинхронном режиме, открывая его когда удобно, и вся команда по умолчанию так и делает. Однако, если вопрос срочный, то всегда можно привлечь внимание нужного человека упомянув его через @.
Отличные вопросы :)
Чат - важное средство общения, но вовсе не единственное. Хранить детали конкретных задач в чате конечно же неудобно, они легко теряются, поэтому для задач есть таск-треккеры. Таск-треккеры, кстати, часто интегрированы с чатом, чтобы в чате был виден весь поток информации. Некоторые вещи бывает удобно оформить не в виде задачи, а в виде общедоступного документа, например в Notion, Confluence, или где-то еще.
Одни и те же вопросы могут обсуждаться по нескольку раз если результаты обсуждений не записываются. Рекомендации довольно стандартные, если что-то обсуждали и что-то решили - обновите соответствующую задачу или документ. После митингов пишите резюме. Это все я отношу к выстраиванию "дисциплины коммуникации в команде". Выстроить ее с нуля бывает сложно, и поддержание дисциплины требует усилий, но если это налажено - оно реально работает.
Как часто проводить митинги каждая команда решает сама. Плановый общекомандный митинг у нас обычно раз в неделю, обсуждаем ближайшие приоритеты. Помимо этого бывают спонтанные митинги по рабочим вопросам, когда людям нужно что-то обсудить и чат для этого не очень удобен.
По поводу стоимости не совсем понятно — она указана в МБ/с за терабайт, и при этом есть baseline и burst… бррр. У вас есть опыты пользования всем этим? Как оно работает на практике? К примеру, сколько будет стоить 200ГБ диск с производительностью аналогичной Instance Store SSD?
Итоговая стоимость — $0.00.