11–20 of 23 posts
It's not that uncommon in MySQL-land to name things after people, so I guess it fits right in! MySQL itself was named after Monty's daughter, and MariaDB was named after Monty's other daughter.
Though I must confess that I originally thought EnnoDB meant "Ain't no DB" in a certain accent :p
Earlier quoted context omitted.
I learned a ton of things doing this (not least how to post something on HN, and that Show HN exists). Can't say that for Minecraft.
That's why I upvoted you. Btw, have you followed a tutorial or a instruction to make this? I'm reviewing the code and it seems pretty straightforward.
Not sure what kind of tutorial I could have read. I've seen two key-value store implementations before, memcache and openkeyval. The memcache code is a nightmare to follow, and openkeyval is written in PHP, so neither of them is what I'd call either a tutorial or instructive.
Other than that, I read a book about C twenty years ago, but I'm completely self-taught ever since. I obviously read djb's paper on critbit trees before implementing them. The rest is from man pages and code. I had never used libfcgi for anything big before embarking on this, so that was a new thing. It's also my first time using mmap, and the Windows equivalent. Configuring nginx just right may have been the hardest part of it all.
I think the code is pretty clean, although it could use a few more tests. Mocking out libfcgi is a bit of a chore that I didn't want to go into right now, and it has already bitten me in the ass once.
> "First of all, yes, the name is a pun." - Enno Rehling It's not that uncommon in MySQL-land to name things after people, so I guess it fits right in! MySQL itself was named after Monty's daughter, and MariaDB was named after Monty's other daughter. Though I must confess that I originally thought EnnoDB meant "Ain't no DB" in a certain accent :p
> The Raspberry Pi that I used for developing and running the server is a fantastic little machine, and its specs encouraged the compact, memory-efficent design.
> I set up a quick JavaScript example that reads and writes values from the database running on my home server, at http://enno.kn-bremen.de/keyval.html.*
Really cool. Is the home server an actual raspberry ?
Earlier quoted context omitted.
Define "full-stack".
Isn't "full-stack" just a new(ish) word for systems programmer? I.e. a programmer who can reason about and optimize for what goes on on the hardware?
> fast, in-memory database > The Raspberry Pi that I used for developing and running the server is a fantastic little machine, and its specs encouraged the compact, memory-efficent design. > I set up a quick JavaScript example that reads and writes values from the database running on my home server, at http://enno.kn-bremen.de/keyval.html.* Really cool. Is the home server an actual raspberry ?
I've got a RPi 2B sitting here that I want to fail over to sometime this weekend, which gives me an opportunity to think about that process, and how EnnoDB could make it easier. My current thinking is: switch to read-only mode, rsync the database to the new host, spin up another process there, then flip the IP address on the router. Probably going to need an admin interface for that. Fun!
This reminds me, I should probably write the database log to the SSD, not the SD card. The new Pi's root filesystem only has 2GB, I was running out of media.
I figured every full-stack programmer worth his salt should try to write his own database at least once, no?
Define "full-stack".
If you are building on external technologies, like a classic LAMP stack, then it helps to know a bit about those, too. Because software has bugs, and sometimes that bug is in apache, in PHP itself, in the PHP memcache library, or in MySQL. And woe be unto you if you are the first person to run into that bug, because congratulations, now you get to diagnose and fix it. Especially if it's open source. If it's proprietary code, you're in a whole other terrible mess.
The more complex the technology stack that you are building on, the more likely that it has crippling bugs, and the less likely that you're still able to figure them out. So in some sense, there is a rationale for building my own NoSQL store: I understand every part of my stack, and I know how to debug it if it should go wrong.
> fast, in-memory database > The Raspberry Pi that I used for developing and running the server is a fantastic little machine, and its specs encouraged the compact, memory-efficent design. > I set up a quick JavaScript example that reads and writes values from the database running on my home server, at http://enno.kn-bremen.de/keyval.html.* Really cool. Is the home server an actual raspberry ?
Can this database be also embedded in applications?