Kiedy używać MongoDB [zamknięty]
Chcesz poprawić to pytanie? zaktualizuj pytanie, aby mogło być odpowiedź z faktami i cytatami przez edytując ten post .
Zamknięte 5 miesięcy temu .
Popraw to pytaniePiszę aplikację, która niekoniecznie potrzebuje zdolności skalowania , ponieważ nie będzie zbierać dużych ilości danych na początku. (Jednak jeśli mam szczęście, to może być w drodze.)
Będę uruchamiał mój serwer WWW i bazę danych na tym samym polu (na razie).
To powiedziawszy, Szukam wydajności i wydajności.Główną częścią mojej aplikacji będzie ładowanie artykułów na blogu. Korzystając z RDBMS (MySQL) wykonam 6 zapytań (2 z nich są połączone), tylko po to, aby załadować pojedynczą stronę artykułu na blogu.
select blog
select blog_album
select blog_tags
select blog_notes
select blog_comments (join with users)
select blog_author_participants (join with users)
Jednak za pomocą MongoDB mogę de-normalizować i spłaszczyć 6 tabel do zaledwie 2 tabele / kolekcje i minimalizuje moje zapytania do potencjalnie tylko jednego zapytania 1,
users
blogs
->blog_album
->blog_tags
->blog_notes
->blog_comments
->blog_author_participants
Teraz, idąc ze schematem MongoDB, nastąpi nadmiarowość danych. Jednak miejsce na dysku twardym jest tańsze niż CPU / serwery.
1.) Czy to byłby dobry scenariusz korzystania z MongoDB?
2.) Czy korzystasz tylko z wydajności przy użyciu MongoDB podczas skalowania poza jednym serwerem?
3.) Czy stosowanie MongoDB jest zagrożone trwałością? Słyszałem, że istnieje możliwość utraty danych podczas wykonywania wstawek-as insert są najpierw zapisywane do pamięci, potem do bazy danych.
4.) Czy to powinno powstrzymać mnie od używania MongoDB w produkcji?
6 answers
Jednak za pomocą MongoDB mogę de-normalizować i spłaszczyć 6 tabel w tylko 2 tabele/kolekcje i minimalizować moje zapytania do potencjalnie tylko jednego 1 zapytania
Ale możesz łatwo odpytywać MySQL o 6 tabel wartych informacji związanych z pojedynczym postem na blogu za pomocą jednego poprawnie wykonanego polecenia SQL.
Jednak miejsce na dysku twardym jest tańsze niż CPU / serwery.
Jeśli wydajność i skalowanie jest priorytetem, to będziesz się martwić o posiadanie wystarczającej ilości pamięci RAM, aby zmieścić wszystko w pamięci głównej i wystarczającej liczby rdzeni procesora do uruchamiania zapytań. Macierz RAID 10 klasy korporacyjnej jest wymogiem, nie zrozum mnie źle, ale jak tylko oprogramowanie bazy danych (MongoDB lub MySQL) musi przeskanować indeks, który nie mieści się w pamięci głównej, będziesz musiał cierpieć, zakładając dużą aktywną bazę danych. :)
Lubię MongoDB, ale dużą siłą w moim umyśle jest map/reduce i jego orientacja na dokumenty. Nie wymagasz żadnej z tych funkcji. MySQL jest testowany na dużą skalę we wdrożeniach i obsługuje partycjonowanie (ale twierdziłbym, że Twoja baza danych musiałaby być w kolejności 50-100 GB, zanim zdołasz osiągnąć znaczny zysk z partycjonowania w porównaniu z pojedynczym (Plus pasywnym serwerem kopii zapasowych) z tonami (64 GB+) PAMIĘCI RAM. Chciałbym również argumentować, że jeśli wydajność jest naprawdę problemem, to MySQL byłby lepszy, ponieważ miałbyś najwyższą kontrolę nad swoimi indeksami.
Nie oznacza to, że MongoDB nie jest wysoką wydajnością, ale jego miejsce prawdopodobnie nie obsługuje blogów. Twoja troska o wkładki jest również ważna. MongoDB nie jest układem . Transakcje Google w obu systemach i porównaj.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-03-08 13:46:20
Możesz użyć MongoDB, gdy masz przypadek użycia, który pasuje do jego mocnych stron.
Czy potrzebujesz magazynu dokumentów bez schematu? Nie, masz stabilny schemat.
Czy potrzebujesz automatycznego shardingu? Nie, Nie masz nadzwyczajnych potrzeb w zakresie danych ani budżetu na sprzęt do skalowania poziomego.
Czy potrzebujesz map/zmniejszyć przetwarzanie danych? Nie dla czegoś takiego jak blog.
Więc dlaczego w ogóle to rozważasz?
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-02-13 01:14:22
Oto dobre wyjaśnienie: http://mod.erni.st/nosql-if-only-it-was-that-easy/
Ostatni akapit podsumowuje to:
Na czym zbuduję swoją następną aplikację? Prawdopodobnie Postgres. Czy będę używał NoSQL? Może. Mogę też użyć Hadoop i Hive. Mogę zachować wszystko w aktach. Może zacznę hakować Magleva. Użyję do tego wszystkiego, co najlepsze. Jeśli będę potrzebował raportowania, Nie będę używał żadnego NoSQL. Jeśli będę potrzebował buforowania, prawdopodobnie użyję Tokyo Tyrant. If I potrzebuję kwasowości, Nie będę używał NoSQL. Jeśli będę potrzebował Tony liczników, użyję Redis. Jeśli będę potrzebował transakcji, użyję Postgres. Jeśli mam tonę jednego typu dokumentów, prawdopodobnie użyję Mongo. Gdybym potrzebował pisać 1 miliard obiektów dziennie, pewnie użyłbym Voldemorta. Gdybym potrzebował pełnego tekstu, pewnie użyłbym Solr. Gdybym potrzebował pełnotekstowego przeszukiwania ulotnych danych, pewnie użyłbym Sphinx.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-06-28 06:55:31
NoSQL vs. RDBMS: jabłka i pomarańcze?
Radzę ci przeczytać trochę o tym, czym jest NoSQL i co robi, zanim zdecydujesz, czy możesz go używać. Nie możesz wziąć normalnej bazy danych i zmienić jej w NoSQL tak po prostu. Sposób pracy z danymi jest zupełnie inny.
NoSQL zdecydowanie ma swoje zastosowania. Ale to zdecydowanie nie jest odpowiedź na wszystko. Główną zaletą NoSQL jest Łatwo zmienny model danych.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-03-08 13:48:50
Zalety korzystania z mongodb (zgodnie z Moshe Kaplan opublikowanym w dzone Artykuł )
- Projekt bez schematu
- skalowalność w zarządzaniu bajtami Tera danych
- Rapid replicaSet with high availability feature Sharding umożliwia liniowy i skalowalny wzrost bez wychodzenia z budżetu]}
- Obsługa wysokiego obciążenia zapisu
- wykorzystanie lokalizacji danych do przetwarzania zapytań
MongoDB spełnia Consistency & Partitioning Wymagania w teorii WPR ( Spójność, dostępność i partycjonowanie)
Powiązane pytania:
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 11:47:21
Nie mogę mówić o względach wydajności, ale dla mnie pierwszym rozważeniem, czy chcesz użyć SQL-DB vs MongoDB, jest struktura danych, które chcesz przechowywać.
MongoDB jest "bez schematu" w tym sensie, że nie musisz wiedzieć, jakie "tabele" i "kolumny" chcesz wcześniej. Jest bardzo elastyczny. Jeśli więc nie wiesz, jakie informacje chcesz przechowywać na przykład w swojej kolekcji "blogi" lub jeśli różne posty na blogu mogą przechowywać różne informacje, to MongoDB umożliwia taką elastyczność. Podczas gdy w relacyjnych bazach danych SQL musisz znać swój schemat z góry.
Ale wygląda na to, że już wiesz, jakie informacje chcesz przechowywać, w takim przypadku mogę po prostu trzymać się relacyjnej bazy danych SQL. Nie sądzę, aby wydajność była pierwszą kwestią w Twoim przypadku - nie budujesz aplikacji w czasie rzeczywistym, w której jedna lub dwie milisekundy mają takie znaczenie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-09-09 21:19:47