индексов много (по размеру в 2 раза больше чем сама таблица), таблица очень нагруженная, на нее много сложных запросов идет
Строились, кстати, недолго — около 5 минут в режиме concurrently.
6 дней непрерывной работы. В связи с принятыми в компании требованиями по стабильности продового окружения, мы можем такие работы проводить только в ночное время.
Из старой таблицы в новую данные переливались чуть менее часа.
На наших тестах удаление 10 000 строк занимало около 1 минуты (база на SSD, но очень нагруженная таблица с кучей индексов и констрейнтов).
Нам нужно было убрать 100 млн строк — такая скорость нам не подходила.
Таблицу взял упрощенную для примера, в реальном кейсе использовалась более сложная таблица, которая использовалась в бизнес логике и ее нельзя выносить в rabbit и kafka.
Что касается партиционирования — рецепт на случай, когда сразу его не предусмотрели, но настал момент когда нужно почистить табличку (после чистки уже можно и партиционирование настроить, кстати)
У PO навыки тайм-менеджмента и уровень эмоционального интеллекта должны быть еще выше, чем у разработчика.
Если уж парень на позиции разработчика не умеет нормально коммуницировать с другими людьми («при возникновении спорных моментов в реализации фичи «проблемный» инженер спорит до посинения и не слышит аргументов других разработчиков»), какой из его PO?
Почему уход? На мой взгляд это вполне один из вариантов решения.
Можно же по договоренности с другим руководителем попробовать это сделать.
Не всегда разработчик попадает сразу в нужную команду, может в пределах компании есть более подходящая для него.
И соглашусь с комментатором выше — не всегда имеет смысл держаться до последнего за человека, если видно, что он не вписывается в команду.
Партиционирование не подошло из-за специфики запросов к нагруженным таблицам.
Много запросов, которым требуются данные из разных периодов и потери на сквозном индексе среди партиций сжирали весь прирост скорости от разбиения.
Строились, кстати, недолго — около 5 минут в режиме concurrently.
Добавил в текст статьи эту информацию
Из старой таблицы в новую данные переливались чуть менее часа.
Нам нужно было убрать 100 млн строк — такая скорость нам не подходила.
Что касается партиционирования — рецепт на случай, когда сразу его не предусмотрели, но настал момент когда нужно почистить табличку (после чистки уже можно и партиционирование настроить, кстати)
Под MacOS же вирусов нет...
используется и java и go где нужно.
Если уж парень на позиции разработчика не умеет нормально коммуницировать с другими людьми («при возникновении спорных моментов в реализации фичи «проблемный» инженер спорит до посинения и не слышит аргументов других разработчиков»), какой из его PO?
Можно же по договоренности с другим руководителем попробовать это сделать.
Не всегда разработчик попадает сразу в нужную команду, может в пределах компании есть более подходящая для него.
И соглашусь с комментатором выше — не всегда имеет смысл держаться до последнего за человека, если видно, что он не вписывается в команду.
При чем тут банкет? Просьба же не работу приостановить, а на удаленку часть сотрудников перевести. Работать же эти люди продолжат
Рувдс публикует по 2 статьи в сутки.
Сложновато находить стабильно столько качественных статей для перевода
Правда, зачем его переводить?
Много запросов, которым требуются данные из разных периодов и потери на сквозном индексе среди партиций сжирали весь прирост скорости от разбиения.
Есть self-hosted runners, которые позволяют запускать пайплайн на своём сервере