RE: Top DBA needed in San Jose, CA
Date: Mon, 18 Aug 2014 09:23:37 -0700
Message-ID: <013001cfbb00$c411d1d0$4c357570$_at_comcast.net>
Amazon's setup of Oracle databases are completely based on the application layer sharding.
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Iggy Fernandez
Sent: Monday, August 18, 2014 7:39 AM
To: mckaydim_at_aston.ac.uk
Cc: oracle-l_at_freelists.org
Subject: RE: Top DBA needed in San Jose, CA
amihay found this great link
http://blog.foundationdb.com/7-things-that-make-google-f1-and-the-foundation db-sql-layer-so-strikingly-similar
From: iggy_fernandez_at_hotmail.com
To: mckaydim_at_aston.ac.uk
CC: oracle-l_at_freelists.org
Subject: RE: Top DBA needed in San Jose, CA
Date: Mon, 18 Aug 2014 07:16:59 -0700
re: Is anyone actually aware of any companies who are sharding in Oracle (as the spec mentions)?
Oracle does not have inbuilt support for sharding. So if you believe in sharding, you have to do it yourself. eBay was one of the pioneers of do-it-yourself sharding which explains why it is mentioned in the job spec. eBay's approach is public knowledge due to the presentations of Randy Shoup, one of the architects of the approach.
<shameless plug>
For more interesting reading, check my ODTUG paper "NoSQL and Big Data for
the Oracle professional" written from a relational-centric point of view.
See
http://iggyfernandez.wordpress.com/2014/06/28/nosql-and-big-data-for-the-ora
cle-professional/. As you will see in the paper, I appreciate the strengths
of the new paradigm, disagree with the conclusion that relational cannot
scale, and believe that SQL needs a lot of improvement and that the
relational camp made fundamental mistakes over the years.
</shameless plug>
If you don't have the energy to read a 30 page paper (15 pages excluding the code demonstrations), here's a short explanation of sharding.
Sharding means:
(1) equi-partitioning of a hierarchical schema on a common key (think
multi-level reference partitioning or composite keys in which every table in
the hierarchy includes the PK of its parent). The trivial case is a single
table.
(2) distribution of these equi-partitions on independent databases
(3) replication of the equi-partitions for reliability. the replication is
aysnchronous which is what "eventual consistency" is all about. also support
for movement of equi-partitions when new servers are added for extra
througput.
(3) application support to hit the right partition (Oracle 7 partitioned
views is an option if you don't mind an extra hop)
Why would anybody consider sharding: One of the new paradigm is "functional decomposition" in which the monolithic enterprise schema is split into small services (each of which is a single table or a hierarchy of tables). This avoids a single point of failure and permits sharding which is the newly popular technique for scaling and reliability. Another new paradigm is key-value access where the "value" can be a document i.e. a collapsed version of all the data relating to a single ancestor in the hierarchical schema.
On the subject of whether relational can scale, also read the Google F1 paper published late last year. Here are some great quotes from that paper.
http://research.google.com/pubs/pub41344.html
In recent years, conventional wisdom in the engineering
community has been that if you need a highly scalable, high-
throughput data store, the only viable option is to use a
NoSQL key/value store, and to work around the lack of
ACID transactional guarantees and the lack of conveniences
like secondary indexes, SQL, and so on. When we sought
a replacement for Google's MySQL data store for the Ad-
Words product, that option was simply not feasible: the
complexity of dealing with a non-ACID data store in ev-
ery part of our business logic would be too great, and there
was simply no way our business could function without SQL
queries. Instead of going NoSQL, we built F1, a distributed
relational database system that combines high availability,
the throughput and scalability of NoSQL systems, and the
functionality, usability and consistency of traditional re-
lational databases, including ACID transactions and SQL
queries.
Google's core AdWords business is now running com-
pletely on F1. F1 provides the SQL database functionality
that our developers are used to and our business requires.
Unlike our MySQL solution, F1 is trivial to scale up by
simply adding machines.
From: mckaydim_at_aston.ac.uk
To: agonenil_at_gmail.com; jeremy.schneider_at_ardentperf.com
CC: oracle-l_at_freelists.org
Subject: RE: Top DBA needed in San Jose, CA
Date: Mon, 18 Aug 2014 13:44:16 +0000
Is anyone actually aware of any companies who are sharding in Oracle (as the spec mentions)?
Regards,
Mike
From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on
behalf of Jeremy Schneider <jeremy.schneider_at_ardentperf.com>
Sent: 18 August 2014 13:49
To: agonenil_at_gmail.com
Cc: oracle-l_at_freelists.org
Subject: Re: Top DBA needed in San Jose, CA
Stupid yahoo, breaking every mailing list on the internet with their dmarc nonsense.
His email address is in a comment in the from field, but you might have to "view source" to see it. It's saibabu_d at yahoo.
-J
-- <http://about.me/jeremy_schneider> http://about.me/jeremy_schneider On Mon, Aug 18, 2014 at 5:12 AM, amihay gonen <agonenil_at_gmail.com> wrote: you didn't provide email . i assume "dmarc-noreply_at_freelists.org" isn't your mail ... On Mon, Aug 18, 2014 at 11:48 AM, Saibabu Devabhaktuni <dmarc-noreply_at_freelists.org> wrote: Sorry for the SPAM. Since it is getting extremely difficult to find top Oracle DBA's/Architect's, I'm posting it here (I acknowledge that this may not be the appropriate forum for this). Requirements: Well versed with all aspects of Oracle database, internals, architecture. Proven track record of solving HA, scalability, and most complex performance problems. Very good understanding of full stack (system, storage, networking) and database applications. Very good understanding of distributed architecture and NoSql databases. Must use command line (No UI tools) and hands on. This person is expected to represent the team, drive next generation database architecture ( Active/Active databases, sharding, Active/Active data centers, etc) and also drive vendor's road map (Oracle and NoSql vendors). If you are not interested, appreciate any referrals. Thanks, Sai. -- http://www.freelists.org/webpage/oracle-lReceived on Mon Aug 18 2014 - 18:23:37 CEST