в данном случае речь о папочке "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 загрузки никто в одной транзакции не делал.
Кривовато решили, но в целом работает. Самопальный шедуллер с шаред и эксклюзив блокировками на уровне целого DAG, пишем в дельту, а потом еще копия в parquets для пользователей impala. в импале делаем alter table set location на новую папку, у пользователей выглядит буд-то вся база страны примерно в единый момент поменялась. плюс эти паркеты в BI на Vertica грузят. вот они грузят как раз ночью.
страны европейские, т.е. часовой пояс примерно одинаковый, фишка именно в скоринге. это получается часть бизнес логики локальных систем, локальные системы принимают решения по этому скорингу, и бывает что им важно выслать письмо до 12:00 или выбрать кому первому звонить. врятли это уж прямо совсем критично, но без скорнинга могут встать некоторые процессы, а данные для решения нужны и из соседних стран.
да можно и здесь. а почему в ночное окно ? почему идемпотентны ? грамотная оркестрация ? очевидно же от того что у надстроек над файликами нет acid и если грузить в разгар дня, пользователи неконсистентную кашу увидят. вот потому вы делаете serializable вручную.
у нас потребности есть, но хадуп старый, я уже старый и давно понял, что выгодней халтурить на сторону, чем че-то новомодное проталкивать и потом все это тащить лидером. так вот, у нас десятки стран, сотни мутных систем и все они в своем ритме сбрасывают данные в хадуп, кроме всего прочего поверх этих данных считаются скоринги. вот тут и потребности в скорости и смывается грань с операционной системой, т.к. кусок логики скоринг забрал. а они у себя в отдельной стране нормальный скоринг не сделают, нужны данные хотя бы соседних стран. выходит или страны вытягивают друг у друга данные и делают микро dwh или идут в централизованную платформу
и типа никогда не приходилось приседать, что бы эмулировать этот acid ? пользователи всегда были согласны видеть транзакции, до того как клиент загружен ? наперника, как и все, использовали приемчики с закатом солнца в ручную.
в данном случае речь о папочке "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 загрузки никто в одной транзакции не делал.
я не очень понял, чего ты от меня хочешь, насмешек ?
у Бернштейна в определении не строка, не поле и не таблица, у Бернштейна в определении база данных. в любом учебнике разжевано, почему это важно.
Кривовато решили, но в целом работает. Самопальный шедуллер с шаред и эксклюзив блокировками на уровне целого DAG, пишем в дельту, а потом еще копия в parquets для пользователей impala. в импале делаем alter table set location на новую папку, у пользователей выглядит буд-то вся база страны примерно в единый момент поменялась. плюс эти паркеты в BI на Vertica грузят. вот они грузят как раз ночью.
Сам же видишь определение в твоем источнике "a set of actions that transform the database"
требование на уровне всей базы, а в базе не одна табличка.
страны европейские, т.е. часовой пояс примерно одинаковый, фишка именно в скоринге. это получается часть бизнес логики локальных систем, локальные системы принимают решения по этому скорингу, и бывает что им важно выслать письмо до 12:00 или выбрать кому первому звонить. врятли это уж прямо совсем критично, но без скорнинга могут встать некоторые процессы, а данные для решения нужны и из соседних стран.
да можно и здесь.
а почему в ночное окно ? почему идемпотентны ? грамотная оркестрация ? очевидно же от того что у надстроек над файликами нет acid и если грузить в разгар дня, пользователи неконсистентную кашу увидят. вот потому вы делаете serializable вручную.
у нас потребности есть, но хадуп старый, я уже старый и давно понял, что выгодней халтурить на сторону, чем че-то новомодное проталкивать и потом все это тащить лидером. так вот, у нас десятки стран, сотни мутных систем и все они в своем ритме сбрасывают данные в хадуп, кроме всего прочего поверх этих данных считаются скоринги. вот тут и потребности в скорости и смывается грань с операционной системой, т.к. кусок логики скоринг забрал. а они у себя в отдельной стране нормальный скоринг не сделают, нужны данные хотя бы соседних стран. выходит или страны вытягивают друг у друга данные и делают микро dwh или идут в централизованную платформу
и типа никогда не приходилось приседать, что бы эмулировать этот acid ? пользователи всегда были согласны видеть транзакции, до того как клиент загружен ?
наперника, как и все, использовали приемчики с закатом солнца в ручную.
попахивает распилом, процессоров нет. на кой было тратить время ?