Solution au problème d'E/S du disque MongoDB

C'est un peu un titre, mais les trois conseils suivants sont en effet plus pratiques. Le contenu provient d'un partage de Colin Howe, vice-président de Conversocial, dans le groupe d'utilisateurs MongoDB de Londres.

Application : Les points suivants ne sont pas universellement applicables. Leur utilisation dépend de vos propres scénarios d'application et des caractéristiques des données.

1. Utilisez des documents volumineux combinés

Nous savons que MongoDB est une base de données de documents et que chacun de ses enregistrements est un document au format JSON. Par exemple, comme dans l'exemple suivant, une donnée statistique sera générée chaque jour :

{ métrique : "content_count", client : 5, valeur : 51, date : ISODate("2012-04- 01 13:00") }

{ métrique : "content_count", client : 5, valeur : 49, date : ISODate("2012-04-02 13:00") }

Et si une combinaison est utilisée. S'il s'agit d'un document volumineux, vous pouvez enregistrer toutes les données d'un mois dans un seul enregistrement comme ceci :

{ métrique : "content_count", client : 5, mois : "2012-04" , 1 : 51, 2 : 49, ... >

Stockés via les deux méthodes ci-dessus, un total d'environ 7 Go de données ont été stockés à l'avance (la machine ne dispose que de 1,7 Go de mémoire), et le test de lecture d'un an d'informations. La différence de performances de lecture entre les deux Évidemment :

Premier type : 1,6 seconde

Deuxième type : 0,3 seconde

Alors, quel est le problème ?

La véritable raison est que le stockage combiné permet de lire moins de documents lors de la lecture des données. Si le document ne peut pas être complètement stocké dans la mémoire, le coût est principalement consacré à la recherche sur disque. Lors de l'obtention d'un an de données, la première méthode de stockage nécessite la lecture de plus de documents, donc le nombre de recherches sur disque est également plus important. . Donc plus lent.

En fait, foursquare, un utilisateur bien connu de MongoDB, utilise largement cette méthode pour améliorer les performances de lecture. Voir ceci

2. Utilisez une structure d'index spéciale

Nous savons que MongoDB, comme les bases de données traditionnelles, utilise des B-trees comme structures de données d'index. Pour les index arborescents, plus le stockage de l'index utilisé pour sauvegarder les données chaudes est centralisé, plus la mémoire gaspillée par l'index est réduite. Nous comparons donc les deux structures d'index suivantes :

db.metrics.ensureIndex({ metric: 1, client: 1, date: 1})

et

db. metrics.ensureIndex({ date : 1, metric : 1, client : 1 })

utilise ces deux structures différentes, et la différence de performances d'insertion est également évidente.

Lors de l'utilisation de la première structure, lorsque le volume de données est inférieur à 20 millions, la vitesse d'insertion peut essentiellement être maintenue à 10 k/s. Lorsque le volume de données augmente à nouveau, la vitesse d'insertion diminue lentement jusqu'à 2,5 k/s. s. Lorsque la quantité de données augmente, ses performances peuvent être encore plus faibles.

Lors de l'utilisation de la deuxième structure, la vitesse d'insertion peut être fondamentalement stable à 10k/s.

La raison est que la deuxième structure place le champ de date en premier dans l'index, de sorte que lors de la construction de l'index, lorsque de nouvelles données mettent à jour l'index, il n'est pas mis à jour au milieu, mais uniquement à la fin de l'index. Apportez des modifications. Les index insérés trop tôt nécessitent peu de modifications lors des opérations d'insertion ultérieures. Dans le premier cas, comme le champ date n'est pas au premier plan, la mise à jour de l'index se produit souvent au milieu de l'arborescence, ce qui entraîne de fréquents changements à grande échelle dans la structure de l'index.

3. Réserver de l'espace

Identique au point 1. Ce point repose également sur le fait que le temps de fonctionnement principal des disques durs mécaniques traditionnels est consacré aux opérations de recherche de disque.

Par exemple, en reprenant l'exemple du point 1, lorsque nous insérons des données, nous insérons d'un coup tout l'espace requis pour les données de cette année. Cela garantit que nos données pour 12 mois de l'année sont dans un seul enregistrement et sont stockées séquentiellement sur le disque. Ensuite, lors de la lecture, nous n'avons peut-être besoin que d'une seule opération de lecture séquentielle sur le disque pour lire les données par an. Lors des 12 lectures précédentes, la recherche sur le disque n'est effectuée qu'une seule fois.

db.metrics.insert([

{ métrique : 'content_count', client : 3, date : '2012-01', 0 : 0, 1 : 0, 2 : 0, ... }

{ .................................., date : '2012 -02', ... })

{ .................................. ... , date : '2012-03', ... })

{ .......................... ... ....., date : '2012-04', ... })

{ ..................... .... ..........., date : '2012-05', ... })

{ .............. ....... ............., date : '2012-06', ... })

{ ......... ... ...................., date : '2012-07', ... })

{ ..... ............................, date : '2012-08', ... })

{ ............................, date : '2012-09', ... })

{ . ............................, date : '2012-10', ... })

{ . .................................., date : '2012-11', .. })

{ .................................., date : '2012 -12', ... })

])

Résultat :

Si la méthode de l'espace réservé n'est pas utilisée, il faut 62 ms pour lire les enregistrements d'un an

Si vous utilisez espace réservé, il ne faut que 6,6 ms pour lire l'équivalent d'un an d'enregistrements

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!