dbt супортит спарк (+click connector) точно также как все остальное, точно так же все на SQL можно строить. airflow это просто оркестратор, логика вся в dbt пайплайнах, джойн спарку в том же dbt аналитик должен описывать
в комитах видно, что поставили коннекшен пул 256, до этого дефолт был 10. вырубили логинг, вырубили ssl. на 10 коннекшенов не удивительно, что спринг в конце болтался, хотя наверняка это не все. тест лажа полная.
да, наверно соглашусь. в Fortunes тесте все в коннекшен пул базы упрется, VT не даст большого прироста. там еще какие-то тесты есть с json и текстовыми файлами. вот там VT может будет полезней.
а зачем ему допускать, мы же все видим что ты подогнал результат, взяв раунд 22, хотя актуальный раунд 23 привел бы ровно к противоположным выводам (не менее бредовым, учитывая абсурдность тестов).
в данном случае речь о папочке "spring", как я вижу там совсем дефолтный спринг, без ничего. врубят VirtualThread - получат преимущество над Go gin не два раза, а в три. по спринг с реактивностью есть отдельная папочка "spring-webflux-r2dbc" и не особо там быстрее дефолтного спринга, на 2 места выше. в целом конечно TechEmpower фигня полная, Go gin на mysql, Spring на postgres что с таким подходом сравнить хотят не особо понятно.
Я не вижу даже сейчас, что бы фигурировал VirtualThread в spring папочке, т.е. конкретно в раунд 23 по spring Virtual Threads ничего не решил и большой вопрос что за фигню они в 22 раунде натестили, что спринг был так низко оказался.
тогда следующая серия должна начаться с объяснения на кой было подсовывать неактуальные цифры из 22 раунда и делать все эти бессмысленные расчеты.
а вообще, было бы намного интересней посмотреть разбор что там реально эти дурачки натестили. не объясняется ли скачек Java читерскими оптимизациями, есть ли у Go честный темплейт енжин, честно ли они оба вычисляют размер ответа в header и прочее, что упоминал чувак про C#. мне кажется когда я заглядывал в 2025 году в round 23, там была java 21, но не было у спринга включенных Virtual Threads. ну и сейчас видно что чуваки поменяли запуск на java 23, а в pom.xml так и осталась java 21. чудики явно не понимают, что делают.
этот TechEmpower совсем фуфлыжный тест, зачем такое приплетать к расчетам ? вон чувак разбирает на примере C# vs Java, у .Net там все фуфлыжное и реально ничего от фреймворка не используется. даже headers там константа и отдается из кеша: https://dusted.codes/how-fast-is-really-aspnet-core
наверняка Go точно так же слил по всем пунктам и просто накрутил счетчик, как .Net
ну и тесты там устаревшие, без волшебных Java Vitrual Threads
заглянул в статью, Go там тоже есть, имплементация норм (No shortcuts or trickery to be found here), но и скорость соответственно ниже Java, причем опять ниже чем Java на обычных тредах.
Запросы возвращают несогласованные результаты. Люди называют это болотом (data swamp), но настоящая проблема — отсутствие контроля транзакций.
попахивает ai контентом. болотом, в том числе Блл Инмон называют свалку сырых данных, без валидации и ссылочной целостности. транзакций и в классических dwh не было. никто весь бач одной транзакцией не заливал. в плане консистентности лейки зачастую даже выигрывают.
нет там путаницы, Кайт обозвал это mini-rollback, на то они и мини, что не снимают блокировок. но тут то дело не в жонглировании терминов, а в наличии самого механизма. мсскл (на rc snapshot) блокировки предикатов накладывает, убивая параллельность и перфоменс, оракл mini-rollback устраивает, а пг ничего не делает и просто забивает на консистентность.
пост Кайта тогда открыл портал в ад и несколько лет каждый считал своим долгом хоть что-то ляпнуть на тему этих mini-rollback, т.к. формально они противоречили утверждению в документации (в доке утверждалось, что на RC запрос видит данные на момент старта запроса). автономные триггеры же лишь инструмент, помогающий понять что там под капотом происходит.
но это все лирика, тут важно что у пг без mini-rollback результат не другой, а неконсистентный.
PostgreSQL doesn't have this (because it would require implicit savepoints for each statement, and savepoints are expensive in PostgreSQL) and restarts only the reading of the row. This results in inconsistent snapshots (results with rows from two states), but it still fits the SQL standard definition of read committed (which requires reading only the committed changes, ignoring that in MVCC databases, they can come from different commit times).
именно, "примерно в единый момент" это нифига не ACID. потому и пришлось изобретать свой шедуллер с блокировками, что бы хотя бы спарк джобы выстраивать аля serializable. а вот пользователи импалы увы, кушают что дают. благо у нас это некий вспомогательный тул.
но с другой стороны никто и не ожидал чуда, на ораклах и mssql тоже dwh загрузки никто в одной транзакции не делал.
dbt супортит спарк (+click connector) точно также как все остальное, точно так же все на SQL можно строить.
airflow это просто оркестратор, логика вся в dbt пайплайнах, джойн спарку в том же dbt аналитик должен описывать
цифры чудак выковыривал из 2023 года, потому что в 2024 жаве connection pool настроили и цифры уже ровно противоположные.
мутный подход, завтра понадобится чуть больше джойнов и все посыпется.
размеры крошечные, обычный airflow + спарк в режиме local мне кажется надежней было бы
в комитах видно, что поставили коннекшен пул 256, до этого дефолт был 10. вырубили логинг, вырубили ssl.
на 10 коннекшенов не удивительно, что спринг в конце болтался, хотя наверняка это не все. тест лажа полная.
да, наверно соглашусь. в Fortunes тесте все в коннекшен пул базы упрется, VT не даст большого прироста. там еще какие-то тесты есть с json и текстовыми файлами. вот там VT может будет полезней.
а зачем ему допускать, мы же все видим что ты подогнал результат, взяв раунд 22, хотя актуальный раунд 23 привел бы ровно к противоположным выводам (не менее бредовым, учитывая абсурдность тестов).
в данном случае речь о папочке "spring", как я вижу там совсем дефолтный спринг, без ничего. врубят VirtualThread - получат преимущество над Go gin не два раза, а в три. по спринг с реактивностью есть отдельная папочка "spring-webflux-r2dbc" и не особо там быстрее дефолтного спринга, на 2 места выше.
в целом конечно TechEmpower фигня полная, Go gin на mysql, Spring на postgres что с таким подходом сравнить хотят не особо понятно.
Я не вижу даже сейчас, что бы фигурировал VirtualThread в spring папочке, т.е. конкретно в раунд 23 по spring Virtual Threads ничего не решил и большой вопрос что за фигню они в 22 раунде натестили, что спринг был так низко оказался.
тогда следующая серия должна начаться с объяснения на кой было подсовывать неактуальные цифры из 22 раунда и делать все эти бессмысленные расчеты.
а вообще, было бы намного интересней посмотреть разбор что там реально эти дурачки натестили. не объясняется ли скачек Java читерскими оптимизациями, есть ли у Go честный темплейт енжин, честно ли они оба вычисляют размер ответа в header и прочее, что упоминал чувак про C#. мне кажется когда я заглядывал в 2025 году в round 23, там была java 21, но не было у спринга включенных Virtual Threads. ну и сейчас видно что чуваки поменяли запуск на java 23, а в pom.xml так и осталась java 21. чудики явно не понимают, что делают.
и еще смешная подтасовка с TechEmpower - взят раунд 22 из 2023 года, хотя год назад состоялся раунд 23 (Fortunes), где java spring на 179, а Go gin на 284 месте
https://www.techempower.com/benchmarks/#section=data-r23
этот TechEmpower совсем фуфлыжный тест, зачем такое приплетать к расчетам ? вон чувак разбирает на примере C# vs Java, у .Net там все фуфлыжное и реально ничего от фреймворка не используется. даже headers там константа и отдается из кеша:
https://dusted.codes/how-fast-is-really-aspnet-core
наверняка Go точно так же слил по всем пунктам и просто накрутил счетчик, как .Net
ну и тесты там устаревшие, без волшебных Java Vitrual Threads
заглянул в статью, Go там тоже есть, имплементация норм (No shortcuts or trickery to be found here), но и скорость соответственно ниже Java, причем опять ниже чем Java на обычных тредах.
Запросы возвращают несогласованные результаты. Люди называют это болотом (data swamp), но настоящая проблема — отсутствие контроля транзакций.
попахивает ai контентом. болотом, в том числе Блл Инмон называют свалку сырых данных, без валидации и ссылочной целостности. транзакций и в классических dwh не было. никто весь бач одной транзакцией не заливал. в плане консистентности лейки зачастую даже выигрывают.
Interbase
в одной таблице у пг тоже играет роль.
когда-то у меня был документ с деталями по ораклу, вот он наверное
https://www.scribd.com/document/664443628/Write-Consistency
нет там путаницы, Кайт обозвал это mini-rollback, на то они и мини, что не снимают блокировок. но тут то дело не в жонглировании терминов, а в наличии самого механизма. мсскл (на rc snapshot) блокировки предикатов накладывает, убивая параллельность и перфоменс, оракл mini-rollback устраивает, а пг ничего не делает и просто забивает на консистентность.
пост Кайта тогда открыл портал в ад и несколько лет каждый считал своим долгом хоть что-то ляпнуть на тему этих mini-rollback, т.к. формально они противоречили утверждению в документации (в доке утверждалось, что на RC запрос видит данные на момент старта запроса). автономные триггеры же лишь инструмент, помогающий понять что там под капотом происходит.
но это все лирика, тут важно что у пг без mini-rollback результат не другой, а неконсистентный.
верно у пг нет микроткатов, там просто inconsistent snapshots. оракл же реализовал микрооткаты
PostgreSQL doesn't have this (because it would require implicit savepoints for each statement, and savepoints are expensive in PostgreSQL) and restarts only the reading of the row. This results in inconsistent snapshots (results with rows from two states), but it still fits the SQL standard definition of read committed (which requires reading only the committed changes, ignoring that in MVCC databases, they can come from different commit times).
вот и выросло поколение детей, ничего не слышавших про микрорестарт.
https://asktom.oracle.com/ords/f?p=100:11:0::::P11_QUESTION_ID:11504247549852
именно, "примерно в единый момент" это нифига не ACID. потому и пришлось изобретать свой шедуллер с блокировками, что бы хотя бы спарк джобы выстраивать аля serializable. а вот пользователи импалы увы, кушают что дают. благо у нас это некий вспомогательный тул.
но с другой стороны никто и не ожидал чуда, на ораклах и mssql тоже dwh загрузки никто в одной транзакции не делал.
я не очень понял, чего ты от меня хочешь, насмешек ?
у Бернштейна в определении не строка, не поле и не таблица, у Бернштейна в определении база данных. в любом учебнике разжевано, почему это важно.