студиска програма по Инженерство и менаџмент на софтверски апликации

Втор циклус

“Перформанси на NoSQL при работа со

големи количества податоци и web апликации во реално време”

магистерски труд

Ментор Изработил Ред. проф. д-р Виолета Маневска

Смилевска Анета157/11/II

Битола,2017 година

Универзитет „Св. Климент Охридски“ – Битола

ФАКУЛТЕТ ЗА ИНФОРМАТИЧКИ И КОМУНИКЦИСКИ ТЕХНОЛОГИИ – БИТОЛА

2

АКРОНИМИ: 4

АПСТРАКТ 6

ABSTRACT 7

1 РАЗВОЈ И КОРИСТЕЊЕ НА БАЗИ НА ПОДАТОЦИ СО SQL И NOSQL 8

1.1 ДИЗАЈНИРАЊЕ НА БАЗИТЕ НА ПОДАТОЦИ 9 1.2 МОДЕЛИ НА ПОДАТОЦИ 12 1.2.1 РЕЛАЦИОНЕН МОДЕЛ 14 1.2.2 КЛУЧ-ВРЕДНОСТ БАЗИ НА ПОДАТОЦИ 15 1.2.3 КОЛОНА-ОРИЕНТИРАНИ БАЗИ НА ПОДАТОЦИ 15 1.2.4 ДОКУМЕНТ-ОРИЕНТИРАНИ БАЗИ НА ПОДАТОЦИ 17 1.2.5 ГРАФ-БАЗИРАНИ БАЗИ НА ПОДАТОЦИ 18 1.3 КРЕИРАЊЕ И КОРИСТЕЊЕ НА БАЗИТЕ НА ПОДАТОЦИ 19 1.4 ОКОЛИНА И АРХИТЕКТУРА 22 1.5 КОНЗИСТЕНТНОСТ 24 1.5.1 ЕВЕНТУАЛНА КОНЗИСТЕНТНОСТ 26 1.6 ТРАНСАКЦИИ И ПОДАТОЧЕН ИНТЕГРИТЕТ 27 1.7 МИГРАЦИЈА НА ШЕМИ 29 1.7.1 МИГРИРАЊЕ НА ПОДАТОЦИ ЗА ВРЕМЕ НА ЧИТАЊЕ 32 1.7.2 ХИБРИДЕН ПРИСТАП 33 1.8 КАРАКТЕРИСТИКИ НА ПРАШАЛНИЦИ И ПОГЛЕДИ 33 1.8.1 ПОГЛЕДИ 34 1.9 ВИЗУЕЛИЗАЦИЈА 35

2 АДМИНИСТРИРАЊЕ НА БАЗИ НА ПОДАТОЦИ 38

2.1 УПРАВУВАЊЕ СО КОРИСНИЦИ И ПРИВИЛЕГИИ 38 2.1.1 КРЕИРАЊЕ И КОРИСТЕЊЕ НОВИ КОРИСНИЦИ 39 2.1.2 ЛОКАЛНИ И ДАЛЕЧИНСКИ (REMOTE) КОРИСНИЦИ 40 2.1.3 ПРИВИЛЕГИИ И ПЕРФОРМАНСИ 41 2.2 ЛОГИРАЊЕ 41 2.2.1 ДАТОТЕКИ НА ЛОГОВИ 41 2.3 ПАРТИЦИОНИРАЊЕ 43 2.3.1 РАНГ ПАРТИЦИОНИРАЊЕ 45 2.3.2 ЛИСТА ПАРТИЦИОНИРАЊЕ 45 2.3.3 ХЕШ ПАРТИЦИОНИРАЊЕ 45 2.3.4 КЛУЧ ПАРТИЦИОНИРАЊЕ 46 2.3.5 КОМПОЗИТНО ПАРТИЦИОНИРАЊЕ 46 2.3.6 ФУНКЦИОНАЛНО ПАРТИЦИОНИРАЊЕ 46 2.4 МОНИТОРИРАЊЕ 47 2.4.1 КОНФИГУРИРАЊЕ НА ОПЦИИТЕ ЗА MYSQL MONITOR 47 2.4.2 МОНИТОРИРАЊЕ НА MONGODB 47 2.5 БЕКАПИ И ОБНОВУВАЊЕ 49 2.5.1 КОРИСТЕЊЕ НА БЕКАПИ 49 2.5.2 ФРЕКВЕНЦИЈА НА БЕКАПИРАЊЕ 50 2.5.3 MYSQL БЕКАПИРАЊЕ 51 2.5.4 БЕКАПИ И ОБНОВУВАЊЕ КАЈ MONGODB 53

3

2.6 КЕШИРАЊЕ 55 2.6.1 КЕШ ТАБЕЛИ 56 2.6.2 РАБОТА СО КЕШ ЗА ПРАШАЛНИЦИ 56 2.7 ПЕРФОРМАНСИ 58 2.7.1 ПРОФИЛИРАЊЕ 59 2.7.2 БЕНЧМАРКИРАЊЕ 59

3 ВИСОКО ДОСТАПНИ ОКОЛИНИ 62

3.1 СКАЛИРАЊЕ И ВИСОКО ДОСТАПНИ АРХИТЕКТУРИ 62 3.1.1 ВЕРТИКАЛНО СКАЛИРАЊЕ 63 3.1.2 ХОРИЗОНТАЛНО СКАЛИРАЊЕ 63 3.1.3 ЛИНЕАРНО СКАЛИРАЊЕ И ЕКСПРЕСИВНОСТ 65 3.1.4 ХОРИЗОНТАЛНО ИЛИ ВЕРТИКАЛНО СКАЛИРАЊЕ 65 3.2 РЕШЕНИЈА ЗА ПРЕСМЕТУВАЊЕ ВО ОБЛАК 66 3.2.1 ШТО Е ПРЕСМЕТУВАЊЕ ВО ОБЛАК (CLOUD COMPUTING)? 66 3.2.2 АРХИТЕКТУРИ НА ОБЛАК 68 3.2.3 SQL И NOSQL БАЗИ НА ПОДАТОЦИ ВО ОБЛАК 70 3.2.4 ПРИДОБИВКИ И РИЗИЦИ ОД ПРЕСМЕТУВАЊЕ ВО ОБЛАК 71 3.2.5 ДАЛИ ПРЕСМЕТУВАЊЕТО ВО ОБЛАК Е ЕКОНОМИЧЕН ИЗБОР? 72 3.3 КЛАСТЕР 73 3.3.1 ИЗБИРАЊЕ НА КЛУЧ ЗА ФРАГМЕНТИРАЊЕ 75 3.3.2 ОГРАНИЧУВАЊА 76 3.3.3 MYSQL CLUSTER 76 3.4 API И КОНЕКТОРИ 78

4 ИЗБОР НА БАЗА НА ПОДАТОЦИ 80

4.1 ПРОГРАМЕРСКА ПРОДУКТИВНОСТ 81 4.2 ПЕРФОРМАНСИ НА ПРИСТАП ДО ПОДАТОЦИ 82 4.2.1 ДОСТАПНОСТ НА ПОДАТОЦИ 82 4.2.2 ПРИСТАП ДО ДОКУМЕНТИ ВО MONGODB 84 4.2.3 ПЕРФОРМАНСИ НА ПРИСТАП ДО ПОДАТОЦИ 85

5 СТУДИЈА НА СЛУЧАЈ – ТЕСТИРАЊЕ НА ПЕРФОРМАНСИТЕ НА ПРЕТСТАВНИЦИ НА SQL И NOSQL БАЗИ НА ПОДАТОЦИ 86

5.1 ПОДГОТОВКА НА ПЛАНОТ ЗА ТЕСТИРАЊЕ 87 5.2 РЕЗУЛТАТИ ОД ТЕСТОВИТЕ 88 5.2.1 ЗАПИШУВАЊЕ НА ПОДАТОЦИ 88 5.2.2 ЧИТАЊЕ НА ПОДАТОЦИ 99

6 ЗАКЛУЧОК 111

7 КОРИСТЕНА ЛИТЕРАТУРА 113

4

Акроними:

ACID – Atomicity, Consistency, Isolation and Durability

Amazon’s EC2 - Elastic Compute Cloud

AMI - Amazon Machine Image

API– Aplication Program Interface

ASP - Application Service Provider

BSON – Binary Structured Object Nation

CAP – Consistency, Availability and Partition Tolerance

CPU– Central Processing Unit

CRUD – Create, Read, Update and Delete

DBMS – Database Management System – СУБП

DDL – Data Definition Language

DML – Data Manipulation Language

DNS– Domain Name System

GAE - Google App Engine

HTTP – HyperText Transfer Protocol

IaaS– Infrastructure as a Service

IOPS– Input/Output Per Second

IP – Internet Protocol

I/O– Input/Output

JDBC– Java Database Connectivity

JSON– JavaScript Object Notation

NDB – Network database

NDBD – Network database deamon

NDB_MGMD – Network database management deamon

NIST - National Institute of Standards and Technology

NoSQL – Not Only Structured Query Language

ODBC driver - Open Database Connectivity

ODM – Object Document Mapper

OLAP– Online Analytical Processing

OLTP– Online Transaction Processing

PaaS– Platform as a Service

QA– Quality Assurance

5

RAM – Random Access Memory

RDBMS – Relational Database Management System - РСУБП

RDS - Amazon Relational Database Service

REST – Representational State Transfer

SaaS– Software as a Service

SDK – Software Development Kit

SLA – Service Level Agreement

SOAP – Simple Object Access Protocol

SQL–Structured Query Language

TCP/IP – Transmission Control Protocol/Internet Protocol

URI – Uniform Resource Identifier

URL - Uniform Resource Locator

YCSB- Yahoo Cloud Servicing Benchmark

6

Апстракт

Податоците растат побрзо од било кога и до 2020 година, околку 1.7 мегабајти

нови податоци ќе се создаваат секоја секунда за секој човек на планетата. Затоа бизнисот

во голем дел зависи од технологијата на базите на податоци.

Изминатиот половина век од појавата и развојот на базите на податоци е период

на паралелна појава и развој и на различни модели на податоци. Тоа е период во кој се

постигна огромен напредок во сферата на информатиката и компјутерските науки, но и

период во кој релационите бази на податоци го задржаа приматот при креирањето и

работењето со базите на податоци.

SQL е еден од првите комерцијални и можеби најактуелен доменски базиран јазик

кој е лесен за изучување, со ограничен вокабулар, недвосмислена граматика и едноставна

синтакса, но се темели на релационата алгебра која работи добро само со релационите

бази на податоци.

Наспроти SQL, NoSQL движењето познато како „Not only SQL“ кое започна 2009

година ја преферира генералната употреба, ограничувањата на релационите системи за

управување со бази на податоци и цената на многу NoSQL решенија.

Во таа насока, во овој труд се поставени и сумирани основните разлики меѓу SQL

и NoSQL базите на податоци и како да се одлучи која база на податоци е посоодветна за

даден проектот.

Клучни зборови: бази на податоци, SQL, NoSQL, бази на податоци без шема,

бенчмаркирање.

7

Abstract

Data is growing faster than ever before and by the year 2020, about 1.7 megabytes of

new information will be created every second for every human being on the planet. That’s why

the business in much of world depends on database technology.

The past half-century since the emergence and development of databases is a period of

parallel occurrence and development of different data models. It is a period in which great

progress has been achieved in the field of information and computer science, but also a period

in which relational databases have retained the primacy in creating and working with databases.

SQL is one of the first commercial and perhaps the most current domain-specific

language that is easy to learn, with limited vocabulary, unambiguous grammar and simple

sintax, but is based on the relational algebra that works well with relational databases only.

In contrast to SQL, the NoSQL movement known as “Not only SQL” that started in

2009, prefers general usage, the constraints of relational database management systems and cost

of many NoSQL solutions.

In this regard, this paper has a task to introduce and summarize the primary differences

between SQL and NoSQL database, and how to make a decision which database is more

appropriate for a given project.

Key words: databases, SQL, NoSQL, schemaless databases, benchmarking.

8

1 Развој и користење на бази на податоци со SQL и

NoSQL

Многу од денешните бизниси се потпираат на сопствените системи за управување

собази на податоци за добивање на точни, ажурни информации. Без овие складишта на

критични податоци, повеќето бизниси не би биле способни да ги извршуваат нивните

нормални дневни трансакции и да креираат извештаи кои ќе им помагаат на менаџментот

да донесува стратешки одлуки. За да бидат корисни, податоците во базите мора да бидат

навремени, комплетни и организирани на начин на кој податоците лесно би можеле да

се извлечат кога има потреба за тоа и во бараниот формат.

Добро пишаните апликации за бази на податоци, без разлика дали се извршуваат

локално или преку мрежа, се фундаментални за навремено и брзо преземање на

податоците. Како и да е, без добра основа за дизајн на базите на податоци, дури и

најдобрите програми не би можеле да се справат со проблемите на точни и конзистентни

податоци.

Добар дизајн на базите на податоци подразбира добро планирање на база на

податоци пред таа да се стави во употреба. Тоа значи фокусирање на начинот на кој

бизнисот работи и специфицирање на базите на податоци според спецификациите на

самата организација. Треба да се добие база на податоци која ќе ги пресретне потребите

на компанијата и ќе овозможува секој да користи навремени и комплетни информации.

SQL и релационите модели генерално беа дизајнирани за интеракција со крајниот

корисник. Оваа кориснички ориентирана природа има некои импликации. Крајниот

корисник често се интересира за агрегирање на извештаи, а SQL има големо влијание на

тој аспект. Никој не очекува корисникот да има експлицитна контрола на

конкурентноста, интегритетот, конзистентноста или валидацијата на типот на

податоците. Затоа SQL обрнува големо внимание на гарантирање на трансакциите,

шемите и референтниот интегритет.

Од друга страна пак, софтверските апликации не се често заинтересирани за

агрегација и способност за контрола, а во многу случаи и за интегритетот и валидацијата

на истите. Заради ова, елиминацијата на овие карактеристики може екстремно да ги

подобри перформансите и скалабилноста на базите на податоци. Ова доведе до нова

еволуција на моделите на податоци.

9

1.1 Дизајнирање на базите на податоци

Дизајнерите на базите на податоци, постојано се во потрага по најдобрите можни

решенија. Базата на податоци е репрезентација на физичка или концептуална структура,

како на пример организација, збир на автомобили или статистички информации за

популацијата во одредена држава и слично. Дизајнирањето на базата е процес на

производство на модел за базата на податоци. Вложениот труд при дизајнирањето на

базата на податоци би требало да зависи од типот на информации кои што треба да се

извлекуваат од неа. Внесувањето премногу детали во базата на податоци е губење на

труд, време и простор од хард дискот, додека пак содржењето премалку детали може да

ја направи безвредна. Затоа треба правилно да се утврди колку детали се потребни и

колку би биле потребни во иднина – и тогаш да се обезбеди точно ниво на детали во

дизајнот. Но, во иднина голема е веројатноста да се наметне потребата за менување на

дизајнот за да се пресретнат потребите од реалниот свет.

Денешните системи на бази на податоци, полни со атрактивни графички

кориснички интерфејси и интуитивни алатки за дизајн, може да му дадат на дизајнерот

на базата на податоци лажно чувство на сигурност. Овие системи го прават

дизајнирањето на базата на податоци да изгледа слично со градење на табела или

ангажирање на некоја друга релативно лесна задача. Дизајнирањето на базата на

податоци е тешко. Доколку се направи погрешно, базата на податоци ќе страда од лоши

перформанси, и тоа може да станува полошо како што врви времето. Со текот на времето

може да се забележи проблемот. Во многу случаи, единствено решение е комплетно

редизајнирање на базата на податоци и повторно внесување на податоци.

Постојат три важни фази во дизајнирањето на базата на податоци:

1. Анализа на барањата

Прво, се утврдува и запишува што точно е потребно за базата на податоци, кои податоци

ќе се чуваат и како податочните елементи се однесуваат еден со друг. Во пракса, ова

може да вклучува детална студија на апликациски барања и разговори со луѓето во

различни улоги кои ќе ги користат базите на податоци и апликацијата.

2. Концептуален дизајн

Откако ќе се утврдат барањата за базата на податоци, тие се дестилираат со формален

опис на дизајнот на базите на податоци.

3. Логички дизајн

10

Конечно може да се мапира дизајнот на базата на податоци во вистински СУБП (Систем

за управување со бази на податоци) и табели на базите на податоци.

Дизајнирањето на шемата на базата на податоци кај SQL базите на податоци е

процес на избирање на најдобра репрезентација на множество на податоци со оглед на

карактеристиките на системот за управување со бази на податоци, природата на

податоците и барањата на апликацијата. Принципите за дизајнирање на шема за

системите на релационите бази на податоци се добро воспоставени. Со релационен

СУБП и со нормализиран модел на податоци се помага да се обезбеди генеричка

кверијабилност и се избегнуваат ажурирањата на податоци кои може да резултираат со

недоследности. Покрај тоа, воспоставените модели спречуваат програмерите да имаат

прашања како да моделираат, на пример асоцијации од типот one-to-many или many-to-

many. Но, дизајнот на шема никогаш не е егзактна наука, па дури и со релационите бази

на податоци. Перформансно интензивните апликации, или апликации кои треба да

консумираат неструктуирани податоци, може да бараат погенерички модел на податоци.

Некои апликации се толку комплексни во нивните складирања и барањата за скалирање

што тие форсираат да се прекршат старите правила за дизајн на шема. Кога се започнува со дизајнирање на базата на податоци, првата работа која треба

да се анализира е природата на апликацијата за која се дизајнира, односно дали е

трансакциски базирана или аналитички базирана.

Трансакциски базирана - е вид на апликација, каде крајниот корисник повеќе е

заинтересиран за CRUD (креирање - creating, читање - reading, ажурирање - updating

ибришење - deleting) на записи. Официјалното име за овој вид на база на податоци е

OLTP (Online Transaction Processing – Онлајн трансакциска обработка).

Аналитички базирана - е вид на апликација каде крајниот корисник е повеќе

заинтересиран за анализа, извештаи итн. Овој вид на бази на податоци имаат помал број

на внесувања и ажурирања. Главната работа овде е “фаќање” и анализирање на

податоците колку што е можно побрзо. Официјалното име за овој вид на база на

податоци е OLAP (Online Analytical Processing – Онлајн аналитичка обработка).

Еден од принципите за моделирање на бази на податоци за NoSQL е дизајнирање

помалку врз основа на податочните субјекти и нивните односи, а повеќе врз основа на

пребарувањата кон базата на податоци. Овде се минимизирани или изостануваат

процесот на нормализација, надворешните клучеви и операцијата соединување (join).

Битна работа која треба да се научи и испраксира е постигнување на соодветна

грануларност на денормализацијата.

11

Кога треба да се моделираат податоците во MongoDB, треба да се одговори

наследните прашања:

- Како ќе се манипулира со тие податоци,

- Какво индексирање ќе се користи,

- Какво ажурирање ќе биде застапено,

- Каков ќе биди патернот на пристап,

- Типовите на ажурирања, на прашалници, животниот циклус на податоците,

слично како и во РСУБП.

Но во MongoDB треба да се забележи дека спојувањето не е поддржано и

запишувањата во документот се атомични.

Прашањата кои треба да се одговорат за табелите кога се моделираат податоците

во некој СУБП се од типот:

Која е основната единица на податоци? Во РСУБП има табели со колони и

редици. Во клуч-вредност базите на податоци има клучеви кои покажуваат кон

аморфни вредности, во MongoDB, документ-ориентираните бази на податоци,

основната единица на податоци е BSON документ (тоа е кратенка за Binary JSON,

бинарно кодирана серијализација за JSON документи. Како и JSON така и BSON

поддржува вгнездување на документи и низи во рамките на други документи и

низи).

Како ќе може да се пребаруваат и ажурираат тие податоци? Еднаш откако ќе

се разбере основниот тип на податоци, треба да се знае како да се манипулира со

него. MongoDB дозволува ад хок прашалници, но не поддржува спојувања.

Единствено клуч-вредност базите дозволуваат само преземање на вредности по

едноставен клуч. Базите на податоци, исто така се разликуваат во видот на

надградби кои ги дозволуваат. Кај РСУБП може да се ажурираат податоци на

софистициран начин со користење на SQL и тие извршуваат повеќе ажурирања

во една трансакција за да се добие атомичност и враќање назад (rollback).

MongoDB не поддржува трансакции, но поддржува различни атомски ажурирања

кои може да работат на внатрешните структури на комплексен документ. Со

едноставни клуч-вредност бази на податоци, може да се ажурираат вредности, но

секое ажурирање обично ќе значи комплетна замена на вредноста. Суштествена

точка е дека изградбата на најдобар модел на податоци значи разбирање на

карактеристиките на базата на податоци.

12

Кои се моделите на пристап на апликацијата? Во прилог на разбирањето на

основните единици на податоците и карактеристиките на базите на податоци, исто

така треба да се утврдат потребите на апликацијата. Кој е соодносот

читање/запишување? Какви видови на пребарувања ќе бидат потребни? Како се

ажурираат податоците? Какви проблеми со конкуренцијата може да се очекуваат?

Колку добро се структуирани податоците?

Најдобриот дизајн на шема е секогаш производ на длабоко познавање на базите

на податоци, добро расудување во врска со барањата на апликацијата и искуство.

1.2 Модели на податоци

Базата на податоци не е ништо друго туку модел на една мала ситуација од

реалниот живот. Како и секоја репрезентација, базата на податоци е секогаш несовршен

модел и многу тесен опис на богата и комплексна реалност.

Секој систем на податоци имплементира различни модели на бази на податоци за

логички да ги структуира податоците кои ќе бидат управувани. Овие модели се првиот

чекор и најголемиот детерминатор за тоа како базите на податоци ќе функционираат и

како ќе се справуваат со информациите.

Моделот на податоци е модел преку кој се гледаат податоците и се опишува како

корисниците манипулираат со тие податоци во неа. Тоа е различно од моделот на

складирање кој опишува како базите на податоци ги зачувуваат и како манипулираат со

податочниот интегритет.

Постојат неколку различни типови на модели на податоци (слика 1) кои јасно и

експлицитно овозможуваат структуирање на податоците, меѓу кои најпознат е

релациониот модел.

13

Слика 1: Модели на бази на податоци

Иако релациониот модел и релационите бази на податоци се екстремно моќни и

флексибилни, кога програмерот знае како да ги искористи, постојат и неколку проблеми

или карактеристики кои овие решенија никогаш не ги нудат.

Различните системи, наречени NoSQL бази на податоци, стекнуваат голема

популарност со надеж за решавање на проблеми од различна природа и нудење на

интересни дополнителни функционалности. Овие системи на бази на податоци нудат

многу послободен начин на обликување и работа со информациите, а со тоа

овозможуваат и поголема флексибилност и едноставна употреба.

Релациониот модел на податоци најдобро се претставува како множество на

табели. Секоја табела има редици и колони при што со секоја редица се претставува некој

запис кој е дел од ентитетното множество, а во колоните се содржат вредностите на

атрибутите на ентитетот.

Една од очигледните промени со NoSQL е оддалечувањето од релациониот модел

на податоци. Секое NoSQL решение има различен модел кој го користи, а кој може да

биде еден од четирите категории: клуч-вредност, документ, колона-фамилија и графика.

Првите три делат заедничка карактеристика во однос на нивните модели која се нарекува

агрегатна ориентација.

Кај релациониот модел на податоци, информациите кои треба да се зачуваат се

сместуваат во торки (редици). Торката е ограничена податочна структура: таа зафаќа

множество на вредности, при што не може да се вгнезди една торка со друга за да се

14

добијат вгнездени записи, ниту пак може да се стави листа на вредности или торки во

некои други торки.

Агрегатната ориентација има друг пристап. Таа забележува дека треба да се

оперира со податоци кои имаат покомплексна структура отколку множеството на торки.

При тоа, може да се воведе терминот на комплексни записи кои дозволуваат листи и

други структури на записи кои меѓусебно да се вгнездуваат. Клуч-вредност, документ и

колона-фамилија категориите на модели на податоци користат покомплексни записи.

Меѓутоа за овој комплексен запис не постои заеднички термин и затоа се користи

терминот агрегат. Агрегат е колекција на поврзани објекти кои може да се третираат како

единица. Тоа е единица за манипулација со податоците и управување со конзистенцијата.

Релационите бази на податоци, во нивниот модел на податоци немаат концепт на

агрегати, па затоа се нарекуваат и агрегат-игноранти.

1.2.1 Релационен модел

Релациониот модел е најчестата класична шема на база на податоци. Во јадрото

на овој модел е концептот на дводимензионална табела со редици и колони каде се

зачувани податочни вредности кои може да бидат нумерички, стрингови, датуми или

други типови. Табелите може да се спојат во нови, покомплексни табели, поради нивните

математички основи во релационата теорија. РСУБП е системот кој ги контролира и

управува тие податоците и врските помеѓу нив. Користи специјален јазик за

комуникација со базата на податоци наречен SQL (Structured Query Language), кој

овозможува да се извршат сложени пребарувања со релативно едноставни барања.

Постојат многу релациони бази на податоци со отворен код, вклучувајќи MySQL, H2,

HSQLDB, SQLite, и многу други.

Внатрешниот дизајн на релационите бази на податоци е управуван од релационата

математика и овие системи имаат потреба од однапред дефинирани шеми и типови на

кои податоците ќе се придржуваат, што ги прави одлични кога треба се работи со

логички поврзани податоци чија структура може однапред да се идентификува. Многу

бизнис проблеми се во потполност моделирани на овој начин, од нарачки на пратки до

попис на шопинг карти. Исто така релациониот модел е добро решение кога

интегритетот на податоците е од суштинско значење.

Кога податоците се многу променливи или длабоко хиерархиски, релационите

бази на податоци не се најдобро решение. Бидејќи треба да се одреди шемата однапред,

податоците кои покажуваат висок степен на разлика од еден запис до друг може да бидат

15

проблематични. Ќе биде тешко да се креира комплетна листа со сите карактеристики. Во

ваков случај, потребна е база на податоци која прави помалку ограничувања за она што

може да се стави во неа.

1.2.2 Клуч-вредност бази на податоци

Клуч-вредност базите на податоци се многу едноставни, но и многу моќни модели

кои се најлесни за имплементирање. Имаат едноставен модел на податоци -мапа/речник,

кој овозможува клиентите да ставаат и бараат вредности според клучот.

Модерните клуч-вредност бази на податоци фаворизираат висока скалабилност

над конзистентноста и затоа повеќето од нив изоставувуваат богати ад хок пребарувања

и аналитички карактеристики (особено операции на спојување и агрегирање). Често

должината на клучевите која може да биде складирана е лимитирана до одреден број на

бајти.

Базите на податоци од овој тип може да достигнат неверојатни перформанси во

голем број на сценарија, но генерално нема да бидат корисни кога има комплексни

прашалници и е потребна агрегација.

Се разбира, неговата едноставност може да биде лоша работа за некои податоци

со комплексни барања за моделирање. Riak и Dynamo се најпознатите клуч-вредност

бази на податоци.

Со малку или без потреба за одржување на индекси, клуч-вредност базите на

податоци често се дизајнирани да бидат хоризонтално скалабилни. Тие се особено

погодни за проблеми каде податоците не се високо поврзани. На пример, во веб

апликација, каде секоја активна сесија на корисникот може да биде различна и во голема

мера неповрзана со активноста на другите корисници.

Често заради недостигот на индекси и способности за скенирање, клуч-вредност

базите на податоци не можат да помогнат доколку треба да се извршат прашалници на

податоците кои се поинакви од основните CRUD операции.

1.2.3 Колона-ориентирани бази на податоци

Можеби најдобар начин да се гледа на колона ориентираните модели е како

двослојна агрегатна структура. Овие бази на податоци ги организираат нивните податоци

во фамилии на колони. Фамилијата на колони може да содржи практично неограничен

број на колони. Податоците кај овој модел може да се структуираат на два начини:

16

Редица ориентирани: секоја редица е агрегат со фамилија на колони претставени

преку корисни парчиња на податоци во тој агрегат.

Колона ориентирани: секоја фамилија на колони дефинира тип на записи со

редици за секој запис. Фамилиите на колони даваат дводимензионален квалитет

на колона фамилијарните бази на податоци.

Базите на податоци се дизајнирани да решаваат проблеми презентирани од реални

случаи. РСУБП произлегуваатод свет каде флексибилноста на пребарување е поважна од

флексибилните шеми. Додека пак, колона ориентираните бази се изградени за чување на

големи количини на податоци низ неколку машини.

Колона ориентираните бази на податоци делат многу сличности со клуч-вредност

и релационите бази на податоци. Како и кај клуч-вредност базите на податоци,

вредностите се пребарувани со совпаѓање на клучевите. Како кај релационите, нивните

вредности се групи од нула или повеќе колони. Колона ориентираните бази на податоци

чуваат податоци по колони наместо да ги чуваат податоците заедно по редици. Колоните

лесно се додават, верзионирањето е тривијално и не постојат вистински трошоци за

складирање на ненаселени вредности.

Колона ориентирани бази на податоци се така наречени поради тоа што важен

аспект од нивниот дизајн е тоа што базите од дадена колона (во дводимензионална

смисла на табели) се чуваат заедно. Спротивно на тоа, редица ориентираните бази на

податоци ги чуваат информациите за редица заедно. Разликата може да изгледа

безначајна, но влијанието на одлуката за дизајн е длабока. Во колона ориентираните бази

на податоци, додавањето на колони е прилично евтино и е направено на ред-по-ред

основа. Секоја редица може да има различно множество на колони, или воопшто да нема,

дозволувајќи табелите да станат раштркани без да предизвикаат трошоци на складирање

за null вредностите. Во пазарот за колона ориентираните бази на податоци, има помалку

конкуренција, отколку во релационите или клуч-вредност бази на податоци. Три

најпознати се HBase, Cassandra, и Hypertable.

Колона ориентираните бази на податоци традиционално се развиени со

хоризонтална скалабилност како примарна дизајнерска цел. Како такви, тие се особено

погодни за “BigData” проблеми, живеејќи на кластери од десетици, стотици и илјадници

јазли. Исто така, тие имаат тенденција да имаат вградена поддршка за карактеристики

како што се компресија и верзионирање. Канонскиот пример за добра колона

ориентирана база на податоци е индексирањето на веб-страни. Страните на веб се високо

17

текстуални (придобивки од компресија), малку поинаку поврзани, и променливи низ

времето (придобивка од верзионирање).

Различни колона ориентирани бази на податоци имаат различни карактеристики

и затоа и различни недостатоци. Но, едно нешто што им е заедничко е тоа дека најдобро

е да се дизајнира шемата врз основа на тоа како се планира да се пребарува низ

податоците. Ова значи дека треба да се има некоја идеја однапред за тоа како ќе се

користат податоците, не само од што ќе се содржат. Ако начините на користење на

податоци не може да се дефинираат однапред, на пример брзи ад хок извештаи, тогаш

овие бази на податоци може да бидат лош избор.

1.2.4 Документ-ориентирани бази на податоци

Документ-ориентираните бази на податоци, чуваат документи. Накратко,

документот е хеш датотека, со единствено ID поле и вредности кои може да бидат било

кој вид вклучувајќи и хеш-клуч. Документите може да содржат вгнездени структури, и

така тие да покажуваат висок степен на флексибилност, овозможувајќи променливи

домени.

Документите се состојат од именувани полиња кои имаат клуч/име и вредност.

Името на полето треба да биде уникатно во документот и неговата доделена вредност

може да биде стринг, број, булеан, датум, подредена листа или асоцијативна мапа.

Документите може да содржат референци до други документи (URIs, URLs).

Различни документ-ориентирани бази на податоци земаат различен пристап во

однос на индексирање, ад хок пребарување, репликација, конзистентност и други одлуки

за дизајн. Изборот од толку широки понуди бара познавање на овие разлики и како тие

влијаат на одредени случаи. Две главни играчи со отворен код во пазарот на документ-

ориентирани бази на податоци се MongoDB и CouchDB.

Бидејќи документите не се поврзани едни со други како во релационите бази на

податоци, тие можат релативно лесно да се одделат и реплицираат низ неколку сервери,

правејќи ја дистрибуираната имплементација прилично честа појава.

Без фиксна шема, додавањето или отстранувањето на полиња станува полесно.

Ова го прави побрз развојот за девелоперите и е полесно за експериментирање.

Програмерите можат да пробаат десетици модели на податоци и потоа да го изберат

најдобриот.

Документ-ориентирaните бази на податоци се прилагодени за проблеми кои

вклучуваат високо променливи домени. Кога не се знае однапред како точно ќе изгледаат

18

податоците, документ базите на податоци се добар избор. Исто така, поради природата

на документите, тие често се мапираат добро со објектно ориентираните програмски

модели. Ова значи помалку несовпаѓање кога се движат податоците помеѓу моделот на

базите на податоци и апликацискиот модел.

Поради непостоењето на фиксна табеларна шема, оневозможена е примената на

операциите на спојување. Документот генерално треба даги содржи повеќето или сите

релевантни информации потребни за нормална употреба.

Дополнително ограничување е тоа што документите во CouchDB не можат да

бидат вгнездени.

1.2.5 Граф-базирани бази на податоци

Повеќето NoSQL бази на податоци се појавиле како одговор на потребата да се

работи со кластери, што доведе до агрегат-ориентирани податочни модели на големи

записи со едноставни врски. Граф-базираните бази на податоци произлегле заради

поразлични фрустрации со релационите бази на податоци и на тој начин имаат спротивен

модел – мали записи со комплексни интерконекции. Оваа е една од поновите класи на

бази на податоци, која се фокусира повеќе на слободна итерација на податоците кои

чуваат високо меѓусебно поврзани податоци.

Во овој контекст, графот не е бар шема или дијаграм. Наместо тоа има графичка

податочна структура на поврзани јазли. Јазлите и врските може да имаат клуч-вредност

пар кој чува податоци.

Ова е идеално за снимање на сите податоци кои се состојат од комплексни врски

како што се социјалните мрежи или параметри на производ.

Основниот модел на податоци на граф-базираната база на податоци е многу

едноставен: јазли поврзани со рабови (исто така наречени ребра или лакови).

Главната предност на граф-базираните бази на податоци е минувањето низ јазлите

со следење на релациите. Во оваа фамилија бази на податоци спаѓаат: Neo4j,

AllegroGraph, Graphbase, InfoGrid, OrientDB.

Граф-базираните бази на податоци се чини дека се скроени за мрежни апликации.

Пример, социјална мрежа, каде јазлите претставуваат корисници кои имаат различни

видови на односи едни со други. Моделирањето на овој вид на податоци со користење

на некој друг стил често е тешко да се изведи, но граф-базираните бази на податоци

пријатно ќе се вклопат. Тие исто така се совршени за објектно ориентирани системи. Ако

19

може да се моделираат податоците во табела, може да се моделираат и во граф-базирана

база на податоци.

Поради високиот степен на поврзаност меѓу јазлите, граф-базираните бази на

податоци генерално не се погодни за мрежна поделба. Граф-базираната база на податоци

не може да си дозволи мрежни hops до други јазли на базата на податоци, па граф-

базираните бази на податоци не скалираат добро.

1.3 Креирање и користење на базите на податоци

Постојат два типа на датотеки на податоци: примарни и секундарни. Кога базата

на податоци е првично креирана, примарната датотека на податоци е создадена. По

дифолт, таа ги содржи сите почетни информации за базата на податоци. Како

корисничките објекти се креираат, тие исто така може да бидат складирани во основната

датотека на податоци. Сепак, може да се имплементираат одредени стратегии за

архитектура за да се подобрат перформансите, скалабилноста и одржливоста на базата

на податоци.

Пред да се стартува скриптата, се креираат две датотеки на коренот на C дискот:

SQLData и SQLLog. Табелата на базата на податоци изгледа многу како spreadsheet

табела: дведимензионална низа составена од редици и колони. Може да се креираат

табели со користење на SQLCREATE TABLE командата. Со оваа команда, се

специфицира името и типот на податокот на секоја колона. Откако ќе се креира табелата,

може да се започне со вчитување на податоци. Ако барањата се променат, може да се

смени податочната структура со користење на ALTER TABLE командата. Доколку треба

да се избрише, таа може да се елиминира со DROP командата.

Нормализација, е начин на структурирање на табелите на базата на податоци така

што ажурирањата да не воведуваат аномалии. Секоја табела која се креира содржи

колони кои одговараат со атрибутите кои се тесно поврзани еден со друг. Може да се

креира КЛИЕНТ табела со атрибути КЛИЕНТ.КлиентID, КЛИЕНТ.Име,

КЛИЕНТ.Презиме, КЛИЕНТ.Улица, КЛИЕНТ.Град, КЛИЕНТ.Држава и

КЛИЕНТ.Телефон. Повеќето системи за управување со бази на податоци обезбедуваат

графичка алатка за креирање на табелите.

Заедничка карактеристика на сите форми на NoSQL базите на податоци е тоа што

тие се без шеми. Кога треба да се зачуваат податоци во релациона база на податоци, прво

треба да се дефинира шемата – дефинирана структура за базата на податоци во која се

20

кажува какви табели постојат, кои колони постојат и какви податочни типови секоја

колона ќе чува. Пред да се зачува некој податок, треба да се има шема дефинирана за тоа.

Со NoSQL базите на податоци, зачувувањето на податоците може да биде многу

посекојдневно. Клуч-вредност базите на податоци дозволуваат да се зачувува било кој

податок под клуч. Документ-ориентираните базите на податоци ефикасно го прават

истото, бидејќи не прават ограничувања на структурата на документот во кој се зачувува.

Колона ориентираната база на податоци дозволува да се зачувуваат било кои податоци

во било која колона. Граф-базираните бази на податоци дозволуваат слободно да се

додаваат нови рабови и слободно да се додаваат атрибути на јазлите и рабовите. Со шема,

треба однапред да се дознае што ќе треба да се зачувува, но тоа може да биде тешко да

се направи. Без шема може лесно да се зачувува било што е потребно. Ова дозволува

лесно да се промени скалирањето на податоци. Лесно може да се додадат нови работи

како што се откриваат. Исто така, доколку се увиди дека не се потребни некои работи

повеќе, треба само да се запре складирањето на нив, без грижа за губење на стари

податоци што би се случило доколку се избришат колони во релационата шема.

Како и справувањето со промени, базата на податоци без шема, исто така, го

олеснува и справувањето со неуниформните податоци – податоци каде секој запис има

посебно множество на полиња. Шемата ги става сите редици на табелата во строги

правила, кои стануваат непријатни доколку треба да се имаат различни податоци во

различни редици. Така се завршува со многу колони кои се обично нули или ќе се заврши

со бесмислени колони. Немањето шема го избегнува ова дозволувајќи секој запис да

содржи само тоа што е потребно, ни помалку ни повеќе. Немањето шема е привлечно и

избегнува многу проблеми кои постојат во бази на податоци со фиксна шема, но тоа носи

и некои проблеми. Доколку се складираат некои податоци и прикажуваат во извештај

како едноставна листа на податочни имиња:вредности – тогаш шемата е добра опција за

да се добие тоа. Но обично со податоците не се прави само тоа.

Витален, понекогаш неповолен факт е дека секогаш кога ќе се напише програма

која пристапува до податоците, таа програма скоро секогаш се потпира на некоја форма

на имплицитна шема. Програмите не се луѓе, тие не можат да читаат “квант” и да

заклучат дека тоа мора да би значело “квантитет” - освен ако не му се специфицира на

програмата да го стори токму тоа. Значи, без разлика колку без шема се базите на

податоци обично е присутна имплицитна шема. Оваа имплицитна шема е множество на

претпоставки за податочната структура во кодот кој манипулира со податоците.

Имањето на имплицитна шема во апликацискиот код резултира со неколку проблеми.

21

Тоа значи дека со цел да се разбере кои податоци се присутни треба да се “копа” во

апликацискиот код. Ако тој код е добро структуиран ќе може да се најде шемата. Но не

постои гаранција, сето тоа зависи од тоа колку чист е апликацискиот код. Исто така,

базата на податоци останува игнорирана од шемата – не може да ја користи шемата за да

помогне во одлучувањето на тоа како да се зачуваат и извлекуваат податоците ефикасно.

Не може да примени своја валидација врз тие податоци за да се осигура дека различни

апликации не манипулираат со податоците на неконзистентен начин. Овие се причините

зошто релационите бази на податоци имаат фиксна шема и навистина причините зошто

повеќе бази на податоци имаа фиксна шема во минатото. Шемите имаат вредност, и

одбивањето на шемите од страна на NoSQL базите на податоци е навистина доста

изненадувачки. Во суштина, базите на податоци без шеми ја преместија шемата во

апликацискиот код кој ги пристапува. Ова станува проблематично во повеќе апликации

развиени од различни луѓе, за пристап до истите бази на податоци. Овој проблем може

да се редуцира со неколку пристапи. Една е енкапсулација на сите интеракции на базата

на податоци во едноставна апликација и интегрирање со други апликации користејќи веб

сервиси. Друг пристап е јасно да се разграничат различните области на агрегација за

пристап од различни апликации. Ова може да бидат различни секции во документ базата

на податоци или различни колони фамилии во колона ориентираната база на податоци.

Иако NoSQL фановите често ги критикуваат релационите шеми бидејќи треба шемите да

се дефинираат однапред и стануваат нефлексибилни, ова не е сосема точно. Релационите

шеми може да се менуваат било кое време со стандардни SQL команди. Доколку е

потребно, може да се креираат нови колони на ад хок начин за зачувување на

неуниформни податоци. Поголемиот дел од времето, неуниформните податоците може

да бидат добра причина за да се фаворизираат базите на податоци без шеми.

Немањето на шема има големо влијание на промените на структурата на базата

на податоци со текот на времето, особено за повеќе униформни податоци. Иако тоа не е

пракса која е широко распространета како што би требало да биде, промената на

релационата шема може да се направи на контролиран начин. Слично, треба да се врши

контрола кога се менува начинот на кој се зачувуваат податоците во безшемната база на

податоци така што ќе може лесно да се пристапи до старите и новите податоци. Исто

така флексибилноста која ја дава базата на податоци која нема шема може да се примени

само во рамките на агрегат – доколку треба да се променат агрегат границите,

миграцијата е толку комплексна колку и во релациониот случај.

22

Кога се моделира колона ориентирана база на податоци може да се именуваат

колоните кои често се користат па до нив ќе се пристапува прво. Кога се користи колона

ориентирана база на податоци за да се моделираат податоците, важно е да се запамети да

се направи тоа за целите на пребарувањата, а не за целите на пишувањата, генералното

правило е да се направи лесно за пребарување и да се денормализираат податоците за

време на запишување.

При користењето на граф-базираните бази на податоци за да се моделираат истите

податоци, се моделираат сите објекти како јазли и релации меѓу нив како односи, овие

односи имаат тип и насока. Агрегат ориентираните бази на податоци ги прават

внатреагрегатните односи потешки за справување отколку интраагрегатните односи.

1.4 Околина и архитектура

РСУБП е комплексен систем кој се состои од специјализирани механизми со цел

да се справи со сите функции потребни за чување и добивање информации.

Архитектурата на РСУБП често е споредувана со онаа на оперативниот систем. На

пример, повеќе клиенти значи дека системот треба да поддржува повеќе барања кои

можат или не можат да ги читаат или запишуваат истите податоци или податоците од

истата локација (како табела). Така, РСУБП мора ефикасно да се справи со

конкурентноста. Слично, РСУБП мора да обезбеди брз пристап до податоците за секој

клиент. Ова обично се остварува со користење на податочни визуелни техники кои ги

чуваат неоддамна или често користените податоци во меморија за побрз пристап.

Конкурентноста бара техники за управување со меморијата кои личат на систем на

виртуелна меморија во оперативниот систем. Други сличности со оперативните системи

вклучуваат поддршка за мрежна комуникација и алгоритми за оптимизација дизајнирани

да ги максимизираат перформансите на извршувањето на прашалниците.

MySQL архитектурата е најдобро опишана како слоевит систем од потсистеми.

Додека изворниот код не е компајлиран како индивидуални компоненти или модули,

изворниот код за потсистемите е организиран на хиерархиски начин што овозможува

потсистемите да бидат раздвоени (енкапсулирани) во изворниот код. Повеќето

потсистеми се потпираат на основни библиотеки за пониско ниво на функции (на

пример, контрола на нишка, распределба на меморија, вмрежување, логирање и

справување со настани, контрола на пристап). Заедно, основните библиотеки,

потсистемите изградени врз тие библиотеки, па дури и потсистемите изградени од други

23

потсистеми формираат апстрахиран API кој е познат како C клиент API. Овој моќен API

овозможува MySQL системот да се користи или како самостоен сервер или како вграден

систем на бази на податоци во голема апликација. Архитектурата овозможува

енкапсулација за SQL интерфејси, парсирање на пребарувањето, оптимизација на

прашалникот и извршување, кеширање и баферирање.

Архитектурските модели дозволуваат да се дадат прецизни имиња на периодични

високонивовски модели на податочно складирање. Кога ќе се предложат специфични

модели на архитектурски модели како решение на некој бизнис проблем, треба да се

користи концизен процес кој овозможува да се именува моделот, да се опиши како тој се

согласува со тековниот бизнис проблем, и артикулираат позитивните и негативните

страни на предложеното решение. Зборот модел има многу значења. За целите се

дефинира модел на податочна архитектура како конзистентен начин на претставување

на податоците во регуларна структура кој се чува во меморија. Иако меморијата во која

се чуваат податоците обично е долгорочна меморија, како што се хард дисковите, овие

структури може исто така да се чуваат во RAM меморија и потоа да се пренесуваат во

трајната меморија преку друг процес.

Исто така важно е да се разбере разликата помеѓу високо ниво на модел на

податочна архитектура која се користи за да се идентификува како податоците се чуваат

во систем наспроти модел на тесно ниво на податочна архитектура кој идентификува

каква е интеракцијата со податоците.

Во NoSQL, корисникот на базата на податоци може да ги менаџира податоците и

од апликациско и од ниво на базана податоци. Директен пристап до базата на податоци

од апликациско ниво овозможува поголема флексибилност за одржување на

апликацијата. Но во релационите бази на податоците, базата на податоци може само да

се менаџира од ниво на база на податоци, но не и од апликациско ниво. Оваа

карактеристика на NoSQL овозможува поголема флексибилност за одржување на

апликацијата како и на базата на податоци. Релационите бази на податоци ги менаџираат

податоците преку нормализирање на податоците. Друга важна разлика во архитектурата

на NoSQL и релационите бази на податоци е шемата. Со релационите бази на податоци

мора да се дефинира шема пред да се додаде некој запис. Модифицирање на шемата или

додавање на нова шема на базата на податоци кога базата на податоци е раширена низ

серверот е тешко.

24

1.5 Конзистентност

Конзистентноста е главна карактеристика на трансакциите на релационите бази

на податоци. Сѐ или ништо, е трансакциското мото. Трансакциите обезбедуваат дека

секое множество од команди е извршено. Доколку нешто падне, сите команди се враќаат

назад како никогаш да не се извршиле.

PostgreSQL трансакциите ја следат ACID усогласеноста, која е кратенка од

Атомичност (сите операции се успешни или ниедна не е), Конзистентност (податоците

секогаш се во добра состојба – не во неконзистентна), Изолираност (трансакциите не се

мешаат), и Трајност (комитираната трансакција е сигурна, дури и доколку серверот се

руши).

Riak серверската архитектура бриши поединечни точки на пад и дозволува да

расте или да се проширува кластерот доколку е потребно. Ова е важно кога се справува

со голем деплојмент, бидејќи дозволува базата на податоци да остане достапна дури и

кога неколку јазли паднат или се на некој начин недостапни.

Дистрибуцијата на податоци низ неколку сервери е оптоварена со основен

проблем. Доколку треба да продолжи да работи базата на податоци кога се случува

поделба на мрежата (односно, некои пораки се изгубени), тоа значи дека треба да се

направи трампа. Или може да се остави на располагање за серверските барања или може

да се одбијат барањата и да се обезбеди конзистентност на податоците. Не е возможно

да се креира дистрибурирана база на податоци која е целосно конзистентна, достапна и

толерантна на партиции. Може да се имаат само две (толерантност на партиции и

конзистентност, толерантност на партиции и достапност, или конзистентност и

достапност, но не и дистрибуција). Ова е познато како CAP теорема (слика 2)

(Конзистентност, Достапност, Толерантност на партиции). CAP теоремата исто така

позната и како Brewes-сова теорема, кажува дека е невозможно за дистрибуираните

компјутерски системи симултано да се овозможат следните карактеристики:

конзистентност (сите јазли ги гледаат истите податоци во исто време), достапност

(гаранција дека секое барање добива одговор дали е тоа успешно или не) и толеранција

на партиции (системот продолжува да работи независно од пораката за изгубени

податоци или пад на дел од системот). Според оваа теорема, дистрибуираните ситеми не

може да ги задоволат трите горенаведени карактеристики во исто време. Riak носи

предност на овој факт што дозволува замена на достапноста за конзистентноста по

основа на барање.

25

Слика 2: CAP теорема

Со почит кон CAP, HBase е дефинитивно CP. HBase гарантира строга

конзистентност. Доколку клиентот успее во запишувањето на вредност, друг клиент ќе

ја прими ажурираната вредност на следното побарување. Некои бази на податоци, како

Riak, дозволуваат да се повлече CAP на основа на операција. Не е така и со HBase. Во

разумните количини на поделба – на пример, паѓање на јазол – HBase ќе остане достапен,

маневрирајќи со исклучување на одговорноста на другите јазли во кластерот. Сепак, во

патолошки пример, каде само еден јазол е останат жив, HBase нема друг избор освен да

ги одбие барањата.

Податоците користени од повеќе документи може да бидат вградени

(денормализирани) или референцирани (нормализирани). Денормализацијата не е

подобра отколку нормализацијата и обратно. Секоја има и позитивни и негативни страни

и треба да се избере што да се прави за да работи најдобро апликацијата.

Денормализацијата може да доведе до неконзистентни податоци. Доколку се

смени вредноста на еден документ, но апликацијата “падне” пред да се ажурираат

другите документи, базата на податоци може да има две различни вредности.

Непостојаноста не е голема, зависи од тоа што се чува. За многу апликации,

краток период на непостојаност е ОК. Бидејќи не е во ред да се има неконзистентни

вредности макар и за кратко, треба да се оди со нормализација. Сепак, доколку се

нормализира, апликацијата мора да прави екстра прашалници секојпат кога се бара

податок. Доколку апликацијата не може да си дозволи да се поништи овој перформанс и

ќе биде во ред да се помират недоследностите подоцна, треба да се изврши

денормализација. Ова е трампа – не може да се има и двете - брзи перформанси и

26

гарантирана непосредна конзистентност. Треба да се реши што е поважно за

апликацијата. Колку е важна конзистентноста? Доколку е важна конзистентноста, треба

да се оди со нормализација. На пример, доколку се дизајнира апликација за тргување

каде одредени хартии од вредност може да се тргуваат само одредени периоди, треба да

се заклучат сите кога тие не се во промет. Тогаш треба да се користи еден заклучен

документ како референца за релевантна група на безбедни документи. Овој вид на работа

може подобро да се направи на апликациско ниво, каде апликацијата ќе ги знае правилата

во кој случај да се заклучи во кој да се отклучи.

Во други примери, има стриктна хиерархија. Доколку има повеќе документи би

било тешко да се одлучи кој треба да победи. Дали читањето треба да биде брзо? Доколку

читањето треба да биде колку што е можно побрзо, треба да се денормализира.

Апликации во реално време треба да се денормализираат колку што е можно побрзо.

Постои добар случај на денормализирање на документите, информацијата не се

променува многу, па дури и да се прави тоа, не треба да се рефлектираат промените.

Нормализацијата не дава некоја предност тука, во овој случај најдобро е

денормализирање на шемата.

1.5.1 Евентуална конзистентност

Дистрибуираните бази на податоци мора да бидат толерантни на поделба, па

изборот меѓу достапност и конзистентност може да биде тежок. Сепак, додека CAP

диктира дека ако да се избере достапноста, нема да се има вистинска конзистентност, сѐ

уште може да се обезбеди евентуална конзистеност. Идејата позади евентуалната

конзистентност е тоа дека секој јазол е секогаш достапен за серверските барања. Како

трампа, модификацијата на податоците е пропагирана во позадина до другите јазли. Ова

значи дека во еден момент системот може да биде неконзистентен, но податоците да

бидат во голема мера точни.

The Internet’s Domain Name Service (DNS) е одличен пример на евентуален

конзистентен систем. Се регистрира домен, и тоа може да потрае неколку дена, за да се

прогапира до сите DNS сервери низ Интернетот. Но, во ниеден момент некој одреден

DNS сервер не е недостапен (под претпоставка дека може да се поврзи на него).

27

1.6 Трансакции и податочен интегритет

Бизнис барањата го определуваат обемот на ситуацијата од реалниот живот кој

треба да бидe моделиран. Еднаш кога ќе се дефинира обемот, може да се продолжи со

идентификување на податоците кои треба правилно да ја зачувуваат бизнис активноста.

Податоците треба да бидат структуирани пред да се користат и треба да се менаџираат

следејќи ги ACID (атомичност, конзистентност, изолираност, трајност) принципите,

структурирани примарно како табели и пристапени со користење на структурираниот

јазик за пребарување (SQL).

Релационите бази на податоци дозволуваат манипулирање со секоја комбинација

на редици од секоја табела во една трансакција. Таквите трансакции се наречени ACID

трансакции. Многу редици опфаќајќи повеќе табели се ажурираат како една операција.

Оваа операција или ќе успее или ќе падне во целост и истовремените операции се

изолирани една од друга па не може да се види делумно ажурирање. Често се вели дека

NoSQL базите на податоци не поддржуваат ACID трансакции и на тој начин се жртвува

конзистентноста. Во принцип, точно е дека агрегат ориентираните бази на податоци

немаат ACID трансакции. Наместо тоа, тие поддржуваат атомична манипулација на еден

агрегат во исто време. Ова значи дека ако треба да се манипулира со повеќе агрегати на

атомичен начин, треба да се менаџира во апликацискиот код.

Релационите бази на податоци ја добиваат нивната флексибилност, бидејќи

нивните податоци престојуваат во табели кои во голема мера се независни меѓу себе.

Може да се додаваат, бришат или менуваат податоците во табелата без да се влијае на

податоците во другите табели.

Трансакциите се одбранбен ѕид на конзистентноста на релационите бази на

податоци. “Сѐ или ништо”, тоа е мотото на трансакцијата. Трансакцијата обезбедува дека

секое множество од команди е извршено. Доколку нешто тргне наопаку, сите команди

се повлекуваат како никогаш да не се случиле.

Може да се завитка секоја трансакција во BEGIN TRANSACTION блок. За да се

верифицира атомичноста, може да се повлече трансакцијата со ROLLBACK командата.

BEGIN TRANSACTION;

DELETE FROM events;

ROLLBACK;

SELECT * FROM events;

28

Трансакцијата е корисна кога се модифицираат две табели кои не треба да се

десинхронизираат. Кога е завиткана во трансакциски блок, иницијалното ажурирање се

повлекува, дури и ако серверот експлодира.

Neo4j е база на податоци со Атомична, Конзистентна, Изолирана и Трајна (ACID)

трансакција, слична на PostgreSQL. Како и релационите бази на податоци, Neo4j

трансакциитесе сѐ-или-ништо операции. Кога ќе започне трансакцијата, секоја следна

операцијаќе биде успешна или ќе падне како атомичен пад што значи целосно

неизвршување.

Како и PostgreSQL, основната функција од една линија автоматски е завитканаво

имплицитна трансакција. За да се демонтираат мултилинијни трансакциитреба да се

исклучи графичкиот објект за трансакциски мод, што дозволува Neo4j да знае дека се

планираат рачни трансакции. Може да се промени трансакцискиот мод преку

setTransactionMode() функцијата.

gremlin>g.setTransactionMode(TransactionalGraph.Mode.MANUAL)

Може да се започне или запре трансакцијата на графички објект со користење на

startTransaction() и stopTransaction(conclusion). Кога ќе се запрe трансакцијата, исто така

треба да се маркира дали трансакцијата била успешна. Доколку не е, Neo4j ќе ги врати

сите команди кои се извршиле на старт. Добра идеја е да се завитка трансакцијата со

try/catch блок да се осигура дека сите грешки ќе повлечат враќање.

g.startTransaction()

try {

// извршување на некои чекори

g.stopTransaction(TransactionalGraph.Conclusion.SUCCESS)

} catch(e) {

g.stopTransaction(TransactionalGraph.Conclusion.FAILURE)

}

MongoDB базата на податоци не вклучува трансакциска семантика (бит кој

гарантира за конзистентноста на податоците и складот). Ова е солиден компромис

базиран на целта на MongoDB за едноставност, брзина и скалабилност.

29

1.7 Миграција на шеми

Во софтверското инженерство, миграција на шема (односно миграции на базата,

управување со промените на базата на податоци) се однесува на управување со

зголемувањето, со реверзибилни промени на шемите на базите на податоци.

Кога се развива апликација која е со база на податоци, програмерите треба да ја

земат предвид еволуцијата на шемата.

Како што расте апликацијата и потребите за промена, шемата можеби треба да се

прошири и да се промени. Доколку треба да се додаде нов атрибут на постоечки ентитет,

обично значи додавање на колона некаде во табелата. Кога се работи на млад производ,

особено во млада компанија, брзата итерација е клучна за успех на апликацијата. Со

користење на релациона база на податоци, додавањето на нова колона бара промена на

шемата. Со текот на времето шемата на базата станува сума од оригиналниот дизајн плус

секоја од тие поединечни промени.

Јадрото на релациониот систем не е добро прилагодено за управување на овие

промени, и затоа тие стануваат напор за софтверското инженерство. Постојат моќни

алатки за управување со овие видови на проблеми.

Во релационите бази на податоци шемата на миграции е добро разбрана и доби

широка прифатливост.

Релационите бази на податоци обично поддржуваат миграции преку АLTER

TABLE наредбата, која му дозволува на девелоперот да додава и да бриши колони од

табелата.

Главните недостатоци во ALTER TABLE наредбата е тоа што троши време да

работи со табела со голем број на редици и може да предизвика застој во апликацијата

додека се извршува миграцијата, бидејќи ALTER TABLE наредбата бара заклучување на

апликацијата додека таа се извршува.

Алатките како DBDeploy, DBMaintain, MyBatis migrations, Flyway, Liquibase,

Active Record Migrations и многу други, дозволуваат да се мигрира базата на податоци и

да се одржува историја на верзии во базата на податоци.

Примена на миграцијата на шема на база на податоци во продукција е секогаш

ризик. Базите на податоци во фазата на развој или тестирање се помали и чисти, па може

лесно да се модифицира и рекреира шемата со автоматизирани скрипти и да се тестираат

податоците дали одговараат со новата шема. Податоците во неа се подобро разбирливи

30

и доколку настане некоја грешка, количеството на податоци е мало што овозможува

рачно да се процесира повторно.

Вистинските проблеми во животот на информатичката технологија се случуваат

после првото деплоирање, кога апликацијата е жива и пополнета со податоци за

клиентите. Нема повеќе можност да се рекреира од почеток базата на податоци. Овој

пристап на креирање на миграциони скрипти за време на деплоирање е склоно на грешки

и не поддржува методи на агилен развој.

Базите на податоци во продукција се обично огромни, стари и полни со

изненадувања. Изненадувањата може да доаѓаат од различни извори:

- собрани податоци запишани преку стари верзии на софтвер,

- внесени зависности во податоците,

- рачно менување на базата на податоци без да се користат алатки,

- грешки во алатките за миграција на шема и слично.

Заради ова, миграциониот процес треба да се прави со највисоко ниво на

дисциплина, преку тестирања и бекап стратегија.

Процесот на миграција е помалку болен со базите на податоци без шема.

Всушност, во повеќе случаи кога само се додаваат или се бришат полиња, не постојат

проблеми воопшто.

Неодамнешен тренд во дискусиите за NoSQL бази на податоци е потенцирањето

на нивната безшемна природа - ова е популарна карактеристика која им дозволува на

девелоперите да се концентрираат на дизајн на доменот без да се грижат за промени на

шемата. Ова е особено точно со појавата на агилните методи каде одговорот на

променливите барања е важен.

Со NoSQL базите на податоци, промената на шемата може да биде направена со

најмал износ на фрикции, подобрувајќи ја продуктивноста на девелоперите. Развојот и

одржувањето на апликацијатаво новиот свет на безшемни бази на податоци барада се

даде посебно внимание на миграцијата на шема.

Сепак, со порастот на NoSQL базите на податоци и нивната прифатливост,

тимовите за развој се соочија со проблем при миграција на NoSQL базите на податоци.

Која шема на податоци за миграција работи во NoSQL базите на податоци?

Бидејќи NoSQL базите на податоци немаат шеми и не форсираат некаква

валидација на шеми, шемата на податоци е во апликацијата и затоа дозволува различни

техники на миграција на податоците. За мигрирање на сите податоци наеднаш, треба да

31

се напише скрипта која ќе пристапи до сите објекти во базата и ќе ги мигрира во

последната верзија на шема во кодот. Овој патерн значи дека:

- можно е да се пристапи до сите објекти во базата, да се модифицираат и зачуваат

повторно. Во клуч-вредност базите ова е скапа операција да се вратат сите

клучеви,

- за време на ажурирањето на сите објекти, апликацијата може да не ги модифицира

објектите и да креира колизии,

- сите постоечки објекти се во иста верзија на шемата.

За воведување на нова колона во колона ориентираните бази на податоци,

колоните не треба да бидат преддефинирани. Апликацијата може веднаш да се смени без

промена на шемата. Но внесувањето на нова фамилија на колони, промена на атрибут на

постоечка фамилија на колони или додавање на нова табела бара промена на шемата.

Може да се креира апликација за секоја миграција, но тоа би било ужасно. Наместо тоа

може да се реплицира истата миграција за управување со шема која се користи за

релационите системи со скриптирање на HBase shell. Оваа техника може да биде многу

неуредна, особено кога има конфликтни верзии. На пример, една верзија може да го бара

"Адреса" полето, и друга верзија можеби не бара да има "Адреса" поле, но да бара друго

поле, а пак трета верзија да мисли дека полето "Адреса" е опционално. Следењето на

овие побарувања може да доведе до “шпагети код”.

Повеќето алатки за миграција на шеми помагаат во минимизирање на влијанието

на промените на шема на постоечките податоци во базата на податоци. Наспроти ова,

зачувувањето на податоци генерално не е гарантирано бидејќи промените на шемата,

како на пример, бришење на колона од базата на податоци може да ги уништи

податоците, вредностите кои се зачувани во таа колона. Наместо тоа, алатките помагаат

во зачувување на значењето на податоците или ги реорганизираат постоечките податоци

за да ги пресретнат новите барања.

MongoDB дозволува да се внесе податок без разлика на неговата структура. Со

MongoDB, аликацијата можеби ќе треба да се промени за да се приспособи на новата

податочна шема, но самата база може да се справи со секаква шема на документ

автоматски.

Постои голем недостаток во неспроведувањето на шемата во MongoBD,ба тоа е

ефикасност во складирањето. Во РСУБП бидејќи сите имиња на колони и типови се

дефинирани на ниво на табела, оваа информација не треба да се повторува во секоја

редица. MongoDB, спротивно, не знае, на ниво на колекција, кое поле е присутно во секој

32

документ, ни неговите типови, па оваа информација мора да биде зачувана на база на

документ. Доколку се чуваат мали вредности (бројки, датуми или кратки стрингови) во

документите и се користат долги имиња на променливите, тогаш MongoDB ќе користи

поголемо количество на меморија отколку РСУБП што би користел за истите податоци.

Еден пристап кој може да помогне и во ефикасно зачувување и во миграции е

користењето на MongoDB објект-документ мапер (ODM). Постојат неколку достапни

ODMs, вклучувајќи ги MongoEngine, MongoKit и Ming.

MongoDB е исто така без шема. Документ клучевите не се предефинирани или

фиксни на било кој начин. Нови или исчезнати клучеви може да се решат на ниво на

апликација, наместо да се форсира сите податоци да имаат иста шема. Ова им дава на

девелоперите многу флексибилност на начинот на кои тие работат со развојот на модели

на податоци.

Наједноставниот тип на ажурирање целосно го заменува совпаѓањето на

документ со нов. Ова може да биде корисно кога се прават драматични миграции на

шема.

Да се справи со променливите барања на малку поконструктуиран начин може да

се вклучи "version" поле во секој документ и да се користи тоа за да се детерминира што

апликацијата може да очекува од структурата на документот. Ова поригорозно

наметнува шема: документот треба да биде валиден за некоја верзија од шемата, но не во

тековната. Сепак, ова сѐ уште бара поддршка на старите верзии.

Конечна опција е мигрирање на сите податоци кога ќе се промени шемата.

Генерално ова не е добра идеја. MongoDB дозволува да се има динамична шема со цел

да се избегнат миграциите бидејќи тие вршат голем притисок на системот. Сепак,

доколку се донесе одлука да се промени некој документ, треба да се осигура дека сите

документи се успешно ажурирани.

MongoDB не поддржува атомични мултиажурирања (или сите се случуваат или

сите тие не се во повеќе документи). Доколку MongoDB се урне на средина на мигација,

може да се заврши со некои ажурирани и некои неажурирани документи.

Непостоењето на шема има големо влијание на промените на структурата на

базата на податоци со текот на времето, особено за некои униформни податоци.

1.7.1 Мигрирање на податоци за време на читање

Со овој патерн, податоците се читаат како што се кога е побарано од апликацијата.

Податоците тогаш се мигрираат во последната верзија која е потребна за апликацијата и

33

се користат од апликацијата и повторно се запишуваат кога корисникот ќе ја заврши

операцијата. Овој патерн значи дека:

- апликацијата ќе може да ги чита старите верзии на податоците и да ги ажурира во

последна верзија, понекогаш зачувувањето на цел код во складишта на код може

да доведе до валкан код и да ја намали продуктивноста на програмерот,

- секој објект треба да знае која верзија од миграција е аплицирана на него, што

значи дополнителен атрибут на објектот,

- може да постојат објекти кои никогаш нема да бидат пристапени што значи

никогаш нема да мигрираат.

Според горенаведеното, треба да се пишува код кој ќе се справи со повеќе верзии

на податоците и ќе ги ажурира сите верзии во бараната верзија и ќе ги зачува повторно

со последната верзија.

1.7.2 Хибриден пристап

Со овој патерн може да се мигрираат објектите еднаш за време на читање на

податоците, и истовремено да има работа во позадина која ќе биде стартувана константно

и ќе ги мигрира објектите еден по еден. Овој пристап дозволува сите објекти да бидат

мигрирани во познат период на време без да треба да се чува цел код.

1.8 Карактеристики на прашалници и погледи

Базите на податоци се дизајнирани да решаваат проблеми претставени како

реални Use cases. РСУБП базите на податоци се појавија во свет каде флексибилноста во

пребарувањето била поважна од флексибилност на шемите. Од друга страна, колона

ориентираните бази на податоци се изградени за да бидат добро прилагодени за чување

на големи количини на податоци низ неколку машини.

Било која базана податоци поддржува пишување и читање на податоци, само што

тоа го прават поразлично една од друга. Некои овозможуваат пребарувања на

произволни полиња, некои обезбедуваат индексирање за побрзо пребарување, други пак,

ад хок поддршка, за трети, пребарувањата мора да бидат планирани.

Релационите пребарувања се декларативни. Извираат од гранка од математиката

позната како торка релациона анализа, која може да се конвертира во релациона алгебра.

РСУБП ги оптимизираат овие прашалници со вршење на конверзија и поедноставување

на алгебрата. Брзината на РСУБП лежи во неговото ефикасно управување со блокови на

34

податоци, редуцирање на читање од диск, оптимизација на прашалници и други техники.

Доколку се пребарува некој запис од некоја табела, алгоритмот ќе мора да ја скренира

секоја редица за да го врати бараниот запис. Без индекси, секоја редица ќе мора да биде

прочитана од диск за да се врати бараната информација. Индексот е специјална

податочна структура која е изградена за да се избегне скенирањето на целата табела кога

се извршува некој прашалник.

Релационите бази на податоци се одличен избор за флексибилно пребарување. Сѐ

додека шемата е дизајнирана на прилично нормализиран начин, без дуплирање и

складирање на пресметливи вредности, би требало да може да се креираат секакви

прашалници.

Во MongoDBможе да се конструираат ад хок пребарувања за вредности на поле,

рангови или комбинација на критериуми. Едно од корисните вградени карактеристики

на MongoDBе индексирањето за да се зголемат перформансите на пребарување. Ова не

е достапно кај сите NoSQL бази на податоци. MongoDB обезбедува неколку од

најдобрите податочни структури за индексирање, како што се Б-дрво, и други додатоци

како што се дводимензионални и сферични GeoSpartial индекси.

Агрегатните пребарувања враќаат структура поразлична од поединечните

документи кои се во базата. Count() агрегира резултат во пребројување на документите,

distinct() враќа резултат во низа од резултати, и group() враќа документи од својот дизајн.

Group() функцијата е моќна како SQL GROUP BY, но MongoDB

имплементацијата има недостатоци. Прво, лимитирана е на резултат од 10 000

документи. Покрај тоа, ако е фрагмент MongoDB колекцијата, group() нема да работи.

1.8.1 Погледи

Поглед е виртуелна табела која настанува како резултат на SQL прашалник над

една или повеќе табели. Креирањето на погледи е едноставно како пишување на

прашалници и префиксирање со CREATE VIEW ime_na_pogled. Па ќе може да се

пребаруваат записите како кај табела.

Погледитесе моќни алатки за отворање на комплесни пребарувани податоци на

едноставен начин.

35

1.9 Визуелизација

Визуелизацијата е многу важна за луѓето. Постои верување дека гледањето или

визуелизирањето е едно од најдобрите начини за разбирање и генерирање на знаење,

како и, интуитивно учење на работите. Визуелизација е визуелна репрезентација на

податоците на некој начин. Техниките за визуелизација ги преведуваат податоците во

корисни информации во графичка форма. Ова помага да се разберат шемите на податоци,

и го олеснува донесувањето на одлуки и анализирањето на податоците. Визуелизацијата,

исто така, ја потпомага комуникацијата со другите, споделувањето на заклучоци и ги

нагласува важните аспекти од податоците.

Една од моќните средства за откривање и разбирање на фактите, проследена со

презентација на истите на интересен и разбирлив начин е визуелизацијата на податоци.

Постојат многу алатки на пазарот за организирање на неструктуираните или

полуструктуираните податоци, како што се релационите бази на податоци или NoSQL.

Сепак, стандардна база на податоци, сама по себе не може да помогне да се анализираат

податоците на ефикасен начин доколку големината на податоци е огромна. Поефикасен

начин на презентација на податоците се графичките модели на податоци кои им помагаат

на истражувачите брзо и поефикасно да ги анализараат податоците. Една од тие алатки

е Spotfire.

36

Слика 3: Презентација на податоци во Sportfire

Spotfire е софтверска платформа за интерактивни анализи на податоци и

визуелизација. Иако не е исцрпна листа, општи типови на визуелизација во Sportfire

вклучуваат бар графика, линија шема, комбинирана графика, пита графикон, топлинска

мапа.

Таа е развиена од страна на TIBCO 1, софтверска компанија базирана на Palo Alto,

CA, US. Првата верзија на Spotfire била лансирана во 1996 година.

Sportfire им овозможува на компаниите и организациите да ги разберат нивните

податоци, па така, тие ќе може да донесуваат информирани одлуки кои за возврат може

да создадат економска вредност. Еден пример за она што компанијата сака да анализира

се податоци за продажба. Бизнисот може да има продавници на повеќе локации и да се

продаваат ранг на различни производи. Со користење на Spotfire (слика 3) им

овозможува на бизнисите и организациите да анализираат, на пример, како продажбата

се разликува на различни локации, кој производ е попопуларен, дали постојат некои

трендови на навиките на потрошувачите итн. Наоди како овие може подоцна да се

користат за донесување на одлуки, на пример, при доделување на буџети на локациите

или кога се одлучува кои производи треба да се стават на полиците, за да се зголеми

успехот на фирмата.

37

Една од најдобрите начини за комуникација на значењето на податоците е преку

извлекување на важните делови и нивно графичко презентирање. Ова е корисно и за

внатрешна употреба, како техника на истражување на обрасци кои не се очигледни од

необработените вредности, и како начин на презентирање на крајните корисници на

разбирливи резултати. Бидејќи веб се префрли на графика од статички слики за

интерактивни објекти, линијата меѓу презентација и истражување стана нејасна.

Можностите на новиот медиум доведуваат до некои фантастични нови алатки.

38

2 Администрирање на бази на податоци

Кога се развиваат и одржуваат реални апликации, круцијално е да се заштитат

серверот и базите на податоци од несреќи или намерни акции кои може да ги избришат,

променат или изложат податоците. Со користење на MySQL софистицираните алатки за

управување со корисници и привилегии, може правилно да се постави безбедносен

пристап до серверот на базите на податоци. Додека пак, MongoDB поддржува едноставен

модел за автентификација кој дозволува администраторот да го ограничи пристапот до

базата на податоци.

2.1 Управување со корисници и привилегии

Кај MySQL, како и повеќето сервери на бази на податоци, корисниците имаат

привилегии кои детерминираат дали тие можат да модифицираат, бришат или да ја

пребаруваат базата на податоци, и исто така дали тие можат да ги модифицираат

привилегиите и да го контролираат серверот. Во пракса, контролата може да биде coarse-

grained—на корисникот може да му биде дозволено или забрането да пристапи до

серверот или fine-grained, каде корисникот може да пристапува само до некои табели од

базата на податоци или само до некои колони во табелата. Некои бази на податоци

поддржуваат само coarse-grained контрола, додека други, како што е и MySQL, ги

дозволуваат двете, и coarse-grained и fine-grained контролата на пристап. MySQL

дозволува да се контролира кои корисници имаат пристап до серверот, базите на

податоци, табелите и колоните од табелите и на типот на акции кои корисниците можат

да ги прават врз тие структури. На пример, MySQL дозволува експлицитна контрола

дали корисниците ќе можат да ги користат SELECT, UPDATE, INSERT и DELETE

изјавите, како и дали тие ќе можат да ги користат LOCK TABLES, ALTER на

структурите, или дали може да креираат и бришат индекси. Може да се креираат

корисници кои ќе може да ги пристапат и да ги модифицираат податоците во базата на

податоци, но од друга страна тие да немаат привилегии да ја прилагодуваат серверската

конфигурација, да ја променат структурата на базата на податоци или да пристапат до

други бази на податоци.

MySQL корисниците се разликуваат од корисниците на оперативниот систем на

серверскиот компјутер. Кога се поставува машината, автоматски се креираат

суперкориснички профили кои дозволуваат конфигурација на серверот – root корисник

39

на Linux или Mac OS X сервер, и Администратор на Windows – и, исто така, еден или

повеќе кориснички профили кои може да се користат за работа со серверот.

Обичните профили не може да пристапат или да ги модифицираат сензитивните

системски датотеки, како што се подесувањето на системскиот хардвер, или MySQL

серверската датотека на логови или датотеките со податоци. Имањето на помалку

привилегиран профил за дневна употреба ги намалува шансите за бришење на важни

системски датотеки или инсталирање на малициозен софтвер по грешка. На

корпорациски или универзитетски сервер, оваа сигурност е есенцијална. Ова не помага

само при заштита од несреќи и малициозни напади, исто така помага и во заштита на

доверливи датотеки и податоци.

Треба да се преземат мерки за одржување на физичка безбедност на серверот, да

се чува оперативниот систем ажуриран, да се додаде мрежен заштитен ѕид, да се користат

соодветни подесувања за дозволи до датотеките и директориумите, и користење на

тешки лозинки. Доколку серверот е небезбеден или компромитиран, и MySQL е

небезбеден, без разлика на тоа како MySQL корисниците и привилегиите се

конфигурирани. Исто така, треба да се внимава на пристапот до бекапите на базите на

податоци.

MongoDB поддржува едноставен модел за автентификација кој дозволува

администраторот да го ограничи пристапот до базата на податоци на база на корисник.

MongoDB овозможува индивидуални извештаи за контрола на пристап до секоја база на

податоци која е зачувана во специјална system.users колекција. За обичен корисник да

има пристап до две бази на податоци, неговото корисничко име и лозинка мора да бидат

додадени во двете бази на податоци.

Доколку се креираат права на пристап за ист корисник на различни бази на

податоци, не постои синхронизација помеѓу овие записи. Со други зборови, доколку се

смени лозинката на корисникот на една база на податоци, тоа не ја променува лозинката

во ниедна друга база на податоци. Постои еден исклучок на ова правило, секој корисник

додаден во специјална админ база на податоци ќе ги има истите права на пристап до сите

бази на податоци, па нема да има потреба да се доделуваат права на такви корисници

поединечно.

2.1.1 Креирање и користење нови корисници

За да се креира нов корисник потребно е да има посебна дозвола за да се направи

тоа, а таа дозвола ја има root корисникот.

40

GRANT изјавата дава привилегии на корисникот.

2.1.1.1 Привилегии

Може да се излистаат сите пристапни привилеги преку стартување на SHOW

PRIVILEGES командата во MySQL. Може да се додадат привилегии на корисник на

различни нивоа, како на пример: на глобално ниво, односно му се дава одредена

привилегија на корисникот врз сите бази на податоци на серверот; на ниво на база на

податоци, односно се доделува привилегија на една или повеќе бази на податоци; на ниво

на табела, каде корисникот има привилегии само врз една или повеќе табели во базата на

податоци; или пак, на ниво на колона, кога корисникот има привилегии на една или

повеќе колони од табелата во базата на податоци.

Привилегиите никогаш не пропагираат нагоре во хиерархијата, на пример,

доколку некој корисник добие привилегија само на ниво на колона, овие привилегии не

важат за табелата, базатата на податоци или серверот. Кога се стартува некоја изјава, за

да се изврши таа изјавасе проверува дали корисникот има некоја од привилегите.

Доколку има привилегија за да ја изврши изјавата, таа се извршува.

MongoDB нуди бројни вградени кориснички улоги кои администраторите ги

користат за контрола при пристап до базата на податоци. Доколку овие улоги не ги

опишуваат саканите привилегии, администраторот може да креира нови улоги со

посакуваните привилегии за одредена база на податоци.

MongoDB користи комбинација од името на базата на податоци и името на

улогата за да дефинира улога. Секоја улога е во склоп на базата на податоци за која е

креирана таа улога.

2.1.2 Локални и далечински (Remote) корисници

MySQL дозволува и локални и далечински (remote) корисници. Локален корисник

се поврзува на серверот и пристапува на базата на податоци од истиот компјутер на кој

работи MySQL серверот. Спротивно на него, далечинскиот корисникот се поврзува на

серверот и пристапува до базата на податоци од друг компјутер. За секоја апликација,

треба да се одлучи како ќе се користат базите на податоци и да се применат

порестриктивни привилегии за пристап потребни за да се заврши работата.

Перформансните и безбедносните проблеми треба да се земат во предвид кога се прави

тоа. MySQL всушност ги третира локалните конекции различно, доколку клиентот е

локален, конекцијата е направена внатрешно преку Unix сокет (за Linux и Mac OS X) или

41

преку таканаречената “цевка” за Windows. Ова генерално е многу побрзо за разлика од

TCP/IP мрежната конекција која се користи за далечински пристап.

2.1.3 Привилегии и перформанси

Управувањето со MySQL корисници и привилегии дава добра контрола врз тоа

кој има пристап до кој дел од серверот и самите бази на податоци, исто така и кои

пристапи се дозволени. Сепак, оваа fine-grained контрола доаѓа со цена: кога се

имплементираат комплексни кориснички и привилегиски подесувања, проверувањето на

истите за секоја SQL изјава која се извршува ги влошува перформансите. Кога се

избираат корисниците и нивните привилегии, треба да се цели кон баланс на контролата

и перформансите.

Kолку повеќе споредби се потребни за да се детерминираат дозволите, толку

побавно ќе се извршува прашалникот на серверот. Сепак, не треба да се прави компромис

со политиката за безбедност за подобри перформанси.

Управувањето со корисниците на серверот е една од најважните задачи на

администраторот на базата на податоци.

2.2 Логирање

2.2.1 Датотеки на логови

Четири датотеки за записи се користат во mysqld: записот за грешки, бинарни

записи, записот за општи прашалници и записот за бавни прашалници. Петтиот тип на

запис, релеј записот, се користи од помошниот (slave) сервер. Доколку се овозможени

логовите, mysqld ги запишува нив во директориумот на податоци доколку не е поинаку

специфицирано. По правило, логирањето не е овозможено.

2.2.1.1 Запис на грешки

Записот за грешки содржи записи за тоа кога mysqld daemon е започнат и запрен

и, исто така, некои критични грешки доколку се случат додека серверот работи.

Информациите за тоа кога некој настан од распоредот се извршил, кога започнала и

завршила репликацијата, исто така, се запишани во записот за грешки. Записот за грешки

е обичен текст документ. Записот за грешки ги запишува податоците во податочна

датотека со format host_name.err формат.

42

2.2.1.2 Бинарни записи

Бинарните записи се користат заради повеќе причини. Може да се користат за да

се изврши point-in-time обноваза време на процесот на обновување. Друга функција на

бинарниот запис е да се овозможи репликација. Содржина на бинарниот запис е секоја

изјава која се случува во серверот која би можела потенцијално да ја промени базата на

податоци. Немодификуваните изјави како што се SELECT изјавите, не се логирани. За

да се овозможи бинарното логирање се користи log-bin опцијата. Датотеката за

бинарниот лог е текстуална датотека која чува трагови од тековните бинарни логови.

Стандардно, името му е mysql-bin.index.

Бинарните податоци во записот се во бинарен формат. Ова значи дека не може

само да се отвори датотеката со текст едитор и да се прочита. За да се прикажат

бинарните логови во читлив формат треба да се користи мysqlbin log алатката.

2.2.1.3 Записи на општи и бавни прашалници

Датотеките на општите прашалници и дневникот на бавни прашалници се

користат за да се логираат активностите кои се случуваат во базата на податоци. Доколку

е овозможен општиот дневник на прашалници, ги логира сите активности на серверот.

Ова може да биде многу корисна алатка кога ќе се случат некои проблеми.

Генералниот запис ги запишува изјавите како што треба да бидат испратени до

mysqld, вклучувајќи ги оние кои завршуваат со грешка.

Не е препорачливо да се вклучи општиот дневник на прашалници во продукција,

освен ако не е навистина потребно бидејќи ги логира сите активности на серверот и може

да биде штета за перформансите. Генералниот дневник на прашалници може да се

вклучува и исклучува додека серверот сѐ уште работи, па ако генералниот запис е

потребен за дебагирање може да биде овозможен за краток временски период.

Записот на бавните прашалници е сличен на записот на општите, но ги зачувува

само логовите на прашалници кои земаат повеќе секунди од вредноста специфицирана

во серверската променлива long_query_time. long_query_time серверската променлива се

користи да се контролира грануларноста на логирањето на бавните прашалници.

Како и записот на грешки, во речиси секоја ситуација има смисла да се овозможи

записот на бавни прашалници.

Датотеките со логови може за кратко време да зафатат големо место на дискот, па

така тие може да се компресираат за архивирање или да се избришат доколку е потребно.

43

Дури и ако има голем простор на дискот, тешко е да се работи со преголеми датотеки со

логови бидејќи предизвикуваат проблеми и бараат голем мониторинг.

2.2.1.4 Релеј записи

Релеј записите се користат од помошниот серверот за да се зачуваат настаните

кои се примаат од главниот сервер пред да се извршат на помошниот серверот. Тие

користат бинарен формат и бинарните записи може да бидат видени со mysqlbinlog

алатка, исто како кај бинарните записи. Стандардно, помошниот серверот ги зачувува

релеј записите во datadir.

Relay записите автоматски се бришат на помошниот серверот кога ќе се извршат

сите настани во записот и не се повеќе потребни.

2.3 Партиционирање

Партиционирањето не е дел од релационата теорија. Партиционирањето има три

главни цели: да обезбеди менаџибилни податоци, перформанси и достапност.

Партиционирањето е делење на податоците во базата на податоци на различни независни

делови.

Постојат два начина на поделба на табелите во базата на податоци (слика 4):

Хоризонтално партиционирање — кај хоризонталното партиционирање,

различни редици се зачувани во различни табели. Пример, клиенти со ИД-а

помали од 500 000 се зачувани во Клиенти1, додека клиентите со ИД-а поголеми

или еднакви со 500 000 се зачувани во Клиенти2. Овие две табели сега

хоризонтално го делат податочното множество за клиентите. Во хоризонталното

партиционирање, шемите на табелите се сосема исти. За архивирање на постари

податоци најчесто се користи хоризонталното партиционирање. Друга техника

која користи хоризонтално партиционирање е фрагментирањето, која вклучува

користење на различни сервери кои ќе бидат домаќини на слични видови на

податоци. Постојат различни критериуми кои се користат за поделба на табелата

или базата на податоци.

Вертикално партиционирање — кај вертикалното партиционирање, различни

полиња се складирани во различни табели. На пример, имињата на клиентите и

емаил адресите може да бидат зачувани во Клиенти табела и адресата на клиентот

може да биде зачувана во Адреси табела. Често, нормализацијата вклучува

44

вертикално партиционирање. Сепак, вертикално партиционирање обично значи

раздвојување на нормализираните податоци. Во вертикалното партиционирање,

шемите на табели се различни иако тие содржат слични записи. На пример,

Клиенти табелата и Адреси табелата имаат различни шеми. Но двете имаат

примарен клуч од клиент_ид, па и двете можат да чуваат записи за истиот клиент.

Овој тип на партиционирање исто така се вика и поделба на редици, бидејќи редот

е поделен во повеќе од една табела. Различни физички складишта може да се

користат во вертикалното партиционирање. На пример, зачувување на слики и

документи во системот на датотеки наместо во базата на податоци, е класичен

пример на вертикално партиционирање со користење на различни физички

складишта. Најчеста форма на вертикално партиционирање е поделба на

динамичките податоци од статичките податоци. Перформансите ќе бидат подобри

кога се пристапува до статичките податоци.

Слика 4: Хоризонтално и вертикално партиционирање

Внатрешното партиционирање во mysqld било огромно подобрување за MySQL,

бидејќи партиционирањето можело да се направи само на апликациско ниво или преку

користење на MERGE табели. Со користење на командите за партиционирање на ниво

на табела, mysqld користи клуч за партиционирање и алгоритам за партиционирање за да

ја определи поделбата на податоците помеѓу партиции.

Алгоритми за партиционирање се:

45

Ранг — се избира партиција преку определување дали клучот на партиција е во

внатрешноста на опсегот на вредности. Пример е партиционирање на сите редици

врз основа на клиент ИД; вредностите помали од 500,000 може да одат во една

партиција, а вредностите поголеми или еднакви на 500,000 може да одат во друга.

Листа — се доделува партиција во зависност од листа на целобројни вредности.

Доколку клучот за партиционирање има некоја од вредностите од одредена

партиција, партиционирањето е избрано.

Хеш — вредноста на хеш функцијата определува членство во партиција. Ако има

10 партиции, хеш функцијата враќа вредност од 0 до 9.

Клуч — се користи внатрешен алгоритам од mysqld за еднакво да се

дистрибуираат податоците низ партициите. Полето наречено клуч колона, се

користи за определување на податочната распределба.

Ранг и Листа партициите може да бидат субпартиционирани со користење на Хеш

или Клуч партиционирањето. Ова е познато како композитно партиционирање.

Секоја од овие алгоритми за партиционирање користи клуч за партиционирање за

определување во која партиција податоците ќе се зачуваат. Овој клуч на партиционирање

е дефиниран при креирањето на партицијата и мора да биде целоброен број.

2.3.1 Ранг партиционирање

Партиционирањето за поделба на податоците врз основа на опсегот е најчеста

форма на партиционирање која се користи со MySQL. Со овој тип на партиционирање,

партициите треба да бидат дефинирани во редослед од најмал до најголем, инаку се

јавува грешка.

Клучот за партиционирање кај овој алгоритам може да биде поле или израз.

2.3.2 Листа партиционирање

Листа алгоритмот за партиционирање доделува податоци на партициите врз

основа на листа со вредности.

2.3.3 Хеш партиционирање

Хеш партициите еднакво ги распределуваат податоците низ предетерминираниот

број на табели. Хеш партиционирањето го користи модуларниот оператор (%) за да ги

дистрибуира податоците низ овие партиции. За разлика од Ранг и Листа

46

партиционирањето, имињата на партициите и совпаѓачките критериуми за клучот на

партиционирање не се дефинираат од корисникот.

2.3.4 Клуч партиционирање

Клуч партиционирањето е слично на хеш партиционирањето. Разликата е во тоа

што Клуч алгоритмот за партиционирање користи различна функција за

партиционирање. Хеш партиционирањето користи %, а Клуч партиционирањето користи

алгоритам сличен на алгоритмот кој се користи во PASSWORD() функција.

2.3.5 Композитно партиционирање

Композитното партиционирање е партиција која е самата партиционирана.

Партициите во Ранг и Листа типовите може да бидат поделени во Хеш или Клуч

потпартиции.

2.3.6 Функционално партиционирање

Партиционирањето може да биде извршено од апликациско ниво исто така. Еден

чест начин на партиционирање на ова ниво е наречено функционално партиционирање.

Со функционалното партиционирање различни сервери се посветени на различни делови

од апликацијата. Еден начин да се направи ова е преку поделба на базата на податоци на

неколку делови и ставање на секој дел на посебен сервер. Пример може да биде веб-сајт

за новости кој функционално ги партиционира податоците низ три бази на податоци:

новости, форуми и архиви. Колку ќе се подобрат перформансите и капацитетот со ова,

зависи од апликацијата. Возможно е да се изврши функционално партиционирње преку

едноставно определување кои табели биле речиси никогаш или нефреквентно здружени

за цели на пребарување и потоа да се преместат тие табели на посебни сервери. Ако

здружувањата се неопходни, тие треба да бидат направени на ниво на апликациски код

или преку федерација табели. Ова е далеку покомплексно отколку претходниот метод и

ретко се користи.

Зборот партиција се користи во две различни концепти во NoSQL. Податочно

партиционирање е механизам на дистрибуирање на податоците низ кластер. Од друга

страна пак, мрежно партиционирање се случува кога два дела од истиот кластер на база

на податоци не може да комуницираат.

На многу големи кластерирани системи, повеќе веројатно е дека ќе се случи

неуспех на едно парче од опремата. Ако мрежниот прекинувач меѓу серверите во кластер

47

падне, се случува феномен кој во компјутерскиот жаргон се нарекува “поделба на

мозокот”. Во овој случај, индивидуалните сервери уште примаат барања, но тие не можат

да комуницираат едни со други.

Ова сценарио може да доведе до неконзистентност на податоците или евентуално

да се намали капацитетот на складирање на податоците.

2.4 Мониторирање

2.4.1 Конфигурирање на опциите за MySQL Monitor

Може да се зачува корисничкото име и лозинката во датотеката за опции и да се

стави на локација каде мониторот ќе гледа. Мониторот автоматски ќе ги внесе

вредностите од датотеката наместо да го прашува корисникот. Не е добра идеја да се

зачувуваат лозинките некриптирани. Треба да се постават барањата за секоја апликација

поодделно.

Во опциската датотека може да се има секција за секоја програма која го користи

мониторирањето. На пример, може да се има [mysql] секција за mysql програма и

[mysqldump] секција за mysqldump програма, слично, може да се има [mysqld] секција за

MySQL серверските daemonsmysqld, mysqld_safe, и mysqld-nt. Опциите кои се заеднички

за сите клиентски програми, може да се консолидираат под [client] секцијата. Слично,

опциите заеднички за сите серверски програми може да се листаат во [server] секцијата.

Треба да се внимава да не се прават програмските опции премногу генерички, на

пример, mysql програмата е клиент и користи опција на база на податоци.

2.4.2 Мониторирање на MongoDB

MongoDB дистрибуцијата содржи едноставна статус-мониторинг алатка која е

наречена mongostat. Оваа алатка е дизајнирана главно да овозможи едноставен преглед

за тоа што се случува на серверот. Mongostat е најсеопфатната достапна алатка за

мониторинг. Дава бројни информации за тоа што се случува на серверот, од грешки во

лоадирање на страните до бројот на отворени конекции. Овие статистики произведени

од страна на оваа алатка не се обемни, но може да овозможат добар преглед на она што

се случува на MongoDB инсталацијата. На пример, овој приказ дозволува да се виде

колку често операции од базата на податоци се изведуваат, колку време е блокирана

апликацијата дури чека за отклучување на базата на податоци и слично.

48

Слика 5: Мониторирање на MongoDB

Главните колони од интерес се првите шест колони, кои ја покажуваат стапката

по која mongod серверот се справува со одредени операции. Другите колони се земаат во

предвид кога се дијагностицираат проблеми со инсталацијата вклучувајќи го следното:

Го покажува процентот на пребарувања кои не користат индекс. Голема вредност

укажува дека треба да се додадат некои индекси во системот,

Покажува колку конекции се отворени од mongod инстанцата. Висок број укажува

дека постои проблем во апликацијата со ослободување на конекциите после

операциите,

Покажува колку време серверот ги држи конекциите заклучени. Висока бројка

укажува на тоа дека се извршуваат блокирачки операции кои најдобро би било да

се стават во период на одржување.

Ако работи кластер, може да се изврши посебен mongostat за секој сервер, но исто

така може да се стартува mongostat --discover на mongos и тоа ќе го открие секој член на

кластерот и ќе ги покаже нивните статистики.

Мониторингот е важен кога има кластер. Сите совети за мониторирање на еден

јазол се применуваат и за мониторирање на повеќе јазли.

Голем дел од информациите обезбедени од страна на mongostat се истите

информации кои може да се добијат од повик на db.serverStatus(). Не би било голема

задача да се креира сервер кој го користи ова API на секои неколку секунди, и да ги става

резултатите во MongoDB колекција. Постојат многу адаптери за MongoDB кои

дозволуваат да се користат заеднички системи со отворен код или комерцијални системи

за мониторирање, вклучувајќи алатки како Nagios, ganglia и cacti.

49

2.5 Бекапи и обновување

Сите забораваме да направиме бекапи, и како што законот на Марфи гласи: "Хард

дискот на компјутерот ќе “падне” баш кога содржи витални информации кои не биле

бекапирани".

Бекапите имаат тенденција да бидат една од омилените теми на систем

администраторите и луѓето одговорни за операциите на системот. Во повеќето

организации, податоците се основни средства и затоа нивното чување е од огромно

значење. Бекапите и обновувањата се неопходни во случај на катастрофа, но исто се

клучни во формирањето на репликации, надградби, миграции и неочекувани промени на

податоци.

Бекапот и обновувањето се делови од големата слика на планирањата за

катастрофи и обнова од нив, како и поставување на нови помошни сервери и средини за

тестирање и развој.

Одржувањето е витална задача која треба да биде вклучена како дел од дневните

задачи на администраторот на базата на податоци. Одржувањето на базата на податоци

вклучува реизградба на индекси, ажурирање на статистики, мониторирање на

перформанси и безбедност, проверка на конзистентноста на базата и извршување на

бекапи. Секоја задача треба да биде направена во регуларни интервали, со интервали

базирани на барањата и потребите на организацијата. Базите на податоци може да бидат

бекапирани на диск, дискета или мрежна патека. Со користење на бекапите,

администраторот на базата на податоци може да ги ресторира од последниот бекап или

од одредено време.

Креирањето на ефективни бекап решенија може да стане проблем кога се работи

со големи системи на бази на податоци. Често, времето потребно за правење на копија

на базата на податоци трае со часови. За тоа време, треба да се одржува базата на

податоци во конзистентна состојба. Колку побрзо се направи копијата, толку помалку

време серверот на базата на податоци ќе биде замрзнат.

2.5.1 Користење на бекапи

Постојат повеќе причини зошто да се има бекап на податоците:

Обнова од катастрофи

50

Повеќето луѓе мислат дека обновувањето од катастрофи е единствената причина

за правење на бекапи. Постојат повеќе видови на катастрофи кои треба да се планираат.

Важен дел од планот за бекапирање е утврдување на честите и нечестите катастрофи и

планирање на соодветен одговор за истите.

Обнова на податоци

Доколку се случи клиентите да ги избришат податоците и после една недела да

сфатат дека им требаат или доколку некој нов код ажурира погрешни записи, податоците

може да се обноват од бекапот.

Лесно креирање на сервер за тестирање

Може да бидат креирани сервери за развој на тестови, за лоадирање на тестови,

QA и содржински сервери. Некои компании имаат регуларни неделни ресторирања.

Користењето на бекапи за да се креира сервер за тестирање е добра причина да се

бекапира само дел од базата на податоци.

Лесно креирање на помошен сервер

Правилно конфигурираните бекапи го прават лесно создавањето на нов помошен

сервер. Реплицираниот сервер може да служи како бекап за обновување од катастрофи,

но не и за податочно обновување. Доколку по грешка се избришат податоците на

мастерот ова ќе биде реплицирано и на помошниот и така нема метод за да се вратат тие

податоци.

2.5.2 Фреквенција на бекапирање

Одговорот на прашањето колку често и каков вид на бекап треба да се прави е –

зависи. Зависи од тоа колку често податоците се ажурираат и колку значајни се тие

ажурирања за организацијата. На пример, не е страшно да се изгуби некој кориснички

коментар на некој запис, за хобија, но страшно е да се изгубат податоците за продажба

на производи или податоците во банките. На некои компании им е совршено да прават

целосен бекап еднаш месечно без да прават некој друг вид на бекап. Овие компании мора

да бидат подготвени да ја изгубат месечната промена на податоците. Правењето на

целосен бекап еднаш месечно и одржување на делумни (поединечни) бекапи не губи

51

податоци, но ресторирањето фаќа подолго време затоа што треба да се применат делумни

(поединечни- incremental) бекапи.

Од друга страна, некои компании извршуваат целосен бекап секоја ноќ,

извршуваат делумни (поединечни) бекапи секои 5 минути и ги копираат нив на сервер и

имаат екстра податочен центар конфигуриран и подготвен во случај на губење на

примарниот податочен центар. Ова е исклучително скапо решение, меѓутоа ако

компанијата губи по голема сума на пари во минута кога податоците се непристапни, ова

е прифатливо.

Прашањето што да се бекапира изгледа лесно на површина. Треба да се избере

меѓу целосни или делумни податоци и комплетни или парцијалнин податоци.

2.5.3 MySQL бекапирање

Постојат повеќе видови на бекапи и тоа:

Логички бекап — Логички бекап е креиран преку зачувување на информации кои

ја претставуваат логичката структура на базата на податоци користејќи SQL

изјави како CREATE DATABASE, CREATE TABLEи INSERT. Не е точно да се

рече дека логички бекап е текст репрезентација на серверот на базата на податоци

бидејќи може да постојат нетекстуални бинарни податоци во логичкиот бекап.

Други имиња на логичкиот бекап се експорт и логички експорт. Предностите на

логичкиот бекап се тоа што дозволува администраторот на базата на податоци да

манипулира со бекапираните податоци користејќи алатки како што се dd и grep и

програмски јазици како што се awk и Perl. Потоа, логичките бекапи се повеќе

компатибилни меѓу различни верзии на mysqld кога се надградува серверот на

база на податоци. Sun препорачува логички бекап и ресторирање на базата на

податоци како стандардна практика кога се надградува меѓу различни верзии

(кога се надградува од верзија 5.1 to 6.0) на mysqld. Недостатоците споредено со

физичкиот бекап се тоа што логичкиот бекап е побавен за да се бекапира и

ресторира и може да заземе повеќе место, но подобро компресира.

Физички бекап — Физички бекап е бекап на тековните датотеки на бази на

податоци или партиција на дискот. Ова може да биде многу побрзо за да се

бекапира и ресторира од логичките бекапи. Иако физичките бекапи не

компресираат многу (податоците обично се во бинарен формат и на тој начин веќе

52

се компресирани), физичките бекапи се често помали отколку некомпресираните

логички бекапи. Физичките бекапи исто може да се наречат и сирови бекапи.

Целосен бекап — Целосен бекап е самостоен бекап кој содржи сѐ што има во

базата на податоци. Ако е потребно може да се користат резултатите од

целокупната копија за да се рекреира сервер на друго место. Целосниот бекап

може да биде логички или физички бекап.

Делумен бекап — Делумен бекап е бекап кој содржи само податоци кои се

променети од претходниот бекап. Претходниот бекап може да бил целосен или

делумен. Предноста наделумниот бекап споредена со целосниот бекап е брзината

на бекапирање. Делумните бекапи се користат за да се бекапираат податоци

пофреквентно отколку што дозволува целосниот бекап. На пример, целосен бекап

на големо множество на податоци може да земе 3 часа, и дневниот делумен бекап

може да земе 30 минути. Организацијата може да е способна само да стартува 3

часовен целосен бекап еднаш во неделата, но за време на другите шест дена од

неделата, организацијата може да стартува делумен бекап. На овој начин,

податочното множество може да биде ресторирано како што било во недела,

четврток или кој било друг ден од неделата. Најголемата негативност на

делумниот бекап е тоа што не е целосно податочно множество, и не може да се

искористи сам по себе за да се врати целосното податочно множество. Ова значи

дека делумните бекапи имаат подолго време за обнова отколку целокупниот

бекап, бидејќи последниот целосен бекап и сите делумни бекапи треба да се

ресторираат.

Конзистентен бекап — Конзистентен бекап е бекап во точен момент од времето.

Потребно е време за бекап процесот да се заврши. Неконзистентниот бекап

обично е поедноставен и бара помалку ресурси за да се произведе отколку

конзистентниот. Сепак, неконзистентен бекап не може да се користи како

самостоен бекап. Неконзистентен бекап може да се користи за делумно

ресторирање на податоците.

Hot бекап — Hot бекап е бекап на базата на податоци која сѐ уште работи. За време

на hot бекап, и читањето и запишувањето е блокирано.

Warm бекап — Warm бекап е бекап на база на податоци која сѐ уште работи. За

време на warm бекап, прашалниците за читање не се блокирани, но запишувањата

се забранети да прават некаква модификација на базата на податоци за време на

траењето на бекапот.

53

Cold backup — Ладен бекап е бекап кој се врши додека базата на податоци е

исклучена. Ова дозволува многу лесно да се направи конзистентна копија на

податоците. Негативноста е во тоа што серверот не е достапен за време на

извршувањето на бекапот.

Point-in-time ресторирање — Ова ресторирање е ресторирање на базата на

податоци на специфичен датум и време. Доколку ова не кореспондира со времето

кога е извршен целосен бекап, делумни бекапи и/или сервер логовите мора да

бидат искористени за да се заврши процесот на ресторирање.

2.5.4 Бекапи и обновување кај MongoDB

Кога ќе се случи катастрофа, добриот бекап може да го спаси денот, и во некои

случаи никогаш нема да се жали за времето потрошено во спроведувањето на редовна

политика на бекапи. Сепак некои корисници сѐ уште одлучуваат да живеат без бекапи.

Постојат две генерални стратегии за бекапирање на MongoDB базите на податоци.

Првиот е да се користат mongodump и mongorestore utilities. Вториот, воедно и најчест, е

да се копираат датотеките со сирови податоци.

MongoDB вклучува фасилити за обновување на база на податоци. Може да се

иницира од командна линијаза да се обноват сите бази на податоци на серверот:

$ mongod --repair

Или може да се изврши repair Database командата за да се обнови една база на

податоци:

> use cloud-docs

>db.runCommand({repairDatabase: 1})

Обновувањето е офлајн операција. Додека таа се извршува, базата на податоци ќе

биде заклучена за секакви читања и запишувања. Процесот на обновување работи преку

читање и презапишување на сите датотеки на податоци отфрлајќи ги оштетените

документи во процесот. Тоа исто така и повторно го изградува секој индекс. Ова значи

дека за да се обнови база на податоци, треба да се има доволно место на дискот за да се

зачуваат презапишаните податоци. Обновувањето на голема база на податоци зема

неколку денови.

Доколку нема доволно време или ресурси за комплетно обновување, може да се

репродуцираат индексите. За да се реизградат индексите, се користи reIndex() методот:

54

> use cloud-docs

>db.spreadsheets.reIndex()

2.5.4.1 Копирање на податочните датотеки

Еден начин на креирање на бекапи е да се прави копија на сѐ што се наоѓа на

директориумот на податоци. Бидејќи не може да се копираат сите датотеки во еден

момент без поддршка од системот на датотеки, треба да се заштитат датотеките на

податоци од промени додека се прави копирањето. Ова може да се постигне со командата

наречена fsynclock:

>db.fsyncLock()

Оваа команда ја заклучува базата на податоци од секакви натамошни запишувања

и потоа се осигурува дека датотеките во директориумот на податоци ги имаат последните

информации и не се менуваат. Откако ќе се стартува оваа команда, mongod ќе ги стави

на ред сите дојдовни запишувања. Нема да се изврши процес на запишување сѐ додека

не се отклучи. Откако ќе заврши fsynclock командата, се копираат сите датотеки во

податочниот директориум на резервна локација. Базата на податоци ќе започне да се

справува со запишувањата нормално.

Како алтернатива на fsynclocking, може да се изгасне mongod, да се копираат

датотеките, и потоа да се стартува mongod back up повторно.

За да се ресторираат податоците од копиите на директориумите, треба да се

осигура дека mongod не работи и дека директориумот на податоци во кој треба да се

ресторира е празен. Се копираат бекапираните податочни датотеки во податочниот

директориум и потоа се стартува mongod.

Може да се ресторираат специфични бази на податоци со копирање само на

датотеки со точно име на базата на податоци во директориумот на податоци.

2.5.4.2 Користење на mongodump и mongorestore

Последниот начин на правење на бекапи е со користење на mongodump.

Mongodump е споменат последен затоа што има неколку негативности. Тој е бавен и кога

се прави бекап и кога се ресторира од него, и има некои проблеми со реплика сетовите.

Сепак има и предности: тоа е добар начин на бекапирање на индивидуални бази на

податоци, колекции и дури и потмножества од колекции.

55

За да се бекапираат сите бази на податоци, едноставно само се стартува

mongodumpалатката.

Mongodump ќе креира dump директориум во тековниот директориум, кој содржи

dump на сите податоци. Овој dump директориум е организиран од база на податоци и

колекција во датотеки и поддатотеки. Актуелните податоци се чуваат во .bson датотеки.

За да се ресторира од mongodump бекап, се користи mongorestore алатката.

Mongodump ја запишува содржината на базата на податоци како BSON датотеки.

mongorestore ги чита тие датотеки и ги ресторира. Овие алатки се корисни за бекапирање

на индивидуални колекции и базите на податоци како и на целиот сервер.

2.5.4.3 Креирање на делумни бекапи со mongooplog

Сите наведени методи на бекапирање треба да прават целосна копија на

податоците, дури и ако мал дел од нив е променет од последниот бекап. Ако има

податоци кои се многу големи во однос на количината која се запишува, треба да се

погледне во делумните бекапи. Наместо да се прави целосна копија на податоците секој

ден или секој викенд, се прави еден бекап, a потоа се користи oplog за да се бекапираат

сите операции кои се случиле до тој бекап. Оваа техника бара две машини, A и B, и

mongod. A е главната машина и B е бекап машината. Постои специјална алатка која доаѓа

со MongoDB која го прави ова лесно. Mongooplog ги копира податоците од oplog од еден

сервер и ги става во податочното множество на друг. Ова го чува бекапот релативно свеж

со податоци. Оваа техника е еден вид на рачно ажурирање.

2.6 Кеширање

Еден од начините за намалување на времето на одговор на прашалниците е

имплементирање на кеширање. Кешот ги зачувува често користените информации на

место каде тие ќе можат да бидат пристапени побрзо. На пример, веб-прелистувач како

Firefox користи кеш за да ги зачува текстот, сликите и другите објекти и често

посетуваните веб-стани на хард дискот. Кога се посетува страна која била претходно

посетена, текстот и сликите не треба да се симнуваат по втор пат.

Како и кеширањето на секоја друга апликација, така и кеширањето со MySQL е

дизајнирано да ги враќа брзо податоците од прашалникот. Постојат три начини на

кеширање на податоците со MySQL: рачно креирање на кеш табели, користење на

56

внатрешно кеширање во mysqld, и користење на memcached дистрибуирани системи за

кеширање.

2.6.1 Кеш табели

Програмерите и администраторите на базите на податоци трошат многу време за

оптимизирање на прашалници. Сепак, еден аспект за оптимизација на прашалници кој е

често занемаруван е дека едноставниот пристап до податоците е побрз отколку со

прашалник со пресметки, сортирање и агрегации. Кеш табелата е обична табела во базата

на податоци која ги чува резултатите од еден или повеќе прашалници за побрзо

пронаоѓање. Резултатите од честите прашалници кои можат да бидат кеширани во табела

се пресметки, рејтинг и суми. На пример, наместо да се пресметува бројот на вкупните

посетители на страна секој пат кога некој ќе ја посети веб-страната, може да се калкулира

вкупниот број на посетители на секои 30 минути и се зачувуваат тие информации во

табела за вкупен број на посетители. Така, побавниот прашалник за пресметка на бројот

се извршува на секои 30 минути, и секој следен пат кога веб-страната е посетена прави

едноставно пребарување во табелата на бројот на посетители. Бенефитот е очигледен.

Губитокот е дека вкупниот број може да не биде 100% точен. Сепак, тоа е доволно добро

- бројот на посетители е обично користен за да се покаже колку луѓе ја посетиле страната.

2.6.2 Работа со кеш за прашалници

Внатрешно, mysqld може да го кешира резултатот од множество на SQL изјави.

Слично на концептот на локален кеш на веб-страна, mysqld може да го спореди

прашалникот со прашалниците зачувани во кешот за прашалници. Доколку прашалникот

е зачуван во кешот за прашалници, резултат е изваден без да се изврши прашалникот

повторно. Ако прашалникот не е зачуван во кешот за прашалници, прашалникот се

извршува и резултатот се зачувува во кешот за прашалници за следниот пат кога

прашалникот ќе се повика резултатот да биде таму.

За користење на кешот за прашалници потребно е повеќе меморија за зачувување

на прашалниците и зема одредено процесирачко време за проверка на кешот за

прашалникот.

Ако кешот за прашалници често се проверува и ретко се наоѓаат совпаѓања,

дополнителното процесирачко време може да им наштети на перформансите, наместо да

им помогне. Треба да се тестира кеш прашалникот пред да се имплементира.

57

Во некои случаи вклучувањето на кешот за прашалници ќе произведе неверојатни

перфомансни подобрувања. Сепак, честа грешка на администраторите на базите на

податоци е да веруваат дека кеширањето на прашалници ќе ги реши повеќето

перформансни прашања. Во реалноста, само прашалниците со одредени карактеристики

ќе имаат бенефит од користење на кеширање на прашалници.

MySQL кеширањето на прашалници е едноставна операција. Ги кешира само

SELECT изјавите со нивните соодветни резултати, но само детерминистичките SELECT

изјави. Детерминистички SELECT изјави се изјавите кои секогаш произведуваат ист

резултат на дадено податочно множество. На пример, SELECT COUNT(*) FROM tbl е

секогаш ист, но SELECT NOW() не е секогаш исто.

Прашалникот кој ќе биде споредуван мора да биде бајт до бајт идентичен со

кешираниот прашалник – самите прашалници не се споредливи, нивните хешови се

споредуваат. Ова значи дека со цел да се совпаѓаат, прашалниците мора да се совпаѓаат

во врска со случајот на сензитивност на зборови и празни места. Пример,

SELECT klient_id,ime from tbl.klient;

SELECT klient_id,ime FROM tbl.klient;

Двата прашалници извршени во командната линија ќе вратат ист резултат. Сепак,

од перспектива на кешот на прашалници, двата прашалници не се идентични. Со првиот

прашалник from е со мали букви, а во вториот прашалник FROM е со големи букви. Од

перспектива на кешот на прашалници не е истиот прашалник. Различни празни места во

прашалниците исто така ќе резултираат со несовпаѓање.

Покрај празните места и големите букви, прашалниците може да бидат видени

како различни во кешот на прашалници доколку користат различни бази на податоци,

различни верзии на протокол или множество на карактери. Не сите SELECT изјави се

кешираат. SELECT изјавите со следните карактеристики нема да бидат кеширани:

Користење на недетерминистички функции,

Повеќето потпрашалници,

Користење на кориснички дефинирани функции,

Користење на привремени табели,

SELECT изјави зачувани во функции, тригери, погледи и настани,

Користење на LOCK IN SHARE MODE или FOR UPDATE,

Резултати поголеми од лимитот на query_cache_limit (1 Mb по дифолт),

58

Користење SQL_NO_CACHE.

Само затоа што прашалникот може да биде кеширан, не значи дека треба да биде

кеширан. Доколку прашалникот се извршува фреквентно и нема резултат кој го

надминува лимитот на query_cache_limit, тој може да биде добар кандидат за кеширање.

Сепак, друг фактор кој треба да се земе во предвид е колку пати кешираниот прашалник

е искористен пред да се отстрани од кешотза прашалници.

Query cache invalidation е кога прашалникот е избришан од кешот за прашалници

бидејќи неговиот резултат можеби се променил. Кога табелата е модификувана или со

DDL или DML (било промена на шемата или промена на податоци), сите прашалници во

кешот за прашалници референцирани на таа табела се инвалидирани и отстранети. Оваа

инвалидација не е многу грануларна – ги инвалидира резултатите базирани на табели, не

на редици. Прашалник може да биде остранет од кешот за прашалници иако неговиот

резултат не е променет, бидејќи табелата на која тој референцира се променила.

Сите прашалници кои немаат совпаѓање во кешот за прашалници ќе користат

повеќе ресурси отколку кога кешот е исклучен. Кога табелата е променета, кешот се

проверува со цел да се избришат прашалниците кои се неважечки.

2.7 Перформанси

Одредувањето колку добро системите работат и каде одредени подобрувања

може да се направат е важен дел од администрирањето со базата на податоци. Најдобар

начин да се утврди е преку бенчмаркинг и профилирање. Бенчмаркинг е извршување на

стандардно множество на програми со цел да се оценат перформансите на системот.

Профилирање е методичен начин на собирање на параметри за системите кои се

тестираат. Овие системи може да бидат во активно тестирање или дури и во продукција

доколку методите за профилирање кои се користат не генерираат големо оптеретување.

Заедно овие може да се користат за планирање на капацитетот. Бенчмарковите

одговараат на прашањето “Дали апликацијата ќе работи побрзо кога ќе се конфигурира

на овој или оној начин?”. Со мерење на множество на активности, бенчмарковите може

да се користат за да се спореди како базата на податоци одговара во дадени услови. Може

да се креираат различни тест сценарија. Возможно сценарио може да вклучува тестирање

на перформансите на базата на податоци со промена на серверските конфигурации,

тестирање на базата на податоци за справување со застој, тестирање на различни методи

за лоадирање на податоци и тестирање на нов апликациски код.

59

Преку планирање и бенчмаркирање може да се забележи кога системот се

доближува до лимитите на неговите способности. Па потоа да се планира или да се

надгради серверот, или да се замени серверот или да се додаде нов сервер доколку

апликацијата ја поддржува таа способност. Со започнување од основната линија за тоа

кои се перформансите на тековниот систем, бенчмаркот дозволува QA и циклусот на

тестирање во процесот на развој да работи подобро и да се заврши поголема работа за

истото време. На крајот, со користење на бенчмарк се овозможува подобро искуство за

крајните корисници на апликацијата.

2.7.1 Профилирање

Профилирањето се користи за да се откријат карактеристиките за системот, без

разлика дали се добри или лоши. На пример, профилирањето може да покаже дека кеш

пребарувањето се користи ефикасно, или дека тоа води до нагласување на некои тесни

грла, како што се премногу I/O дискови. Профилирањето се остварува на голем број на

начини. Тоа може да биде едноставно како извршување на SHOW GLOBAL STATUS

командата. Тоа може да биде и многу комплицирано како програма која ги собира

метричките и генералните статистички податоци за користење на системот во реално

време. Профилирањето се користи во бенчмаркинг – бенчмаркингот без мерења е само

извршување на множество на постапки. Многу од истите техники кои се користат за

профилирање на сервер се користат и во бенчмаркингот.

2.7.2 Бенчмаркирање

Некои од алатките кои се користат за бенчмарк на mysqld вклучуваат mysqlslap и

SysBench.

Постои BENCHMARK функција во mysqld која дозволува да се виде времето на

извршување на експресијата. BENCHMARK функцијата зема два аргумента – бројот за

колку пати е евалуирана експресијата и самата експресија. На овој начин, BENCHMARK

може да се користи за споредување на прашалници. Може да се спореди колку долго се

извршуваат различни функции кои враќаат иста вредност. На пример, за да се изваде

датумот од DATETIME полето, може да се користи соодветната DATE() функција или

може да се користи идејата дека датумот е стринг и да се користи LEFT() функцијата која

го враќа датумот:

LEFT() функцијата е речиси 20 пати побрза.

60

2.7.2.1 Mysqlslap

Mysqlslap програмата емулира лоадирање на клиент на mysqld. Тaа извршува

произволен број на SQL изјави кои се содржани во текстуална датотека. Дел од

генералниот или бинарниот запис може да се користи со mysqlslap. Со неговата

способност на автоматско генерирање на податоци, mysqlslap програмата обезбедува брз

начин на бенчмаркирање на mysqld.

2.7.2.2 SysBench

SysBench програмата (слика 6) обезбедува погенерален преглед на ниво на систем

на серверот на mysqld. Постојат посебни режими за тестирање на перформанси на CPU,

I/O перформанси, брзина на меморија, перформанси на нишка и перформанси на база на

податоци.

Слика 6: Бенчмаркирање со SysBench

Постојат следниве четири возможни команди со SysBench:

Подготовка - извршува подготовка за тестови кои се потребни (FileIO и

OLTP тестови),

Извршување - извршување на одреден тест,

Cleanup - бришење на повремените податоци после извршувањето на

тестот (FileIO и OLTP тестови),

Помош - Прикажувакорисни информации за одреден тест.

61

2.7.2.3 Бенчмарк тестови со користење на YCSB

YCSB (Yahoo Cloud Servicing Benchmark) е тест рамка развиена од страна на

Yahoo. Ова овозможува да се спроведат бенчмарк тестови на складишта со креирање на

“work loads”. Преку овој бенчмарк, ќе се изберат складиштата кои се најсоодветни за

сервисот кој треба да се развива.

Основни операции се Insert, Update, Read и Scan. YCSB во моментов ги поддршува

Cassandra, HBase, MongoDB, Voldemort и JDBC.

62

3 Високо достапни околини

3.1 Скалирање и високо достапни архитектури

Напредокот во технологијата со сензори, зголемувањето на пропусниот опсег,

популарноста на преносни уреди кои може да се поврзат на Интернет, креираа средина

каде дури и малоскалабилните апликациии треба да зачуваат повеќе податоци.

Терабајт податоците, некогаш нечуена големина на количество на информации,

сега е вообичаена. Бидејќи количината на податоци која програмерите треба да ја

зачуваат расте, тие се соочуваат со тешко прашање: како да ги скалираат базите на

податоци?

Денес, во времето на онлајн работењето, каде апликациите треба да работат

постојано и брзо, скалирањето и високата достапност се многу важни.

Скалабилност е способност на системот да ја зголемува пропусната моќ со

додавање на ресурси за да се справи со зголеменото оптоварување. Скалабилноста може

да се постигне или преку обезбедување на поголем и помоќен ресурс за да се справи со

дополнителните барања или тоа може да се постигне со додавање на кластер на обичните

машини за да работи како единица. Вклучувањето на големи моќни машини е

класифицирано како вертикално скалирање. Обезбедувањето на супер компјутери со

многу процесорски јадра и голема количина на дирекно додадени складишта е типично

решение на вертикално скалирање. Ваквите опции на вертикално скалирање се обично

скапи.

Алтернативно на вертикалното скалирање е хоризонталното скалирање.

Хоризонталното скалирање вклучува кластер на системите каде кластерот скалира како

што се зголемува оптоварувањето. Хоризонталното скалирање обично вклучува

додавање на дополнителни јазли за да служат на дополнителниот товар. Некои од

хоризонтално скалирачките инфраструктури на Google, Amazon, Facebook, eBay и

Yahoo! вклучуваат многу голем број на сервери. Некои од овие инфраструктури имаат

илјадници дури и стотици илјади сервери. Обработката на податоците низ кластер на

хоризонтално скалирани машини е комплексно.

Висока достапност значи дека апликацијата работи во поголем дел од времето. Не

сите архитектури кои овозможуваат скалирање ќе понудат висока достапност, и обратно.

63

Чекањето кај РСУБП и застоите се зголемуваат нелинеарно со бројот на

трансакции и конкурентноста. Комерцијални РСУБП се достапни и може да решат многу

од овие проблеми, но тие често се специјализирани, покриваат само одреден аспект и се

многу скапи.

Може да се денормализира моделот на податоци и да се избегнат чекањата и

застоите со минимизирање на неопходните заклучувања, да се изгради хоризонтална

скалабилност без да треба да се партиционира, да се исфрли толеранцијата на грешки и

достапноста на податоците со користење на истиот механизам кој дозволува

скалабилност и она што ќе се добие е NoSQL решение.

3.1.1 Вертикално скалирање

Најлесен начин да се скалираат повеќето бази на податоци е да се надградат со

хардвер. Ако апликацијата работи на еден јазол, обично е возможно да се додаде

комбинација од diskIOPS, меморијаи CPU за да се олеснат тесните грла на базата на

податоци. Техниката на јакнење на хардверот на еден јазол за скалирањето е позната како

вертикално скалирање или скалирање нагоре. Вертикалното скалирање има предности

да биде едноставно, сигурно и ефективно до одредена точка. Доколку се работи со

виртуелен хардвер како Amazon’s EC2 (Elastic Compute Cloud), тогаш може да се

забележи дека тој во голем делне е на располагање. Ако се работи на физички хардвер,

тогаш може да се дојде до точка каде што цената на помоќен сервер станува премногу

висока.

Моќните машини обично чинат многу повеќе од цената на обичниот хардвер. Тие

работат добро сѐ додека не се наполнат целосно со податоци. Во тој момент, не постои

друг избор освен податоците да се преселат во друга поголема машина или да се скалира.

И најголемата машина има лимит на количество на податоци кое може да го складира и

количина која може да ја обработи за да може да се изврши успешно. Кога се скалира

вертикално, во стратегијата за скалирање треба да се зголеми и буџетот однапред. Ова е

особено тешко и комплесно да се процени и да се испланираат потребите за скалирање

бидејќи растот на употребата, растот на податоците и трансакциите често е невозможно

да се предвиди.

3.1.2 Хоризонтално скалирање

Со оглед на предизвиците поврзани со вертикалното скалирање, хоризонталното

скалирање, во изминатите неколку години, стана стратегија за скалирање. Кај

64

хоризонталното скалирање системите се дистрибуирани низ повеќе машини или јазли.

Секој од овие јазли може да биде некој вид на машина која е рентабилна.

Бидејќи хоризонтално скалираната архитектура може да користи обичен хардвер,

трошоците за хостирање на целото множество на податоци може значително да се

намалат, а она што е поважно е дека дистрибуцијата на податоците низ машините ги

ублажува последиците од неуспех.

Неизбежно е машините одвреме навреме да“паднат”. Ако има вертикално

скалирање и машината “падне”, настанува неуспех на машината од која зависи

поголемиот дел од системот. Тоа значи дека само еден сервер треба да падне за да се

урне целиот систем. Спротивно на ова, неуспехот кај хоризонтално скалираната

архитектура претставува помала катастрофа бидејќи една машина е многу помал процент

од системот во целина.

MongoDB уште од почетокот е дизајниран да скалира нанадвор. Неговиот

документ-ориентиран модел дозволува автоматски да се поделат податоците низ повеќе

сервери. Ова може да ги балансира податоците и товарот низ кластерот,

редистрибуирајќи ги документите автоматски.

MongoDB е дизајниран да биде лесно скалабилен на повеќе дистрибуирани

сервери. Два од најголемите проблеми во дизајнот на дистрибуирани бази на податоци

се дистрибуираните операции за соединување (join) и дистрибуираните трансакции.

Двете овие операции се комплексни да се имплементираат и може да дадат лоши

резултати па дури и застој во случај серверот да стане недостапен. Со неподдржувањето

на операциите за соединувањеили мултидокументските трансакции, MongoDB стана

способен да имплементира автоматско решение за фрагментирање со многу подобро

скалирање и перформансни карактеристики, што не би било случај доколку би се

поддржале релационите операции за соединување и дистрибуираните трансакции.

MongoDB е дизајниран да го направи хоризонталното скалирање менаџибилно.

Ова го прави преку механизмот на ранг-базирано партиционирање, познато како

автофрагментирање, кое автоматски менаџира со дистрибуцијата на податоци низ

јазлите. Системот за фрагментирање се справува со додавањето на фрагмент-јазли и со

тоа го олеснува автоматското обновување на грешки.

Ова дозволува програмерите да се фокусираат на програмирање на апликацијата,

а не на скалирањето. Кога е потребно поголем капацитет, само се додаваат нови машини

на кластерот и се дозволува на базата на податоци да определи како ќе го организира

сето тоа.

65

3.1.3 Линеарно скалирање и експресивност

Еден од клучните концепти на големите податоци е линераното скалирање. Кога

системот има линерано скалирање, автоматски се добива пропорционална добивка на

перформанси секогаш кога се додава нов процесор на кластерот.

Експресивноста е способност за вршење на фино-грануларни прашалници на

поединечни елементи од множеството на податоци.

За секоја NoSQL технологија, знаењата за тоа колку се добри нејзините

перформанси во однос на скалабилноста и експресивноста се потребни кога се избира

NoSQL решение. За да се одбере правилниот систем, треба да се идентификуваат

барањата за скалабилност и експресивност на системот и да се осигура дека системот кој

се избрал ги пресретнува двата критериуми. Скалабилноста и екпресивноста може да

биде тешко да се измерат и затоа треба да се креира пилот проект и да се симулираат

реалните оптоварувања со користење на изнајмени системи во облак.

Предизвикот е што рангот на скалабилноста и експресивноста зависат од

спецификациите на бизнис решението. За некои системи барањата за скалабилност може

да се фокусирани на висок број на читања во секунда, а на други може да се фокусирани

на записи во секунда. Други барања за скалабилност може да специфицираат само

големото количество на податоци да се трансформира во текот на ноќта. На ист начин,

експресивноста може да вклучи барања за рангирани пребарувања по целосен текст или

способност да се пребарува за забелешки во текстот.

3.1.4 Хоризонтално или вертикално скалирање

Традиционалните архитектури на бази на податоци се дизајнирани да работат

добро на една машина и наједноставниот начин да се справат со поголемо количество на

операции е да се надгради машината со побрз процесор или повеќе меморија. Поновите

системи за обработка на податоци, како што се Hadoop и Cassandra, се дизајнирани да

работат на кластери на релативно ниско специфицирани сервери и наједноставниот

начин да се справат со поголемо количество на податоци е да се додадат повеќе машини

на кластерот. Овој пристап на хоризонтално скалирање е поефтин бидејќи бројот на

операции, големината на зголемувањето на податоци и најголемите доводи на податоци

за процесирање се однесуваат на хоризонтален модел. Затоа постои цена на чинење на

овој пристап. Пишувањето на код за справување со дистрибуирани податоци е деликатно

и вклучува замена меѓу брзината, скалабилноста, толерантноста на грешки и

66

традиционалните цели на базите на податоци како што се атомичноста и

конзистентноста.

Како и кај другите тешки проблеми, не постои лесно решение кое би ги решило

сите различни видови на скалирање и високата достапност. Многу администратори на

веб базирани апликации откриле дека корисниците ги користат апликациите различно од

очекуваното. Промената на шемата и додавање на карактеристики предизвикува

менување на архитектскиот дизајн. Дури и ако се планира најдобро решение за

апликацијата, барањата може да се менуваат врз основа на тоа како апликацијата се

користи. Преку мерење, планирање, флексибилност и проценка на ризик, може да се

постигне висока достапност и скалабилност и таа да се одржува.

3.2 Решенија за пресметување во облак

3.2.1 Што е пресметување во облак (Cloud Computing)?

Терминот “cloud computing” е изведен од концептуален цртеж кој ги опишува

ресурсите хостирани на голема мрежа (cloud). Се користи облак симбол бидејќи

имплементацијата на ресурс (пример, хардвер, оперативен систем итн.) е скриена. Така,

наместо да се бараат рутери и сервери, се разгледуваат ресурсите презентирани како

сервис. Корисниците на ресурсите не се грижат за тоа како се спроведува услугата, на

општа важност е сервисот да ги задоволува потребите и да биде достапен кога е

потребно.

Облак е колекција на компјутерски ресурси кои се достапни преку интернет

пребарувач или преку интернет или на приватен интранет. Она што ги разликува

компјутерските ресурси во облак од слични компјутерски ресурси во физички податочен

центар е фактот дека ресурсите се достапни преку интернет пребарувач наместо

апликациска програма која директно пристапува до тие ресурси.

Националниот институт за стандарди и технологии (National Institute of Standards

and Technology - NIST) го дефинира пресметувањето во облак на следниот начин:

пресметување во облак (Cloud computing) е модел кој овозможува лесен, мрежен пристап

до заеднички “базен” на конфигурирани компјутерски ресурси (пример: мрежи, сервери,

меморија, апликации и сервиси) кои може брзо да се резервираат и да се ослободат со

минимален менаџерски труд или интеракција со сервис провајдерот. Овој облак модел

промовира достапност и се состои од пет основни карактеристики, три модели на сервиси

и четири модели на деплоирање.

67

Трите модели на сервиси (слика 7) се:

- Инфраструктура како сервис (IaaS). Ресурсите се обезбедени како виртуелни

инстанци на комлетен хардвер или платформи на оперативен систем. Клиентот

може да додаде виртуелизирани компјутерски ресурси по барање (пример:

сервери, балансери). Така компонентите на информатичката структура се

предвидени како компоненти или middleware. Корисникот има пристап и

контрола до ресурсите.

- Платформа како сервис (PaaS). API дозволува клиентите да креираат апликации

специјално дизајнирани да работат на хардверот (платформите) на провајдерот.

Продавачот овозможува средина за хостирање и програмски алатки за да им

овозможи на клиентите да развијат решенија за специфична средина.

- Софтвер како сервис (SaaS). Софтверот е обезбеден како ресурс во форма на

апликации кои работат на хардверот на провајдерот. Корисникот го гледа само

интерфејсот на софтверот со десктоп апликација.

Слика 7: Модели на сервиси во облак

Хардверот, оперативните системи итн. се скриени и контролирани само од страна

на продавачот. Ова е најстариот модел вклучен во дефинирањето на облак и за многу

децении било познато како Application Service Provider (ASP).

Моделите на деплоирање се однесуваат на достапноста и пристапноста на

добиените решенија и вклучуваат:

Приватен - Пристапот до ресурсите е лимитиран само на клиентот.

Заеднички - Пристапот до ресурсите се дели меѓу еден или повеќе корисници.

Јавен - Пристапот до ресурсите е достапен за целата јавност.

68

Хибриден - Ова е инфраструктура составена од две или повеќе други модели.

Обично овој модел резултира со поделба на приватни и јавни ресурси кои може

да комуницираат.

3.2.2 Архитектури на облак

Често користени технологии кај пресметувањето во облак се:

Виртуелизација

Мрежно пресметување

Трансакциско пресметување

Еластичност

3.2.2.1 Виртуелизација

Постојат многу форми на виртуелизација. Во суштина, оваа технологија создава

псевдоплатформи врз основа на концептуален модел на хардверот. На пример, може да

работи инстанца од Microsoft Windows оперативниот систем на Linux машина во

VirtualBox. VirtualBox креира софтверски базиран модел од секоја компонента на

компјутерот. Ова формира основа на која Windows ќе може да се подигне и стартува исто

како да е на реален хардвер.

Ова е само една форма на виртуелизација. Постојат неколку механизми за

симулирање на хардвер, како и оптимизации за лансирање, извршување и управување со

инстанци. Виртуелизацијата користена во повеќето IaaS решенија бара да се користат

претходно пакувани машини наречени слики, каде секоја виртуелна машина се вика

инстанца на сликата. На пример, Amazon облакот користи Xen технологија за

виртуелизација, софтвер со отворен код и често заедничко решение кое дозволува

скалирање на виртуелизираниот хардвер (пример: број на CPU), толерантност на грешки

и други предности.

Покрај тоа, некои продавачи дозволуваат да се менуваат постоечките слики за да

се направи машина според потребите со користење или на специфични алатки за

продавање (како продавач) или со опис на машината во специфичен формат. Ова може

да биде проблем ако корисникот се одлучи да се префрли кај друг продавач бидејќи

тогаш сликите не се пренесуваат.

69

3.2.2.2 Мрежно пресметување (Grid Computing)

Во времето кога компјутерската моќ била лимитирана и потребата за решавање

на комплексни аналитички или научни проблеми била голема, била воведена технологија

наречена мрежно пресметување (grid computing), која дозволува програмите да делат

дополнителна компјутерска моќ во заедница на меѓусебно поврзани машини. Ова работи

со делење на проблемот на помали компјутерски единици кои може да се испраќаат на

други машини за обработка, а потоа да се приберат резултатите и да се корелацираат на

една машина.

Технологијата која им овозможува овие машини да комуницираат е софистициран

механизам со строго дефиниран редослед. Овој механизам може да се демонстрира на

следниов начин: машината за менаџирање на податоците делегира задачи на споредните

машини и потоа ги чита нивните резултати. Ова вклучува поставување на една или

повеќе машини кои ја испраќаат задачата за обработка до било кој поврзан компјутер и

потоа ги враќаат резултатите до менаџерот на податоци. Кога корисникот сака да

учествува во програмата за мрежно пресметување, прво го поврзува сопствениот

компјутер на машина која го праќа пакетот за обработка.

Може и да се мигрираат постоечките решенија на мрежното пресметување или да

се градат нови решенија на мрежното пресметување на пресметување во облак. Оваа

можност е причината зошто некои инсистираат дека пресметувањето во облак е

едноставно мрежно пресметување со виртуелизација. Но, постојат многу повеќе

технологии на пресметување во облак, отколку само овие две технологии.

3.2.2.3 Трансакциско пресметување

Кај трансакциското пресметување се обработени повеќе сегменти на податоци

заедно како една трансакција и поврзани со други податоци. Идејата е да се дефинира

работа која вклучува одредени податоци и извршува некои акции на тие податоци во

еден чекор (трансакција). Најдобрите решенија за мрежно пресметување го користат овој

концепт за да обезбедат уредна достава на резултатите. Сепак, пресметувањето во облак

е малку посложено, односно големи трансакциски апликации се наменети да работат за

подолг период, додека мрежните решенија имаат помало време на извршување. Добра

можност е што може да изгради систем за трансакциско пресметување во облак. За да се

направи тоа, треба да се обезбеди долговечност на компјутерските решенија и да се

обезбедат механизми кои дозволуваат податоците да бидат сегментирани и процесирани

70

во паралела. Повеќето продавачи на простор за пресметување во облак овозможуваат

виртуелизирани ресурси за поддршка на трансакциско компјутерско решение

вклучувајќи балансери за оптоварување, постојани инстанции перманентна поделба на

мрежните ресурси.

3.2.2.4 Еластичност

Еластичност е термин кој се користи за да се опише апстракцијата за вмрежување

или системски ресурс. На пример, Amazon дозволува да се примени дадена IP адреса на

некоја инстанца на сервер во неговиот облак. Ова е од големо значење за трансакциските

системи каде е потребно мноштво од сервери да одговараат на одредена адреса. И покрај

тоа што е во ред да се виртуелизираат серверите за тие да можат да работат било каде во

облакот, мора да постои начин да се осигура дека IP адресата останува константна.

3.2.3 SQL и NoSQL бази на податоци во облак

Oрганизациите се во состојба ефикасно да ги елиминираат потребите за купување

и конфигурирање на скапи хардвери со користење на “облак”. Секоја организација треба

да погледне во цената, сигурноста и контролата на проблемите при одлучување дали да

се земе некој софтверски модел.

Денес голем број на опции на релационите бази на податоци се овозможени да

функционираат во “облак”.

Такви се:

Microsoft’s SQL податочни сервиси на Windows Azure платформата

(microsoft.com/windowsazure/)

Amazon Relational Database Service (RDS), кој хостира кластери на MySQL

инстанци (http://aws.amazon.com/rds/)

Алтернативно, многу Amazon Machine Image (AMI) опции за Oracle, PostgresSQL,

MySQLи други дозволуваат да се постават сопствени кластери на бази на податоци во

EC2 средини. Некои продавачи на РСУБП како Oracle и Greenplum почнаа да нудат

решенија за приватни облак средини.

Работењето на MySQL во облак нема разлика од работењето на MySQL на реален

хардвер. И понатаму може да се прави репликација, да се постави висока достапност и

решенија за скалирање, да се користат истите алатки за мониторирање и менаџирање на

тие решенија. Она што го прави користењето на MySQL во облак поразлично е

способноста за брзо распоредување на стотици сервери секогаш кога се потребни.

71

Најновата генерација на популарни апликации, како Google и Amazon, имаат

постигнато висок степен на достапност и способност истовремено да сервисираат

милиони корисници преку хоризонтално скалирање меѓу неколку машини, проширени

низ повеќе податочни центри. Успешни приказни за високо скалабилни веб апликации,

како оние од Google и Amazon, докажаа дека NoSQL решенијата имаат тенденција да

блеснат над релационите решенија.

Ако скалабилноста и достапноста се приоритет, поставувањето на NoSQL во

облакот е веројатно идеално. Постојат многу “облак”сервис провајдери и достапни се

повеќе NoSQL производи. Во многу случаи како Amazon EC2, има можност да се

инсталира било кој NoSQL производ. Без оглед на слободата на избор, неколку облак

сервис провајдери го прават животот полесен со обезбедување на целосно инсталирани,

конфигурирани инфраструктури на базата на податоци, спремни за употреба.

Google вовел услуги и инфраструктури спремни и лесни за употреба. Облак

платформата на Google, Google App Engine (GAE), брзо се расширила и била брзо

усвоена во краток временски период. Неговата sandboxed средина и недостигот на

поддршка за долги процеси се меѓу неколкуте од нејзините аспекти кои биле несакани.

Иако понудите на Google и Amazon се најпознати и цврсти во нивната категорија,

се појавуваат повеќе опции за бази на податоци на облак. На пример, денес постојат

облак базиран хост за CouchDB и MongoDB. Производителите на CouchDBго вовеле

CouchOne. Слично, MongoHQ е скалабилен MongoDB хост.

3.2.4 Придобивки и ризици од пресметување во облак

Потенцијалните придобивки од пресметувањето во облак вклучуваат:

- Намалено време на работа и време на одговор. Со проширување на мрежата или

скалирачките техники, возможно е да се редуцира количеството на време за

комплетирање на задачите, па дури и подобрување на времето за пристап до

податоци. Може да се користат хардвер базирани решенија за слични ефекти, но

со сериозни инвестициски трошоци. Облак решенијата дозволуваат да се

генерираат онолку машински инстанци колку што се потребни и се плаќа само

толку колку што се користи.

- Минимизирање на инфраструктурниот ризик и одржување. Хардверскиот

неуспех не е повеќе одговорност на корисникот. Продавачите ги поседуваат и

одржуваат машините на кои работат облак системите, па не е потребно голем тим

или инвестирање во сервис провајдери.

72

- Пониски трошоци за влез. Со можноста да се плати само за она што се користи,

веќе не треба буџет за голема инфраструктура. Уште подобро, може да се

зголемува инфрастуктурата тековно и да се редуцира без притоа да се амортизира

хардверот или да се прогласи за вишок.

- Забрзано темпо на развој. Пониските трошоци за влез и можноста да се плати само

за она што се користи значи дека може да се започне со нови апликации со далеку

помали инвестиции отколку во минатото.

Се разбира, за секоја предност постои соодветен недостаток. Некои потенцијални

ризици на пресметувањето во облак се:

- Прекин на услугата. Договорите за услуги (SLAs) имаат тенденција да бидат лошо

дефинирани или непостоечки во полето за пресметување во облак и ако услугата

е несигурна тогаш може да има мал напредок.

- Потенцијални прикриени трошоци. Доколку се соочи со необично тежок товар и

се скалира за да се пресретне, може да се успее во исполнувањето на потребата,

но се прават големи трошоци за користење на тоа.

- Недостиг на карактеристики. Може да се донесе одлука дека е потребно да се

имплементираат функции во архитектурата или апликацијата кои продавачот не

ги поддржува.

- Безбедносни ризици. Се делат машините со другите корисници, па може

податоците да бидат украдени.

3.2.5 Дали пресметувањето во облак е економичен избор?

Постојат аналитичари и експерти кои го делат мислењето по ова прашање.

Крајниот заклучок е: зависи. Зависи од тоа кој облак провајдер се користи, колку сервиси

се потребни, колку простор е потребно, и за колку време. Една компаративна студија

покажала дека цената на облак решение во споредба со традиционално решение за е-

продавница во период од пет години е само малку пониска кога се користи пресметување

во облак. Ова е доказ дека пресметувањето во облак не нуди многу во заштеда. Сепак,

деталите од испитувањето покажале дека иницијалните инвестиции за традиционално

решение може да бидат многу високи, но на крајот од пет години организацијата ќе

поседува сопствен хардвер, што не е случај доколку користи облак решение. Значи, нема

периодични трошоци за надградувања на опремата кога се користи облак базирано

решение. Студијата не ги вклучува овие трошоци во споредбата и доколку би ги

73

вклучиле, веројатно е дека разликата во петте години би била значително повисока за

традиционалното решение.

Многу клиенти го користат пресметувањето во облак не за да заштедат пари, туку

заради неговата флексибилност. Сепак, има организации кои го гледаат користењето на

пресметувањето во облак како забрането или со страв. На пример, некои организации не

дозволуваат складирање на нивните приватни податоци на системи кои тие не ги

поседуваат и кои некои надворешни администратори од организацијата би можеле да го

користат пристапот до податоците. Еден начин да се надмини оваа лимитација е да се

изолираат податоците и да се користи облак само за јавните податоци.

3.3 Кластер

Справувањето со зголемувањето на податоците и сообраќајот бара повеќе

компјутерски ресурси. За да се справи со овој вид на зголемување, има два избора:

хоризонтално и вертикално скалирање. Скалирање нагоре вклучува поголеми машини,

повеќе процесори, дискови и меморија. Но поголемите машини стануваат сѐ поскапи и

поскапи, и постои реален лимит. Алтернатива е да се користат повеќе мали машини во

кластер. Кластер на мали машини може да користи обичен хардвер и да биде поевтин од

овие видови скалирања. Исто така тој е повеќе еластичен, додека неуспесите на

индивидуалните машини се заеднички; вкупниот кластер може да се изгради за да се

продолжи и после таквите неуспеси, обезбедувајќи висока доверливост.

Големите карактеристики пренесени кај кластерите предизвикуваат нов проблем:

релационите бази на податоци не се дизајнирани да работат на кластери. Кластерираните

релациони бази на податоци како што се Oracle RAC или Microsoft SQL Server, работат

на концепт на фрагментиран диск потситем. Релационите бази на податоци може исто

така да работат како одделни сервери за различни видови на множества на податоци,

ефикасно фрагментирајќи ја базата на податоци. Додека ова го одвојува оптоварувањето,

сите фрагменти треба да бидат контролирани од страна на апликацијата која треба да

следи кој сервер на базата на податоци „разговара“ со кој бит на податоци.

Фрагментирањето се однесува на процес на поделба на податоците и зачувување

на различни делови од податоци на различни машини; терминот партиционирање исто

така се користи понекогаш за да се опише овој концепт. Преку разделување на

податоците низ различни машини, станува возможно да се складираат повеќе податоци

и да се справи со поголемо оптоварување без да се бараат поголеми и помоќни машини.

74

Рачното фрагментирање може да се направи со речиси секој софтвер на бази на

податоци. Тоа е кога апликацијата одржува конекции со неколку различни системи на

бази на податоцикои се комплетно независни. Апликацискиот код управува со

складирањето на различни податоци на различни сервери и пребарување соодветните

сервери да добијат повратни податоци. Овој пристап во принцип работи добро, но е

тешко да се одржи кога се додаваат или се отстрануваат јазли од кластерот или кога треба

да се соочи со променливи податочни дистрибуции или шеми за полнење со податоци.

Фрагмент е еден или повеќе сервери во кластерот кои се одговорни за некое

подмножество на податоци. На пример, ако има кластер кој содржи 1,000,000 документи

претставувајќи кориснички веб-сајт, еден фрагмент може да содржи информации за

околу 200,000 корисници.

Рачното фрагментирање го решава проблемот со оптоварување, неговото

имплементирање не е без грешки. Најзначајна е тешкотијата со мигрирањето на

податоци. Доколку еден фрагмент е преоптоварен, миграцијата на тие податоци до

другите фрагменти е целосно рачен процес. Вториот проблем со рачното

фрагментирање е тешкотијата на пишување на сигурен апликациски код за рутирање на

читањата и запишувањата и менаџирање на базата на податоци во целост.

MongoDB поддржува автофрагментирање со што се елиминираат некои од

административните проблеми за рачнофрагментирање. Кластерот се справува со

разделување на податоци и автоматски ребаланс.

За да се разбере како работи ова, нека постојат податоци за повеќе корисници во

Корисници табелата кои треба да се дистрибуираат низ повеќе сервери на бази на

податоци. Ова може да се направи со назначување на една база на податоци како база на

податоци за пребарување. Оваа база на податоци ќе ги содржи метаподатоците мапирајќи

ги корисничките ID на даден фрагмент. Така прашалникот за корисник може да вклучи

два прашалника: првиот прашалник ќе ја контактира базата на податоци за пребарување

за да ја добие локацијата на фрагментот на корисникот и потоа вториот прашалник ќе

биде насочен кон индивидуалниот фрагменткој ги содржи податоците за корисникот.

MongoDB кластерот обично се состои од три видови на процеси: фрагменти за

складирање на податоци, mongo процеси за рутирање на барањата до точните податоци,

и конфигурациски сервери за чување на податоци за состојбата на кластерот. Секоја од

овие компоненти не е машина. Mongo процесите обично работат на апликациски сервери.

Конфигурациските сервери се прилично лесни и може да работат на било која машина

75

која е на располагање. Секој фрагмент обично се состои од повеќе машини каде се

сместуваат податоците.

Фрагментирањето е дизајнирано да ги исполни следниве три цели:

- Да го направи кластерот “невидлив”- за да се исполни ова, MongoDB доаѓа со

посебен процес за рутирање наречен mongos. Mongos е поставен на предниот дел

од кластерот и изгледа како обичен mongod сервер за сѐ што се поврзува со него.

Ги проследува барањата до точниот сервер или сервери во кластерот, потоа ги

собира нивните одговори и ги враќа до клиентот.

- Го прави кластерот секогаш достапен за читање и запишување. Кластерот не може

да гарантира дека секогаш ќе биде достапен, но во разумни параметри, никогаш

нема да постои време кога корисниците нема да можат да читаат и запишуваат.

Кластерот би дозволил онолку јазли колку што е возможно пред неговата

функционалност значително да деградира. MongoDB обезбедува максимално

работно време на неколку различни начини. Секој дел од кластерот може и треба

да има барем неколку редундантни процеси кои работат на други машини

(оптимално во други податочни центри), па така, ако еден

процес/машина/податочен центар падне, другите ќе можат веднаш (и автоматски)

да продолжат со работа.

- Дозволува кластерот лесно да расте. Бидејќи на системот му треба повеќе простор

или ресурси, треба да се има способност да се додадат истите. MongoDB

дозволува да се додава капацитет колку што е потребно и кога е тоа потребно.

Овие цели имаат некои последици: кластерот треба лесно да се користи и лесно

да се администрира. MongoDB дозволува апликацијата да расте лесно, силно и

природно колку што е тоа потребно.

3.3.1 Избирање на клуч за фрагментирање

Избирањето на добар клуч за фрагментирање е апсолутно критично. Доколку се

избере лош клуч за фрагментирање, може веднаш да се “скрши” апликацијата или може

да се “скрши”апликацијата во случаен момент кога има густ сообраќај.Oд друга страна,

ако се избере добар клуч, тогаш MongoDB ќе додаде сервери кога ќе се појави погуст

сообраќај. Фрагмент клучот определува како податоците ќе бидат дистрибуирани низ

кластерот.

76

3.3.2 Ограничувања

Во фрагментираната средина ограничувањата на максималната стапка на

вметнување се:

Бројот на фрагменти во кластер,

Избран клуч за фрагментирање.

Бидејќи MongoDB ги дистрибуира податоците со користење на парчиња

(деловчиња) врз основа на опсегот на фрагмент клучот, при што изборот на фрагмент

клуч може да контролира како MongoDB ги дистрибуира податоците и капацитетот на

резултирачкиот систем за записи и прашалници.

Во идеален случај, фрагмент клучот треба да има две карактеристики:

Внесувањата да се балансирани меѓу фрагментите,

Повеќето прашалници, за да бидат задоволени, може да бидат рутирани на

подмножество фрагменти.

3.3.3 MySQL Cluster

MySQL Cluster е одлична алатка за копиите на податоците да бидат

партиционирани и чувани синхронизирано на различни сервери. Тоа е посебна верзија

на MySQL. MySQL Cluster е слободно достапен. Ова е многу комплексен и посебен

продукт од стандардниот MySQL сервер.

Во стандардната верзија на MySQL, серверот работи mysqld, податоците се

зачувани на серверот и клиентите се поврзуваат со серверот да работат SQL команди. Во

MySQL Cluster, само SQL јазлите работат mysqld. Податоците се зачувувани само на

податочни јазли кои работат ndbd. Клиентите се поврзуваат со некој од SQL јазлите за

да обработат прашалник; SQL јазолот се конектира со податочните јазли за да ги извади

потребните податоци. Исто така постои и менаџмент јазол кој работи ndb_mgmd.

SQL јазлите се редундантни. Клиентот може да се поврзе со било кој од SQL

јазлите за да работи со прашалници кои пристапуваат до податоците. Клиентот не може

да се конектира директно на податочните јазли за да пристапи до податоците.

Група на јазли е една или повеќе податочни јазли кои чуваат идентични податоци.

Постојат четири податочни јазли во две групи на јазли. Податоците се партиционирани

– половина од податоците одат во едната група на јазли, каде се чуваат четири идентични

копии. Другата половина од податоците оди во другата група на јазли, каде се чуваат

четири копии од податоците. Податочните јазли се редундантни: ако еден податочен

77

јазол не е функционален, постојат уште три други податочни јазли до кои SQL јазолот

може да пристапи.

Менаџмент јазолот е потребен само за време на стартување на кластерот. Тоа

може да се направи редундантно со имање на повеќе од една машина на која работи

ndb_mgmd процес.

Податоците се поделени според тоа колку групи на јазли постојат. Со две групи

на јазли, секој податочен јазол во групата на јазли чува 50% од податоците. Ако има

четири групи на јазли, секој податочен јазол во групата јазли чува 25% од податоците.

MySQL Cluster е добро решение за скалабилноста и високата достапност.

Редундантноста на секој дел се однесува на прашањето за висока достапност.

Партиционирањето и сепарацијата на SQL јазол и податочен јазол се однесува на

скалабилноста. Сепак, MySQL Cluster-от не е соодветно решение за многу апликации.

MySQL Cluster-от бил дизајниран за да зачувува и добива многу од малите податоци брзо

со многу малку прекини, неуспеси и корупција. Ова е постигнато со складирање на

повеќето или сите податоци во меморија.

MySQL Cluster-от дозволува табелите да бидат зачувани на диск. Сепак, сите

полиња со податоци кои се дел од индекс, како и самите индекси се зачувани во

меморијата. Ова значи дека големите табели зачувани во MySQL Cluster ќе бараат многу

меморија. Количеството на меморија потребно за податочен јазол е еквивалентно на

вкупното количество на меморија потребно да се подели меѓу групите јазли.

MySQL Cluster не е претставува општо прифатливо решениекое би го користеле повеќе

луѓе; тоа е решение само за мал број на апликации. Податоците кои се соодветни за

употреба во MySQL Cluster архитектурата се мали, најчесто со фиксна ширина. Типичните инсталации на MySQL Cluster-от вклучуваат инсталирање на

компоненти на кластерот на различни машини во мрежата. Оттука, MySQL Cluster е исто

така познат како мрежна база на податоци (NDB). Кога се користи терминот “MySQL

Cluster,” се однесува на MySQL серверот плус NDB компонентите. Сепак, кога се

користи “NDB” или “NDBCluster” се однесува специфично на кластер компонентите.

MySQL Cluster е систем на бази на податоци кои користат MySQL сервер како

краен корисник за поддршка на стандардните SQL прашалници. Storage engine наречен

NDBcluster е интерфејс кој ги поврзува MySQL серверот со кластер технологијата.

Врската е често конфузна. Не може да се користи NDBcluster storage engine без NDB

Cluster компонентите.

78

Сепак, возможно е да се користат NDB Cluster технологиите без MySQL сервер,

но ова бара пониско ниво напрограмирањесо NDB API.

NDB API е објектно ориентирано и имплементира индекси, трансакции и

справување со настани. Ова дозволува да се пишуваат апликации кои пребаруваат,

зачувуваат и манипулираат со податоците во кластерот. NDB API исто така овозможува

објектно ориентирано справување со грешки за да дозволи правилно исклучување или

обнова за време на грешки.

3.4 API и конектори

Во клиент/сервер системот, интерфејсот меѓу клиентскиот и серверскиот дел е

наречен интерфејс на апликациско програмирање (API). На пример ODBC драјверот

вклучува API. API може да бидe комерцијалeн (proprietary) или стандардeн.

Комерцијален API е оној во кој клиентскиот дел на интерфејсот е специјално дизајниран

да работи со еден одреден краен корисник на серверот. Актуелниот код кој го формира

овој интерфејс е наречен мајчин драјвер (native driver). Тој е оптимизиран за употреба со

специфичен преден клиент и неговите поврзани крајни податочни извори. Бидејќи

мајчините драјвери се оптимизирани за специфични предни апликации и специфични

крајни СУБП со кои тие работат, драјверите имаат тенденција да ги поминат командите

и информациите напред и назад многу брзо, со минимално задоцнување.

Најлесен начин да се користи SimpleDB е да се користи нејзиното REST API. Иако

SimpleDB’s REST API не е темелно RESTful од гледна точка на чистота, овозможува

едноставен HTTP модел базиран на барање-одговор. Најлесниот начин да се тестира ова

API е да се стартуваат операциите користејќи командна линија. SOAP API е исто

достапен за Amazon SimpleDB.

Повеќето системи кои се поврзуваат со базата на податоци преку комуникациски

патеки го прават тоа преку множество на протоколи наречени конектори на базата

(database connectors). Конекторите на базите на податоци најчесто се базирани на Open

Database Connectivity (ODBC) моделот.

MySQL исто така поддржува конектори за Java (JDBC), PhP, Python, и Microsoft

.NET повеќето иплементации на ODBC конекторите исто така ја поддржуваат

комуникацијата преку мрежни протоколи.

ODBC е спецификација за апликациски програмски интерфејс (API). ODBC е

дизајниран за трансфер на SQL командите до серверот на базата на податоци да ги добие

79

информациите и да ги презентира во апликацијата. ODBC имплементацијата вклучува

апликакација дизајнирана да користи API кое дејствува како посредник со ODBC

библиотеката, јадро ODBC библиотека која поддржува API и драјвер за базата на

податоци дизајниран за специфичен систем на бази на податоци. Обично множеството

на клиентски пристап API и драјверот се нарекува конектор. Така, ODBC конекторот

делува како интерпретер меѓу клиентската апликација и серверот на бази на податоци.

ODBC стана стандард за скоро секој систем на релациони бази на податоци. Стотици

конектори и драјвери се достапни за употреба во широк спектар на клиенти и системи на

бази на податоци.

Oracle обезбедува неколку конектори на бази на податоци за програмерите со цел да

им овозможи на апликациите интеракција со MySQL. Овие конектори може да се

користат со апликации и алатки кои се компатибилни со индустриските стандарди

вклучувајќи ODBC и JDBC. Ова значи дека секоја апликација која работи со ODBC или

JDBC може да користи MySQL конектор. MySQL конектори достапни за Oracle се:

Connector/ODBC – стандарден ODBC конектор за Windows, Linux, Mac OS X и

Unix платформи,

Connector/J[ava] - за Java платформи и развој,

Connector/net - Windows .NETразвој на апликации,

Connector/mXJ - mbean за ембедирање на MySQL сервер во Java апликации,

Connector/c++ - c++ програмирање,

Connector/c (libmysql) - развој на апликации во c,

Connector/python - развој на апликации во Python.

Connectors - содржи листа поврзана со MySQL конектори како што се

Connector/C++, Connector/J, .NET, PHP, NDB Connectors и Message API.

80

4 Избор на база на податоци

Релационите бази на податоци се користат за чување на податоци со децении,

додека SQL е дефакто јазик за интеракција со РСУБП. Во последните неколку години, се

појави NoSQL алтернативата, особено за големи, веб скалабилни апликации.

Нерелационите бази на податоци овозможуваат скалирање и брзина која можеби е

потребна за апликацијата. Познавањето на опциите, предностите и недостатоците,

сценаријата каде што тие најдобро одговараат, и каде треба да се избегнуваат се од

клучно значење за да се донесе одлука за избор на база на податоци.

Брзина

Една од основните причини за избор на NoSQL решение е брзината.

Споредувањето и компарирањето (benchmarking) на базите на податоци е нетривијална

задача со оглед на тоа дека секоја база на податоци има сопствено множество на хардвер

и други конфигурациски барања.

Притоа може да се најде целиот опсег на повратни резултати споредувајќи NoSQL

база на податоци во однос на друга со детали за тоа како се извршени тестовите.

Споредба

Изборот на технологија не вклучува само техничка споредба. Исто така важна

улога играат некои други фактори поврзани со документацијата, одржливоста,

скалабилноста и зрелоста, подршката на продавачот, програмерите, лиценцата, цената и

иднина на производот или организацијата.

Техничка споредба

Од техничка перспектива, се споредуваат следниве параметри:

Јазикот на имплементација,

Типови на Engine,

Брзина.

Јазик на имплементација Една од поважните фактори кои играат клучна улога е како да се прошири

производот, доколку е тоа потребно. Програмскиот јазик во кој е напишан производот

одредува голем дел од тоа. Некои од базите на податоци може да обезбедат различни

јазици за пишување на плагијати, но тоа не мора секогаш да биде вистина:

81

Amazon SimpleDB: достапен е на облак и има клиентска SDK за Java, .NET, PHP,

и Ruby. Постојат библиотеки за Android и iOS исто така,

BaseX: пишуван во Java. За да се прошири, мора да се кодира во Java,

Cassandra: сѐ е во Java,

CouchDB: пишуван во Erlang. За проширување се користи Erlang,

Google Datastore: достапен на облак и има SDK за Java, Python и Go,

HBase: во Java,

MemcacheDB: пишуван во C. Се користи истиот јазик за проширување,

MongoDB: пишуван во C++. Клиентските драјвери се достапни во неколку јазици

вклучувајќи, но не лимитирани само на JavaScript, Java, PHP, Python и Ruby,

Neo4j: како и неколку други и ова е во Java,

Redis: пишуван во C, па може да се прошири со користење на C.

4.1 Програмерска продуктивност

Ако се набљудува некоја апликација за претпријатие, ќе се забележи

незадоволство од работата со релационите бази на податоци. Информациите обично се

собираат и се прикажуваат во форма на агрегати, но треба да бидат трансформирани со

цел да се постојани.

Сите видови на NoSQL системите се подобро прилагодени за неуниформирани

податоци. Ако се заглави со строгите шеми со цел да се поддржат ад хок полињата, тогаш

NoSQL базите на податоци може да нудат значително олеснување.

Ова се значителни причини зошто програмскиот модел на NoSQL базите на

податоци може да ја подобри продуктивноста на програмерскиот тим. Првиот чекор за

оценување на ова е да се погледне во тоа што софтверот треба да направи, т.е. да се

работи низ тековните карактеристики и да се види дали и како се вклопува употребата

на податоците. Кога ова ќе се анализира, ќе се согледа дека одреден модел на податоци

изгледа дека добро се вклопува.

Таа блискост на вклопување укажува дека со користење на тој модел се доаѓа до

полесно програмирање. Може да се забележи дека различни модели за складирање се

вклопуваат со различни делови од податоците. Ова може да значи дека користењето на

различни бази на податоци за различни делови од податоците (користењето на повеќе

бази на податоци) е посложено од користење на една. Но предностите на добро

совпаѓање во секој случај може да биде подобро. Кога ќе се види дека моделот на

82

податоци се совпаѓа, треба да се обрне внимание на случаите каде постои проблем.

Имањето на карактеристики кои не се совпаѓаат добро со моделот не е причина да се

избегне моделот - тешкотиите на лошо совпаѓање може да не ги надминуваат

предностите на доброто совпаѓање, но корисно е да се нагласат лошо совпаѓачките

случаи.

Минувањето низ карактеристиките и проценката на потребите на податоците

треба да доведе до една или повеќе алтернативи за тоа како да се пресретнат потребите

на базата на податоци. Ова претставува само почеток, а наредниот чекор е обид да се

работи со тековно градениот софтвер, да се земат неколку првични карактеристики и да

се изградат, додека се обрнува внимание на тоа како едноставно е да се користи

технологијата за која се размислува. Во оваа ситуација, може да биде вредно да се

изградат истите карактеристики со различни бази на податоци со цел да се согледа како

би функционирало најдобро. Луѓето често не се подготвени да го направат ова. Сепак,

ова е суштински начин да се процени колку е ефикасна одредена рамка.

За жал, не постои начин правилно да се измери колку продуктивни се различните

дизајни. Нема соодветни начини да се измери резултатот. Дури и ако се изгради истата

функција, не може точно да се спореди продуктивноста бидејќи знаењето за нивно

градење го прави полесен следниот тек. Она што може да се направи е да се обезбеди

мислење од луѓето кои работат. Повеќето програмери имаат осет кога се повеќе

продуктивни во една или друга средина. Иако ова е субјективна пресуда и може да дојде

до несогласување во тимот, ова е најдоброто што може да се добие.

Исто така, кога се испитува базата на податоци за да се процени нејзината

продуктивност важно е да се проба некој лошо избран случај. На овој начин тимот може

да добие чувство на лесен или тежок начин, за да се добие вкупниот впечаток. Овој

пристап има недостатоци. Често не може да се добие целосна оцена за технологијата без

да се потрошат месеци за нејзино испробување. Но како и многу нешта во животот, треба

да се направи најдобра проценка за да се знаат нејзините недостатоци.

4.2 Перформанси на пристап до податоци

4.2.1 Достапност на податоци

Корисниците треба да имаат пристап до податоците во моментот кога тие им се

потребни. Иако ова може да изгледа очигледно, често пати тоа е занемарено кога

83

програмерите градат одредени решенија за базата на податоци. Достапноста на

податоците може да се гледа од две гледишта:

Податочно траење или постоење и

Ефикасност во пристапот до податоците.

Од гледна точка на податочната постојаност, програмерот треба да се осигура

дека податоците се зачувани безбедно, се бекапирани правилно и се достапни за

соодветните корисници. За да се исполни ова, податоците кои треба да се пристапени од

повеќе корисници треба да бидат зачувани на локација во мрежата.

Сепак, во зависност од тоа за која база на податоци станува збор, помалку од пет

корисници може да бидат во можност да пристапат до податоците истовремено.

Моќноста на сервер базираните бази на податоци е навистина добра: многу сервер

базирани бази на податоци може да се справат со стотици дури и илјадници корисници

кои пристапуваат до податоците истовремено, додека кај локалните бази на податоци тоа

не е можно. Иако мрежното складирање гарантира дека податоците ќе бидат

пристапливи, storage engine кои се користат од страна на сервер базираните бази на

податоци ќе обезбедат дека податоците се зачувани безбедно. SQL Server користи

трансакциски логови за да помогне во оваа област. Активните трансакциски логови се

користат за базата на податоци да се опорави од мали грешки, а бекапираните

трансакциски логови може да се користат за таа да се опорави од големи грешки или

неуспеси. Во секој случај, серверскиот систем воспоставува солидни процеси за чување

на базите на податоци за да обезбеди дека податоците се земаат од базата на податоци

како што треба.

Последниот елемент на постоење на податоците е бекапот. Бекап

карактеристиките на сервер базираните системи на бази на податоци се обично многу

пошироки од оние на локалните бази на податоци. Всушност, повеќето локални бази на

податоци се бекапираат само на датотечно ниво. Целата датотека е копирана на бекап

локација и податоците се бекапираат на овој едноставен начин. Овој едноставен метод

може да изгледа корисен, но му недостига една важна карактеристика – способноста да

се бекапира базата на податоци додека корисникот е врзан за неа. Сервер базираните

системи обично ја овозможуваат оваа карактеристика. На пример, SQL Server дозволува

онлајн бекапи на податоците кои се во базата на податоци. Оваа карактеристика

дозволува бекапите да се случуваат 24/7 во бизнисот, и е од суштинско значење за

модерните системи на бази на податоци.

84

За податоците да постојат или да перзистираат, без оглед на катастрофата, мора

да се земат во предвид следните три фактори:

Податоците мора да бидат соодветно зачувани кога се иницијално внесени,

Податоците мора да бидат бекапирани за да се заштитат од катастрофи,

Податоците мора да бидат достапни на барање на корисниците.

SQL Server ги овозможува сите три фактори.

Следниот елемент на достапноста на податоците е ефикасниот пристап. Едно е

корисниците да можат да дојдат до податоците кои им требаат, а сосема друго е

корисниците да можат да дојдат до нив навремено. Сервер базираните системи на бази

на податоци имаат многу посложени алгоритми на заклучување, кои им дозволуваат да

се справат со многу повеќе корисници побрзо отколку на локална или база на податоци

за еден корисник. SQL Server може да ја заклучи целата табела, една податочна страна

(која може да содржи една или повеќе редици), или еден ред (запис). Покрај тоа, SQL

Server може да користи различни типови на заклучување. На пример, заедничкото

заклучување може да се искористи за читање на податоците. Овој тип на заклучување

дозволува другите корисници да ги читаат истите податоци без да чекаат првото

корисничко заедничко заклучување да се ослободи. Се разбира дека може да се користат

и ексклузивните заклучувања при модифицирањето на податоците за да се обезбеди

интегритетот на податоците.

Од перспектива на податочната достапност за мултикориснички апликации, не

постои споредба меѓу соодветен серверски базиран систем на база на податоци како SQL

Server и база на податоци за еден корисник како што е Microsoft Access. Кога треба

податоците да бидат достапни до вистинските корисници во вистинско време и повеќе

корисници да пристапат до исти податоци, сервер базираните системи се подобри во

секое време.

4.2.2 Пристап до документи во MongoDB

MongoDB дозволува прашалниците да користат синтакса и семантика кои личат

на SQL.Иронично како што може да биде, сличноста на SQL во светот на NoSQL го прави

пребарувањето на документите полесно и помоќно во MongoDB.

MongoDB поддржува богат спектар на компаратори, вклучувајќи ги: помало од,

поголемо од, помало од или еднакво на, поголемо од или еднакво на, и нееднакво на.

Покрај тоа, поддржува множество на оператори на логики за вклучување и исклучување

како: се содржи во и не се содржи во дадено множество.

85

Множеството на податоци е вгнезден документ, па може да биде од корист при

пребарување врз основа нададена вредност на некоја карактеристика. Во MongoDB, ова

е лесно да се направи. При минувањето низ дрвото со користење на точка нотацијата

може да се пристапи до секое вгнездено поле.

4.2.3 Перформанси на пристап до податоци

Загриженоста што доведе до раст на NoSQL базите на податоци беше брзиот

пристап до големи количини на податоци. Како што се појавуваат големи веб-сајтови,

треба да се расте хоризонтално и да се работи на големи кластери. На почетокот се

развија NoSQL базите на податоци за да им се помогне да работат ефикасно на таквите

архитектури. Постојат многу фактори кои може да ги утврдат подобрите перформанси

на базите на податоци за разлика кај релационите бази на податоци во различни

околности. Агрегат-ориентираните бази на податоци може да бидат многу брзи за читање

и прибирање на агрегирани податоци во споредба со релационите бази на податоци каде

податоците се распоредени низ многу табели.

Фрагментирањето и репликацијата преку кластери дозволува хоризонтално

скалирање. Граф-базираните бази на податоци може да повлечат високо конектирани

податоци многу побрзо отколку со користење на релационите соединувања.

При проценување на перформансите, најтешката работа е одредувањето на реално

множество на тестови за перформансите. При тоа многу е важно подмножеството да биде

веродостоен претставник на базата. Не е добро да се земе база на податоци која треба да

им служи на стотици истовремени корисници, а да се оценуваат нејзините перформанси

со еден корисник. Треба да се изградат репрезентативни оптоварувања и податочен

волумен, треба да се изберат сценарија кои се најчести, кои се перформансно зависни, а

не оние кои не се вклопуваат во моделот на податоци.

86

5 Студија на случај – Тестирање на перформансите на претставници на SQL и NoSQL бази на податоци

Во претходните глави беа претставени примарните разлики меѓу SQL и NoSQL

базите на податоци. Во оваа глава е земен пример и специфични сценарија преку кои ќе

се прикажат поконкретно разликите меѓу двете категории на бази на податоци,

прикажани преку податоци од тестирање на две претставници на овие категории на бази

на податоци.

SQL базите на податоци се идеални за проекти каде барањата може да се утврдат

и интегритетот на податоци е од суштинско значење. Најдобро работи со јасно

дефинирани, дискретни елементи со точни спецификации, на пример, онлајн продавници

и банкарски системи. За разлика од нив, NoSQL базите на податоци се идеални за

неповрзани, неопределени или променливи барања за податоци, каде брзината и

скалабилноста се многу поважни, на пример, социјални мрежи, менаџмент и веб

аналитички системи.

Кога се извршува тестирање на перформанси обично треба да се провери целата

апликација за да се измери крајното кориснички искуство. Но пред да се одлучи за тоа

која база на податоци ќе се користи треба да се направат тестирања на секоја компонента

на алтернативните бази на податоци одделно за да се провери времето на извршување на

одредени прашалници, ефикасноста на хоризонталното скалирање, репликациите,

неуспесите и да се избере базата на податоци која најдобро ќе одговара.

Apache JMeter е одлична алатка за тестирање која овозможува увид во тоа како

апликациите се однесуваат при оптоварување, овозможувајќи им на организациите да се

фокусираат на правење на соодветни подготовки за испорака на квалитет, стабилност и

сигурност на базите на податоци, а со тоа и на апликациите.

Во овој труд се користи токму таа алатка, Apache JMeter, можеби најдобрата

алатка со отворен код за тестирање на перформанси која е достапна денес на пазарот.

Резултатите од извршените тестирања може да се покажат во облик на дрво, табели

графици или едноставно запишани во датотека со логови. Различни погледи ги

покажуваат информациите на различни начини.

Извршени се тестирања на операциите за креирање и читање на податоци врз

претставник на SQL база на податоци, односно MS SQL Express, и претставник на NoSQL

база на податоци, односно MongoDB, кои ќе се користат при споредба на перформансите

87

на двете бази на податоци. За поедноставен преглед на содржината на базите на податоци

се користат алатките SQL Management Studio и Robomongo.

Направени се по 3 различни планови за тестирање на операции врз двaтa сервери

на бази на податоци. Во првиот тест креирани се 1000 корисници кои испраќаат барања

до базите на податоци за запишување и читање на податоци со помала конкурентност,

односно на секоја секунда ќе испраќа барање следниот корисник. Кај вториот тест

зголемена е конкурентноста при истиот број на корисници. За таа цел тест планот

користи 1000 корисници со чекање од 0.5 секунди за да започне следниот корисник, и во

третиот тест се користат поголем број на корисници за да се виде какво е справувањето

со поголем товар и исто така е зголемена конкурентноста. Се користат 2500 корисници

кои испраќаат барање до серверот во исто време. За да се направи тој план се користат

следните елементи од JMeter: Thread Group, JDBC Request, и неколку видови на извештаи

и тоа: Summary Report, Agregate Report, View Results in Table, View Results Tree, Agregate

Graph, Response Time Graph, Statistical Agregate Report.

5.1 Подготовка на планот за тестирање

Во JMeter се додаваThread Group елементот кој му го кажува на JMeter бројот на

корисници кои треба да се симулираат и колку често корисниците ќе испраќаат барања.

Потоа се сетира rаmp-up период кој покажува колкаво ќе биде чекањето додека започне

следниот корисник. Во првиот пример вредноста за 1000 корисници е 1000 секунди rаmp-

up период, што значи деказа 1000 корисници и 1000 секунди ramp-up период чекањето

меѓу започнувањето на корисниците би било 1 секунда, односно 1 секунда после

започнувањето на првиот корисник, би започнал и вториот корисник. Во Loop Count

полето има вредност 1, што му кажува на JMeter колку пати да се повтори тестот.

За вториот тест ќе се промени само ramp-up периодот на 500 милисекунди, а во

третиот тест бројот на корисници ќе биде 2500, а ramp-up периодот 0, што би значело

дека сите корисници истовремено ќе ги испраќаат барањата.

88

Слика 8: Поставување на бројот на корисници и конкурентноста во JMeter

Откако се дефинирани корисниците, се внесува URL до базата на податоци до

која ќе се пристапува, потоа, JDBC драјвер класа која ќе се користи. JMeter креира

конекција до базата на податоци со специфицираните конфигурациски поставувања.

Слика 9: Поставување на конфигурации во JMeter

На крај се дефинираат задачите коишто треба да се извршат, JDBC барањата,

односно се пишуваат прашалниците кои треба да се извршат и се избираат начините на

приказ на резултатите од тестирањето.

5.2 Резултати од тестовите

5.2.1 Запишување на податоци

Извршени се три тестови на запишување на двете бази на податоци: MS SQL

Express и MongoDB. Резултатите се генерирани во различните погледи кои ги нуди

JMeter.

89

Кај првиот тест кога бројот на корисници е 1000, а ramp-up периодот е 1000

секунди, резултатите се следни:

Слика 10: Тест 1 при запишување во MSSQL: Агрегиран извештај

Слика 11: Тест 1 при запишување во MSSQL: Статистички извештај

90

Слика 12: Тест 1 при запишување во MSSQL: Збирен извештај

Од извештаите за спроведениот тест (слика 10-12) врз MS SQL може да се

забележи дека доколку се испраќаат барања за запишување во базата на податоци од

страна на 1000 корисници, додека времето измеѓу испраќањето на барањата е 1 секунда,

просечното време кое е потребно за да се изврши едно барање за запишување е 4

милисекунди. Средна вредност на одговор на барањето е 3 милисекунди.

Минималното време на одговор е 1 милисекунда, додека пак максималното е 951

милисекунда. Во примероците немало грешки, а пак пропусната моќ која е всушност

излез по единица време, односно количина на оптоварување на серверот и е прикажана

во полето Throughput и истата изнесува 1.0 во сек.

Истиот тест кај MongoDBбазата на податоци ги покажа следниве податоци (слика

13-16):

91

Слика 13: Тест 1 при запишување во MongoDB: Агрегиран извештај

Слика 14: Тест 1 при запишување во MongoDB: Извештај за времето на одговор

92

Слика 15: Тест 1 при запишување во MongoDB: Статистички извештај

Слика 16: Тест 1 при запишување во MongoDB: Збирен извештај

Овој тест кај MongoDBзаврши со следниве резултати: просечна вредност на

одговор на барањето е 3 милисекунди, средна вредност е 3 милисекунди, минимално

време на одговор е 1 милисекунда, додека максималното време на одговор е 194

милисекунди, оптоварувањето на серверот е 1.0 во сек.

Вториот тест, каде има симулирани 1000 корисници кои пристапуваат со цел да

внесат податоци до базата на податоци, а притоа на секоја половина секунда друг

корисник испраќа барање, резултатите се прикажани на слика 17, 18, 19 и 20.

93

Слика 17: Тест 2 при запишување во MSSQL: Агрегиран извештај

Слика 18: Тест 2 при запишување во MSSQL: Извештај за времето на одговор

94

Слика 19: Тест 2 при запишување во MSSQL: Статистички извештај

Слика 20: Тест 2 при запишување во MSSQL: Збирен извештај

Кај MS SQL просечното време на одговор се зголемило на 6 милисекунди,

средната вредност и минималното време на одговор останале исти, додека пак

максималното време на одговор се зголемило на 1281 милисекунди, а количеството на

оптоварување на серверот на 2.0 во секунда.

Кај MongoDBовој тест ги даде следниве резултати (слика 21-24):

95

Слика 21: Тест 2 при запишување во MongoDB: Агрегиран извештај

Слика 22: Тест 2 при запишување во MongoDB: Извештај за времето на одговор

96

Слика 23: Тест 2 при запишување во MongoDB: Статистички извештај

Слика 24: Тест 2 при запишување во MongoDB: Збирен извештај

Резултатите покажуваат просечно време на одговор од 3 милисекунди, средната

вредност е намалена за разлика од првиот тест на 2 милисекунди, исто така и

минималното време е намалено на 0 милисекунди, но е зголемено максималното време

на 274 милисекунди, а количеството на оптоварување покажува 2.0 во секунда.

Со третиот тест, доколку се зголеми бројот на корисници на 2500 и нивните

барања се испратат истовремено до серверот тогаш се добиваат следниве резултати:

97

Слика 25: Тест 3 при запишување во MSSQL: Агрегиран извештај

Слика 26: Тест 3 при запишување во MSSQL: Извештај за времето на одговор

98

Слика 27: Тест 3 при запишување во MSSQL: Збирен извештај

Кај MS SQL при 2500 корисници кои испраќаат истовремено барања за

запишувања, просечното време на одговор на барањето е 2627 милисекунди, додека пак

средното време е 2647 милисекунди, минималното време е 1369 милисекунди, а пак

максималното е 3810 милисекунди. Исто така зголемено е и количеството на

оптоварување на серверот и изнесува 655,8 во секунда (слика 25-27).

А кај MongoDBтестот ги покажа следниве резултати:

Слика 28: Тест 3 при запишување во MongoDB: Агрегиран извештај

99

Слика 29: Тест 3 при запишување во MongoDB: Извештај за времето на одговор

Слика 30: Тест 3 при запишување во MongoDB: Збирен извештај

На слика 28-30 може да се забележи дека просечното време на одговор на

барањето на корисникот изнесува 548, средната вредност покажува 500, додека пак

минималното време на одговор е 21 милисекунда, а максималното изнесува 1422

милисекунди. Оптоварувањето на серверот е 925,2 во секунда.

Од овие тестови за запишување на податоци, може да се забележи дека во трите

различни сценарија MongoDB покажува подобри резултати.

5.2.2 Читање на податоци

Кај тестовите за читање на податоците се користат истиот број на корисници со

истата конкурентност и истите подесувања, само е променет прашалникот кој би читал

податоци од базата на податоци. При првиот случај на студија, кога има 1000 корисници

кои испраќаат барање до базата на податоци со 1 секунда доцнење, се добиени следниве

резултати:

100

Слика 31: Тест 1 при читање податоци од MSSQL: Агрегиран извештај

Слика 32: Тест 1 при читање податоци од MSSQL: Извештај за времето на одговор

101

Слика 33: Тест 1 при читање податоци од MSSQL: Статистички извештај

Слика 34: Тест 1 при читање податоци од MSSQL: Збирен извештај

При Select команда кај MS SQL кога пристапуваат 1000 корисници паралелно со

доцнење од 1 секунда, може да се забележи од слика 31-34 дека просечно време на

одговор е 35 милисекунди, средното време е 34 милисекунди, минималното време на

одговор е 9, додека пак максималното време на одговор е 953 милисекунди, а товарот на

оптварување е 1,0 во секунда.

Истиот тест применет кај MongoDBбазата на податоци ги покажа следниве

резултати (слика 35-38):

102

Слика 35: Тест 1 при читање податоци од MongoDB: Агрегиран извештај

Слика 36: Тест 1 при читање податоци од MongoDB: Извештај за времето на одговор

103

Слика 37: Тест 1 при читање податоци од MongoDB: Статистички извештај

Слика 38: Тест 1 при читање податоци од MongoDB: Збирен извештај

Резулатите покажуваат просечно време на одговор на барањата и медијана од 2

милисекунди, минимално време на одговор под 0 милисекунди, а максималното 56

милисекунди. Тестот се извршил без грешки, а количеството на оптоварување било 1.0

во секунда.

Доколку пристапат ист број на корисници, но со доцнење од 0.5 секунди тогаш се

добиваат следниве резултати:

104

Слика 39: Тест 2 при читање податоци од MSSQL: Агрегиран извештај

Слика 40: Тест 2 при читање податоци од MSSQL: Извештај за времето на одговор

105

Слика 41: Тест 2 при читање податоци од MSSQL: Статистички извештај

Слика 42: Тест 2 при читање податоци од MSSQL: Збирен извештај

Кај MS SQL базата на податоци, при истиот број на корисници кои пристапуваат

со прашалник за пребарување на податоци, со доцнење од 0.5 секунди, може да се

забележи дека просечното време е 34 милисекунди, средното време е 35милисекунди,

додека пак, минималното време се зголемило на 10, а максималното време на 975

милисекунди, како и оптоварувањето на 2.0 во секунда што може да се види од слика 39-

42.

Истиот тест применет на MongoDB ги покажува резултатите прикажани на слика

43-46:

106

Слика 43: Тест 2 при читање податоци од MongoDB: Агрегиран извештај

Слика 44: Тест 2 при читање податоци од MongoDB: Извештај за времето на одговор

107

Слика 45: Тест 2 при читање податоци од MongoDB: Статистички извештај

Слика 46: Тест 2 при читање податоци од MongoDB: Збирен извештај

Кај MongoDB базата на податоци, доколку се зголеми конкурентноста просечното

време на одговор како и медијаната остануваат исти, 2 милисекунди, иста вредност

останала и на минималното време на одговор – 0 милисекунди, додека пак се зголемило

максималното време на 84 милисекунди, а количеството оптеретување на 2.0 во секунда.

Доколку се изврши истиот тест на пребарување на базите на податоци, но притоа

се зголеми бројот на корисници на 2500 кои пристапуваат истовремено со своите барања,

тогаш тестот ги покажува овие податоци:

108

Слика 47: Тест 3 при читање податоци од MSSQL: Агрегиран извештај

Слика 48: Тест 3 при читање податоци од MSSQL: Извештај за времето на извршување

109

Слика 49: Тест 3 при читање податоци од MSSQL: Збирен извештај

Во овој случај може да се забележи дека тестот заврши со голем број на грешки,

односно 51,60% (слика 47-49). Причина за оваа грешка е времето за чекање да се

ослободи ресурсот (timeout). Притоа просечното време изнесува 9322 милисекунди,

минималното исто така е зголемено на 1201, а максималното време на одговор на 13074

милисекунди.

Со овие поставувања, тестот извршен на MongoDB базата на податоци го покажа

следново:

Слика 50: Тест 3 при читање податоци од MongoDB: Агрегиран извештај

110

Слика 51: Тест 3 при читање податоци од MongoDB: Статистички извештај

Слика 52: Тест 3 при читање податоци од MongoDB: Збирен извештај

Од слика 50, 51 и 52 може да се забележи дека просечното време на одговор во

овој случај изнесува 289 милисекунди, медијаната е 290, додека пак минималното време

на одговор на барањето изнесува 0, а максималното време на одговор е 820 милисекунди.

Процентот на грешки е помал тука и изнесува 7,52%. Количеството на оптоварување е

1315,1 во секунда.

111

6 Заклучок

При запишување на податоци во MS SQL и MongoDB од страна на 1000

корисници кои испраќаат барања до базата на податоци на разлика од 1 секунда

MongoDB има побрзо време на одговор на барањето, што значи помало просечно време

од 3 милисекунди, наспроти 4 милисекунди кај MS SQL базата на податоци и помало

максимално време на одговор од 194 милисекунди наспроти 951 милисекунда кај

MSSQL.

Кај вториот тест каде е зголемена конкурентноста на корисниците, односно каде

на секоја половина секунда друг корисник испраќа барање, повторно MongoDB е во

предност. Иако се зголемило оптоварувањето на серверот, сепак MongoDB има исто

просечно време на одговор како кај претходниот тест, а кај MS SQL може да се забележи

декатоа време значително се зголемило на 6 милисекунди, како и максималното време

на одговор на 1281 милисекунди.

Кај резултатите од третиот тест е зголемен бројот на корисници како и

конкурентноста, кога 2500 корисници истовремено испраќаат барање до базите на

податоци, доаѓа до израз големата разлика во перформанси на базите на податоци.

MS SQL има речиси 5 пати поголемо просечно време на одговор на барањата за

разлика од MongoDB. Ова значи, кога има помал број накорисници кои испраќаат барања

за запишување до базата на податоци и помала конкурентност, нема некоја голема

разлика во справувањетосо барањата кај двете бази на податоци, но кога оптоварувањето

е многу поголемо веќе разликите се очигледни.

Кај резултатите од вториот вид на тестирања, каде е извршено тестирање на

базите на податоци при испраќање на барања за читање, односно пребарување на

податоци повторно MongoDB има подобри резултати.

Резултатите од првиот тест за читање на податоци од страна на 1000 корисници

кои испраќаат барање со доцнење од 1 секунда, максималното време на одговор на

барањето е за 17 пати поголемо кај MSSQL. Кога се испраќаат барањата од корисниците

на секои 0,5 секунди, кај MS SQL има пораст во времето на одговор кај сите променливи

кои се набљудувани при тестирањето, додека пак кај MongoDB има мало зголемувањена

максималното време на одговор за разлика од резултатите од првиот тест.

Резултатите од третиот тест при читање на податоци завршија и кај двете бази на

податоци со грешки, со таа разлика што кај MS SQL процентот на грешки е 51,60%, а кај

112

MongoDB е 7,52% заради истекот на времето за чекање да се ослободи ресурсот. Исто

така, има голема разлика во времето на одговор на барањата.

Од извршените тестирања врз двете бази на податоци, може да се заклучи дека

MongoDB подобро се справува со поголем број на корисници, исто и со поголем број на

конкурентни корисници. Времето на одговор на барањата е пократко и завршува со

помал број на грешки.

Потребно е да се направат и дополнителни тестови врз базите на податоци според

карактеристиките на апликацијата која ќе се развива, сѐ со цел да се избере онаа база на

податоци која ќе покаже најдобри перформанси за конкретното решение.

113

7 Користена литература

1. Eric Redmond, Jim R. Wilson, Seven Databases in Seven Weeks: A Guide to Modern

Databases and the NoSQL Movement, 2012

2. Eelco Plugge, Peter Membrey and Tim Hawkins, The Definitive Guide to MongoDB,

2010

3. Reza Rad and Pedro Perfeito, Microsoft SQL Server 2012 Integration Services: An

Expert Cookbook, 2012

4. Kristina Chodorow, 50 Tips and Tricks for MongoDB Developers, 2011

5. Petter Nasholm, Extracting Data from NoSQL Databases A Step towards Interactive

Visual Analysis of NoSQL Data (Master od Science Thesis), 2012

6. Pete Warden, Big Data Glossary, 2011

7. Charles Bell, Expert MySQL, second edition

8. Allen G.Taylor, SQL for Dummies, eight edition 2013

9. Gaurav Vaish, Getting Started with NoSQL – Your guide to the world and technology

of NoSQL, 2013

10. Nich Dimiduk, Amandeep Khurana, HBase in Action, 2013

11. Lars George, HBase: The Definitive Guide, 2011

12. Seyed M.M. “Saied” Tahaghoghi and Hugh E. Williams, Learning MySQL, 2007

13. Dan McCreary and Ann Kelly, Making Sense of NoSQL A guide for managers and the

rest of us, 2014

14. Patrrick LeBlanc, Microsoft SQL Server 2012 Step by Step, 2013

15. Kyle Banker, MongoDB in Action, 2012

16. Karl Seguin, A Little MongoDB Book,

17. Rick Copeland, MongoDB Applied Design Patterns, 2013

18. Kristina Chadorow and Michael Dirolf, MongoDB The Definitive Guide, 2010

19. Kristina Chadorow, MongoDB: The Definitive Guide, second edition 2013

20. Bryan Syverson and Joel Murach, murach’s SQL Server 2008 for developers, 2008

21. Sheeri Cabral and Keith Murphy, MySQL Administrator’s Bible, 2009

22. Charles Bell, Mats Kindahl, and Lars Thalmann, MySQL High Availability, 2010

23. Russell J.T. Dyer, MySQL in a nutshell, second edition 2008

24. Guy Harrison with Steven Feuerstein, MySQL Stored Procedure Programming, 2006

114

25. Pramod J. Sadalage and Martin Flower, NoSQL Distilled, A Brief Guide to the Emerging

World of Polyglot Persistence, 2013

26. Christof Strauch, NoSQL Databases,

27. C.J. Date, Database Design and Relational Theory, 2012

28. C.J. Date, Relational Theory for Computer Professionals, 2013

29. C.J. Date, SQL and Relational Theory: How to Write Accurate SQL Code, second

edition 2012

30. Stephane Faroult with Peter Robson, The Art of SQL, 2006

31. Gaurav Vaish, Getting Started with NoSQL, 2013

32. Bradley Ball, TJay Belt, Glenn Berry, Jes Borland, Carlos Bossy, Louis Davidson, Ben

DeBow, Grant Fritchey, Jonathan Gardner, Jesper Johansen, Jeremy Lowell, Wendy

Pastrick, Kellyn Pot’vin, Mladen Prajdic, Herve Roggero, Chris Shaw, Gail Shaw, and

Jason Strate, Pro SQL Server 2012 Practices,

33. Shashank Tiwari, Professional NoSQL, 2011

34. Kristina Chodorow, Scaling MongoDB, 2011

35. Tom Carpenter, Microsoft SQL Server 2012 Administration – Real World Skills for

MCSA Certification and Beyond, 2013

36. Eelco Plugge, Peter Membrey and Tim Hawkins, The Definitive Guide to MongoDB –

The NoSQL Databases for Cloud and Desktop Computing, 2010

37. Phil Simon, too Big to Ignore, The Business Case for Big Data, 2013

38. Bayo Erinle, JMeter Cookbook, 2014

39. Bayo Erinle, Performance Testing with JMeter, 2015

40. Emily H. Halili, Apache JMeter, 2008