Tak więc, aby bezpośrednio odpowiedzieć na pytania...
Pamięć bez schematu jest z pewnością ważnym powodem, aby wybrać MongoDB, ale jak już wspomniałeś, przechowywanie JSON w RDBMS jest dość łatwe. Siła MongoDB polega na bogatych zapytaniach przeciwko pamięci masowej bez schematu.
Jeśli mógłbym wskazać mały błąd na ilustracji dotyczący aktualizacji pola JSON, nie jest to po prostu kwestia pobrania bieżącej wartości, zaktualizowania dokumentu, a następnie odesłania go z powrotem do bazy danych. Cały proces musi być opakowany w transakcję. Transakcje są zazwyczaj dość proste, dopóki nie zaczniesz denormalizować swojej bazy danych. Wtedy coś tak prostego, jak nagranie głosu za, może zablokować tabele w całym schemacie.
Z MongoDB nie ma transakcji. Ale operacje można prawie zawsze zorganizować w sposób, który pozwala na atomowe aktualizacje. Zwykle wiąże się to z pewnymi dramatycznymi odejściami od paradygmatów SQL, ale moim zdaniem są one dość oczywiste, gdy przestaniesz próbować wciskać obiekty w tabele. Przynajmniej wielu innych ludzi napotkało te same problemy, z którymi Ty będziesz się zmagać, a społeczność Mongo zazwyczaj jest dość otwarta i głośno mówi o wyzwaniach, które pokonała.
Przez „bezpieczne zapisy” zakładam, że masz na myśli opcję włączenia automatycznego „getLastError()” po każdym zapisie. Mamy bardzo cienkie opakowanie na DBCollection, które pozwala nam na precyzyjną kontrolę nad wywołaniem getLastError(). Jednak nasze zasady nie są oparte na tym, jak „ważne” są dane, ale raczej na tym, czy kod następujący po zapytaniu oczekuje, że jakiekolwiek modyfikacje będą natychmiast widoczne w kolejnych odczytach.
Ogólnie rzecz biorąc, jest to nadal słaby wskaźnik i zamiast tego przeprowadziliśmy migrację do findAndModify() dla tego samego zachowania. W przypadku, gdy nadal wyraźnie wywołujemy getLastError(), jest to sytuacja, w której baza danych prawdopodobnie odrzuci zapis, na przykład gdy wstawiamy() z identyfikatorem _id, który może być duplikatem.
Obawiam się, że nie mogę mówić, czy nasza polityka tworzenia kopii zapasowych/przywracania jest skuteczna, ponieważ nie musieliśmy jeszcze przywracać. Postępujemy zgodnie z zaleceniami MongoDB dotyczącymi tworzenia kopii zapasowych; @mark-hillick wykonał świetną robotę, podsumowując je. Korzystamy z zestawów replik, przeprowadziliśmy migrację wersji MongoDB oraz wprowadziliśmy nowe elementy replik. Jak dotąd nie mieliśmy przestojów, więc nie jestem pewien, czy potrafię dobrze mówić do tego momentu.
Tak więc z mojego doświadczenia wynika, że MongoDB oferuje przechowywanie danych bez schematu z zestawem prymitywów zapytań na tyle bogatym, że transakcje można często zastąpić operacjami atomowymi. Trudno było oduczyć się ponad 10 lat doświadczenia w SQL, ale każdy problem, z którym się spotkałem, został rozwiązany bezpośrednio przez społeczność lub 10gen. Nie straciliśmy danych ani nie mieliśmy żadnych przestojów, które pamiętam.
Mówiąc prościej, MongoDB to bez wątpienia najlepszy ekosystem przechowywania danych, jakiego kiedykolwiek używałem pod względem zapytań, konserwacji, skalowalności i niezawodności. O ile nie miałem aplikacji, która była tak wyraźnie relacyjna, że nie mógłbym z czystym sumieniem używać niczego innego niż SQL, dołożyłbym wszelkich starań, aby użyć MongoDB.
Nie pracuję dla 10gen, ale jestem bardzo wdzięczny ludziom, którzy to robią.
