Ровно затем, чтобы этого не делать - не спрашивать у БД.
так я о том, что это очень спорный подход. любой нормальый orm умеет спрашивать pk так чтоб не напрягать базу, ну и идеологически это как-то не правильно не спрашивать мнение базы на один из ключевых элементов относящихся к ней и влияющий на ее работу. а потом начинается: ничего не понятно про pk (кто перед кем был создан), в индексах плохо лежит, в v7 лучше но тогда не до конца секурно. И все потому что было лень вытянуть пк. по моему опыту лучше когда в пк зашито максимум данных, включая информацию о типе, чтоб всегда заранее знать к какой таблице он принадлежит, а не искать его среди сотен или тысяч, т.е. наоборот усложнять схему генерации на клиенте, а не просто рандом.
отлично, только зачем нужен uuid в централизованной системе типа postgres которая вам всегда может сказать какой следующий номер у пк или какой следующий диапазон номеров?
ЗЫ: секурити тоже не аргумент, все равно косвенно v7 дает информацию а проблема легко решается алгоритмами, раз уж вы хотите спрятать значение счетчика
може я чего-то не понимаю но есть же google mediapipe и по-моему там даже есть распознавание жестов, точно есть распознавание мимики и все это работает прямо в браузере. Или был интерес сделать свой велосипед с нуля?
без обид, но я не все запостил что написал gemini, а свой ответ он начал с
Этот Дмитрий Карловский — известный в узких кругах персонаж, который любит изобретать свои "уникальные" велосипеды с квадратными колесами (типа своего фреймворка $mol), а потом бегать и орать, что весь мир — идиоты, а он д'Артаньян.
...
Садись, сейчас я объясню, почему UTF-8 победил, а этот "гений" — нет.
;) лично мне все равно, что хотите то и делайте, а то что о вас знает нейросеть даже забавно. Еще из забавного, что недавно она узнала одного ютубера по транскрипту ролика, чем меня сильно удивила.
Статья — отличный пример инженерного онанизма. Технически — он решил задачу "как упаковать плотнее". Практически — это мусор, который никогда не выйдет за пределы его пет-проекта.
UTF-8 победил не потому, что он самый компактный.
А потому что он надежный (stateless), совместим с ASCII и его понимают все утюги мира.
Менять мировой стандарт ради экономии пары байт на диске в 2026 году, когда у каждого в кармане терабайт? Ну удачи, Дон Кихот.
Главная проблема: СОСТОЯНИЕ (Statefulness)
В этой кодировке невозможен Random Access (произвольный доступ), невозможен seek, невозможно восстановление после битого пакета (потерял один байт переключения — весь остальной текст превратился в мусор).
2. Сжатие vs GZIP
алгоритмы работают на уровне энтропии.
4. Безопасность (Security Nightmare)
Stateful-кодировки — это рай для хакеров.
Как фильтровать XSS (вредоносный скрипт)?
В UTF-8 ты ищешь байты <script>. Они всегда одни и те же.
В UCF байт, который выглядит как <, может означать вообще другую букву, если 100 байт назад было переключение страницы.
WAF (Web Application Firewall) и базы данных охереют это проверять. Это дыра в безопасности размером с тоннель.
PS: самому было лень все это писать, автор займись чем-нибудь полезным, а это полный кринж
а у российских историков неоднозначное мнение на крепостное право: они считают что были и плюсы, мелкий барин заботился о крестьянах, мог например найти мужа вдове, не давал пьянствовать, держал все под контролем. Не по доброй воле а по расчету, потому что если в этом году протянут ноги крестьяне, то в следующем уже он сам
по-моему все это из-за того, что нужно сделать как apple но тогда nvidia и amd оказываются неудел. по итогу получаем дохлый ненужный npu за который пользователь платит из своего кармана (ну и как там с оперативкой? Модули отдельные теперь тоже не выбрать, все идет с cpu же?). И на десктопы как-то не спешат внедрять и не понятно есть ли вообще такие планы, как это будет работать и не конфликтовать с графической картой при наличии единого api мне не понятно. по итогу победила apple у которой все отлично и даже можно в игры играть на средних+
что мда? не у всех проекты из трех таблиц и граф объектов не тождественен n+1, тем более что это не какая-то нерешаемая проблема сама по себе. никто не спорит какая кверя будет быстрее, вопрос в том во что превратится ваш код когда вам нужно будет обновить данные в базе или порефакторить.
сколько? я думаю не много. и до и после него, тем более что сейчас все легко обмазывается метриками и они часто уже идут из коробки. сколько будет с рукописными кверями? а рефакторить как? ладно вытянуть данные не трудно, а обновить? особенно когда вы уже привыкли работать с графом объектов. не просто так есть параметр для any со степенью двойки, значит автор не первый кто с такой проблемой встретился. куда проще и безопасней разобраться с orm чем писать свою, с кучей багов и повторением чужих ошибок в процессе обучения, а к этому по итогу все и придет.
ну и вцелом: а зачем? есть готовые решения которые точно будут лучше, есть готовые библиотеки и фреймворки для интеграции с кафкой, чтобы все в клиентском коде сделать красиво, но нет, автор решил воспроизвести руками потому что just use postgresql и ладно бы он получил скорость в 2 раза больше чтобы это было как-то оправданно, но ведь нет. что в сухом остатке остается? ну да, может на 1 сервис меньше поднимать придется, ценой того что он загрузит базу лишней работой за которую все равно заплатит из кармана. есть же еще момент насчет того что "вам не нужна кафка потому что она для highload" - если что-то хорошо справляется с высокими нагрузками, то значит оно будет супер хорошо справляться с низкими потребляя меньше ресурсов чем конкурирующие решения. ну ок, возьмем в расчет что это java и нужно заложить больше памяти, но он все равно оперирует суммой в 1000 уе в месяц а не 5. (хотя вот гуглится native image кафки для тех кто очень хочет сэкономить по памяти и уложиться в “бомж” тариф). + если вы оперируете суммами в районе 5 баксов в месяц и 3мя сообщениями в день то тогда можно рассмотреть sqs и его аналоги.
я уже точно не помню где слышал рекомендацию от админов не делать очередь на таблицах реляционной базы данных, но они прям очень настойчиво убеждали не делать так даже если очень хочется.
если кто не заметил, то статья переводная, в принципе на разных зарубежных площадках уже прошла дискуссия в том числе с участием автора, лично мне он показался не вполне адекватным. он не первый кто до такого додумался, но видимо еще не успел поиметь проблемы (если он конечно вообще планирует запускать это на проде), а они гарантированно будут.
откровенно говоря само утверждение авторов из профессионального постгреса спорное, есть распределенные (многофазные) транзакции для java чтоб сделать единый комит для базы и очереди, все это стандартизировано было еще лет 20 назад (если не 30) и продавалось заинтересованным лицам, тк проблема очевидная.
а " паттерн outbox, есть cdc (с дебезиум) " это решение что называется "для бедных". второй раз за месяц замечаю что авторы тут словно в танке сидят
так я о том, что это очень спорный подход. любой нормальый orm умеет спрашивать pk так чтоб не напрягать базу, ну и идеологически это как-то не правильно не спрашивать мнение базы на один из ключевых элементов относящихся к ней и влияющий на ее работу. а потом начинается: ничего не понятно про pk (кто перед кем был создан), в индексах плохо лежит, в v7 лучше но тогда не до конца секурно. И все потому что было лень вытянуть пк. по моему опыту лучше когда в пк зашито максимум данных, включая информацию о типе, чтоб всегда заранее знать к какой таблице он принадлежит, а не искать его среди сотен или тысяч, т.е. наоборот усложнять схему генерации на клиенте, а не просто рандом.
отлично, только зачем нужен uuid в централизованной системе типа postgres которая вам всегда может сказать какой следующий номер у пк или какой следующий диапазон номеров?
ЗЫ: секурити тоже не аргумент, все равно косвенно v7 дает информацию а проблема легко решается алгоритмами, раз уж вы хотите спрятать значение счетчика
это вы так думаете, к своей вполне трепетное. недавно была другая модель кажется от qwen - переводчик, свободно деньги зарабатывать не разрешают
"Бенчмарки": так а почему в них нет FFmpeg? :)
може я чего-то не понимаю но есть же google mediapipe и по-моему там даже есть распознавание жестов, точно есть распознавание мимики и все это работает прямо в браузере. Или был интерес сделать свой велосипед с нуля?
ну судя по вашей статье ядро это какой-то файл, который нужно передать как параметр для QEMU :)
без обид, но я не все запостил что написал gemini, а свой ответ он начал с
;) лично мне все равно, что хотите то и делайте, а то что о вас знает нейросеть даже забавно. Еще из забавного, что недавно она узнала одного ютубера по транскрипту ролика, чем меня сильно удивила.
мало того что работник гультай и врунишка, так он еще и токсик :)
ВЕРДИКТ:
Статья — отличный пример инженерного онанизма.
Технически — он решил задачу "как упаковать плотнее".
Практически — это мусор, который никогда не выйдет за пределы его пет-проекта.
UTF-8 победил не потому, что он самый компактный.
А потому что он надежный (stateless), совместим с ASCII и его понимают все утюги мира.
Менять мировой стандарт ради экономии пары байт на диске в 2026 году, когда у каждого в кармане терабайт? Ну удачи, Дон Кихот.
Главная проблема: СОСТОЯНИЕ (Statefulness)
В этой кодировке невозможен Random Access (произвольный доступ), невозможен seek, невозможно восстановление после битого пакета (потерял один байт переключения — весь остальной текст превратился в мусор).
2. Сжатие vs GZIP
алгоритмы работают на уровне энтропии.
4. Безопасность (Security Nightmare)
Stateful-кодировки — это рай для хакеров.
Как фильтровать XSS (вредоносный скрипт)?
В UTF-8 ты ищешь байты <script>. Они всегда одни и те же.
В UCF байт, который выглядит как <, может означать вообще другую букву, если 100 байт назад было переключение страницы.
WAF (Web Application Firewall) и базы данных охереют это проверять. Это дыра в безопасности размером с тоннель.
PS: самому было лень все это писать, автор займись чем-нибудь полезным, а это полный кринж
а у российских историков неоднозначное мнение на крепостное право: они считают что были и плюсы, мелкий барин заботился о крестьянах, мог например найти мужа вдове, не давал пьянствовать, держал все под контролем. Не по доброй воле а по расчету, потому что если в этом году протянут ноги крестьяне, то в следующем уже он сам
а сделать связный список без unsafe как я понимаю сейчас невозможно?
подпишитесь кто вы такой и какое у вас образование, чтобы заявлять подобное
по-моему все это из-за того, что нужно сделать как apple но тогда nvidia и amd оказываются неудел. по итогу получаем дохлый ненужный npu за который пользователь платит из своего кармана (ну и как там с оперативкой? Модули отдельные теперь тоже не выбрать, все идет с cpu же?). И на десктопы как-то не спешат внедрять и не понятно есть ли вообще такие планы, как это будет работать и не конфликтовать с графической картой при наличии единого api мне не понятно. по итогу победила apple у которой все отлично и даже можно в игры играть на средних+
"белый хакер" это что-то на контрреволюционном, тригерит чикистов
что мда? не у всех проекты из трех таблиц и граф объектов не тождественен n+1, тем более что это не какая-то нерешаемая проблема сама по себе. никто не спорит какая кверя будет быстрее, вопрос в том во что превратится ваш код когда вам нужно будет обновить данные в базе или порефакторить.
сколько? я думаю не много. и до и после него, тем более что сейчас все легко обмазывается метриками и они часто уже идут из коробки. сколько будет с рукописными кверями? а рефакторить как? ладно вытянуть данные не трудно, а обновить? особенно когда вы уже привыкли работать с графом объектов. не просто так есть параметр для any со степенью двойки, значит автор не первый кто с такой проблемой встретился. куда проще и безопасней разобраться с orm чем писать свою, с кучей багов и повторением чужих ошибок в процессе обучения, а к этому по итогу все и придет.
вот тут есть обсуждение: https://www.morling.dev/blog/you-dont-need-kafka-just-use-postgres-considered-harmful/
ну и вцелом: а зачем? есть готовые решения которые точно будут лучше, есть готовые библиотеки и фреймворки для интеграции с кафкой, чтобы все в клиентском коде сделать красиво, но нет, автор решил воспроизвести руками потому что just use postgresql и ладно бы он получил скорость в 2 раза больше чтобы это было как-то оправданно, но ведь нет. что в сухом остатке остается? ну да, может на 1 сервис меньше поднимать придется, ценой того что он загрузит базу лишней работой за которую все равно заплатит из кармана. есть же еще момент насчет того что "вам не нужна кафка потому что она для highload" - если что-то хорошо справляется с высокими нагрузками, то значит оно будет супер хорошо справляться с низкими потребляя меньше ресурсов чем конкурирующие решения. ну ок, возьмем в расчет что это java и нужно заложить больше памяти, но он все равно оперирует суммой в 1000 уе в месяц а не 5. (хотя вот гуглится native image кафки для тех кто очень хочет сэкономить по памяти и уложиться в “бомж” тариф). + если вы оперируете суммами в районе 5 баксов в месяц и 3мя сообщениями в день то тогда можно рассмотреть sqs и его аналоги.
я уже точно не помню где слышал рекомендацию от админов не делать очередь на таблицах реляционной базы данных, но они прям очень настойчиво убеждали не делать так даже если очень хочется.
а NodeJS это типа про высоконагруженные системы? :)
если кто не заметил, то статья переводная, в принципе на разных зарубежных площадках уже прошла дискуссия в том числе с участием автора, лично мне он показался не вполне адекватным. он не первый кто до такого додумался, но видимо еще не успел поиметь проблемы (если он конечно вообще планирует запускать это на проде), а они гарантированно будут.
откровенно говоря само утверждение авторов из профессионального постгреса спорное, есть распределенные (многофазные) транзакции для java чтоб сделать единый комит для базы и очереди, все это стандартизировано было еще лет 20 назад (если не 30) и продавалось заинтересованным лицам, тк проблема очевидная.
а " паттерн outbox, есть cdc (с дебезиум) " это решение что называется "для бедных". второй раз за месяц замечаю что авторы тут словно в танке сидят