3 ms·

From the OP's posting: Test MDBM LevelDB KyotoCabinet BerkeleyDB Write Time 1.1 μs 4.5 μs 5.1 μs 14.0 μs Read Time

From the OP's posting: Test MDBM LevelDB KyotoCabinet BerkeleyDB Write Time 1.1 μs 4.5 μs 5.1 μs 14.0 μs Read Time 0.45 μs 5.3 μs 4.9 μs 8.4 μs Sequential Read 0.05 μs 0.53 μs 1.71 μs 39.1 μs Sync Write 2625 μs 34944 μs 177169 μs 13001 μs As to losing credibility, I'm semi retired, I stopped trying to impress people a decade ago. If i were you I'd be more worried about your own image, bad mouthing other people's tech when you demonstrate you don't understand it hasn't made you like good to at least a few people here. It wouldn't be that hard to say "MDBM is great when used as an index into a DB, it works just fine for that. But you are going to have to rebuild the index after a power failure unless you take care to flush the data. It's somewhat unfair that the OP compared against my database because mine is slower because it handles crashes." Instead you come out with "MDBM is complete crap". Well, no, it's not. In the domain where it is useful it is actually quite useful, it's 10x faster for lookups than your DB. So the trade off is speed vs surviving reboots. For lots of people, speed is much more important. Machines don't crash every ten minutes. In fact, it's pretty common to see uptimes in 100's of days. Lets say that 100 days is average and lets say that it takes a full day to rebuild the MDBM. So MDBM is delivering 99/100 days of useful work. You deliver 100/100 days. Oh, wait, except that your useful work is running 10x slower if the DB is being used as an index. So you delivered 10/100 days. See why some people may prefer to use MDBM when it is put like that? Performance is a feature.

cbsmith 12y ago
I think the comparison was totally appropriate because the article specifically highlighted mdbm's design limitations. The whole point was that given the compromises mdbm makes, it is possible to yield significant performance gains, so if those design limitations fit your context (and it cited 4 specific examples where Yahoo uses them), you ought to consider it.
- hyc_symas 12y ago
  My point, and the reason I will still say MDBM is garbage, is that you can get mmap/zero-copy performance without sacrificing reliability. Only a fool would argue for the performance without reliability when they can get both. And with a lower total system cost.
  - cbsmith 12y ago
    > Only a fool would argue for the performance without reliability when they can get both. And with a lower total system cost. I think that statement is absolutely true. I just think you have a myopic view about how to achieve performance and reliability. Look at Yahoo's example use cases.
hyc_symas 12y ago
Nice try. Performance is a side-effect, efficiency is a feature. Nothing you can find will show MDBM to be 10x faster than LMDB. You must be talking about LevelDB. Look at the results I posted again, and look at the benchmark code. Tell me that I've made a mistake, that's fine. The thing about open source is there's no reason to BS, anyone can build and run it and see for themselves. LMDB is faster and its data is more compact than MDBM, so you can get more work done using less resources, and you don't have to worry about losing your work for unexpected downtime. Hashes suck for large volumes of data. That's just the reality of it, plain and simple: Low storage efficiency, memory-intensive, and cache-unfriendly. Whether people like or dislike me personally for saying so doesn't change the facts. As for uptime - sure, and my PCs have uptimes for hundreds of days too. But I'd be a fool to just take that for granted and not take regular backups. The problem with your 99/100 days math is that you can't actually account for the cost of a crash that way. It might only set you back to 0/100; if you're unlucky it will set you back to -100 or more.
- luckydude 12y ago
  You're right, I was talking about LevelDB. But in your benchmark MDBM is 2x faster on the code path it cares about, random reads. Lots of people pay attention to a factor of 2. Any idea why it is that much better than LMDB? I actually agree with you in that hashes sort of suck, just look at Git when the repo gets big, a hash is a miserable way to traverse all that data, very cache unfriendly. But the use cases for MDBM are the same, you have lots of keys and you want to get to any key very quickly. It appears to me that it (still, 20 years later) wins that race.
  - hyc_symas 12y ago
    > Any idea why it is that much better than LMDB? Yes, for exactly the reasons you'd expect: mdb_stat /tmp/leveldbtest-1000/dbbench_mdb-6/ Status of Main DB Tree depth: 4 Branch pages: 204 Leaf pages: 31250 Overflow pages: 0 Entries: 1000000 As you said, MDBM can find any record in 2 seeks; for this database the LMDB tree height is 4 so any random access takes 4 seeks. 2x perf difference. On a larger DB we would expect MDBM's random read perf advantage to get larger as well, until the DB exceeds the size of RAM. I've tried to duplicate my http://symas.com/mdb/ondisk/ http://symas.com/mdb/ondisk/ tests with MDBM but it makes XFS lose its mind by the time the DB gets to 2x the size of RAM. First I had to increase the MDBM page size from my default of 4KB to 128KB, otherwise I'd see a lot of this in the output: 2014/12/16-13:13:29 ... thread 0: (200000,12200000) ops and (3436.0,8072.2) ops/second in (58.206750,1511.358831) seconds 3:54903002:dc057:00864 mdbm.c:1809 MDBM cannot grow to 33554432 pages, max=16777216 but on this VM with 32GB RAM, every time the DB hit 60GB in size the kernel log would start getting spammed with Dec 16 22:19:19 localhost kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) Dec 16 22:19:21 localhost kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) Dec 16 22:19:23 localhost kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) So thus far I've been unable to load the 160GB DB to reproduce the test. But this underscores the basically uncacheable nature of hashes - once the directory gets too big to fit in RAM, your "2 seeks per access" goes out the window because the kernel is thrashing itself trying to keep the whole directory in-memory while finding the requested data pages. B+tree performance degrades gracefully as data volumes increase. Hash performance falls off a cliff once you cross the in-memory threshold.
cbsmith 12y ago
> For lots of people, speed is much more important. Machines don't crash every ten minutes. Even if they do, it is often faster and more reliable to recover from the RAM of a surviving node than to try to recover from the disk on the crashed system. > lets say that it takes a full day to rebuild the MDBM I can't imagine a circumstance where it'd take even an hour to rebuild an MDBM from raw data.

cbsmith 12y ago

I think the comparison was totally appropriate because the article specifically highlighted mdbm's design limitations. The whole point was that given the compromises mdbm makes, it is possible to yield significant performance gains, so if those design limitations fit your context (and it cited 4 specific examples where Yahoo uses them), you ought to consider it.

hyc_symas 12y ago
My point, and the reason I will still say MDBM is garbage, is that you can get mmap/zero-copy performance without sacrificing reliability. Only a fool would argue for the performance without reliability when they can get both. And with a lower total system cost.
- cbsmith 12y ago
  > Only a fool would argue for the performance without reliability when they can get both. And with a lower total system cost. I think that statement is absolutely true. I just think you have a myopic view about how to achieve performance and reliability. Look at Yahoo's example use cases.

hyc_symas 12y ago

Nice try. Performance is a side-effect, efficiency is a feature. Nothing you can find will show MDBM to be 10x faster than LMDB. You must be talking about LevelDB. Look at the results I posted again, and look at the benchmark code. Tell me that I've made a mistake, that's fine. The thing about open source is there's no reason to BS, anyone can build and run it and see for themselves. LMDB is faster and its data is more compact than MDBM, so you can get more work done using less resources, and you don't have to worry about losing your work for unexpected downtime. Hashes suck for large volumes of data. That's just the reality of it, plain and simple: Low storage efficiency, memory-intensive, and cache-unfriendly. Whether people like or dislike me personally for saying so doesn't change the facts. As for uptime - sure, and my PCs have uptimes for hundreds of days too. But I'd be a fool to just take that for granted and not take regular backups. The problem with your 99/100 days math is that you can't actually account for the cost of a crash that way. It might only set you back to 0/100; if you're unlucky it will set you back to -100 or more.

luckydude 12y ago
You're right, I was talking about LevelDB. But in your benchmark MDBM is 2x faster on the code path it cares about, random reads. Lots of people pay attention to a factor of 2. Any idea why it is that much better than LMDB? I actually agree with you in that hashes sort of suck, just look at Git when the repo gets big, a hash is a miserable way to traverse all that data, very cache unfriendly. But the use cases for MDBM are the same, you have lots of keys and you want to get to any key very quickly. It appears to me that it (still, 20 years later) wins that race.
- hyc_symas 12y ago
  > Any idea why it is that much better than LMDB? Yes, for exactly the reasons you'd expect: mdb_stat /tmp/leveldbtest-1000/dbbench_mdb-6/ Status of Main DB Tree depth: 4 Branch pages: 204 Leaf pages: 31250 Overflow pages: 0 Entries: 1000000 As you said, MDBM can find any record in 2 seeks; for this database the LMDB tree height is 4 so any random access takes 4 seeks. 2x perf difference. On a larger DB we would expect MDBM's random read perf advantage to get larger as well, until the DB exceeds the size of RAM. I've tried to duplicate my http://symas.com/mdb/ondisk/ http://symas.com/mdb/ondisk/ tests with MDBM but it makes XFS lose its mind by the time the DB gets to 2x the size of RAM. First I had to increase the MDBM page size from my default of 4KB to 128KB, otherwise I'd see a lot of this in the output: 2014/12/16-13:13:29 ... thread 0: (200000,12200000) ops and (3436.0,8072.2) ops/second in (58.206750,1511.358831) seconds 3:54903002:dc057:00864 mdbm.c:1809 MDBM cannot grow to 33554432 pages, max=16777216 but on this VM with 32GB RAM, every time the DB hit 60GB in size the kernel log would start getting spammed with Dec 16 22:19:19 localhost kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) Dec 16 22:19:21 localhost kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) Dec 16 22:19:23 localhost kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) So thus far I've been unable to load the 160GB DB to reproduce the test. But this underscores the basically uncacheable nature of hashes - once the directory gets too big to fit in RAM, your "2 seeks per access" goes out the window because the kernel is thrashing itself trying to keep the whole directory in-memory while finding the requested data pages. B+tree performance degrades gracefully as data volumes increase. Hash performance falls off a cliff once you cross the in-memory threshold.

cbsmith 12y ago

> For lots of people, speed is much more important. Machines don't crash every ten minutes. Even if they do, it is often faster and more reliable to recover from the RAM of a surviving node than to try to recover from the disk on the crashed system. > lets say that it takes a full day to rebuild the MDBM I can't imagine a circumstance where it'd take even an hour to rebuild an MDBM from raw data.