MýtusRelačné databázy (spolu s objektovými a

OR) sú najvyspelejšou formou databáz. Nie je dôvod uvažovať o ničom lepšom.

REDIS - REmote DIctionary Serverkey-value store alebo data structure server

(string, hash, list, set, sorted set) patrí do skupiny NoSQL DB (not-SQL, noRel) dnes je silne vžité SQL – jednoduché pre

programátora a analytyka, zložité pre server ACID (atomicity, consistency, isolation, durability)

ACID (v REDISe)Atomicity - je zabezpečené Consistency, Isolation - transakcie vo forme

blokovania všetkých ostatných volaní (transakcia sa nezastaví ani kvôli chybe)

Durability – všetko v RAM, môže sa robiť záloha na disk ako append-only súbor. Po reštarte sa znovu načíta do RAM.

Iné noSQLDocument store Graph DBKey-value store (memcached)Hierarchický key-value store

SQL vs noSQLSQL noSQLfixná štruktúra (tabuľky,

typy)časté krátke read/write

transakcie alebo dlhé batch jobs hlavne s čitanim cross veľa tabuliek

veľké BLOB dáta JOIN spĺňa ACID podmienkytažko distribuovateľné

(dáta sú zviazané už v DB)

univerzálne typyčasté krátke read alebo

write transakcie s malými dátami

dáta v databáze nie sú zviazané

plne nezabezpečuje ACIDrelatívne ľahko

distribuovateľne

REDIS vs Memcachedredis - je zložitejší ako memcacheddb (viac

operácií aj funkcií)Keys - (navyše expirácia, hash keys - kľúč je

tabuľka, lists - kľúč je zoznam s operáciami insert, append, remove atď)

Sets - kľúč je množina Sorted Sets - utriedený zoznam Pub/Sub - publish, subscribe, channel Transactions – blokujúce (serialized)pipelining – šetrí sieťový roundtrip

MýtusDatabázový server musí byť poriadne zložitý

a plný zložitých algoritmov aby bol rýchly.

REDIS inside(jednoduchší, ako by sa dalo čakať)REDIS = len 20k riadkov kódu append only file, všetko je v RAM (a VM) dva druhy protokolov

jednoduchý textový veľmi jednoduchý textový

=> široká podpora klientov (možno viac ako MySQL)

REDIS - Multiuser serverredis obsluhuje mnoho userov (rádovo 10k)

Znamená to mnoho threadov? Ako dokáže menežovať toľko threadov? Nemusí – redis je single threaded (event

library)

MýtusPre obslúženie mnoho úloh a userov

potrebujem mnoho threadov.

Event Libraryhttp://redis.io/topics/internals-eventlib

jedna veľká slučka (Event Loop)rad eventov s prioritou rozdelený podľa zdrojov

(napr. IO)vytváram eventy (napr. počúvam zo siete),

hádžem ich do zoznamu eventov spolu s časmi pre scheduler

Vo volaní eventu neblokujem hlavné vlákno. Ak čakám na nejaký zdroj, volanie robím znovu ako event v event loop (asynchrónne).

Iny spôsob myslenia, napr. nemám stack trace ani pri rekurzívnom volaní (nevýhoda pre debug)

MýtusV dnešných viacjadrových serveroch musí

mať proces viac threadov, aby bol efektívny.

Nemusí. Môže mať viac procesov.

Event LibraryVhodné pre “mega multi”-user servere (napr.

REDIS)

Je ale použiteľny aj inde?

MýtusRýchly server (web, TCP, file, ...) musí byť

špecializovaný software.Programovať takýto server v javascripte je

čistá samovražda (prečo by som to vlastne robil???).

Node.JS

(DEMO)

Aky rýchly je redis? http://redis.io/topics/benchmarks

SET GET100007 requests

completed in 0.88 seconds 50 parallel clients 3 bytes payload58.50% <= 0 milliseconds

99.17% <= 1 milliseconds 99.58% <= 2 milliseconds 99.85% <= 3 milliseconds 99.90% <= 6 milliseconds 100.00% <= 9 milliseconds

114 293.71 requests per second

100000 requests completed in 1.23 seconds

50 parallel clients3 bytes payload43.12% <= 0 milliseconds

96.82% <= 1 milliseconds 98.62% <= 2 milliseconds 100.00% <= 3 milliseconds

81 234.77 requests per second

Budúcnosť databáz?množstvo dát (GB, TB)sociálne siete – silné väzby, interaktivitaveľa RAM - ako ju vôbec využiť?SSD disky – vhodné pre redis

Ďakujem za pozornosť.

Diskusia