By Zed A. Shaw

Announcing NoNoSQL

I got bored recently so I decided to create my NoSQL entrant. Those seem to be pretty hot projects and I had some ideas, so I hacked one up in a few days to try it out. Originally it was just gonna be a joke, but actually I kind of like this thing. I'm gonna screw around with it and try it out on Crapmania! to see if it'll work.

I'm calling it NoNoSQL for lack of a better name. If it gets more serious then I'll pick something else. The man part of the joke is that it's a "NoSQL" server, but it has SQL in it, but you don't use SQL to do the SQL. Let me explain.

What I did was combine 0mq with sqlite3, tokyo cabinet, and finally, the filesystem, to create a server that lets you do all four at once using the 0mq scalability and speed building blocks. In theory this thing should be dead easy to scale out, shard, cluster, whatever you need to do. Right now of course it doesn't but the potential is there.

However, I took things one step further by making most everything you send and receive JSON. When you build a SQL query, it's just a JSON abbreviated format:

sql.select {"table": "test", "what": "name", "where": "age = $age$", "vars": {"age": 35}} RESPONSE {"query":"select name from test where age = 35 ","columns":1,"data": [["Zed"]]}

Now why do this? Because if your way of interacting with the database is encoded in a consistent JSON format, then the server can analyze it easier to decide what to do. That should make sharding and clustering a lot easier.

You can also do fun things with the mem hash and the disk like copy between them, the usuall put/get/del operations, move files, get file info, etc. The idea is that you can use the mem hash to store temporary stuff you're building, and then store it to disk for later retrieval.

Using disk isn't quite as fast as a disk hash database, but it has some advantages, namely it's a lot easier to work with and you can very easily export it out to a web server or similar file server. In theory you could use NoNoSQL to store things to disk and then plain old HTTP to serve them.

Anyway, check out the fossil repo I threw up real quick and let me know what you think. It's written in C++ using the excellent Grace library.

License

Right now I'm not sure. Depends on how useful I find it and whether I think it'll get ripped off like usual. I'm leaning toward BSD license but if your company uses any Ruby it'll be AGPL. That'd be fun.