jvanlightly
Re:S3 Express One Zone, Not Quite What I Hoped For
on Sunday December 17, 2023 @02:50PM (#38675785)
Author here: Regarding point 3, it was my understanding that inserts are synchronous but updates may be asynchronous. Is that the case?
Re:Why `fsync()`: Losing unsynced data on a single node leads to globa...
on Tuesday May 16, 2023 @12:32PM (#35964218)
Protocol Aware Recovery is really needed if you want Raft to tolerate disk corruption. https://www.usenix.org/conference/fast18/presentation/alagap...
Re:Kafka vs. Redpanda Performance – Do the claims add up?
on Monday May 15, 2023 @04:46PM (#35954258)
These instances can manage up disk throughput up to 2 GB/s (400K IOPS) and network throughout of 25gbps or ~3.1 GB/s.
There are so many dimensions, with configurations, CPU architecture, hardware resources plus all the workloads and the client configs. It gets kind of crazy. I like to use a dimension testing approach where I fix everything but vary one or possibly two dimensions at a time and plot the relationships to performance.
Re:Kafka vs. Redpanda Performance – Do the claims add up?
on Monday May 15, 2023 @03:59PM (#35953682)
It's a common misconception about Kafka and fsyncs. But the Kafka replication protocol has a recovery mechanism, much in the same way that Viewstamped Replication Revisited does (except it's safer due to the page cache), which allows Kafka to write to disk asynchronously. The trade-off is that we need fault domains (AZs in the cloud), but if we care about durability and availability, we should be deploying across AZs anyway. We've seen plenty of full region outages, but zero power loss events in multiple AZs in six years.
Kafka and fsyncs: https://jack-vanlightly.com/blog/2023/4/24/why-apache-kafka-...
Re:Kafka vs. Redpanda Performance – Do the claims add up?
on Monday May 15, 2023 @12:51PM (#35951113)
Well, that just isn't accurate really. Kafka would need simulteanous VM failure across all AZs. That just doesn't happen in the real world often enough to worry about. It has never happened in Confluent Cloud. RP have a similar issue. Single AZ deployments with local NVMe drives. AZ loses power, a majority of brokers could lose all their data. Then there's data corruption. Fsyncs alone don't save you. The next step would be to implement Protocol Aware Recovery (https://www.usenix.org/conference/fast18/presentation/alagap...) like TigerBeetle have. Does a system that has implemented anti-corruption in the storage layer now get to lambast Redpanda, Pulsar, ZooKeeper etc because they didn't implement that?
Re:Kafka vs. Redpanda Performance – Do the claims add up?
on Monday May 15, 2023 @12:21PM (#35950689)
Author here. Yes both Kafka and Redpanda were deployed on identical hardware: three i3en.6xlarge.