Besoin d'aide ?
Configuration requise pour le disque
La quantité d’espace disque requise par MongoDB dépend entièrement du nombre d’actifs dans le système. Si le nombre d’actifs est stable, ou s’il y a un taux d’afflux / suppression constant dans l’archive de sorte que le nombre d’actifs reste à un certain niveau, l’instance ne grandira pas.
Chaque actif reste environ 10 jours dans MongoDB après sa suppression. Par conséquent, la formule approximative pour calculer le nombre d’actifs peut être exprimée comme suit :
N = i * (t + 10) + p
p : nombre d’actifs qui sont en permanence dans le système
t : nombre maximal de jours pendant lesquels un actif est conservé dans le système après l’ingestion
i : Nombre d’actifs ingérés par jour (24h)
N : nombre total d’actifs dans le système à un moment donné.
Chaque élément nécessite environ 10 Ko d’espace. La formule pour calculer l’espace disque requis pour les actifs dans MongoDB est la suivante :
Espace disque (Mégaoctets) = N * 0,01
(N est le nombre total d’actifs, comme expliqué ci-dessus.)
Les performances du disque sont importantes
Les données MongoDB doivent être stockées sur un SSD local rapide pour les meilleures performances. Le stockage des données MongoDB sur un lecteur réseau ne fonctionnera pas.
Tous les fichiers indexés sont poussés vers MongoDB
Lorsqu’un Index Manager est configuré pour pousser les données vers l’instance MongoDB d’un serveur FotoWeb, tout le contenu indexé de ce serveur Index Manager est poussé vers MongoDB, même si seuls certains des index sont utilisés comme archives dans FotoWeb. Par exemple, il peut arriver que FotoWeb n’héberge que quelques archives du serveur Index Manager alors que d’autres index sont utilisés par FotoStation. Dans ce cas, les données de tous les index sont transmises au serveur MongoDB, car Index Manager est considéré comme un « esclave » du serveur FotoWeb.
Routine de nettoyage de MongoDB
MongoDB ne libère pas d’espace disque lorsque les données sont supprimées. Cependant, l’espace disque déjà alloué peut être réutilisé par de nouvelles données. Il existe des commandes d’administration MongoDB qui peuvent être utilisées pour réduire et défragmenter les fichiers de la base de données. Cependant, FotoWeb n’exécute pas automatiquement de telles commandes sur MongoDB.
FotoWeb utilise l’option « smallfiles » de MongoDB pour s’assurer que l’espace disque est alloué en petits morceaux plutôt que des blocs énormes avec des tailles exponentiellement croissantes. Les anciennes versions de FotoWeb ne faisaient pas cela, donc les anciennes installations peuvent avoir de gros fichiers de données MongoDB qui sont pour la plupart inutilisés.
Important : ne supprimez jamais les fichiers de la base de données
MongoDB n’est PAS un cache – C’est une base de données. Des données précieuses telles que les albums, les exportations CMS et (à partir de la Feature Release 4) les utilisateurs et les groupes sont stockés dans MongoDB.
La suppression de fichiers de base de données entraîne la perte de données qui ne peuvent être restaurées qu’à partir d’une sauvegarde.
Stockage des fichiers de base de données MongoDB dans un autre emplacement
L’emplacement des fichiers de données MongoDB n’est pas configurable en soi. Cependant, vous pouvez créer un point de jonction du système de fichiers pour placer le dossier ailleurs.
Mémoire requise
MongoDB nécessite environ 1 Go de RAM pour 100 000 actifs. Si le système doit commencer à échanger de la mémoire sur le disque, cela aura un impact très négatif sur les performances et doit être évité.
Exigences relatives au fichier d’échange
En outre, il est important de suivre les exigences décrites par MongoDB pour la taille du fichier d’échange. Les informations suivantes sont copiées à partir des notes de production MongoDB :
Configurez le fichier d’échange de sorte que les tailles minimale et maximale du fichier d’échange soient égales et d’au moins 32 Go. Utilisez un multiple de cette taille si, lors d’une utilisation maximale, vous vous attendez à des écritures simultanées dans de nombreuses bases de données ou collections. Cependant, la taille du fichier d’échange n’a pas besoin de dépasser la taille maximale de la base de données.
Un fichier d’échange volumineux est nécessaire car Windows nécessite suffisamment d’espace pour accueillir toutes les régions de fichiers mappés en mémoire rendues accessibles en écriture pendant l’utilisation maximale, que des écritures se produisent ou non.
Le fichier d’échange n’est pas utilisé pour le stockage de la base de données et ne recevra pas d’écritures pendant le fonctionnement normal de MongoDB. En tant que tel, le fichier d’échange n’affectera pas les performances, mais il doit exister et être suffisamment volumineux pour prendre en charge les règles d’engagement de Windows lors de l’utilisation maximale de la base de données.
REMARQUE : Le dimensionnement dynamique des fichiers d’échange est trop lent pour prendre en charge les frais de validation fluctuant rapidement d’un déploiement MongoDB actif. Cela peut entraîner des situations de surengagement transitoire pouvant entraîner un arrêt brutal du serveur avec une erreur VirtualProtect 1455.
[source (en anglais) : disponible sur fotoware.com]