Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00092 006352 18983922 na godz. na dobę w sumie
NoSQL, NewSQL i BigData. Bazy danych następnej generacji - książka
NoSQL, NewSQL i BigData. Bazy danych następnej generacji - książka
Autor: Liczba stron: 248
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-4751-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> bazy danych >> inne
Porównaj ceny (książka, ebook (-35%), audiobook).

Model relacyjnej bazy danych zdecydowanie dominował wśród technologii bazodanowych przez ostatnie 20 lat. Poszczególne rozwiązania były do siebie na tyle podobne, że decyzja o zastosowaniu relacyjnej bazy danych stała się oczywista. Architektura rozwiązań tego typu była zbliżona, a różnice polegały głównie na koszcie wdrożenia, wydajności, niezawodności i łatwości użycia aplikacji. Obecnie sytuacja diametralnie się zmieniła: powstało wiele radykalnie różniących się od siebie technologii bazodanowych, a wybór właściwej bazy danych stał się złożonym zadaniem, wymagającym sporej wiedzy i obarczonym poważnymi konsekwencjami natury ekonomicznej i technologicznej.

Ta książka szczególnie przyda się architektom technologii informatycznych, administratorom baz danych i projektantom, którzy do wykonywania swoich obowiązków potrzebują wiedzy o najświeższych rozwiązaniach z dziedziny technologii baz danych. Omówiono tu najnowsze, wykorzystywane obecnie technologie baz danych. Wyjaśniono, w jakim celu zaprojektowano każdą z nich. Zaprezentowano możliwości poszczególnych baz danych oraz ich potencjał w rozwiązywaniu realnych problemów biznesowych i problemów z aplikacjami. Co najważniejsze, ukazano różnice w architekturze między technologiami, które mają kluczowe znaczenie przy wyborze platformy baz danych dla nowych i planowanych projektów.

W tej książce między innymi:

NoSQL i BigData: potężne bazy danych przyszłości!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Next Generation Databases: NoSQL and Big Data Tłumaczenie: Piotr Pilch ISBN: 978-83-283-4751-9 Original edition copyright © 2015 by Guy Harrison. All rights reserved. Polish edition copyright © 2018 by HELION SA. All rights reserved. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Helion SA dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Helion SA nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Helion SA ul. Kościuszki 1c, 44-100 Gliwice tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/nosqln Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści O autorze ........................................................................................................ 11 O recenzencie merytorycznym ......................................................................... 13 Podziękowania ................................................................................................ 15 Bazy danych następnej generacji ..................................................... 17 Część I Rozdział 1. Trzy rewolucje związane z bazami danych ...................................................... 19 Wczesne systemy baz danych ................................................................................................... 19 Pierwsza rewolucja związana z bazami danych ...................................................................... 21 Druga rewolucja związana z bazami danych .......................................................................... 23 Teoria modelu relacyjnego ................................................................................................. 23 Modele transakcji ................................................................................................................. 25 Pierwsze relacyjne bazy danych ......................................................................................... 25 Wojny baz danych! .............................................................................................................. 26 Model przetwarzania klient-serwer ................................................................................... 26 Programowanie obiektowe i system OODBMS .............................................................. 27 Okres stabilizacji relacyjnych baz danych ........................................................................ 29 Trzecia rewolucja związana z bazami danych ........................................................................ 29 Google i Hadoop .................................................................................................................. 29 Reszta witryn internetowych .............................................................................................. 30 Chmura obliczeniowa ......................................................................................................... 30 Bazy danych dokumentów ................................................................................................. 31 NewSQL ................................................................................................................................ 32 Eksplozja nierelacyjnych baz danych ................................................................................ 32 Podsumowanie: jeden rozmiar nie pasuje wszystkim ........................................................... 33 Źródła ........................................................................................................................................... 34 Poleć książkęKup książkę SPIS TREŚCI Rozdział 2. Google, Big Data i Hadoop .............................................................................. 35 Rewolucja związana z koncepcją Big Data .............................................................................. 35 Chmura, urządzenia przenośne, serwisy społecznościowe i Big Data ......................... 36 Google: pionier koncepcji Big Data ......................................................................................... 37 Sprzęt używany przez firmę Google .................................................................................. 38 Stos oprogramowania firmy Google ................................................................................. 38 Dodatkowe informacje o modelu MapReduce ................................................................ 40 Hadoop: stos open source firmy Google ................................................................................. 42 Początki technologii Hadoop ............................................................................................. 42 Siła technologii Hadoop ...................................................................................................... 43 Architektura technologii Hadoop ..................................................................................... 43 HBase ..................................................................................................................................... 46 Hive ........................................................................................................................................ 46 Pig ........................................................................................................................................... 49 Ekosystem Hadoop .............................................................................................................. 49 Podsumowanie ............................................................................................................................ 50 Źródła ........................................................................................................................................... 51 Rozdział 3. Sharding, Amazon i narodziny systemu NoSQL ............................................... 53 Skalowanie standardu Web 2.0 ................................................................................................. 53 Historia triumfu standardu Web 2.0 ................................................................................. 54 Rozwiązanie open source .................................................................................................... 55 Sharding ................................................................................................................................ 55 Fatalny koniec spowodowany przez tysiąc segmentów .................................................. 57 Twierdzenie CAP ................................................................................................................. 58 Spójność ostateczna ............................................................................................................. 58 System Dynamo firmy Amazon ............................................................................................... 59 Mieszanie spójne .................................................................................................................. 62 Spójność umożliwiająca dostosowanie ............................................................................. 62 System Dynamo i rodzina magazynów klucz-wartość ................................................... 63 Podsumowanie ............................................................................................................................ 65 Źródła ........................................................................................................................................... 65 Rozdział 4. Bazy danych dokumentów .............................................................................. 67 Format XML i bazy danych XML ............................................................................................ 68 Narzędzia i standardy związane z formatem XML ......................................................... 68 Bazy danych XML ................................................................................................................ 69 Obsługa danych XML w systemach relacyjnych ............................................................. 69 Bazy danych dokumentów JSON ............................................................................................. 70 JSON i AJAX ......................................................................................................................... 71 Bazy danych dokumentów JSON ...................................................................................... 71 Modele danych w bazach danych dokumentów .............................................................. 73 Pierwsze bazy danych dokumentów JSON ...................................................................... 74 MemBase i Couchbase ........................................................................................................ 75 MongoDB .............................................................................................................................. 75 Format JSON, wszędzie format JSON .............................................................................. 76 Podsumowanie ............................................................................................................................ 77 6 Poleć książkęKup książkę SPIS TREŚCI Rozdział 5. Tabele nie są przyjazne: grafowe bazy danych ............................................... 79 Czym jest graf? ............................................................................................................................ 79 Wzorce systemu RDBMS związane z grafami ........................................................................ 81 RDF i SPARQL ........................................................................................................................... 82 Grafy właściwości i Neo4j ......................................................................................................... 83 Gremlin ........................................................................................................................................ 84 Wewnętrzne szczegóły baz danych grafów ............................................................................. 86 Silniki obliczeniowe grafów ...................................................................................................... 87 Podsumowanie ............................................................................................................................ 88 Rozdział 6. Kolumnowe bazy danych ................................................................................ 89 Schematy hurtowni danych ...................................................................................................... 89 Alternatywa kolumnowa ........................................................................................................... 91 Kompresja kolumnowa ....................................................................................................... 91 Konsekwencje zapisu kolumnowego ................................................................................ 93 Sybase IQ, C-Store i Vertica ...................................................................................................... 94 Architektury kolumnowych baz danych ................................................................................. 94 Projekcje ................................................................................................................................ 96 Technologia kolumnowa w innych bazach danych ........................................................ 97 Podsumowanie ............................................................................................................................ 98 Źródła ........................................................................................................................................... 98 Rozdział 7. Koniec dysku? Pamięciowe bazy danych i bazy oparte na dyskach SSD ......... 99 Koniec dysku? ............................................................................................................................. 99 Dysk SSD ............................................................................................................................. 100 Ekonomia dysku ................................................................................................................. 101 Bazy danych oparte na dyskach SSD ............................................................................... 102 Pamięciowe bazy danych ......................................................................................................... 103 TimesTen ............................................................................................................................ 104 Redis ..................................................................................................................................... 105 SAP HANA ......................................................................................................................... 107 VoltDB ................................................................................................................................. 109 „Pamięciowa” baza danych Oracle 12c ........................................................................... 111 Stos Berkeley Analytics Data Stack i Spark ........................................................................... 112 Architektura środowiska Spark ........................................................................................ 113 Podsumowanie .......................................................................................................................... 115 Źródła ......................................................................................................................................... 115 Część II Ze wszystkimi szczegółami ............................................................ 117 Rozdział 8. Wzorce rozproszonych baz danych ................................................................ 119 Rozproszone relacyjne bazy danych ...................................................................................... 120 Replikacja ............................................................................................................................ 120 Współużytkowany dysk i brak współużytkowania ....................................................... 120 Nierelacyjne rozproszone bazy danych ................................................................................. 124 7 Poleć książkęKup książkę SPIS TREŚCI Sharding i replikacja w bazie danych MongoDB ................................................................. 125 Sharding .............................................................................................................................. 125 Mechanizmy shardingu ..................................................................................................... 125 Równoważenie klastra ....................................................................................................... 128 Replikacja ............................................................................................................................ 128 Potwierdzenie zapisu i preferowanie odczytu ............................................................... 128 HBase .......................................................................................................................................... 130 Tabele, regiony i serwery regionów ................................................................................. 130 Buforowanie i lokalność danych ...................................................................................... 131 Uporządkowanie oparte na kluczach wierszy ................................................................ 132 Serwer regionów — podziały, równoważenie i awarie ................................................. 133 Repliki regionów ................................................................................................................ 134 Cassandra ................................................................................................................................... 134 Protokół „plotek” ............................................................................................................... 134 Mieszanie spójne ................................................................................................................ 135 „Wtyczki” ............................................................................................................................ 137 Podsumowanie .......................................................................................................................... 140 Rozdział 9. Modele spójności .......................................................................................... 141 Typy spójności .......................................................................................................................... 141 Modele ACID i MVCC ..................................................................................................... 142 Globalne numery sekwencyjne transakcji ...................................................................... 144 Potwierdzanie dwuetapowe .............................................................................................. 144 Inne poziomy spójności .................................................................................................... 144 Spójność w bazie danych MongoDB ..................................................................................... 145 Blokowanie w bazie danych MongoDB .......................................................................... 145 Zestawy replik i spójność ostateczna ............................................................................... 146 Spójność w bazie danych HBase ............................................................................................. 146 Repliki regionów o ewentualnej spójności ..................................................................... 146 Spójność w bazie danych Cassandra ...................................................................................... 147 Współczynnik replikacji ................................................................................................... 148 Spójność zapisu .................................................................................................................. 148 Spójność odczytu ............................................................................................................... 149 Interakcja między poziomami spójności ........................................................................ 150 Mechanizm hinted handoff i naprawianie odczytu ...................................................... 150 Znaczniki czasu i szczegółowość ..................................................................................... 151 Zegary wektorowe .............................................................................................................. 152 Uproszczone transakcje .................................................................................................... 153 Podsumowanie .......................................................................................................................... 157 Rozdział 10. Modele danych i magazynowanie ................................................................ 159 Modele danych .......................................................................................................................... 159 Przegląd relacyjnego modelu danych .............................................................................. 160 Magazyny klucz-wartość ................................................................................................... 160 Modele danych w bazach danych BigTable i HBase ..................................................... 164 Cassandra ............................................................................................................................ 166 Modele danych JSON ........................................................................................................ 168 8 Poleć książkęKup książkę SPIS TREŚCI Magazynowanie ........................................................................................................................ 169 Typowy model magazynu relacyjnego ............................................................................ 170 Drzewa LSM ....................................................................................................................... 172 Dodatkowe indeksowanie ................................................................................................. 175 Podsumowanie .......................................................................................................................... 178 Rozdział 11. Języki i interfejsy programowania ................................................................ 181 Język SQL ................................................................................................................................... 182 Interfejsy API baz danych NoSQL ......................................................................................... 183 Riak ...................................................................................................................................... 183 HBase ................................................................................................................................... 185 MongoDB ............................................................................................................................ 187 Język CQL (Cassandra Query Language) ....................................................................... 189 MapReduce ......................................................................................................................... 191 Pig ......................................................................................................................................... 193 Grafy DAG .......................................................................................................................... 194 Cascading ............................................................................................................................ 195 Spark .................................................................................................................................... 195 Powrót języka SQL ................................................................................................................... 196 Hive ...................................................................................................................................... 197 Impala .................................................................................................................................. 198 Spark SQL ........................................................................................................................... 199 Couchbase N1QL ............................................................................................................... 199 Apache Drill ........................................................................................................................ 201 Inne narzędzia SQL baz danych NoSQL ........................................................................ 203 Podsumowanie .......................................................................................................................... 204 Źródła ......................................................................................................................................... 204 Rozdział 12. Bazy danych przyszłości ................................................................................ 205 Powrót do rewolucji ................................................................................................................. 205 Kontrrewolucje ......................................................................................................................... 206 Czy zatoczono pełne koło? ............................................................................................... 207 Problem z wyborem ........................................................................................................... 208 Czy można mieć wszystko? ..................................................................................................... 208 Modele spójności ............................................................................................................... 209 Schemat ............................................................................................................................... 210 Języki baz danych ............................................................................................................... 211 Przechowywanie ................................................................................................................. 213 Wizja zbieżnej bazy danych .............................................................................................. 214 A tymczasem powróćmy do centrali firmy Oracle .............................................................. 215 Obsługa formatu JSON przez firmę Oracle ................................................................... 216 Uzyskiwanie dostępu do danych JSON za pośrednictwem interfejsu Oracle REST .................................................................. 218 Dostęp do tabel bazy danych Oracle przy użyciu interfejsu REST ............................. 218 Obsługa grafów w bazie danych Oracle .......................................................................... 219 Sharding firmy Oracle ....................................................................................................... 221 Oracle jako hybrydowa baza danych ............................................................................... 222 9 Poleć książkęKup książkę SPIS TREŚCI Inne zbieżne bazy danych ........................................................................................................ 223 Przełomowe technologie baz danych .................................................................................... 224 Technologie magazynowania ........................................................................................... 224 Łańcuch bloków ................................................................................................................. 225 Komputer kwantowy ......................................................................................................... 226 Podsumowanie .......................................................................................................................... 227 Źródła ......................................................................................................................................... 228 Dodatek A Przegląd baz danych ..................................................................................... 229 Aerospike.................................................................................................................................... 230 Cassandra.................................................................................................................................... 230 Couchbase................................................................................................................................... 231 DynamoDB................................................................................................................................. 232 HBase........................................................................................................................................... 232 MarkLogic................................................................................................................................... 233 MongoDB ................................................................................................................................... 234 Neo4j ........................................................................................................................................... 234 NuoDB ........................................................................................................................................ 235 Oracle RDBMS........................................................................................................................... 236 Redis ............................................................................................................................................ 236 Riak.............................................................................................................................................. 237 SAP HANA................................................................................................................................. 238 TimesTen.................................................................................................................................... 238 Vertica......................................................................................................................................... 239 VoltDB ........................................................................................................................................ 239 Skorowidz .................................................................................................... 241 10 Poleć książkęKup książkę R O Z D Z I A Ł 1    Trzy rewolucje związane z bazami danych Urojenie. Szaleństwo. Dopóki się nie wydarzą, wszystkie rewolucje tym są, a potem stają się historycznymi nieuchronnościami. Nadal tkwimy w pierwszych minutach pierwszego dnia rewolucji internetowej. — David Mitchell, Atlas chmur — Scott Cook Książka poświęcona jest trzeciej rewolucji związanej z technologiami baz danych. Pierwsza rewolucja została zainicjowana przez pojawienie się komputera elektronicznego, natomiast druga rewolucja była wynikiem powstania relacyjnej bazy danych. Trzecią rewolucję spowodowała eksplozja alternatyw w postaci nierelacyjnych baz danych, które były odpowiedzią na zapotrzebowanie nowoczesnych aplikacji wymagających globalnego zasięgu i ciągłej dostępności. W rozdziale tym dokonamy przeglądu tych trzech fal technologii baz danych, a także omówimy czynniki rynkowe i technologiczne, które doprowadziły do pojawienia się obecnie używanych baz danych następnej generacji. Na rysunku 1.1 pokazano prostą oś czasu z głównymi systemami baz danych. Na rysunku 1.1 zilustrowano trzy podstawowe okresy związane z technologią baz danych. W ciągu 20 lat następujących od momentu rozpoczęcia powszechnego wykorzystywania komputerów elektronicznych pojawiła się grupa coraz bardziej zaawansowanych systemów baz danych. Krótko po zdefiniowaniu modelu relacyjnego w 1970 r. niemal każdy znaczący system baz danych korzystał ze wspólnej architektury. Trzema filarami tej architektury były: model relacyjny, transakcje ACID (Atomicity, Consistency, Isolation, Durability) i język SQL. Począwszy od około 2008 r. miała jednak miejsce eksplozja nowych systemów baz danych, z których żaden nie opierał się na tradycyjnych implementacjach relacyjnych. Tym nowym systemom baz danych poświęcona jest książka. W niniejszym rozdziale zostanie zaprezentowane, w jaki sposób wcześniejsze fale technologii baz danych doprowadziły do pojawienia się następnej generacji systemów baz danych. Wczesne systemy baz danych W serwisie Wikipedia termin baza danych zdefiniowano jako „zbiór danych zapisanych zgodnie z określonymi regułami”. Choć termin ten pojawił się w używanym słownictwie dopiero pod koniec lat 60., gromadzenie i organizowanie danych stanowiło integralny element rozwoju ludzkiej cywilizacji i technologii. Poleć książkęKup książkę NOSQL, NEWSQL I BIGDATA. BAZY DANYCH NASTĘPNEJ GENERACJI Rysunek 1.1. Oś czasu z głównymi systemami baz danych i ich innowacjami Książki, a zwłaszcza te z wyraźnie narzuconą strukturą, takie jak słowniki i encyklopedie, są zbiorami danych w postaci fizycznej. Biblioteki oraz inne indeksowane archiwa informacji są odpowiednikami nowoczesnych systemów baz danych z czasów przed rozwojem przemysłu. Możliwe jest też dostrzeżenie genezy cyfrowej bazy danych w zastosowaniu kart dziurkowanych oraz innych nośników fizycznych, które mogły przechowywać informacje w postaci pozwalającej na mechaniczne przetwarzanie. W XIX wieku karty krosien służyły do „programowania” krosien tkackich w celu uzyskania złożonych wzorów na materiale. Z kolei w wypadku maszyn licząco-analitycznych stosowano karty dziurkowane do przygotowywania statystyk dotyczących spisu ludności, a w pianolach używano perforowanych pasków papierowych reprezentujących melodie. Na rysunku 1.2 pokazano maszynę licząco-analityczną Holleritha, używaną w 1890 r. do przetwarzania danych dotyczących spisu ludności w Stanach Zjednoczonych. Pojawienie się komputerów elektronicznych po drugiej wojnie światowej stanowiło pierwszą rewolucję związaną z bazami danych. Powstało kilka wczesnych komputerów cyfrowych, które wykonywały funkcje czysto matematyczne, takie jak obliczanie tabel balistycznych. Jednakże równie często miały one za zadanie przetwarzać dane, tak jak w wypadku szyfrowanej komunikacji wojskowej Axis. Początkowo wczesne „bazy danych” korzystały z taśmy papierowej, a ostatecznie do sekwencyjnego przechowywania danych zastosowano taśmę magnetyczną. Choć możliwe było „szybkie przewijanie” i „cofanie” w obrębie takich zbiorów danych, stało się tak dopiero w momencie pojawienia się w połowie lat 50. obrotowego dysku magnetycznego, który umożliwił bezpośredni dostęp z dużą szybkością do poszczególnych rekordów. Bezpośredni dostęp pozwolił na szybki dostęp do dowolnego elementu w obrębie 20 Poleć książkęKup książkę ROZDZIAŁ 1.  TRZY REWOLUCJE ZWIĄZANE Z BAZAMI DANYCH Rysunek 1.2. Maszyny licząco-analityczne i karty dziurkowane używane w 1890 r. do przetwarzania danych dotyczących spisu ludności w Stanach Zjednoczonych pliku o dowolnej wielkości. Rozwój metod indeksowania, takich jak ISAM (ang. Index Sequential Access Method), urzeczywistnił szybki dostęp oparty na rekordach, a w konsekwencji doprowadził do pojawienia się pierwszych systemów komputerowych OLTP (ang. On-line Transaction Processing). Na bazie metody ISAM oraz podobnych struktur indeksowania działały pierwsze elektroniczne bazy danych. Znajdowały się one jednak pod całkowitą kontrolą aplikacji. Były to bazy danych, lecz nie systemy zarządzania bazami danych DBMS (ang. Database Management Systems). Pierwsza rewolucja związana z bazami danych Wymaganie tego, aby każda aplikacja tworzyła własny kod obsługujący dane, stanowiło oczywiście problem związany z efektywnością: każda aplikacja musiała w wypadku bazy danych na nowo „odkrywać koło”. Co więcej, błędy występujące w kodzie obsługującym dane aplikacji nieuchronnie prowadziły do uszkodzenia danych. Zezwolenie wielu użytkownikom na jednoczesny dostęp do danych lub na ich modyfikowanie bez spowodowania logicznego lub fizycznego uszkodzenia danych wymaga zastosowania zaawansowanego kodu. I wreszcie, optymalizacja dostępu do danych z wykorzystaniem buforowania, wstępnego ładowania danych oraz innych technik wymagała użycia złożonych i specjalizowanych algorytmów, które nie mogły być w prosty sposób duplikowane w każdej aplikacji. W związku z tym pożądane stało się wyodrębnienie logiki związanej z obsługą bazy danych z aplikacji i przeniesienie jej do osobnej bazy kodu. Taka warstwa, która nazywana jest systemem DBMS, minimalizuje nakład pracy programistów, a ponadto zapewnia wydajność i integralność funkcji dostępu do danych. We wczesnych systemach baz danych wymuszano zarówno schemat (definicja struktury danych w bazie), jak i ścieżkę dostępu (ustalone metody nawigacji między rekordami). System DBMS mógł na przykład zawierać definicję elementów KLIENT i ZAMÓWIENIE wraz z określoną ścieżką dostępu, która umożliwiała uzyskanie zamówień skojarzonych z konkretnym klientem lub klienta powiązanego z określonym zamówieniem. 21 Poleć książkęKup książkę NOSQL, NEWSQL I BIGDATA. BAZY DANYCH NASTĘPNEJ GENERACJI Takie bazy danych pierwszej generacji działały wyłącznie w ówczesnych systemach komputerowych typu mainframe (głównie produkowanych przez firmę IBM). Z początkiem lat 70. o dominację walczyły ze sobą dwa podstawowe modele systemów DBMS. Model sieciowej bazy danych został sformalizowany w ramach standardu CODASYL i zaimplementowany w bazach danych takich jak IDMS. Z kolei model hierarchiczny zapewniał trochę prostsze rozwiązanie, które najbardziej było widoczne w systemie IMS (ang. Information Management System) firmy IBM. Na rysunku 1.3 porównano strukturalną reprezentację danych tych baz danych. Rysunek 1.3. Model sieciowej bazy danych i model hierarchiczny  Uwaga Te wczesne systemy często opisywano jako z natury „nawigacyjne”, ponieważ w ich wypadku niezbędne jest nawigowanie z jednego obiektu do drugiego przy użyciu wskaźników lub łączników. Aby na przykład znaleźć zamówienie w hierarchicznej bazie danych, może być niezbędne zlokalizowanie najpierw klienta, a następnie użycie łącznika do jego zamówień. Sieciowe i hierarchiczne systemy baz danych dominowały w erze przetwarzania z wykorzystaniem komputerów typu mainframe, a ponadto obsługiwały zdecydowaną większość aplikacji komputerowych do końca lat 70. Systemy te miały jednak kilka znaczących wad. Po pierwsze, nawigacyjne bazy danych cechowały się wyjątkową nieelastycznością w odniesieniu do struktury danych i możliwości tworzenia zapytań. Ogólnie rzecz biorąc, możliwe były tylko zapytania, które mogły zostać przewidziane w początkowej fazie projektowania. Niezmiernie trudne było dodawanie nowych elementów danych do istniejącego systemu. Po drugie, systemy baz danych opierały się na przetwarzaniu transakcji po jednym rekordzie jednocześnie. Obecnie jest to określane za pomocą terminu CRUD (ang. Create, Read, Update, Delete). Operacje zapytań, a zwłaszcza grupa złożonych zapytań analitycznych, które obecnie kojarzone są z analityką biznesową, wymagały tworzenia skomplikowanego kodu. Zapotrzebowanie biznesu związane z raportami 22 Poleć książkęKup książkę ROZDZIAŁ 1.  TRZY REWOLUCJE ZWIĄZANE Z BAZAMI DANYCH analitycznymi szybko się zwiększało wraz z postępującą integracją systemów komputerowych z procesami biznesowymi. W efekcie większość działów informatycznych miała do czynienia z ogromnymi zaległościami związanymi z żądaniami dotyczącymi raportów, a cała generacja programistów tworzyła w języku COBOL pełen powtórzeń kod obsługujący raportowanie. Druga rewolucja związana z bazami danych Bez wątpienia żadna inna osoba nie miała większego wpływu na technologię baz danych niż Edgar Codd. Codd uzyskał tytuł magistra matematyki na uniwersytecie w Oksfordzie niedługo po wybuchu drugiej wojny światowej. Później wyemigrował do Stanów Zjednoczonych, gdzie począwszy od 1949 r. z przerwami pracował dla firmy IBM. Codd pracował na stanowisku „matematyka programującego” (ach, co to były za czasy), a ponadto brał udział w pracach związanych z niektórymi z pierwszych komercyjnych komputerów elektronicznych firmy IBM. Pod koniec lat 60. Codd pracował w laboratorium firmy IBM znajdującym się w San Jose w stanie Kalifornia. W bardzo dużym stopniu był zaznajomiony z bazami danych z tamtych czasów. Miał spore zastrzeżenia do ich budowy. W szczególności zauważył, że:  Korzystanie z istniejących baz danych jest zbyt utrudnione. Bazy danych z tamtych czasów mogły być używane wyłącznie przez osoby dysponujące specjalnymi umiejętnościami programistycznymi.  Istniejące bazy danych są pozbawione podstawy teoretycznej. Wykształcenie matematyczne Codda sprawiło, że dane traktował jako struktury formalne i operacje logiczne. Postrzegał istniejące bazy danych jako stosowanie przypadkowych reprezentacji, które nie zapewniały logicznej spójności ani możliwości radzenia sobie z brakującymi informacjami.  W istniejących bazach danych wymieszano implementacje logiczne i fizyczne. Reprezentacja danych w istniejących bazach danych była dopasowana do formatu magazynu fizycznego w bazie, zamiast mieć postać reprezentacji logicznej danych, która może być zrozumiała dla użytkownika bez wiedzy specjalistycznej. Codd opublikował wewnętrzny dokument firmy IBM, w którym opisał swoje pomysły zapewnienia bardziej sformalizowanego modelu systemów baz danych. Doprowadziło to później do zaprezentowania przez niego w 1970 r. pracy zatytułowanej A Relational Model of Data for Large Shared Data Banks1 (model relacyjny danych w wypadku dużych współużytkowanych banków danych). W tej klasycznej pracy zawarto podstawowe idee definiujące model relacyjnej bazy danych, który stał się dla całej generacji najbardziej znaczącym — niemal uniwersalnym — modelem systemów baz danych. Teoria modelu relacyjnego Zawiłości teorii relacyjnej bazy danych mogą być złożone i wykraczają poza zakres niniejszego wprowadzenia. W zasadzie jednak model relacyjny opisuje to, w jaki sposób konkretny zbiór danych powinien być prezentowany użytkownikowi, a nie to, jak powinien być przechowywany na dysku lub w pamięci. Kluczowe zagadnienia modelu relacyjnego obejmują:  Krotki, czyli nieuporządkowany zbiór wartości atrybutów. W samym systemie baz danych krotka odpowiada wierszowi, a atrybut — wartości kolumny.  Relację, czyli kolekcję różnych krotek odpowiadającą tabeli w implementacjach relacyjnych baz  Ograniczenia wymuszające spójność bazy danych. Ograniczenia klucza służą do identyfikowania danych. krotek i relacji między nimi. 23 Poleć książkęKup książkę NOSQL, NEWSQL I BIGDATA. BAZY DANYCH NASTĘPNEJ GENERACJI  Operacje na relacjach, takie jak złączenia, projekcje czy sumy. Operacje te zawsze zwracają relacje. W praktyce oznacza to, że zapytanie dotyczące tabeli zwraca dane w formacie tabelarycznym. Wiersz w tabeli powinien być możliwy do zidentyfikowania i efektywnie dostępny dla wartości klucza unikatowego. Z kolei każda kolumna w tym wierszu musi być zależna od tej wartości klucza, a nie od żadnego innego identyfikatora. Oznacza to, że tablice oraz inne struktury zawierające zagnieżdżone informacje nie są bezpośrednio obsługiwane. Poziomy zgodności z modelem relacyjnym opisano w różnych postaciach normalnych (ang. normal forms). Najpowszechniejszym poziomem jest trzecia postać normalna. Praktycy używający baz danych zapamiętują zwykle definicję trzeciej postaci normalnej przez utrwalenie sobie, że wszystkie atrybuty niebędące kluczem muszą być zależne od „klucza, całego klucza i tylko od klucza — tu może pomóc tylko Codd”2! Na rysunku 1.4 zaprezentowano przykład normalizacji: dane po lewej stronie reprezentują dość prosty zbiór danych. Występuje w nim jednak redundancja w imieniu studenta i nazwie testu, a użycie dla odpowiedzi testowych powtarzającego się zestawu atrybutów jest wątpliwe (choć jest to możliwe w obrębie postaci relacyjnej, oznacza, że każdy test zawiera taką samą liczbę pytań i utrudnia określone operacje). Pięć tabel po prawej stronie reprezentuje znormalizowaną postać tych danych. Rysunek 1.4. Dane znormalizowane i dane bez normalizacji 24 Poleć książkęKup książkę ROZDZIAŁ 1.  TRZY REWOLUCJE ZWIĄZANE Z BAZAMI DANYCH Modele transakcji Sam model relacyjny nie definiuje sposobu, w jaki baza danych obsługuje współbieżne żądania zmiany danych. Takie zmiany, które ogólnie są określane mianem transakcji w bazie danych, wywołują problemy we wszystkich systemach baz danych z powodu konieczności zapewnienia spójności i integralności danych. Jim Gray zdefiniował pod koniec lat 70. najpowszechniej przyjęty model transakcji. Jak sam to określił, „transakcja jest transformacją stanu, który ma właściwości w postaci niepodzielności (wszystko albo nic), trwałości (efekty są odporne na awarie) i spójności (poprawna transformacja)”3. Wkrótce zostało to spopularyzowane jako transakcje ACID: Atomic (niepodzielność), Consistent (spójność), Independent (niezależność) i Durable (trwałość). Transakcja ACID powinna być:  Niepodzielna. Transakcja jest niepodzielna — albo wszystkie polecenia w transakcji zostaną zastosowane w bazie danych, albo żadne z nich.  Spójna. Baza danych pozostaje w spójnym stanie przed wykonaniem transakcji i po jej wykonaniu.  Izolowana. Choć wiele transakcji może być wykonywanych jednocześnie przez jednego lub wielu użytkowników, jedna transakcja nie powinna mieć dostępu do efektów innych transakcji będących w trakcie realizacji.  Trwała. Po zapisaniu transakcji w bazie danych (w wypadku baz danych SQL odbywa się to za pomocą polecenia COMMIT) związane z nią zmiany mają być trwałe nawet wtedy, gdy nastąpi awaria systemu operacyjnego lub sprzętu. Transakcje ACID stały się standardem we wszystkich poważnych implementacjach baz danych, ale też w największym stopniu zostały powiązane z relacyjnymi bazami danych, które zaczęły się pojawiać mniej więcej w czasie, gdy została opublikowana praca Graya. Jak się później okaże, narzucane przez model transakcji ACID ograniczenie dotyczące skalowalności nieprzekraczającej pojedynczego centrum danych było głównym czynnikiem motywującym do tworzenia nowych architektur baz danych. Pierwsze relacyjne bazy danych Początkowa reakcja na model relacyjny była dość chłodna. Istniejący dostawcy, w tym firma IBM, nie byli skłonni do zaakceptowania podstawowego założenia Codda, zgodnie z którym ówczesne bazy danych oparte były na wadliwym fundamencie. Co więcej, wielu dostawców miało poważne zastrzeżenia co do możliwości zapewnienia przez system odpowiedniej wydajności, jeśli reprezentacja danych nie została dokładnie dopasowana do bazowych mechanizmów dostępu. Czy byłoby możliwe stworzenie systemu baz danych o dużej wydajności, który pozwalałby użytkownikowi na uzyskanie dostępu do danych w dowolny sposób, jaki być może sobie wyobrazi? Firma IBM zainicjowała jednak w 1974 r. program badawczy w celu opracowania prototypowego systemu relacyjnych baz danych o nazwie System R. Pokazał on, że relacyjne bazy danych mogą zapewnić odpowiednią wydajność. Poza tym po raz pierwszy w systemie tym użyto języka SQL (Codd określił, że system relacyjny powinien uwzględniać język zapytań, ale nie definiować konkretnej składni). Również w tym czasie Michael Stonebraker z uczelni w Berkeley rozpoczął pracę nad systemem bazy danych, który ostatecznie przyjął nazwę INGRES. Był to też system relacyjny, ale wykorzystywał język zapytań o nazwie QUEL, który nie był językiem SQL. Na tym etapie w prezentowanej historii pojawia się Larry Ellison. Z natury Ellison był bardziej przedsiębiorcą niż naukowcem, choć dysponował wyjątkową wiedzą techniczną, którą zdobył podczas pracy w firmie Amdahl. Zaznajomiony był zarówno z pracą Codda, jak i z systemem System R. Ellison był przekonany, że relacyjne bazy danych są przyszłością technologii baz danych. W 1977 r. założył firmę, która ostatecznie stała się korporacją Oracle Corporation. Może się ona pochwalić udostępnieniem systemu relacyjnych baz danych, który jako pierwszy odniósł sukces komercyjny. 25 Poleć książkęKup książkę NOSQL, NEWSQL I BIGDATA. BAZY DANYCH NASTĘPNEJ GENERACJI Wojny baz danych! Miało to miejsce w czasie, gdy na rynku pojawiły się minikomputery, które ostatecznie zakończyły dominację komputerów typu mainframe. W porównaniu z obecnym sprzętem komputerowym minikomputery z końca lat 70. i początku lat 80. z trudem można określić mianem „mini”. W przeciwieństwie jednak do komputerów typu mainframe w niewielkim stopniu wymagały specjalistycznych pomieszczeń albo wcale tego nie wymagały. Dzięki temu średniej wielkości firmy po raz pierwszy mogły sobie pozwolić na posiadanie własnej infrastruktury informatycznej. Na tych nowych platformach sprzętowych działały nowe systemy operacyjne. Spowodowało to pojawienie się zapotrzebowania na nowe bazy danych, które mogłyby zostać uruchomione na tych systemach operacyjnych. Około 1981 r. firma IBM udostępniła komercyjną relacyjną bazę danych o nazwie SQL/DS. Ponieważ jednak działała ona tylko na systemach operacyjnych komputerów typu mainframe firmy IBM, nie miała żadnego wpływu na szybko rozwijający się rynek minikomputerów. W 1979 r. pojawiła się komercyjna wersja systemu baz danych Oracle Ellisona, która szybko znalazła zastosowanie w wypadku minikomputerów dostarczanych przez takie firmy jak Digital i Data General. W tym samym czasie w ramach projektu INGRES uczelni w Berkeley powstała komercyjna relacyjna baza danych Ingres. Systemy Oracle i Ingres walczyły o dominację na rozwijającym się dopiero rynku relacyjnych baz danych dla minikomputerów. Około połowy lat 80. powszechnie stały się zrozumiałe, jeśli nie niuanse teorii relacyjnej, to przynajmniej zalety relacyjnej bazy danych. Nabywcy baz danych w szczególności docenili to, że język SQL, który obecnie został zaadaptowany przez wszystkich dostawców, w tym przez system Ingres, zapewniał ogromny wzrost wydajności w zakresie tworzenia raportów i zapytań analitycznych. Ponadto coraz bardziej popularna stawała się następna generacja narzędzi do tworzenia baz danych, znanych wówczas pod nazwą 4GL. Te nowe narzędzia sprawdzały się zwykle najlepiej w wypadku serwerów relacyjnych baz danych. I wreszcie, w porównaniu z komputerami typu mainframe minikomputery oferowały wyraźne korzyści pod względem ceny i uzyskiwanej wydajności, co dotyczyło zwłaszcza segmentu średniej wielkości firm. W tej sytuacji relacyjna baza danych była tak naprawdę jedynym słusznym wyborem. I faktycznie, relacyjne bazy danych w tak dużym stopniu zdominowały świadomość użytkowników, że dostawcy starszych systemów baz danych byli zmuszeni do prezentowania swoich produktów jako również opartych na modelu relacyjnym. Sprowokowało to Codda do sformułowania słynnych 12 postulatów (w rzeczywistości 13 postulatów, gdyż pierwszy z nich ma przypisaną cyfrę 0) jako czegoś w rodzaju sprawdzianu mającego za zadanie odróżnić prawdziwe relacyjne bazy danych od baz, które do tego miana jedynie pretendują. W ciągu kolejnych dekad pojawiło się wiele nowych systemów baz danych. Są to następujące systemy: Sybase, Microsoft SQL Server, Informix, MySQL i DB2. Choć każdy z tych systemów próbuje się wyróżniać znakomitą wydajnością, dostępnością, funkcjonalnością lub ceną, wszystkie one są w zasadzie identyczne pod względem bazowania na trzech podstawowych zasadach: modelu relacyjnym Codda, języku SQL i modelu transakcji ACID.  Uwaga Termin RDBMS (ang. Relational Database Management System) zasadniczo dotyczy bazy danych implementującej relacyjny model danych, obsługującej transakcje ACID i korzystającej z języka SQL na potrzeby zapytań i przetwarzania danych. Model przetwarzania klient-serwer Pod koniec lat 80. model relacyjny osiągnął zdecydowane zwycięstwo w batalii o świadomość użytkowników baz danych. Dominacja ta przełożyła się na dominację na rynku w trakcie przechodzenia do modelu przetwarzania klient-serwer. Pod pewnymi względami minikomputery były małymi komputerami typu mainframe: w wypadku aplikacji minikomputera całe przetwarzanie odbywało się w jego obrębie, a użytkownik prowadził 26 Poleć książkęKup książkę ROZDZIAŁ 1.  TRZY REWOLUCJE ZWIĄZANE Z BAZAMI DANYCH interakcję z aplikacją za pośrednictwem bardzo prostych terminali z zielonym ekranem. Jednakże nawet wtedy, gdy minikomputer stał się podstawą przetwarzania danych biznesowych, nie powstrzymało to nadchodzącej nowej rewolucji związanej z architekturą aplikacji. Zwiększająca się dominacja platform minikomputerów opartych na standardzie IBM PC, a także pojawienie się graficznych interfejsów użytkownika, takich jak obecny w systemie Microsoft Windows, przyczyniły się do powstania nowego modelu aplikacji, czyli modelu klient-serwer. W modelu tym logika warstwy prezentacji została umiejscowiona na terminalu PC pracującym zwykle pod kontrolą systemu Microsoft Windows. Takie programy klienckie bazujące na komputerze PC komunikowały się z serwerem bazy danych, który zazwyczaj działał na minikomputerze. Logika warstwy aplikacji była często skoncentrowana po stronie klienta, ale mogła też być zlokalizowana w obrębie serwera bazy danych, gdy korzystano z procedur przechowywanych, czyli programów działających wewnątrz bazy danych. Architektura klient-serwer zapewniła bogactwo możliwości użytkowych, które były niespotykane w czasach „zielonego ekranu”. Z początkiem lat 90. w zasadzie wszystkie nowe aplikacje aspirowały do tego, by być zgodne z tą architekturą. Praktycznie we wszystkich platformach do tworzenia klientów używano serwera RDBMS. I w rzeczy samej język SQL był zazwyczaj uznawany za „wehikuł” dla wszystkich żądań między klientem i serwerem. Programowanie obiektowe i system OODBMS Niedługo po rewolucji w postaci modelu klient-serwer na powszechnie używane języki do tworzenia aplikacji wpłynęło przejście do kolejnego znaczącego modelu. W tradycyjnych, proceduralnych językach programowania dane i logika były w zasadzie rozdzielone. Procedury ładowały i przetwarzały dane w obrębie własnej logiki, ale sama procedura nie uwzględniała danych w żaden istotny sposób. Programowanie obiektowe dokonało scalenia w jeden obiekt atrybutów i działań. Oznacza to na przykład, że obiekt pracownika może reprezentować strukturę rekordów pracowników, a także operacje, które mogą być wykonywane na tych rekordach (zmiana pensji, awans, przejście na emeryturę itp.). W niniejszym omówieniu dwiema najistotniejszymi zasadami programowania obiektowego są:  Hermetyzacja. Klasa obiektów hermetyzuje zarówno dane, jak i działania (metody), które mogą być wykonywane na tych danych. Okazuje się, że obiekt może ograniczyć bezpośredni dostęp do bazowych danych, wymagając, aby modyfikacje danych były możliwe tylko za pośrednictwem metod obiektu. Na przykład klasa pracowników może uwzględniać metodę uzyskującą wysokość pensji oraz kolejną metodę modyfikującą tę wartość. Metoda ta może zawierać ograniczenia dotyczące minimalnej i maksymalnej wysokości pensji, a klasa może nie zezwalać na żadne modyfikowanie wysokości pensji poza obrębem tych metod.  Dziedziczenie. Klasy obiektów mogą dziedziczyć właściwości klasy nadrzędnej. Klasa pracowników może dziedziczyć wszystkie właściwości klasy osób (datę urodzenia, imię itp.) w trakcie dodawania właściwości i metod, takich jak wysokość pensji czy data zatrudnienia. Programowanie obiektowe oznaczało ogromne zwiększenie efektywności pracy programistów, niezawodności aplikacji i wydajności. W latach 80. i na początku lat 90. większość języków programowania została dostosowana do modelu obiektowego, a także pojawiło się wiele znaczących nowych języków, takich jak Java, które z założenia były obiektowe. Rewolucja związana z programowaniem obiektowym przygotowała grunt pod pierwsze poważne wyzwanie postawione przed relacyjną bazą danych, które pojawiło się w połowie lat 90. Projektanci używający języków obiektowych byli sfrustrowani tym, co uznali za wyjątkowo kłopotliwą niezgodność między reprezentacjami obiektowymi swoich danych wewnątrz tworzonych programów a reprezentacją relacyjną w bazie danych. W programie obiektowym wszystkie szczegóły związane z roboczą jednostką logiczną byłyby przechowywane wewnątrz jednej klasy lub bezpośrednio z nią połączone. Na przykład obiekt klienta zawierałby wszystkie szczegóły dotyczące klienta z łączami prowadzącymi do obiektów zawierających zamówienia klienta. Z kolei te obiekty zawierałyby łącza do pozycji zamówienia. Taka reprezentacja z natury 27 Poleć książkęKup książkę NOSQL, NEWSQL I BIGDATA. BAZY DANYCH NASTĘPNEJ GENERACJI była nierelacyjna. Tak naprawdę reprezentacja danych w większym stopniu była zgodna z sieciowymi bazami danych z czasów konsorcjum CODASYL. Gdy obiekt był zapisywany w relacyjnej bazie danych lub z niej pobierany, niezbędnych było wiele operacji SQL do dokonania konwersji reprezentacji obiektowej na reprezentację relacyjną. Było to kłopotliwe dla programisty i mogło spowodować problemy związane z wydajnością lub niezawodnością. Problem ten zilustrowano na rysunku 1.5. Rysunek 1.5. Zapisywanie obiektu w systemie RDBMS wymaga wykonania wielu operacji SQL Zwolennicy programowania obiektowego zaczęli postrzegać relacyjną bazę danych jako relikt proceduralnej przeszłości. Spowodowało to powstanie raczej niechlubnego powiedzenia: „Relacyjna baza danych jest jak garaż, który zmusza do rozłożenia samochodu na części i przechowywania ich w małych szufladkach”. Szybkie powodzenie programowania obiektowego niemal nieuchronnie doprowadziło do stwierdzenia, że system OODBMS (ang. Object Oriented Database Management System) jest lepiej dostosowany do spełnienia wymagań nowoczesnych aplikacji. System ten był w stanie przechowywać obiekty programu bezpośrednio bez normalizacji, a ponadto umożliwiał aplikacjom łatwe ładowanie i zapisywanie ich obiektów. Przejście do obiektowej bazy danych spowodowało powstanie manifestu, w którym wyszczególniono kluczowe argumenty popierające system OODBMS oraz jego właściwości4. Pod względem implementacji system OODBMS przypomina model nawigacyjny z czasów przed pojawieniem się modelu relacyjnego — wskaźniki w obrębie jednego obiektu (na przykład obiekt klienta) umożliwiały przejście do powiązanych obiektów, takich jak obiekty zamówień. Wsparcie modelu systemu OODBMS zwiększyło się w połowie lat 90. Dla wielu osób naturalne wydało się, że system ten będzie logicznym sukcesorem systemu RDBMS. Istniejący w tamtym czasie dostawcy relacyjnych baz danych (chodzi głównie o firmy Oracle, Informix, Sybase i IBM) szybko zaczęli stosować elementy systemu OODBMS w swoich systemach RDBMS. Tymczasem zaprojektowanych zostało kilka czystych systemów OODBMS, które zyskały początkowo uznanie. Jednak pod koniec dekady systemom OODBMS zupełnie nie powiodło się zwiększenie udziału w rynku. Główni dostawcy baz danych, tacy jak Oracle i Informix, z powodzeniem zaimplementowali wiele elementów systemu OODBMS, ale nawet one były rzadko używane. Programiści korzystający z języków obiektowych ponownie sięgali po systemy RDBMS, aby zapewnić trwałość obiektów. 28 Poleć książkęKup książkę ROZDZIAŁ 1.  TRZY REWOLUCJE ZWIĄZANE Z BAZAMI DANYCH Utrudnienia zostały w pewnym stopniu zniwelowane za pomocą środowisk ORM (ang. Object-Relational Mapping), które automatyzowały większość uciążliwych aspektów translacji. Istnieją rywalizujące ze sobą i niekoniecznie sprzeczne wyjaśnienia niepowodzenia obiektowych baz danych. Osobiście uważam, że zwolennicy modelu systemu OODBMS skoncentrowali się wyłącznie na zaletach, jakie oferował on projektantowi aplikacji, ignorując wady nowego modelu mające znaczenie dla osób, które zamierzały wykorzystywać informacje do celów biznesowych. Bazy danych nie mają po prostu zapewniać korzyści jedynie programistom. Reprezentują znaczące zasoby, które muszą być dostępne dla osób, które wymagają informacji w celu podejmowania decyzji i przeprowadzania analiz biznesowych. Implementując model danych, który mógł być używany tylko przez programistę, i pozbawiając użytkownika biznesowego przydatnego interfejsu SQL, system OODBMS nie zyskał uznania poza kręgami programistów. Jak się jednak okaże w rozdziale 4., motywy związane z systemem OODBMS w dużym stopniu wpłynęły na kilka najpopularniejszych nierelacyjnych baz danych, które są obecnie stosowane. Okres stabilizacji relacyjnych baz danych Podekscytowanie związane z obiektowymi bazami danych minęło, a relacyjne bazy danych pozostały niezagrożone aż do kolejnych lat po 2005 r. Okazuje się, że w okresie liczącym w przybliżeniu 10 lat (od 1995 r. do 2005 r.) nie pojawiły się żadne nowe znaczące bazy danych. Dostępna była już wystarczająca liczba systemów RDBMS, aby nasycić rynek. Kontrola, jaką na rynku sprawował model systemu RDBMS, oznaczała, że nie mogły zaistnieć żadne alternatywy w postaci modeli nierelacyjnych. Biorąc pod uwagę, że okres ten w zasadzie jest czasem, w którym Internet przeobraził się z ciekawostki dla informatyków w wszechobecną sieć globalną, zaskakujące jest to, że nie pojawiły się w tym czasie żadne nowe architektury baz danych. Świadczy to o sile modelu relacyjnego. Trzecia rewolucja związana z bazami danych Około 2005 r. relacyjne bazy danych wydawały się mieć całkowicie ugruntowaną pozycję. Począwszy od tego roku, choć widoczne były ciągłe i znaczące innowacje istniejących wtedy systemów relacyjnych baz danych, nie było żadnych oznak radykalnych zmian. Okazuje się jednak, że era całkowitej supremacji relacyjnych baz danych dobiegała właśnie końca. W szczególności różnica między architekturami aplikacji używanymi w czasach modelu klient-serwer i w czasach ogromnych aplikacji internetowych spowodowała obciążenia dotyczące relacyjnej bazy danych, które nie mogły zostać wyeliminowane drogą stopniowej innowacji. Google i Hadoop Około 2005 r. witryna internetowa firmy Google była największa na świecie. Taki stan rzeczy utrzymywał się przez kilka lat od powstania tej firmy. Gdy rozpoczynała ona swoją działalność, relacyjna baza danych miała już dobrze ugruntowaną pozycję. Nie była jednak odpowiednia do tego, by poradzić sobie z takimi ilościami danych (a także z ich zmiennością), z jakimi miała do czynienia firma Google. Wyzwania, przed jakimi stoją obecnie przedsiębiorstwa w związku z „dużymi danymi”, to problemy, z którymi firma Google borykała się po raz pierwszy niemal 20 lat temu. Bardzo wcześnie firma ta musiała zaprojektować nowe architektury sprzętowe i programowe, aby przechowywać i przetwarzać dane witryn internetowych wymagających zindeksowania, których liczba zwiększała się w tempie wykładniczym. W 2003 r. firma Google zaprezentowała szczegóły rozproszonego systemu plików GFS, który stanowił podwaliny opracowanej przez nią architektury magazynowania5. W 2004 r. firma ujawniła szczegóły algorytmu rozproszonego przetwarzania równoległego MapReduce, który został wykorzystany do tworzenia indeksów witryn internetowych6. W 2006 r. firma przedstawiła szczegóły
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

NoSQL, NewSQL i BigData. Bazy danych następnej generacji
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: