Mongodb - czy problemy z niezawodnością są nadal znaczące?

Question

Mam kilka sqlite dbs (powiedziałbym około 15 GB), z około 1m wierszy w sumie - więc nie super duży. Patrzyłem na mongodbę i wygląda na to, że łatwo z nim pracować, szczególnie jeśli chcę spróbować wykonać podstawowe przetwarzanie języka naturalnego na dokumentach, które tworzą bazy danych.

Nigdy nie pracowałem z Mongo w przeszłości, nie musiałbym uczyć się od zera (będzie pracował w Pythonie). Po krótkim przeglądzie, natknąłem się na kilka przerażających historii o Mongodbie. niezawodność. Czy to nadal jest poważny problem? W razie kryzysu oczywiście zachowam kopie zapasowe sqlite, ale raczej nie będę musiał ciągle odtwarzać moich baz danych.

Zastanawiasz się, jakie problemy z uszkodzeniem danych ludzie mieli ostatnio do czynienia z Mongo? Czy to duży problem?

Dzięki!

Answer 1

Tak, trwałość to duży problem w Mongo. Musisz używać zestawów replikacji w mongodb, aby uzyskać wytrzymałość (potrzebujesz co najmniej 2 komputerów), w przeciwnym razie możesz stracić do ostatniej minuty na przykład w przypadku awarii zasilania. Nie ma trwałości pojedynczego serwera w Mongo, ale będzie rozwijana dla 1.7-1.8, jak wiem. Po awarii musisz ręcznie naprawić db, a operacja rapair może zająć godziny, jeśli twoje dane są duże. Nie ma transakcji ani kwasu, więc nie nadaje się do aplikacji e-commerce lub bankowości.

Nie powinieneś używać rozwojowych wersji mongo (nieparzysta liczba wersjid jak 1.3.x, 1.5.x, 1.7.x to wersje rozwojowe) i wolisz używać 64-bitowych systemów operacyjnych. Jeśli sięgniesz po artykuły o katastrofie w sieci na temat mongo, źródłem problemu są w większości przypadków te dwa.

CouchDB, Cassandra i postgresql mają silną trwałość (fsync domyślnie wynosi 10 milisekund w języku kassandra i postgresql), więc wszystkie mają wytrzymałość na pojedynczym serwerze.

Jeśli potrzebujesz martwej łatwej skalowalności, odporności na uszkodzenia i równoważenia obciążenia; cassandra jest najlepsza, ale ze słabymi opcjami zapytania. Wadliwe węzły mogą zniknąć i wrócić po pewnym czasie, bez problemu, system sam się naprawi.

EDYCJA: Mongo 1.8 przyszedł z księgowaniem (pozwala na trwałość), ale nie jest to ustawienie domyślne. Należy również spojrzeć na to http://news.ycombinator.com/item?id=2684423

Pozdrawiam,

Serdar Irmak

Answer 2

Mongo nie ma właściwości ACID, w szczególności trwałości. Możesz więc stawić czoła problemom, jeśli proces nie zostanie całkowicie zamknięty lub urządzenie straci moc. Powinieneś zaimplementować kopie zapasowe i nadmiarowość, aby sobie z tym poradzić.

Answer 3

"MongoDB obsługuje zautomatyzowaną architekturę shardingu, umożliwiając skalowanie w poziomie w wielu węzłach." - source Musisz więc uruchomić wiele węzłów do równoważenia i obsługi przełączania awaryjnego. Jeśli chcesz uruchomić pojedynczą instancję, która nie zawiedzie, jeśli nagle nastąpi utrata zasilania, potrzebujesz czegoś, co obsługuje ACID, np. CouchDB. Mówiąc o tym, używam mongo w pracy przez miesiąc i nie rozbił się on na mnie, jednak niedługo przejdziemy do klastra z 6 węzłami.

Trwałość

Produkty mają różne podejścia do trwałości. CouchDB to projekt typu "tylko awaryjnego", w którym db może zakończyć w dowolnym czasie i pozostaje zgodny z . MongoDB przyjmuje inne podejście do trwałości: . Na wypadek awarii komputera, jeden następnie uruchomiłby operację repairDatabase() po ponownym uruchomieniu (podobnie jak MyISAM). MongoDB zaleca używanie replikacji - zarówno LAN, jak i WAN - dla prawdziwej trwałości, ponieważ dany serwer może być trwale martwy . Podsumowując: CouchDB ma większą trwałość, gdy używa pojedynczego serwera bez replikacji .

Cytat z oficjalnej strony mongodb.org.

Answer 4

Nie widzę problemu, jeśli masz te same dane również w SQLite kopii zapasowych. Zawsze możesz uzupełnić swoje bazy danych MongoDb. Ponowne napełnianie zajmie tylko kilka minut.

Answer 5

Jak już powiedzieli inni, MongoDB nie ma obecnie wytrzymałości na pojedynczym serwerze. Na szczęście jest to dead easy, aby skonfigurować replikację wielowęzłową. Możesz nawet ustawić drugą maszynę w innym centrum danych i automatycznie zreplikować dane na żywo!

Jeżeli zapis musi uda, można spowodować Mongo nie powrócić z wkładką/aktualizacji aż że dane zostały replikowane do n niewolników. Zapewnia to, że masz co najmniej n kopii danych. Zestawy replik pozwalają na dodawanie i usuwanie węzłów z klastra w locie bez żadnej istotnej pracy; po prostu dodaj nowy węzeł i automatycznie zsynchronizuje kopię danych. Usuń węzeł, a klaster ponownie się wyrówna. Jest bardzo zaprojektowany do użycia na wielu maszynach, z wieloma węzłami działającymi równolegle; jest to preferowana konfiguracja domyślna, w porównaniu do czegoś takiego jak MySQL, który oczekuje, że jedna gigantyczna maszyna wykona swoją pracę, którą możesz następnie sparować z niewolnikami, kiedy musisz skalować. Jest to inne podejście do przechowywania i skalowania danych, ale bardzo wygodne, jeśli poświęcisz czas, aby zrozumieć różnicę w założeniach i jak zbudować architekturę, która wykorzystuje swoje mocne strony.