kafka-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenny Gorman <ke...@eventador.io>
Subject Re: Kafka as a database/repository question
Date Thu, 15 Dec 2016 18:16:26 GMT
A couple thoughts..

- If you plan on fetching old messages in a non-contiguous manner then this may not be the
best design. For instance, “give me messages from mondays for the last 3 quarters” is
better served with a database. But if you want to say “give me messages from the last month
until now” that works great.

- I am not sure what you mean by updating messages. You would need to have some sort of key
and push in new messages with that key. Then when you read by key, the application should
understand that the latest is the version it should use.

- Alternatively, you can consume to something like a DB and use SQL to select what you want
using regular SQL. We see this pattern a lot.

- For storing messages indefinitely it’s mostly making sure the config options are set appropriately
and you have enough storage space. Set replication to something that makes you comfortable,
maybe take backups as was mentioned.

Hope this helps some

Kenny Gorman

> On Dec 15, 2016, at 12:00 PM, Susheel Kumar <susheel2777@gmail.com> wrote:
> Hello Folks,
> I am going thru an existing design where Kafka is planned to be utilised in
> below manner
>   1. Messages will pushed to Kafka by producers
>   2. There will be updates to existing messages on ongoing basis.  The
>   expectation is that all the updates are consolidated in Kafka and the
>   latest and greatest version/copy is kept
>   3. Consumers will read the messages from Kafka and push to Solr for
>   ingestion purposes
>   4. There will be no purging/removal of messages since it is expected to
>   replay the messages in the future and perform full-re-ingestion.  So
>   messages will be kept in Kafka for indefinite period similar to database
>   where data once stored remains there and can be used later in teh future.
> Do you see any pitfalls / any issue with this design especially wrt to
> storing the messages indefinitely.
> Thanks,
> Susheel

View raw message