RE: Top DBA needed in San Jose, CA

  • From: "Dimensional DBA" <dimensional.dba@xxxxxxxxxxx>
  • To: <iggy_fernandez@xxxxxxxxxxx>, <mckaydim@xxxxxxxxxxx>
  • Date: Mon, 18 Aug 2014 09:23:37 -0700

Amazon's setup of Oracle databases are completely based on the application
layer sharding.

 

 

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Iggy Fernandez
Sent: Monday, August 18, 2014 7:39 AM
To: mckaydim@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxx
To: mckaydim@xxxxxxxxxxx
CC: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxx
To: agonenil@xxxxxxxxx; jeremy.schneider@xxxxxxxxxxxxxx
CC: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on
behalf of Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
Sent: 18 August 2014 13:49
To: agonenil@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxx> wrote:

you didn't provide email . i assume "dmarc-noreply@xxxxxxxxxxxxx" isn't your
mail ... 

 

 

On Mon, Aug 18, 2014 at 11:48 AM, Saibabu Devabhaktuni
<dmarc-noreply@xxxxxxxxxxxxx> 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.

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 08-2014