А вы видели чтобы кто нибудь когда нибудь синхронизировался на value-based типах. Что это может быть за кейс? Или может быть на реальный баг натыкались? Я просто за 15 лет такого не встречал.
JEP 390 для подготовки к valhalla, там собственно про это и написано.
На самом деле описать схему протобаф по dto модели это 5 минут пользуясь тем же чатгпт или дипсик. Опять же в случае с grpc вы получаете проверенный оттестированый транспорт, асинхронный клиент из коробки. Не понимаю правда зачем в 2025 городить свой rpc.
Ещё вопрос, а тестировать как руками? С рестом понятно, для grpc сейчас тоже есть клиенты. Будете ещё тулинг писать к своему протоколу?
Так я не про память ram, я про диск. Каждое обновление создает новую версию той же строки, периодически запускается avtovacuum для очистки старых значений + обновление индекса, это достаточно жирные процессы. Может создаваться ситуация когда нагрузка при каждом следующем vacuum увеличивается и в конечном счёте через день два получаем колом вставшую базу. Видел такое на проде. Поэтому тест этот нужно гонять и смотреть на всю систему и все процессы. Причем гонять именно сутками, даже за час вы эту деградацию скорее всего не увидите. Можно конечно использовать unlogged таблицы которые не пишут wal(при сбое данные пропадут). Но тогда зачем тут постгрес?
Так получается самые нагруженные методы просто через сервлеты написаны? В чём тогда вообще смысл использовать спринг? Чтобы его в критических местах не использовать? Может просто взять другой фреймворк?
Горизонтально масштабируемые транзакционные бд, которых к сожалению не так много.
Шардирование имеющихся бд. Скорее всего наиболее часто используемый вариант на данный момент. Но тут конечно минус, вся кодовая база должна поддерживать шардирование.
@bibendi нужно отметить один важный момент - это производительность, БД становится узким местом при таком подходе. Думаю стоит про это упомянуть. И да, понятно, что мы платим эту цену за надёжность и непротиворечивость доставки.
Понятно что не думает как человек. Но в весах модели заложена логика, которая собственно есть в текстах. Иначе как он решает задачи про шестерёнки(в какую строну будет крутиться последняя шестерёнка, если первую повернуть влево/вправо). И это очень похоже на наш интеллект в части того, как мы пользуемся логикой для решения задач.
В целом же предлагают использовать обратносовместимые изменения при релизе. Поэтому по идее откатывать ничего не нужно. А есть какие нибудь инструменты с поддержкой отката?
Очень сложно добиться нужного результата. Да какой то результат будет, но почти наверняка не, то что вы хотели. Постоянно пробую разные чаты, есть подписка openai. Удачных кейсов по разработке у себя могу по пальцам пересчитать. Чаще быстрее самому написать
single thread executor работает медленее чем обычный synchronized в 2 раза. Хоть на долгих, хоть на быстрых операциях. SpinLock работает так же как и ReentrantLock или synchronized. Поэтому для java ваши выводы не применимы
"То есть можно "говнокодить" на уровне приложения и не следить за его производительностью? Не согласен совсем. И я привел пример почему, на основе опыта Paypal."
Опыт paypal ничего нам не говорит о java и nodejs, так как мы не знаем что они там и как переписали и какого уровня по и разработчики были на java и на nodejs. На любом языке можно написать плохо.
Что касается асинхронного и синхронного подхода, то средства нужно выбирать под задачу. Если у вас есть nfr с большой нагрузкой то возможно нужно будет использовать асинхронный код. Если же у вас их нет, то асинхронный код - обычный оверинжиниринг, который ни к чему кроме увелечения стоимости разработки и поддержки не ведёт. И да в реальных тестах r2dbc не всегда может показать результаты лучше, так как упретесь вы скорее всего раньше в базу.
Подход ваш понятен, попробую на java потестить и сравнить
А вы видели чтобы кто нибудь когда нибудь синхронизировался на value-based типах. Что это может быть за кейс? Или может быть на реальный баг натыкались? Я просто за 15 лет такого не встречал.
JEP 390 для подготовки к valhalla, там собственно про это и написано.
Ошибка конечно джуновая
На самом деле описать схему протобаф по dto модели это 5 минут пользуясь тем же чатгпт или дипсик. Опять же в случае с grpc вы получаете проверенный оттестированый транспорт, асинхронный клиент из коробки. Не понимаю правда зачем в 2025 городить свой rpc.
Ещё вопрос, а тестировать как руками? С рестом понятно, для grpc сейчас тоже есть клиенты. Будете ещё тулинг писать к своему протоколу?
Почему не взять grpc? Автогенерация для большинства популярных языков и фреймворков. Чем ваш подход лучше?
Так я не про память ram, я про диск. Каждое обновление создает новую версию той же строки, периодически запускается avtovacuum для очистки старых значений + обновление индекса, это достаточно жирные процессы. Может создаваться ситуация когда нагрузка при каждом следующем vacuum увеличивается и в конечном счёте через день два получаем колом вставшую базу. Видел такое на проде. Поэтому тест этот нужно гонять и смотреть на всю систему и все процессы. Причем гонять именно сутками, даже за час вы эту деградацию скорее всего не увидите. Можно конечно использовать unlogged таблицы которые не пишут wal(при сбое данные пропадут). Но тогда зачем тут постгрес?
Тут интресно что там с vacuum на постргрес, ресурсов будет потреблять на порядок больше, особенно io
А может это специально созданный алгоритм для введения противника в заблуждение?
События в бд не надёжно. Только репликация и полинг даст хорошую гарантию.
Так получается самые нагруженные методы просто через сервлеты написаны? В чём тогда вообще смысл использовать спринг? Чтобы его в критических местах не использовать? Может просто взять другой фреймворк?
Тема не раскрыта. Утверждение что передача json занимает 200 мс, а protobuf 20 мс нужно проверить. Напишите хотя бы простейший перф тест.
Чтение с wal лога хороший вариант согласен. Единственное бывает не всегда доступен в инфраструктуре компании.
На мой взгляд тут 2 варианта.
Горизонтально масштабируемые транзакционные бд, которых к сожалению не так много.
Шардирование имеющихся бд. Скорее всего наиболее часто используемый вариант на данный момент. Но тут конечно минус, вся кодовая база должна поддерживать шардирование.
@bibendi нужно отметить один важный момент - это производительность, БД становится узким местом при таком подходе. Думаю стоит про это упомянуть. И да, понятно, что мы платим эту цену за надёжность и непротиворечивость доставки.
Понятно что не думает как человек. Но в весах модели заложена логика, которая собственно есть в текстах. Иначе как он решает задачи про шестерёнки(в какую строну будет крутиться последняя шестерёнка, если первую повернуть влево/вправо). И это очень похоже на наш интеллект в части того, как мы пользуемся логикой для решения задач.
Нашёл у liquibase и flyway в enterprise. Буду иметь ввиду. Но в целом конечно в автоматическом режиме выглядит конечно рискованно у liquibase.
В целом же предлагают использовать обратносовместимые изменения при релизе. Поэтому по идее откатывать ничего не нужно. А есть какие нибудь инструменты с поддержкой отката?
Я насколько понял, этот инструмент покрывает кейс использования бд в нескольких сервисах. В целом вроде бы интересно.
Очень сложно добиться нужного результата. Да какой то результат будет, но почти наверняка не, то что вы хотели. Постоянно пробую разные чаты, есть подписка openai. Удачных кейсов по разработке у себя могу по пальцам пересчитать. Чаще быстрее самому написать
Вы просто подменяете тезисы. Я не писал про невероятные усилия.
Попробовал на java https://github.com/pkokoshnikov/habr_803273
single thread executor работает медленее чем обычный synchronized в 2 раза. Хоть на долгих, хоть на быстрых операциях. SpinLock работает так же как и ReentrantLock или synchronized. Поэтому для java ваши выводы не применимы
"То есть можно "говнокодить" на уровне приложения и не следить за его производительностью? Не согласен совсем. И я привел пример почему, на основе опыта Paypal."
Опыт paypal ничего нам не говорит о java и nodejs, так как мы не знаем что они там и как переписали и какого уровня по и разработчики были на java и на nodejs. На любом языке можно написать плохо.
Что касается асинхронного и синхронного подхода, то средства нужно выбирать под задачу. Если у вас есть nfr с большой нагрузкой то возможно нужно будет использовать асинхронный код. Если же у вас их нет, то асинхронный код - обычный оверинжиниринг, который ни к чему кроме увелечения стоимости разработки и поддержки не ведёт. И да в реальных тестах r2dbc не всегда может показать результаты лучше, так как упретесь вы скорее всего раньше в базу.
Подход ваш понятен, попробую на java потестить и сравнить