Corrigez l'orthographe, ça devrait être MongoDB.
Chaque base de données a ses propres avantages et inconvénients, et ses situations applicables sont également différentes. Puisque je suis du côté de MongoDB et que quelqu'un a mentionné MySQL et HDFS ci-dessus, j'analyserai les avantages de MongoDB par rapport à MySQL et HDFS dans l'analyse des données. La personne qui pose la question souhaitera peut-être voir si ces avantages correspondent à ce que vous souhaitez, puis prendre une décision en fonction de la situation réelle de votre projet.
MySQL est un SGBDR établi de longue date, avec des fonctionnalités communes aux SGBDR et une prise en charge complète d'ACID. Sa technologie a traversé une longue période de tests de précipitation et d'application, et est déjà à un stade d'application relativement stable. Le principal avantage du SGBDR par rapport à NoSQL dans les applications pratiques réside dans les transactions solides. Cependant, dans une application OLAP, les transactions fortes ne sont pas très utiles, mais elles entravent le support distribué. Dans le cadre d'un développement complet, l'expansion horizontale finira par devenir le principal goulot d'étranglement dans votre choix de MySQL. De plus, pour les applications telles que les robots d'exploration, les données non structurées sont généralement analysées, ce qui présente de grandes limitations en termes de stockage et d'interrogation des modèles relationnels. Mais il est également possible que les sites Web qui vous intéressent soient tous du même type de sites Web et que vous ne soyez intéressé que par un contenu spécifique des pages Web, afin qu'ils puissent être organisés en données structurées. MySQL est donc toujours compétent dans ce domaine. cet égard. Mais même ainsi, avec le développement des applications, la flexibilité du stockage des données sera encore sacrifiée à l'avenir. Par conséquent, pour les applications telles que les robots d’exploration, le principal problème de MySQL est que le modèle de données n’est pas assez flexible et ne peut pas (ou est difficile à) s’étendre horizontalement.
En ce qui concerne les deux principaux problèmes ci-dessus, HDFS peut réellement les gérer. Par conséquent, HDFS présente des avantages par rapport à MySQL dans des applications telles que les robots d'exploration. De même, MongoDB résout également très bien ces deux problèmes. Alors, quels sont les avantages de MongoDB par rapport à HDFS ? Un point très important vient du fait que MongoDB peut établir un index secondaire sur n'importe quel champ du document comme une base de données relationnelle, afin que les avantages en termes de performances apportés par l'index puissent être maximisés pendant le processus d'analyse. De plus, HDFS ressemble davantage à un système de fichiers, tandis que MongoDB fournit une technologie de base de données flexible. Des opérations telles que la répartition géographique et l'archivage de documents expirés peuvent être facilement mises en œuvre sur MongoDB.
D'un point de vue écosystémique, les outils périphériques de HDFS doivent être plus riches, après tout, où est l'historique de développement. MongoDB prend actuellement principalement en charge :

• Connecteur BI : MongoDB fournit une interface PostgreSQL ou MySQL avec le monde extérieur pour utiliser les outils BI existants

• Connecteur Spark : MongoDB se connecte à Spark pour le calcul

Pour en revenir à votre question, en toute honnêteté, l'efficacité n'est pas si grande au niveau d'un million à dix millions. Quelle que soit la base de données utilisée, il n'y aura aucune différence qualitative de performances si elle est utilisée correctement. Concernant les problèmes de disponibilité, la haute disponibilité de MongoDB peut permettre une récupération sur erreur de deuxième niveau. MySQL propose également des solutions correspondantes, mais le fonctionnement et la maintenance peuvent être plus compliqués. Il n'y a pas beaucoup de différence entre les entreprises en termes de sécurité.

MySQL deviendra très nerveux lors du traitement de grandes quantités de données. Au contraire, MongoDB devrait être meilleur via un cluster.

En fait, vous n'avez pas du tout besoin d'une base de données. Cela peut devenir un goulot d'étranglement d'E/S pour les robots d'exploration.

Vous pouvez essayer HDFS avec Hadoop.

Vous devez choisir Hadoop comme plate-forme de traitement. Dans ce cas, le stockage de données sous-jacent est généralement préférable d'utiliser la combinaison .mangodb+hadoop de MySQL pour la surveillance en temps réel, comme le barrage lors de la diffusion en direct du Gala de la Fête du Printemps, car mongodb prend en charge les requêtes de données au niveau de la milliseconde et l'analyse en temps réel. Hadoop l'écrit une fois et le récupère plusieurs fois. S'il est couplé à MySQL, il est plus adapté à votre projet. La sécurité est en réalité à peu près la même. Ce n'est pas grave si le pare-feu clé est sécurisé. Après tout, votre base de données est isolée. Je vous suggère donc de choisir MySQL.

Nous allons maintenant écrire un robot pour capturer une grande quantité de données (il est prévu qu'elle puisse atteindre l'ordre de 2 millions à 20 millions d'enregistrements plus tard)

Si vous ne disposez que de ce peu de données, MySQL ou MongoDB fonctionneront mais relativement parlant, MongoDB sera plus flexible.

La quantité de données entre 200w et 2000w est relativement faible. Vous pouvez déterminer laquelle des deux vous est la plus familière et utiliser celle-là. Mais fondamentalement, si la base de données atteint des dizaines de millions de niveaux, il y aura des problèmes de performances des requêtes, donc si les données continuent de croître, vous pouvez envisager d'utiliser mongodb. Après tout, il est beaucoup plus simple de créer un cluster fragmenté Mongodb qu'un cluster MySQL. Et c’est plus flexible à gérer.

1. Il n'est pas nécessaire d'utiliser hadoop pour un volume de données de 200 à 2 000 W, à moins que votre équipe ne soit familiarisée avec la pile technologique hadoop ;

2. Du point de vue des performances, ce niveau de données peut être utilisé à la fois par MySQL et mongoDB. La clé dépend si vos données sont structurées ou non. Relativement parlant, mongo est plus flexible

.

Il se trouve que l'entreprise pour laquelle je travaille a fait quelque chose dans ce domaine, et j'en suis responsable, je peux vous en parler à titre de référence.
Ce que je fais principalement ici, c'est le traitement et l'archivage des journaux, la réalisation de statistiques chaudes et froides sur les journaux d'accès générés chaque jour, la génération de divers rapports de données, etc. En fait, le robot est finalement similaire.
J'ai d'abord pensé à MYSQL, mais les performances d'une seule table MYSQL dépassant des dizaines de millions étaient médiocres, j'ai donc choisi d'utiliser mongodb à ce moment-là.
En fait, ce que vous faites est très simple. Vous utilisez simplement Python pour capturer régulièrement les journaux quotidiens du serveur localement, puis utilisez la bibliothèque pandas pour construire les données dans la structure de données souhaitée si vous avez besoin de calculer l'agrégation de groupe. , il suffit de les regrouper. Enfin, les résultats des données quotidiennes sont jetés dans mongodb.
L'entreprise dispose actuellement d'environ 8 KW de données mongodb. L'efficacité de la récupération des données est toujours acceptable.
En plus d'enregistrer les données dans mongodb, nous avons également écrit une API reposante utilisant flask pour appeler spécifiquement les résultats des statistiques de données pour le système d'exploitation. Le côté opération créera également une table sur MYSQL pour collecter les statistiques de notre mongodb. est à nouveau calculé en données totales et placé dans MYSQL, de sorte qu'il n'est pas nécessaire d'appeler mongodb pour effectuer des calculs d'agrégation répétés à chaque fois que les données sont récupérées de l'API.