И така, за да отговоря директно на въпросите...
Безсхемното съхранение със сигурност е убедителна причина да отидете с MongoDB, но както посочихте, е доста лесно да съхранявате JSON и в RDBMS. Силата зад MongoDB е в богатите заявки срещу съхранение без схеми.
Ако мога да посоча малък недостатък в илюстрацията за актуализиране на JSON поле, това не е просто въпрос на получаване на текущата стойност, актуализиране на документа и след това връщането му обратно към базата данни. Целият процес трябва да бъде обвит в транзакция. Транзакциите обикновено са доста ясни, докато не започнете да денормализирате вашата база данни. Тогава нещо толкова просто като записване на гласуване за може да заключи таблици в цялата ви схема.
С MongoDB няма транзакции. Но операциите почти винаги могат да бъдат структурирани по начин, който позволява атомарни актуализации. Това обикновено включва някои драматични промени от парадигмите на SQL, но по мое мнение те са доста очевидни, след като спрете да се опитвате да вкарвате обекти в таблици. Най-малкото, много други хора са се сблъсквали със същите проблеми, с които ще се сблъскате и вие, а общността на Mongo е склонна да бъде доста открита и гласовита за предизвикателствата, които са преодолели.
Под „безопасни записи“ предполагам, че имате предвид опцията за включване на автоматичен „getLastError()“ след всяко писане. Имаме много тънка обвивка върху DBCollection, която ни позволява фин контрол върху това кога се извиква getLastError(). Нашата политика обаче не се основава на това колко „важни“ са данните, а по-скоро на това дали кодът след заявката очаква някакви модификации да бъдат незабавно видими при следващите четения.
Най-общо казано, това все още е лош индикатор и вместо това мигрирахме към findAndModify() за същото поведение. В случаите, когато все още изрично извикваме getLastError(), това е, когато има вероятност базата данни да отхвърли запис, като например когато вмъкнем() с _id, който може да е дубликат.
Страхувам се, че не мога да говоря дали нашата политика за архивиране/възстановяване е ефективна, тъй като все още не се е налагало да възстановяваме. Ние следваме препоръките на MongoDB за архивиране; @mark-hillick свърши страхотна работа, като ги обобщи. Използваме комплекти реплики и мигрирахме версии на MongoDB, както и въведохме нови членове на реплики. Досега не сме имали престой, така че не съм сигурен, че мога да говоря добре до този момент.
И така, според моя опит, MongoDB предлага съхранение на данни без схема с набор от примитиви на заявки, достатъчно богати, че транзакциите често могат да бъдат заменени от атомарни операции. Беше трудно да се отуча от 10+ години SQL опит, но всеки проблем, с който се сблъсках, беше адресиран от общността или директно от 10gen. Не сме губили данни или имали престой, доколкото мога да си спомня.
Казано по-просто, MongoDB е най-добрата екосистема за съхранение на данни, която някога съм използвал по отношение на заявки, поддръжка, мащабируемост и надеждност. Освен ако нямах приложение, което беше толкова ясно релационно, че не можех с чиста съвест да използвам нищо друго освен SQL, бих положил всички усилия да използвам MongoDB.
Не работя за 10gen, но съм много благодарен на хората, които го правят.
