NOSQL ELLER SQL ?

NOSQL slår samtlige SQL database systemer på drift, hastighed og skalérbarhed.

KORT INTRO: NoSQL er en betegnelse for de nye nonrelationelle “databasesystemer” som kan arbejde med datalagring langt hurtigere end konventionelle Relationelle RDBMS SQL Server systemer. NoSQL er primært en Open Source bevægelse som er startet som spinoff på udvikling udført til de meget kendte amerikanske portaler og tjenester.

I dag benyttes NOSQL af verdens største aktører og portaler f.eks. Facebook, Google, Twitter, LinkedIn, Cisco, Digg, Alexa, Amazon m.fl.

SQL RDMS Databaser eller NOSQL?

Netop fordi NOSQL  forretningsmodellen er så bredt accepteret og det faktum at mange skifter til NoSQL får NoSQL vind i sejlene og der opstår nye produkter næsten dagligt. Egentligt burde de ikke kaldes for databaser, selvom det gør det fleste. Forskellen på RDBMS og NOSQL er at SQL er relationelle og netop her er en del af forklaringen fordi NOSQL er ikke relationelt på indtil flere måder og dog, man kan nemlig sætte NOSQL op på utroligt mange måder, hvilket gør den alsidigt i brug. Men NOSQL benyttes som databaser men med den fordel at de kan være indtil 2.000 gange hurtigere, når der tales om skrivninger og læsninger. Man kan sammenligne NOSQL med et spreadsheet eller en tabel i stedet.

NOSQL er ikke en SQL database ligesom MySQL, Oracle og Microsoft SQL Server

NOSQL har sin baggrund i 1998 hvor flere talsmænd hævdede at NOSQL var at foretrække. Oprindeligt var det Carlo Strozzi der proklamerede at NOSQL bevægelsen reelt burde hedde NOREL, hvor REL står for relationel. Derfor har man diskuteret at NOSQL skulle stå for NOT ONLY SQL, fordi at NOSQL kan tilbyde SQL lignende produkter. Dette rette navn for NOSQL vil i Danmark formentligt være DATAKILDE,  DATALAGRINGSSYSTEM eller rettere STRUKTURERET DATA LAGER. En af de store fordele NOSQL har er at undgå JOIN operationer og så typisk at skalere horisontalt.

NOSQL er IKKE en nyhed, idet NOSQL blev introduceret i 1998 og tidligere som synonym for relationelle letvægts Open Source databaser. De har ikke udgjort nogen trussel i en 10 års tid. Men det gør de nu, fordi NOSQL er gratis og ingen har siddet det argument overhørigt at man kan spare på servere og harddiske for ikke at tale om skaleringer som helt automatisk uden nogen former for tilpasninger standard kan give ca. 2.200 gange hurtigere datalagring. 2.200 er et enormt tal og det fremkommer når man tager de tests der er udformet og de test sammenligner man så med produkter såsom MYSQL, POSTGRESQL, ORACLE og MICROSOFT SQL SERVER. De sidstnævnte kan nemt koste ca. 125.000 kr.

NOSQL er nemt at integrere, benytte og vokse med uden man behøver at foretage sig noget

NOSQL er både lysår foran i hastighed og nemhed med hensyn til integration og brug. Så hvorfor så i det hele taget overveje at købe databaser. Ja for mange er det en god forretning med gratis software, men der kan stadig være mange eksempler som retfærdiggør brugen af dyrere  konventionelle proprietære og ACID (syrefaste) SQL systemer. F.eks. kan der være systemer som er skrevet til dedikerede SQL systemer.

MYSQL er den mest benyttede database i verden og man kan f.eks. ikke umiddelbart benytte f.eks. WordPress, Joomla, Drupal og Typo3 med NOSQL, det er der ved at blive lavet radikalt om på, men her og nu er svaret nej. Men NOSQL forventes at have nogenlunde samme udbredelse som JAVA har indenfor programmering. Jeg tror at de traditionelle databaseproducenter bliver tvunget til at indbytte NOSQL teknologier, i takt med afvandringen fra SQL standarder.

NOSQL fordele og ulemper

De typiske moderne relationelle databaser har ikke vist hastighed, men at de er langsomme når det gælder krævende applikationer eller det at indeksere store mængder af dokumenter eller grafik. Man har så kompenseret for dette på forskellig vis, men SQL er og bliver for langsomt. Endvidere er det en meget stor ulempe at de kendte databaseleverandører sender produkter på gaden som kun kan blive noget hurtigere ved hjælp af fin konfiguration som ofte skal ændres når datamængderne f.eks. ændrer indhold.

På verdens største sites kan man ikke benytte SQL, det bliver ganske enkelt flere dage om de samme operationer. NOSQL er blevet kritiseret fir at NOSQL ikke kunne  tilbyde en fuld distribueret ACID arkitektur. Dette kan leveres siden 2009 i de fleste distributioner. Det har den fordel at NOSQL dermed bliver fuld redundans på flere servere.

Ulemperne ved NOSQL er at produktet først igennem de senere år er slået igennem, hvorimod RDBMS er produktmodnet siden starten af 90′erne med meget store feedbacks fra millioner af sites og udviklere. Dette henstår endnu og vi spår NOSQL en stor udvikling igennem de kommende år samt at NOSQL kan vælges på lige fod i applikationer indenfor f.eks. ERP, CMS, CRM og specielt BI løsninger.

Agiludvikling® og NOSQL med Dedikeret Server og/eller med Cloud Computing

NOSQL betegner vi som et agilt værktøj. Med Agiludvikling kan du få sat servere op på 2 måder. Den ene er at vi installere en 1 eller 2U server til dig hvor hele applikationen, websider m.v. så kan ligge. Den anden måde er at vi sætter en Virtual Server op til dig på Cloud Computing platformen på DIX der ligger hos Verinet. Huslejen for en server er ca. 200 pr. måned + strøm og trafik og huslejen for en virtual server er 795,- kr. for en ikke redundant Virtual Server hos Verinet. Se www.verinet.dk

Agiludvikling kan så udvikle direkte til NOSQL produktet efter frit valg. Vi anbefaler f.eks. Cassandra, CouchDB eller MongoDB og man kan overveje VoltDB som ER en SQL RDMS men hurtigere end normalt. Vi anbefaler IKKE nybegyndere at udvikle til NOSQL, fordi man ofte kan få en acceptabel performance med Microsoft SQL Server, IBM DB2, Oracle eller MYSQL.

Der er en flot support på community siderne. Sidder man om aftenen som jeg gør har man svar i løbet af 1 time på selv vanskelige spørgsmål eller konceptuelle spørgsmål. Man får iøvrigt også rigtig god support på den officielle NOSQL forum på: http://groups.google.de/group/nosql-discussion

Hvad hedder NOSQL  produkterne?

NOSQL Datalagring

NOSQL Grafiksystemer
NOSQL Key/Value datalagring
Key/value cache RAM
Eventually‐consistent key‐value store
Ordered key-value store
Multivalue databases
Object database
Tabular
Tuple store

Har du forslag så skriv dem her på en kommentar:

Tryk CONTROL+D for at HUSKE denne side.