How to Choose Be­tween an RDBMS and a NoSQL Data­base

NoSQL data­bases dis­rupted the or­derly world of re­la­tional data­base man­age­ment sys­tems (RDBMS). These data­bases of­fered tremen­dous scope for scal­ing, econ­omy and flex­i­bil­ity, com­pared to the rigid­ity of RDBMSs. How­ever, in a world over­flow­ing with data, bo

OpenSource For You - - Contents -

In the planet of data­base tech­nol­ogy, there are two main types of data­bases: SQL and NoSQL—or, re­la­tional data­bases and non-re­la­tional data­bases. The dif­fer­ences are mainly in how they’re built, the type of in­for­ma­tion they store and how they store it. Re­la­tional data­bases are struc­tured like phone books that store phone num­bers and ad­dresses. Non­re­la­tional data­bases are doc­u­men­to­ri­ented and dis­trib­uted, like file fold­ers that hold ev­ery­thing from a per­son’s ad­dress and phone num­ber to their Face­book likes and on­line shop­ping pref­er­ences. We call them SQL and NoSQL.

The rise of RDBMSs

In 1970, E.F. Codd en­vi­sioned a new model of DBMS through his pa­per ti­tled, ‘A Re­la­tional Model of Data for Large Shared Data Banks’, which paved the way for the emer­gence of re­la­tional DBMSs (RDBMSs). ƒ RDBMSs for­mu­lated a new method­ol­ogy for stor­ing data and pro­cess­ing large data­bases.

ƒ The records (data) would be stored in ‘ta­bles’ with fixed-length records, un­like the free-form list of linked records in an IDS (In­te­grated Data Store) and IMS (In­for­ma­tion Man­age­ment Sys­tem).

ƒ Later, data­bases like In­gres, and a query lan­guage like SQL evolved. The nu­ances and ben­e­fits of RDBMSs had a wide im­pact, re­sult­ing in buy-in from dif­fer­ent ven­dors and set­ting the stage for an era of the data­base wars.

Many RDBMSs such as Sy­base, Mi­crosoft SQL Server, In­formix, MySQL, DB2 and Or­a­cle got launched around the same time, each claim­ing to be bet­ter in terms of:

ƒ Per­for­mance

ƒ Avail­abil­ity

ƒ Func­tion­al­i­ties

ƒ Cost of stor­age

ƒ Econ­omy of us­age

With no com­pe­ti­tion, RDBMSs got com­pletely en­trenched in the IT ecosys­tem by the early 2000s.

The evo­lu­tion of NoSQL

Around 2005, the ar­chi­tec­tural de­sign of ap­pli­ca­tions changed from the client- server model to the mas­sive Web scale ap­pli­ca­tions. This put a lot of pres­sure on RDBMSs that couldn’t in­no­vate on the fol­low­ing as­pects: ƒ Level of us­age

ƒ Vol­ume of data con­sid­ered

ƒ Ca­pa­bil­ity of han­dling/mon­i­tor­ing change

This started the era of the dis­trib­uted non-re­la­tional data­base man­age­ment sys­tem, later called ‘NoSQL’, which was more aligned to new age ap­pli­ca­tions. NoSQL grabbed every­one’s at­ten­tion be­cause it changed the way tra­di­tional SQL data­bases worked.

Note: NoSQL fore­casts a US$ 4.2 bil­lion rev­enue by 2020.

NoSQL: On what pa­ram­e­ters does it score high?

The key fea­tures of NoSQL that make it the most sought after data­base are:

ƒ It’s a dis­trib­uted com­put­ing sys­tem ƒ Higher scal­a­bil­ity

ƒ Re­duced costs

ƒ Flex­i­ble schema de­sign

ƒ Pro­cesses un­struc­tured and semistruc­tured data

ƒ No com­plex re­la­tion­ships

ƒ Open source

RDBMS vs NoSQL

Let’s com­pare the two types of data­bases on the fol­low­ing set of pa­ram­e­ters.

1. Scal­ing

RDBMSs scale ver­ti­cally.

ƒ Ar­chi­tec­ture de­sign runs well on a sin­gle ma­chine.

ƒ To han­dle larger vol­umes of op­er­a­tions, it is bet­ter to up­grade the ma­chine with a faster pro­ces­sor or more mem­ory.

ƒ There is a lim­i­ta­tion to the level of scal­ing.

NoSQL data­bases scale hor­i­zon­tally. ƒ NoSQL data­bases are in­tended to run on clus­ters of com­par­a­tively low-spec­i­fi­ca­tion servers. ƒ To han­dle more data, more servers need to be added to the clus­ter. ƒ These data­bases are cal­i­brated to op­er­ate with full throt­tle even with low cost hard­ware.

ƒ It’s a rel­a­tively cheaper ap­proach to han­dle in­creased num­ber of op­er­a­tions.

ƒ Can han­dle high vol­umes of data.

2. Main­te­nance

RDBMSs are high main­te­nance data­bases.

ƒ Main­tain­ing high-end RDBMS sys­tems is ex­pen­sive and re­quires a trained work­force for data­base man­age­ment.

NoSQL data­bases are low main­te­nance data­bases.

ƒ These data­bases re­quire min­i­mal man­age­ment and they of­fer many fea­tures. These in­clude au­to­matic re­pair, eas­ier data dis­tri­bu­tion and sim­pler data mod­els.

3. Data model

RDBMSs have a rigid data model. ƒ RDBMSs re­quire data in a struc­tured for­mat as per a de­fined data model. ƒ As change man­age­ment is a big headache in SQL with a strong de­pen­dency on pri­mary/for­eign keys, ad hoc data in­ser­tion be­comes tougher.

NoSQL data­bases are based on a no schema data model.

ƒ A NoSQL data­base is schema­less; so data can be in­serted into it with ease, even with­out any pre­de­fined schema.

ƒ The for­mat or data model can be changed any­time, with­out ap­pli­ca­tion dis­rup­tion.

4. Caching

RDBMSs use sep­a­rate hard­ware for caching.

ƒ The caching in a typ­i­cal RDBMS re­quires sep­a­rate in­fra­struc­ture. ƒ As there are over­heads, the logic of re­trieval in­volves a lit­tle de­lay.

NoSQL data­bases in­te­grate caching. ƒ NoSQL data­bases sup­port caching in the sys­tem mem­ory, which in­creases data out­put per­for­mance.

Rea­sons to use an SQL data­base

Listed be­low are a few rea­sons for choos­ing an SQL data­base over a

NoSQL one.

ƒ You need to en­sure ACID com­pli­ance (atom­ic­ity, con­sis­tency, iso­la­tion, dura­bil­ity): ACID com­pli­ance re­duces anom­alies and pro­tects the in­tegrity of your data­base by pre­scrib­ing ex­actly how trans­ac­tions in­ter­act with the data­base. Gen­er­ally, NoSQL data­bases sac­ri­fice

ACID com­pli­ance for flex­i­bil­ity and pro­cess­ing speed, but for many e-com­merce and fi­nan­cial ap­pli­ca­tions, an ACID-com­pli­ant data­base re­mains the pre­ferred op­tion. ƒ Your data is struc­tured and un­chang­ing: If your busi­ness is not ex­pe­ri­enc­ing mas­sive growth that would re­quire more servers and you’re only work­ing with data that’s con­sis­tent, then there may be no rea­son to use a sys­tem de­signed to sup­port a va­ri­ety of data types and high traf­fic vol­ume.

Rea­sons to use a NoSQL data­base

Given be­low are a few rea­sons you might choose a NoSQL data­base.

ƒ Your busi­ness stores large vol­umes of data that of­ten have lit­tle to no struc­ture: A NoSQL data­base sets no lim­its on the types of data you can store to­gether, and al­lows you to add dif­fer­ent new types as your needs change. With doc­u­ment based data­bases, you can store data in one place with­out hav­ing to de­fine what ‘types’ of data these are, in ad­vance. ƒ A NoSQL data­base makes the most of cloud com­put­ing and stor­age: Cloud-based stor­age is an ex­cel­lent cost-sav­ing so­lu­tion, but re­quires data to be eas­ily spread across mul­ti­ple servers to scale up. Us­ing com­mod­ity (af­ford­able, smaller) hard­ware on-site or in the cloud saves you the has­sle of ad­di­tional soft­ware, and NoSQL data­bases like Cas­san­dra are de­signed to be scaled across mul­ti­ple data cen­tres out-ofthe-box with­out a lot of headaches. ƒ Rapid de­vel­op­ment: If you’re de­vel­op­ing within two-week, ag­ile sprints, crank­ing out quick it­er­a­tions, or need to make fre­quent up­dates to the data struc­ture with­out a lot of down­time be­tween ver­sions, a re­la­tional data­base will slow you down. A NoSQL data­base doesn’t need to be prepped ahead of time.

NoSQL RDBMS

Fig­ure 1: RDBMS vs NoSQL

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.