Column Oriented Database

Fordele ved Column Oriented Database

• Kompression. Column Oriented Database er meget effektiv til at kompresse data. 
• Sammenlæggende queries. Grundet deres struktur er Column Oriented Database meget effektiv til at arbejde med sammenlæggende queries (som f.eks. SUM, COUNT, AVG, etc).
• Scalability. Column Oriented Database er meget Scaleable . De passer perfekt til at udfører massively parallel processing (MPP), Hvilket involverer at have data spredt ud over en masse maskiner, often tusindvis af maskiner
• Hurtigt til at loade og query. Column Oriented Database kan loade ekstremt hurtigt, en database på mere end 1 million rows kan ofte blive læst på bare et par sekunder. Hvilket gør den ekstremt effektiv hvis der arbejdes med store mængder af data.

Use cases

• Content management systems
• Blogging platforms
• Systems that maintain counters
• Services that have expiring usage
• Systems that require heavy write requests (like log aggregators)

Opbygningen af en Column Oriented Database minder meget om ens sædvanlige SQL database. Tabellerne er opbygget på samme måde, med man har en key/id, og derefter følger tabellens attributter. En af fordelene ved Column Oriented Database er her at man i modsætningen til Row Oriented Database, ikke er bundet af de samme regler, Hvor i Row Oriented Database er hver row i ens tabel bundet af de columns der er indsat i tabellen, men i Column Oriented Database kan man indsætte lige de attributter der er relevante for den givne row, ligegyldigt om de er blevet brugt tidligere eller ej.

Nedenunder kan du se et eksempel på forskellen mellem lagring af data i de to former for database

Fordelen ved denne måde at gemme data på, er når man skal søge i den, er det super hurtigt og effektivt

Her er et billed over hvordan der søges i en Row Oriented Database

insert photo

Her er et billed over hvordan der søges i en Column Oriented Database

insert Photo

Dette gør den netop ekstremt effektiv i databaser med store mængder af data, til og med kan den også være god at bruge hvis man arbejder med numeriske værdier hvor man har brug for at finde overblik over ens data, som min værdi, maks værdi og median, da den bare kan nøjes med at læse dataen fra den enkelte kolonne 

Cassandra and Apache Hadoop Hbase (programmer til at lave en Column Oriented Database)

GRAPH NOSQL

• MONGODB er det documents baseret database
• Dyrt at anvende relationel database på grund af joints mellem flere datbaser gøre det langsomt og dyrt
• NOSQL query mere og mere data. Man fjerner ACID. 
• GRAPH database er relational og mere logisk facon, i en måde der repræsentere den rigtige verden. 

Properties

• Intiutivbness -> way to create and maintain your data in a logical facon -> less translation
• speed -> speed of developtment because more intiuativ, and execution result to application ebay used it
• agility -> how easily and quicxkly can adapt to change in buisness -> a naturally adaptive model
• Cypher

Use cases

• Real time recommendations -> recommendation to customers in shops
• Master data management -> to companys with bigger integrations and bigger systems
• Fraud detection 
• Graph vbased search -> 
• Network and it operations -> sammensætning af f.eks routers osv. 
• Identy and access management -> en skole eller virksomhed

roperty graph model

NEO4J Crash Course

• Graph database er en online database management system med CRUD operationer. 
• Hvad er en graph? Den er baseret på to elementer nodes og relationsships
• Hver node reepræsentere en entity (person, sted, ting)

Som vi kan se på billedet så har vi 3 noder. De 3 noder har såkaldte “labels” Person og Location. Vi kan se med pilene også kaldt “relationships” og dermed også properties som beskrive relationships eller noderne

Ligheder mellem en relationel database og en NoSQL Graph database:

.

Forskel mellem en Relation og en NoSQL Graph database:

• Neo4j er en database brug til at sikkert gemme infiormation og finde det senere
• NEO4JS data model er Graph -> af typen Property Graph
• Cypher er Neo4js graph query language (sql for graphs)
• Cyper er et decklarativt query langauge: det beskriver whvad du er intesseret i og ikke hvordan det bliver skaffet
• CVypher er lavet til at være læseliugt og ekspressivt

Man kan arbejde med Neo4j på 3 forskellige måder:

• Neo4j dekstop -> inkludere en neo4j database server som har en graph engine og kernel så cypher statements kan blive eksekveret til at få adgang til databse i dit system. Det inkludere en applikation kaldes neo4j browser. Neo4j browser tillader at du får adgang til neo4j databse som bruger cypher. Du kan også kalde “built in” procedures som kommuikere med database serveren. 

• Neo4j aura -> giver dig mulighed for at oprette en instance af en neo4j datase i cloud. 

• Neo4j sandbox -> er en en midlertidig løsning anvendes kun til træning osv. Forsvinder efter 7 dage alt bliver slettet. Bliver brugt til tutorials osv. 

Cypher

• Cypher er en query language man bruger til at hente data fra en Neo4j database, også til at oprette og updatere data
• Cypher er et deklarativt query sprog som tillader for eksspresiv og effektiv quering og updatering af graph data. 
• Bruger ASCII og Engelsk. 

Key value database

En key value database er en type af en non relationel database som bruger en simple key og value til at gemme data. En key value datase gemmer data som en collection af key-value pairs hvor en key fungere som en unik identifier. Key og values kan være mange ting, som f.eks simple objekter til komplekse objekter. En key value database er højt skalerebart. 

eksempler på key value database i virkeligheden kan f.eks være en telefonbog hvor navn er en key og værdien er et telefonnummer.

Nøglen / Key

Nøglen i en key value pair SKAL være unik. Det er denne unikke identifier som giver dig adagang til værdien associeret med nøglen.

I teorien kan nøglen være hvad som helst. Men den kan være afhængig af DBMS (Database Management System) som kan have nogle restriktationer på hvad der kan være en nøgle. 

For performance grunde skal nøglen ikke være så stor (i mb) da dette kan give nogle performance issues. 

The value / Værdien

Værdien i en key-value store kan være alt fra text, til et tal, til markup kode som html, eller php eller et billede osv.

Værdien kan også være en liste af informationer, eller endnu en key value indkapslet i et objekt. 

Nogle DBMS tillader dig at specificere en data type for værdien. Et eksempel kan være at man specificere at værdien skal være en integer. 

Nogle af de ting en Key-value database kan blive brugt til er f.eks.:

• General Web/Computers
  • User profiles (f.eks som facebook en brugerprofil)
  • Article/blog comments 
  • Emails
• Ecommerce
  • Shopping cart contents
  • Product categories
  • Product details
  • Product reviews
• Networking Data maintenance
  • Telecom directories
  • Internet Protocol (IP) forwarding tables
  • Data deduplication

Key value databases kan også gemme hele hjemmesider, ved at bruge URL som en key og selve siden som en value

Nogle fordele:

• Ret hurtigt
• Meget skalerbart
• simple model – let forståeligt

Nogle ulemper:

• Mange datastrukturer (objekter) er svært at modelere som key value pairs
• Svært at gennemgå hele databasen altså fast read and write but not optimized for look up

Document Database

Use cases

• E-commerce platforms
• Content management systems
• Analytics platforms
• Blogging platforms

Document Database minder meget om Key-Value Database, i det der er en Key og en Value, data er gemt som value. Den associeret key er en unik identifier for den value. Forskellen ligger så i at i en document database består valueen af struktureret eller semi struktureret data. Den struktureret/semi struktureret value kaldes for et document og kan være i henholdsvis XML, Json eller BSON format.

Document Database enabler Flexible indexing, powerful ad hoc queries og analyse over kollektionen af dokumenter

Hvad er en dokument database?

• Er bygget omkring JSON-lignende dokumenter, således at databasen er både naturlig og fleksibel for udvikler at arbejde med. Nosql Document database lover højere udviklings produktivitet og hurtig udvikling som programmer / applikationen har brug for. 
• Man arbejder med intuitive data modeller som er hurtigere og nemmere for udvikler. Hvordan det er sat op, altså det er nemt for os at læse og få overblik. 
• Fleksible schema: Dynamisk adaption til ændrelse i ens database, da nosql dokument database er dynamisk og selv beskrivende så du har ikke brug for at pre definere det i databasen. Felterne kan varier fra document til document og du kan modificere strukturen til hver en tid, og undelade disprutive schema migrationer. Og man kan i sin dokument database lave nogle JSON schema så man kan frivilligt lave restriktioner omkring dokumenternes struktur. 
• Universlet! JSON dokumenter er ovarlt! Letvægt, sprog-uafhængig og menneskelig læseligt. JSON er blevet en etableret standard for data behandling og opbevaring. Dokumenter er et supersæt af alle andre data modeller, så man kan strukturere data enhver måde som ens applikation har brug for.
  • Rig objekter, key value pairs, tabeller, geospatial og time series data
• Meget skalerbart! Da dokumenter i en dokumentdatabase er uafhængig enheder / units gøre det nememre at distribuere det gennem diverse servers samtidig med at vedligholde data lokaliteten.