Discussion
“The 'No SQL' Discussion Has Nothing to Do With SQL.”, Michael Stonebraker argues that
“blinding performance depends on removing overhead...”
NoSQL databases aka “not only SQL“ are non-relational databases, free from table format
which is used my SQL databases. In SQL we use relational database to store data in table
format logically linking each table together. The problem with that is its hard to scale the
database, second issue is to maintain relationships with table which is an overhead problem
require lot of memory and compute power. This is where NoSQL comes in the picture,
Author talks about NoSQL which comes in various types like key-value pair which stores
records as keys and payload format. These keys are identified by a distributed hash tables
which create a unique hash for every keys. Some examples are AWS has DynamoDB, Google
has Bigtable, and Azure has CosmoDB. Next type is document-style which stores in the
format of Key-Value pairs plus payload. Examples are MongoDB and CouchDB.
Author talks about two possible reason to move around these DBMS technologies:
Performance and Flexibility, and when he started his using MySQL for data storage and
found inadequate performance, he gave two options to recover from this issue First is to
Shard his data into several data storage servers which gives a hard time managing
distributed data across application. Second is to either pay big for enterprise licensing fees
for SQL DBMS or move to something other than MySQL.
In this blog, author’s data does not bound with the relational databases thus he needs
something more flexible. This discussion is more oriented towards performance side of
NoSQL which is Online Transation Processing (OLTP). Author mentions two ways to improve
OLTP.
First is Automatic Sharding of data to improve per-server OLTP performance. Either
providing scalability as nodes are added or improve performance of individual nodes.
Author believes that one should not run a DBMS that does not provide automatic Sharding
over computing nodes. Further he said Overhead associated with OLTP databases in SQL has
little to do with SQL itself. Major Overhead in OLTP SQL DBMS is communication with DBMS
Discussion
using ODBC and JDBC, to reduce back and forth communication between APP and DBMS is
to run DBMS in same address space as App.
Autor talks about a recent research paper [7] calculate OLTP overhead was divided in four
components:
1) Logging : Traditional Database writes everything twice; once to database and second
to the Logs.
2) Locking : A transaction must set a lock in lock table before accessing a record.
3) Latching : Mostly update to shared data structure is done with short-term duration
latches, which creates overhead.
4) Buffer Management : Typically Data is stored on fixed-size disk pages. When CPU call
is made to retrieve some data and data is not present on memory, can cause some
overhead there.
Features of NoSQL includes, data is distributed across multiple sites, many NoSQL systems
are disk based and contains buffer pool as well as multi-threaded architecture. Transaction is
only single record thus ACID transactions were sacrifice for performance.
At last, Author talks about a recent project [8] which removed all four overheads by
implementing open-source SQL engines that not only provides automatic Sharding but also
ACID transactions, increased programmer productivity, lower maintenance, high
performance, and data independency. Author Believes after removing all four overheads of
ACID transactions, multi-threading, and disk management, SQL will be Unbeatable.
Reference:
[1] [Link]
do-with-sql/fulltext
[2] [Link]
[3] [Link] (amazing video explaining
NOSQL)
[4] [Link]
[5] [Link]
[6] [Link]
[7] [Link]
[8] S. Harizopoulos, et. al., “Through the Looking Glass, and What We Found There,”
Proc. 2008 SIGMOD Conference, Vancouver, B.C., June 2008
Discussion
[9] M. Stonebraker, et. al., “The End of an Architectural Era (It’s Time for a Complete
Rewrite),” Proc 2007 VLDB Conference, Vienna, Austria, Sept. 2007