0

is there a database schema-free/less like mongodb but acid transaction support that I can use only when necessary in small parts of web application?

so, I'm building a web application, 70% it does not require a transaction, but 30% yes. My problem is that when I can query that 30%, it require data also from nosql database. I know that mongodb and others nosql database sacrificate acid transaction for high-performance, but I have opted for mongodb because it is simple nest document and array into collection and query it, and then I can scaling well. But for that 30% not work well, because I need transaction support.

So is there a dbms document oriented with acid transaction support that I can scaling out well if my web application grow in terms of access read and write operation by users?

tshepang
  • 12,111
  • 21
  • 91
  • 136
paganotti
  • 5,591
  • 8
  • 37
  • 49

4 Answers4

1

nosql databases are not typically acid compliant, but its been said that OrientDB is (someone asked about it here: Is there any NoSQL that is ACID compliant?)

...and from CraigTB's answer which quotes the nosql wiki (http://en.wikipedia.org/wiki/NoSQL):

NoSQL is a movement promoting a loosely defined class of non-relational data stores that break with a long history of relational databases and ACID guarantees.

and also:

The name was an attempt to describe the emergence of a growing number of non-relational, distributed data stores that often did not attempt to provide ACID guarantees.

and

NoSQL systems often provide weak consistency guarantees such as eventual consistency and transactions restricted to single data items, even though one can impose full ACID guarantees by adding a supplementary middleware layer.

Also, don't feel like you have to force your whole application into being nosql, facebook uses a whole handful of different database types all at once. For example, they use sql for their timeline feature, and use nosql for much of the other features

Community
  • 1
  • 1
Kristian
  • 21,204
  • 19
  • 101
  • 176
0

The only way you can support multi-document transactions against a nosql database is by managing the transaction within your app. Not an inconsequential task, especially for a distributed database. The nice part about a doc based db like Mongo is that it can help alleviate your need for transactions by grouping data within a doc (line items in orders in customer docs, for example) as it is mostly ACID for single document actions.

If you want to manage transactions for a part of your data take a look at Gigaspaces. It can be costly and it is not the simplest to implement, but it may fit your needs. It fully supports XA transactions on data within memory and then writes out to your datastore asynchronously. Basically, you operate against Gigaspaces XAP product for the tables you want transactional integrity for and everything else you hit your database directly. They even have an article on using it with Cassandra that can easily be applied to Mongo - http://blog.gigaspaces.com/cassandra-on-acid/. Not the ideal solution, but it does provide you with a transactional option over a non-transactional database.

AlexGad
  • 6,612
  • 5
  • 33
  • 45
0

I am only going to briefly answer the question.

As others say MongoDB is not fully ACID compliant and infact breaks ACID compliancy at times along with most NoSQL DBs no matter how much marketing comes out of their mouth the nature of NoSQL does break ACID.

No transaction that writes to memory is ACID compliant since memory is temporary storage so you cannot guarantee it has written to disk and replicated across your network which breaks ACID immediately for durable writes. I am not sure how Gigaspaces does this but it sounds like something I would personally not look at.

In order to be ACID you must write to disk first (maybe to two nodes in your network too?) then the DB must write back down to temporary storage, not the other way around.

Now Mongo does provide the safety of writing to disk and even multiple nodes. In PHP it provides the safe and fsync option which you can use to dictate how many nodes it should write to before the function (insert, save, update) returns true or false. So you can get write concern within your app. You can also setup your actual replica and shards to be fully consistent, by nature they are not but you can. Not only that but MongoDB has Journaling. In reality even writing to memory writes are "not durable" for 100ms (seriously how much data are you going to lose in 100ms? I bet your app is less durable than that in reality).

The difficult part comes when doing transactions and two phase commits. Most people find a way of overcoming these problems by using hashes of the document to be inserted and/or version numbers. I just did a quick Google search for a Java framework I know does supports ACID transactions and two phase commits but I am having problems finding it. If you search the user group for some they are out there and there are full explanations in the user group (I know this because I participated in some) of how to achieve rollbacks in MongoDB based upon hashes and version numbers. I should warn you however, just as in SQL, transactions are deathly slow and kind of go against the fundamentals of MongoDB.

So now you know how you can start to rely on Mongo and even have a slow transactional handler in your app for those small times you need the durable writes of many documents dependent upon each other.

So is there a dbms document oriented with acid transaction support that I can scaling out well if my web application grow in terms of access read and write operation by users?

It is dependent upon how far you are looking at scaling and I don't think anyone here can give a serious answer to that.

As for Fbs usage of other DBs. Once I lost about 5 wall posts on my wall an hour after writing them. I contacted Fb about it and asked them for a geeky explanation. They said that even though the wall post wrote to the temporary storage it failed to sync to the permanent storage. So all this talk Fb being totally ACID compliant is just talk and as Kristian says they use many DBs including NoSQL.

I hope this helps a little,

Sammaye
  • 43,242
  • 7
  • 104
  • 146
  • The original q wanted to handle multi-doc trans (if I understand correctly). That is not something ANY nosql database can handle. ACID for one doc only. Gigaspaces provides multirow 'XA' by writing to a multi-server in memory grid. Is it truly ACID? Absolutely not, because as you pointed out, on its own, it does not have durability to disk. However, that does not mean it is not an interesting solution to the need for multi-doc transactional support for Mongo - write an XA transaction to GS and then async to Mongo. Perfect? No way. But better than writing your own 2-phase commit ;) – AlexGad Aug 21 '12 at 23:44
  • @AlexGad Two phase commit is basically the same where you can multi commit say, a user and his default playlist and use verisoning to understand if both write and then rollback if not, of course this is app side so it doesn't have the durability of being on the DB server (as I said) however it is still 99% durable since the problem isn't normally the app as I have seen so many times before. You are correct it is an interesting idea but I *personally* would not look into it due non-durable writes to disk. – Sammaye Aug 22 '12 at 07:11
  • You realize it does ultimately get written to Mongo (within ms)? The big hole is if any writes to Mongo bypass GS. Having written 2PC and experienced the nasty issues associated with it and having implemented GS in other projects, I personally feel anyone who requires multidoc transactions for a nosql database are doing themselves a disservice if they write-off GS as an option. Its not a solution for every case as it is a hack, but in some cases it can wrap multidoc transactions without writing 2PC at the app level which is like having your molars extracted ;). – AlexGad Aug 22 '12 at 12:06
  • @AlexGad Yea it is 100ms and I agree it sounds interesting and writing the transctional handler on client side is a ***** but it also looks quite expensive. For a super large scale site I can see the benefit but for a medium scale site, client side code will be just as easy. Personally my perferred choice (which I didn't mention) is to do transactions to SQL when you require them and then push the data down, but it all depends on how you use transactions. Some people seem to think the whole of fb is ACID compliant so the use case comes down to your own view of what should be transactional – Sammaye Aug 22 '12 at 13:03
  • Can't argue with you on that. As I said in my initial post, it can get quite expensive. They do have a free 2 cluster 4GB implementation for small projects but the jump from free to paid is quite large. – AlexGad Aug 22 '12 at 19:05
0

ArangoDB.

Claim to have cross collection ACID transactions, JOINS, document store, graph store. But transacation should be sent "one piece".

So you can't use isolation to process business logic during transaction and still need to get a locking mechanics manualy. Shouldn't be a problem to get redis or zookeeper for pessimistic locking.

garkin
  • 458
  • 5
  • 10