| Abstract | Relacijske baze podataka podupiru većinu poslovnih sustava današnjice. Funkcionalnost i pouzdanost ovih baza podataka provjerena je mnogim godinama njihovog korištenja. No ipak organizacije sve više uzimaju u obzir drugačija rješenja za svoje poslovne probleme. Motivacije za to su razne. Od tehničkih – potreba za upravljanjem novim tipovima podataka različitih struktura, potreba za razmještanjem podataka van ograničenja mogućnosti trenutnih sustava. Preko ekonomskih – želja za pronalaskom alternativnih rješenja skupih namjenskih sustava poznatih proizvođača, kako hardverskih tako i softverskih. Sve do praktičnih - nove metodologije razvojnih inženjera baziraju se na agilnosti i brzini razvoja, u svrhu efikasnije prilagodbe trenutnim zahtjevima tržišta. Skup rješenja, implementacija i tehnologija koja nisu dio relacijskog ekosustava te udovoljavaju aktualnim tehnološkim trendovima današnjice, počela su se okupljati pod zajedničkom kategorijom ne-relacijskih sustava za upravljanjem bazama podataka, popularno zvanih NoSQL baze podataka. U usporedbi s relacijskim bazama podataka, NoSQL sustavi dijele nekoliko ključnih karakteristika: fleksibilniji model podataka, veća skalabilnost, superiornije performanse. Istovremeno, NoSQL rješenja, kao kompromis za bolje izvođenje, odbacuju temelje koje čine relacijske baze podataka korisnima generacijama aplikacija, kao što su ekspresivan upitni jezik, visoka konzistentnost podataka te sekundarni indeksi. NoSQL baze podataka možemo podijeliti na četiri tipa s obzirom na to koji model pohranjivanja podataka koristimo:
Ključ-vrijednost baze podataka
Ključ-vrijednost baze podataka jednostavne su i fleksibilne za korištenje. Osnovne odlike su im brzina pristupa podacima te visoka mogućnost skaliranja. Imaju osnovnu arhitekturu asocijativnog polja koja dopušta pohranu raznih tipova podataka za vrijednost indeksa polja, kojeg zovemo ključ. Ključevi moraju biti jedinstveni unutar imenika i koristimo ih za dohvat i spremanje podataka različitih struktura i veličina. Neke nedostatke, poput nedostatka jezika upita, mogu se ublažiti korištenjem oblikovnih obrazaca ili zasebnih alata.
Dokument baze podataka
Dokumenti u dokument bazama podataka predstavljaju hijerarhijske fleksibilne strukture koje ne zahtijevaju predefiniranu shemu. Organizirani su u logički povezane skupove koje nazivamo kolekcijama. Kolekcije sadrže dokumente koji imaju slične tipove entiteta, iako im se ključevi i vrijednosti međusobno mogu razlikovati. Denormalizacija, indeksi i način pretrage dokumenata igraju ključnu ulogu u dobroj izvedbi ovih baza podataka. Preporučljivo je koristiti oblikovne obrasce pri oblikovanju hijerarhijskih veza, mnogo-namnogo veza, kao i jedna-na-mnogo veza. Ponekad se dokumenti umeću jedni u druge, a ponekad se međusobno referenciraju, ovisno o tipu veze.
Stupčane baze podataka
Stupčane baze podataka najviše su skalabilne od svih NoSQL baza podataka. Stoga podržavaju visoku dostupnost podataka, čak i preko više podatkovnih centara. Osmišljene su za rad nad velikim skupinama podataka. Poželjno je pri radu s takvim podacima koristi zasebne i ugrađene alate osmišljene za brz prijenos, analizu i upravljanje Velikim Podacima. Osnovne logičke komponente ovih baza podataka su imenici, familije stupaca, stupci i ključevi redaka. Fleksibilne su po pitanju tipa i strukture podataka koji se pohranjuju te omogućavaju dinamičko mijenjanje stupaca unutar familije stupaca.
Graf baze podataka
Teorija grafova pruža solidnu podlogu metoda i algoritama za oblikovanje podataka po modelu grafa i analizom veza među njima. Grafovi se sastoje od dvije osnovne komponente, čvorova kojima modeliramo entitete te bridova kojima modeliramo veze među entitetima. S obzirom na to koje vrste veza koje prikazujemo, bridovi mogu biti usmjereni ili neusmjereni. Graf model, unatoč svojoj jednostavnosti, može imati cijeli spektar svojstava. Time omogućava široku primjenu modela pri oblikovanju kako apstraktnih tako i stvarnih međusobno povezanih pojava i objekata. |
| Abstract (english) | Relational databases have a long-standing position in most organizations, and for good reason. Their functionality and reliability has clearly been proven over time. But organizations are increasingly considering alternatives to legacy relational infrastructure. In some cases the motivation is technical — such as a need to handle new, multi-structured data types or scale beyond the capacity constraints of existing systems — while in other cases the motivation is driven by the desire to identify viable alternatives to expensive proprietary database software and hardware. A third motivation is agility or speed of development, as companies look to adapt to the market more quickly and embrace agile development methodologies. The term “NoSQL” started to make an umbrella category for all non-relational databases that satisfy to some extent these principles. When compared to relational databases, many NoSQL systems share several key characteristics including a more flexible data model, higher scalability, and superior performance. But most of these NoSQL databases also discard the very foundation that has made relational databases so useful for generations of applications - expressive query language, secondary indexes and strong consistency. We can group NoSQL databases into four distinct models:
Key-Value databases
Key-value databases are simple and flexible but they satisfy the need of fast retrieval services and high scalability options. They are based on the associative array, which is a more generalized data structure than arrays. Keys may be integers, strings, lists of values, or other types. An important constraint on keys is that they must be unique within a namespace. Keys are used to look up values and those values can vary by type. Some of the limitations of key-value databases, such as lack of query language, are mitigated with additional features such as search tools.
Document databases
Documents are flexible data structures that do not require predefined schemas. Documents are organized into related sets called collections. Collections should contain similar types of entities, although the keys and values may differ across documents. Denormalization, query processors and indexes play crucial roles in the overall performance of document databases. It helps to use design patterns when modeling common relations such as one-to-many, many-to-many, and hierarchies. Sometimes embedded documents are called for, whereas in other cases, references to other document identifiers are a better option when modeling these relations.
Column databases
Column family databases are some of the most scalable databases available. They also support high availability, even cross-data center availability. Column family databases are designed for large volumes of data. It helps to use tools designed specifically for moving, processing, and managing Big Data and Big Data systems. They are flexible in regard to the type of data stored and the structure of schemas. They provide developers with the flexibility to change the columns of a column family. The basic, logical components of a column family database are namespaces, column families, columns, and row keys.
Graph databases
Graph theory provides a solid foundation of methods and algorithms for building graph databases and analyzing relations between entities. Graphs are composed of two simple components: vertices that represent entities and edges that represent relationships between entities. Depending on the types of relations, edges may be directed or undirected. This simplicity quickly gives way to a broad range of graph properties and features that are useful for modeling a number of phenomena. |
