Day One: Disruptive Innovation
Day Two: Requirements and Assumptions
Day Three: Functional Segmentation
Day Four: Sharding
Day Five: Replication and Eventual Consistency
Day Six: The False Premise of NoSQL
Day Seven: Schemaless Design
Day Eight: Oracle NoSQL Database
Day Nine: NoSQL Taxonomy
Day Ten: Big Data
Day Eleven: Mistakes of the relational camp
Day Twelve: Concluding Remarks
On the twelfth day of Christmas, my true love gave to me
Twelve drummers drumming.
The relational camp put productivity, ease-of-use, and logical elegance front and center. However, the mistakes and misconceptions of the relational camp prevent mainstream database management systems from achieving the performance levels required by modern applications. For example, Dr. Codd forbade nested relations (a.k.a.unnormalized relations) and mainstream database management systems equate the normalized set with the stored set.
The NoSQL camp on the other hand put performance, scalability, and reliability front and center. Understandably the NoSQL camp could not see past the…
View original post 390 more words
On the ninth day of Christmas, my true love gave to me
Nine ladies dancing.
NoSQL databases can be classified into the following categories:
- Key-value stores: The archetype is Amazon Dynamo of which DynamoDB is the commercial successor. Key-value stores basically allow applications to “put” and “get” values but each product has differentiators. For example, DynamoDB supports “tables” (namespaces) while Oracle NoSQL Database offers “major” and “minor” key paths.
- Column-family stores: Column-family stores allow data associated with a single key to be spread over multiple storage nodes. Each storage node only stores a subset of the data associated with the key; hence the name “column-family.” A key is therefore composed of a “row key” and a “column key” in a manner analogous to the major and minor key paths of Oracle NoSQL Database.
- Graph databases: Graph databases are non-relational databases that use graph concepts such as nodes and edges to solve certain classes of problems: for example; the shortest route between two towns on a map. The concepts of functional segmentation, sharding, replication, eventual consistency, and schemaless design do not apply to graph databases so I will not discuss graph databases.
NoSQL products are numerous and rapidly evolving. There is a crying need for a continuously updated encyclopedia of NoSQL products but none exists. There is a crying need for an independent benchmarking organization but none exists. My best advice is to do a proof of concept (POC) as well as a PSR (Performance Scalability Reliability) test before committing to using a NoSQL product. Back in the day, in 1985 to be precise, Dr. Codd had words of advice for those who were debating between the new relational products and the established pre-relational products of his day. The advice is as solid today as it was in Dr. Codd’s day.
“Any buyer confronted with the decision of which DBMS to acquire should weigh three factors heavily.
The first factor is the buyer’s performance requirements, often expressed in terms of the number of transactions that must be executed per second. The average complexity of each transaction is also an important consideration. Only if the performance requirements are extremely severe should buyers rule out present relational DBMS products on this basis. Even then buyers should design performance tests of their own, rather than rely on vendor-designed tests or vendor-declared strategies. [emphasis added]
The second factor is reduced costs for developing new databases and new application programs …
The third factor is protecting future investments in application programs by acquiring a DBMS with a solid theoretical foundation …
In every case, a relational DBMS wins on factors two and three. In many cases, it can win on factor one also—in spite of all the myths about performance.”
—An Evaluation Scheme for Database Management Systems that are claimed to be Relational
Solve the Oracle Database murder mystery and win a free ticket for yourself and a friend to the NoCOUG conference
Here are the solutions that have received so far. The last one is plausible but doesn’t explain the graceful shutdown of nine databases using SHUTDOWN IMMEDIATE. The murder mystery is still unsolved.
- “From digits 10 if 1 falls, remains is 0 (ZERO).”
- “It’s a Cascade delete issue … If Main record is deleted, then any corresponding foreign records too would be deleted.”
- “Oracle does not keep any spot for the “Accidental” fall of bottles. If one bottle can fall accidently, then all ten bottles can also fall accidently. There should not be any scope for accidental falls.”
- “Perhaps Jack connected to a CDB and since he didn’t specify a PDB name, the commands impacted all PDBs contained therein?”
- “Since STARTUP FORCE does an SHUTDOWN ABORT/STARTUP—did he do it on a ASM Instance (NetApp storage) shared by 9 other running instances? There can only be one ASM instance per server. Other instances crashed and were restarted automatically with Oracle Restart (Oracle Grid Infrastructure)?”
You may remember this children’s song from kindergarten or you can listen to this YouTube video:
“Ten green bottles hanging on the wall
Ten green bottles hanging on the wall
And if one green bottle should accidentally fall
There’ll be nine green bottles hanging on the wall.”
In this Oracle Database murder mystery, there were no green bottles left hanging on the wall after the first bottle fell. Send your solution to firstname.lastname@example.org and receive a free ticket for yourself and a friend to the NoCOUG conference on Thursday, August 15 featuring performance guru Craig Shallahamer, a full track of Oracle Database 12c presentations, and alternative technology presentations on MySQL, NoSQL, and Big Data. Click here to review the detailed agenda.
It was a beautiful spring day. Popcorn was popping on the apricot tree. What does this have to do with databases? Nothing, but I’m trying to write…
View original post 448 more words
It may have sounded like I have NoSQL envy but the point I was trying to make is that Amazon had an opportunity to kick the relational model up a notch but did not rise to the occasion. Amazon could have eaten its cake—extreme performance, extreme scalability, and extreme availability for important use cases such as shopping carts—and had it too—the relational model with all its wonderful declarative power. My keynote address at the summer conference of the Northern California Oracle Users Group on August 15 is titled “Soul-Searching for the Relational Movement: Why NoSQL and Big Data Have Momentum.” The perceived deficiencies of relational technology are actually a result of deliberate choices made by the relational movement in its early years. NoSQL and Big Data technologies would not have gained popularity if they did not excel at certain tasks that relational implementations cannot handle well. Instead of pretending that the new problems do not exist, the relational movement needs to do some serious soul-searching. The full conference agenda is at http://www.nocoug.org/rsvp.html. Some guest passes are available. Please contact me at email@example.com if you would like a guest pass.
See also : What’s so sacred about relational anyway?
The opinions of relational theoreticians C. J. Date and Hugh Darwen about SQL are well known but they have not previously commented on the NoSQL phenomenon and so their interview in the latest issue of the NoCOUG Journal—the official publication of the Northern California Oracle Users group—makes for interesting reading. In my opinion, their comments are right on the mark even though Date admits that he knows almost nothing about NoSQL products.
In discussing Amazon Dynamo—the forerunner of the NoSQL movement—and those that came after it, Date and Darwen make these astute observations:
“Developers tend to be more concerned with convenience in database definition and updating than with the ease of deriving useful and reliable information from the database.”—Darwen
“If there’s a suggestion that Amazon’s various disaster scenarios, regarding tornados and the rest, are somehow more of…
View original post 2,578 more words
Books to the ceiling, Books to the sky,
My pile of books is a mile high.
How I love them! How I need them!
I’ll have a long beard by the time I read them”
—Lobel, Arnold. Whiskers and Rhymes. William Morrow & Co, 1988.
To celebrate Independence Day, I freed myself from several hundred pounds of old books and manuals, most in new condition, that I had accumulated over the years but never read. Here is a picture of me with some of the books before they went into the recyling bin. A complete set of Ingres 6.4 manuals still in shrink wrap also went into the recycling bin. You can clearly see some of them in the middle of the pile if you click on the picture and zoom in.
The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.
Here’s an excerpt:
The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 28,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 10 sold-out performances for that many people to see it.
A tiny slip can lead to big delays. Late yesterday evening, I had to go from the Courtyard in Foster City to the Marriott in San Mateo, a distance of only 3.3 miles according to Google Maps (http://g.co/maps/2bry9). I made one wrong turn in the dark and the 3.3 mile trip suddenly ballooned into a 22.8 mile trip (http://g.co/maps/ae7sq). Zoom out a bit in Google Maps to get a better picture. Not funny, if I only say so myself.
Notes to self for the next major production change:
- Entertain the team with the above anecdote.
- Check if we are using an SOP (Standard Operating Procedure).
- Check if the person executing the SOP has practiced it.
- Check if there is ample slack time in the change window.