by Tuyen H
In the article “SQL Databases v. NoSQL Databases” Michael Stonebraker writes about why businesses should switch their database to NoSQL from SQL. People argue that they select NoSQL technology because of two reasons: Performance and Flexibility. For performance, the author says over time SQL performance will be inadequate and we need to pay huge licensing fees for enterprise SQL database management system (DBMS) such as Oracle, IBM, or HP. For flexibility, people argue that, they cannot be bound by the structure of a Relational database management system (RDBMS), so they need something more flexibility. The answer for those questions is NoSQL. Michael also talks about the reasons why database performance becomes slow down. First, in traditional databases, everything is recorded twice in database and log (Logging). Second, when a record is called, it is locked in the lock table (Locking). Third, “Updates to shared data structures, such as B-trees, the lock table, and resource tables, must be done carefully in a multithreaded environment.” Finally, traditional database uses buffer manages which cached in memory an any given time. This is one of overhead intensive. Therefore, if we can eliminate these overhead our databases performance will speed up.
This article is absolutely related to our class topic because it talks about SQL database management system. It also talks about how to improve our databases performance. I was very interested on the four overhead components that make our database slow down. The author explains very clear on those points. At work, I write stored procedures every day, but I have not really understood that stored procedures help improving our database performance.
In this article, Michael said that NoSQL can help solving the overhead problems but he did not clearly explain how. I really want to research more about that because if we can solve those overhead issues, our database performance will improve a lot.
Stonebraker, M. (2010). SQL Databases v. NoSQL Databases. Communications Of The ACM, 53(4), 10-11.