31–40 of 66 posts
Really excited about seeing IndexedDB run atop of this
Is LevelDB batching writes or is there something more interesting going on?
How is this different than BDB?
LevelDB is for if you need ordered data, and a more appropriate comparison would be against a B+\tree database.
How is this different than BDB?
BDB is a key\value store for unordered data more similar to Tokyo Cabinet hash databases. Tokyo Cabinet hash databases are a much faster option than BDB if you only need unordered data. LevelDB is for if you need ordered data, and a more appropriate comparison would be against a B+\tree database.
LevelDB is slower with random reads, but that doesn't mean you shouldn't use it for unordered data - it's still quite fast.
The synchronous writes benchmark is interesting. This is normally bound by # seeks your disk can do per second, which is mostly a function of rotational speed. With 7200RPM drive you get 7200/60 = 120 of these a second. So the 100 and 110 numbers for competitors make sense. 2,400 for LevelDB does not. Is LevelDB batching writes or is there something more interesting going on?
It's worth noting that the makefile includes options to build for iOS. I've successfully done it and my next iOS app will include LevelDB. Also worth noting, thanks to the iOS devices SSDs, it's much faster than with the traditional HDD machines.
The synchronous writes benchmark is interesting. This is normally bound by # seeks your disk can do per second, which is mostly a function of rotational speed. With 7200RPM drive you get 7200/60 = 120 of these a second. So the 100 and 110 numbers for competitors make sense. 2,400 for LevelDB does not. Is LevelDB batching writes or is there something more interesting going on?
Yes, updates can be done in one atomic batch. Please correct me if I'm wrong, but I don't think Tokyo Cabinet allows it without Tokyo Tyrant.
The synchronous writes benchmark is interesting. This is normally bound by # seeks your disk can do per second, which is mostly a function of rotational speed. With 7200RPM drive you get 7200/60 = 120 of these a second. So the 100 and 110 numbers for competitors make sense. 2,400 for LevelDB does not. Is LevelDB batching writes or is there something more interesting going on?
If you write full disk blocks, wouldn't the disk cache hide the seek latency?
You turn off write-through caching on disks when you run a database unless you are willing to accept corruption (which is worse than data loss) on power outage. And that's why you can't get acceptable write performance out of database without a battery-backed RAID controller (or something other kind of RAM-based write cache with a battery backup).
Here's a simple way to test # fsyncs/s (a.k.a. commit rate) on your system:
sysbench --test=fileio --file-fsync-freq=1 --file-num=1 \
--file-total-size=16384 --file-test-mode=rndwr run --max-time=10 \
| grep "Requests/sec"