5 ms·

It doesn't mean he's wrong, but hyc_symas is the CTO of Symas who produce the Lightning memory-mapped database, so part of his business is in direct competition

by nieve 12y ago

It doesn't mean he's wrong, but hyc_symas is the CTO of Symas who produce the Lightning memory-mapped database, so part of his business is in direct competition. He does dance around this a bit below, but I think how aggressively he's trashing MDBM with broad & unsupported statements in this thread doesn't really speak well of his company or his personaly integrity. You can have a technical disagreement without looking like you're spreading FUD in place of valid technical arguments. This isn't how you do that.

hyc_symas 12y ago
I stated up front that I am totally biased. I provided multiple links backing up my statements. Nothing I've said here is unfounded. The only FUD here is advertising a piece of software as a high performance embedded database when in fact it's not suitable for such use on its own. The most viable use cases the authors have presented is when using MDBM as part of a larger distributed system such that the loss of a single DB instance isn't fatal. The above comment talks about restoring from a log, but the actual log mechanism isn't part of MDBM. I.e., MDBM is incomplete on its own and you must provide additional pieces in order to use it effectively. I'm not solely interested in promoting my own DB. If you read the On-Disk microbenchmarks I linked you'll see that there's a broad range of use cases where LMDB gets trounced by LevelDB and other LSMs. I'm interested in facts. From the original link: "On clean shutdown of the machine, all of the MDBM data will be flushed to disk. However, in cases like power-failure and hardware problems, it’s possible for data to be lost, and the resulting DB to be corrupted. MDBM includes a tool to check DB consistency. However, you should always have contingencies. One way or another this is some form of redundancy…" The fact is, this is a system that can lose data on a crash and it doesn't include its own recovery mechanism. Without such a mechanism you can't call it a persistent data store because MDBM by itself is not persistent.
- cbsmith 12y ago
  > The fact is, this is a system that can lose data on a crash and it doesn't include its own recovery mechanism. Without such a mechanism you can't call it a persistent data store because MDBM by itself is not persistent. Persistence != ACID By your definition, ext2 is not persistent. Give it a break.
  - hyc_symas 12y ago
    ext2 comes with its own recovery system: fsck.
    - luckydude 12y ago
      The yahoo people claim to have the same thing for mdbm. As someone who worked on it, I can easily see how you would write such a thing, it's way more trivial than fsck (and I'm a file system guy, I'd much rather write a mdbm_fsck than a file system fsck).
      - cbsmith 12y ago
        They don't just claim to have the same thing for mdbm, it's right there in the project. Sounds like you are shooting off without really understanding what you are criticizing.
luckydude 12y ago
That explains a lot, I had guessed as much. hyc_symas should give it a rest, mdbm isn't competing with an actual DB, it's a memory mapped hash, a fast one and useful for a lot of things, but it's not a DB. I dunno where he got that idea from in the first place.
- hyc_symas 12y ago
  > I dunno where he got that idea from in the first place. You really started posting on this comment thread without reading the title of the article?
  - luckydude 12y ago
    Lots of things are called a database without having database functionality. man gdbm: GDBM - The GNU database manager. So you are spouting all your disdain based on a title? Just curious, have you even run any version of mdbm? Or are you just spitting out baseless opinions? I'm sure your code is awesome and all but man, you are defensive. If your code is that great let it speak for itself. Bashing stuff that isn't even trying to compete with you makes you look pretty insecure. You remind me of me when I was younger; that's not a compliment, I was a raging asshole.
    - hyc_symas 12y ago
      Don't be silly. My opinions are never baseless. We used MDBM in OpenLDAP for a few years on SGI Irix. I haven't touched it myself in something like 9 or 10 years though. http://www.openldap.org/lists/openldap-devel/199903/msg00094.html http://www.openldap.org/lists/openldap-devel/199903/msg00094... http://www.openldap.org/lists/openldap-devel/200501/msg00053.html http://www.openldap.org/lists/openldap-devel/200501/msg00053... Using DBM-style DBs was an endless nightmare of corruption bugs. That technology belongs firmly in the distant past, we have better solutions today. http://www.openldap.org/lists/openldap-software/200607/msg00070.html http://www.openldap.org/lists/openldap-software/200607/msg00... I'm not bashing MDBM because it's a competitor; it obviously isn't a competitor. Heck the only reason I'm commenting in this thread is because you asked me to elaborate on its design flaws. Now you're hurt that I answered your question. Don't ask if you don't want to know the answer. ... seems like us folks in OpenLDAP weren't the only ones to have bad experiences with it. This guy in this same discussion seems to share the basic sentiment. https://news.ycombinator.com/item?id=8733819 https://news.ycombinator.com/item?id=8733819

by nieve 12y ago

hyc_symas 12y ago

I stated up front that I am totally biased. I provided multiple links backing up my statements. Nothing I've said here is unfounded. The only FUD here is advertising a piece of software as a high performance embedded database when in fact it's not suitable for such use on its own. The most viable use cases the authors have presented is when using MDBM as part of a larger distributed system such that the loss of a single DB instance isn't fatal. The above comment talks about restoring from a log, but the actual log mechanism isn't part of MDBM. I.e., MDBM is incomplete on its own and you must provide additional pieces in order to use it effectively. I'm not solely interested in promoting my own DB. If you read the On-Disk microbenchmarks I linked you'll see that there's a broad range of use cases where LMDB gets trounced by LevelDB and other LSMs. I'm interested in facts. From the original link: "On clean shutdown of the machine, all of the MDBM data will be flushed to disk. However, in cases like power-failure and hardware problems, it’s possible for data to be lost, and the resulting DB to be corrupted. MDBM includes a tool to check DB consistency. However, you should always have contingencies. One way or another this is some form of redundancy…" The fact is, this is a system that can lose data on a crash and it doesn't include its own recovery mechanism. Without such a mechanism you can't call it a persistent data store because MDBM by itself is not persistent.

cbsmith 12y ago
> The fact is, this is a system that can lose data on a crash and it doesn't include its own recovery mechanism. Without such a mechanism you can't call it a persistent data store because MDBM by itself is not persistent. Persistence != ACID By your definition, ext2 is not persistent. Give it a break.
- hyc_symas 12y ago
  ext2 comes with its own recovery system: fsck.
  - luckydude 12y ago
    The yahoo people claim to have the same thing for mdbm. As someone who worked on it, I can easily see how you would write such a thing, it's way more trivial than fsck (and I'm a file system guy, I'd much rather write a mdbm_fsck than a file system fsck).
    - cbsmith 12y ago
      They don't just claim to have the same thing for mdbm, it's right there in the project. Sounds like you are shooting off without really understanding what you are criticizing.

luckydude 12y ago

That explains a lot, I had guessed as much. hyc_symas should give it a rest, mdbm isn't competing with an actual DB, it's a memory mapped hash, a fast one and useful for a lot of things, but it's not a DB. I dunno where he got that idea from in the first place.

hyc_symas 12y ago
> I dunno where he got that idea from in the first place. You really started posting on this comment thread without reading the title of the article?
- luckydude 12y ago
  Lots of things are called a database without having database functionality. man gdbm: GDBM - The GNU database manager. So you are spouting all your disdain based on a title? Just curious, have you even run any version of mdbm? Or are you just spitting out baseless opinions? I'm sure your code is awesome and all but man, you are defensive. If your code is that great let it speak for itself. Bashing stuff that isn't even trying to compete with you makes you look pretty insecure. You remind me of me when I was younger; that's not a compliment, I was a raging asshole.
  - hyc_symas 12y ago
    Don't be silly. My opinions are never baseless. We used MDBM in OpenLDAP for a few years on SGI Irix. I haven't touched it myself in something like 9 or 10 years though. http://www.openldap.org/lists/openldap-devel/199903/msg00094.html http://www.openldap.org/lists/openldap-devel/199903/msg00094... http://www.openldap.org/lists/openldap-devel/200501/msg00053.html http://www.openldap.org/lists/openldap-devel/200501/msg00053... Using DBM-style DBs was an endless nightmare of corruption bugs. That technology belongs firmly in the distant past, we have better solutions today. http://www.openldap.org/lists/openldap-software/200607/msg00070.html http://www.openldap.org/lists/openldap-software/200607/msg00... I'm not bashing MDBM because it's a competitor; it obviously isn't a competitor. Heck the only reason I'm commenting in this thread is because you asked me to elaborate on its design flaws. Now you're hurt that I answered your question. Don't ask if you don't want to know the answer. ... seems like us folks in OpenLDAP weren't the only ones to have bad experiences with it. This guy in this same discussion seems to share the basic sentiment. https://news.ycombinator.com/item?id=8733819 https://news.ycombinator.com/item?id=8733819