Bazy NoSQL'owe - naturalny storage aplikacji JS'owych
Świat JavaScriptowy przeżywa ostatnimi czasy rewolucję w postaci SSJS (zwłaszcza za sprawą wszędobylskiego Node.JS), śmiało też można powiedzieć, że równolegle ma miejsce rewolucja w świecie baz danych. Po wielu latach panowania opartych na logice zbiorów, relacyjnych baz danych, coraz częstsze zastosowania w świecie rzeczywistym znajdują bazy noSQL, które w praktyce /często są bazami dokumentów JSON/, a zatem idealnie /wpasują się w filozofię JavaScript/, która przecież JSON-em stoi. Użycie takich baz danych staje się jednym z kluczowych uzasadnień dla SSJS – osiągamy bowiem spójność zarówno w charakterze języka, jak i formatu wymiany danych.
Bazy JSON’owe
Kluczowym i przełomowym przykładem będzie tutaj CouchDB – baza dokumentów JSON, która do komunikacji z serwerem używa protokołu HTTP, a językiem zapytań jest JavaScript. Nie sposób nazwać CouchDB inaczej, jak internetową bazą danych. To właśnie filozofia CouchDB oraz sukces googlowskiej BigTable, spowodowały żywe zainteresowanie noSQL. Zwrócono też w końcu uwagę, iż rozwiązania inernetowe często różnią się od aplikacji stricte transakcyjnych (typowych np. dla operacji finansowych), w których kluczowym jest aktualność informacji. Dla internetu najbardziej istotna jest dostępność informacji oraz możliwość ich rozproszenia i łatwego skalowania – co w przypadku relacyjnych baz danych jest trudne do osiągnięcia.
Żegnaj SELECT, witaj map-reduce
Proponujemy Wam DevMeeting poświęcony nowościom w świecie baz danych. Przyjrzymy się istniejącym rozwiązaniom i przeanalizujemy ich słabości i zalety – również w porównaniu z bazami relacyjnymi. Jak to jednak na DevMeetingach bywa – najwięcej miejsca poświęcimy aspektom praktycznym. Z doświadczenia wiemy, że nie jest łatwo zamienić myślenie w kategoriach rachunku zbiorów na podejścia typu map-reduce i podobne. Nierelacyjne bazy danych wymagają bowiem zupełnie nowego podejścia, zarówno w kwestii organizacji danych, jak i (a może przede wszystkim) sposobu zadawania zapytań.
Zagadnienia
- Relacje vs dokumenty vs key/value
- Bazy danych na potrzeby aplikacji internetowych
- Przegląd baz noSQL
- Bazy dokumentów (CouchDB, MongoDB)
- Bazy klucz-wartość (Cassandra, Redis)
- Struktura i projektowanie nierelacyjncyh baz danych
- Wydawanie zapytań
- Bazy noSQL w architekturze aplikacji SSJS
Dla kogo?
Tematyka pojawia się częściowo w kontekście języka JavaScript i jego zastosowania w rozwiązaniach serwerowych, dlatego jego znajomość, a zwłaszcza dobre zrozumienie JSON-a, są wymagane od uczestników. Przyda się znajomość Node.JS. Oczywiście niezbędna jest wiedza z tematu baz danych, SQL oraz projektowania aplikacji internetowych. Reasumując – zapraszamy webdeveloperów z krwi i kości. Jeśli jednak jesteś senior developerem od urodzenia rozmawiającym SQL-em, znajdzie się miejsce i dla Ciebie.
Devmeetings @ facebook
Prowadzący
David de Rosier, rocznik 1977. Programista, szkoleniowiec i pasjonat WEB2.0 oraz nowoczesnych technik programistycznych. Były nauczyciel akademicki, stały współpracownik Software Developers Journal. W latach 2003-2010 zajmował się szkoleniem programistów z technologii MDA (BML, Java, JavaScript) oraz projektowaniem aplikacji bankowych i mobilnych, pracując onsite dla klientów w Azji, Afryce i Europie. Aktualnie freelancer, zajmujący się głównie szkoleniami i konsultingiem z technologii javascriptowych. W wolnych chwilach programuje lub podróżuje. Często jedno i drugie.
David zapewnia, że żadne z waszych pytań, które pojawi się podczas pisania aplikacji, nie pozostanie bez odpowiedzi.
Dyskusja
Witam,
devmeeting ten, tak jak wszystkie we wrzesniu, jest kontynuacja lipcowego devcampa (www.devcamps.pl). W miniona sobote skypilismy sie na porownaniu wydajnosci roznych implementacji tego samego przypadku (uproszczonego klona twittera) opartego na sporej i podzielonej bazie relacyjnej – MySQL(http://devmeetings.pl/trainings/wydajno%C5%9B%C4%87-nodejs-kontra-reszta-%C5%9Bwiata).
Na tym devmeetingu chcemy natomiast, uzywajac tej samej aplikacji opartej na node.js, sprobowac przerobic warstwe dostepu do danych wraz z relacyjnym modelem i danymi na kilka rozwiazan NoSQL. Interesuja nas przede wszystkim aspekty praktyczne i konkretne problemy z jakimi przychodzi sie zmierzyc wybierajac NoSQL.
Forma tego devmeetingu bedzie rowniez devcampowa i przede wszystkim praktyczna – koderska. W malych grupach (podzial zupelnie dowolny) przygotujemy wersje naszego twittera oprate o rozne technologie NoSQL. Z naszej strony proponujemy CouchDB, MongoDB i projekt Cassandra. Co oczywiscie nie oznacza, ze nie mozna zaproponowac i zastosowac czegos zupelnie innego.
Zapraszam do zadawania pytan i dyskusji. Sugeruje rowniez przejrzenie dyskusji dla poprzedniego devmeetingu (http://devmeetings.pl/trainings/wydajno%C5%9B%C4%87-nodejs-kontra-reszta-%C5%9Bwiata).
Jutro podam info odnosnie zalecanego przygotowania oprogramowania.
Dla osob, ktore nie przejrzaly watku “wydajnosc”, przedstawiam nasz prosty model relacyjny, z ktorym pracowalismy w ubiegla sobote i ktory teraz chcemy (wraz danymi) zmigrowac na rozne rozwiazania NoSQL:
users: id, name, screen_name
statuses: id, text, created_at, user_id
followers: user_id, follower_id
Baza nasza to w praktyce 4 bazy MySQL, a partycjonowanie zrobione jest po user_id, czyli dane konkretnego usera (wraz ze statusami oraz informacja kogo sledzi) znajduja sie w jednej partycji/bazie.
Czy były wysyłane może wymagania co do oprogramowania?
Czy oprócz Node i wybranego engine’u coś będzie jeszcze potrzebne?
Node (z managerem pakietow npm) i wybrany engine to taka podstawa. Sugeruje rowniez posiadanie MySQLa, z tego wzgledu, ze bedzie to element wyjsciowy dla naszej pracy.
Dla chcacych pobawic sie wczesniej:
https://github.com/adamjodlowski/tweet-perf
Jest to link to aplikacji stworzonej przez Adam Jodlowskiego na “wydajnosciowym” devmeetingu, ktory mozemy uzyc za punkt wyjscia do stworzenia odpowiednika pracujacego na wybranym NoSQLu.
Do powyższej aplikacji możecie panowie dopisać swoje moduły na kształt database-xxx.js, które wypluwają wyższej warstwie (engine.js) tablicę tweetów z datami utworzenia a ta warstwa je sortuje i wysyła do klienta 20 najnowszych (banalna redukcja). Trzeba tylko pobrać dane z bazy, cały interfejs jest gotowy, dla celów testowych postowanie tweetów jest na GET (zamienione w jednym miejscu w app.js z POST na GET pod wpływem chwili, w trakcie devmeetingu).
Powodzenia, jestem bardzo ciekaw wyników, jeśli się uda to podłączę się zdalnie. Adam, upublicznij generator jeśli znajdziesz wolną chwilę :-)
Adamie, fix tabs pls. Github straaasznie to pokazuje..
I rozumiem, ze jutro kontynuujemy w CoffeeScript :)
Dziękuję bardzo za świetne szkolenie! David jak zwykle pokazał klasę, choć z Cassandrą nikt sobie do końca nie poradził…
Moim zadaniem na przyszłe kilka dni jest zaaplikowanie poprawnego wykonywania operacji nosql’owych w połączeniu z NodeJS, bo insert do bazy, poprzez sterownik cassandra, krótko mówiąc “nie działają”.
See U soon in Kraków!
http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef0148c80ac6ef970c-pi
Zgodnie z filmem:
http://www.youtube.com/watch?v=a6c_3m7CMU4&feature=related
od 0:48 sekundy..
“Ty, to dobre jest!” – hahah
Jeśli nie posiadasz jeszcze konta, prosimy się zarejestrować .
Hej!
Bede pierwszy raz na Waszym spotkaniu. Sledzilem dyskusje “poznanska”.
Czy cos trzeba/ mogę przygotowac?
Czy jakis podzial na teamy juz ma sie wyklarowac przed sobotą?
Czasowo jaki bedzie podzial: wyklad / warsztaty, praca parami?
Wolalbym sie przygotowac z danej technologii, anizeli siedziec i podziwiac czyjs monitorek, albo czytac dokumentacje w sobote.. szkoda czasu wtedy.
Moze chcecie kontynuwac prace na kodzie powstalym w ten weekend, to moze go udostepnic gdzies?
Propozycje?
:)
Tomasz