Show HN: EnnoDB, a simple NoSQL database
twigtechnology.com> 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 ?
It's a Raspberry 1 Model B, the 512 MB version. So with any luck, I will see how this code performs once it runs out of memory? https://imgur.com/gallery/XI3Rul6
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.
Oh cool, an in-memory lightweight NOSQL database. In the context of pervasive computing I can see its multiple use cases. A embedded device with limited computing capabilites would be able to store, process and act on sensor data in near real-time.
Can this database be also embedded in applications?
The source code is there for anyone to do whatever they like with it. Of course you could use this in-process and strip away the server logic, it's even split into source files to make that easy (nosql.[hc] are the files that implement the key-value store, everything else handles the fcgi requests).
> "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
I did not know that! This is some cool trivia.
I figured every full-stack programmer worth his salt should try to write his own database at least once, no?
Define "full-stack".
It all depends on your stack. I think of a full-stack programmer as someone who can dive into any level of the application to fix something. If you have a classic app that is javascript in the front, PHP in the back, then he will need to be familiar with at least those two technologies.
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.
Those who can (or employed to) do everything from wire crimping, kernel hacking, to UX and graphic design.
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?
I've always thought "full-stack" meant both front-end and back-end. Meaning that they could work on the website and the API.
Don't you love it when you announce your project to the world, only to spot a massive bug immediately after? Let me reiterate everything I already said about people not using this for critical data, because it's apparently losing keys from time to time.
Incidentally, this is where the idea of writing a journal paid of, because even though keys were getting corrupted in memory, the journal was fine, and after the bugfix, read back nicely and recreated the keys.