Utiliser efficacement la stratégie d'allocation de MongoDB

Question

Je suis novice en ce qui concerne certains concepts de MongoDB, comme la stratégie d'allocation. Actuellement, j'utilise la version MongoDB-3.2.2, j'utilise la même version avec Windows 32 bits et 64 bits ainsi que . Selon les documents Mongo la stratégie d'allocation par défaut est "PowerOf2Sizes" et ce qui est mieux pour les opérations d'insertion/mise à jour/suppression. J'ai l'exigence suivante: Je stocke mes journaux dans un tableau en tant que document. Donc au départ, j'ai commencé à insérer un journal dans le tableau et ensuite je mettrai à jour le même tableau dans le document avec no.of entrées du journal. J'insère et met à jour le tableau dans le document. Ici, j'utilise un moteur 32 bits (MMAPV1) et un moteur 64 bits (Wired Tiger). Selon ma compréhension des documents Mongo, je n'ai pas besoin de définir un facteur de remplissage (par stratégie d'allocation) à 64 bits pour éviter le mouvement du document. J'ai seulement besoin de définir le facteur de remplissage (via la stratégie d'allocation) pour 32 bits (moteur de stockage MMAP v1).

Est-ce que n'importe quel corps pourrait me dire comment puis-je utiliser la stratégie d'allocation pour mon exigence ci-dessus? Ou ma compréhension est-elle correcte?

Answer 1

MongoDB a une limite de 16 Mo/document. Donc, votre solution peut ne pas fonctionner dans des serevers de production en temps réel avec un bon trafic. Beacuse le document sera épuisé quand un bug de la proktion commence à le remplir rapidement.

Le document ci-dessous vous aidera à concevoir le back-end et à apporter de l'évolutivité.

https://docs.mongodb.com/ecosystem/use-cases/storing-log-data/

Answer 2

J'ai une très bonne vidéo pour répondre à votre question. Ceci est d'architecte MongoDB et vous aidera à analyser vos besoins

https://youtu.be/9nYFnlM4vYw

Good Day

Answer 3

Dans le stockage wiredTiger il n'y a pas de rembourrage nécessaire au stockage ne soit pas linéaire comme dans MMapV1 où nous obtenir un problème de fragmentation dû au mouvement du document jusqu'à la fin (ou partout où se trouve l'espace vide disponible).

Si vous savez déjà que votre document va être assez grand et que vous ne voulez pas le mouvement, la stratégie d'allocation est d'insérer votre document avec un champ avec un gros texte poubelle puis d'appeler une mise à jour avec $ unset ce champ de texte qui supprimera le texte de la corbeille, de sorte que votre document a déjà un plus grand espace et le mouvement de celui-ci est peu probable que les données se développent plus loin. Cependant, il y a une limite de 16 Mo par document, ce qui est assez bon, donc pour maintenir un niveau sain, vous pouvez appeler $ push avec $ slice comme -50 (ou plus), cela garantira que votre tableau n'a que 50 derniers journaux.

S'il s'agit de journaux, la collecte avec cap est une bonne stratégie, mais elle fonctionnera lorsque chaque journal est un document distinct, ce qui n'est pas le cas de votre conception.