This could be an interesting competitor to Apache Kafka, which is singularly unique in this space as far as I'm aware. On another note, I find it somewhat funny that these are called "log" services, logging is probably the least interesting use case for these things I can think of. A better description in my mind would be as a distributed event processing framework, since what they are really doing is distributing di…
I don't think "distributed event processing framework" describes this system at all. It's exactly what it says on the tin: a replicated log (i.e. event log) storage system that one can build other systems on top of. It's not processing events as far as I can see?
Twitter open-sources a high-performance replicated log service
11–20 of 121 posts
Re: Twitter open-sources a high-performance replicated log service
#12Earlier quoted context omitted.
There's a great blog post on this: https://blog.twitter.com/2015/building-distributedlog-twitte...
Which says " At design time we had concerns about Kafka’s I/O model and its lack of strong durability guarantees‐a non-starter for an application like a distributed transaction log[3]" Seems reasonable, right? Except "[3] Kafka addressed these durability concerns in version 0.8" So they built a whole thing, because they didn't bother to ask or say "hey, if we help fix the durability, would that we welcome?" or even "…
Re: Twitter open-sources a high-performance replicated log service
#13Re: Twitter open-sources a high-performance replicated log service
#14Wonder how it compares to Facebook Scribe?
Re: Twitter open-sources a high-performance replicated log service
#15Earlier quoted context omitted.
I don't think "distributed event processing framework" describes this system at all. It's exactly what it says on the tin: a replicated log (i.e. event log) storage system that one can build other systems on top of. It's not processing events as far as I can see?
You put events in one end, and it distributes them, reliably and consistently, to distributed end-points that can consume them. That is far more powerful than simply being used to log events for later retrieval, though it can be used for that. I have seen systems using Kafka that process tens of thousands of time-sensitive events a second and distribute them all over the world for independent processing as part of a…
Re: Twitter open-sources a high-performance replicated log service
#16Re: Twitter open-sources a high-performance replicated log service
#17This could be an interesting competitor to Apache Kafka, which is singularly unique in this space as far as I'm aware. On another note, I find it somewhat funny that these are called "log" services, logging is probably the least interesting use case for these things I can think of. A better description in my mind would be as a distributed event processing framework, since what they are really doing is distributing di…
Re: Twitter open-sources a high-performance replicated log service
#18Earlier quoted context omitted.
You put events in one end, and it distributes them, reliably and consistently, to distributed end-points that can consume them. That is far more powerful than simply being used to log events for later retrieval, though it can be used for that. I have seen systems using Kafka that process tens of thousands of time-sensitive events a second and distribute them all over the world for independent processing as part of a…
"real-time event journaling and dissemination system"?
Re: Twitter open-sources a high-performance replicated log service
#19Earlier quoted context omitted.
"real-time event journaling and dissemination system"?
Yes I like that, much more accurate descriptor than "log", though it is more verbose. In the end it is really just nitpicking I guess, but the discoverability of calling these systems "log services" is very low compared to what they are really capable of.
Re: Twitter open-sources a high-performance replicated log service
#20Earlier quoted context omitted.
There's a great blog post on this: https://blog.twitter.com/2015/building-distributedlog-twitte...
Which says " At design time we had concerns about Kafka’s I/O model and its lack of strong durability guarantees‐a non-starter for an application like a distributed transaction log[3]" Seems reasonable, right? Except "[3] Kafka addressed these durability concerns in version 0.8" So they built a whole thing, because they didn't bother to ask or say "hey, if we help fix the durability, would that we welcome?" or even "…
Not saying that they couldn't have worked more closely with Kafka's team in the first place, but, hey, now we have two Kafkaesque log services instead of just one. Seems like a win to me.