We were discussing the use case of stream storage with message broker. We continue the discussion today.
A message broker can roll over all data eventually to persistence, so the choice of storage does not hamper the core functionality of the message broker.
A stream storage can be hosted on any Tier2 storage whether it is files or blobs. The choice of tier 2 storage does not hamper the functionality of the stream store. In fact, the append only unbounded data nature of messages in the queue is exactly what makes the stream store more appealing to these message brokers
Together the message broker and the storage engine provide address and persistence of queues to facilitate access via a geographically close location. However, we are suggesting native message broker functionality to stream storage in a way that promotes this distributed message broker that is enhanced by storage engineering best practice. Since we have streams for queues, we don’t need to give queues any additional journaling.
The stream store has an existing concept of events with their readers and writers. The queues continuously read and write but there does not need to be a dual definition of stream and queue. Their purpose was to define a logical boundary where service and store. These queues and streams can actually be local or global since they were hosted on independent clusters and can now be hosted from the same cluster. A local queue can be store or stream specific. The global queues can be reached from anywhere by any client and the store takes care of regional availability The integration of clusters is central to making this work. The stream and the queue can have improved addressing that enables local or regional lookup. The persistence strategy for queue processing can take advantage of scopes and streams to group them together. However, in this case too, we don’t have to leverage external technologies such as a gateway for address translation. It can be part of the address that the store recognizes.
A message broker can roll over all data eventually to persistence, so the choice of storage does not hamper the core functionality of the message broker.
A stream storage can be hosted on any Tier2 storage whether it is files or blobs. The choice of tier 2 storage does not hamper the functionality of the stream store. In fact, the append only unbounded data nature of messages in the queue is exactly what makes the stream store more appealing to these message brokers
Together the message broker and the storage engine provide address and persistence of queues to facilitate access via a geographically close location. However, we are suggesting native message broker functionality to stream storage in a way that promotes this distributed message broker that is enhanced by storage engineering best practice. Since we have streams for queues, we don’t need to give queues any additional journaling.
The stream store has an existing concept of events with their readers and writers. The queues continuously read and write but there does not need to be a dual definition of stream and queue. Their purpose was to define a logical boundary where service and store. These queues and streams can actually be local or global since they were hosted on independent clusters and can now be hosted from the same cluster. A local queue can be store or stream specific. The global queues can be reached from anywhere by any client and the store takes care of regional availability The integration of clusters is central to making this work. The stream and the queue can have improved addressing that enables local or regional lookup. The persistence strategy for queue processing can take advantage of scopes and streams to group them together. However, in this case too, we don’t have to leverage external technologies such as a gateway for address translation. It can be part of the address that the store recognizes.
No comments:
Post a Comment