DynamoDB vs MongoDB NoSQL [zamknięte]

172

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.

Kuba Rozpruwacz
źródło
3
Jeśli potrzebujesz porady na temat struktury zapytań, proponuję podać przykład swojego schematu wraz z przypadkami użycia dostępu do danych. Bez nich trudno jest orzekać co do możliwości.
James Wahlin
Rzeczywiście, sposób odpytywania danych może dramatycznie wpłynąć na wybór bazy danych zaplecza. Jak hierarchiczna byłaby moja pierwsza kwestia.
zanlok
3
Dziwię się, że to pytanie nie zostało już zamknięte przez ranking osób SO. Zazwyczaj pytania, które wymagają porady, są zamykane, ponieważ nie proszą o pomoc w bardzo konkretnym problemie.
LS

Odpowiedzi:

67

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

Mason Zhang
źródło
dziękuję za zamieszczenie tutaj twoich artykułów, które pomogły mi uzyskać jaśniejszą wizję i to z pewnością pomoże mi do czasu, gdy podejmę decyzję
jack.the.ripper
1
czytając trzy powody, dla których powinieneś używać dynamo zamiast mongo, jest firma, która oferuje zarządzaną usługę, która jest droższa w porównaniu do dynamoDB, ale można to wziąć pod uwagę, jeśli nie masz osoby odpowiedzialnej za konserwację nosql , nazwa firmy to mongoLab
jack.the.ripper
2
@ Pedro Wielkie dzięki za przypomnienie. Może używam MongoDB w nieefektywny sposób. Mam 1,4 miliona płyt i zajmuję dysk 8G, ale po przeniesieniu do DynamoDB zajmuję tylko 300M miejsca. Mogę potrzebować testu i zobaczyć, jaka będzie pamięć, jeśli przeniosę te dane do MongoLab :)
Mason Zhang
1
Czy linki są zepsute?
fedorqui 'SO przestań szkodzić'
@MasonZhang Bardzo interesujące będzie zobaczenie, jaka jest pamięć, jeśli migrujesz te dane do MongoLab.
fuiiii
164

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.

CargoMeister
źródło
35
Jeśli trzeba porównać bazę danych z bazą danych, należy porównać tylko cechy bazy danych. Rozwiązanie hostowane nie jest funkcją bazy danych. Jeśli szukasz hostowanej bazy danych MongoDB, wybierz MongoHQ, a oni wykonują wszystkie podstawowe prace, których możesz chcieć uniknąć, koncentrując się na podstawowej pracy.
Kabeer
12
To prawda, chociaż wstępne porównanie kosztów pokazało, że dynamo to całkiem niezła oferta. Innym problemem jest to, że jeśli musisz zwiększyć / zmniejszyć rozmiar dynamo, jest to kliknięcie przycisku. Jeśli musisz dodać dysk lub zmienić rozmiar serwera mongo, wiąże się to z przestojem, niezależnie od tego, czy musisz to zrobić, czy ktoś inny.
CargoMeister
@Kabeer Technicznie w 100% zgadzam się z tobą, ale w prawdziwym świecie cały pakiet ma znaczenie dla podjęcia decyzji biznesowej. Ostatecznie jest to decyzja biznesowa.
poitroae
59

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.

Derick
źródło
tak, moja troska burmistrza dotyczy zwiększenia skali i utrzymania w czasie, aby być szczerym osobiście. Uważam, że mongoDB może wykonać pracę, o której właśnie myślę w kategoriach średnio- i długoterminowej konserwacji
jack.the.ripper
10
Derick, kolejnym ważnym czynnikiem wpływającym na skalę jest wykorzystanie, a nie tylko liczba dokumentów czy rozmiar bazy danych. @jack nie "czuje", ale polega na testowaniu, w tym na platformie i sprzęcie końcowego wdrożenia; tydzień spędzony na wypychaniu danych i testach porównawczych kilku wariantów db powinien prowadzić do świadomych decyzji, które oszczędzą wiele bólu.
zanlok
3
Zapewnienie profesjonalnego produktu / usługi wykracza daleko poza proste rozwiązanie typu „to może to zrobić”. Tylko dlatego, że tania maszyna może obsługiwać Linuksa, MongoDB i miliony rekordów za prawie żadne pieniądze, nie oznacza doskonałej wydajności w prawdziwym świecie. 500 tys. Rekordów (ze schematem PROSTYM) byłoby prawdopodobnie dobrym kandydatem do DynamoDB po prostu dlatego, że OP nie miałby kosztów utrzymania (przynajmniej dla sprzętu), a miesięczna opłata byłaby prawdopodobnie znacznie niższa niż koszt serwera w trakcie rok lub dwa.
cbmeeks
21

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

AnneTheAgile
źródło
2
dzięki za link! Nigdy wcześniej nie byłem na db-engines.com. Świetna strona!
Tom Hert
16

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.

Deemoe
źródło
Naprawdę powinieneś sprawdzić, jak łatwo jest zintegrować wyszukiwanie w chmurze ze strumieniami dynamodb i lambda, aby uzyskać pełny tekst lub zapytania oparte na lokalizacji.
MrTJ
4
Wybierz bazę danych zgodnie ze swoimi potrzebami. Nie jest to wybór między SQL a noSQL, ale między DB zorientowaną na dokumenty, DB zorientowaną na wykresy, DB z kluczami i wartością, RDMBS ... Nie ma złotego wyboru, a SQL z pewnością nie.
vcarel
14

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 ":" [email protected] "}. 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.

Steffan Perry
źródło
9

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.

Rahul Kumar
źródło
1
A połączenie Redis i MongoDB? Myślę, że to niesamowite.
ismaestro
Wydaje mi się, że tak, nie mam doświadczenia z Redisem, ale z pewnością jest on szeroko stosowany ze względu na jego wydajność, w pamięciowych DB prawie zawsze działa lepiej niż DB oparte na dyskach. Dlatego myślę, że dane, do których dostęp jest potrzebny przy ogromnym zapotrzebowaniu i wysokiej częstotliwości, powinny trafiać do Redis. Z drugiej strony w przypadku dużych, letargicznych danych należy używać MongoDB.
Rahul Kumar
7

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.

AndrewSouthpaw
źródło