Teams sometimes need lower latency, lower costs (especially as they scale) or the ability to run their applications somewhere other than AWS. Łatwo jest zrozumieć, dlaczego tak wiele zespołów zwróciło się do Amazon DynamoDB od czasu wprowadzenia go w 2012 roku. Łatwo jest zacząć, zwłaszcza jeśli Twoja organizacja jest już zakorzeniona w ekosystemie AWS. Jest stosunkowo szybki i skalowalny, z niską krzywą uczenia się. Jednak w miarę upływu czasu pojawiają się wady, zwłaszcza w miarę ewolucji obciążeń roboczych i wymagań biznesowych. zespoły czasami potrzebują mniejszej opóźnienia, niższych kosztów (zwłaszcza w miarę ich skalowania) lub możliwości uruchamiania aplikacji w innym miejscu niż AWS. Przyjrzyjmy się wyzwaniom, które skłoniły trzy zespoły do opuszczenia DynamoDB. Elastyczność w chmurze i oszczędności kosztów Yieldmo jest platformą reklamową online, która łączy wydawców i reklamodawców w czasie rzeczywistym za pomocą systemu opartego na aukcjach, zoptymalizowanego z ML. Ich działalność opiera się na dostarczaniu reklam szybko (w ciągu 200-300 milisekund) i efektywnie, co wymaga ultra-szybkich, wysoce wydajnych wyszukiwań baz danych w skali. Początkowo zbudowali platformę na DynamoDB. Jednak podczas gdy DynamoDB był niezawodny, po ich wzroście pojawiły się znaczące ograniczenia. Jak wyjaśnił Todd Coleman, współzałożyciel techniczny i główny architekt, ich główne obawy były podwójne: eskalacja kosztów i ograniczenia geograficzne. Badając alternatywy dla DynamoDB, mieli nadzieję znaleźć opcję, która utrzyma prędkość, skalowalność i niezawodność, jednocześnie obniżając koszty i zapewniając niezależność dostawców chmury. Yieldmo najpierw rozważył pozostanie z DynamoDB i dodanie warstwy pamięci podręcznej. Jednak pamięć podręczna nie mogła rozwiązać problemu z geograficznym opóźnieniem. Eksplorowali również Aerospike, który oferował wsparcie prędkości i cross-cloud. Jednak indeksowanie w pamięci Aerospike wymagałoby ogromnego i kosztownego klastra do obsługi dużej liczby małych obiektów danych Yieldmo. Następnie odkryli ScyllaDB. A kompatybilny z DynamoDB API (Alternator) ScyllaDB był zmianą gry. Todd wyjaśnił: „ScyllaDB obsługiwało wdrożenia w chmurze, wymagało obsługiwalnej liczby serwerów i oferowało konkurencyjne koszty. Najlepiej, że jego API było zgodne z DynamoDB, co oznacza, że mogliśmy migrować z minimalnymi zmianami kodu. Proces migracji został starannie zaplanowany, wykorzystując istniejącą architekturę kolejki wiadomości Kafki w celu zapewnienia integralności danych. Przeprowadzili dwa testy proof-of-concept (POC): najpierw z jedną tabelą 28 miliardów obiektów, a następnie we wszystkich pięciu regionach AWS. Wyniki były imponujące. Todd podzielił się, „Nasze koszty bazy danych zostały obniżone o połowę, nawet przy wycenie zastrzeżonej mocy DynamoDB.” A poza oszczędnościami kosztów, Yieldmo zyskało elastyczność, aby potencjalnie wdrażać w różnych dostawcach chmur. Ich opóźnienie uległo poprawie, a ScyllaDB było tak proste do obsługi, jak DynamoDB. Podsumowując, Todd stwierdził: „Jednym z naszych początkowych obaw było odwrócenie się od udowodnionej niezawodności DynamoDB. Jednak ScyllaDB był doskonałym partnerem. Ich zespół zapewnia monitorowanie naszych klastrów, ostrzega nas o potencjalnych problemach i doradza nam, kiedy skalowanie jest konieczne pod względem ciągłej konserwacji. Doświadczenie było porównywalne z DynamoDB, ale z większą niezależnością i znaczną oszczędnością kosztów.” Posłuchaj Yieldmo Migracja do GCP z lepszą wydajnością i niższymi kosztami Digital Turbine, główny gracz w technologii reklam mobilnych z rocznym przychodem w wysokości 500 milionów dolarów, stał w obliczu rosnących wyzwań związanych z wdrażaniem DynamoDB. "Może to być trochę drogie, gdy skalujesz, aby być szczerym" - wyjaśnił Joseph Shorter, wiceprezes ds. Architektury Platform w Digital Turbine. „Znalazłyśmy pewne problemy z wydajnością. Robiliśmy mnóstwo odczytów – 90% wszystkich interakcji z DynamoDB było operacjami odczytu. Głównym problemem, według Shorter, było „Jak możemy migrować bez radykalnego refaktorowania naszej platformy, zachowując przynajmniej tę samą wydajność i wartość – i unikając sytuacji awarii? Po ocenieniu kilku opcji, Digital Turbine przeniósł się do ScyllaDB i osiągnął natychmiastowe ulepszenia. "Różnica kosztów 20% - to duża liczba, bez względu na to, o czym mówisz" - zauważył Shorter. "A kiedy rozważysz nasze plany dalszej skalowania, staje się to jeszcze bardziej znaczące." Oprócz oszczędności kosztów, okazało się, że „tylko korzystają z klastrów ScyllaDB”, sugerując jeszcze większy wzrost bez proporcjonalnego wzrostu kosztów. Słuchaj z cyfrowej turbiny Wysoka przepustowość pisania z niskim opóźnieniem i niższymi kosztami Zespół User State and Customizations dla jednej z największych na świecie usług streamingowych wykorzystuje DynamoDB od kilku lat. Podczas przebudowy dwóch istniejących przypadków użycia zastanawiali się, czy nadszedł czas na zmianę bazy danych. Pause / resume: Jeśli użytkownik ogląda program i zatrzymuje go, może odebrać miejsce, w którym się zatrzymał - na dowolnym urządzeniu, z dowolnego miejsca. Stan oglądania: Używając tych samych danych, określ, czy użytkownik oglądał program. Oto prosty diagram architektury: Co 30 sekund klient wysyła uderzenia serca z zaktualizowaną pozycją głowy odtwarzania programu, a następnie wysyła te zdarzenia do bazy danych. Rurociąg Edge ładuje wydarzenia w tym samym regionie co użytkownik, podczas gdy rurociąg Autoryzacja (Auth) łączy wydarzenia dla wszystkich pięciu regionów obsługiwanych przez firmę. Dwa główne wymagania techniczne dla wspierania tej architektury były: Aby zapewnić doskonałe doświadczenie użytkownika, system musiał pozostać wysoce dostępny, z niskimi odczytami opóźnień i możliwością skalowania w oparciu o ruch. Aby uniknąć rozległej konfiguracji infrastruktury lub pracy DBA, potrzebna była łatwa integracja z usługami AWS. Po sprawdzeniu tych pudełek zespół miał również nadzieję na zmniejszenie ogólnych kosztów. "Nasza istniejąca infrastruktura miała dane rozsiane po różnych klastrach DynamoDB i Elasticache, więc naprawdę chcieliśmy czegoś prostego, co mogłoby je połączyć w znacznie niższy system kosztów" - wyjaśnił ich inżynier. W szczególności potrzebna jest baza danych z: Wsparcie dla wielu regionów, ponieważ usługa była popularna w pięciu głównych regionach geograficznych. Aktualizacje nie miały ścisłej umowy na poziomie usług (SLA), ale system musiał wykonywać aktualizacje warunkowe w oparciu o znaczniki czasu zdarzeń. Możliwość obsługi ponad 78K odczytów na sekundę z opóźnieniem P99 od 10 do 20 milisekund. przypadek użycia obejmował tylko proste zapytania punktowe; rzeczy takie jak indeksy, partycjonowanie i skomplikowane wzorce zapytań nie były głównym problemem. Około 10 TB danych z możliwością rozwoju. Według ich inżyniera backendowego, „DynamoDB mogłoby doskonale obsługiwać nasze wymagania techniczne. ale biorąc pod uwagę nasz rozmiar danych i wysoką przepustowość, kontynuacja korzystania z DynamoDB byłaby jak wrzucanie pieniędzy do ognia”. W oparciu o ich wymagania dotyczące wydajności pisania i kosztów, postanowili zbadać ScyllaDB. Aby udowodnić koncepcję, założyli klastr testowy ScyllaDB Cloud z sześcioma węzłami AWS i4i 4xlarge i załadowali klastr z 3 miliardami rekordów. Wykonali łączne obciążenia 170K zapisów na sekundę i 78K odczytów na sekundę. Te niskie opóźnienia, w połączeniu z znaczną oszczędnością kosztów (ponad 50%), przekonały ich do opuszczenia DynamoDB. Oprócz niższych opóźnień przy niższych kosztach, zespół docenił również następujące aspekty ScyllaDB: Konstrukcja ScyllaDB koncentrująca się na wydajności (budowana w oparciu o ramy Seastar, wykorzystująca C++, świadoma NUMA, oferująca sterowniki nieświadome itp.) pomaga zespołowi zmniejszyć czas i koszty konserwacji. Zwiększona strategia kompaktowania pomaga im znacząco zmniejszyć wzmocnienie pisania. Elastyczny poziom spójności i czynniki replikacji pomagają im obsługiwać oddzielne rurociągi Auth i Edge. Na przykład Auth używa spójności kworum, podczas gdy Edge używa poziomu spójności „1” ze względu na powielanie danych i wysoką przepustowość. Ich inżynier końcowy stwierdził: „Wybór bazy danych jest trudny. Musisz wziąć pod uwagę nie tylko funkcje, ale także koszty. „W naszym przypadku, ze względu na wysokie wymagania dotyczące przepustowości i opóźnienia, bezserwerowy DynamoDB nie był dobrym rozwiązaniem.Nie lekceważ również roli sprzętu. Dowiedz się więcej Twój zespół jest następny? Jeśli Twój zespół rozważa , do eksplorowania. Zarejestruj się dla aby porozmawiać więcej o przypadku użytkowania, SLA, wymaganiach technicznych i tym, co masz nadzieję zoptymalizować. powiadomimy Cię, czy ScyllaDB jest dobrym rozwiązaniem i, jeśli tak, co migracja może oznaczać pod względem zmian w aplikacji, modelowania danych, infrastruktury itp. Przejście z DynamoDB ScyllaDB może być opcją Konsultacje techniczne Bonus: Oto krótki przegląd tego, jak ScyllaDB porównuje się do DynamoDB: Napisane przez • : Guilherme da Silva Nogueira i - Felipe Cardeneti Mendes . Napisane przez Guilherme da Silva Nogueira - Felipe Cardeneti Mendes
