Tymczasowy magazyn jest czyszczony, zasoby s\u0105 zwalniane.<\/li>\n<\/ul>\nW tej architekturze p\u0142acimy tylko za proces wykonania zapytania. Brak zapyta\u0144 \u2014 brak wydatk\u00f3w.<\/p>\n
Na przyk\u0142adzie Athena wida\u0107, \u017ce serwerowa baza danych dzia\u0142a na rzeczywistych zapytaniach z dziesi\u0105tkami i setkami terabajt\u00f3w danych. Dla setek terabajt\u00f3w potrzebne b\u0119d\u0105 setki serwer\u00f3w, ale nie musimy za nie p\u0142aci\u0107 \u2014 p\u0142acimy za zapytania. Pr\u0119dko\u015b\u0107 ka\u017cdego zapytania jest (bardzo) niska w por\u00f3wnaniu z wyspecjalizowanymi bazami analitycznymi, takimi jak Vertica, ale nie p\u0142acimy za okresy bezczynno\u015bci.<\/p>\n
Taka baza danych nadaje si\u0119 do rzadkich analitycznych zapyta\u0144 ad-hoc. Na przyk\u0142ad, gdy spontanicznie zdecydujemy si\u0119 sprawdzi\u0107 hipotez\u0119 na olbrzymiej ilo\u015bci danych. W takich przypadkach Athena sprawdza si\u0119 idealnie. Dla regularnych zapyta\u0144 taki system staje si\u0119 drogi. W takim przypadku nale\u017cy buforowa\u0107 dane w jakim\u015b wyspecjalizowanym rozwi\u0105zaniu. <\/p>\n
Serverless dla rozwi\u0105za\u0144 OLTP<\/h2>\n \nW poprzednim przyk\u0142adzie rozwa\u017cano zadania OLAP (analityczne). Teraz om\u00f3wimy zadania OLTP.<\/p>\n
Przedstawmy skalowalny PostgreSQL lub MySQL. Podnie\u015bmy standardow\u0105 zarz\u0105dzan\u0105 instancj\u0119 PostgreSQL lub MySQL na minimalnych zasobach. Kiedy na instancj\u0119 nap\u0142ywa wi\u0119ksze obci\u0105\u017cenie, do\u0142\u0105czamy dodatkowe repliki, na kt\u00f3re rozdzielamy cz\u0119\u015b\u0107 obci\u0105\u017cenia odczytowego. Je\u015bli nie ma zapyta\u0144 i obci\u0105\u017cenia \u2014 wy\u0142\u0105czamy repliki. Pierwsza instancja to master, a pozosta\u0142e to repliki.<\/p>\n
Ta idea zosta\u0142a zrealizowana w bazie o nazwie Aurora Serverless AWS. Zasada jest prosta: zapytania z zewn\u0119trznych aplikacji przyjmuje zesp\u00f3\u0142 proxy. Widz\u0105c wzrost obci\u0105\u017cenia, przydziela zasoby obliczeniowe z wst\u0119pnie uruchomionych minimalnych instancji \u2014 po\u0142\u0105czenie nast\u0119puje maksymalnie szybko. Wy\u0142\u0105czanie instancji odbywa si\u0119 w ten sam spos\u00f3b.<\/p>\n
W ramach Aurory istnieje poj\u0119cie Aurora Capacity Unit, ACU. To (umownie) instancja (serwer). Ka\u017cde konkretne ACU mo\u017ce by\u0107 master lub slave. Ka\u017cda jednostka pojemno\u015bci ma w\u0142asn\u0105 pami\u0119\u0107 RAM, procesor i minimalny dysk. W zwi\u0105zku z tym jedna instancja jest master, a pozosta\u0142e to repliki tylko do odczytu.<\/p>\n
Liczba tych dzia\u0142aj\u0105cych jednostek pojemno\u015bci Aurora jest parametrem konfigurowalnym. Minimalna liczba mo\u017ce wynosi\u0107 jeden lub zero (w takim przypadku baza nie dzia\u0142a, je\u015bli nie ma zapyta\u0144).<\/p>\n
Baza Aurora Serverless mo\u017ce skalowa\u0107 obci\u0105\u017cenie odczytowe. Ale w dokumentacji nie jest to powiedziane wprost. Mo\u017ce powsta\u0107 wra\u017cenie, \u017ce mog\u0105 uruchamia\u0107 multi-master. \u017badnego magicznego aspektu tu nie ma. <\/p>\n
Ta baza dobrze nadaje si\u0119 do unikania wydawania ogromnych pieni\u0119dzy na systemy z nieprzewidywalnym dost\u0119pem. Na przyk\u0142ad, przy tworzeniu MVP lub marketingowych stron wizyt\u00f3wkowych, zwykle nie spodziewamy si\u0119 stabilnego obci\u0105\u017cenia. W zwi\u0105zku z tym, przy braku dost\u0119pu, nie p\u0142acimy za instancje. Gdy nagle pojawia si\u0119 obci\u0105\u017cenie, na przyk\u0142ad po konferencji lub kampanii reklamowej, t\u0142umy ludzi odwiedzaj\u0105 stron\u0119, a obci\u0105\u017cenie gwa\u0142townie ro\u015bnie, Aurora Serverless automatycznie przyjmuje to obci\u0105\u017cenie i szybko uruchamia brakuj\u0105ce zasoby (ACU). Po zako\u0144czeniu konferencji wszyscy zapominaj\u0105 o prototypie, serwery (ACU) gasn\u0105, a wydatki spadaj\u0105 do zera \u2014 to wygodne.<\/p>\n
To rozwi\u0105zanie nie nadaje si\u0119 do stabilnego wysokiego obci\u0105\u017cenia, poniewa\u017c nie potrafi skalowa\u0107 obci\u0105\u017cenia zapisu. Wszystkie te po\u0142\u0105czenia i od\u0142\u0105czenia zasob\u00f3w odbywaj\u0105 si\u0119 w momencie tzw. \u201epunktu skalowania\u201d \u2014 momentu, w kt\u00f3rym baza nie jest trzymana przez transakcj\u0119 ani przez tymczasowe tabele. Na przyk\u0142ad, w ci\u0105gu tygodnia punkt skalowania mo\u017ce si\u0119 nie zdarzy\u0107, a baza dzia\u0142a na tych samych zasobach i po prostu nie mo\u017ce ani si\u0119 rozbudowa\u0107, ani skurczy\u0107. <\/p>\n
Nie ma magii \u2014 to zwyk\u0142y PostgreSQL. Ale proces dodawania maszyn i od\u0142\u0105czania jest cz\u0119\u015bciowo zautomatyzowany.<\/p>\n
Serverless by design<\/h2>\n \nAurora Serverless to stara baza, przepisana pod chmury, aby wykorzysta\u0107 oddzielne zalety Serverless. A teraz opowiem o bazie, kt\u00f3ra zosta\u0142a pierwotnie napisana pod chmury, w podej\u015bciu serverless \u2014 Serverless-by-design. Zosta\u0142a od razu zaprojektowana bez za\u0142o\u017cenia, \u017ce dzia\u0142a na fizycznych serwerach.<\/p>\n
Ta baza nazywa si\u0119 Snowflake. Ma trzy kluczowe bloki.<\/p>\n
Drugi blok \u2013 to wiele wirtualnych klastr\u00f3w obliczeniowych do oblicze\u0144 (na ilustracji \u2013 zestaw niebieskich k\u00f3\u0142ek).<\/p>\n
Trzeci blok \u2013 to system przechowywania danych oparty na S3. S3 to bezwymiarowe obiektowe przechowywanie w AWS, co\u015b w rodzaju bezwymiarowego Dropboxa dla biznesu.<\/p>\n
Przyjrzyjmy si\u0119, jak dzia\u0142a Snowflake, zak\u0142adaj\u0105c zimny start. To znaczy, \u017ce baza istnieje, dane zosta\u0142y za\u0142adowane, a zapyta\u0144 nie ma. W zwi\u0105zku z tym, je\u015bli nie ma zapyta\u0144 do bazy, uruchomiony mamy szybki serwis Metadata w pami\u0119ci (pierwszy blok). A w naszym przypadku mamy r\u00f3wnie\u017c magazyn S3, w kt\u00f3rym znajduj\u0105 si\u0119 dane tabel, podzielone na tzw. mikropartycje. Upraszczaj\u0105c: je\u015bli w tabeli znajduj\u0105 si\u0119 transakcje, to mikropartycje to dni transakcji. Ka\u017cdy dzie\u0144 to oddzielna mikropartycja, oddzielny plik. Gdy baza dzia\u0142a w takim trybie, p\u0142acisz tylko za miejsce zajmowane przez dane. Co wi\u0119cej, stawka za miejsce jest bardzo niska (szczeg\u00f3lnie bior\u0105c pod uwag\u0119 znaczne kompresje). Serwis metadanych r\u00f3wnie\u017c dzia\u0142a ca\u0142y czas, ale aby zoptymalizowa\u0107 zapytania, nie potrzebuje wielu zasob\u00f3w, wi\u0119c mo\u017cna uzna\u0107 go za warunkowo bezp\u0142atny. <\/p>\n
Teraz wyobra\u017amy sobie, \u017ce u\u017cytkownik przyszed\u0142 do naszej bazy i z\u0142o\u017cy\u0142 zapytanie SQL. Zapytanie SQL jest natychmiast kierowane do przetworzenia do serwisu Metadata. Odpowiednio, po otrzymaniu zapytania, ten serwis analizuje zapytanie, dost\u0119pne dane, uprawnienia u\u017cytkownika i, je\u015bli wszystko jest w porz\u0105dku, tworzy plan przetwarzania zapytania.<\/p>\n
Nast\u0119pnie serwis inicjuje uruchomienie klastra obliczeniowego. Klastr obliczeniowy to klaster serwer\u00f3w, kt\u00f3re przeprowadzaj\u0105 obliczenia. To znaczy, \u017ce klaster mo\u017ce zawiera\u0107 1 serwer, 2 serwery, 4, 8, 16, 32 \u2014 ile chcesz. Sk\u0142adasz zapytanie, a w jego odpowiedzi natychmiast rozpoczyna si\u0119 uruchamianie tego klastra. To naprawd\u0119 zajmuje sekundy.<\/p>\n
Ka\u017cde zapytanie SQL mo\u017ce nie tylko oblicza\u0107 agregaty z wcze\u015bniej za\u0142adowanych danych, ale tak\u017ce \u0142adowa\u0107\/formowa\u0107 nowe dane w bazie. Oznacza to, \u017ce mo\u017ce to by\u0107 zapytanie, kt\u00f3re na przyk\u0142ad wstawia nowe rekordy do innej tabeli, co prowadzi do powstania nowej partycji w klastrze obliczeniowym, kt\u00f3ra z kolei automatycznie zostaje zapisana w jednolitym magazynie S3.<\/p>\n
Opisany powy\u017cej scenariusz, od momentu przybycia u\u017cytkownika do uruchomienia klastra, za\u0142adunku danych, wykonania zapyta\u0144 i otrzymania wynik\u00f3w, jest naliczany wed\u0142ug stawki za minuty korzystania z uruchomionego wirtualnego klastra obliczeniowego, wirtualnego magazynu. Stawka r\u00f3\u017cni si\u0119 w zale\u017cno\u015bci od strefy AWS i rozmiaru klastra, ale \u015brednio wynosi kilka dolar\u00f3w za godzin\u0119. Klaster sk\u0142adaj\u0105cy si\u0119 z czterech maszyn kosztuje dwa razy wi\u0119cej ni\u017c klaster z dw\u00f3ch maszyn, a klaster z o\u015bmiu maszyn jeszcze dwa razy wi\u0119cej. Dost\u0119pne s\u0105 opcje z 16 lub 32 maszynami, w zale\u017cno\u015bci od z\u0142o\u017cono\u015bci zapyta\u0144. P\u0142acisz jednak tylko za te minuty, kiedy klaster rzeczywi\u015bcie dzia\u0142a, poniewa\u017c gdy zapyta\u0144 nie ma, mo\u017cesz jakby odczeka\u0107, a po 5-10 minutach oczekiwania (mo\u017cna to dostosowa\u0107) klaster sam si\u0119 wy\u0142\u0105czy, zwalniaj\u0105c zasoby i staj\u0105c si\u0119 bezp\u0142atnym.<\/p>\n
Scenariusz, w kt\u00f3rym sk\u0142adaj\u0105c zapytanie, klaster uruchamia si\u0119, m\u00f3wi\u0105c w skr\u00f3cie, w ci\u0105gu minuty, przez kolejn\u0105 minut\u0119 wykonuje obliczenia, a nast\u0119pnie przez pi\u0119\u0107 minut si\u0119 wy\u0142\u0105cza, a w rezultacie p\u0142acisz za siedem minut pracy tego klastra, a nie za miesi\u0105ce czy lata.<\/p>\n
Pierwszy scenariusz opisa\u0142 u\u017cycie Snowflake w wariancie jednego u\u017cytkownika. Teraz wyobra\u017amy sobie, \u017ce u\u017cytkownik\u00f3w jest wielu, co ju\u017c bardziej zbli\u017ca si\u0119 do rzeczywistego scenariusza.<\/p>\n
Przypu\u015b\u0107my, \u017ce mamy wielu analityk\u00f3w i raporty Tableau, kt\u00f3re nieustannie bombarduj\u0105 nasz\u0105 baz\u0119 du\u017c\u0105 ilo\u015bci\u0105 prostych analitycznych zapyta\u0144 SQL.<\/p>\n
Ponadto za\u0142\u00f3\u017cmy, \u017ce mamy pomys\u0142owych Data Scientist\u00f3w, kt\u00f3rzy pr\u00f3buj\u0105 robi\u0107 z danymi rzeczy niezwyk\u0142e, operuj\u0105c dziesi\u0105tkami terabajt\u00f3w, analizuj\u0105c miliardy i tryliony wierszy danych. <\/p>\n
Dla opisanych powy\u017cej dw\u00f3ch typ\u00f3w obci\u0105\u017cenia Snowflake umo\u017cliwia uruchamianie kilku niezale\u017cnych klastr\u00f3w obliczeniowych o r\u00f3\u017cnej mocy. Te klastry obliczeniowe dzia\u0142aj\u0105 niezale\u017cnie, ale na wsp\u00f3lnych, zgody danych.<\/p>\n
Dla du\u017cej liczby lekkich zapyta\u0144 mo\u017cna uruchomi\u0107 2-3 ma\u0142e klastry, na przyk\u0142ad po 2 maszyny ka\u017cdy. To zachowanie mo\u017cna wdro\u017cy\u0107 r\u00f3wnie\u017c za pomoc\u0105 automatycznych ustawie\u0144. M\u00f3wi\u0105c: \u201eSnowflake, uruchom ma\u0142y klaster. Je\u015bli obci\u0105\u017cenie wzro\u015bnie ponad okre\u015blony parametr, uruchom analogiczny drugi, trzeci. Kiedy obci\u0105\u017cenie zacznie male\u0107 \u2014 zga\u015b zb\u0119dne\u201d. Dzi\u0119ki temu niezale\u017cnie od tego, ile analityk\u00f3w przychodzi i zaczyna przegl\u0105da\u0107 raporty, wszystkim wystarczy zasob\u00f3w.<\/p>\n
Jednocze\u015bnie, je\u015bli analitycy \u015bpi\u0105, a nikt nie przegl\u0105da raport\u00f3w \u2014 klastry mog\u0105 ca\u0142kowicie si\u0119 wy\u0142\u0105czy\u0107, a Ty przestajesz za nie p\u0142aci\u0107.<\/p>\n
Jednak w przypadku ci\u0119\u017cszych zapyta\u0144 (od Data Scientist\u00f3w) mo\u017cesz uruchomi\u0107 jeden bardzo du\u017cy klaster na przyk\u0142ad 32 maszyn. Ten klaster r\u00f3wnie\u017c b\u0119dzie op\u0142acany tylko za te minuty i godziny, kiedy dzia\u0142a Twoje ogromne zapytanie.<\/p>\n
Opisana powy\u017cej mo\u017cliwo\u015b\u0107 pozwala dzieli\u0107 obci\u0105\u017cenia na klastry nie tylko dla 2, ale i dla wi\u0119cej rodzaj\u00f3w obci\u0105\u017cenia (ETL, monitorowanie, materializacja raport\u00f3w,\u2026).<\/p>\n
Podsumujmy Snowflake. Baza \u0142\u0105czy pi\u0119kn\u0105 ide\u0119 z funkcjonaln\u0105 realizacj\u0105. W ManyChat u\u017cywamy Snowflake do analizy wszystkich dost\u0119pnych danych. Mamy nie trzy klastry, jak w przyk\u0142adzie, a od 5 do 9, w r\u00f3\u017cnych rozmiarach. Posiadamy klastrowe maszyny 16-rdzeniowe, 2-rdzeniowe, a tak\u017ce super ma\u0142e 1-rdzeniowe do niekt\u00f3rych zada\u0144. One efektywnie rozdzielaj\u0105 obci\u0105\u017cenie i pozwalaj\u0105 nam zaoszcz\u0119dzi\u0107.<\/p>\n
Baza skutecznie skalowalna jest na obci\u0105\u017ceniach odczytu i zapisu. To ogromna r\u00f3\u017cnica i znacz\u0105cy prze\u0142om w por\u00f3wnaniu do 'Aurory', kt\u00f3ra obs\u0142ugiwa\u0142a tylko obci\u0105\u017cenie odczytu. Snowflake umo\u017cliwia skalowanie tych obci\u0105\u017ce\u0144 obliczeniowymi klastrami, w tym zapisu. Jak wspomnia\u0142em, w ManyChat u\u017cywamy kilku klastr\u00f3w, a ma\u0142e i super ma\u0142e klastry najcz\u0119\u015bciej wykorzystywane s\u0105 do ETL, do \u0142adowania danych. Analitycy pracuj\u0105 z kolei na \u015brednich klastrach, kt\u00f3re s\u0105 ca\u0142kowicie niezagro\u017cone obci\u0105\u017ceniem ETL, dlatego dzia\u0142aj\u0105 bardzo szybko. <\/p>\n
Odpowiednio, baza dobrze nadaje si\u0119 do zada\u0144 OLAP. Niestety, nie nadaje si\u0119 jeszcze do obci\u0105\u017ce\u0144 OLTP. Po pierwsze, ta baza jest kolumnowa, co poci\u0105ga za sob\u0105 odpowiednie konsekwencje. Po drugie, sama koncepcja, w kt\u00f3rej na ka\u017cde zapytanie odpowiednio uruchamiasz obliczeniowy klaster i obci\u0105\u017casz go danymi, niestety, dla obci\u0105\u017ce\u0144 OLTP jest jeszcze niewystarczaj\u0105co szybka. Sekundy oczekiwania w przypadku zada\u0144 OLAP s\u0105 akceptowalne, ale w przypadku obci\u0105\u017ce\u0144 OLTP s\u0105 niedopuszczalne; lepiej by\u0142oby w 100 ms, a jeszcze lepiej \u2014 w 10 ms.<\/p>\n
Podsumowanie<\/h2>\n \nBaza danych bezserwerowa mo\u017cliwa jest dzi\u0119ki podzia\u0142owi bazy danych na cz\u0119\u015bci Stateless i Stateful. Z pewno\u015bci\u0105 zauwa\u017cy\u0142e\u015b, \u017ce we wszystkich podanych przyk\u0142adach cz\u0119\u015b\u0107 Stateful \u2014 to, powiedzmy, przechowywanie mikropartycji w S3, a Stateless \u2014 to optymalizator, praca z metadanymi, przetwarzanie kwestii bezpiecze\u0144stwa, kt\u00f3re mog\u0105 by\u0107 uruchomione jako niezale\u017cne, lekkie us\u0142ugi Stateless.<\/p>\n
Wykonywanie zapyta\u0144 SQL mo\u017cna r\u00f3wnie\u017c postrzega\u0107 jako us\u0142ugi z lekkim stanem, kt\u00f3re mog\u0105 dzia\u0142a\u0107 w trybie bezserwerowym, jak obliczeniowe klastry Snowflake, pobiera\u0107 tylko potrzebne dane, wykonywa\u0107 zapytanie i 'wygasza\u0107'.<\/p>\n
Bazy danych bezserwerowych poziomu produkcyjnego s\u0105 ju\u017c dost\u0119pne i dzia\u0142aj\u0105. Te bazy bezserwerowe s\u0105 gotowe do radzenia sobie z zadaniami OLAP. Niestety, w przypadku zada\u0144 OLTP stosowane s\u0105... z pewnymi zastrze\u017ceniami, poniewa\u017c istniej\u0105 ograniczenia. Z jednej strony jest to wada. Z drugiej strony to szansa. Mo\u017ce kto\u015b z czytelnik\u00f3w znajdzie spos\u00f3b, aby baza OLTP sta\u0142a si\u0119 ca\u0142kowicie bezserwerowa, bez ogranicze\u0144 Aurora.<\/p>\n
Mam nadziej\u0119, \u017ce to by\u0142o interesuj\u0105ce. Za bezserwerow\u0105 przysz\u0142o\u015b\u0107 \ud83d\ude42habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0413\u043e\u043b\u043e\u0432 \u041d\u0438\u043a\u043e\u043b\u0430\u0439. \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u043b \u0432 \u0410\u0432\u0438\u0442\u043e \u0438 \u0448\u0435\u0441\u0442\u044c \u043b\u0435\u0442 \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u043b Data Platform, \u0442\u043e \u0435\u0441\u0442\u044c \u0437\u0430\u043d\u0438\u043c\u0430\u043b\u0441\u044f \u0432\u0441\u0435\u043c\u0438 \u0431\u0430\u0437\u0430\u043c\u0438: \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c\u0438 (Vertica, ClickHouse), \u043f\u043e\u0442\u043e\u043a\u043e\u0432\u044b\u043c\u0438 \u0438 OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). \u0417\u0430 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f \u044f \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u043b\u0441\u044f \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u2014 \u0441\u0430\u043c\u044b\u0445 \u0440\u0430\u0437\u043d\u044b\u0445 \u0438 \u043d\u0435\u043e\u0431\u044b\u0447\u043d\u044b\u0445, \u0438 \u0441 \u043d\u0435\u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u044b\u043c\u0438 \u043a\u0435\u0439\u0441\u0430\u043c\u0438 \u0438\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91636,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91635","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t