Добрый день, у jenv есть хорошая альтернатива - SDKman - https://sdkman.io. Он по запросу выкачивает и устанавливает как JDK, так и такие инструменты как maven, gradle. Так же можно в разных каталогах использовать разные JVM.
Если под "монолитом" понимается то, что сервис делает более одной вещи (слушает очередь и предоставляет api) то да, деплоится сервис, который обслуживает часть домена и он единственный знает как с этой частью работать.
И то, что запущено 10 копий этого сервиса, но под чтение очереди используется 0.000001% мощности одной копии, а всё остальное выедает API на мой взгляд ничего страшного.
Можно конечно делить сервис на отдельные операции и деплоить 10 копий "Лента-GET-List", 5 копий "Лента-GET-Message" ,2 копии "Лента-POST-mesage", ... но все эти наносервисы будут зависимыми от единой доменной модели сервиса. В том числе и по деплою.
и каждый сервис будет включать в себя логику того, как именно ему надо распорядиться информацией о сообщении. Поставщик же просто уведомляет всех заинтересованных "появился новый человек". А подписчики уже реагируют по-своему.
По поводу vacuum - есть утилита pg-repack (https://github.com/reorg/pg_repack) которая обслуживает таблицы без долгого глобального лока. Она оттестирована, и лучше использовать её вместо своих велосипедов.
С партиционированием тоже не всё так просто. От версии к версии конечно становится лучше, но партиционированные таблицы имеют ограничения по уникальным констрейнам, которые должны включать ключ партиционирования. А при неправильно выбранном ключе запросы становятся дольше, так как опрашиваются сразу все партиции.
А если не найдёт, то упадёт в рантайме.
Именно поэтому мы у себя используем свои мапперы, которые являются спринговыми бинами и обеспечивают типобезопасность на этапе компиляции. Нет маппера — ошибка компиляции.
Это как раз просто, имея полный ключ посчитать CRC32, прибавить и сделать список Get
А если ключ составной, и известна только часть ключа, то всё становится гораздо более интересно.
Предположим, что ключ имеет вид «customerId|year|month|day|transactionId», от него считается CRC32 и в БД кладётся «hash|customerId|year|month|day|transactionId»
Задача посчитать сумму транзакций клиента за месяц года. Известная часть ключа «customerId|year|month»
Так как ключи подсолены, данные по транзакциям размазаны по кластеру, put и get идут быстро, но… нельзя уже сделать один scan с префиксом ключа «customerId|year|month» чтобы получить данные по всем транзакциям месяца. Тут или делать сканы по всем возможным значениям хеша +частичный ключ или full scan.
А как вы работаете со Scan по частичному ключу в случае «солёных» таблиц?
Чтобы не делать full scan по всей таблице из 100500 миллионов записей.
Из -за того, что ключи подсолены CRC32, данные распределяются по кластеру более-менее равномерно, надо или сделать scan со всеми возможными солями + частичный ключ или… здаравствуй fullscan.
Если мы говорим про Spring, то не надо забывать про scope бинов. При использовании не singleton scope (prototype, request,session.....) внедрение самого бина в конструкторе невозможно. И тут уже либо сеттеры либо поля.
Добрый день, у jenv есть хорошая альтернатива - SDKman - https://sdkman.io. Он по запросу выкачивает и устанавливает как JDK, так и такие инструменты как maven, gradle. Так же можно в разных каталогах использовать разные JVM.
Не холивара ради а только для разнообразия.
Если под "монолитом" понимается то, что сервис делает более одной вещи (слушает очередь и предоставляет api) то да, деплоится сервис, который обслуживает часть домена и он единственный знает как с этой частью работать.
И то, что запущено 10 копий этого сервиса, но под чтение очереди используется 0.000001% мощности одной копии, а всё остальное выедает API на мой взгляд ничего страшного.
Можно конечно делить сервис на отдельные операции и деплоить 10 копий "Лента-GET-List", 5 копий "Лента-GET-Message" ,2 копии "Лента-POST-mesage", ... но все эти наносервисы будут зависимыми от единой доменной модели сервиса. В том числе и по деплою.
и каждый сервис будет включать в себя логику того, как именно ему надо распорядиться информацией о сообщении. Поставщик же просто уведомляет всех заинтересованных "появился новый человек". А подписчики уже реагируют по-своему.
Всё куда проще, надо сделать worker частью Ленты. Тогда Лента сама будет вычитывать данные из очереди и класть их в свою базу нужным образом.
По поводу vacuum - есть утилита pg-repack (https://github.com/reorg/pg_repack) которая обслуживает таблицы без долгого глобального лока. Она оттестирована, и лучше использовать её вместо своих велосипедов.
С партиционированием тоже не всё так просто. От версии к версии конечно становится лучше, но партиционированные таблицы имеют ограничения по уникальным констрейнам, которые должны включать ключ партиционирования. А при неправильно выбранном ключе запросы становятся дольше, так как опрашиваются сразу все партиции.
Именно поэтому мы у себя используем свои мапперы, которые являются спринговыми бинами и обеспечивают типобезопасность на этапе компиляции. Нет маппера — ошибка компиляции.
А если ключ составной, и известна только часть ключа, то всё становится гораздо более интересно.
Предположим, что ключ имеет вид «customerId|year|month|day|transactionId», от него считается CRC32 и в БД кладётся «hash|customerId|year|month|day|transactionId»
Задача посчитать сумму транзакций клиента за месяц года. Известная часть ключа «customerId|year|month»
Так как ключи подсолены, данные по транзакциям размазаны по кластеру, put и get идут быстро, но… нельзя уже сделать один scan с префиксом ключа «customerId|year|month» чтобы получить данные по всем транзакциям месяца. Тут или делать сканы по всем возможным значениям хеша +частичный ключ или full scan.
Каким путём лучше идти в этом случае?
А как вы работаете со Scan по частичному ключу в случае «солёных» таблиц?
Чтобы не делать full scan по всей таблице из 100500 миллионов записей.
Из -за того, что ключи подсолены CRC32, данные распределяются по кластеру более-менее равномерно, надо или сделать scan со всеми возможными солями + частичный ключ или… здаравствуй fullscan.