Hacker News Reader

Comment by drodgers | Hacker News Reader

I'm pretty sure they mean operations on the block storage layer (EBS) as reported by AWS CloudWatch monitoring.

It's a standard measure: https://en.wikipedia.org/wiki/IOPS

That is why I asked, I am only aware of the use of IOPS in connection with disk I/O and it seems a rather unusual measure for a database where caches hopefully avoid hitting the disk too often, at least for reads. And writing 8 MiB/s assuming 4k clusters seems not really noteworthy especially given three fold redundancy. On the other hand reading 700 MiB/s per second which would also not be affected by the redundancy seems a comparatively big number especially because caches should limit the disk traffic to a small fraction.

Databases usually don't use caches. It's cheaper to just ask the file-system for the data.

In Aerospike case, they do not use a file system. they own the mount point and access the disk blocks directly, optimizing for local SSD disks.

This is not true at all, bordering to utter nonsense. Databases try hard to keep the correct set of blocks in memory because that is essential for their performance. Heck, many of the fastest database systems advertise themselves as in-memory databases avoiding disks altogether.

Queries here are measured from the application side. And in our case, those are simple key-value operations such as get(key), update(key, value), write(key, value) and delete(key). Aerospike is known to optimize those into fewer block operation as it can.

No N1QL was involved that needed to be ported/re-architected?

N1QL was our primary use case for using Couchbase at my last position and it worked wonderfully (though at less than half your scale).

For straight key operations, the overhead of all the JVM stuff on couchbase seems like a lot, especially when considering the alternative amount of K/V stores these days.

Glad to hear Aerospike turned out well. Been keeping an eye on them over the past few years.

Reply on news.ycombinator.com