Niedawno miałem okazję przeprowadzić wywiad z Orenem Eini, dyrektorem generalnym i założycielem firmy Hibernating Rhinos, która dostarcza RavenDB, zorientowany na dokumenty NoSQL typu open source, zaprojektowany specjalnie dla platformy .NET/Windows.
Oren ma ponad 20-letnie doświadczenie w świecie deweloperskim, z silnym naciskiem na ekosystem Microsoft i .NET. Uznawany za jednego z najbardziej wartościowych specjalistów Microsoftu od 2007 roku, Oren jest także autorem „DSLs in Boo:Domain Specific Languages in .NET”. Często występuje na konferencjach branżowych, takich jak DevTeach, JAOO, QCon, Oredev, NDC, Yow! i Progressive.NET.
Możesz przeczytać cały wywiad poniżej:
1. W tym zdigitalizowanym świecie dane stały się jednym z najcenniejszych zasobów. dlatego sposób przechowywania, organizowania i przetwarzania danych ma kluczowe znaczenie dla sukcesu firmy. Ponieważ firmy są bombardowane coraz większą ilością danych, przechowywanie danych i ich analiza stają się coraz bardziej złożone. Czy możesz nam opowiedzieć o niektórych typowych wyzwaniach związanych z zarządzaniem bazami danych, przed którymi stoją dziś firmy?
Myślę, że głównym problemem jest sam rozmiar danych. Niekoniecznie mówię o Big Data i złożoności zarządzania zbiorem danych mierzonym w setkach terabajtów. Mówię o liczbie baz danych i silosów danych, które masz w organizacji. Ponieważ wszystko jest cyfrowe, masz do dyspozycji funkcje o znaczeniu krytycznym dla firmy, które znajdują się w arkuszu kalkulacyjnym programu Excel na dysku współdzielonym, oraz historyczne dane zakupów klientów na serwerze, do którego nikt nie chce się zbliżać z obawy przed zaakceptowaniem własności.
Samo ustalenie, co wie organizacja jako całość, może być złożonym zadaniem. Dane przemykające przez szczeliny są niestety powszechne.
Próby stworzenia scentralizowanego repozytorium dla całej firmy również skazane są na niepowodzenie. Różne części firmy mają bardzo różne poglądy na to, co wydaje się oczywiste. Na przykład dział rozliczeń ma zupełnie inne pojęcie o tym, kim jest klient, niż dział marketingu. Próba dopasowania danych do typowej formy wyrządza wszystkim krzywdę.
2. Jak radzimy sobie z pokonywaniem tych wyzwań? Czy uważasz, że wybór skutecznego rozwiązania do zarządzania bazami danych to pierwszy krok? I dlaczego?
Pierwszym krokiem jest zdefiniowanie na poziomie organizacyjnym własności danych i reguł odpowiedzialności. Na najbardziej podstawowym poziomie Billing jest właścicielem koncepcji tego, co Klient jest w statusie Zaległa płatność, a Marketing jest właścicielem Interesów Klienta. Ideą nie jest tworzenie silosów informacji w organizacji, ale wyraźne uwzględnienie różnych potrzeb. Gdy to zrobisz, możesz zdefiniować właściwy przepływ danych w organizacji.
Dział rozliczeń udostępni swój pogląd na temat klienta reszcie organizacji, zachowując jednocześnie swobodę zmiany jego kształtu w dziale.
Posługuję się działem Billingu i Marketingu oraz pojęciem Klient jako tym przykładem, aby móc najpierw porozmawiać o biznesie, co jest ważne. Aby przenieść to w nieco bardziej techniczny sposób, mówimy o umowach dotyczących usług i przepływu danych. Odniosę się do mandatu Bezosa i tego, jak przekształcił Amazon. Pomysł jest prosty:zamiast traktować całą organizację jako jedną całość, co jest prawie niemożliwe powyżej pewnego rozmiaru, traktuj ją jako grupę współpracujących organizacji, które mają bardzo wyraźne granice między nimi.
Kiedy już ustalisz te granice i będziesz mieć dobry pomysł na przepływ danych w organizacji, możesz poprosić swoich hydraulików i zrobić z nimi takie rzeczy, jak przekierowanie przepływu danych do centralnej lokalizacji w celu analizy.
Posiadanie takich opublikowanych interfejsów bardzo pomaga, gdy przychodzi czas na zmianę zachowania niektórych rzeczy. Dopóki zachowanie zewnętrzne jest takie samo, możemy zmienić sposób, w jaki je przetwarzamy.
3. W ostatnich latach przedsiębiorstwa przyjęły różne typy baz danych NoSQL. Ponieważ w bazach danych NoSQL przechowywane są coraz bardziej wrażliwe dane, kwestie bezpieczeństwa stają się coraz większym problemem. Jakie jest Twoje zdanie na ten temat?
Ogólnie rzecz biorąc, najczęstszą przyczyną braku bezpieczeństwa w bazach danych NoSQL jest zaniedbanie operatora. Chcę tutaj wyraźnie oddzielić dwie odrębne kwestie. Mamy bazy danych NoSQL, takie jak Redis, których model bezpieczeństwa wyraźnie dotyczy pracy w zaufanym środowisku. Istnieje kilka podstawowych funkcji bezpieczeństwa dla Redis, ale ogólne założenie jest takie, że mają one służyć tylko jako trzecia lub czwarta linia obrony.
Oczekuje się, że inne bazy danych NoSQL, takie jak MongoDB, będą działać w wrogich sieciach (tj. Internecie). Jednak łatwo jest skonfigurować MongoDB bez żadnych zabezpieczeń. Na pierwszy rzut oka MongoDB ma bezpieczną konfigurację, dzięki czemu może słuchać tylko lokalnego komputera.
Pierwszą rzeczą, jaką znajdziesz, próbując połączyć się zdalnie z MongoDB, jest przewodnik wyjaśniający, jak włączyć zdalny dostęp do MongoDB bez żadnych zabezpieczeń.
W pewnym stopniu jest to zaniedbanie operatora. Ale biorąc pod uwagę samą liczbę baz danych MongoDB, które pozostają szeroko otwarte, uważam, że jest to podział włosów. W Chinach otwarta baza danych MongoDB zawierała ponad 200 milionów CV, które tylko czekały, aż ktoś je przeszuka; nieostrożnie skonfigurowana baza danych ujawniła rosyjskie tylne drzwi ponad 2000 firm.
Dzięki bezpieczeństwu nie dostaniesz drugiej szansy.
W przeciwieństwie do tego RavenDB po prostu odmówi uruchomienia w podatnej konfiguracji. Możesz uruchomić RavenDB bez zabezpieczeń na komputerze lokalnym, ale jeśli spróbujesz udostępnić bazę danych w Internecie bez odpowiednich zabezpieczeń, baza danych zwróci błąd wyjaśniający, jak prawidłowo ją skonfigurować.
Wypełniamy maksymalną liczbę luk, zakładając, że większość ludzi wykona minimalną wymaganą ilość pracy i upewniamy się, że gdy tak się stanie, stan końcowy jest dobry, więc mamy dla Ciebie ochronę.
4. Mówiąc o RavenDB, czy możesz wymienić niektóre z najważniejszych funkcji, które dodają klientom więcej wartości? W jaki sposób RavenDB wyróżnia się spośród innych dostawców pod względem funkcji i wydajności?
RavenDB działa w systemach produkcyjnych od ponad dekady. Niektóre z najpotężniejszych funkcji, z których korzystaliśmy, pochodzą z naszej oryginalnej wersji. Najbardziej oczywista jest umiejętność dynamicznego reagowania na środowisko operacyjne. RavenDB stale analizuje, co się dzieje (przychodzące zapytania, obciążenie serwera, itp.) i reaguje na to, zmieniając alokację zasobów, struktury wewnętrzne itp. Chodzi o to, aby zamiast mieć pełnoetatową opiekę DBA nad Twoją bazą danych, Twoja baza danych może zarządzać własne sprawy.
Kiedy zaczynaliśmy pracę nad RavenDB, chcieliśmy bazy danych, która ma wszystkie zalety relacyjnej bazy danych (szybka, ACID, niezawodna), ale nie ma żadnych wad (sztywny schemat, ciągła konserwacja, duża złożoność).
Kiedy zaczynaliśmy, nie miałem pojęcia, jak wielkie to zadanie. W ciągu ostatnich 10 lat zdobyliśmy duże doświadczenie w budowaniu bazy danych, która może po prostu działać, bez konieczności zwracania na nią większej uwagi. Zaprojektowaliśmy RavenDB, aby ułatwić nam wdrażanie rzeczy z naciskiem na wydajność. Niedawny test porównawczy na maszynie Raspberry Pi (25 $, 1 GHz, 1 GB RAM) dał nam ponad 5000 zapisów na sekundę. Na standardowym sprzęcie możemy uzyskać ponad 100 000 zapisów na sekundę i ponad 1 000 000 odczytów na sekundę.
Wszystko to w jednym węźle, ale RavenDB od samego początku jest rozproszoną bazą danych. Oznacza to, że możesz skonfigurować klaster w kilka minut (i oczywiście zrobić to w bezpieczny sposób) i mieć wysoce dostępny i niezawodny system.
Oferujemy kilka unikalnych funkcji, które nie są dostępne nigdzie indziej. ETL jest wbudowany w RavenDB i jest intensywnie wykorzystywany przez naszych klientów, aby umożliwić bogaty przepływ danych. Nie musisz łączyć rozwiązania z różnych części, wszystko jest w pudełku i po prostu działa.
Funkcja subskrypcji jest tą, z której jestem szczególnie dumny. Pozwala na wykonanie bieżącego zapytania. Baza danych początkowo poda wszystkie wyniki pasujące do zapytania. Ponieważ nadal subskrybujesz to zapytanie, Twoja baza danych będzie przesyłać wszystkie nowe dokumenty pasujące do zapytania w miarę ich wprowadzania lub aktualizowania w celu dopasowania do tego zapytania. Pozwala to z łatwością budować niezawodne procesy biznesowe i systemy zaplecza.
Skupiliśmy wiele wysiłku na przekształceniu RavenDB w wielomodelową bazę danych zdolną do obsługi dokumentów, wartości klucz-wartość, danych binarnych, rozproszonych liczników i zapytań do wykresów.
5. I wreszcie, jaka jest przyszłość systemów zarządzania bazami danych? Jak to się zmieni w ciągu najbliższych 3-4 lat?
Zobaczysz, że znacznie bardziej skupisz się na wielomodelowych bazach danych. Zamiast wdrażać dedykowane rozwiązanie dla każdego rodzaju danych, które chcesz, i zajmować się złożoną integracją między każdym z elementów, rynek przechodzi na zintegrowane rozwiązanie, które może zaoferować pełny zestaw opcji w jednym pudełku.
Chmura nadal będzie ważniejsza, ale nie spieszyłbym się z pożegnaniem z systemami lokalnymi i rozproszonymi. Widzimy, jak wielu naszych klientów przetwarza dane na urządzeniach brzegowych i w okazjonalnie podłączonych systemach. Myślę, że zobaczysz przesunięcie uwagi, w którym centra danych z przeszłości przeniosłyby się do chmury, ale większość rzeczywistego przetwarzania byłaby rozproszona na brzegach i na urządzeniach mobilnych. To wymaga innego sposobu myślenia o dystrybucji danych oraz o tym, jak przesyłać dane do chmury i pobierać dane z chmury.
Będzie dużo większy nacisk na rodzaj rozproszonego przetwarzania danych, które kiedyś było wyłączną gamą systemów wysokiej klasy.
Z pewnością będzie bardzo interesujące zobaczyć, jak zmienia się krajobraz i jak budujemy narzędzia i metodologie, aby radzić sobie ze stale rosnącą złożonością i funkcjonalnością.
