DynamoDB kontra MongoDB NoSQL

Question

Próbuję go rozgryźć, co mogę wykorzystać do przyszłego projektu, planujemy przechowywać około 500 000 rekordów miesięcznie w pierwszym roku, a może więcej na następne lata to aplikacja pionowa więc nie ma potrzeby korzystania z bazy danych, dlatego zdecydowałem się wybrać pamięć masową noSQL.

Pierwsza opcja, która przyszła mi do głowy to mongo db, ponieważ jest to bardzo dojrzały produkt z dużym wsparciem ze strony społeczności, ale z drugiej strony mamy zupełnie nowy produkt, który oferuje usługę zarządzaną przy najwyższej wydajności, I Rozwiążę tę apelację, 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.

Moja główna troska dotyczy struktury zapytań, nie analizowałem jeszcze możliwości zapytań dynamoDB, ale ponieważ jest to przechowywanie danych w k/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, wszelkie porady zostaną całkowicie docenione.

Answer 1

Z dokumentami 500 tys. Nie ma powodu do skali. Typowy laptop z dyskiem SSD i 8 GB pamięci RAM może z łatwością zrobić 10 milionów rekordów, więc jeśli próbujesz wybrać z powodu skalowania, wybór nie ma znaczenia. Proponuję wybrać to, co lubisz najbardziej, i być może tam, gdzie możesz znaleźć najwięcej wsparcia online.

Answer 2

Aby uzyskać szybki przegląd porównań, bardzo podoba mi się ta strona internetowa, która ma wiele stron porównawczych, np. AWS DynamoDB kontra MongoDB; http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB

Answer 3

Wiem, że jest stary, ale wciąż pojawia się, gdy szukasz porównania. Używaliśmy Mongo, przeprowadziliśmy się prawie całkowicie do Dynamo, co jest teraz naszym pierwszym wyborem. Nie dlatego, że ma więcej funkcji, nie ma. Mongo ma lepszy język zapytań, możesz indeksować w strukturze, jest wiele małych rzeczy. Przewaga Dynamo wynika z tego, co OP stwierdził w swoim komentarzu: jest to łatwe. Nie musisz dbać o żadne serwery. Kiedy zaczynasz konfigurować rozwiązanie z Mongo, staje się to skomplikowane. Możesz iść do jednej z firm hostingowych, ale to też nie jest tanie. Dzięki Dynamo potrzebujesz większej przepustowości, wystarczy kliknąć przycisk. Możesz pisać skrypty do skali automatycznie. Kiedy nadszedł czas, aby uaktualnić Dynamo, jest to zrobione za Ciebie. To wszystko dużo cennego stresu i czasu nie wydanego. Jeśli nie masz dedykowanych ludzi z ops, Dynamo jest doskonałe.

Teraz domyślnie używamy Dynamo. Może Mongo, jeśli struktura danych jest wystarczająco skomplikowana, aby to uzasadnić, ale prawdopodobnie wrócimy do bazy danych SQL. Dynamo jest tępy, naprawdę musisz pomyśleć o tym, jak zamierzasz go zbudować, i prawdopodobnie użyjesz Redisa w Elasticcache, by działał na skomplikowane rzeczy. Ale na pewno dobrze jest nie dbać o to. Kodujesz. to jest to!

Answer 4

Należy pamiętać, mam eksperymentował tylko z MongoDB ...

Z tego co czytałem, DynamoDB przebyła długą drogę, jeśli chodzi o funkcje. Był to super-podstawowy sklep z kluczem wartości o bardzo ograniczonych możliwościach przechowywania i wysyłania zapytań. Od tego czasu rośnie, wspierając teraz bigger document sizes + JSON support i global secondary indices. Różnica między ofertami DynamoDB i MongoDB pod względem funkcji rośnie z każdym miesiącem. Nowe funkcje DynamoDB są rozszerzone na here.

Większość porównań MongoDB i DynamoDB jest nieaktualna ze względu na niedawne dodanie funkcji DynamoDB. Jednakże, this post oferuje kilka innych przekonujących punktów do wyboru DynamoDB, a mianowicie, że jest to proste, mało wymagające w utrzymaniu i często tanie. Another discussion here wyborów bazy danych był interesujący, choć nieco stary.

Moje dania na wynos: jeśli używasz poważnych zapytań do bazy danych lub pracujesz w językach nieobsługiwanych przez DynamoDB, użyj MongoDB. W przeciwnym razie trzymaj się DynamoDB.

Answer 5

Krótka odpowiedź: Zacznij od SQL i dodaj NoSQL tylko wtedy, gdy/w razie potrzeby. (chyba, że ​​nie potrzebujesz niczego poza bardzo prostymi pytaniami)

Moje osobiste doświadczenia: nie używałem MongoDB do zapytań, ale od kwietnia 2015 DynamoDB jest nadal bardzo okaleczony, jeśli chodzi o coś innego niż najbardziej podstawowy klucz/zapytania wartości. Uwielbiam go za podstawowe rzeczy, ale jeśli chcesz języka zapytań, spójrz na prawdziwe rozwiązanie bazy danych SQL.

W DynamoDB możesz zapytać o skrót lub klawisz skrótu i ​​zakresu, a możesz mieć wiele wtórnych indeksów globalnych. Robię zapytania na pojedynczej tabeli z 4 możliwymi parametrami filtrowania i sortowaniem wyników, jest to obsługiwane (ledwo) poprzez użycie globalnych indeksów pomocniczych z wyrażeniami filtru. Problem pojawia się, gdy próbujesz uzyskać sumaryczne wyniki pasujące do filtra, nie możesz po prostu wyszukać pierwszych 10 elementów pasujących do filtra, ale raczej sprawdza 10 elementów i możesz uzyskać 0 poprawnych wyników, zmuszając Cię do ponownego znalezienia skanowanie z klawisza kontynuacji - ból szyi i zużywa zbyt dużo limitu odczytanego ze stołu dla prostego scenariusza.

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

 
In a response, DynamoDB returns all the matching results within 
the scope of the Limit value. For example, if you issue a Query 
or a Scan request with a Limit value of 6 and without a filter 
expression, the operation returns the first six items in the 
table that match the request parameters. If you also supply a 
FilterExpression, the operation returns the items within the 
first six items in the table that match the filter requirements. 

Moja konkluzja jest taka, że ​​zapytań obejmujących 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łą twoją tabelę, która pochłania zbyt wiele jednostek czytających DynamoDB. Gdy użyjesz zbyt wielu odczytanych jednostek, uzyskasz dławienie i słabą wydajność.

Opinia eksperta: Na szczycie AWS w dniu 9 kwietnia 2015 r. Brett Hollman, menedżer ds. Architektury rozwiązań, AWS w swoim przemówieniu na temat skriningu do pierwszych 10 milionów użytkowników opowiada się za rozpoczęciem od bazy danych SQL, a następnie za pomocą NoSQL tylko wtedy i to ma sens. Ponieważ prędzej czy później prawdopodobnie będziesz potrzebował serwera SQL gdzieś w twoim stosie. Jego slajdy są tutaj: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users Zobacz slajd 28.

Answer 6

Wybraliśmy kombinację Mongo/Dynamo dla produktu medycznego. Zasadniczo mongo pozwala na lepsze wyszukiwanie, ale hostowane Dynamo jest świetne, ponieważ jest zgodne z HIPAA bez dodatkowej pracy. Więc obsługujemy część mongo bez danych osobowych na standardowej konfiguracji i pozwalamy amazonowi zajmować się częścią HIPAA pod względem infrastruktury. Możemy przesyłać zapytania o pewne przedmioty z mongo, które przywołują dokumenty ze wskaźnikami (identyfikatorami) powiązanego dokumentu Dynama.

Głównym powodem, dla którego zdecydowaliśmy się zrobić to za pomocą mongo zamiast hostingu całej aplikacji na dynamo było 2 powody. Najpierw musieliśmy przeprowadzić wyszukiwanie oparte na lokalizacji, z którego mongo jest świetne i na czasie, Dynamo nie było, ale teraz mają opcję.

Po drugie, niektóre dokumenty były niestrukturalne, a my nie wiedzieliśmy z wyprzedzeniem, jakie dane będą, więc na przykład powiedzmy, że użytkownik wprowadza dokument w kolekcji "form" w następujący sposób: {"nazwa użytkownika": " user1 "," email ":" me@me.com "}. Inny użytkownik umieszcza to w tej samej kolekcji {"telefon": "813-555-3333", "lokalizacja": [28.1234, -83.2342]}. Za pomocą mongo możemy przeszukiwać dowolne z tych dynamicznych i nieznanych pól w dowolnym momencie. Dynamo, możesz to zrobić, ale musiałby utworzyć indeks za każdym razem, gdy dodano nowe pole, które chciałbyś wyszukać. Więc jeśli nigdy wcześniej nie miałeś pola telefonicznego w swoim dokumencie Dynamo, a potem nagle, ktoś je dodaje, jest całkowicie niezbadany.

Teraz to przywołuje inny punkt, o którym wspomniałeś.Czasami wybór właściwego rozwiązania nie zawsze oznacza wybór najlepszego produktu do pracy. Na przykład możesz mieć klienta, który potrzebuje i będzie używać systemu utworzonego przez 10 lat. Korzystanie z rozwiązania SaaS/IaaS, które jest wystarczająco dobre, aby wykonać pracę, może być lepszym rozwiązaniem, ponieważ możesz polegać na Amazon, aby utrzymywać i utrzymywać swoje systemy na dłuższą metę.

Answer 7

Pracowałem zarówno nad fanem obu.

Ale musisz zrozumieć, kiedy użyć tego, co iw jakim celu.

Nie wydaje mi się, że dobrym pomysłem jest przeniesienie całej bazy danych do DynamoDB, ponieważ zapytania są trudne, z wyjątkiem kluczy podstawowych i pomocniczych, indeksowanie jest ograniczone, a skanowanie w DynamoDB jest bolesne.

Wybrałbym hybrydowy rodzaj DB, gdzie powinny być dostępne obszerne dane do zapytania, z MongoDB, z całą jego funkcją, której nigdy nie czułbyś się ograniczony do wprowadzania ulepszeń lub modyfikacji.

DynamoDB działa błyskawicznie (szybciej niż MongoDB), więc DynamoDB jest często używany 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, że masz artykuły lub kanały. Ludzie częściej szukają rzeczy w zeszłym tygodniu lub w tym miesiącu. szanse na to, że ludzie odwiedzają dwuletnie dane, są bardzo rzadkie. W tym celu DynamoDB preferuje przechowywanie danych przez miesiące lub lata w różnych tabelach.

DynamoDB jest bezspornie skalowalny, coś, co trzeba zrobić ręcznie w MongoDB. jednak można stracić na wydajności DynamoDB, jeśli nie rozumiesz partycji przepustowości i jak działa skalowanie za sceną.

DynamoDB powinien być używany tam, gdzie prędkość jest krytyczna, z drugiej strony MongoDB ma za dużo rąk i funkcji, coś, czego nie ma DynamoDB.

na przykład, możesz mieć zestaw replik MongoDB w taki sposób, że jedna z replik posiada instancję danych z 8 (lub cokolwiek) godzinami. Naprawdę użyteczne, jeśli spartaczyłeś coś dużego czasu w DB i chcesz uzyskać dane tak jak wcześniej.

To jednak moja opinia.