Taille maximale des documents MongoDB

Ce tutoriel décrit la limite de taille maximale par défaut pour stocker un document dans MongoDB. Il éduque également la solution alternative si les données dépassent la limite de taille.

Nous découvrirons également l’utilisation efficace de la limite de taille maximale par défaut pour un document BSON.

Taille maximale des documents MongoDB

Dans MongoDB, les documents (objets) sont stockés au format BSON. Le BSON (le JSON binaire) est une sérialisation binaire des documents de type JSON.

En utilisant ce format, nous pouvons utiliser différentes extensions pour utiliser les différentes représentations de types de données qui ne font pas partie du JSON.

Par exemple, nous avons un type Date et BinData dans BSON qui ne sont pas disponibles dans JSON. Selon la documentation MongoDB, la limite de taille pour un seul document BSON est de 16 Mo.

Nous avons la limite de taille maximale d’un document pour nous assurer qu’un document ne peut pas utiliser la quantité illimitée de RAM ou de bande passante pendant la transmission. N’oubliez pas que nous pouvons imbriquer les documents BSON jusqu’à 100 niveaux où chaque tableau/objet ajoute un niveau.

Dans le monde d’aujourd’hui, nous avons des données tout autour de nous. Il est donc possible que nos données augmentent la taille limite d’un document BSON qui est de 16 mégaoctets.

Dans ce cas, MongoDB nous assiste en fournissant l’API GridFS pour stocker les documents supérieurs à 16 Mo.

Qu’est-ce que l’API GridFS

Le GridFS est une spécification MongoDB que nous pouvons utiliser pour stocker et accéder aux fichiers volumineux dépassant la limite du document BSON (16 Mo), par exemple, des fichiers audio, vidéo ou image. Il est similaire au système de fichiers pour le stockage des fichiers, mais les données sont stockées dans des collections MongoDB.

L’API GridFS divise le fichier en morceaux et stocke chaque morceau de données dans un document séparé où la taille de chaque document est de 255 Ko. Le GridFS contient deux collections, fs.files et fs.chunks par défaut, stockant les métadonnées et les morceaux d’un fichier.

Chaque morceau est reconnu par un champ _id (le ObjectId) unique, tandis que les fs.files servent de document parent. Le champ files_id dans le document fs.chunks relie le morceau à son parent.

Vous pouvez parcourir cet article pour comprendre la syntaxe lors de l’utilisation de GridFS.

Utiliser efficacement la limite de taille de document BSON par défaut

La limite de taille de document BSON (16MB) est beaucoup. Par exemple, tout le texte non compressé de la Guerre des mondes n’est qu’en 364k (HTML), mais il y a toujours des exceptions.

Si vos données dépassent la limite, vous pouvez utiliser l’API GridFS dont nous avons parlé précédemment ou élaborer une stratégie pour une utilisation efficace de 16 Mo.

Prenons un scénario dans lequel nous voulons développer une application XYZ. L’application a besoin de quatre types de données - Booleans, numbers, strings, et dates (représentés par UNIX ms).

Avec une limite de taille de 16 Mo, MongoDB peut facilement stocker environ deux millions de valeurs de nombres 64 bits (ainsi que des dates et des booléens).

Ici, les valeurs de type string nécessitent une attention particulière car chaque caractère UTF-8 occupe un byte. Il faut optimiser la taille de toutes les colonnes contenant des valeurs de type string.

Nous pouvons essayer les méthodes suivantes pour diminuer la taille d’une colonne ayant des valeurs de type string.

1. Nous pouvons utiliser les méthodes stringify() et zip() comme zip(JSON.stringify(column.values));.

2. Nous pouvons créer un dictionnaire et insérer toutes les valeurs uniques de type chaîne dans le dictionnaire. Ensuite, remplacez les valeurs de chaîne par des index.

   Cette approche est utile si nous avons de nombreuses valeurs de chaîne répétées dans un champ. Cette méthode n’aidera pas si quelqu’un veut stocker une colonne de hachages, mais il peut utiliser l’API GridFS.

3. Nous pouvons également diviser la colonne en plusieurs morceaux et enregistrer ces morceaux dans d’autres documents liés au document principal.

Il existe un article de référence démontrant toutes ces approches.