Cassandra hard
An extreme financial trading application requires 'Batch' sync for the Commit Log. What is the fundamental throughput limitation introduced by this setting?
- A The database can only handle one user at a time.
- B Disk I/O Bottleneck: Every single write operation must wait for a physical `fsync` (flush) to the disk hardware before acknowledging success to the client, limiting throughput to the IOPS capacity of the drive.
- C The network speed is reduced by 50% automatically.
- D It disables the use of SSDs, forcing the system back to HDD.
Answer: B. Disk I/O Bottleneck: Every single write operation must wait for a physical `fsync` (flush) to the disk hardware before acknowledging success to the client, limiting throughput to the IOPS capacity of the drive.
Most apps use `periodic` (10s window of risk) because it allows the OS to buffer writes in RAM, maximizing speed. `batch` ensures 100% ACID durability even during power loss, but it turns 'Memory speed' writes into 'Disk speed' writes, which are much slower.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In a Cassandra Keyspace, what does a 'Replication Factor of 3' specifically guarantee for your data redundancy?
- Unlike a Leader-Follower architecture (like MySQL or Redis), how does Cassandra maintain high availability within its node cluster?
- Cassandra Query Language (CQL) looks similar to SQL. What is a fundamental SQL feature that CQL does NOT support to ensure distributed performance?
- What is the critical architectural function of the 'Partition Key' in a Cassandra table?
- Apache Cassandra is fundamentally designed as which architectural category of NoSQL database?
- In a cluster with high 'Mutation' (Write) frequency, why is the `Row Cache` almost universally disabled by experts?