Używam MySQL od jakiegoś czasu i czuję się komfortowo z jego strukturą, zapytaniami SQL itp.
Obecnie buduję nowy system w AWS i patrzyłem na DynamoDB. Obecnie niewiele o tym wiem.
Czy jeden jest lepszy od drugiego?
Jakie są zalety DynamoDB?
jak wygląda przejście z zapytań MySQL itp. do tej płaskiej bazy danych?
Odpowiedzi:
Możesz przeczytać wyjaśnienie AWS na ten temat tutaj .
Krótko mówiąc, jeśli masz głównie zapytania Lookup (a nie zapytania Join), DynamoDB (i inne bazy danych NoSQL) jest lepsze. Jeśli potrzebujesz obsługiwać dużo danych , będziesz ograniczony podczas korzystania z MySQL (i innych RDBMS).
Nie możesz ponownie używać zapytań MySQL ani schematu danych, ale jeśli poświęcisz wysiłek na naukę NoSQL, dodasz ważne narzędzie do swojego zestawu narzędzi. Istnieje wiele przypadków, w których DynamoDB daje najprostsze rozwiązanie.
Naprawdę DynamoDB i MySQL to jabłka i pomarańcze. DynamoDB to warstwa pamięci NoSQL, podczas gdy MySQL jest używany do przechowywania relacyjnego. Powinieneś wybrać, czego chcesz użyć, na podstawie rzeczywistych potrzeb aplikacji. W rzeczywistości niektóre aplikacje mogą być dobrze obsługiwane przy użyciu obu.
Jeśli, na przykład, przechowujesz dane, które nie nadają się dobrze do schematu relacyjnego (struktury drzewa, reprezentacje JSON bez schematu itp.), Które można porównać z pojedynczym kluczem lub kombinacją klucz / zakres, wówczas DynamoDB ( lub inny sklep NoSQL) byłby prawdopodobnie najlepszym rozwiązaniem.
Jeśli masz dobrze zdefiniowany schemat danych, który może dobrze pasować do struktury relacyjnej i potrzebujesz elastyczności w wyszukiwaniu danych na wiele różnych sposobów (oczywiście dodając indeksy w razie potrzeby), RDS może być lepszym rozwiązaniem .
Główną korzyścią z używania DynamoDB jako magazynu NoSQL jest to, że masz gwarantowaną przepustowość odczytu / zapisu na dowolnym wymaganym poziomie bez martwienia się o zarządzanie magazynem danych w klastrze. Więc jeśli Twoja aplikacja wymaga 1000 odczytów / zapisów na sekundę, możesz po prostu udostępnić swoją tabelę DynamoDB dla tego poziomu przepustowości i tak naprawdę nie musisz się martwić o podstawową infrastrukturę.
RDS ma taką samą korzyść, że nie musisz martwić się o samą infrastrukturę, jednak jeśli w końcu będziesz musiał wykonać znaczną liczbę zapisów do punktu, w którym największy rozmiar instancji nie będzie już nadążał, pozostaniesz bez opcje (można skalować w poziomie dla odczytów przy użyciu replik do odczytu).
Zaktualizowana uwaga: DynamoDb obsługuje teraz globalne indeksowanie pomocnicze, więc masz teraz możliwość wykonywania zoptymalizowanych wyszukiwań w polach danych innych niż hash lub kombinacja kluczy hash i range.
Właśnie dokonaliśmy migracji wszystkich naszych tabel DynamoDB do RDS MySQL.
Chociaż używanie DynamoDB do określonych zadań może mieć sens, zbudowanie nowego systemu na bazie DynamoDB jest naprawdę złym pomysłem. Najlepiej ułożone plany itp., Zawsze potrzebujesz dodatkowej elastyczności od swojej bazy danych.
Oto powody, dla których przenieśliśmy się z DynamoDB:
Teraz używamy DynamoDB jako kopii zapasowej dla niektórych systemów i jestem pewien, że będziemy go używać w przyszłości do konkretnych, dobrze zdefiniowanych zadań. To nie jest zła baza danych, po prostu nie jest to baza danych obsługująca 100% podstawowego systemu.
Jeśli chodzi o zalety, powiedziałbym, że skalowalność i trwałość. Skaluje się niesamowicie i przejrzyście i jest (jakby) zawsze w górę. To naprawdę świetne funkcje, ale w żaden sposób nie rekompensują ich wad.
Korzystając z DynamoDB, powinieneś również wiedzieć, że pozycje / rekordy w DynamoDB są ograniczone do 400KB (patrz Limity DynamoDB ). W wielu przypadkach to nie zadziała. Więc DynamoDB będzie dobre do kilku rzeczy, ale nie do wszystkich. To samo dotyczy wielu innych baz danych NoSQL.