Ce n'est pas un schéma idéal pour un clone de Twitter. Le principal problème est que "posts" est un tableau sans cesse croissant, ce qui signifie que mongo devra déplacer votre document volumineux tous les quelques messages car il n'a plus de rembourrage de document. De plus, il existe une limite de taille stricte (16 Mo) pour les documents, ce qui rend ce schéma au mieux restrictif.
Le schéma idéal dépend du fait que vous vous attendiez ou non à la charge de Twitter. Le schéma mongodb "parfait" en termes de maintenabilité et de facilité d'utilisation n'est pas le même que celui que j'utiliserais pour quelque chose avec le débit de Twitter. Par exemple, dans le premier cas, j'utiliserais une collection de publications avec un document par publication. Dans le scénario à haut débit, je commencerais à créer des documents de compartiment pour de petits groupes de messages (par exemple, un par page "obtenir plus"). De plus, dans le scénario à haut débit, vous devrez tenir à jour la chronologie de l'abonné dans des documents de chronologie utilisateur distincts, tandis que dans les scénarios à faible débit, vous pourrez simplement les interroger.
