Cześć, Hubrowicze. Zgodnie z tradycją, kontynuujemy dzielenie się ciekawymi materiałami w przeddzień rozpoczęcia nowych kursów. Dzisiaj specjalnie dla was przetłumaczyliśmy artykuł o Google Cloud Spanner, dostosowując go do uruchomienia kursu .
Pierwotnie opublikowano w .
Jako firma, która oferuje wiele chmurowych rozwiązań POS dla detalistów, restauratorów i sprzedawców internetowych na całym świecie, Lightspeed korzysta z kilku różnych typów platform baz danych do wielu transakcyjnych, analitycznych i wyszukiwawczych przypadków użycia. Każda z tych platform baz danych ma swoje mocne i słabe strony. Dlatego, kiedy Google wprowadził na rynek Cloud Spanner — obiecujące funkcje, niespotykane w świecie relacyjnych baz danych, takie jak praktycznie nieograniczona horyzontalna skalowalność i 99,999% umowa o poziomie usług (SLA) — nie mogliśmy przegapić okazji, aby zdobyć ją w nasze ręce!
Aby dać wyczerpujący przegląd naszego doświadczenia z Cloud Spanner, a także kryteriów oceny, które wykorzystaliśmy, omówimy następujące tematy:
- Nasze kryteria oceny
- Cloud Spanner w dwóch słowach
- Nasza ocena
- Nasze wnioski
1. Nasze kryteria oceny
Zanim przejdziemy do szczegółowych funkcji Cloud Spanner, jej podobieństw i różnic w stosunku do innych rozwiązań na rynku, porozmawiajmy najpierw o podstawowych przypadkach użycia, które mieliśmy na myśli, rozważając kwestię, gdzie wdrożyć Cloud Spanner w naszej infrastrukturze:
- Jako alternatywa (przewaga) tradycyjnego rozwiązania dla baz danych SQL
- Jako rozwiązanie OLTP z obsługą OLAP
Uwaga: Dla uproszczenia i wygody porównania ten artykuł porównuje Cloud Spanner z opcjami MySQL rodzin rozwiązań GCP Cloud SQL i Amazon AWS RDS.
Wykorzystanie Cloud Spanner jako alternatywy dla tradycyjnego rozwiązania dla baz danych SQL
W środowisku tradycyjnych baz danych, kiedy czas reakcji na zapytanie do bazy danych zbliża się lub nawet przekracza wcześniej określone wartości progowe aplikacji (głównie z powodu wzrostu liczby użytkowników i/lub zapytań), istnieje kilka sposobów na obniżenie czasu reakcji do akceptowalnych poziomów. Jednak większość z tych rozwiązań wymaga ręcznej interwencji.
Na przykład, pierwszym krokiem, który należy podjąć, jest przyjrzenie się różnym parametrom bazy danych związanym z wydajnością i ich dostosowanie, aby najlepiej odpowiadały wzorcom scenariuszy użytkowania aplikacji. Jeśli to okaże się niewystarczające, można wybrać skalowanie bazy danych w pionie lub w poziomie.
Skalowanie pionowe aplikacji polega na aktualizacji instancji serwera, zazwyczaj poprzez dodanie większej liczby procesorów/rdzeni, większej ilości pamięci RAM, szybszej pamięci masowej itp. Dodanie większej ilości zasobów sprzętowych prowadzi do zwiększenia wydajności bazy danych, mierzonej głównie w transakcjach na sekundę oraz opóźnieniu transakcji dla systemów OLTP. Systemy relacyjnych baz danych (które wykorzystują podejście wielowątkowe), takie jak MySQL, dobrze skalują się w pionie.
Podejście to ma kilka wad, ale najbardziej oczywistą jest maksymalny rozmiar serwera dostępnego na rynku. Gdy osiągnięty zostanie limit największej instancji serwera, pozostaje tylko jedno rozwiązanie: skalowanie poziome.
Skalowanie poziome to podejście, w którym do klastra dodawane są kolejne serwery, aby idealnie liniowo zwiększać wydajność wraz z dodawaniem liczby serwerów. Większość tradycyjnych systemów baz danych słabo skaluję się w poziomie lub w ogóle nie skalują. Na przykład MySQL może być skalowany poziomo dla operacji odczytu, dodając niewolników-odczytywaczy, ale nie może być skalowany poziomo dla operacji zapisu.
Z drugiej strony, dzięki swojej naturze, Cloud Spanner może łatwo skalować się w poziomie przy minimalnej ingerencji.
W pełni funkcjonalna Baza danych jako usługa powinna być oceniana z różnych perspektyw. Za punkt wyjścia wzięliśmy najbardziej popularną bazę danych w chmurze — dla Google, GCP Cloud SQL i dla Amazona, AWS RDS. W naszej ocenie skupiliśmy się na następujących kategoriach:
- Porównanie funkcji: zakres SQL, DDL, DML; biblioteki połączeń/konektory, wsparcie dla transakcji i tak dalej.
- Wsparcie dla rozwoju: łatwość w tworzeniu i testowaniu.
- Wsparcie administracyjne: zarządzanie instancjami — na przykład, skalowanie w górę/w dół i aktualizacja instancji; SLA, backup i odzyskiwanie; bezpieczeństwo/kontrola dostępu.
Użycie Cloud Spanner jako rozwiązania OLTP z wsparciem OLAP
Choć Google wyraźnie nie twierdzi, że Cloud Spanner jest przeznaczony do przetwarzania analitycznego, dzieli on niektóre atrybuty z innymi mechanizmami, takimi jak Apache Impala & Kudu i YugaByte, które są przeznaczone do obciążeń OLAP.
Nawet jeśli istniała tylko niewielka szansa, że Cloud Spanner zawierałby zgodny, poziomo skalowalny silnik HTAP (hybrydowego przetwarzania transakcyjnego/analitycznego) z (bardziej lub mniej) użytecznym zestawem funkcji OLAP, uważamy, że zasługiwałoby to na naszą uwagę.
Mając to na uwadze, rozważylismy następujące kategorie:
- Ładowanie danych, indeksy i wsparcie partycjonowania
- Wydajność zapytań i DML
2. Cloud Spanner w dwóch słowach
Google Spanner to klastrowy system zarządzania relacyjnymi bazami danych (RDBMS), który Google wykorzystuje do kilku swoich usług. Google udostępnił go publicznie użytkownikom Google Cloud Platform na początku 2017 roku.
Oto niektóre z atrybutów Cloud Spanner:
- Silnie zgodny, skalowalny klaster RDBMS: wykorzystuje sprzętową synchronizację czasu w celu zapewnienia spójności danych.
- Wsparcie transakcji między tabelami: transakcje mogą obejmować wiele tabel — nie muszą być ograniczone do jednej tabeli (w przeciwieństwie do Apache HBase czy Apache Kudu).
- Tabele oparte na kluczu głównym: wszystkie tabele muszą mieć zadeklarowany klucz główny (PK), który może składać się z wielu kolumn tabeli. Dane tabelaryczne przechowywane są w kolejności PK, co czyni je bardzo efektywnymi i szybkim w wyszukiwaniu po PK. Jak w innych systemach opartych na PK, wdrożenie musi być modelowane z uwzględnieniem wcześniej przemyślanych przypadków użycia dla osiągnięcia .
- Tabela naprzemienna: tabele mogą mieć fizyczne zależności od siebie nawzajem. Wiersze tabeli podrzędnej mogą być powiązane z wierszami tabeli nadrzędnej. Takie podejście przyspiesza wyszukiwanie relacji, które można zdefiniować na etapie modelowania danych, na przykład przy wspólnym rozmieszczeniu klientów i ich faktur.
- Indeksy: Cloud Spanner obsługuje indeksy wtórne. Indeks składa się z indeksowanych kolumn i wszystkich kolumn PK. Na życzenie indeks może również zawierać inne nieindeksowane kolumny. Indeks może być naprzemiennie z tabelą nadrzędną w celu przyspieszenia zapytań. W przypadku indeksów stosuje się kilka ograniczeń, na przykład maksymalną liczbę dodatkowych kolumn przechowywanych w indeksie. Zapytania poprzez indeksy mogą być również mniej bezpośrednie niż w innych RDBMS.
Cloud Spanner automatycznie wybiera indeks tylko w rzadkich przypadkach. W szczególności Cloud Spanner nie wybiera automatycznie indeksu wtórnego, jeśli zapytanie żąda jakichkolwiek kolumn, które nie są zapisane w ».
- Umowa o poziomie usług (SLA): wdrożenie w jednym regionie z SLA wynoszącym 99,99%; wdrożenia multiregionowe z SLA wynoszącym 99,999%. Chociaż sama umowa o poziomie usług jest tylko umową, a nie żadną gwarancją, uważam, że pracownicy Google rzeczywiście mają pewne dokładne dane, aby złożyć tak poważne stwierdzenie. (Dla porównania, 99,999% oznacza 26,3 sekundy niedostępności usługi w miesiącu.)
- Więcej:
Uwaga: Projekt Apache Tephra dodaje rozszerzone wsparcie dla transakcji w Apache HBase (teraz również wdrożony w Apache Phoenix jako wersja beta).
Nasza ocena
Wszyscy czytaliśmy stwierdzenia Google na temat zalet Cloud Spanner – praktycznie nieograniczone poziome skalowanie przy utrzymaniu wysokiej spójności i bardzo wysokiego SLA. Chociaż te wymagania są w każdym razie niezwykle trudne do osiągnięcia, naszym celem nie było ich obalenie. Zamiast tego skupmy się na innych rzeczach, które martwią większość użytkowników baz danych: prostota i użyteczność.
Oceniliśmy Cloud Spanner jako alternatywę dla Sharded MySQL
Google Cloud SQL i Amazon AWS RDS, dwie najbardziej popularne OLTP bazy danych na rynku chmurowym, oferują bardzo szeroki zestaw funkcji. Niemniej jednak, aby skalować te bazy danych poza rozmiar jednego węzła, konieczne jest dzielenie aplikacji. Takie podejście tworzy dodatkową złożoność zarówno dla aplikacji, jak i dla administracji. Sprawdziliśmy, jak Spanner wpisuje się w scenariusz łączenia kilku segmentów w jeden instans oraz z jakimi funkcjami (o ile takie istnieją) można się zmierzyć.
Wsparcie dla SQL, DML i DDL, a także konektor i biblioteki?
Po pierwsze, uruchamiając jakąkolwiek bazę danych, należy stworzyć model danych. Jeśli myślisz, że możesz podłączyć JDBC Spanner do swojego ulubionego narzędzia SQL, przekonasz się, że możesz za jego pomocą zapytywać swoje dane, ale nie możesz go używać do tworzenia tabel ani do modyfikacji (DDL) lub wszelkich operacji wstawiania/aktualizacji/usuwania (DML). Oficjalny JDBC od Google nie wspiera ani jednego, ani drugiego.
„Obecnie sterowniki nie wspierają operatorów DML ani DDL.”
Dokumentacja Spanner
Sytuacja z konsolą GCP nie jest lepsza — możesz wysyłać tylko zapytania SELECT. Na szczęście istnieje sterownik JDBC z wsparciem dla DML i DDL od społeczności, łącznie z transakcjami. . Chociaż ten sterownik jest niezwykle użyteczny, brak własnego sterownika JDBC od Google budzi zdziwienie. Na szczęście Google oferuje dość szerokie wsparcie dla bibliotek klienckich (opartych na gRPC): C#, Go, Java, node.js, PHP, Python i Ruby.
Praktycznie obowiązkowe korzystanie z interfejsów API Cloud Spanner (z powodu braku DDL i DML w JDBC) prowadzi do pewnych ograniczeń dla powiązanych obszarów kodu, takich jak pule połączeń czy ramy powiązań z bazą danych (np. Spring MVC). Z reguły przy użyciu JDBC można swobodnie wybierać ulubioną pulę połączeń (np. HikariCP, DBCP, C3PO itp.), która została przetestowana i działa dobrze. W przypadku interfejsów API Spanner musimy polegać na ramach/pulach powiązań/sesjach, które stworzyliśmy sami.
Struktura zorientowana na klucz główny (PK) pozwala Cloud Spanner na bardzo szybki dostęp do danych poprzez PK, ale także prowadzi do pewnych problemów z zapytaniami.
- Nie możesz zaktualizować wartości klucza głównego; najpierw musisz usunąć rekord z oryginalnym PK i ponownie go wstawić z nową wartością. (To przypomina inne bazy danych/składowania zorientowane na PK.)
- Wszystkie operatory UPDATE i DELETE muszą wskazywać PK w WHERE, w związku z tym nie mogą istnieć puste operatory DELETE all – zawsze musi być podzapytanie, na przykład: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Brak opcji autoinkrementacji lub czegoś podobnego, co określałoby sekwencję dla pola PK. Aby to działało, odpowiednia wartość musi być tworzona po stronie aplikacji.
Indeksy wtórne?
Google Cloud Spanner ma wbudowaną obsługę indeksów wtórnych. To bardzo przyjemna cecha, która nie zawsze występuje w innych technologiach. Apache Kudu obecnie w ogóle nie obsługuje indeksów wtórnych, a Apache HBase nie obsługuje indeksów bezpośrednio, ale może je dodawać przez Apache Phoenix.
Indeksy w Kudu i HBase można modelować jako osobną tabelę z innymi kombinacjami kluczy głównych, ale atomowość operacji wykonanych na tabeli głównej i powiązanych tabelach indeksów musi być realizowana na poziomie aplikacji i nie jest trywialna w prawidłowej implementacji.
Jak wspomniano w przeglądzie Cloud Spanner, jego indeksy mogą różnić się od indeksów MySQL. Należy zatem zachować szczególną ostrożność przy budowaniu zapytań i profilowaniu, aby zapewnić użycie właściwego indeksu tam, gdzie jest on potrzebny.
Widoki?
Bardzo popularnym i użytecznym obiektem w bazie danych są widoki. Mogą być przydatne w wielu przypadkach użycia; dwa moje ulubione to poziom logicznej abstrakcji i poziom bezpieczeństwa. Niestety, Cloud Spanner NIE obsługuje widoków. Jednak to ogranicza nas tylko częściowo, ponieważ dla uprawnień dostępu nie ma szczegółowej kontroli na poziomie kolumn, gdzie widoki mogą być akceptowalnym rozwiązaniem.
W dokumentacji Cloud Spanner w sekcji szczegółowo opisującej kwoty i ograniczenia (), jest, w szczególności, jeden, który może być problematyczny dla niektórych aplikacji: Cloud Spanner ma domyślnie ograniczenie do maksymalnie 100 baz danych na instancję. Oczywiste jest, że może to stanowić poważną przeszkodę dla bazy danych, która ma być skalowalna na więcej niż 100 baz danych. Na szczęście, po rozmowie z naszym przedstawicielem technicznym z Google, dowiedzieliśmy się, że ten limit może być zwiększony niemal do dowolnej wartości przez wsparcie Google.
Wsparcie dla rozwoju?
Cloud Spanner oferuje całkiem dobrą obsługę języków programowania do pracy z jego API. Oficjalnie wspierane biblioteki obejmują C#, Go, Java, node.js, PHP, Python i Ruby. Dokumentacja jest dość szczegółowa, ale, jak w przypadku innych zaawansowanych technologii, społeczność jest stosunkowo mała w porównaniu z najbardziej popularnymi technologiami baz danych, co może prowadzić do wydłużenia czasu potrzebnego na rozwiązywanie mniej powszechnych przypadków użycia lub problemów.
A co z wsparciem lokalnego rozwoju?
Nie znaleźliśmy sposobu na utworzenie instancji Cloud Spanner w lokalnym środowisku. Najbliżej, co udało nam się osiągnąć, to obraz Dockera. , który w zasadzie jest podobny, ale w praktyce znacznie się różni. Na przykład, CockroachDB może używać PostgreSQL JDBC. Ponieważ środowisko deweloperskie powinno być jak najbliższe środowisku produkcyjnemu, Cloud Spanner nie jest idealne, ponieważ trzeba polegać na pełnej instancji Spanner. Aby zredukować koszty, można wybrać instancję w jednym regionie.
Wsparcie dla administracji?
Utworzenie instancji Cloud Spanner jest bardzo proste. Wystarczy wybrać między utworzeniem instancji multi-regionowej lub dla jednego regionu, wskazać region(y) oraz liczbę węzłów. W mniej niż minutę instancja zostanie uruchomiona i gotowa do pracy.
Kilka podstawowych metryk jest bezpośrednio dostępnych na stronie Spanner w konsoli Google. Bardziej szczegółowe widoki są dostępne przez Stackdriver, gdzie można również ustawić progi metryk i zasady powiadomień.
Dostęp do zasobów?
MySQL oferuje rozbudowane i bardzo szczegółowe ustawienia uprawnień/rol użytkowników. Łatwo można dostosować dostęp do określonej tabeli lub nawet tylko do podzbioru jej kolumn. Cloud Spanner korzysta z narzędzia Google Identity & Access Management (IAM), które pozwala na ustalanie polityk i uprawnień tylko na bardzo wysokim poziomie. Najbardziej szczegółową opcją jest uprawnienie na poziomie bazy danych, które nie znajduje zastosowania w większości sytuacji produkcyjnych. To ograniczenie zmusza cię do dodawania dodatkowych środków bezpieczeństwa w swoim kodzie, infrastrukturze lub w obu tych elementach, aby zapobiec nieautoryzowanemu wykorzystaniu zasobów Spanner.
Kopie zapasowe?
Mówiąc prosto, nie ma kopii zapasowych w Cloud Spanner. Choć wysokie wymagania Google SLA mogą zapewnić, że nie stracisz żadnych danych z powodu awarii sprzętu lub bazy danych, od błędów ludzkich, defektów aplikacji itd. Wszyscy znamy zasady: wysoka dostępność nie zastępuje rozsądnej strategii tworzenia kopii zapasowych. Obecnie jedynym sposobem na tworzenie kopii zapasowych danych jest strumieniowe przesyłanie ich z bazy danych do oddzielnego środowiska przechowywania.
Wydajność zapytań?
Do ładowania danych i testowania zapytań użyliśmy Yahoo! Cloud Serving Benchmark. W poniższej tabeli przedstawiono obciążenie B YCSB z stosunkiem odczytów 95% do zapisów 5%.
* Test obciążeniowy został przeprowadzony na silniku obliczeniowym (CE) n1-standard-32 (32 vCPU, 120 GB pamięci), a instancja testowa nigdy nie była wąskim gardłem podczas testów.
** Maksymalna liczba wątków w jednej instancji YCSB wynosi 400. Łącznie trzeba było uruchomić sześć równoległych instancji testów YCSB, aby uzyskać łącznie 2400 wątków.
Patrząc na wyniki testów, szczególnie na połączenie obciążenia procesora i TPS, wyraźnie widzimy, że Cloud Spanner dobrze się skaluje. Duże obciążenie generowane przez dużą liczbę wątków jest kompensowane przez dużą liczbę węzłów w klastrze Cloud Spanner. Chociaż opóźnienie wydaje się dość wysokie, szczególnie przy pracy z 2400 wątkami, aby uzyskać dokładniejsze liczby, może być konieczne ponowne testowanie z 6 mniejszymi instancjami silnika obliczeniowego. Każda instancja uruchomi jeden test YCSB zamiast jednej dużej instancji CE z 6 równoległymi testami. W ten sposób łatwiej będzie odróżnić opóźnienia zapytań Cloud Spanner i opóźnienia, które dodaje połączenie sieciowe między Cloud Spanner a instancją CE, na której wykonywany jest test.
Jak Cloud Spanner radzi sobie jako OLAP?
Partycjonowanie?
Podział danych na fizycznie i/lub logicznie niezależne segmenty, zwane partycjami, jest bardzo popularną koncepcją właściwą dla większości mechanizmów OLAP. Partycje mogą znacznie poprawić wydajność zapytań i konserwowalność bazy danych. Dalsze zgłębianie partycji mogłoby zająć osobny artykuł(-y), więc po prostu wspomnijmy o znaczeniu posiadania schematu partycjonowania i sub-partycjonowania. Możliwość dzielenia danych na partycje, a nawet dalej na sub-partycje, jest kluczowa dla wydajności zapytań analitycznych.
Cloud Spanner nie obsługuje partycji jako takich. Dzieli dane wewnętrzne na tzw. split-y na podstawie zakresów klucza głównego. Podział jest wykonywany automatycznie w celu równoważenia obciążenia w klastrze Cloud Spanner. Bardzo przydatną funkcją Cloud Spanner jest rozbicie podstawowego obciążenia tabeli macierzystej (tabeli, która nie jest naprzemienna z inną). Spanner automatycznie określa, czy split dane są odczytywane częściej niż dane w innych split-ach, i może podjąć decyzję o dalszym podziale. W ten sposób w zapytaniu może być zaangażowanych więcej węzłów, co skutecznie zwiększa również przepustowość.
Ładowanie danych?
Metoda Cloud Spanner dla dużych danych jest taka sama jak przy zwykłym ładowaniu. Aby osiągnąć maksymalną wydajność, należy przestrzegać kilku zaleceń, w tym:
- Sortuj swoje dane według klucza głównego.
- Podziel je na 10*liczba węzłów oddzielnych sekcji.
- Utwórz zestaw zadań roboczych, które ładować będą dane równolegle.
Podczas takiego ładowania danych wykorzystywane są wszystkie węzły Cloud Spanner.
Użyliśmy obciążenia A YCSB do wygenerowania zestawu danych z 10M wierszami.
* Test obciążenia był przeprowadzany na silniku obliczeniowym n1-standard-32 (32 vCPU, 120 GB pamięci), a instancja testowa nigdy nie była wąskim gardłem w testach.
** Konfiguracja z 1 węzłem nie jest zalecana dla jakichkolwiek obciążeń produkcyjnych.
Jak wspomniano wcześniej, Cloud Spanner automatycznie obsługuje podziały w zależności od ich obciążenia, dlatego wyniki poprawiają się po kilku kolejnych powtórzeniach testu. Wyniki przedstawione tutaj to najlepsze wyniki, jakie uzyskaliśmy. Patrząc na powyższe liczby, możemy zobaczyć, jak Cloud Spanner (dobrze) skalują się ze wzrostem liczby węzłów w klastrze. Liczby, które się wyróżniają, to niezwykle niski czas opóźnienia, który kontrastuje z wynikami mieszanych obciążeń (95% na odczyt i 5% na zapis), jak opisano w powyższej sekcji.
Skalowanie?
Zwiększanie i zmniejszanie liczby węzłów Cloud Spanner to zadanie wykonywane za pomocą jednego kliknięcia. Jeśli chcesz szybko załadować dane, możesz rozważyć zwiększenie instancji do maksimum (w naszym przypadku było to 25 węzłów w regionie US-EAST), a następnie zmniejszyć liczbę węzłów, która pasuje do twojego normalnego obciążenia, po załadowaniu wszystkich danych do bazy danych, mając na uwadze ograniczenie 2 TB/węzeł.
Przypomniano nam o tym limicie nawet przy znacznie mniejszej bazie danych. Po kilku przebiegach testów obciążeniowych nasza baza danych miała rozmiar około 155 GB, a przy zmniejszeniu do instancji z 1 węzłem otrzymaliśmy następujący błąd:
Udało nam się zmniejszyć skalę z 25 do 2 instancji, ale utknęliśmy na dwóch węzłach.
Zmiany w liczbie węzłów w klastrze Cloud Spanner można zautomatyzować za pomocą REST API. Może to być szczególnie przydatne w celu zmniejszenia zwiększonego obciążenia systemu w godzinach szczytu.
Wydajność zapytań OLAP?
Początkowo planowaliśmy przeznaczyć znaczną ilość czasu na naszą ocenę Spanner w tej części. Po kilku SELECT COUNT od razu zdaliśmy sobie sprawę, że testowanie będzie krótkie i że Spanner NIE będzie odpowiednim silnikiem OLAP. Bez względu na liczbę węzłów w klastrze, proste zapytanie o liczbę wierszy w tabeli zawierającej 10M wierszy zajmowało od 55 do 60 sekund. Ponadto każde zapytanie, które wymagało większej ilości pamięci do przechowywania wyników pośrednich, kończyło się błędem OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M unikalnych wartości) -> SpoolingHashAggregateIterator wyczerpał pamięć podczas dodawania nowego wiersza.
Niektóre dane dla zapytań TPC-H można znaleźć w artykule Todda Lipkona , slajdy 42 i 43. Te liczby są zgodne z naszymi własnymi wynikami (niestety).
4. Nasze wnioski
Biorąc pod uwagę obecny stan funkcji Cloud Spanner, trudno wyobrazić sobie jego prostą zastąpienie istniejącym rozwiązaniem OLTP, szczególnie gdy twoje potrzeby przekroczą jego możliwości. Wymagałoby to znacznej ilości czasu na zbudowanie rozwiązania z uwzględnieniem niedociągnięć Cloud Spanner.
Kiedy rozpoczęliśmy ocenę Cloud Spanner, oczekiwaliśmy, że jego funkcje zarządzania będą na poziomie lub przynajmniej niezbyt odbiegają od innych rozwiązań Google SQL. Jednak byliśmy zaskoczeni całkowitym brakiem kopii zapasowych oraz bardzo ograniczoną kontrolą dostępu do zasobów. Nie wspominając już o braku widoków, braku lokalnego środowiska deweloperskiego, nieobsługiwanych sekwencjach, JDBC bez wsparcia dla DML i DDL itd.
Jak więc ma postąpić ten, kto musi skalować bazę danych transakcyjnych? Wygląda na to, że na rynku nie ma jeszcze jednego rozwiązania, które odpowiadałoby wszystkim przypadkom użycia. Istnieje wiele rozwiązań z zamkniętym i otwartym kodem źródłowym (niektóre z nich zostały wspomniane w tym artykule), z których każde ma swoje mocne i słabe strony, ale żadne z nich nie oferuje SaaS z SLA na poziomie 99,999% i wysokim poziomie spójności. Jeśli wysoki poziom SLA jest Twoim głównym celem i nie planujesz tworzyć własnego rozwiązania dla kilku środowisk chmurowych, Cloud Spanner może okazać się rozwiązaniem, którego szukasz. Musisz jednak być świadomy wszystkich jego ograniczeń.
Sprawiedliwości należy jednak zadośćuczynić, że Cloud Spanner została udostępniona publicznie dopiero wiosną 2017 roku, więc rozsądnie jest oczekiwać, że niektóre z jego obecnych wad mogą ostatecznie zniknąć (miejmy nadzieję), a kiedy to się stanie, może to zmienić zasady gry. W końcu Cloud Spanner to nie tylko projekt zewnętrzny dla Google. Google wykorzystuje go jako podstawę dla innych produktów Google. A kiedy Google niedawno zastąpił Megastore w Google Cloud Storage Cloud Spanner, to umożliwiło Google Cloud Storage stać się ściśle spójnym dla list obiektów na całym świecie (co nadal nie dotyczy ).
Tak więc, nadzieja jeszcze jest… mamy nadzieję.
Na tym kończymy. Tak jak i autor artykułu, my również nadal mamy nadzieję, co o tym sądzicie? Podzielcie się w komentarzach
Zachęcamy wszystkich do wzięcia udziału w naszym w ramach którego szczegółowo omówimy kurs od OTUS.
Źródło: habr.com
