по-моему все это из-за того, что нужно сделать как 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 (с дебезиум) " это решение что называется "для бедных". второй раз за месяц замечаю что авторы тут словно в танке сидят
и все равно вы какой-то велосипед сделали, давным давно есть clip от openai - давно есть консольная утилита rclip для поиска фото по тексту или картинке в качестве примера для поиска, работает это все очень быстро даже на cpu потому что модели не нужно напрягаться и выдавливать из себя текст, она сразу картинку превращает в вектор, и дает вам возможность текст превращать в вектор из такого же пространства. Это называется мультимодальность.
сколько лет этой модели? года 3 наверно. Зачем такое брать? clip правда еще старше, но она работает, она маленькая и она решает более простую задачу
С выбором векторной базы вопрос не стоял - разумеется, PostgreSQL с расширением pgvector. Не потому, что постгри весь такой крутой и сильный, а потому что дополнительных приключений на свой филей не хотелось. Раз финтех на нём работает, то и я как-нибудь разберусь.
разумеется? какой финтех на этом работает? я сам не ковырял это все, но по отзывам pgvector это решение чисто "на поиграть", под серьезные вещи ее никто не дизайнил. Может для ваших 20 тысяч фото пойдет, в rlicp вообще sqlite и тоже работает, но если для вашего приложения не нужен постгрес то тогда зачем?
вы опять про веру и то, что вам должны что-то доказать и показать, я ж сказал, есть тесты, их демонстрировали на одной из java конф в контексте ускорения старта приложения, мол почему лучше все же немного подождать и дать vm собрать статистику по выполнению кода, 20 тысяч дефолтных итераций. был пример когда через vm опции вместо 20 тысяч ставили меньше и бенчмарки сразу заметно проседали. Вы сейчас пытаетесь оспорить основы
а любой язык без gc умножает затраты на 2 и во столько же риск инсульта у разработчиков ;) я с .net не знаком и на сколько знаю vm у него сильно проще чем у java (и это еще надо учесть что в java 2 vm с разными компиляторами, та что graalvm бывает и в 2 раза ускоряет программы просто за счет более умного-нового jit). разница не только в том что vm знает железо но и еще знает данные над которыми работает алгоритм (это часто даже важнее), разница легко вычисляется и в java и нативных языках, в java вы можете скомандовать компилировать код без учета профиля выполнения - не ждать 20 тысяч вызовов и компилировать раньше, сразу, примерно так как это делает ваш c++ компилятор и разница по горячим методам там будет в разы если не 10 раз для некоторых участков. И нативные языки на сколько знаю имеют режим сборки профиля на тестовых данных-прогонах и учет их при финальном билде, вроде это может дать 30% (если не путаю ff так билдят и там профиль дает такой прирост). Так что тут не то что вам должен кто-то подтвердить, а вы сами должны взять и посмотреть.
в этом и есть смысл java - пишешь 1 раз а оно дальше оптимально выполняется на конкретном железе где вы запускаете. точно так же сейчас активно в нее внедряют gpu вычисления чтоб не слишком сильно переживать что у вас там за железка будет стоять в серверной. ваша позиция и ей подобные в чем-то забавные, они звучат примерно так: java это отстой, потому что там vm тянется, нужно время на ее старт + еще память для нее, не то что наши компактные быстрые нативные программы, а когда эта vm генерирует целевой оптимизированный код потому что она знает на чем запущена и еще реальный профиль выполнения на конкретных данных то это не, это уже жульничество ;)
ну какое значительное? если у вас такая программа из трех классов то то на современном железе это несколько сот миллисекунд (я про java говорю, про .net не знаю ничего). медленный старт больших серверов связан с активным сканирование классов, поиском метаданных и динамической кодогенерацией, а если у вас простая консольная программа то тут более-менее быстро. ну и нужно подождать 20к вызовов метода для сбора статистики чтоб эффективно и агрессивно его скомпилировать
лично я не хочу собеситься потому, что у меня нет время и интереса вспоминать алгоритмы + зп там по слухам не выше рынка. т.е. это "гемор без вознаграждения". учитывая специфику компании там нужны люди с принципиально разными навыками и знаниями: условные "олимпиадники" но и так же люди которые сделают чтобы было потом не стыдно и все работало, как я понимаю компания хочет чтобы это тоже были "олимпиадники", которые вдруг решили заниматься обычными техническими и инженерными задачами, а таких не много. В принципе не имею ничего против занудного и затянутого процесса найма - ваше дело кого брать и в принципе я даже согласен что в бигтех нужно брать лучших, а это значит что вы обидете большинство, но если вы не готовы платить зп сильно выше рынка, то тогда на кого вы рассчитываете? на инфантилов-задротов с мехмата? так это не масштабируется. как вариант тогда ищете контракторов, apple и google активно ими пользуется
странное у вас понимание async это не про утилизацию СХД - это про утилизацию CPU когда наоборот, СХД отвечает долго и ваш поток (и ядро в какой-то мере) заблокирован без дела, хотя мог бы делать что-то полезное. Так что все наоборот ;) и это кстати отдельная проблема как делать IO в случаи быстрых СХД, которые работают со скоростью RAM например, ведь для чтения и записи в память нет никаких прерываний и асинхронных чтений. А зачем делают async к быстрым СХД - так потому что они условно быстрые, они быстрые за счет широкой шины а не низкой латенси - там через async одним потоком можно сформировать огромный план работ для СХД и он ее переварит за счет своего внутреннего параллелизма. А обычным образом вам для этого нужно было бы потоков раз 30 больше создать. А async для постгреса нужен для облачных сред, где диски могут подтупливать, я в описании фичи видел именно такую мотивацию.
ЗЫ: я не прям эксперт в теме, так интересовался со стороны java разработки
ужос, вы не знаете о существовании ${rabbitmq.queue.name} ?? Открыл 5 статей где учат rabbitmq со спрингом и везде какой-то полумрак. переобъявление стандартных бинов, пропертей из докер компос файла и т.д. Хорошо что сразу полез в доки + нейронка, а эти вкладки просто остались висеть. Ну и сам способ тестировать что-то через http ендоинты это костыль, вам же спринг тесь все это дает и запускать удобней.
а сделать связный список без 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 (с дебезиум) " это решение что называется "для бедных". второй раз за месяц замечаю что авторы тут словно в танке сидят
а для этого точно нужна llm? вроде как словарь-регулярка или простейший nlp подойдет
и все равно вы какой-то велосипед сделали, давным давно есть clip от openai - давно есть консольная утилита rclip для поиска фото по тексту или картинке в качестве примера для поиска, работает это все очень быстро даже на cpu потому что модели не нужно напрягаться и выдавливать из себя текст, она сразу картинку превращает в вектор, и дает вам возможность текст превращать в вектор из такого же пространства. Это называется мультимодальность.
сколько лет этой модели? года 3 наверно. Зачем такое брать? clip правда еще старше, но она работает, она маленькая и она решает более простую задачу
разумеется? какой финтех на этом работает? я сам не ковырял это все, но по отзывам pgvector это решение чисто "на поиграть", под серьезные вещи ее никто не дизайнил. Может для ваших 20 тысяч фото пойдет, в rlicp вообще sqlite и тоже работает, но если для вашего приложения не нужен постгрес то тогда зачем?
если спрашиваете то значит вам это не надо ;)
вы опять про веру и то, что вам должны что-то доказать и показать, я ж сказал, есть тесты, их демонстрировали на одной из java конф в контексте ускорения старта приложения, мол почему лучше все же немного подождать и дать vm собрать статистику по выполнению кода, 20 тысяч дефолтных итераций. был пример когда через vm опции вместо 20 тысяч ставили меньше и бенчмарки сразу заметно проседали. Вы сейчас пытаетесь оспорить основы
а любой язык без gc умножает затраты на 2 и во столько же риск инсульта у разработчиков ;) я с .net не знаком и на сколько знаю vm у него сильно проще чем у java (и это еще надо учесть что в java 2 vm с разными компиляторами, та что graalvm бывает и в 2 раза ускоряет программы просто за счет более умного-нового jit). разница не только в том что vm знает железо но и еще знает данные над которыми работает алгоритм (это часто даже важнее), разница легко вычисляется и в java и нативных языках, в java вы можете скомандовать компилировать код без учета профиля выполнения - не ждать 20 тысяч вызовов и компилировать раньше, сразу, примерно так как это делает ваш c++ компилятор и разница по горячим методам там будет в разы если не 10 раз для некоторых участков. И нативные языки на сколько знаю имеют режим сборки профиля на тестовых данных-прогонах и учет их при финальном билде, вроде это может дать 30% (если не путаю ff так билдят и там профиль дает такой прирост). Так что тут не то что вам должен кто-то подтвердить, а вы сами должны взять и посмотреть.
в этом и есть смысл java - пишешь 1 раз а оно дальше оптимально выполняется на конкретном железе где вы запускаете. точно так же сейчас активно в нее внедряют gpu вычисления чтоб не слишком сильно переживать что у вас там за железка будет стоять в серверной. ваша позиция и ей подобные в чем-то забавные, они звучат примерно так: java это отстой, потому что там vm тянется, нужно время на ее старт + еще память для нее, не то что наши компактные быстрые нативные программы, а когда эта vm генерирует целевой оптимизированный код потому что она знает на чем запущена и еще реальный профиль выполнения на конкретных данных то это не, это уже жульничество ;)
ну какое значительное? если у вас такая программа из трех классов то то на современном железе это несколько сот миллисекунд (я про java говорю, про .net не знаю ничего). медленный старт больших серверов связан с активным сканирование классов, поиском метаданных и динамической кодогенерацией, а если у вас простая консольная программа то тут более-менее быстро. ну и нужно подождать 20к вызовов метода для сбора статистики чтоб эффективно и агрессивно его скомпилировать
лично я не хочу собеситься потому, что у меня нет время и интереса вспоминать алгоритмы + зп там по слухам не выше рынка. т.е. это "гемор без вознаграждения". учитывая специфику компании там нужны люди с принципиально разными навыками и знаниями: условные "олимпиадники" но и так же люди которые сделают чтобы было потом не стыдно и все работало, как я понимаю компания хочет чтобы это тоже были "олимпиадники", которые вдруг решили заниматься обычными техническими и инженерными задачами, а таких не много. В принципе не имею ничего против занудного и затянутого процесса найма - ваше дело кого брать и в принципе я даже согласен что в бигтех нужно брать лучших, а это значит что вы обидете большинство, но если вы не готовы платить зп сильно выше рынка, то тогда на кого вы рассчитываете? на инфантилов-задротов с мехмата? так это не масштабируется. как вариант тогда ищете контракторов, apple и google активно ими пользуется
странное у вас понимание async это не про утилизацию СХД - это про утилизацию CPU когда наоборот, СХД отвечает долго и ваш поток (и ядро в какой-то мере) заблокирован без дела, хотя мог бы делать что-то полезное. Так что все наоборот ;) и это кстати отдельная проблема как делать IO в случаи быстрых СХД, которые работают со скоростью RAM например, ведь для чтения и записи в память нет никаких прерываний и асинхронных чтений. А зачем делают async к быстрым СХД - так потому что они условно быстрые, они быстрые за счет широкой шины а не низкой латенси - там через async одним потоком можно сформировать огромный план работ для СХД и он ее переварит за счет своего внутреннего параллелизма. А обычным образом вам для этого нужно было бы потоков раз 30 больше создать. А async для постгреса нужен для облачных сред, где диски могут подтупливать, я в описании фичи видел именно такую мотивацию.
ЗЫ: я не прям эксперт в теме, так интересовался со стороны java разработки
ужос, вы не знаете о существовании ${
rabbitmq.queue.name} ?? Открыл 5 статей где учат rabbitmq со спрингом и везде какой-то полумрак. переобъявление стандартных бинов, пропертей из докер компос файла и т.д. Хорошо что сразу полез в доки + нейронка, а эти вкладки просто остались висеть. Ну и сам способ тестировать что-то через http ендоинты это костыль, вам же спринг тесь все это дает и запускать удобней.