3. PLAN
co to jest nosql?
dlaczego nie?
dlaczego tak?
kupuję to, co dalej?
4.
5. IN COMPUTING, NOSQL IS A
TERM USED TO DESIGNATE
DATABASE MANAGEMENT
SYSTEMS THAT DIFFER FROM
CLASSIC RELATIONAL
DATABASE MANAGEMENT
SYSTEMS (RDBMSES) IN
SOME WAY.
33. REDIS - TYPY DANYCH
• łańcuchy tekstowe
• hashe
• listy
• kolekcje
• kolekcje posortowane
34. ARGUMENTUM AD AUDITOREM
ARGUMENTUM AD BACULUM
ARGUMENTUM AD HOMINEM FALLACIA
ACCIDENTIS ARGUMENTUM AD
IGNORANTIAM ARGUMENTUM AD
MISERICORDIAM CIRCULUS VITIOSUS
ARGUMENTUM AD NUMERUM
ARGUMENTUM AD PERSONAM
ARGUMENTUM AD POPULUM PETITIO
PRINCIPII ARGUMENTUM AD TRADITIONEM
ARGUMENTUM AD VANITATEM IGNORATIO
ELENCHI ARGUMENTUM AD VERECUNDIAM
dlaczego go nie potrzebujesz dzisiaj, ale jeśli masz szczęście - możesz potrzebować go jutro\n
\n
\n
na początek definicja - co to jest nosql\nkto z was miał styczność z nosql w produkcji\n
definicja z wikipedii nie definiuje pojęcia prezycyjnie\na w zasadzie niczego nie precyzuje\nogólnie - system przetrzymywania danych, podobny do bazy danych, ale nią nie będący\n
definicje są co najmniej 2 - pierwsza z nich wyklucza korzystanie z jakichkolwiek baz sql-owych\nta definicja nam się nie podoba\n
tak jak ja to rozumiem\nnie brak SQL-a, ale “nie tylko SQL”\nnosql jedynie jako pomoc dla relacyjnych baz danych\ntak naprawdę nie ma jednoznacznej definicji - przedstawiam swój punkt widzenia\n
po co w ogóle powstał nosql?\ndo czego Tobie może przydać się nosql\n
pierwszy i podstawowy to skalowalność - nosql ma być magicznym rozwiązaniem, które ulży wszystkim problemom związanym ze skalowalnością - został tak naprawdę stworzony przez firmy, które musiały rozwiązać konkretny problem - dzisiaj się to zmienia, postawają wyspecjalizowane firmy tworzące takie rozwiązania\n
baaaaaaardzo duuuuuuużo danych\npartycjonowanie pozwala na względnie łatwe przetrzymywanie ogromnej ilości danych\nw zwykłych bazach zwykle trzeba robić to na poziomie kodu (sharding)\n\n
jako baza danych\n
nierelacyjny, nie można wykonywać joinów, pobranie każdego zasobu wymaga osobnego zapytania do bazy danych, nie da się wyciągnać skomplikowanych struktur, które są ze sobą powiązane, nie da się wykonywać obliczeń - tak naprawdę przy pewnej skali chcesz wszystko obsługiwać asynchronicznie i trzymać wyniki\n
rozproszony - w uproszczeniu - jest centrum, które bazą steruje, ale dane w niej zawarte są rozrzucone po wielu serwerach, a nawet lokalizacjach\n
horyzontalnie skalowalny - skalowanie następuje poprzez dorzucanie maszyn, a nie dorzucanie sprzętu do pojedynczej maszyny - sprzęt tanieje, ale ilość pamięci, którą jesteśmy w stanie umieścić w serwerze zawsze będzie ograniczona (i mniejsza od najbardziej wyrafinowanych wymagań)\n
nieustrukturyzowany - tak naprawdę w zaprzeczeniu do bazy danych, nie per se - nie ma kolumn, ale nawet klucz-wartość jest strukturą\n
łatwo replikowalny - dane można trzymać w wielu kopiach i nie powinno to być skomplikowane\n
ostatecznie zgodny - to najbardziej skomplikowany temat - po odpowiednio długim czasie od ostatniej aktualizacji bazy będzie ona taka sama we wszystkich kopiach\n
typy nosql baz danych (opisać poszczególne typy)\nkv - memcached, nosql\nbaza kolumnowa - cassandra, simpledb, bigtable\ndokumentowa - couchdb, mongodb\n
i teraz trzeba sobie odpowiedzieć na podstawowe pytanie - dlaczego nie chce mieć no sql\njak myślicie - dlaczego nie?\nodpowiem przez przykłady\n
główną bazą jest mysql\n
twitter chciał trzymać dane w cassandrze, pozostawił jednak wszystko w mysqlu\ntestuje Redisa\n
projektowanie aplikacji w oparciu o nosql wymaga zupełnie innego podejścia,\nprojektowanie modelu danych jest dużo trudniejsze, odpytywanie bazy danych jest dużo trudniejsze - nie wszystko da się trzymać w jednym miejscu, nie wiadomo czy będzie potrzebny, premature optimization\n
zgodność, dostępność, partycjonowanie - rozproszony system nigdy nie zapewni tych wszystkich elementów\n\nrozwiązanie tego problemu jest podstawowe dla zastosowania nosql\nmożna wybrać tylko 2 z trzech\n
sprawa zupełnie podstawowa - administracja - jeszcze brakuje specjalistów, łatwiej znaleźć specjalistę od mysqla niż cassandry\nco zrobić w przypadku krytycznej sytuacji?\n
te główne problemy to powód, dla którego to logo będziemy widzieć jeszcze bardzo długo\n
czasami trzeba, bo nie ma innej możliwości\n2 bazy danych, na które warto spojrzeć, które mają przed sobą przyszłość w zastosowaniach nawet podstawowych, przy mniejszych serwisach\n
baza dokumentowa\n
dokumentowa - czyli do klucza przypisujemy dokument json, wydajna - bez joinów, ale posiada indeksy, wysokodostępna - automatyczna replikacja z failoverem mastera, skalowalna - automatyczny sharding, język zapytań - javascript + możliwość pisania map reduce\n
ciekawostka - GridFS - czyli możliwość przechowywania plików w bazie danych (i ma to sens)\nindeksy geograficzne - coś, z czego mocno korzysta Foursquare - wyszukiwanie lokalizacji najbliższych wskanazej lokalizacji\n
memcached na sterydach, serwer struktur danych\n
\n
persystencja - coś, czego nie ma memcache - zrzut bazy, dopisywanie do pliku\nwłasna pamięc wirtualna, która trzyma w RAM-ie tylko te dane, z których aktualnie korzystamy\npipeline - optymalizacja wykonywania operacji - wysłanie wielu komend bez czekania na odpowiedź poprzedniej\n
łańcuchy tekstowe (ale ze wsparciem dla liczb całkowitych)\nhashe - czyli struktura w strukturze (świetnie optymalizuje wykorzystanie pamięci)\n
