4

It seems to me that, at the end of the day, most NoSQL databases are at their core key/value stores, which means one should be able to build a layer which could be NoSQL database agnostic.

That layer would only use CRUD operations (put, set, delete), but would expose more advanced features, and you'd be able to switch with minimal effort the underlying DB whether it's Mongo, Redis, Cassandra, etc.

Would building something like this have value to many people, and does it already exist?

Thanks

Community
  • 1
  • 1
Jamona Mican
  • 1,574
  • 1
  • 23
  • 54

5 Answers5

3

NuoDB is an elastically scalable SQL/ACID database that uses a Key/Value model for storage. It runs on top of Amazon S3 today (as well as standard file systems) and could support any KV store in principle. For the moment it's access method is SQL, but the system could readily support other data access languages and methods if that is a common requirement.

Barry Morris, NuoDB Inc.

Barry Morris
  • 31
  • 1
2

There's kundera and DataNucleus

vivek mishra
  • 1,162
  • 8
  • 16
Arnon Rotem-Gal-Oz
  • 25,469
  • 3
  • 45
  • 68
2

UnQL means Unstructured Query Language. It's an open query language for JSON, semi-structured and document databases.

nicerobot
  • 9,145
  • 6
  • 42
  • 44
  • 1
    Interesting. Seems like a flexible SQL counterpart, without JOINs could help document-based k/v store adoption, and move the compatibility onus to the DB developers themselves. – Jamona Mican Dec 28 '11 at 17:05
1

It's next to impossible to build such thing.

As a thought experiment, I suggest that you take, for example, Redis, MongoDB and Cassandra, and design an API of such layer.

These NoSQL solutions have drastically different characteristics and they serve different purposes. Trying to build a common API for them is like building a common API for SQL database, spreadsheet document, plain text file and gmail.

While you can certainly come up with something, it will completely pointless.

Different needs call for different tools.

Sergio Tulentsev
  • 226,338
  • 43
  • 373
  • 367
  • I don't think, the OP wants to build a SQL layer on top of NoSQL dbs. He just wants to build some kind of API for CRUD operations on top. – Jan Dec 28 '11 at 10:41
  • I meant, if you limit yourself to basic CRUD, you're doing something wrong. This turns MongoDB into a memcache with persistence. Same for Redis. You won't be able to use all the power of these solutions. What's the point? – Sergio Tulentsev Dec 28 '11 at 10:44
  • 2
    @SergeiTulentsev I partly agree with "you're doing it wrong" but there are also very many problems that can be solved with a CRUD-like abstraction that don't require the specific capabilities of any particular NoDB yet still benefit from NoSQL over Relational. In the end, these are all key-value stores. Each NoDB's drivers can 1) optimize CRUD to suit their DB, and 2) provide a means to entend the API so it can be _easier_ to switch between NoDBs than it is currently. Also, such an abstraction in no way restricts direct access to a NoDB driver for the use-cases that require it. – nicerobot Dec 28 '11 at 13:52
  • @nicerobot: wait, your app ceases being "portable" at the same instant when you start using underlying driver directly (let's say, to employ hash commands of Redis). Now you can't just swap storage from under the app. I've yet to find a use case for this. – Sergio Tulentsev Dec 28 '11 at 14:07
  • 3
    basically what nicerobot said. At the beginning of a project you may be happy with just CRUD and not want to commit to any one NoSQL k/v store as they are all quite young still. Eventually, if you feel any single one has the best performance or the best 'specific' features, you may decide to stick with that one and stray away from the CRUD interface. – Jamona Mican Dec 28 '11 at 16:51
  • @SergeiTulentsev All i'm talking about is: imagine you have CRUD working generically but decide to focus on Redis. Ideally, you'll write wrappers over the direct Redis driver's API to accomplish the specifics you need. Now, if you then decide to try another DB, you can implement the same wrappers for the new driver. On the other hand, if the abstraction layer were extensible, these specifics could be implemented generically to appear as part of the abstraction rather than as customized wrappers around the abstraction layer. – nicerobot Dec 28 '11 at 20:31
  • @nicerobot: I understand what you're saying, but don't accept it (well, maybe a little bit). Perhaps, I'm just being ignorant. – Sergio Tulentsev Dec 28 '11 at 20:51
  • Also, please note that such library didn't show up yet in this topic. Maybe it doesn't exist. I think, it supports my point :-) – Sergio Tulentsev Dec 28 '11 at 20:54
  • @SergeiTulentsev Not "ignorant", hard-headed :P j/k And I understand your position, but I think it's only a matter of time. NoSQL is still relatively new. ODBC/JDBC didn't develop along with relational DBs and it took quite a long time to improve on JDBC with JPA and JDO. I'm certain it will happen and i'm certain abstractions will be heavily used but i'm also certain there are plenty of cases where it'll pay to lock into a single driver. – nicerobot Dec 29 '11 at 00:37
0

PlayOrm is another solution that is built on cassandra but has a pluggable interface for hbase, mongodb, etc. etc. 20/30 years ago they said the same thing about RDBMS, but more and more the featuresets converged. I suspect you will see alot of that in nosql database's as well as they adopt each other's feature sets.

currently, they have vastly different feature sets but at the core there is a set of operations that is very very similar.

PlayOrm actually builds it's query language which works on any noSQL provider as well, so it's S-SQL scalable SQL can work with cassandra, hadoop, etc. etc.

later, Dean

Dean Hiller
  • 19,235
  • 25
  • 129
  • 212