This thread has gone in two directions at once: first, a generic "shared-nothing" versus "shared everything" debate, and second, comparing MySQL Cluster to other things.
Since this was originally a "Oracle to MySQL migration" thread I'll try to address the MySQL cluster topic first: > if you said about rac that people dont know how to tune or configure > rac.. they same true also to people who dont know how to configure > mysql cluster... Very true. Expertise doesn't come free with any technology. > alcatel uses mysql cluster for their home location register (HLR).. > HLR is a central database that contains details of each mobile phone > subscriber that is authorized to use the gsm network.. vodafone in UK > uses mysql cluster too.. I would expect that MySQL Cluster is not a major player in the embedded telecom space. There are a lot of incumbents in there: TimesTen, SolidDB, Altibase to name a few. Ericsson, T-Mobile, China Mobile, Amdocs, Salesforce.com etc. embed TimesTen. Nokia-Siemens embeds SolidDB. SK Telecom and Samsung embed Altibase. NDB Cluster code base came from Ericsson... but they no longer use it (I guess they decided making databases was not their core business and someone else could do it better). Incidentally, if Sun acquisition by IBM pushes through, I don't know what will be the fate of MySQL Cluster, as IBM owns an existing (and better-proven in the field) IMDB in the form of SolidDB, not to mention DB2. > the mysql cluster replication provides highly availability in case one > node fails the other node will take care of that data... usually > replication took place when an update on the master server... it > propagates to a slave server and not to the rest of the nodes... This is fine, in fact part of the requirement for in-memory store is so that acknowledges from the slave happen "fast enough" to maintain throughput. The MySQL Cluster manual states (and I quote) that "In MySQL Cluster, all data nodes are kept in synchrony, and a transaction committed by any one data node is committed for all data nodes. In the event of a data node failure, all remaining data nodes remain in a consistent state. " (23.10.3) That seems like "write to one, write to all" although there is an option for setting the number of replicas. It would seem that due to the synchronous commit, write performance can't be THAT high. To be honest, the last time I checked MySQL Cluster was 3 years ago and I was not impressed. The feature set seems to be improving nicely. I think it's time I revisit MySQL Cluster. (for which I have fooler to thank...) On to the shared-all versus shared-nothing topic: > in a shared-nothing architecture... all nodes has its own disk cache > for delay writes but the writes are not pointed to a centralized > storage.. thus a higher throughput and scalability... This is fine if the workload can be cleanly partitioned. However many transactional workloads cannot be sliced-and-diced so easily. Having shared-nothing and individual buffer caches means you cannot guarantee transactional integrity across all members. For things like Google (which is bulk write from robot + many many reads) basically any read-mostly workload, this will work fine. > > Of course taken to the extreme, any shared architecture will show > > negative scalability at some point. I was talking about N where N is a > > small integer. Going from 1 node to 2, or 2 nodes to 4, will not show > > negative scalability in most cases, and Oracle isn't generally used > > for large N, regardless of what the product literature claims. > > it was claimed for enterprise environment and enterprise expected a > high performance database especially on scaling as they are paying big > bucks for this enterprise database... there is no problem on the > frontend but on the backend.... oracle knows this thus their solution > is exadata storage... As N gets large, RAC scalability for writes gets to the point of diminishing returns. Not a limitation unique to RAC, even SMP boxes suffer from this. Shared-nothing is a known scalable solution, almost all the Top500 supercomputers are MPP. But shared-nothing has been traditionally very hard use get working properly for traditional workloads. > > I'm not aware of any off-the-shelf shared-nothing architectures which > > allow you to scatter the data over multiple nodes. Except Exadata, as > > you point out. > > mysql cluster is one of it... greenplum... teradata... netezza.. etc.. > that is how shared-nothing architecture really does... Greenplum and Netezza (and DATAllegro) have tiny market share. The much-derided RAC has over 40% of the worldwide data warehousing market. So if you went for these products, you'd have a much smaller community to turn to for help. And these products (well even Exadata) aren't designed for OLTP workloads which I believe are most interesting to PLUG readers. > If we count "roll your own," such as Google does, that's not something > readily replicatable by most end-users. > let us take a look how google does... their algorithm is pretty clean > and simple... it just a one big flat file... the raw data is partition > and spread to all nodes.. another set of server farm where it holds > the one big index file that spread to all nodes on that cluster... > query begins by consulting the index file and the index file pointing > the actual data to a particular node.. the algorithm here is actually > the same with a single node database where the index file pointing the > actual data to a particular offset of a file.. I don't see Google wannabes popping up right and left if Google's implementation was that clean and simple... Google's technology is one of their competitive advantages and I don't see anyone seriously threatening them at what they do. Besides it's built for a query workload where it's permissible to lose data. Which is an important use case but not one that most of us can use. >> exadata storage cell concept scales simply because they move their >> traditional shared-everything storage like rac to shared-nothing like >> exadata storage.. your exadata storage is a shared-nothing >> architecture... now as you can see oracle starting to understand and >> reliaze how shared-nothing architecture scales... > > It is not shared-nothing, because it still is fronted by RAC. > ill cut and paste the exadata white paper here... ... > take note that exadata is based on a massively parallel architecture > (MPP)... MPP is actually a shared-nothing architecture.. RAC is shared-all, but you add Exadata storage nodes to an existing RAC instance. The Exadata storage nodes don't exist in a vacuum, they are fronted by a non-MPP engine. > but you dont realize the one who built exadata is a rocket > scientist... the same thing you dont need to build a database program > from scratch as another rocket scientist already built it for you.. > you just use it... Well I must admit that I hadn't looked at MySQL Cluster in a while, and the last time I looked at it, it was quite crude and required a lot of hackery (i.e. requires being a rocket scientist). So as-of-5.0 MySQL Cluster does seem usable without a degree in rocket science. I am curious to see though what sort of data set sizes and transactional data rates are being achieved with MySQL Cluster. There are some accounts that NDB Cluster is actually slower than MyISAM. > i dont see any point from you here... any company or a person can > build a product to sell or for free to an ordinary user.. they just > simply create a cd installation disk to automate things... with > exadata it just a finish product... It never is just about the finished product. It's also about support, help with best practices, etc. I have a bad feeling about MySQL Cluster because the last time I tried it, I got nowhere with it. Besides, a product's limitations always come out when you're already doing your non-trivial production workload, at which point, you'll be much happier if there are some people whose job it is to help you and you can yell at them. _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
