Dobrze, że Grzegorz bierze udział w rozmowach :) Może trochę ścinacie zakręty tematów, czasem zbaczając również z trasy, ale punkt widzenia osoby, która zjadła zęby na on-premie i próbuje nadrobić zaległości na szybko relatywizując swoją wiedzę w odniesieniu do chmurowej fizyki, pokazuje z czym trzeba się mierzyć na co dzień w pracy architekta z niektórymi klientami i jak tłumaczyć pewne rzeczy szerszej publiczności. Zmusza to nas też do zejścia na ziemię podczas tego całego bujania w chmurowych obłokach :) Pozwolę sobie też nieco dalej poelaborować. Technologie do rozproszonego przetwarzania w oparciu o równie rozproszone repozytoria plikowe z sukcesem wspierały big data od dawna, nie dając sobie jednak rady z koncepcjami stosowanymi w hurtowniach, które tak się składa, budujemy od lat w silnikach relacyjnych. W międzyczasie Spark i Hive całkiem sporo odmieniło w tym temacie. Idąc dalej, wprowadzenie takiej transakcyjności, jaką daje delta lake, wniosło wiele dobrego i odmieniło uciążliwy los systemów próbujących okiełznać współbieżność, wersjonowanie, choć nie zapominajmy, że on nie był pierwszy. Zachęcam Was przy okazji do poznania funkcjonalności przykładowo Apache Hudi i Iceberg. Poszerzy to horyzonty wiedzy o silnikach operujących na plikach osadzonych w data lake. Ale wracając do tematu, rozproszone systemy, czy to aplikacyjne, czy storage, niosą za sobą sporo wyzwań, których nie doświadczaliśmy w monolitach. Brak więzów integralności jest tego najprostszym przykładem. Choć jeszcze bardziej fundamentalnym jest brak choćby constrainta UNIQUE. I przy tym PK czy FK (jeśli w ogóle jest), ich znaczenie jest symboliczne, a czasem nawet zgubne (przypadek PDW/ADWH/Synapse Dedicated Pools i PK, który duplikuje dane w joinach: tinyurl.com/synapsepk ). Sporym wyzwaniem jest mimo wszystko brak bezpośredniego dostępu do danych na poziomie klastrów, sektorów, extentów, stron danych czy innych offsetów, co jest typowe dla systemów plików wykorzystywanych w bazach danych relacyjnych. Systemy plików w chmurze, takie jak Azure Data Lake, opierają się na modelu obiektowym, gdzie dane są dostępne poprzez wysokopoziomowe prymitywne REST API, który stawia na łatwość i powszechność, zapominając mocno o wydajności, którą formalnie kompensuje astronomiczną wręcz skalowalnością (chociaż kto nie osiągnął limit requestów ADLS 20k/s w porządnym lakehouse niech pierwszy rzuci kamieniem) To GIGANTYCZNIE utrudnia realizację wielu optymalnych operacji typowych dla niskopoziomowego dostępu do danych. Oznacza to, że trudniej jest realizować optymalizacje specyficzne dla systemów dyskowych, takie jak np. operacje na stronach danych czy bezpośredni dostęp do fragmentów plików. Nadal więc istnieje wyzwanie związane z optymalizacją dostępu I/O na poziomie pojedynczych rekordów. Na dodatek, tradycyjne bazy danych relacyjne oferują zaawansowane mechanizmy indeksowania (np. B-tree, hash), które pozwalają na szybki dostęp do danych na podstawie kluczy lub wartości. Synapse pozwalał w niektórych sytuacjach na indeksowanie i budowę w oparciu o rowstore i clusterd/nonclustered. Snowflake poszedł w Iceberg dla danych, ale dla większej kompatybilności pomyślał też o Unistore (poczytajcie, też ciekawy temat). Wracając do databricks/fabric i delta lake.. Różne mechaniki optymalizacji są tam stosowane, takie jak tradycyjny i nowy (liquid) clustering, ordering (z-|v-), kompaktowanie (defragmentacja? :) ) itp. Ale to optymalizacje na zupełnie innych poziomach, które przegrywają z wydajnością poczciwych baz, co niekiedy mocno zaskakuje ludzi, którzy w rozwiązaniach chmurowych poszukują mega wydajności przy mega skalowalności.. A tymczasem pobranie kilku rekordoów bez sortowania i filtrowania wymaga długich sekund operacji. Trzeba zawsze poświęcić czasu i cierpliwości na wyjaśnienie czym ten świat się charakteryzuje i na jakie kompromisy to wszystko poszło. Spodziewam się, że w najbliższej przyszłości prace nad mechaniką tych platform pójdą w kierunku zdecydowanie większej wydajności i zapewnienia obsługi zapytań na poziomie atomowym (z czasem dostępu rzędu ms), tak jak wspomniane przykłady z Synapse i Snowflake. Coś na koniec. Dla mnie osobiście największy żal, który ściska za pośladki, związany jest z BACKUPami i zapewnieniem prawdziwym odtwarzalnym Disaster Recovery. Nawet jeśli ostatecznie MS wprowadzi Azure Backup dla ADLS (tak jak zamierza to zrobić z blob storage w trybie "snapshota" do wybranego storage), wciąż będzie brakowało możliwosći zrobienia !konsystentnego! backupu, taki jaki robiony jest w silnikach relacyjnych (np w MSSQL backup stron + zrzut z dziennika aby zrobic rollback lub rollforward). Na dodatek platforma uzależniona jest od wielu komponentów, do których podejście w odtwarzaniu może być kompletnie inne, sposób sparowania z dodatkowym regionem oparty na innych zasadach i często niemożliwym do przetestowania. Repliki active-passive są ciężkie w realizacji w kontekście całych infrastruktur i nie do końca opłacalne... Czy ktokolwiek z was zastanawiał się może, co się stanie z regionem sparowanym albo nawet availability zone, jeśli dojdzie do padu? Czy mamy gwarancję capacity? Wszyscy wiemy jak obciążone są WE i NE, nie bez powodu mamy opcję capacity reserveration, czy dla usług PaaS i SaaS też ona jest przewidziana natywnie od zaplecza...? No nie wiem :) No dobra, czy doczekamy się poprawy sytuacji? Mam nadzieję, że wszystkie stajnie spod znaku Big Data znajdą na to sposób, bo im więcej ludzi przesiada się z klasycznych hurtowni, gdzie byli przyzwyczajeni do wszystkich mechanizmów silników relacyjnych w swoich hurtowniach, tym więcej pojawia się głosów niezadowolenia i zmiany decyzji co do niektórych wdrożeń. Pozdrawiam i do następnego odcinka ;)