MongoDB może służyć do przechowywania większości lub wszystkich jednostek w szybkim, zorientowanym na dokumenty magazynie. Ten typ magazynu skaluje się znacznie lepiej niż standardowy magazyn oparty na SQL, który mamy w rdzeniu Drupala (który jest oparty na schemacie „jedna tabela na pole”).
W obecnym stanie Drupala 7 masz:
- Tabela podstawowa encji przechowywana w SQL (tj. Tabela użytkowników, tabela węzłów itp.)
- Wszystkie pola przechowywane w SQL
- Właściwości encji z ich tabel podstawowych zduplikowanych w MongoDB
Umożliwia to szybkie odpytywanie o jednostki na MongoDB i możliwość dodawania złożonych indeksów, które nie obsługują bazy danych SQL opensource (w tym indeksów między tabelami). Jednocześnie nie tracisz interoperacyjności, ponieważ tabela podstawowa encji jest nadal przechowywana w języku SQL, a zatem można do niej dołączyć moduły, które są nadal tylko SQL (jak flaga).
Ten rodzaj szybkiego zapytania jest dostępny dzięki mechanizmowi EntityFieldQuery, który jest sposobem na tworzenie zapytań dotyczących encji, ich właściwości i pól w sposób abstrakcyjny. Domyślna implementacja w rdzeniu tłumaczy te zapytania na SQL, ale moduł MongoDB ma w pełni funkcjonalną implementację, która może bezpośrednio zaspokoić te zapytania z MongoDB.
Dzięki backendowi EntityFieldQuery dla widoków możesz łatwo wykorzystać tę moc, korzystając z narzędzi, do których jesteś przyzwyczajony. Jedynym minusem jest to, że relacje nie są obsługiwane (ale w praktyce i tak rzadko są one potrzebne - i można to obejść, wpychając dodatkowe dane do obiektu encji i dodając ujawnianie ich jako dodatkowych właściwości encji).
W skrócie, gdy tylko wydajność zapytania stanowi problem w twoim projekcie, co dzieje się, gdy masz znaczący zestaw danych (powiedzmy, że zaczynając od kilku dziesiątych tysięcy jednostek dla danego typu jednostki), MongoDB jest zyskiem netto dla bardzo niewielu wad. Wysoce polecany.