Oracle database is a relational database management system that mostly complies with ACID transaction requirements ( atomicity, consistency, isolation, durability ). It means that each database transaction will be executed in a reliable, safe and integral manner. In order to comply with ACID Oracle database software implements fairly complex and expensive (in terms of computing resources, i.e., CPU, disk, memory) set of processes like redo and undo logging, memory latching, meta data maintenance etc. that make concurrent work possible, while maintaining data integrity. Any database transaction or even SELECT statement makes relational database systems perform tremendous amounts of work behind the scene, thus making it inherently slow and resource intensive.

Oracle is trying to address scalability and performance problem in a variety of ways:

- by introducing constant performance enhancements to the query optimizer

- Oracle RAC - Real Application Clusters based scale out ( much increased complexity with little practical value in terms of performance and functionality )

- appliances ( Exa* line of products - complex, unbalanced architecture, suboptimally utilized hardware,  patched up and repackaged  software )

All these attempt still feature performance and scalability bottleneck in shape of Oracle RDBMS and its shared-nothing, or assymmetric MPP ( in case of Exadata ) architecture.

Companies dealing with millions of users, huge volumes of data and needing great performance like Google could not use proprietary RDBMSs.  They developed their own solutions, relying on utilizing commodity hardware and open source software. They developed software that can make thousands of Intel boxes behave like a single system that can process your query searching through petabytes of data  in sub-second time. This could never be accomplished if they used standard RDBMS like Oracle. RDBMSs were not designed to deal with problems that Google is facing.

Data processing technologies that originated at Google or other places ( including direct Google research descendant Hadoop,  NoSQL group of products, etc. )  parallelize work and distribute data over thousands of servers, relax ACID requirement so it now maybe becomes BASE (Basically Available, Soft state, Eventual consistency) i.e., they provide weaker consistency guarantees ( CAP theorem ), they loose relational data structure i.e. basically go back to flat files, or distributed, scalable hash tables. By relaxing, modifying or loosing some properties of RDBMs and optimizing to run on commodity hardware they were able to get  results that are good enough in terms of data quality and consistency, while achieving great performance and sufficient accuracy for very basic transactions. Ironically many of these technologies are step backwards i.e. they will end up reinventing many RDBMS features as they mature ( Hadapt - Hadoop based relational database; Hive, Hbase ).

Oracle RDBMS has completely different purpose, i.e., it is targeted for corporate/business use where complex transactions must be accurately executed. Eventually consistent paradigm does not suffice here. While Oracle database can contain huge volumes of multi-media data, its main purpose is to store and concurrently process structured data sets relatively limited in size, for a limited number of concurrent corporate/business users.

• Big Data Consolidation Enters Home Stretch as Teradata Buys Aster Data
• Yahoo! VP to Present Lessons of Big Data at Cloud Expo 2011 New York
• Pentaho #1 in Support for Big Data Platforms