NOSQL бази данни – част 2

08.06.2016

Много NoSQL технологии на база данни имат отлично интегрирани способности за кеширане, поддържайки често използваните данни в системната памет, колкото е възможно и премахват необходимостта от отделен кеширащ слой, който трябва да се поддържа.

 

Различните вендори на релационни БД са предприели различни подходи за реализация на кеширането:

 

• MySQL – MySQL кешира последно подадените към сървъра заявки, като след подаване на заявката се проверява дали резултата не е наличен вече в кеша. Ако е наличен отговора се връща директно от кеша, ако заявката не е кеширана се изпълнява на сървъра, върнатия резултат се кешира и клиента получава отговора.

 

Когато системата е разпределена и има клъстеризация, основен проблем при MySQL е, че всеки сървър в клъстера разполага със свой собствен кеш.

 

• MSSQL/Oracle – MSSQL не кешира последно подадените заявки, а последно четените блокове от паметта като това се нарича data page. Когато бъде подадена заявка към сървъра, първо се проверява за резултат в кеша, ако липсва заявката се подава към сървъра. Преди изпълнението върху сървъра, заявката попада в т.н. Query plans, който се грижи за оптимизирането на заявките с цел повишаване на производителността, след което заявката се изпълнява и резултата се връща на клиента. В MSSQL това става прозрачно от гледна точка на администраторите и те нямат контрол върху процеса. В Oracle нещата стоят по аналогичен начин с разликата, че администраторът има контрол върху този процес, може да определя големината на буферите, кеша и др.

 

 

 

Един от основните проблеми при кеша е т.н. студен старт. Когато имаме сървър кеширан с месеци големи обеми от данни и той се рестартира губи своя кеш. При възстановяването на системата всяка заявка подадена към сървъра започва да се кешира отново. При големи обеми от данни това води до огромно пиково натоварване върху сървъра. Именно тук приложение намират първите noSQL БД. Те се грижат за това да изнесат кеша и да го съхраняват в оптимизирани за целта БД , така след възстановяването на машината кеша се възстановява от БД и загубите в него са незначителни. Пример за такива БД са MemCache и Redis.

 

 

• Възможност за адаптиране и изменение – Този недостатък е открит от Twitter, след това WordPress правят тестове в тази насока и потвърждават. Twitter първоначално залага на MySQL като БД за своята платформа. След нарастване на обема от данните и достигане на няколко ТВ схема се установява, че процесът за модификация на схемата или е невъзможен или е изключително бавен. Поради тази причина от Twitter решават да мигрират от MySQL към noSQL – Cassandra. В процеса на миграция обаче се сблъскват с ефекта, че не могат да добавят допълнителни колони в таблиците, защото след себе си добавянето на всяка нова колона води до увеличаването на данните в големи размери.

 

При noSQL БД този проблем не съществува поради факта, че те нямат схема , измененията в тях са динамични и не са обвързани със структурата.

 

 

• Нарушаване на релационния модел като метод за оптимизация – С това явление също се сблъсква Twitter. Те забелязват, че при големи обеми от данни заявки от типа SELECT вървят сравнително бързо, но заявки от рода на JOIN са няколко десетки пъти по-бавни. За да намерят бързо е ефективно решение започват да дублират една и съща информация в няколко таблици като идеята е била да се изпълнява SELECT само върху една таблица, което да увеличи производителността. Производителността се повишава за сметка на дублираните данни, което нарушава нормалната форма на данните и oт там релационния модел като цяло. В Twitter се е наблюдавала изключително тежка деформация на данните като съхраняваните в системата данни са били няколко хиляди пъти повече от реално необходимите.

 

NoSQL се справя успешно с този проблем като оптимизира т.н. Map/Reducer модел

 

Благодарение на проблемите който решават noSQL БД те започват да намират все по-голямо приложение в съвременните системи. Намираш приложение в:

 

• Системи за управление на профили

Целта тук е да се повиши удовлетвореността на клиентите и приходите от доволни клиенти с повтарящ се опит въз основа на данни от актуален профил за всеки потребител.

 

• Системи за откриване на измами

В този случай разкриването на измами разчита на NoSQL данни – правила, информация за клиентите, информация за сделките, местоположение, време на деня, и още – прилага се в мащаб и в реално време.

 

• За интернет на нещата

Някъде между 26 милиарда и 30 милиарда устройства ще бъдат свързани с интернет на нещата до 2020 г. според оценки съответно от Gartner и ABI Research. От екологичен мониторинг до управлението на инфраструктурата, производството, управлението на енергията, здравеопазване и т.н., NoSQL базите данни ще помогнат да се събират, управляват и организират всички тези данни.

 

• Системи за управление на каталози

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

 

• Системи За цифрови комуникации

От SMS‑ите до мигновените съобщения и още, NoSQL може да поддържа големи масиви от данни и потенциално милиарди съобщения в реално време.

 

• Системи за пълен поглед върху клиентите

Обобщават се различни типове данни, за да се получи един цялостен поглед върху всеки клиент – това увеличава продажбите към съществуващи клиенти, както и възможностите за продажба на допълнения към даден продукт.

 

•  Системи за управление на съдържанието

Събират се и организират множество типове данни и атрибути – включително структурирани, полу- и неструктурирани данни.

 

• Системи за мобилност 

Доставя приложения, които са винаги включени – с или без връзка с мрежата.

 

• Системи за големи данни в реално време

Увеличава приходите, удовлетвореността на клиентите, както и оперативната ефективност чрез предоставяне на заключения от анализ на големите данни в реално време.