Witajcie Chabrowicze. Tradycyjnie kontynuujemy udostępnianie ciekawych materiałów w przeddzień startu nowych kursów. Dziś specjalnie dla Ciebie przetłumaczyliśmy artykuł o Google Cloud Spanner, który zbiegł się w czasie z rozpoczęciem kursu .
Pierwotnie opublikowane w .
Jako firma oferująca różnorodne rozwiązania POS oparte na chmurze dla sprzedawców detalicznych, restauratorów i sprzedawców internetowych na całym świecie, Lightspeed korzysta z kilku różnych typów platform bazodanowych do różnych zastosowań transakcyjnych, analitycznych i wyszukiwania. Każda z tych platform bazodanowych ma swoje mocne i słabe strony, dlatego kiedy Google wprowadziło na rynek Cloud Spanner - obiecujące funkcje niespotykane w świecie relacyjnych baz danych, takie jak praktycznie nieograniczona pozioma skalowalność i 99,999% umowa o poziomie usług (SLA) , Nie mogliśmy przepuścić okazji, żeby mieć ją w swoich rękach!
Aby przedstawić kompleksowy przegląd naszych doświadczeń z Cloud Spanner, a także zastosowanych przez nas kryteriów oceny, omówimy następujące tematy:
- Nasze kryteria oceny
- Cloud Spanner w pigułce
- Nasza ocena
- Nasze znaleziska
1. Nasze kryteria oceny
Zanim zagłębimy się w specyfikę Cloud Spanner, jego podobieństwa i różnice w stosunku do innych rozwiązań na rynku, porozmawiajmy najpierw o głównych przypadkach użycia, o których myśleliśmy, zastanawiając się, gdzie wdrożyć Cloud Spanner w naszej infrastrukturze:
- Jako zamiennik (przeważającego) tradycyjnego rozwiązania bazodanowego SQL
- Jako rozwiązanie OLTP z obsługą OLAP
Uwaga: Dla ułatwienia porównania w tym artykule porównano Cloud Spanner z wariantami MySQL z rodzin rozwiązań GCP Cloud SQL i Amazon AWS RDS.
Używanie Cloud Spanner jako zamiennika tradycyjnego rozwiązania bazodanowego SQL
W środowisku tradycyjny baz danych, gdy czas odpowiedzi na zapytanie do bazy danych zbliża się lub nawet przekracza predefiniowane progi aplikacji (głównie ze względu na wzrost liczby użytkowników i/lub żądań), istnieje kilka sposobów na skrócenie czasu odpowiedzi do akceptowalnych poziomów. Jednak większość z tych rozwiązań wymaga ręcznej interwencji.
Na przykład pierwszym krokiem, który należy wykonać, jest przyjrzenie się różnym ustawieniom bazy danych związanym z wydajnością i dostrojenie ich tak, aby najlepiej pasowały do wzorców scenariuszy użycia aplikacji. Jeśli to nie wystarczy, możesz wybrać skalowanie bazy danych w pionie lub w poziomie.
Skalowanie aplikacji wiąże się z aktualizacją instancji serwera, zwykle poprzez dodanie większej liczby procesorów/rdzeni, więcej pamięci RAM, szybszej pamięci masowej itp. Dodanie większej liczby zasobów sprzętowych skutkuje zwiększeniem wydajności bazy danych, mierzonej głównie w transakcjach na sekundę, oraz opóźnieniami transakcji dla systemów OLTP. Systemy relacyjnych baz danych (wykorzystujące podejście wielowątkowe), takie jak MySQL, dobrze skalują się w pionie.
Takie podejście ma kilka wad, ale najbardziej oczywistą jest maksymalna wielkość serwera na rynku. Po osiągnięciu największego limitu instancji serwera pozostaje tylko jedna ścieżka: skalowanie w poziomie.
Skalowanie w poziomie to podejście polegające na dodawaniu większej liczby serwerów do klastra w celu idealnego liniowego zwiększenia wydajności w miarę dodawania kolejnych serwerów. Większość tradycyjny systemy baz danych nie skalują się dobrze lub nie skalują się wcale. Na przykład MySQL może skalować w górę dla operacji odczytu, dodając czytniki podrzędne, ale nie może skalować w poziomie dla operacji zapisu.
Z drugiej strony, ze względu na swój charakter, Cloud Spanner może łatwo skalować się w poziomie przy minimalnej interwencji.
W pełni funkcjonalny DBMS jako usługa trzeba oceniać z różnych perspektyw. Jako podstawę wzięliśmy najpopularniejszy DBMS w chmurze - dla Google GCP Cloud SQL oraz dla Amazon AWS RDS. W naszej ocenie skupiliśmy się na następujących kategoriach:
- Mapowanie cech: zasięg SQL, DDL, DML; biblioteki/łączniki połączeń, obsługa transakcji i tak dalej.
- Wsparcie programistyczne: Łatwość programowania i testowania.
- Wsparcie administracyjne: Zarządzanie instancjami, takie jak skalowanie w górę/w dół i aktualizacja instancji; SLA, tworzenie kopii zapasowych i odzyskiwanie; kontrola bezpieczeństwa/dostępu.
Używanie Cloud Spanner jako rozwiązania OLTP z obsługą OLAP
Chociaż Google nie stwierdza wprost, że Cloud Spanner służy do analiz, ma wspólne atrybuty z innymi silnikami, takimi jak Apache Impala & Kudu i YugaByte, które są przeznaczone do obciążeń OLAP.
Nawet gdyby istniała niewielka szansa, że Cloud Spanner zawiera spójny, skalowalny silnik HTAP (Hybrid Transactional/Analytic Processing) z (mniej lub bardziej) użytecznym zestawem funkcji OLAP, uważamy, że zasługuje na naszą uwagę.
Mając to na uwadze, przyjrzeliśmy się następującym kategoriom:
- Ładowanie danych, indeksy i obsługa partycjonowania
- Wydajność zapytań i DML
2. Cloud Spanner w pigułce
Google Spanner to klastrowy system zarządzania relacyjnymi bazami danych (RDBMS), którego Google używa w kilku własnych usługach. Google udostępnił ją publicznie użytkownikom Google Cloud Platform na początku 2017 roku.
Oto niektóre atrybuty Cloud Spanner:
- Wysoce spójny, skalowalny klaster RDBMS: Wykorzystuje sprzętową synchronizację czasu w celu zapewnienia spójności danych.
- Obsługa transakcji między tabelami: transakcje mogą obejmować wiele tabel — niekoniecznie ograniczone do jednej tabeli (w przeciwieństwie do Apache HBase lub Apache Kudu).
- Tabele oparte na kluczu podstawowym: Wszystkie tabele muszą mieć zadeklarowany klucz podstawowy (PC), który może składać się z wielu kolumn tabeli. Dane tabelaryczne są przechowywane w kolejności na komputerze, co sprawia, że wyszukiwanie na komputerze jest bardzo wydajne i szybkie. Podobnie jak w przypadku innych systemów opartych na komputerach PC, wdrożenie musi być modelowane w oparciu o z góry przyjęte przypadki użycia, aby osiągnąć sukces .
- Tabele rozłożone: Tabele mogą mieć fizyczne zależności od siebie. Wiersze tabeli podrzędnej można dopasować do wierszy tabeli nadrzędnej. Takie podejście przyspiesza poszukiwanie relacji, które można określić na etapie modelowania danych, np. podczas umieszczania klientów i ich faktur razem.
- Indeksy: Cloud Spanner obsługuje indeksy dodatkowe. Indeks składa się z indeksowanych kolumn i wszystkich kolumn PC. Opcjonalnie indeks może zawierać również inne nieindeksowane kolumny. Indeks można przeplatać z tabelą nadrzędną, aby przyspieszyć zapytania. Do indeksów stosuje się kilka ograniczeń, takich jak maksymalna liczba dodatkowych kolumn, które można przechowywać w indeksie. Ponadto zapytania za pośrednictwem indeksów mogą nie być tak proste, jak w przypadku innych systemów RDBMS.
„Cloud Spanner automatycznie wybiera indeks tylko w rzadkich przypadkach. W szczególności Cloud Spanner nie wybiera automatycznie indeksu dodatkowego, jeśli zapytanie żąda kolumn, w których nie są przechowywane ".
- Umowa dotycząca poziomu usług (SLA): wdrożenie w jednym regionie z umową SLA na 99,99%; wdrożenia w wielu regionach z umową SLA na poziomie 99,999%. Chociaż sama umowa SLA jest tylko umową, a nie jakąkolwiek gwarancją, uważam, że pracownicy Google mają pewne twarde dane, aby wysunąć tak mocne twierdzenie. (Dla porównania, 99,999% oznacza 26,3 sekundy przestoju usługi miesięcznie).
- Więcej:
Uwaga: Projekt Apache Tephra dodaje zaawansowaną obsługę transakcji do Apache HBase (teraz również zaimplementowany w Apache Phoenix jako wersja beta).
3. Nasza ocena
Wszyscy więc czytaliśmy wypowiedzi Google o zaletach Cloud Spanner – praktycznie nieograniczone skalowanie w poziomie przy zachowaniu wysokiej spójności i bardzo wysokiego SLA. Chociaż te twierdzenia 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, na których zależy większości użytkowników baz danych: parzystości i użyteczności.
Oceniliśmy Cloud Spanner jako zamiennik dla Sharded MySQL
Google Cloud SQL i Amazon AWS RDS, dwie najpopularniejsze bazy danych OLTP na rynku chmury, mają bardzo duży zestaw funkcji. Aby jednak skalować te bazy danych poza rozmiar pojedynczego węzła, należy wykonać podział aplikacji. Takie podejście powoduje dodatkową złożoność zarówno aplikacji, jak i administracji. Przyjrzeliśmy się, jak Spanner pasuje do scenariusza łączenia wielu odłamków w jedną instancję i jakie funkcje (jeśli w ogóle) mogą wymagać poświęcenia.
Wsparcie dla SQL, DML i DDL, a także konektor i biblioteki?
Po pierwsze, zaczynając od dowolnej bazy danych, musisz utworzyć model danych. Jeśli myślisz, że możesz połączyć JDBC Spanner ze swoim ulubionym narzędziem SQL, przekonasz się, że możesz za jego pomocą wyszukiwać swoje dane, ale nie możesz go użyć do utworzenia tabeli lub aktualizacji (DDL) ani żadnego wstawiania/aktualizacji/usuwania operacje (DML). Oficjalny JDBC Google również nie obsługuje.
„Sterowniki obecnie nie obsługują instrukcji DML ani DDL”.
Dokumentacja klucza
Nie lepiej sytuacja wygląda z konsolą GCP – można wysyłać tylko zapytania SELECT. Na szczęście istnieje sterownik JDBC z obsługą DML i DDL od społeczności, w tym transakcji . Chociaż ten sterownik jest niezwykle przydatny, zaskakujący jest brak własnego sterownika JDBC firmy Google. Na szczęście Google oferuje dość szerokie wsparcie bibliotek klienckich (oparte na gRPC): C#, Go, Java, node.js, PHP, Python i Ruby.
Niemal obowiązkowe korzystanie z niestandardowych interfejsów API Cloud Spanner (ze względu na brak DDL i DML w JDBC) skutkuje pewnymi ograniczeniami dla powiązanych obszarów kodu, takich jak pule połączeń lub struktury powiązań bazy danych (jak Spring MVC). Ogólnie rzecz biorąc, podczas korzystania z JDBC możesz wybrać swoją ulubioną pulę połączeń (np. HikariCP, DBCP, C3PO itp.), która jest przetestowana i działa dobrze. W przypadku niestandardowych API Spannera musimy polegać na frameworkach/bindingach/pulach sesji, które sami stworzyliśmy.
Projekt zorientowany na klucz podstawowy (PC) umożliwia Cloud Spanner bardzo szybki dostęp do danych za pośrednictwem komputera, ale wprowadza również pewne problemy z zapytaniami.
- Nie można zaktualizować wartości klucza podstawowego; Musisz najpierw usunąć oryginalny wpis PC i wstawić go ponownie z nową wartością. (Jest to podobne do innych silników baz danych/przechowywania zorientowanych na komputery PC).
- Każda instrukcja UPDATE i DELETE musi określać PC w polu WHERE, dlatego nie może być pustych instrukcji DELETE all - zawsze musi być podzapytanie, na przykład: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Brak opcji automatycznego zwiększania lub czegoś podobnego, co ustawia kolejność dla pola PC. Aby to zadziałało, odpowiednia wartość musi zostać utworzona po stronie aplikacji.
Indeksy drugorzędne?
Google Cloud Spanner ma wbudowaną obsługę indeksów dodatkowych. To bardzo fajna funkcja, która nie zawsze jest obecna w innych technologiach. Apache Kudu obecnie w ogóle nie obsługuje indeksów pomocniczych, a Apache HBase nie obsługuje bezpośrednio indeksów, ale może je dodawać za pośrednictwem Apache Phoenix.
Indeksy w Kudu i HBase mogą być modelowane jako oddzielna tabela z innym składem kluczy podstawowych, ale atomowość operacji wykonywanych na tabeli nadrzędnej i powiązanych tabelach indeksów musi być wykonywana na poziomie aplikacji i nie jest trywialna do poprawnego zaimplementowania.
Jak wspomniano w przeglądzie Cloud Spanner, jego indeksy mogą różnić się od indeksów MySQL. W związku z tym należy zachować szczególną ostrożność podczas tworzenia zapytań i profilowania, aby zapewnić użycie poprawnego indeksu tam, gdzie jest to potrzebne.
Reprezentacja?
Bardzo popularnym i użytecznym obiektem w bazie danych są widoki. Mogą być przydatne w wielu przypadkach użycia; moimi dwoma ulubionymi są warstwa logicznej abstrakcji i warstwa bezpieczeństwa. Niestety Cloud Spanner NIE obsługuje widoków. Jednak ogranicza nas to tylko częściowo, ponieważ nie ma szczegółowości uprawnień dostępu na poziomie kolumny, gdzie widoki mogą być akceptowalnym rozwiązaniem.
Zapoznaj się z dokumentacją Cloud Spanner, aby zapoznać się z sekcją szczegółowo opisującą przydziały i limity (), jest jeden, który może być problematyczny dla niektórych aplikacji: Cloud Spanner po wyjęciu z pudełka ma maksymalnie 100 baz danych na instancję. Oczywiście może to stanowić poważną przeszkodę dla bazy danych zaprojektowanej do skalowania do ponad 100 baz danych. Na szczęście po rozmowie z naszym przedstawicielem technicznym Google dowiedzieliśmy się, że ten limit można zwiększyć do niemal dowolnej wartości za pośrednictwem pomocy technicznej Google.
Wsparcie rozwoju?
Cloud Spanner oferuje całkiem przyzwoitą obsługę języków programowania do pracy z interfejsem API. Oficjalnie wspierane biblioteki to C#, Go, Java, node.js, PHP, Python i Ruby. Dokumentacja jest dość szczegółowa, ale podobnie jak w przypadku innych najnowocześniejszych technologii, społeczność jest dość mała w porównaniu z większością popularnych technologii baz danych, co może skutkować poświęceniem większej ilości czasu na mniej powszechne przypadki użycia lub problemy.
A co ze wsparciem rozwoju lokalnego?
Nie znaleźliśmy sposobu na utworzenie lokalnej instancji Cloud Spanner. Najbliżej otrzymaliśmy obraz Dockera który jest podobny w zasadzie, ale bardzo różny w praktyce. Na przykład CockroachDB może używać PostgreSQL JDBC. Ponieważ środowisko programistyczne powinno być jak najbardziej zbliżone do środowiska produkcyjnego, Cloud Spanner nie jest idealny, ponieważ musisz polegać na pełnej instancji Spanner. Aby zaoszczędzić na kosztach, możesz wybrać pojedynczą instancję regionu.
Wsparcie administracyjne?
Tworzenie instancji Cloud Spanner jest bardzo proste. Musisz tylko wybrać między utworzeniem instancji z wieloma regionami lub z jednym regionem, określić regiony i liczbę węzłów. Za mniej niż minutę instancja zostanie uruchomiona.
Kilka podstawowych danych jest dostępnych bezpośrednio na stronie Spanner w Google Console. Bardziej szczegółowe widoki są dostępne w usłudze Stackdriver, w której można również ustawić progi metryk i zasady alertów.
Dostęp do zasobów?
MySQL oferuje rozbudowane i bardzo szczegółowe ustawienia uprawnień/roli użytkownika. Możesz łatwo dostosować dostęp do określonej tabeli, a nawet tylko podzbioru jej kolumn. Cloud Spanner korzysta z narzędzia Google Identity & Access Management (IAM), które umożliwia ustawianie zasad i uprawnień tylko na bardzo wysokim poziomie. Najbardziej szczegółową opcją są uprawnienia na poziomie bazy danych, które nie pasują do większości przypadków produkcyjnych. To ograniczenie zmusza Cię do dodania dodatkowych środków bezpieczeństwa do kodu, infrastruktury lub obu, aby zapobiec nieautoryzowanemu użyciu zasobów Spanner.
Kopie zapasowe?
Mówiąc prościej, w Cloud Spanner nie ma kopii zapasowych. Podczas gdy wysokie wymagania Google dotyczące umów SLA mogą zapewnić, że nie utracisz żadnych danych z powodu awarii sprzętu lub bazy danych, błędu ludzkiego, wad aplikacji itp. Wszyscy znamy zasadę: wysoka dostępność nie zastąpi inteligentnej strategii tworzenia kopii zapasowych. Obecnie jedynym sposobem tworzenia kopii zapasowych danych jest programowe przesyłanie ich strumieniowo z bazy danych do osobnego środowiska pamięci masowej.
Wydajność zapytania?
Użyliśmy Yahoo! do ładowania danych i testowania zapytań. Test porównawczy udostępniania w chmurze. Poniższa tabela przedstawia obciążenie B YCSB ze stosunkiem odczytu 95% do zapisu 5%.
* Test obciążenia przeprowadzono na n1-standard-32 Compute Engine (CE) (32 procesory wirtualne, 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 to 400. W sumie 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 porównawczych, w szczególności połączenie obciążenia procesora i TPS, wyraźnie widać, że Cloud Spanner skaluje się całkiem dobrze. Duże obciążenie spowodowane dużą liczbą wątków jest równoważone przez dużą liczbę węzłów w klastrze Cloud Spanner. Chociaż opóźnienie wygląda na dość wysokie, zwłaszcza przy 2400 wątkach, może być konieczne ponowne przetestowanie z 6 mniejszymi instancjami silnika obliczeniowego w celu uzyskania dokładniejszych liczb. Każda instancja uruchomi jeden test YCSB zamiast jednej dużej instancji CE z 6 równoległymi testami. Ułatwi to rozróżnienie opóźnień żądań Cloud Spanner od opóźnień dodanych przez połączenie sieciowe między Cloud Spanner a instancją CE, w której przeprowadzany jest test.
Jak działa Cloud Spanner jako OLAP?
Partycjonowanie?
Dzielenie danych na fizycznie i/lub logicznie niezależne segmenty, zwane partycjami, to bardzo popularna koncepcja spotykana w większości silników OLAP. Partycje mogą znacznie poprawić wydajność zapytań i łatwość konserwacji bazy danych. Dalsze zagłębianie się w partycjonowanie byłoby osobnym artykułem (-ami), więc wspomnijmy tylko o znaczeniu posiadania schematu partycjonowania i partycjonowania podrzędnego. Możliwość dzielenia danych na partycje, a nawet dalej na partycje podrzędne, jest kluczem do wydajności zapytań analitycznych.
Cloud Spanner nie obsługuje partycji jako takich. Segreguje dane wewnętrznie na tzw dzielić-s na podstawie zakresów kluczy podstawowych. Partycjonowanie odbywa się automatycznie w celu zrównoważenia obciążenia klastra Cloud Spanner. Bardzo przydatną funkcją Cloud Spanner jest dzielenie podstawowego obciążenia tabeli nadrzędnej (tabeli, która nie jest przeplatana z inną). Spanner automatycznie wykrywa, czy zawiera dzielić dane, które są odczytywane częściej niż dane w innych dzielić-ah, i może zdecydować o dalszej separacji. W ten sposób więcej węzłów może być zaangażowanych w żądanie, co również skutecznie zwiększa przepustowość.
Ładowanie danych?
Metoda Cloud Spanner dla danych zbiorczych jest taka sama jak w przypadku zwykłego przesyłania. Aby uzyskać maksymalną wydajność, należy przestrzegać kilku wskazówek, w tym:
- Sortuj dane według klucza podstawowego.
- Podziel je przez 10*liczba węzłów poszczególne sekcje.
- Utwórz zestaw zadań procesu roboczego, które ładują dane równolegle.
To ładowanie danych wykorzystuje wszystkie węzły Cloud Spanner.
Użyliśmy obciążenia A YCSB do wygenerowania zestawu danych wierszy 10M.
* Test obciążenia przeprowadzono na silniku obliczeniowym n1-standard-32 (32 procesory wirtualne, 120 GB pamięci), a instancja testowa nigdy nie była wąskim gardłem podczas testów.
** Konfiguracja z 1 węzłem nie jest zalecana dla żadnego obciążenia produkcyjnego.
Jak wspomniano powyżej, Cloud Spanner automatycznie przetwarza podziały w zależności od ich obciążenia, dzięki czemu wyniki poprawiają się po kilku kolejnych iteracjach testu. Przedstawione tutaj wyniki są najlepszymi wynikami, jakie otrzymaliśmy. Patrząc na powyższe liczby, możemy zobaczyć, jak Cloud Spanner skaluje się (dobrze) wraz ze wzrostem liczby węzłów w klastrze. Liczby, które się wyróżniają, to wyjątkowo niskie średnie opóźnienie, które kontrastuje z wynikami z mieszanymi obciążeniami (95% odczytu i 5% zapisu), jak opisano w sekcji powyżej.
Skalowanie?
Zwiększanie i zmniejszanie liczby węzłów Cloud Spanner to zadanie za jednym kliknięciem. Jeśli chcesz szybko ładować dane, możesz rozważyć maksymalne przyspieszenie instancji (w naszym przypadku było to 25 węzłów w regionie US-EAST), a następnie zmniejszenie liczby węzłów odpowiedniej do normalnego obciążenia po wszystkich danych w bazie danych, pamiętając o limicie 2 TB/węzeł.
Przypominano nam o tym limicie nawet przy znacznie mniejszej bazie danych. Po kilku testach obciążenia nasza baza danych miała rozmiar około 155 GB, a po przeskalowaniu do instancji 1 węzła 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.
Zwiększanie i zmniejszanie liczby węzłów w klastrze Cloud Spanner można zautomatyzować za pomocą interfejsu API REST. Może to być szczególnie przydatne w celu zmniejszenia zwiększonego obciążenia systemu w godzinach szczytu.
Wydajność zapytania OLAP?
Pierwotnie planowaliśmy poświęcić sporo czasu na ocenę Spannera w tej części. Po kilku SELECT COUNT od razu zdaliśmy sobie sprawę, że test będzie krótki i że Spanner NIE będzie odpowiednim silnikiem dla OLAP. Niezależnie od liczby węzłów w klastrze, samo wybranie liczby wierszy w 10M tabeli wierszy zajęło od 55 do 60 sekund. Ponadto każde zapytanie, które wymagało więcej pamięci do przechowywania wyników pośrednich, kończyło się niepowodzeniem z powodu błędu OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Niektóre numery zapytań TPC-H można znaleźć w artykule Todda Lipcona , slajdy 42 i 43. Liczby te są zgodne z naszymi wynikami (niestety).
4. Nasze ustalenia
Biorąc pod uwagę obecny stan funkcji Cloud Spanner, trudno postrzegać go jako prosty zamiennik istniejącego rozwiązania OLTP, zwłaszcza gdy Twoje potrzeby go przerastają. Zbudowanie rozwiązania uwzględniającego wady Cloud Spanner wymagałoby poświęcenia znacznej ilości czasu.
Kiedy zaczynaliśmy oceniać Cloud Spanner, spodziewaliśmy się, że jego funkcje zarządzania będą na równi z innymi rozwiązaniami Google SQL lub przynajmniej nie będą od nich odbiegać. Zaskoczył nas jednak całkowity brak kopii zapasowych i bardzo ograniczona kontrola dostępu do zasobów. Nie wspominając o żadnych widokach, lokalnym środowisku programistycznym, nieobsługiwanych sekwencjach, JDBC bez obsługi DML i DDL i tak dalej.
Gdzie zatem szukać kogoś, kto potrzebuje skalować transakcyjną bazę danych? Wydaje się, że na rynku nie ma jeszcze jednego rozwiązania, które pasowałoby do wszystkich przypadków użycia. Istnieje wiele zamkniętych i otwartych rozwiązań (niektóre z nich wymieniono w tym artykule), z których każde ma swoje mocne i słabe strony, ale żadne z nich nie oferuje usługi SaaS z umową SLA na poziomie 99,999% i wysokim stopniem spójności. Jeśli Twoim głównym celem jest wysoka umowa SLA i nie masz ochoty tworzyć własnego rozwiązania dla wielu chmur, Cloud Spanner może być rozwiązaniem, którego szukasz. Ale powinieneś być świadomy wszystkich jego ograniczeń.
Aby być uczciwym, Cloud Spanner został udostępniony publicznie dopiero wiosną 2017 r., więc rozsądne jest oczekiwanie, że niektóre z jego obecnych wad mogą w końcu zniknąć (miejmy nadzieję), a kiedy to nastąpi, może to zmienić zasady gry. W końcu Cloud Spanner to nie tylko poboczny projekt dla Google. Google używa go jako podstawy dla innych produktów Google. A kiedy Google niedawno zastąpiło Megastore w Google Cloud Storage przez Cloud Spanner, pozwoliło to Google Cloud Storage stać się wysoce spójne dla list obiektów w skali globalnej (co nadal nie ma miejsca w przypadku ).
Więc jest jeszcze nadzieja... my mamy nadzieję.
To wszystko. Podobnie jak autor artykułu, nadal mamy nadzieję, ale co o tym sądzisz? Napisz w komentarzach
Zapraszamy wszystkich do odwiedzenia naszego w którym szczegółowo opowiemy o kursie z firmy OTUS.
Źródło: www.habr.com