Никакой конкретики, хоть бы одну проблему разобрали детально.
Много воды. Однословные предложения, как у видео для сна с YouTube
По смыслу статьи.
ИИ и hibernate хорошо знает и все подводные камни в нём. Вряд ли тут есть большая разница.
Hibernate позволяет достаточно просто работать с вложенными доменными моделями. Сам следить что было изменено внутри модели и сохраняет только изменнные объекты. Можно больше сосредоточится на написании бизнес логики. В противном случае придётся писать достаточно трудоёмкий код по отслеживанию изменений или просто написать кучу мелких скриптов склеенных в сервисном слое. Читать и разбирать это потом та ещё забава.
Если модель простая и плоская в hibernate конечно смысла особо нет, пихать его в любой проект не стоит.
У нас multi-DC кластер, приложения тоже развернуты в двух ДЦ, и в каждом настроен свой local_dc. И чтение, и запись идут с LOCAL_QUORUM, чтобы не тянуть междцшную latency в каждый запрос. Для наших требований по консистентности этого достаточно.
Данный кластер работает на Cassandra версии 4.1.8. Кластер развернут в двух собственных дата-центрах, по 9 нод в каждом с RF=3. Конфигурация ноды 8 CPU 32 GB RAM. Cassandra доступна у нас как внутренний сервис и управляется выделенной командой.
Ну просто мало кто самостоятельно может описать свои +-. Это скорее исключение. + качества человека меняются со временем. нужно постоянно переоценку делать. я бы брал например информацию за месяц - пол года, которую удалось насобирать, и прогонял например раз в месяц через модель, чтобы выявить профиль поведения
Ну жиденько, можно например танскрибировать видео с митингов и прогонять по ночам на них модель выделяя какие то особенности, или переписки в мессенджерах неплохое место для сбора данных о характере, темпераменте, настойчивости ну и т.д
Я бы ещё задачи вёл в условной jira там можно больше контекста собрать для агента. Опять же есть всякие дедлайны.
Не понял зачем в одной таблице смешивать разные типы сущностей. Гораздо проще разделить. Может появится потребность расширить одну из них позже, но тут уже архитектурно заложено ограничение.
Откуда вы берёте факты о предпочтениях? Самый неочевидный момент
Так я в начале спросил какой объём данных в редис? И насколько я понял у вас не хранится в редис большая часть данных так как и их достаточно много, поэтому при падении редиса придётся перечитать данные полностью из кафка, но не факт что там будут хранится все данные.
Меня этот диалог тоже натолкнул на одну мысль как из схемы с постгрес сделать ещё более оптимальную схему которая обойдёт проблему с хот ключами. Скину чуть позже нужно время проверить.
Для меня просто защита от сбоев и восстановление имеют высокий приоритет и я не могу ими пренебречь. Не знаю задач где можно спокойно пол дня не работать, причём закладывать это в архитектуру.
Ну у вас же есть политика ретрая, через сколько вы хотите запустить обработку, задаёте поле execute_after которое как раз и решает эту проблему, при запросе фильтруете по нему. Это не проблема. Можете обрабатывать в транзакции не все ключи, а по одному это решит проблему транзакций. В этом кейсе даже лучше подходит.
Проблема autovacuum не так критична, я уже привёл что можно разделить таблицу самой очереди где по партициям можно хранить сами сообщения и на таблицу статусов сообщений, тогда vacuum будет не такой большой. А очередь будет очищаться дропом партиций.
Постгрес - не очередь и не сможет стабильно держать высокую пропускную способность для таких задач.
Делаем таблицу очереди. У каждого сообщения есть ключ, который задаёт логическую партицию.
Открываем транзакцию
Сначала через FOR UPDATE SKIP LOCKED выбираем кандидатов на обработку из таблицы очереди. После этого пытаемся взять pg_try_advisory_xact_lock для 1 ключа.
Этим мы обеспечиваем эксклюзивность обработки данного ключа. Далее отдельным запросом выбираем сообщения этого ключа для обработки.
После успешной обработки удаляем сообщения из очереди и коммитим транзакцию.
Тут можно довольно многое оптимизировать например разделить на 2 таблицы саму очередь и потребление, либо заменить pg_try_advisory_xact_lock на таблицу уникальных ключей которые лочатся вместе с выборкой.
Для меня просто ваш подход кажется опасным, сбой может быть очень болезненным
По поводу скорости работы, оно конечно понятно, только непонятно откуда такие требования? Вам уже отгрузили запросы через кафка, вы уже потеряли в latency, на приёме и отправке обратно. Как тут такой подход может быть связан с требованиями low latency? А если latency не важно, то в чём смысл тогда делать это на redis?
А что с консистентностью вашей очереди? Или можно и не выполнять запрос если редис приложет? А если в режиме консистентности то какой объём данных и сколько будет подниматься в случае сбоя? Зачем вообще скорость ретрая если задача асинхронная? Вопросов очень много
Раньше писали более верхнеуровневую спецификацию, которая оставляла разработчику достаточно много свободы для реализации. Ну например раньше точно не было границ транзакций или описания агрегатов. Теперь часть спецификации пишет разработчик. Так как не каждый аналитик тянет эти детали пока что. В целом конечно граница между аналитиком и разработчиком размывается. А ну и может быть забыл упомянуть вся специкация лежит в том же репозитории и публикуется на doc-as-code платформе. Достаточно удобно получается.
Да на что вы столько тратите? Пользую codex за 20$ и мне хватает. Да периодически в лимиты утыкаюсь, но использую это время как раз чтобы подумать, что нагенерила модель и пишу замечания и будущий рефакторинг. Опять же часть приходится делать самому в любом случае, так как не все задачи хорошо вайбкодятся.
Такое ощущение что прочитал ии текст.
Никакой конкретики, хоть бы одну проблему разобрали детально.
Много воды. Однословные предложения, как у видео для сна с YouTube
По смыслу статьи.
ИИ и hibernate хорошо знает и все подводные камни в нём. Вряд ли тут есть большая разница.
Hibernate позволяет достаточно просто работать с вложенными доменными моделями. Сам следить что было изменено внутри модели и сохраняет только изменнные объекты. Можно больше сосредоточится на написании бизнес логики. В противном случае придётся писать достаточно трудоёмкий код по отслеживанию изменений или просто написать кучу мелких скриптов склеенных в сервисном слое. Читать и разбирать это потом та ещё забава.
Если модель простая и плоская в hibernate конечно смысла особо нет, пихать его в любой проект не стоит.
У нас multi-DC кластер, приложения тоже развернуты в двух ДЦ, и в каждом настроен свой
local_dc. И чтение, и запись идут сLOCAL_QUORUM, чтобы не тянуть междцшную latency в каждый запрос. Для наших требований по консистентности этого достаточно.Данный кластер работает на Cassandra версии 4.1.8. Кластер развернут в двух собственных дата-центрах, по 9 нод в каждом с RF=3. Конфигурация ноды 8 CPU 32 GB RAM. Cassandra доступна у нас как внутренний сервис и управляется выделенной командой.
А зачем? Есть какие-то серьёзные приемущества по сравнению с java?
Асинхронный код это дополнительная сложность, порог входа и всё остальное. Зачем её нести в проект если можно писать проще?
Ну просто мало кто самостоятельно может описать свои +-. Это скорее исключение. + качества человека меняются со временем. нужно постоянно переоценку делать.
я бы брал например информацию за месяц - пол года, которую удалось насобирать, и прогонял например раз в месяц через модель, чтобы выявить профиль поведения
Ну жиденько, можно например танскрибировать видео с митингов и прогонять по ночам на них модель выделяя какие то особенности, или переписки в мессенджерах неплохое место для сбора данных о характере, темпераменте, настойчивости ну и т.д
В целом то достаточно очевидное решение.
Я бы ещё задачи вёл в условной jira там можно больше контекста собрать для агента. Опять же есть всякие дедлайны.
Не понял зачем в одной таблице смешивать разные типы сущностей. Гораздо проще разделить. Может появится потребность расширить одну из них позже, но тут уже архитектурно заложено ограничение.
Откуда вы берёте факты о предпочтениях? Самый неочевидный момент
Так я в начале спросил какой объём данных в редис? И насколько я понял у вас не хранится в редис большая часть данных так как и их достаточно много, поэтому при падении редиса придётся перечитать данные полностью из кафка, но не факт что там будут хранится все данные.
Меня этот диалог тоже натолкнул на одну мысль как из схемы с постгрес сделать ещё более оптимальную схему которая обойдёт проблему с хот ключами. Скину чуть позже нужно время проверить.
Ну сделайте execute after на ключ. Он же не обязательно должен быть привязан к сообщению.
Идею с двумя таблицами можете глянуть тут https://github.com/pkokoshnikov/dbq
Для меня просто защита от сбоев и восстановление имеют высокий приоритет и я не могу ими пренебречь. Не знаю задач где можно спокойно пол дня не работать, причём закладывать это в архитектуру.
Ну у вас же есть политика ретрая, через сколько вы хотите запустить обработку, задаёте поле execute_after которое как раз и решает эту проблему, при запросе фильтруете по нему. Это не проблема. Можете обрабатывать в транзакции не все ключи, а по одному это решит проблему транзакций. В этом кейсе даже лучше подходит.
Проблема autovacuum не так критична, я уже привёл что можно разделить таблицу самой очереди где по партициям можно хранить сами сообщения и на таблицу статусов сообщений, тогда vacuum будет не такой большой. А очередь будет очищаться дропом партиций.
Тут голословно.
Ещё один странный момент, вам так важен порядок обработки, но вы можете потерять часть сообщений, тоже странно выглядит.
Есть достаточно не сложное решение
Делаем таблицу очереди. У каждого сообщения есть ключ, который задаёт логическую партицию.
Открываем транзакцию
Сначала через FOR UPDATE SKIP LOCKED выбираем кандидатов на обработку из таблицы очереди. После этого пытаемся взять pg_try_advisory_xact_lock для 1 ключа.
Этим мы обеспечиваем эксклюзивность обработки данного ключа. Далее отдельным запросом выбираем сообщения этого ключа для обработки.
После успешной обработки удаляем сообщения из очереди и коммитим транзакцию.
Тут можно довольно многое оптимизировать например разделить на 2 таблицы саму очередь и потребление, либо заменить pg_try_advisory_xact_lock на таблицу уникальных ключей которые лочатся вместе с выборкой.
Для меня просто ваш подход кажется опасным, сбой может быть очень болезненным
По поводу скорости работы, оно конечно понятно, только непонятно откуда такие требования? Вам уже отгрузили запросы через кафка, вы уже потеряли в latency, на приёме и отправке обратно. Как тут такой подход может быть связан с требованиями low latency? А если latency не важно, то в чём смысл тогда делать это на redis?
Ну ладно главный вопрос, почему не взяли postgres? 2500 rps не выглядит слишком большой нагрузкой. В придачу бы получили персистентность и надёжность.
Асинхронный контракт обычно делают когда результат нужен не обязательно сразу. Иначе зачем вообщем вам асинхронный контракт?
А что с консистентностью вашей очереди? Или можно и не выполнять запрос если редис приложет? А если в режиме консистентности то какой объём данных и сколько будет подниматься в случае сбоя? Зачем вообще скорость ретрая если задача асинхронная? Вопросов очень много
Раньше писали более верхнеуровневую спецификацию, которая оставляла разработчику достаточно много свободы для реализации. Ну например раньше точно не было границ транзакций или описания агрегатов. Теперь часть спецификации пишет разработчик. Так как не каждый аналитик тянет эти детали пока что. В целом конечно граница между аналитиком и разработчиком размывается. А ну и может быть забыл упомянуть вся специкация лежит в том же репозитории и публикуется на doc-as-code платформе. Достаточно удобно получается.
Так мой комментарий и относится к физику, он жалуется что у него половина дохода на нейронки уходит.
.
Да на что вы столько тратите? Пользую codex за 20$ и мне хватает. Да периодически в лимиты утыкаюсь, но использую это время как раз чтобы подумать, что нагенерила модель и пишу замечания и будущий рефакторинг. Опять же часть приходится делать самому в любом случае, так как не все задачи хорошо вайбкодятся.
Ну да с кем не бывало. Ну поэтому и нужно описывать кейсы применимости как мне кажется, чтобы из пушки по воробьям не стреляли