Я читал несколько блогов, где люди говорят, что мы можем использовать Streams в качестве базы данных. (Вроде это ).
И это будет иметь очевидное преимущество масштабируемости, атомарности и т. Д. Потому что давайте возьмем пример Кафки Если мы используем Кафку в качестве хранилища данных и в Кафке есть 10 тем. Теоретически мы можем писать с 10 транзакциями в секунду, не беспокоясь о коллизиях (если все записи идут в другую тему). Но на очень низком уровне в любой другой базе данных только один поток будет что-то фиксировать в файловой системе. (мое понимание верно?)
Если я планирую реализовать вышеизложенное. У меня будет кафка в качестве промежуточного хранилища данных. И работают слушатели, которые продолжают отправлять данные в какое-то постоянное хранилище (для чтения / просмотра агрегатов).
Во многих службах CRUD мы должны прочитать объект, прежде чем пытаться его обновить. Но при вышеуказанном подходе могут быть некоторые события, которые еще не были обработаны. (Я понимаю, что вышеупомянутая проблема может существовать и в других базах данных с точки зрения возможной согласованности, но мы можем обойтись, используя сильные кворумы , но в приведенном выше случае мы привели еще один момент отказ и вероятность несинхронизации увеличивается). Также нам придется строить конвейеры, чтобы уведомлять пользователей об успешности их работы. Что нельзя сделать синхронно сейчас.
Следовательно, каковы все возможные варианты использования вышеуказанного подхода? Кафка хорош как база данных источников событий, но для написания CRUD-сервиса я вижу слишком много проблем. Я что-то упустил?