На сколько помню у Берштейна то что соответствовало ACID, то может называться транзакцией, т.е. ACID=транзакция.
а девочки рисующую рекламу из DuckDB читали Берштейна, они точно понимают о чем говорят или как у датабрика ? если я открою DeckDB в Dbeaver и параллельно моя программа будет менять в транзакции несколько таблиц ? наверняка же Dbeaver ничего не будет знать о внешних для него транзакциях и вычитает неконсистентную кашу.
мы одну и ту же статью читали ? в той что читал было обещание "должны были принести гарантии полноценных баз данных в S3" и на полном серьезе утверждается "это действительно работает. Delta Lake, Iceberg и Hudi обеспечивают надежные ACID-гарантии"
mysql разочаровал абсурдными локами при фуллскане, невинный апдейт/делит с предикатом по полю без индекса лочит нафиг всю таблицу, вызывая дедлоки и прочую хрень. на этом фоне даже вакум постгреса уже не столь уж угнетает.
ни в лейкак, ни в лейкхаусах нет самого понятия транзакция, соответственно "должны были принести гарантии полноценных баз данных в S3" пока далековато.
Еще одна жертва рекламы, так и не видевшая дата лейков. в лейках нет ACID, мало того там нет самих транзакций. там попросту не к чему ACID пристегнуть. конкретно у Databrisks с его Delta форматом таблица это просто папочка, в папочке json с метой. поменять два json в единый момент времени не возможно, соответственно транзакционно записать изменения в несколько таблиц Delta не может. да и Датабрикс мелким шрифтом везде уточняет, что у них атомарность в рамках одной таблички.
правда в том, что ты пытаешься обмануть читателя осознанно подсовывая расчеты на не свежем тесте, хорошо осознавая, что и тест и рассуждения фуфло. цифры из более свежего теста ведут к противоположному выводу, поэтому ты взял не свежий тест и скрыл от читателя. если бы перфоманс спринг был бы в самом деле на уровне мини фреймворков го, это был бы разгром го. то что делается парой аннотаций в спринге, на го потребует тонны кода и месяцы тестирования. со всеми вытекающими по стоимости.
очень скоро ии болванчики все изменят, нагенерят библиотек, обвязок и выиграет не тот язык где короче запись, а где больше рычажков тонкой настройки, возможности влезть в потроха и прочее.
у вас какое-то неверное представление о dbt. dbt это и есть та абстракция, которая скроет движок под низом. ваш аналитик правит dbt пайплайны в уже настроенном проекте dbt, что там под низом один лишь клик или spark он скорее всего и вникать не будет.
локальный spark врятли что-то к масштабируемости даст, у него просто запас прочности на тему джойнов сильно выше, ну и может побогаче SQL синтаксис. при этом пристегнуть локальный спарк к dbt это просто папочку распаковать и переменные среды выставить.
что касается airflow то я тут сетаю на колхоз. если что-то упало airflow пришлет нотификацию, в человеческом виде отобразит, где упало, покажет ретраи, затраченное время. если там начнет тыкать джун, все будет запротоколировано, все что он там наделал. а вам все это колхозить надо.
ну да, потому что airflow+dbt+spark гораздо проще, чем ваше нагромождение, которое совсем не факт, что завтра под нагрузкой продолжит работать (из-за джойнов в клике). airflow+dbt+spark же можно попросить поднять джуна и рассчитывать, что он часик-два посмотрит видосы и через часик-два поднимет. благо туториалов и видосов миллионы.
еще раз, когда вы произносите "airflow+dbt+spark", то джун сходу понимает всю архитектуру. а вот что там у вас, наверняка джун так просто не осилит. документации наверняка толком нет, кто там должен мониторить рефреши вьюшек, как наколхозжены нотификации, как перезапустить с нужного шага, там же тысячи вопросов будет.
плюсы в том, что схема рабочая и всем в индустрии знакомая и тот самый аналитик, без вас знает, что ему в dbt подправить надо, потому что он это делал на предыдущем месте.
это не логично подсовывать читателю невалидные цифры из раунда 22, прекрасно осознавая, что все расчеты на таких цифрах - вранье (цифры из раунда 23 приводят к ровно противоположным выводам). но вы можете кушать, что дают и много, много думать.
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 на обычных тредах.
На сколько помню у Берштейна то что соответствовало ACID, то может называться транзакцией, т.е. ACID=транзакция.
а девочки рисующую рекламу из DuckDB читали Берштейна, они точно понимают о чем говорят или как у датабрика ? если я открою DeckDB в Dbeaver и параллельно моя программа будет менять в транзакции несколько таблиц ? наверняка же Dbeaver ничего не будет знать о внешних для него транзакциях и вычитает неконсистентную кашу.
мы одну и ту же статью читали ? в той что читал было обещание "должны были принести гарантии полноценных баз данных в S3" и на полном серьезе утверждается "это действительно работает. Delta Lake, Iceberg и Hudi обеспечивают надежные ACID-гарантии"
mysql разочаровал абсурдными локами при фуллскане, невинный апдейт/делит с предикатом по полю без индекса лочит нафиг всю таблицу, вызывая дедлоки и прочую хрень. на этом фоне даже вакум постгреса уже не столь уж угнетает.
ни в лейкак, ни в лейкхаусах нет самого понятия транзакция, соответственно "должны были принести гарантии полноценных баз данных в S3" пока далековато.
Еще одна жертва рекламы, так и не видевшая дата лейков. в лейках нет ACID, мало того там нет самих транзакций. там попросту не к чему ACID пристегнуть. конкретно у Databrisks с его Delta форматом таблица это просто папочка, в папочке json с метой. поменять два json в единый момент времени не возможно, соответственно транзакционно записать изменения в несколько таблиц Delta не может. да и Датабрикс мелким шрифтом везде уточняет, что у них атомарность в рамках одной таблички.
дальше читать уже не стал.
правда в том, что ты пытаешься обмануть читателя осознанно подсовывая расчеты на не свежем тесте, хорошо осознавая, что и тест и рассуждения фуфло. цифры из более свежего теста ведут к противоположному выводу, поэтому ты взял не свежий тест и скрыл от читателя.
если бы перфоманс спринг был бы в самом деле на уровне мини фреймворков го, это был бы разгром го. то что делается парой аннотаций в спринге, на го потребует тонны кода и месяцы тестирования. со всеми вытекающими по стоимости.
очень скоро ии болванчики все изменят, нагенерят библиотек, обвязок и выиграет не тот язык где короче запись, а где больше рычажков тонкой настройки, возможности влезть в потроха и прочее.
у вас какое-то неверное представление о dbt. dbt это и есть та абстракция, которая скроет движок под низом. ваш аналитик правит dbt пайплайны в уже настроенном проекте dbt, что там под низом один лишь клик или spark он скорее всего и вникать не будет.
локальный spark врятли что-то к масштабируемости даст, у него просто запас прочности на тему джойнов сильно выше, ну и может побогаче SQL синтаксис. при этом пристегнуть локальный спарк к dbt это просто папочку распаковать и переменные среды выставить.
что касается airflow то я тут сетаю на колхоз. если что-то упало airflow пришлет нотификацию, в человеческом виде отобразит, где упало, покажет ретраи, затраченное время. если там начнет тыкать джун, все будет запротоколировано, все что он там наделал.
а вам все это колхозить надо.
ну да, потому что airflow+dbt+spark гораздо проще, чем ваше нагромождение, которое совсем не факт, что завтра под нагрузкой продолжит работать (из-за джойнов в клике). airflow+dbt+spark же можно попросить поднять джуна и рассчитывать, что он часик-два посмотрит видосы и через часик-два поднимет. благо туториалов и видосов миллионы.
еще раз, когда вы произносите "airflow+dbt+spark", то джун сходу понимает всю архитектуру. а вот что там у вас, наверняка джун так просто не осилит. документации наверняка толком нет, кто там должен мониторить рефреши вьюшек, как наколхозжены нотификации, как перезапустить с нужного шага, там же тысячи вопросов будет.
плюсы в том, что схема рабочая и всем в индустрии знакомая и тот самый аналитик, без вас знает, что ему в dbt подправить надо, потому что он это делал на предыдущем месте.
это не логично подсовывать читателю невалидные цифры из раунда 22, прекрасно осознавая, что все расчеты на таких цифрах - вранье (цифры из раунда 23 приводят к ровно противоположным выводам).
но вы можете кушать, что дают и много, много думать.
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 на обычных тредах.