Jak wybrać magazyn danych dla następnej nowej błyszczącej rzeczy?

Opublikowany: 2018-01-26

Uwaga: jest to techniczny post na blogu napisany przez głównego inżyniera Silvię Botros i po raz pierwszy pojawił się na blogu Sysadvent 25 grudnia 2017 r.

Bazy danych mogą być trudne. Wiesz, co jest trudniejsze? Wybór jednego w pierwszej kolejności. Jest to trudne, niezależnie od tego, czy pracujesz w nowej firmie, która wciąż znajduje odpowiedni produkt/rynek, czy w firmie, która znalazła swoich odbiorców i po prostu rozszerza ofertę produktów.

Podczas tworzenia nowej rzeczy, jedną z pierwszych części tego procesu projektowania jest to, jakich magazynów danych powinniśmy użyć i czy powinna to być liczba pojedyncza czy mnoga? Czy powinniśmy korzystać ze sklepów relacyjnych, czy też musimy wybrać sklep z kluczową wartością? A co z opcjami czasowymi? Czy powinniśmy również dodać jakąś rozproszoną powtórkę dziennika?

Więc. Wiele. Opcje…

W tym artykule postaram się opisać proces, który, miejmy nadzieję, ukierunkuje tę decyzję i, w stosownych przypadkach, wyjaśni, w jaki sposób wielkość i dojrzałość Twojej organizacji może wpłynąć na tę decyzję.

Podstawowe wymagania

Dane są siłą napędową każdego produktu. Nawet jeśli planujemy używać bardziej zaawansowanej technologii do przechowywania stanu aplikacji (ponieważ MySQL lub Postgres nie są już „fajne”), cokolwiek wybierzemy, nadal jest magazynem danych, a zatem wymaga, abyśmy stosowali rygorystyczne, gdy dokonując naszego wyboru.

Ważną rzeczą do zapamiętania jest to, że nic nie jest za darmo. Wszystkie magazyny danych wiążą się z kompromisami i jeśli nie mówisz jasno, jakie kompromisy podejmujesz jako ryzyko biznesowe, podejmiesz nieznane ryzyko, które ujawni się w najgorszym możliwym momencie.

Twój menedżer produktu prawdopodobnie nie będzie wiedział, a nawet nie będzie musiał dbać o to, czego używasz w swoim magazynie danych, ale będzie napędzał potrzeby, które zmniejszą listę opcji. Czasami nawet to wymaga wsparcia ze strony zespołu programistów. Oto lista rzeczy, o które należy poprosić zespół ds. produktu, aby uzyskać pomoc w wyborze opcji:

  • Tempo wzrostu: Jak mają się zmieniać same dane lub dostęp do nich w czasie?
  • W jaki sposób zespół rozliczeniowy wykorzysta te nowe dane?
  • W jaki sposób zespół ETL wykorzysta te dane?
  • Jakie wymagania dotyczące dokładności/spójności są oczekiwane dla tej nowej funkcji?
  • Jaki przedział czasowy dla tej konsystencji jest akceptowalny? Czy korekta przetwarzania końcowego jest akceptowalna?

Znajdź kontekst, który nie został powiedziany

Wybór magazynu danych nie jest wyborem zarezerwowanym dla DBA lub zespołu operacyjnego, ani nawet dla inżyniera piszącego kod.

Dojrzałe organizacje ze znanym rynkiem adresowalnym muszą podjąć decyzję od interesariuszy z całej organizacji.

Jeśli wymagania zespołu ds. produktu pasują do kilkunastu magazynów danych, jak określić wymagania, które nie zostały wyraźnie wymienione?

Musisz jak najszybciej ujawnić niewypowiedziane wymagania, ponieważ jest to droga do niespełnionych oczekiwań.

Wiele ukrytych rzeczy może sprawić, że poniesiesz porażkę w pułapce „zbyt wielu wyborów”. Obejmuje to między innymi:

  • Niekompletne listy funkcji
  • Wymagania dotyczące wydajności, które nie są wyraźnie wymienione
  • Zakładane potrzeby w zakresie spójności
  • Tempo wzrostu, które nie jest określone
  • Potrzeby dotyczące rozliczeń lub zapytań ETL, które nie są jeszcze dostępne/znane

Są to wszystkie możliwe sposoby, które mogą sprawić, że zespół inżynierów zbyt długo kręci się w kółko, sprawdzając długą listę wyborów dotyczących przechowywania danych, ponieważ jasne kryteria, z którymi pracuje, są zbyt liberalne lub niekompletne.

W przypadku produktów „greenfield”, jak wspomniałem wcześniej, Twoim celem jest elastyczność. Tak więc magazyn danych o bardziej ogólnym przeznaczeniu i znanej jakości pomoże ci zbliżyć się do rezultatu, mając świadomość, że może być konieczne przejście do magazynu danych, który jest bardziej podatny na nową skalę.

Zrób swoją listę

Czas przefiltrować potencjalne rozwiązania według listy wymagań. Wynikowa lista musi zawierać nie więcej niż garść możliwych magazynów danych. Jeśli lista potencjalnych baz danych, z których możesz skorzystać, jest większa, oznacza to, że Twoje wymagania są zbyt liberalne i musisz wrócić i dowiedzieć się więcej.

Dla młodszych, mniej dojrzałych firm wymagania dotyczące przechowywania danych to obszar największej niewiadomej. Prawdopodobnie budujesz nową rzecz, której nikt jeszcze nie oferuje, więc rzeczy takie jak całkowita wielkość rynku i tempo wzrostu mogą być stosunkowo nieznane i trudne do oszacowania.

W tym przypadku potrzebujesz nie ograniczać się zbyt wcześnie w życiu nowej firmy, używając jednego magazynu danych kucyka. Tak, w pewnym momencie Twoje dane będą rosły w nowy i nieoczekiwany sposób, ale teraz potrzebujesz elastyczności, aby znaleźć swoją niszę rynkową i dowiedzieć się, jak będzie wyglądać wzrost Twoich danych i jakie konkretne funkcje skalowalności staną się kluczowe dla Twój wzrost.

Jeśli jesteś większą firmą z rosnącą liczbą płacących klientów, Twoim zadaniem jest zmniejszenie listy opcji, najlepiej do magazynów danych, które już posiadasz i utrzymujesz. Kiedy masz już wielu płacących klientów, ryzyko dodania nowych magazynów danych, z którymi Twój zespół nie jest zaznajomiony, staje się większe i, w zależności od kontekstu danych, po prostu nie do zaakceptowania.

Inną rzeczą, o której należy pamiętać, jest to, jakie narzędzia już istnieją dla magazynów danych i co oznaczałoby przyjęcie nowego, jeśli chodzi o pracę z góry, którą musi wykonać Twój zespół. Zarządzanie konfiguracją, skrypty tworzenia kopii zapasowych, skrypty odzyskiwania danych, nowe kontrole monitorowania, nowe pulpity nawigacyjne do tworzenia i poznawania. Lista kosztów operacyjnych nowego magazynu danych, niezależnie od ryzyka, nie jest trywialna.

Wybierz swoją truciznę

Oto źle strzeżony sekret, którego trzymają się administratorzy baz danych. Bazy danych są w czymś okropne. Istnieje nawet całe twierdzenie na ten temat. Nie tylko bazy danych w tradycyjnym sensie, ale każda technologia, która przechowuje stan, będzie okropna w sposób unikalny dla tego, jak z niej korzystasz.

To tylko fakt z życia, który lepiej teraz przyswoisz sobie. Nie, nie mówię, że powinieneś unikać używania którejkolwiek z tych technologii, mówię, że zachowaj swoje oczekiwania przy zdrowych zmysłach i wiedz, że TY i tylko Ty i Twój zespół ostatecznie jesteście w stanie spełnić złożone obietnice.

Co to oznacza w kategoriach nieabstrakcyjnych? Gdy już masz solidny pomysł, jakie magazyny danych będą częścią tego, co tworzysz, powinieneś zacząć od poznania słabości tych magazynów danych. Te słabości obejmują między innymi:

  • Czy ten magazyn danych działa dobrze w przypadku zapytań dotyczących skanowania?
  • Czy ten magazyn danych opiera się na protokole plotkarskim do replikacji danych? jeśli tak, jak radzi sobie z partycjami sieciowymi? Ile danych jest związanych z tą plotką?
  • Czy ten magazyn danych ma pojedynczy punkt awarii?
  • Jak dojrzali są kierowcy w społeczności, aby z nimi rozmawiać, czy też musisz rzucić swoją własną?
  • Ta lista może być ogromna

Przemyślenie słabości potencjalnych rozwiązań, które wciąż znajdują się na Twojej liście, powinno usunąć z niej więcej opcji. To jest teraz rzeczywistość spełniająca wzniosłe obietnice technologii.

Arkusz kalkulacyjny i odpiecz!

Gdy lista wyborów jest już niewielka, nadszedł czas, aby umieścić je wszystkie w arkuszu kalkulacyjnym i zacząć kopać nieco głębiej. Potrzebujesz kolumny „za” i „przeciw”, a na tym etapie będziesz musiał poświęcić trochę czasu na dokumentację każdej bazy danych, aby dowiedzieć się, jak wykonać określone zadania.

Jeśli spodziewasz się, że te dane będą miały duże tempo wzrostu, musisz wiedzieć, która z tych opcji jest łatwiejsza do skalowania. Jeśli jest to funkcja, która wykonuje dużo wyszukiwania rozmytego, musisz wiedzieć, który magazyn danych może lepiej obsługiwać skanowanie lub przeszukiwanie dużej liczby wierszy iz jakim projektem. Celem na tym etapie jest skrócenie listy do najlepiej 2 lub 3 opcji za pomocą samej dokumentacji, ponieważ jeśli ta nowa funkcja jest wystarczająco krytyczna dla sukcesu firmy, będziesz musiał porównać wszystkie trzy.

Dlaczego mówisz benchmark? Ponieważ żadna 2 firmy nie korzysta z tego samego magazynu danych w ten sam sposób. Ponieważ czasami dokumentacja zawiera zastrzeżenia, które ujawniają się tylko w opowieściach wojennych innych ludzi.

Ponieważ nikt oprócz Ciebie nie jest właścicielem stabilności, niezawodności i przewidywalności tego magazynu danych.

Zaprojektuj swój punkt odniesienia z wyprzedzeniem. Najlepiej byłoby skonfigurować pełną instancję magazynów danych na liście ze specyfikacjami na poziomie produkcyjnym i wygenerować dane testowe, które nie są zbyt małe, aby testowanie obciążenia było bezużyteczne. Upewnij się, że nie tylko porównałeś „normalne obciążenie”, ale także przetestowałeś niektóre scenariusze awarii.

Mamy nadzieję, że dzięki testowi porównawczemu można znaleźć wszelkie zastrzeżenia, które są na tyle poważne, że skłonią Cię do ponownego odwiedzenia listy opcji teraz, a nie później, gdy cały kod zostanie napisany i jesteś teraz w fazie ćwiczenia ogniowego z dużą ilością czasu i wysiłek włożony w wybór, którego dokonałeś.

Udokumentuj swój wybór

Bez względu na to, co robisz, musisz udokumentować i rozpowszechnić wewnętrznie metodę, za pomocą której dokonałeś wyboru, oraz alternatywy, które zostały zbadane na drodze do tej decyzji. Zakładając, że istnieje nadrzędny plan architektury dotyczący tego, jak ta nowa funkcja zostanie utworzona i wszystkie jej komponenty, upewnij się, że utworzyłeś sekcję poświęconą magazynowi danych napędzającemu tę nową funkcję z linkami do wszystkich testów porównawczych wykonanych w celu podjęcia decyzji, do której przyszedł zespół .

Jest to nie tylko z korzyścią dla przyszłych nowych pracowników, ale także z korzyścią dla Twojego zespołu. Dokument, który ludzie mogą asynchronicznie czytać i opracowywać, zapewnia sposób na zachowanie przejrzystości procesu decyzyjnego, rozwijanie poczucia najlepszych intencji wśród członków zespołu i może wnieść krytykę z perspektywy, której nie przewidziałeś.

Na wynos

Kroki te nie tylko doprowadzą do podejmowania decyzji opartych na danych podczas rozwijania oferty biznesowej, ale także doprowadzą do solidnej infrastruktury i bardziej zdyscyplinowanego podejścia do tego, kiedy i gdzie korzystasz z coraz większej dziedziny technologii, aby zapewnić wartość swoim płacącym klienci.