On Fri, Mar 20, 2009 at 10:27 PM, Orlando Andico <[email protected]> wrote: >> >> oracle rac belongs to shared-everything architecture... the cache >> fusion is a global cache (distributed caching) similar to disk cache >> in a single node to delay writes... still a bottleneck when you are >> running out of memory as it needs to write to give room for incoming >> data to write when write load increases and you are having a >> scalability problem there... > > Yes, I was pointing out that the global cache allows you to delay > writes, which results in better scalability to the disk. The disk > still is a "single point of knowledge" and therefore is, yes, a > shared-all architecture.
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... >> >> naahhh... the internal communication of RAC in a separate channel >> simply shows a negative scalability when the nodes increases due to >> the fact that each node must coordinate with each other regarding to >> lock ownership and all nodes updates the same control file as well as >> data-block ownership transfer which creates a big bottleneck in the >> performance.. > > 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... >> let the index do its job (if a query has a condition) and fetch those >> data where it resides to a particular node.. thus less load to every >> disk storage on every node and much faster to get the data if you >> compare that to a shared storage... that is why google is too damn >> fast to return a search query because of a shared-nothing >> architecture... > > 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... > 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.. >> 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... The Exadata products address the three key dimensions of database I/O that can hamper data warehouse performance. • Exadata is based on a massively parallel architecture which provides more pipes to deliver more data faster between the database servers and the storage servers. • Exadata is built using wider pipes that provide extremely high bandwidth between the database servers and the storage servers. • Exadata is database aware and can ship just the data required to satisfy SQL requests resulting is less data being sent between the database servers and the storage servers. take note that exadata is based on a massively parallel architecture (MPP)... MPP is actually a shared-nothing architecture.. > The > storage nodes simply abstract the concept of storage to "smart > storage." Yes in a way it is "Federated" which is a bad word in most > places (most "federated" architectures tend to be fragile)... but in > the case of Exadata the federation and storage management is all > internal to the system so you don't have to be a rocket scientist to > build a federated database, it's pure plug-and-play (add storage nodes > on the fly for more scaling). 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... > > Like I mentioned above, there's no denying you can build a fast > shared-nothing architecture like Google has done. But is this > something an ordinary user can do? in the case of Exadata, you can (if > you have enough money). It's meaningless to compare this functionality > to MySQL when you'd basically have to build it from zero on one side, > and buy a box on the other side. 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... fooler. _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
