Когда Kafka Streams GlobalKTable — хороший выбор в качестве хранилища данных в мире микросервисов?

В целом преимущества GlobalKTable:

• Вы можете выполнить присоединение к GlobalKTable по внешнему ключу.
• Приложение имеет полный набор данных в памяти, набор данных автоматически загружается во время запуска приложения, и все изменения данных автоматически синхронизируются во всех экземплярах. Сравнивая это с архитектурой с внешней базой данных, вам не нужно связываться (через сеть) с каким-либо другим ресурсом (например, с реляционной базой данных) во время обработки сообщений, поэтому очевидно, что обработка происходит намного быстрее, и в результате вы можете обрабатывать большие объемы данных. объем данных быстро. Когда вы хотите добиться аналогичной производительности обработки, вам нужно реализовать свой собственный кеш в памяти (например, Guava), а затем вам нужно решить все вопросы, связанные с правильным управлением кэшированием - прогрев, обновление, выселение.

И главные недостатки:

• Приложение имеет полный набор данных в памяти, это преимущество, но это может быть очень большой проблемой, все зависит от того, насколько велик ваш набор данных или как вы моделируете свои данные. Ссылаясь на ваш пример, хранение всех пользовательских заказов в GlobalKTable звучит как очень плохая идея, набор данных будет расти очень быстро, а размер данных со временем растет, поэтому после нескольких месяцев / лет работы приложения на производстве набор данных может иметь гигабайты, и он будет постоянно расти. Когда нам все еще нравится хранить заказы в GlobalKTable для эффективной обработки, нам нужно по-другому проектировать нашу модель данных. Вероятно, наши объекты (заказы, документы и т. д.) имеют некоторый жизненный цикл, например: новые, оплаченные, закрытые и т. д., некоторые из них завершаются — я имею в виду, что дальнейшая обработка объекта с заданным идентификатором не будет (например, закрытый заказ ), так что если обработки не будет, хранить данные в памяти не нужно, мы можем перенаправить их в какое-то другое хранилище, например Elasticsearch, и удалить из GlobalKTable. Мы можем назвать наш набор данных с заказами при обработке горячим хранением и набором данных с прекращенными заказами с холодным хранением. Короче говоря: иметь только активные/горячие заказы в GlobalKTable может быть хорошей идеей.
• Запрос GlobalKTable ограничен перебором всего набора данных, подмножества или получением данных по ключу записи или ключу, составленному с отметкой времени.
• Обработка на основе состояния во внешней базе данных широко используется уже много лет, поэтому многие разработчики знают, как развивать и поддерживать такие приложения. Мы не можем сказать то же самое о сохранении состояния в уплотненных топиках Kafka.