 |
 |
|
|
03.30.10 Comparing NoSQL And RDBMS For Large Database Structure  By Mike KavisThe last few weeks I have witnessed a ton of passionate debate about what is better, NoSQL or RDBMS. It almost sounds like a religious battle between Windows and Mac fan-boys. To me this is like arguing that a hammer is better than a screw driver. If you need to pound a nail, I'll take the hammer. If you want to turn a screw, I'll take the screw driver. First, here is a little history on how we got here. As telecommunications and storage costs dropped due to advancements in those technologies, it became more feasible to store larger amounts of data than ever before. This led to marketers investing heavily in targeted, one-to-one marketing in order to better understand and influence potential consumers of goods and services. As the databases grew larger, the queries started taking longer and longer. Eventually, engineers started looking for better solutions because relational databases (RDBMS) where not able to keep up with the demand. RDBMS Relational databases are great for enforcing data integrity. They are the tool of choice for online transaction processing (OLTP) applications like data entry systems or on-line ordering applications. RDBMS requires that data is normalized so that it can provide quality results and prevent orphan records and duplicates. It uses primary and secondary keys and indexes to allow queries to quickly retrieve data. But all of the good intentions that the RDBMS has for ensuring data integrity comes with a cost. Normalizing data requires more tables, which requires more table joins, thus requiring more keys and indexes. As databases start to grow into the terabytes, performance starts to significantly fall off. Often, hardware is thrown at the problem which can be expensive both from a capital standpoint and from an ongoing maintenance and support standpoint. So many data architects moved to denormalized data structures to solve the problem. With denormalized data structures, extremely large databases are extracted and flattened and put into structures like a star schema for faster retrieval (see diagram below). 
Continue reading this article. About the Author: Mike Kavis is a veteran Chief Architect with over 23 years of IT experience including distributed computing, SOA, BPM, data warehouse, business intelligence, and enterprise architecture. Read Mike's blog at Enterprise Initiatives. |
|
| ||
| --
SQLProNews is an iEntry, Inc. publication -- iEntry, Inc. 2549 Richmond Rd. Lexington KY, 40509 2010 iEntry, Inc. All Rights Reserved Privacy Policy Legal advertising info | news headlines | free newsletters | comments/feedback | submit article |
SQLproNews is brought to you by: