Does a NoSQL database have better HA traits than Oracle with two-way replication for a medium (100 GB) database?

[tza...@hotmail.com]

We are designing an e-commerce web site that will sell about 20,000
train tickets per day(about 150,00 transactions per day). a major
requirement is High Availability(99.999%).
Many people tell me I should go NoSQL way.
From what I understand - NoSQL DBs implement active-active replication
for HA just like regular relational DBs, so they are no better than
e.g. Oracle with replicatoin .
Is there something special about NoSQL databases that make it more
resilient than relational + active-active replication ?

Thanks, Tzahi

[Emin Gun Sirer]

Hi Tzahi,

The answer you're looking for would be "performance and scale" but
this application does not sound sufficiently demanding to warrant a
switch to NoSQL. Can you clarify the transaction rate? You said both
20,000 xactions/day and 150 xactions/day in the same message. Assuming
the higher number is correct, and further assuming that all those
sales take place within an 8 hour period, this is still a system that
will perform about 1 xaction/second.

Anything, even a klunky RDBMS setup, should be able to serve that.
There should be no need for you to explore the NoSQL route, and I say
this as someone with a very fast NoSQL system that I would like to see
used (HyperDex, http://hyperdex.org).

Having said that, I've seen many database installations that have had
difficulty even with such low rates. So my request on behalf of
everyone here is to report back on your experience. I'd be especially
curious about your average transaction latency and the variance of
that latency. NoSQL stores, besides being fast, usually provide
predictable latencies, with small variance.

Hope this helps,
- egs

> --
> You received this message because you are subscribed to the Google Groups "NOSQL" group.
> To post to this group, send email to nosql-di...@googlegroups.com.
> To unsubscribe from this group, send email to nosql-discussi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nosql-discussion?hl=en.
>

[Georges DICK]

I think you should find an answer here :  http://en.wikipedia.org/wiki/CAP_theorem 

In short : NoSQL DB can offer better availability, because they can be "Partition Tolerant"... but at the cost of loosing the Consistency (one of the biggest strength of RDBMS).

BTW, for 150000 transactions per day, on a train ticket selling platform, IMHO you shouldn't make the sacrifice of Consistency, and you don't have to : even MySQL can handle this !

2012/3/7 tza...@hotmail.com <tza...@hotmail.com>

--
You received this message because you are subscribed to the Google Groups "NOSQL" group.
To post to this group, send email to nosql-di...@googlegroups.com.
To unsubscribe from this group, send email to nosql-discussi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nosql-discussion?hl=en.

--
Cordialement,

Georges DICK
email geo...@monaco.net
http://georgesdick.com

[Winston Pacheco Junior]

I realy don't understand this "loosing the consistency" thing in this case. Not necesserely you'll loose your consistency by using NoSQL DB.

In Tzahi case he need to know if the data is or isn't relational (to justify if he need a nosqldb). If the data isn't relational or is a little bit relational I think he can use a NoSQL DB without problem and without loose consistency.

In his case I think he will cut the P (of the CAP theorem), because he want only replication, not Partitioning and probably will achieve his goal.

2012/3/7 Georges DICK <george...@gmail.com>

[Georges DICK]

As the question is about better availability and replication, I answered that a better availability than the one offered by RDBMS can only be achieved through partition tolerance (of course, assuming that the application connected to the datastore is replicated on a large number of nodes).

But : in this case (20,000 train tickets per day) I fully agreed in advance that there is no need for this : I'm pretty sure that a couple of DB servers is more than enough, even using only one master, and routing transactions to a slave (or "new master") only in a crash event case.

My DB architecture would be based on two MySQL servers, a master and a slave.

BTW, Tzahi, if you want to use a NoSQL DB, I think that a document oriented one (like MongoDB) could be a choice that makes sense, and you won't loose on consistency if you set a master/slave replication.

2012/3/7 Winston Pacheco Junior <winston...@gmail.com>

[tzahij]

Thanks so much to all of you for the answers - this is most helpful. I feel you gave me the best advice money cannot buy :-)

as for the transactions discrepency - there are 20,000 write (purchase) transactions, and 130,000 read transactions (plan rout, etc).

Thanks so much again

[Joe Scanlon]

Tzahi - 

You have just described two completely different scenarios - commerce and routing. I agree with the general consensus here - you don't need a NOSQL db for your transactions, however, you may want to consider a NOSQL graph db for your routing application as astar and djikstra are very easy to plan and implement with graphs.  Take a quick peek at neo4j if you want more info.

Joe

--

You received this message because you are subscribed to the Google Groups "NOSQL" group.

To view this discussion on the web visit https://groups.google.com/d/msg/nosql-discussion/-/QYkLwnr_87gJ.

To post to this group, send email to nosql-di...@googlegroups.com.
To unsubscribe from this group, send email to nosql-discussi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nosql-discussion?hl=en.

--
Joe Scanlon

jsca...@element115.net

Google Voice number:  (941) 404-5630

Mobile: 603 459 3242

CONFIDENTIALITY NOTICE: This email message (including attachments) contains information which may be confidential and/or legally privileged. Unless you are the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message or from any attachments that were sent with this email, and If you have received this email message in error, please advise the sender by email, and delete the message. Unauthorized disclosure and/or use of information contained in this email may result in civil and criminal liability.

[K.S. Bhaskar]

While the CAP theorem says that you have to pick any two of Consistency, Availability and Partition tolerance, in practice, real world applications must pick Availability and Partition tolerance.  You can't avoid Partition tolerance - systems and networks that don't fail have not been built yet.  As a practical matter, you can't avoid Availability either - if you can afford to have your application not be available... there are easier ways than building distributed applications to make them not Available.

So, real world applications are AP, and, depending on business requirements implement eventual Consistency in different ways.

As the platform for FIS Profile (http://fis-profile.com), the database I manage, FIS GT.M (http://fis-gtm.com) is the system of record for the two of the largest real time core banking applications that I know of that are in daily production anywhere in the world.  It implements ACID transaction processing: the largest systems have on the order of 10,000 concurrent users and channels, scaling to thousands of online transactions per second each with full ACID properties, against aggregate databases of a few TB, all on a single originating primary instance.  As real time core banking requires strong serialization, it is easier to make serialization decisions centrally on a single instance, with real time replication to as many as 16 replicating secondary instances, each of which can replicate to 16 for 256 tertiary instances, and so on (in practice, three instances seem to be enough for most enterprises' risk tolerance).  In the event the originating primary goes down, any of the other instances can step in.

For our requirements, restoring Consistency after a Partition means not only making sure that all instances have the same state, but also restoring the same path through state space (e.g., for audit purposes).  I have blogged about this at http://ksbhaskar.blogspot.com/2011/03/eventual-consistency-vs-eventual.html and http://ksbhaskar.blogspot.com/2011/04/maintaining-eventual-path-consistency.html

For anyone who wants detail, there is a lot of it in the Database Replication Chapter of the GT.M Administration and Operations Guide.  To access all GT.M user documentation, go to http://fis-gtm.com and click on the User Documentation tab.

Regards

-- Bhaskar

ks dot bhaskar at fisglobal dot com <-- send e-mail here

--

GT.M - Rock solid. Lightning fast. Secure. No compromises.