Live data from Hacker News

UnQLite - An Embeddable NoSQL Database Engine

unqlite.org

11–20 of 88 posts

Re: UnQLite - An Embeddable NoSQL Database Engine

#11

This turned up recently on proggit too. http://www.reddit.com/r/programming/comments/1etfxi/sqlite_n... was heavily downvoted for saying its an order of magnitude faster than SQLite http://www.reddit.com/r/programming/comments/1etkix/unqlite_... raises concerns about the license, and there's a Global Lock in there too? The scripting performance gives cause for pause too.

"It furthermore states that commercial licence must be acquired for closed source applications." I love the description of the scripting language as "Turing complete" based on "JSON". That is the first time I have ever heard turing complete used to market a programming language! The scripting language is incredible, I have never seen a more verbose way to program. It is a scripting language, yet seems to combine JSON…

It clearly states on the license page that its two clause BSD. Its only custom extensions and custom dev work done by the architect that requires payment. Perfectly fair and still open source.

Re: UnQLite - An Embeddable NoSQL Database Engine

#13

A very uncharitable reading of the features seems to suggest that this is some strange bastard child of a hashmap, a scripting language interpreter, and a JSON serializer. I'm sure it's much more than that, but one wonders where this stacks up compared to existing solutions.

LevelDB is similarly self-contained, and client/server API-less and is extremely fast. Though it has a large advantage of speed, the databases are not one files.

Re: UnQLite - An Embeddable NoSQL Database Engine

#14

A very uncharitable reading of the features seems to suggest that this is some strange bastard child of a hashmap, a scripting language interpreter, and a JSON serializer. I'm sure it's much more than that, but one wonders where this stacks up compared to existing solutions.

LevelDB is similarly self-contained, and client/server API-less and is extremely fast. Though it has a large advantage of speed, the databases are not one files.

LevelDB holds neither a read performance advantage in any scenerio over common alternatives (LSM reads fundamentally require extra work by design), or a write performance advantage for anything but very short benchmark-friendly bursts. In the meantime its worst-case performance characteristics are orders of magnitude worse than just about any alternative.

(Keep clicking "more" in my comment history for detail)

Re: UnQLite - An Embeddable NoSQL Database Engine

#15

This turned up recently on proggit too. http://www.reddit.com/r/programming/comments/1etfxi/sqlite_n... was heavily downvoted for saying its an order of magnitude faster than SQLite http://www.reddit.com/r/programming/comments/1etkix/unqlite_... raises concerns about the license, and there's a Global Lock in there too? The scripting performance gives cause for pause too.

"It furthermore states that commercial licence must be acquired for closed source applications." I love the description of the scripting language as "Turing complete" based on "JSON". That is the first time I have ever heard turing complete used to market a programming language! The scripting language is incredible, I have never seen a more verbose way to program. It is a scripting language, yet seems to combine JSON…

JX9 was what got me too. "Based on JSON..." didn't prepare me for the code samples. I can't think of a reason to invent a new language (that has to be learnt) as opposed to JavaScript or Lua.

Re: UnQLite - An Embeddable NoSQL Database Engine

#16
post #3

This would be a great replacement for the fairly awful sqlite on android - accomplishes much the same goal, but should fit into Android a lot better. Someone should write a android/java wrapper for it in the same way Google has a built in wrapper for sqlite.

In what way is SQLite awful on Android? I'm just curious what your experience has been.

Not really SQLite's fault, but Android automatically deletes corrupt SQLite files

http://code.google.com/p/android/issues/detail?id=10127

and SQLite can corrupt databases (for sure back in 2010, with some discussion on whether or not this is still an issue)

http://code.google.com/p/android/issues/detail?id=8427

Combined, this means the db file gets damaged (usually manually repairable) so the Android OS just deletes it.

Re: UnQLite - An Embeddable NoSQL Database Engine

#18

A very uncharitable reading of the features seems to suggest that this is some strange bastard child of a hashmap, a scripting language interpreter, and a JSON serializer. I'm sure it's much more than that, but one wonders where this stacks up compared to existing solutions.

It looks like they started with the scripting language and this is a tactic of trying to get it out there (we all want to see our creations adopted, etc, so an understandable desire).

Unfortunately the pitch is hitting some of the wrong notes by being a bit loose with the truth in some of the narrative (e.g. implies that Berkeley DB doesn't have concurrency or transactions, and claims of significant benchmark superiority with no benchmarks at all to back it up), not to mention the buzzword soup on a page and for a product that is targeted at buzzword-adverse developers.

Re: UnQLite - An Embeddable NoSQL Database Engine

#19

A very uncharitable reading of the features seems to suggest that this is some strange bastard child of a hashmap, a scripting language interpreter, and a JSON serializer. I'm sure it's much more than that, but one wonders where this stacks up compared to existing solutions.

It looks like the name and scripting is inspired by UnQL, which I found described in this article:

http://www.infoq.com/news/2011/08/UnQL

If that's the case, I'm surprised there's no obvious link to UnQL, so people know they're building off previous ideas. The article says Richard Hipp was planning on building a UnQLite embedded database; the website, though, says the sole developer is not Richard Hipp.

Re: UnQLite - An Embeddable NoSQL Database Engine

#20
If I wasn't going to get the benefit of my data automatically being distributed across servers, why would I use this? In many cases, NoSQL solutions seem to be a compromise that you make, giving up ACID (yes I know this has it) and other nice query features of databases and in return gaining the ability to scale to much larger amounts of data and having redundancy without needing to think about it.

In this case though, it's all embedded so I don't gain any of the benefits.

Post reply on HN