On Fri, Mar 20, 2009 at 9:21 PM, fooler mail <[email protected]> wrote: > On Fri, Mar 20, 2009 at 6:48 PM, Orlando Andico <[email protected]> wrote: >> Oracle is not exactly shared-everything. While the storage is indeed a >> single point of bottleneck, the existence of Cache Fusion means that >> you will not bottleneck the disk right away. > > 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. >> As for lock contention... that's why in a correctly-configured RAC >> environment you MUST use the Partitioning option as well (that's an >> additional $10K+ / CPU, ka-ching!) and partition your tables properly >> so that you won't have lock contention. > > no matter how you spend more money to improve lock contention.. there > is always a lock contention in a shared-everything architecture simply > because two or more nodes can still access the same block on that > partition.. > >> To simply say "in real implementatons RAC shows negative scalability" >> is a very common misconception and indeed, people see this in practice >> but it's because they don't know how to tune RAC. > > 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. >> Shared-nothing is very challenging simply because you don't have a >> single system view. > > you do... > >> Most people don't have to have to aggregate their >> data from all over the place just to do a single query. > > 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. If we count "roll your own," such as Google does, that's not something readily replicatable by most end-users. >> In any case, in Oracle 11g the new Exadata storage cell concept allows >> linear scalability to very many nodes and removes the shared-storage >> requirement that RAC has (traditionally) had. > > 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. 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). 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. -- Orlando Andico +63.2.976.8659 | +63.920.903.0335 _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
