Oui, j'ai voté contre parce que cette réponse induit les lecteurs en erreur. Quel que soit le type de base de données, le coût de création d'un index est énorme, car cela implique de parcourir les données dans toute la table, comment cela peut-il être possible sans trop de pression ? C’est pourquoi il existe l’option {background: true} pour atténuer cette situation de manière appropriée. Lors de la création d'un index dans un cluster soumis à trop de pression, nous recommandons d'utiliser la méthode de création d'index "rolling", qui supprime les nœuds un à un pour créer l'index puis le met en ligne pour ne pas affecter le fonctionnement du système en ligne. . En ce qui concerne le problème de verrouillage, à partir de la version 3.0, le moteur WT prend en charge les verrous de documents (verrouillage de ligne). Le coût d'interrogation de l'index est énorme. C'est probablement parce que votre index n'est pas établi correctement. Vous pouvez donner des exemples spécifiques à discuter. Lorsque les données dépassent 100 millions, il existe de nombreux pièges. Veuillez donner des exemples spécifiques à discuter.
Mongodb prend en charge l'architecture de partitionnement et de partitionnement automatique, qui peut être utilisée pour créer un système de cluster de bases de données évolutif horizontalement et stocker des tables de base de données sur chaque nœud de partitionnement.
Veuillez consulter le partage de MongoDB au lieu du partage de base de données [1] : https://yq.aliyun.com/article...
Vous pouvez diviser les tables par mois. Nom_03 Nom_04 Le nom reste inchangé Le nom de la table à interroger est modifié dynamiquement en fonction de l'horodatage dans le programme
Personnellement, je pense que c'est toujours nécessaire. MongoDB a le problème de verrouiller la base de données (version basse) et de verrouiller la table (version moyenne), même s'il y a des fragments pour stocker les fichiers, la surcharge de construction d'un index et de recherche. l'indice est toujours énorme ! ! ! ! Lorsque les données dépassent les 100 millions, les écueils restent encore nombreux !
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Oui, j'ai voté contre parce que cette réponse induit les lecteurs en erreur.
Quel que soit le type de base de données, le coût de création d'un index est énorme, car cela implique de parcourir les données dans toute la table, comment cela peut-il être possible sans trop de pression ? C’est pourquoi il existe l’option
{background: true}pour atténuer cette situation de manière appropriée. Lors de la création d'un index dans un cluster soumis à trop de pression, nous recommandons d'utiliser la méthode de création d'index "rolling", qui supprime les nœuds un à un pour créer l'index puis le met en ligne pour ne pas affecter le fonctionnement du système en ligne. .En ce qui concerne le problème de verrouillage, à partir de la version 3.0, le moteur WT prend en charge les verrous de documents (verrouillage de ligne).
Le coût d'interrogation de l'index est énorme. C'est probablement parce que votre index n'est pas établi correctement. Vous pouvez donner des exemples spécifiques à discuter.
Lorsque les données dépassent 100 millions, il existe de nombreux pièges. Veuillez donner des exemples spécifiques à discuter.
Mongodb prend en charge l'architecture de partitionnement et de partitionnement automatique, qui peut être utilisée pour créer un système de cluster de bases de données évolutif horizontalement et stocker des tables de base de données sur chaque nœud de partitionnement.
Veuillez consulter le partage de MongoDB au lieu du partage de base de données [1] : https://yq.aliyun.com/article...
Vous pouvez diviser les tables par mois. Nom_03 Nom_04 Le nom reste inchangé Le nom de la table à interroger est modifié dynamiquement en fonction de l'horodatage dans le programme
Personnellement, je pense que c'est toujours nécessaire. MongoDB a le problème de verrouiller la base de données (version basse) et de verrouiller la table (version moyenne), même s'il y a des fragments pour stocker les fichiers, la surcharge de construction d'un index et de recherche. l'indice est toujours énorme ! ! ! ! Lorsque les données dépassent les 100 millions, les écueils restent encore nombreux !