AWS ElastiCache / SimpleQueue vs DynamoDB

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.

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.

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.

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ć.