Интересный кейс, но, кажется, здесь есть еще один пласт проблем, до которого вы пока просто не дошли.
Мы тоже долго исходили из простой модели: SELECT можно вынести на read-only replica, разгрузить primary и получить почти бесплатное горизонтальное масштабирование чтения. На большой транзакционной PostgreSQL-базе выяснилось, что это далеко не всегда работает.
У нас база около 3.4 TB, одна только таблица истории транзакций занимает около 1.3 TB. На PostgreSQL 17.5 один и тот же запрос с практически одинаковой статистикой и одинаковой структурой индексов выполнялся на primary за ~32 ms, а на hot standby мог уходить в десятки секунд. В одном из измерений получили 31k shared buffer hits на primary против 915k на replica при практически одинаковом количестве результирующих строк.
Причина оказалась интереснее обычного replication lag. На hot standby PostgreSQL во время recovery иначе работает с killed/dead index tuples: то, что primary при index scan уже может пропустить, replica в ряде случаев вынуждена проверять через heap из-за MVCC. При этом planner использует нормальную pg_statistic, оценки selectivity у нас буквально совпадали с расчетом статистики, но cost model не отражала реальную дополнительную стоимость такого index scan на standby.
Особенно весело становится, если кто-то до этого “оптимизировал SSD” и поставил условные random_page_cost = 0.5 и seq_page_cost = 0.5. Planner начинает еще сильнее верить в дешевые index scans. У нас удаление этих overrides фактически восстановило работу replica. При тестах повышение random_page_cost с 1.1 до 2.0 уже меняло проблемный план с обычного Index Scan на Bitmap Heap Scan.
Поэтому тезис “чтение с replica разгружает primary” я бы формулировал осторожнее. На OLTP с высокой изменяемостью данных бывает парадоксальная ситуация: прочитать одни и те же данные с primary дешевле, чем с replica. И чем больше история транзакций, churn строк и количество старых index entries, тем заметнее может становиться эффект.
Это не значит, что читать с реплик нельзя. Скорее, replica reads требуют не только контракта по consistency, lag и failover, о которых хорошо написано в статье, но еще и отдельного анализа планов и фактической стоимости запросов именно на standby. Возможно, на текущем профиле нагрузки вы просто еще не встретили этот класс проблем. Но на больших транзакционных базах он вполне реальный.
Я то думал что то интересное, в тут дилетант какой то с ИИ научился читать dbc файлы.
Сам хорошо понимаю работу can шины, буквально на выходных вмешался в работу своего авто чтобы сигнализировал о превышении скорости с оффсетом в 5 км/час.
Я в своих проектах одата использую для отчётности. Делается метариализованное представление, прописывается в качестве entity, интегрируется в Excel или power bi и можно забыть навсегда. Работает отлично.
когда с постгресом познакомитесь поглубже, узнаете что можно аггрегировать строки, объекты, выборки в массивы в виде JSON, а потом легким движением руки производить DTO, то поймете, что хибернейтовские джоины одна из самых главных причин торможения БД. Вот когда начнете работать с таблицами не напрямую, а с представлениям, где данные аккумулированы в регистры сведений, то вспомните эту статью
Когда кто-то начинает жаловаться, что таблицы работают медленно уже при 30 миллионах записей, меня начинает колотить.
Я понимаю, когда записей 3 миллиарда, да, начинает слегка подтормаживать, но если у вас на 3 миллионах уже начинаются сомнения, то сомнения должны быть в первую очередь к себе, к архитектуре и правильности составления запросов...
Полно же всяких партиционирований, отложенных джоинов, промежуточных коммитов в функциях, отложенных триггеров и т.д. и т.д.
Для проверки глубины знаний я задаю базовый вопрос, на который очень редко получаю ответ: “А в чем разница между CI и CD ?”
И? Толк ест?
В качестве примера из жизни: кандидат на собеседовании легко отвечает на вопрос типа какой коэфициент расширения HashMap или сколько байт занимает при инициализации пустой ArrayList, а рассказать как реализовать Singletone он не может. Ну понимает как оно работает. Они выучили много умных слов, знают как на них отвечать, а на практике сделать ничего не могут.
Много лет занимался оупен сорсом, где все мои проекты были покрыты юнит тестами со 100% coverage и я знаю как автоматизировать многие рутинные задачи, как упростить сборку и деплоймент, сделать нормальные пайплайны, хорошо понимаю структуру и сущность того же GitHub Actions, Gitlab CI/CD, Travis CI. И мне глубоко фиолетово кто и что вкладывает в значение CI/CD.
Друзья, помогите найти игру конца 80-х, начала 90-х. Там на космическом броневике ездишь по различным звездам и уничтожаешь вражеские строения и транспорт, помню на первом этапе были Антарес, Альдебаран, Ригель и другие крупные звезды нашего северного полушария. Каждая звезда имела свою цветовую характеристику. Вот нигде не могу найти как игра называлась.
В органических удобрениях содержание азота меньше чем в минеральных. Азот больше нужен на вегетационный период и комбинирование орг и мин удобрений даже полезно. Проблема в том, что на стадии плодообразования нужно уменьшать азот, который в минеральных всегда будет в избытке. Нитраты всегда будут в растении, вопрос лишь в их концентрации, усвояемости и скорости вывода из самого растения.
Все конечно хорошо, только удобрения должны быть органические, а не минеральные, если продукт собираетесь есть. Перекорм азотом может плачевно сказаться в виде нитратов.
40+. Давеча был на втором этапе собеседования. За плечами 20+ лет программирования, интересные авторские статьи на Хабре, оупен сорс библиотеки, мерджи в Apache, SAP.
И тут меня вдруг на втором этапе собеседуют меня два тим лида. Ну как тим лида? Скажем так один реально хороший сеньор, второй средний такой мидл.
Ну и HR после собеседования спрашивает у них мнение и потом мне прилетает отказ. Довольно глупый отказ.
Скажем так, с опытом менеджерские скилы растут, исполнительские падают. К сожалению у нас пока нет четкого понимания чем тим лид отличается от сеньора.
дык людям проще понять "войти через ФБ или поставить лайк", вон как @Ilusha написал... нищает программистская братия. Отвалился то не только FB, но я весь резольвинг и маршруты. У нас гугловские мультикасты DNS стали отвечать с RT от 100мс, хотя обычно 3-5
Возможные варианты причин: 1. жестко прописанные резольверы 2. процессы авторизации через соц сети 3. конфиги для пулов и кластеров 4. гео настройки CDN и стораджей
мало того, можно описывать вложенные объекты друг в друга бесконечно. Писалось да, под драйвер, но в целом получилась универсальная штука, которой можно описывать любые структуры и их зависимости друг от друга. Очень часто использую для обработки именно JSON данных в объекты
Интересный кейс, но, кажется, здесь есть еще один пласт проблем, до которого вы пока просто не дошли.
Мы тоже долго исходили из простой модели: SELECT можно вынести на read-only replica, разгрузить primary и получить почти бесплатное горизонтальное масштабирование чтения. На большой транзакционной PostgreSQL-базе выяснилось, что это далеко не всегда работает.
У нас база около 3.4 TB, одна только таблица истории транзакций занимает около 1.3 TB. На PostgreSQL 17.5 один и тот же запрос с практически одинаковой статистикой и одинаковой структурой индексов выполнялся на primary за ~32 ms, а на hot standby мог уходить в десятки секунд. В одном из измерений получили 31k shared buffer hits на primary против 915k на replica при практически одинаковом количестве результирующих строк.
Причина оказалась интереснее обычного replication lag. На hot standby PostgreSQL во время recovery иначе работает с killed/dead index tuples: то, что primary при index scan уже может пропустить, replica в ряде случаев вынуждена проверять через heap из-за MVCC. При этом planner использует нормальную pg_statistic, оценки selectivity у нас буквально совпадали с расчетом статистики, но cost model не отражала реальную дополнительную стоимость такого index scan на standby.
Особенно весело становится, если кто-то до этого “оптимизировал SSD” и поставил условные random_page_cost = 0.5 и seq_page_cost = 0.5. Planner начинает еще сильнее верить в дешевые index scans. У нас удаление этих overrides фактически восстановило работу replica. При тестах повышение random_page_cost с 1.1 до 2.0 уже меняло проблемный план с обычного Index Scan на Bitmap Heap Scan.
Поэтому тезис “чтение с replica разгружает primary” я бы формулировал осторожнее. На OLTP с высокой изменяемостью данных бывает парадоксальная ситуация: прочитать одни и те же данные с primary дешевле, чем с replica. И чем больше история транзакций, churn строк и количество старых index entries, тем заметнее может становиться эффект.
Это не значит, что читать с реплик нельзя. Скорее, replica reads требуют не только контракта по consistency, lag и failover, о которых хорошо написано в статье, но еще и отдельного анализа планов и фактической стоимости запросов именно на standby. Возможно, на текущем профиле нагрузки вы просто еще не встретили этот класс проблем. Но на больших транзакционных базах он вполне реальный.
Я то думал что то интересное, в тут дилетант какой то с ИИ научился читать dbc файлы.
Сам хорошо понимаю работу can шины, буквально на выходных вмешался в работу своего авто чтобы сигнализировал о превышении скорости с оффсетом в 5 км/час.
а где латеральные джоины? Это же панацея для сращивания больших таблицы при узких выборках
Я в своих проектах одата использую для отчётности. Делается метариализованное представление, прописывается в качестве entity, интегрируется в Excel или power bi и можно забыть навсегда. Работает отлично.
Ansible уже не в моде?
когда с постгресом познакомитесь поглубже, узнаете что можно аггрегировать строки, объекты, выборки в массивы в виде JSON, а потом легким движением руки производить DTO, то поймете, что хибернейтовские джоины одна из самых главных причин торможения БД. Вот когда начнете работать с таблицами не напрямую, а с представлениям, где данные аккумулированы в регистры сведений, то вспомните эту статью
Когда кто-то начинает жаловаться, что таблицы работают медленно уже при 30 миллионах записей, меня начинает колотить.
Я понимаю, когда записей 3 миллиарда, да, начинает слегка подтормаживать, но если у вас на 3 миллионах уже начинаются сомнения, то сомнения должны быть в первую очередь к себе, к архитектуре и правильности составления запросов...
Полно же всяких партиционирований, отложенных джоинов, промежуточных коммитов в функциях, отложенных триггеров и т.д. и т.д.
Дак есть же уже... https://hub.docker.com/_/docker
Docker in Docker!
И? Толк ест?
В качестве примера из жизни: кандидат на собеседовании легко отвечает на вопрос типа какой коэфициент расширения HashMap или сколько байт занимает при инициализации пустой ArrayList, а рассказать как реализовать Singletone он не может. Ну понимает как оно работает. Они выучили много умных слов, знают как на них отвечать, а на практике сделать ничего не могут.
Много лет занимался оупен сорсом, где все мои проекты были покрыты юнит тестами со 100% coverage и я знаю как автоматизировать многие рутинные задачи, как упростить сборку и деплоймент, сделать нормальные пайплайны, хорошо понимаю структуру и сущность того же GitHub Actions, Gitlab CI/CD, Travis CI. И мне глубоко фиолетово кто и что вкладывает в значение CI/CD.
Так вот вопрос: вам шашечки или ехать?
Друзья, помогите найти игру конца 80-х, начала 90-х. Там на космическом броневике ездишь по различным звездам и уничтожаешь вражеские строения и транспорт, помню на первом этапе были Антарес, Альдебаран, Ригель и другие крупные звезды нашего северного полушария. Каждая звезда имела свою цветовую характеристику. Вот нигде не могу найти как игра называлась.
Упустили важный момент или я не нашел в тексте вопрос про разворачивание с бэкапа?
В органических удобрениях содержание азота меньше чем в минеральных. Азот больше нужен на вегетационный период и комбинирование орг и мин удобрений даже полезно.
Проблема в том, что на стадии плодообразования нужно уменьшать азот, который в минеральных всегда будет в избытке. Нитраты всегда будут в растении, вопрос лишь в их концентрации, усвояемости и скорости вывода из самого растения.
очень даже используются. BioBizz, ProOrganic, Go BIO и множество других, даже у GHE вроде что-то появилось и у Advanced Nutritions
Все конечно хорошо, только удобрения должны быть органические, а не минеральные, если продукт собираетесь есть. Перекорм азотом может плачевно сказаться в виде нитратов.
40+. Давеча был на втором этапе собеседования. За плечами 20+ лет программирования, интересные авторские статьи на Хабре, оупен сорс библиотеки, мерджи в Apache, SAP.
И тут меня вдруг на втором этапе собеседуют меня два тим лида. Ну как тим лида? Скажем так один реально хороший сеньор, второй средний такой мидл.
Ну и HR после собеседования спрашивает у них мнение и потом мне прилетает отказ. Довольно глупый отказ.
Скажем так, с опытом менеджерские скилы растут, исполнительские падают. К сожалению у нас пока нет четкого понимания чем тим лид отличается от сеньора.
дык людям проще понять "войти через ФБ или поставить лайк", вон как @Ilusha написал... нищает программистская братия. Отвалился то не только FB, но я весь резольвинг и маршруты. У нас гугловские мультикасты DNS стали отвечать с RT от 100мс, хотя обычно 3-5
Возможные варианты причин:
1. жестко прописанные резольверы
2. процессы авторизации через соц сети
3. конфиги для пулов и кластеров
4. гео настройки CDN и стораджей
https://github.com/Falseclock/dbd-php-entity/blob/d8065a449f75536deec9fd5d873177219f723f5c/tests/DBD/Entity/Tests/ComplexTest.php#L50
Все тоже самое. Создаете класс, делаете маппинг, скармливаете данные и получаете объект.
github.com/Falseclock/dbd-php-entity
до документации руки не дошли, но все очевидно в тестах