I think some folks are missing the point of being able to scale up when needed by just changing the connection string. If you are trying to prove a big data concept with small data, this might be a cheaper path. Now, if there were just standards for NoSQL query interfaces, this might be 100% true...
UnQLite - An Embeddable NoSQL Database Engine
81–88 of 88 posts
Re: UnQLite - An Embeddable NoSQL Database Engine
#82I think some folks are missing the point of being able to scale up when needed by just changing the connection string. If you are trying to prove a big data concept with small data, this might be a cheaper path. Now, if there were just standards for NoSQL query interfaces, this might be 100% true...
That's just it. Since it uses a specific scripting language, if you use it for anything more than direct CRUD operations, you very well may need to do quite a bit more than change the connection string. SQLite has less of a problem with this because SQL is standardized (but of course all the RDBMS have their variants).
It's unfortunate that it's called UnQLite. Richard Hipp, the creator of SQLite is now involved with the UnQL specification[1], which looks unrelated to this. In fact, there's an interview where Hipp states his plans to make an UnQlite[2], which makes this, intentional or not, a namespace grab.
Re: UnQLite - An Embeddable NoSQL Database Engine
#83Not that I am envious for the karma, but I wonder why this was not merged into my exactly identical submission 1 hour earlier ( https://news.ycombinator.com/item?id=5749969 ) -- afaict there was no ?repost or similar stunt ...
From the markup, that submission has a trailing slash while this one does not. This is one of few ways two URLs can differ but cannot ever point at separate resources, so more clever URL handling would have noticed it's a dup.
Re: UnQLite - An Embeddable NoSQL Database Engine
#84As a hacker/tinkerer type programmer I can understand why it might be fun to build something like this. All of the data structure fun with none of the distributed difficulty! NoSQL! I can even build in that cool new language I've been designing in my head! But like everyone else I'm straining to see a use case. "Serverless" NoSQL? If you've got something small enough that you want an embedded datastore, why use a NoS…
When I was at Singly working on the locker project, this was actually the absolute perfect solution to how we wanted to store data (it just wasn't available then.) We wanted to store all the raw JSON that was coming down the pipe from various sources (Facebook, Twitter, etc.) and wanted it all to be queryable. Also, since each user's data was completely isolated, having a tiny embeddable solution made a lot more sense vs. firing up a MongoDB or something similar for every user.
Re: UnQLite - An Embeddable NoSQL Database Engine
#85Nice, I'm currently using SQLite for key value storage, because there aren't better light options afaik. Python shelve module is totally useless with multi gigabyte tables and millions of keys.
Perhaps a little tangential, but that reminds me I wrote a SQLite interface with a shelf-like API, for when I wanted incredibly simple data storage which may grow more complex and relational later:
from sqliteshelf import SQLiteShelf
d = SQLiteShelf("filename.sdb", "tablename")
# now use d like any other dictionary, but this one has
# persistent storage
Re: UnQLite - An Embeddable NoSQL Database Engine
#86I would love an embeddable nosql database engine but this isn't it. I'm looking for something like MongoDB but embeddable. RaptorDB comes close but it doesn't have full support for Mono yet. https://raptordb.codeplex.com/ Can anyone recommend one?
https://github.com/Softmotions/ejdb exactly what you wanted.
Looks great! Unfortunately there is no love for .net. :(
Re: UnQLite - An Embeddable NoSQL Database Engine
#87It doesn't explain the advantages over all the other dbm alternatives: http://en.wikipedia.org/wiki/Dbm#Successors I'm yet to see a good replacement to Kyoto cabinet both in terms of ease of use and performance. I feel it'd be better energy to pick up kyoto cabinet and maintain it than re-write something from scratch.
Isn't Kyoto Cabinet GPL licensed though which makes it less useful for embedding?
Never thought of this... It turns out it is dual licensed:
Although I'm not sure how difficult it would be to get a license, the author now works for google and doesn't seem to answer to that email (when asking technical question anyway - offering money might get a different reaction).