NoSQL Datumaro povas esti de malsamaj kategorioj kiel kerna-valora datumaro, Dokumenta datumaro, Aŭ grafea datumaro. NoSQL datumaro estas sendependa kategorio kiu plenigas la mankojn trovita en tradicia RDBMS. Krome, NoSQL datumaro estas konsiderita specialecan datumaron subteni kompleksajn komercajn bezonojn. Lasi nin vidi kiom NoSQL datumaro povas plenigi la mankojn trovita en tradicia RDBMS.
Hodiaŭaj aplikoj (Plejparte araneaĵo bazita interretajn aplikojn) Estas tre postulema. Do la datumaroj ne estas nur atendita esti tre fleksebla en naturo subteni diversajn datumajn formatojn, Sed ili estas ankaŭ atendita administri ekstreman elfaron kaj grimpanta. Do la entreprenaj arkitektoj estas taksantaj la aplikojn konvene kaj tiam sugestanta la konvenajn datumarojn.
Ĝi estas esti notita ke NoSQL datumaroj ne estas anstataŭaĵo por tradiciaj datumaroj. Do la konvena rekomendo (RDBMS aŭ NoSQL) Estas tute bazita sur la naturo de uzaj kazoj. Iu tempo, RDBMS estas pli konvena komparita al NoSQL. Tiel, Se NoSQL estas elektita por malĝusta uza kazo tiam ĝi estos problemo por la apliko ĝi mem. Lasi nin havas rigardi kelkajn fundamentajn ĉefaĵojn de ĉi tiuj teknologioj en la sekvanta sekcio. Ĝi malbaros nian komprenon pri la realaj mankoj kiu povas esti plenigita supre de NoSQL DB.
Fundamenta kompreno de RDBMS kaj NoSQL: La tradiciaj datumaraj administradaj sistemoj povas garantii bonan elfaron kun volumo de miloj de transakcioj por dua. Sed la novaj aĝaj interretaj aplikoj kiel ‘fraŭda malkaŝo', ‘Vera tempa risko analizo -a, ‘vera tempa reklamado' kaj ‘multi-ludisto enretaj ludoj' ktp. okupas milionojn de transakcioj por dua. Do ĉi tiu OLTP (Enreta transakcia pretigo) Aplikoj estas tre malfacilaj administri kun tradiciaj interrilataj datumaroj. Kvankam, La RDBMSaj vendistoj estas ankaŭ metanta multon de penoj venki ĉi tiujn aferojn, Sed la manko kvietaj restaĵoj kiel ĝi estas.
Tradicia interrilata datumaro administradaj sistemoj estas ĉiam desegnis bazita sur ACIDAJ principoj. Ĉi tiuj ACIDAJ nemoveblaĵoj (Atomicity, Konsistenco, integreco kaj fortikeco) Certigi datuman integrecon ĉe ajna kosto, Kiu estas la kerno de ajna interrilata datumara administrada sistemo. Kun RDBMS, SQL estas la de-facto normo por datumo pretiganta taskojn kiel datuma demando, Datuma difino, Datuma manipulado ktp.
Aliflanke, NoSQL datumara administrado sistemoj uzas malsamajn formatojn enteni la datumon. La plej popularaj formatoj estas grafea vendejo, Dokumenta vendejo kaj kerna-valora vendejo. La kerna-valora vendejo estas la plej simpla formato kaj ĝenerale uzita. NoSQL databases remove most of the hard constraints used in RDBMS architecture to achieve data storage flexibility, scalability, performance etc.
Where an RDBMS is not suitable? How to fill those gaps?
There are many applications where traditional ACID driven relational model is not the simplest or best option. Let us have a close look at those gaps where a NoSQL is the best fit.
- If the requirement of your application is just to store the entities in a persistent and consistent way, then RDBMS is a overhead. The simple key-value store is more than sufficient to meet your application’s requirement. The value can be any complex entity as per your requirement.
- If the application has a requirement to store hierarchical objects with query capabilities, then RDBMS is not the suitable option. Kvankam, RDBMSa ujo faras ĝin kun la helpo de ORMaj iloj, Sed ke estas denove iom komplikita. Tiel, Ĉi tie ajna NoSQL solvoj estas tre rekomendita.
- En scenaro, Kie ni devas enteni retojn aŭ grandajn arbojn, RDBMS ne estas la solvo. Iu ajn NoSQL datumaro kiel grafea datumaro povas esti la plej bona kapabla dependanta sur via aliaj postuloj.
- Se via apliko estas deplojiĝita en nuba medio kun distribuita datumaron, Tiam RDBMSa solvo ne estas preferita. Ĉi tie la manko nur povas esti plenigita de NoSQL solvo.
Grava influanta faktorojn, Grimpanta kaj elfaro: RDBMS havas konstruita en limo por horizontala grimpanta. Do la radika problemo de RDBMS estas la horizontala grimpanta kiam la ŝarĝon kaj datumaj pliigoj. RDBMS ankaŭ ne subtenas aŭtomata datumo sharding. Aŭtomata datumo sharding estas nur ebla kiam la klaraj datumaj entoj estas distribuita kaj pretigis sendepende. ACIDA bazita interrilata modelo ne povas fari tion pro ĝia tablo bazita datuman modelon. Ĉi tie NoSQL solvo havas grandan diferencon. NoSQL datumaroj ne distribuas logikajn entojn en multoblaj tabloj; Ĝi estas ĉiam entenita en ununura loko. Kaj estas ne referential integreco daŭrigita inter ĉi tiuj logikaj entoj, Do NoSQL estas libera proponi aŭtomatan datumon sharding. Kvankam NoSQL solvoj limigis ĉefaĵojn komparita al interrilata modelo, Sed la desegno estas farita intence provizi altan scalability. La NoSQL solvo povas grimpi horizontale sur distribuita medion kaj subtenan haveblecon.
Elfaro plejparte dependas al la elekto de ĝusta teknologio (NoSQL aŭ RDBMS) Por la ĝusta uza kazo. Tiel, Se ni elektas NoSQL por malĝusta uza kazo tiam ĝi ankaŭ mortigos la elfaron de la apliko. Krom la faktoroj kiel reto, Caching, Disko I/O ktp., La elfaro multe dependas al la datumo kaj ĝia disdonado trans la distribuita tenadon. Tiel, La NoSQL estas la nura solvo kapabla pritrakti grandan volumon de datumo en clustered medio kaj tial akceli la elfaron.
Do ni povas konkludi ke la NoSQL ne estas anstataŭaĵo por tradicia RDBMS sed ĝi estas sinsekva solvo trakti malsaman aron de uzaj kazoj.
