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?
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,