Наскоро имах възможност да интервюирам Орен Еини, главен изпълнителен директор и основател на Hibernating Rhinos, която предоставя RavenDB, документно ориентиран NoSQL с отворен код, създаден специално за платформата .NET/Windows.
Орен има повече от 20 години опит в света на разработката със силен фокус върху екосистемата на Microsoft и .NET. Признат за един от най-ценните професионалисти на Microsoft от 2007 г., Орен е и автор на „DSLs в Boo:Специфични за домейна езици в .NET“. Той често говори на индустриални конференции като DevTeach, JAOO, QCon, Oredev, NDC, Yow! и Progressive.NET.
Можете да прочетете цялото интервю по-долу:
1. В този дигитализиран свят данните се превърнаха в един от най-ценните активи. и следователно начинът, по който данните се съхраняват, организират и обработват, е от решаващо значение за успеха на бизнеса. Тъй като компаниите са бомбардирани с все повече и повече данни, съхранението на данни и анализите стават все по-сложни. Можете ли да ни кажете някои от често срещаните предизвикателства при управлението на бази данни, пред които са изправени бизнесите днес?
Основният проблем, според мен, е просто размерът на данните. Не говоря непременно за големите данни и сложността на управлението на набор от данни, измерен в стотици терабайти. Говоря за броя на базите данни и силозите за данни, които имате в една организация. Тъй като всичко е цифрово, имате критична за бизнеса функционалност, която се намира в електронна таблица на Excel на споделен диск и исторически данни за покупки на клиенти в сървър, до който никой не иска да се доближи от страх да не приеме собствеността върху него.
Само да разберем това, което организацията като цяло знае, може да бъде сложна задача. Пропускането на данни през пукнатините е за съжаление често срещано явление.
Опитите за създаване на централизирано хранилище за цялата компания също са обречени на провал. Различните части от компанията имат много различни идеи за това, което изглежда очевидно, че са нещата. Например отделът за фактуриране има много различна представа за това какво е клиент от отдела за маркетинг. Опитът да приведе данните в общ шаблон прави лоша услуга на всички.
2. Как да преодолеем тези предизвикателства? Смятате ли, че изборът на ефективно решение за управление на база данни е първата стъпка? И защо?
Първата стъпка е да се дефинират на организационно ниво правила за собственост и отговорност. На най-основното ниво, Billing притежава концепцията за това, което клиентът е в състояние на просрочено плащане, а маркетингът притежава интересите на клиента. Идеята не е да се създават силози от информация в организацията, а да има изрично признание за различните нужди. След като това стане, можете да дефинирате правилния поток от данни в организацията.
Отделът за фактуриране ще направи възгледа си за Клиента достъпен за останалата част от организацията, като същевременно запази свободата да променя начина, по който е оформен вътре в отдела.
Използвам отделите за фактуриране и маркетинг и понятието клиент като този пример, за да мога да говоря първо за бизнеса, което е важно. За да го преместим към малко по-технически начин, говорим за услуги и договори за поток от данни. Ще ви насоча към мандата на Безос и как той трансформира Amazon. Идеята е проста:вместо да третирате цялата организация като едно цяло, което е почти невъзможно след определен размер, третирайте я като куп сътрудничещи организации, които имат много ясни граници между тях.
След като имате тези граници и имате добра представа за потока от данни в организацията, можете да накарате вашите водопроводчици да дойдат и да направят нещо с нея, като пренасочване на потока от данни към централно място за анализ.
Наличието на такива публикувани интерфейси помага много когато дойде време да промените начина, по който се държат някои неща. Докато външното поведение е същото, ние сме свободни да променяме начина, по който го обработваме.
3. През последните години предприятията приеха различни типове бази данни NoSQL. С все по-чувствителните данни, които се съхраняват в NoSQL бази данни, проблемите със сигурността стават все по-големи притеснения. Какво мислите за това?
Като цяло най-честата причина за липса на сигурност в NoSQL бази данни е небрежността на оператора. Тук искам ясно да разделя два отделни въпроса. Имаме NoSQL бази данни като Redis, чийто модел на сигурност е изрично за работа в надеждна среда. Има някои елементарни функции за сигурност за Redis, но общото предположение е, че те са предназначени да служат само като трета или четвърта линия на защита.
Други бази данни NoSQL, като MongoDB, се очаква да работят във враждебни мрежи (т.е. Интернет). Въпреки това е лесно да настроите MongoDB без никаква сигурност. На пръв поглед MongoDB се предлага в защитена конфигурация, което му позволява да слуша само локалната машина.
Първото нещо, което ще откриете, когато се опитвате да се свържете отдалечено с MongoDB, е ръководство, което обяснява как да активирате отдалечен достъп до MongoDB, без каквато и да е сигурност.
До известна степен това е небрежност на оператора. Но като се има предвид огромния брой бази данни на MongoDB, които са оставени широко отворени, вярвам, че това е разделяне на косми. В Китай отворена база данни на MongoDB имаше над 200 милиона автобиографии, само чакащи някой да шушне; една небрежно настроена база данни разкри задните врати на Русия в над 2000 компании.
Със сигурност нямате втори шанс.
RavenDB, за разлика от тях, просто ще откаже да работи в уязвима конфигурация. Можете да стартирате RavenDB без сигурност на локалната машина, но ако се опитате да изложите базата данни в Интернет без подходящи предпазни мерки, базата данни ще върне грешка, обясняваща как трябва да я настроите правилно.
Попълваме максималния брой пропуски, като приемаме, че повечето хора ще свършат минималния обем работа и се уверяваме, че когато това се случи, крайното състояние е добро, така че сме ви покрили.
4. Говорейки за RavenDB, можете ли да посочите някои от най-важните функции, които добавят повече стойност към клиентите? С какво RavenDB се откроява сред другите доставчици по отношение на функции и производителност?
RavenDB работи в производствени системи повече от десетилетие. Някои от най-мощните функции, които датираме от нашата оригинална версия. Способността да се реагира динамично на оперативната среда е най-очевидната. RavenDB непрекъснато анализира какво се случва (входящи заявки, натоварване на сървъра и т.н.) и реагира на това, като променя разпределението на ресурсите, вътрешните структури и т.н. Идеята е, че вместо да има DBA на пълен работен ден, който гледа вашата база данни, вашата база данни може да управлява свои собствени дела.
Когато започнахме да работим върху RavenDB, искахме база данни, която да има всички предимства на релационна база данни (бърза, ACID, надеждна), но нито един от недостатъците (твърда схема, текуща поддръжка, висока сложност).
Когато започнахме, нямах представа колко голяма задача е това. През последните 10 години натрупахме много опит в изграждането на база данни, която може просто да работи, без да се налага да й обръщате много внимание. Ние проектирахме RavenDB, за да ни улесни при внедряването на неща с фокус върху производителността. Скорошен бенчмарк на Raspberry Pi (25$, 1 GHz, 1 GB RAM) машина ни показа над 5000 записа в секунда. При стандартния хардуер можем да достигнем до над 100 000 записа в секунда и над 1 000 000 четения в секунда.
Всичко това е на един възел, но RavenDB е разпределена база данни от самото начало. Това означава, че можете да настроите клъстер за няколко минути (и да го направите по сигурен начин, разбира се) и да имате високодостъпна и стабилна система.
Предлагаме някои уникални функции, които не са налични другаде. ETL е вграден в RavenDB и се използва силно от нашите клиенти, за да даде възможност за богат поток от данни. Не е нужно да зашивате решение от различни парчета, всичко е наред в кутията и просто работи.
Функцията за абонамент е тази, с която се гордея особено. Позволява ви да изпълнявате текуща заявка. Базата данни първоначално ще ви даде всички резултати, които отговарят на вашата заявка. Тъй като все още сте абонирани за тази заявка, вашата база данни ще изпраща всички нови документи, които съответстват на вашата заявка, когато бъдат въведени или актуализирани, за да отговарят на тази заявка. Това ви позволява да изграждате стабилни бизнес процеси и бекенд системи с лекота.
Съсредоточихме много усилия, за да превърнем RavenDB в мултимоделна база данни, способна да обработва документи, ключ-стойност, двоични данни, разпределени броячи и заявки за графики.
5. И накрая, какво е бъдещето на системите за управление на бази данни? Как ще се промени през следващите 3-4 години?
Ще видите много повече фокус върху многомоделните бази данни. Вместо да се налага да разгръщате специално решение за всеки тип данни, които искате, и да се занимавате със сложната интеграция между всяка от частите, пазарът преминава към интегрирано решение, което може да предложи пълен набор от опции в една кутия.
Облакът ще продължи да бъде по-важен, но няма да бързам да се сбогувам с локалните и разпределените системи. Виждаме, че много от нашите клиенти извършват обработка на ръба и от време на време свързани системи. Мисля, че ще видите изместване на фокуса, при което центровете за данни от миналото ще се преместят в облака, но голяма част от действителната обработка ще бъде разпределена на ръба и на мобилни устройства. Това изисква различен начин на мислене за разпределението на данни и как да се изпращат данни в облака и да се изтеглят данни от облака.
Ще се набляга много повече върху вида на разпределената обработка на данни, който някога е бил изключителната гама на системите от висок клас.
Със сигурност ще бъде много интересно да видим как се променя пейзажът и как изграждаме инструментите и методологиите за справяне с непрекъснато нарастваща сложност и функционалност.
