To nie jest idealny schemat dla klona Twittera. Głównym problemem jest to, że "posty" to stale rosnąca tablica, co oznacza, że mongo będzie musiało przenosić twój ogromny dokument co kilka postów, ponieważ zabrakło mu wypełnienia dokumentu. Dodatkowo istnieje twardy (16 MB) limit rozmiaru dokumentów, co czyni ten schemat w najlepszym wypadku restrykcyjnym.
Idealny schemat zależy od tego, czy spodziewasz się obciążenia Twittera. „Doskonały” schemat mongodb pod względem łatwości konserwacji i łatwości użytkowania nie jest taki sam, jak ten, którego użyłbym do czegoś z przepustowością Twittera. Na przykład w pierwszym przypadku użyłbym kolekcji postów z dokumentem na post. W scenariuszu z wysoką przepustowością zacząłbym tworzyć dokumenty zasobnikowe dla małych grup postów (powiedzmy, jeden na stronę „uzyskaj więcej”). Dodatkowo w scenariuszu o wysokiej przepustowości musisz aktualizować oś czasu obserwatora w oddzielnych dokumentach osi czasu użytkownika, podczas gdy w scenariuszach o niskiej przepustowości możesz po prostu wysłać do nich zapytanie.
