Bilingual

<antirez>
9 hours ago
- Performance in database systems consists of three main components: latency, operations per unit of time per core, and quality of operations.
- Latency measures the time for a query reply, with predictability and consistency being as important as average time.
- Operations per second per core distinguishes raw performance from scalability and relates to energy efficiency.
- Quality of operations reflects the value of each operation, such as performing complex tasks (e.g., INCR) in a single command, which can double performance for certain use cases.
- The importance of quality of operations varies by problem; it is especially critical in in-memory systems where computation time is minimal compared to command dispatch.
- High-quality operations can reduce latency and bandwidth usage by enabling more selective or complex replies, as seen with Redis commands like ZRANK or HMGET.
<antirez>
9 hours ago
- Redis speed is a selling point, but comparative benchmarks are often misleading due to differences in data models, durability, and testing conditions.
- Fair comparisons require identical protocols and client libraries; otherwise, results reflect network stack and kernel rather than database performance.
- A benchmark comparing Redis and AerospikeDB on large EC2 instances (244 GB RAM) is unrealistic; a smaller m3.medium instance shows Redis achieving 32k ops/sec without pipelining.
- Using pipelining (e.g., 32 operations) boosts Redis performance dramatically: 250k ops/sec on a single core, outperforming the benchmark's multi-core result.
- Benchmarking simple GET/SET operations is insufficient; Redis excels at complex operations like ZADD for leaderboards and HyperLogLog for cardinality estimation, achieving 500k ops/sec combined.
- Better performance comparisons should focus on specific use cases, realistic instance types, and the number of instances needed to handle equivalent traffic.
Support for atomic block writes in Linux 6.13 (2025)
13 days ago
- Linux 6.13 introduces atomic block writes to prevent data tearing in databases.
- Atomic writes require hardware support (NVMe/SCSI) and software stack updates (VFS, filesystem, block layer).
- Databases use double writes for consistency, which atomic writes can replace to improve performance.
- Current implementation supports single-block atomic writes via O_DIRECT and pwritev2() with RWF_ATOMIC flag.
- Filesystem block size must align with device constraints; ext4 limits block size to page size, while XFS supports larger blocks.
- statx() system call queries atomic-write capabilities, including min/max unit sizes and support flags.
- Future work includes multi-block atomic write support and broader filesystem integration.

database performance

<antirez>

<antirez>

Support for atomic block writes in Linux 6.13 (2025)