AWS ElastiCache / SimpleQueue vs DynamoDB

13

Zastanawiam się nad uzasadnieniem używania ElastiCache / SimpleQueue w porównaniu z posiadaniem tabel „Cache” i „Queue” odpowiednio w DynamoDB.

Wygląda na to, że opóźnienie sieci dla usług pamięci podręcznej / kolejki przyniosłoby znaczny wzrost wydajności, a EC2 traktuje Dynamo jako swoją usługę pamięci podręcznej / kolejki, oferując takie samo opóźnienie i przepustowość (ponieważ Dynamo pozwala na stałe niskie opóźnienie w dowolnym Załaduj).

Czy chodzi głównie o cenę dynamo w porównaniu do innych usług pod obciążeniem?

Czy ktoś ma jakieś przybliżone liczby opóźnień porównujące Dynamo z ElastiCache / SQS?

Czy brakuje mi innych ważniejszych uwag, które uzasadniają dodatkową złożoność?

Dzięki.

amazon-web-services amazon-elasticache amazon-dynamodb Scott Klarenbach
źródło

Odpowiedzi:

9

Używamy DynamoDB i ElastiCache Redis z różnych powodów.

DynamoDB:

  • Ma język zapytań, który jest w stanie wykonywać bardziej złożone rzeczy (większe niż między, itp.)
  • Jest osiągalny przez zewnętrzny interfejs internetowy API (różne regiony są osiągalne bez żadnych zmian lub własnej infrastruktury)
  • Możliwe są uprawnienia oparte na tabelach, a nawet wierszach
  • Skaluje pod względem wielkości danych do nieskończoności
  • Płacisz za żądanie -> niskie numery żądań oznaczają mniejsze rachunki, wysokie numery żądań oznaczają wyższe rachunki
  • Odczyty i zapisy różnią się kosztami
  • Dane są zapisywane jako nadmiarowe przez AWS w wielu obiektach
  • DynamoDB jest wysoce dostępny od razu po wyjęciu z pudełka
  • Automatyczne skalowanie jest dostępne w samej usłudze

ElastiCache Redis:

  • Prosty język zapytań - bez skomplikowanych funkcji
  • Jest (gotowy do użycia) nieosiągalny z innych regionów.
  • Zawsze jesteś ograniczony ilością pamięci (lub sumą wszystkich podstawowych instancji w klastrze)
  • Podział na wiele instancji jest możliwy tylko w Twojej aplikacji - Redis nic tutaj nie robi (klaster Redis tutaj pomaga, ale logika dzielenia jest nadal w sterowniku / SDK, którego używasz w aplikacji) - skalowanie i skalowanie obecnie nie jest możliwe bez przestoju
  • Płacisz za instancję, bez względu na obciążenie i liczbę żądań.
  • Jeśli chcesz nadmiarowości danych, musisz skonfigurować replikację (niemożliwe w różnych regionach)
  • Aby uzyskać wysoką dostępność, musisz użyć replik
  • Brak możliwości automatycznego skalowania (patrz część o braku skalowania w ogóle powyżej)

Nasza konfiguracja przez większość czasu to: Proste pamięci podręczne z dużą liczbą żądań w Redis wspierane przez DynamoDB jako trwałe i trwałe miejsce do przechowywania. Dzięki temu ograniczamy koszty, ponieważ otrzymujemy domyślną zniżkę na nasze odczyty dzięki modelowi Redis typu pay-per-instance, ale także czerpiemy korzyści z redundancji DynamoDB, a nawet jesteśmy w stanie używać języka zapytań DynamoDB do bardziej złożonych rzeczy ( jeśli będziemy tego potrzebować).

Mam nadzieję, że to pomaga!

Aktualizacja: Wraz z ogłoszeniem Amazon DynamoDB Accelerator ( https://aws.amazon.com/de/dynamodb/dax/ ) przełączamy się na używanie języka DAX w obecnej postaci (w końcu) dokładnie to, co robiliśmy z połączenie DynamoDB i Redis. Ponieważ DAX jest w pełni zarządzany przez AWS i daje nam szansę zawsze używać języka DynamoDB w naszej aplikacji, ale także czerpać korzyści z pamięci podręcznej zapisu, takiej jak Redis.

Osterjour
źródło
Bardzo pomocny, dzięki. Nie rozumiem, w jaki sposób tworzysz kopie zapasowe za pomocą dynamodb: czy jest to funkcja AWS? lub kiedy i jak utworzysz kopię zapasową? Dziękuję, jeśli możesz to wyjaśnić!
badera
Moje „wspierane przez” nie jest rozumiane jako kopia zapasowa w tradycyjny sposób. W rzeczywistości cały czas piszemy do DynamoDB i używamy Redis do czytania w pierwszej kolejności. Więc nawet jeśli Redis straci dane, mamy to w DynamoDB dostępne. Dzięki wykorzystaniu DAX ( aws.amazon.com/de/dynamodb/dax ) ten przypadek użycia stał się teraz znacznie łatwiejszy!
Osterjour,
7

Głównym powodem, dla którego używamy Elasticache zamiast DynamoDB, jest prędkość - dla małych obiektów dostajesz opóźnienie w obie strony poniżej 1ms. Pudełko jest naprawdę blisko komputera EC2, a pamięć jest o wiele szybsza niż dysk, nawet dysk SSD.

Przy różnych modelach cenowych może być także korzyść kosztowa, chociaż nie opisałem tam zbyt wielu szczegółów.

Maksymilian
źródło
Czy to wciąż aktualne? Czy DAX tego nie zmienił?
dmigo
1
DAX rozwiąże wiele problemów z opóźnieniami, tak. Nie jestem pewien dokładnych różnic prędkości - w przypadku małych obiektów sieć będzie głównym czynnikiem opóźniającym.
Maximilian
1

Redis / memcached są magazynami w pamięci i zazwyczaj powinny być szybsze niż DynamoDB dla danych typu pamięci podręcznej / kolejki. Mają także przydatne dodatkowe przedmioty, takie jak wygasające klucze, Pub / Sub w Redis itp., Których Dynamo może nie mieć.

ceejayoz
źródło
1
Dzięki. Zdaję sobie sprawę, że pamięć podręczna jest w pamięci, ale przeczytałem, że można spodziewać się, że minie ok. 10 ms, aby trafić do pamięci podręcznej i wrócić, co czyni charakterystyki wydajności takie same jak Dynamo. Myślę, że masz rację, że możesz chcieć, aby określone funkcje w memcached nie były dostępne w dynamo. Ale dla mnie główną zaletą pamięci podręcznej RAM jest wzrost wydajności rzędu rzędów wielkości w porównaniu z trwałym sklepem, który nie wydaje się mieć tutaj zastosowania.
Scott Klarenbach,