DynamoDB vs MongoDB NoSQL [zamknięte]

Próbuję dowiedzieć się, czego mogę użyć w przyszłym projekcie, planujemy przechowywać od około 500 tys. Rekordów miesięcznie w pierwszym roku, a może więcej przez następne lata. Jest to aplikacja pionowa, więc nie ma potrzeby używania bazy danych do tego, dlatego zdecydowałem się na przechowywanie danych noSQL.

Pierwszą opcją, która przyszła mi do głowy, była mongo db, ponieważ jest to bardzo dojrzały produkt z dużym wsparciem społeczności, ale z drugiej strony otrzymaliśmy zupełnie nowy produkt, który oferuje zarządzaną usługę o najwyższej wydajności, opracuję to aplikacji, ale nie ma planu konserwacji (przynajmniej na razie), więc myślę, że będzie to ogromna zaleta, ponieważ amazon zapewnia elastyczny sposób skalowania.

Moim głównym zmartwieniem jest struktura zapytań, nie patrzyłem jeszcze na możliwości zapytań dynamoDB, ale ponieważ jest to magazyn danych ak / v, uważam, że może to być bardziej ograniczone niż mongo db.

Jeśli ktoś miał doświadczenie w przenoszeniu projektu z mongoDB do DynamoDB, każda rada zostanie w pełni doceniona.

Niedawno przeprowadziłem migrację mojej MongoDB do DynamoDB i napisałem 3 blogi, aby podzielić się doświadczeniami i danymi dotyczącymi wydajności i kosztów.

Migracja z MongoDB do AWS DynamoDB + SimpleDB

7 powodów, dla których warto używać MongoDB zamiast DynamoDB

3 powody, dla których powinieneś używać DynamoDB zamiast MongoDB

Wiem, że to jest stare, ale nadal pojawia się, gdy szukasz porównania. Używaliśmy Mongo, prawie całkowicie przenieśliśmy się do Dynamo, które jest teraz naszym pierwszym wyborem. Nie dlatego, że ma więcej funkcji, tak nie jest. Mongo ma lepszy język zapytań, możesz indeksować w strukturze, jest wiele drobiazgów. Wyższość Dynamo tkwi w tym, co OP stwierdził w swoim komentarzu: to łatwe. Nie musisz dbać o żadne serwery. Kiedy zaczynasz konfigurować rozwiązanie oparte na fragmentach Mongo, sprawa się komplikuje. Możesz udać się do jednej z firm hostingowych, ale to też nie jest tanie. W przypadku Dynamo, jeśli potrzebujesz większej przepustowości, po prostu kliknij przycisk. Możesz pisać skrypty do automatycznego skalowania. Kiedy nadejdzie czas na ulepszenie Dynamo, zrobisz to za Ciebie. To dużo cennego stresu i nie spędzonego czasu. Jeśli nie

Więc teraz domyślnie korzystamy z Dynamo. Może Mongo, jeśli struktura danych jest na tyle skomplikowana, że ​​to uzasadnia, ale wtedy prawdopodobnie wrócilibyśmy do bazy danych SQL. Dynamo jest tępe, naprawdę musisz pomyśleć o tym, jak go zbudujesz, i prawdopodobnie użyjesz Redis w Elasticcache, aby działało dla złożonych rzeczy. Ale na pewno miło jest nie musieć się tym zajmować. Ty kodujesz. Otóż ​​to.

Z dokumentami o wartości 500 tys. Nie ma żadnego powodu do skalowania. Typowy laptop z dyskiem SSD i 8 GB pamięci RAM może z łatwością wykonać 10 milionów rekordów, więc jeśli próbujesz wybrać ze względu na skalowanie, Twój wybór tak naprawdę nie ma znaczenia. Sugerowałbym, abyś wybrał to, co najbardziej Ci się podoba, i być może tam, gdzie znajdziesz najbardziej pomoc online.

Jeśli chodzi o szybkie porównania przeglądowe, bardzo podoba mi się ta witryna, która ma wiele stron porównawczych, np. AWS DynamoDB vs MongoDB; http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB

Krótka odpowiedź: Zacznij od SQL i dodawaj NoSQL tylko wtedy, gdy jest to konieczne. (chyba że nie potrzebujesz niczego poza bardzo prostymi zapytaniami)

Moje osobiste doświadczenie: nie używałem MongoDB do zapytań, ale od kwietnia 2015 DynamoDB jest nadal bardzo ułomny, jeśli chodzi o wszystko poza najbardziej podstawowymi zapytaniami klucz / wartość. Uwielbiam to za podstawowe rzeczy, ale jeśli potrzebujesz języka zapytań, spójrz na prawdziwe rozwiązanie bazy danych SQL.

W DynamoDB możesz wykonywać zapytania dotyczące skrótu lub klucza skrótu i ​​zakresu, a także możesz mieć wiele pomocniczych indeksów globalnych. Robię zapytania na pojedynczej tabeli z 4 możliwymi parametrami filtru i sortuję wyniki, jest to obsługiwane (ledwo) przez użycie globalnych indeksów pomocniczych z wyrażeniami filtrującymi. Problem pojawia się, gdy próbujesz uzyskać wszystkie wyniki pasujące do filtra, nie możesz po prostu wyszukać pierwszych 10 pozycji pasujących do filtra, ale raczej sprawdza 10 pozycji i możesz otrzymać 0 prawidłowych wyników, zmuszając Cię do ponownego skanowanie za pomocą klawisza kontynuacji - ból w karku i pochłanianie zbyt dużej ilości odczytu tabeli dla prostego scenariusza.

Mówiąc konkretnie o problemie z limitami filtrów w zapytaniu, jest to z dokumentacji ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ):

W odpowiedzi DynamoDB zwraca wszystkie zgodne wyniki
zakres wartości granicznej. Na przykład, jeśli wydasz zapytanie
lub żądanie skanowania z wartością graniczną 6 i bez filtra
wyrażenie, operacja zwraca pierwszych sześć elementów z pliku 
tabela pasująca do parametrów żądania. Jeśli podasz również plik
FilterExpression, operacja zwraca elementy w ramach 
pierwszych sześć pozycji w tabeli, które odpowiadają wymaganiom filtra.

Mój wniosek jest taki, że zapytania obejmujące FilterExpressions są użyteczne tylko w bardzo rzadkich przypadkach i nie są skalowalne, ponieważ każde zapytanie może z łatwością odczytać większość lub całą tabelę, która zużywa zbyt wiele jednostek odczytu DynamoDB. Gdy użyjesz zbyt wielu jednostek odczytu, zostaniesz dławiony i zobaczysz słabą wydajność.

Opinia eksperta: Na szczycie AWS 9 kwietnia 2015 r. Brett Hollman, menedżer ds. Architektury rozwiązań, AWS w swoim wystąpieniu na temat docierania do pierwszych 10 milionów zwolenników użytkowników, zaczynając od bazy danych SQL, a następnie używaj NoSQL tylko wtedy, gdy ma to sens. Ponieważ wcześniej czy później prawdopodobnie będziesz potrzebować serwera SQL gdzieś w swoim stosie. Jego slajdy są tutaj: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users Zobacz slajd 28.

Wybraliśmy połączenie Mongo / Dynamo na produkt medyczny. Zasadniczo mongo pozwala na lepsze wyszukiwanie, ale hostowane Dynamo jest świetne, ponieważ jest zgodne z HIPAA bez dodatkowej pracy. Więc hostujemy część mongo bez danych osobowych w standardowej konfiguracji i pozwalamy amazonowi zająć się częścią HIPAA w zakresie infrastruktury. Możemy zapytać o pewne pozycje z mongo, które przywołują dokumenty ze wskaźnikami (identyfikatorami) powiązanego dokumentu Dynamo.

Głównym powodem, dla którego zdecydowaliśmy się to zrobić przy użyciu mongo zamiast hostowania całej aplikacji na dynamo, były dwa powody. Po pierwsze, musieliśmy przeprowadzić wyszukiwanie w oparciu o lokalizację, w której mongo świetnie się sprawdza, a Dynamo nie było w tamtym czasie, ale teraz mają taką opcję.

Po drugie, niektóre dokumenty były nieustrukturyzowane i nie wiedzieliśmy wcześniej, jakie będą dane, więc na przykład powiedzmy, że użytkownik wprowadza dokument do kolekcji "form" w następujący sposób: {"nazwa użytkownika": "użytkownik1", " email ":" me@me.com "}. Inny użytkownik umieszcza to w tej samej kolekcji {"phone": "813-555-3333", "location": [28.1234, -83.2342]}. Dzięki mongo możemy przeszukiwać dowolne z tych dynamicznych i nieznanych pól w dowolnym momencie, z Dynamo możesz to zrobić, ale za każdym razem, gdy zostanie dodane nowe pole, które chcesz przeszukiwać, będziesz musiał tworzyć indeks. Więc jeśli nigdy wcześniej nie miałeś pola telefonu w swoim dokumencie Dynamo, a potem nagle, ktoś je dodaje, jest to całkowicie niemożliwe do przeszukania.

Teraz pojawia się inny punkt, o którym wspomniałeś. Czasami wybór odpowiedniego rozwiązania do pracy nie zawsze oznacza wybór najlepszego produktu do pracy. Na przykład możesz mieć klienta, który potrzebuje i będzie korzystał z systemu, który stworzyłeś przez ponad 10 lat. Wybór rozwiązania SaaS / IaaS, które jest wystarczająco dobre, aby wykonać zadanie, może być lepszą opcją, ponieważ możesz polegać na amazon, że będzie utrzymywał i utrzymywał swoje systemy przez długi czas.

Pracowałem nad obydwoma i jestem ich fanem.

Ale musisz wiedzieć, kiedy i w jakim celu użyć.

Myślę, że przeniesienie całej bazy danych do DynamoDB nie jest dobrym pomysłem, ponieważ wykonywanie zapytań jest trudne, z wyjątkiem kluczy głównych i pomocniczych, indeksowanie jest ograniczone, a skanowanie w DynamoDB jest bolesne.

Wybrałbym hybrydowy rodzaj bazy danych, w której powinny znajdować się obszerne dane umożliwiające zapytania, czyli MongoDB, z całą jego funkcją, której nigdy nie czułbyś zmuszony do wprowadzania ulepszeń lub modyfikacji.

DynamoDB działa błyskawicznie (szybciej niż MongoDB), więc DynamoDB jest często używane jako alternatywa dla sesji w skalowalnych aplikacjach. Najlepsze praktyki DynamoDB sugerują również, że jeśli jest dużo danych, które są rzadziej używane, przenieś je do innej tabeli.

Załóżmy więc, że masz artykuły lub kanały. Ludzie chętniej szukają rzeczy z zeszłego tygodnia lub z tego miesiąca. szanse na przeglądanie danych sprzed dwóch lat są naprawdę rzadkie. W tym celu DynamoDB preferuje przechowywanie danych według miesięcy lub lat w różnych tabelach.

DynamoDB jest pozornie skalowalne, co będziesz musiał zrobić ręcznie w MongoDB. jednak stracisz na wydajności DynamoDB, jeśli nie rozumiesz partycji przepływności i jak działa skalowanie za kulisami.

DynamoDB powinno być używane tam, gdzie szybkość jest krytyczna, MongoDB z drugiej strony ma zbyt wiele rąk i funkcji, czego brakuje DynamoDB.

na przykład możesz mieć zestaw replik MongoDB w taki sposób, aby jedna z replik przechowała instancję danych sprzed 8 (lub cokolwiek) godzin. Naprawdę przydatne, jeśli zepsułeś coś ważnego w swojej bazie danych i chcesz uzyskać dane tak, jak było wcześniej.

Taka jest jednak moja opinia.

Pamiętaj, że eksperymentowałem tylko z MongoDB ...

Z tego, co przeczytałem, DynamoDB przeszedł długą drogę pod względem funkcji. Kiedyś był to superpodstawowy magazyn wartości klucza z bardzo ograniczonymi możliwościami przechowywania i zapytań. Od tego czasu się rozrósł, obsługując teraz większe rozmiary dokumentów + obsługę JSON i globalne indeksy wtórne . Różnica między tym, co oferuje DynamoDB i MongoDB pod względem funkcji, zmniejsza się z każdym miesiącem. Nowe funkcje DynamoDB są tutaj rozszerzone .

Wiele porównań MongoDB i DynamoDB jest nieaktualnych z powodu niedawnego dodania funkcji DynamoDB. Jednak ten post oferuje kilka innych przekonujących punktów do wyboru DynamoDB, a mianowicie to, że jest prosty, tani w utrzymaniu i często tani. Inna dyskusja na temat wyboru bazy danych była interesująca do przeczytania, choć nieco stara.

Mój wniosek: jeśli wykonujesz poważne zapytania do bazy danych lub pracujesz w językach nieobsługiwanych przez DynamoDB, użyj MongoDB. W przeciwnym razie trzymaj się DynamoDB.