web-dev-qa-db-fra.com

Avantages et inconvénients de l'utilisation de MongoDB au lieu de MS SQL Server

Je suis nouveau dans le monde NoSQL et je pense remplacer ma base de données MS SQL Server par MongoDB. Mon application (écrite en .Net C #) interagit avec les caméras IP et enregistre les métadonnées pour chaque image provenant de la caméra, dans la base de données MS SQL. En moyenne, j'insère environ 86400 enregistrements par jour pour chaque caméra et dans le schéma de base de données actuel, j'ai créé un tableau séparé pour des images de caméra distinctes, par ex. Camera_1_Images, Camera_2_Images ... Camera_N_Images. L'enregistrement d'image unique se compose d'informations simples sur les métadonnées. comme AutoId, FilePath, CreationDate. Pour ajouter plus de détails à cela, mon application lance un processus séparé (.exe) pour chaque caméra et chaque processus insère 1 enregistrement par seconde dans la table relative de la base de données.

J'ai besoin de suggestions d'experts (MongoDB) sur les problèmes suivants:

  1. pour savoir si MongoDB est bon pour conserver de telles données, qui seront éventuellement interrogées par rapport aux plages de temps (par exemple, récupérer toutes les images d'une caméra particulière entre une heure spécifiée)? Des suggestions sur la conception de schéma basé sur le document pour mon cas?

  2. Quelles devraient être les spécifications du serveur (CPU, RAM, disque)? toute suggestion?

  3. Dois-je envisager le partage/la réplication pour ce scénario (tout en considérant les performances en écriture pour synchroniser les jeux de réplicas)?

  4. Y a-t-il des avantages à utiliser plusieurs bases de données sur la même machine, de sorte qu'une base de données contiendra des images de la journée en cours pour toutes les caméras, et la seconde sera utilisée pour archiver les images de la veille? Je pense à cela en ce qui concerne le fractionnement des lectures et des écritures sur des bases de données distinctes. Parce que toutes les demandes de lecture peuvent être traitées par la deuxième base de données et écrites dans la première. En bénéficiera-t-il ou non? Si oui, alors une idée pour s'assurer que les deux bases de données sont toujours synchronisées.

Toutes autres suggestions sont les bienvenues s'il vous plaît.

sqlmongodbschema
34
theGeekster

Je suis moi-même un débutant sur les bases de données NoSQL. Je réponds donc à cela au détriment de votes négatifs potentiels, mais ce sera une grande expérience d'apprentissage pour moi.

Avant de faire de mon mieux pour répondre à vos questions, je dois dire que si MS SQL Server fonctionne bien pour vous, respectez-le. Vous n'avez mentionné aucune raison valable POURQUOI vous souhaitez utiliser MongoDB, sauf le fait que vous l'avez appris en tant que base de données orientée document. De plus, je vois que vous avez presque le même ensemble de métadonnées que vous capturez pour chaque caméra, c'est-à-dire que votre schéma est dynamique.

  • pour savoir si MongoDB est bon pour conserver de telles données, qui seront éventuellement interrogées par rapport aux plages de temps (par exemple, récupérer toutes les images d'une caméra particulière entre une heure spécifiée)? Des suggestions sur la conception de schéma basé sur le document pour mon cas?

MongoDB étant une base de données orientée document, il est bon d'interroger dans un agrégat (vous l'appelez document). Puisque vous stockez déjà les données de chaque caméra dans sa propre table, dans MongoDB, vous aurez une collection distincte créée pour chaque caméra. Voici comment vous effectuez des requêtes de plage de dates.

  • Quelles devraient être les spécifications du serveur (CPU, RAM, disque)? toute suggestion?

Toutes les bases de données NoSQL sont conçues pour évoluer sur du matériel standard. Mais par la façon dont vous avez posé la question, vous pensez peut-être à améliorer les performances en augmentant . Vous pouvez commencer avec une machine raisonnable et à mesure que la charge augmente, vous pouvez continuer à ajouter plus de serveurs (évolutivité). Vous n'avez pas besoin de planifier et d'acheter un serveur haut de gamme.

  • Dois-je envisager le partage/la réplication pour ce scénario (tout en considérant les performances en écriture pour synchroniser les jeux de réplicas)?

MongoDB verrouille la base de données entière pour une seule écriture (mais cède pour d'autres opérations) et est destiné aux systèmes qui ont plus de lectures que d'écritures. Cela dépend donc de l'état de votre système. Il existe plusieurs façons de partager et devrait être spécifique au domaine. Une réponse générique n'est pas possible. Cependant certains exemples peuvent être donnés comme le sharding par géographie, par branches etc.

Lisez aussi ne introduction en anglais au CAP Theorem

Mis à jour avec la réponse au commentaire sur le partage

Selon leur documentation , vous devriez envisager de déployer un cluster partagé, si:

  • votre ensemble de données approche ou dépasse la capacité de stockage d'un seul nœud de votre système.
  • la taille de l'ensemble de travail actif de votre système dépassera bientôt la capacité maximale de RAM pour votre système.
  • votre système a une grande quantité d'écriture, une seule instance MongoDB ne peut pas écrire des données assez rapidement pour répondre à la demande, et toutes les autres approches n'ont pas réduit les conflits.

Donc, sur la base du dernier point, oui. La fonction de partitionnement automatique est conçue pour mettre à l'échelle les écritures. Dans ce cas, vous avez un verrou en écriture par shard, pas par base de données. Mais la mienne est une réponse théorique. Je vous suggère de consulter le groupe 10gen.com.

29
Aravind R. Yarram

pour savoir si MongoDB est bon pour conserver de telles données, qui seront éventuellement interrogées par rapport aux plages de temps (par exemple, récupérer toutes les images d'une caméra particulière entre une heure spécifiée)?

Cette question est trop subjective pour que je puisse y répondre. D'après mon expérience personnelle avec de nombreuses solutions SQL (ironiquement pas MS SQL), je dirais qu'elles sont toutes deux aussi bonnes, si elles sont bien faites.

Également:

Quelles devraient être les spécifications du serveur (CPU, RAM, disque)? toute suggestion?

Cela dépend de trop de variables que vous seul connaissez, mais un petit groupe de matériel de base fonctionne assez bien. Je ne peux pas vraiment donner une réponse factuelle à cette question et cela dépendra de vos tests.

Quant au schéma j'irais pour un document de la structure:

{
    _id: {},
    camera_name: "my awesome camera",
    images: [
        { 
            url: "http://I_like_S3_here.amazons3.com/my_image.png" ,
            // All your other fields per image
        }
    ]
}

Cela devrait être assez facile à maintenir et à mettre à jour tant que vous n'incorporez pas beaucoup plus profondément, car cela pourrait devenir un peu pénible, cependant, cela dépend de vos requêtes.

Non seulement cela, mais cela devrait être bon pour le partage, car vous avez toutes les données dont vous avez besoin dans un seul document, si vous deviez partager le _id vous pourriez probablement obtenir la configuration parfaite ici.

Dois-je envisager le partage/la réplication pour ce scénario (tout en considérant les performances en écriture pour synchroniser les jeux de réplicas)?

Il est possible que de nombreuses personnes supposent qu'elles doivent tailler des fragments alors qu'en réalité, elles doivent simplement être plus intelligentes dans la façon dont elles conçoivent la base de données. MongoDB est une forme très libre, il existe donc de nombreuses façons de le faire mal, mais cela étant dit, il existe également de nombreuses façons de le faire correctement. Personnellement, je garderais à l'esprit le partage. La réplication peut également être très utile.

Y a-t-il des avantages à utiliser plusieurs bases de données sur la même machine, de sorte qu'une base de données contiendra des images de la journée en cours pour toutes les caméras, et la seconde sera utilisée pour archiver les images de la veille?

Même si le verrouillage en écriture de MongoDB est au niveau de la base de données (actuellement), je dirais: Non. La bonne structure de document et la partition/réplication appropriée (si nécessaire) devraient être capables de gérer cela dans une seule collection basée sur un document sous une seule DB. Non seulement cela, mais vous pouvez diriger les écritures et les lectures au sein d'un cluster vers certains serveurs afin de créer une situation de concurrence entre certaines machines de votre cluster. Je voudrais promouvoir l'utilisation correcte des fonctionnalités de concurrence de MongoDB sur la séparation de bases de données.

Modifier

Après avoir relu la question, j'ai omis de ma solution que vous insériez 80k + d'images pour chaque caméra par jour. En tant que tel, au lieu de l'option intégrée, je créerais en fait une ligne par image dans une collection appelée images puis une collection camera et interrogerais les deux comme vous le feriez en SQL.

Le partage de la collection images devrait être tout aussi facile sur camera_id.

Assurez-vous également de prendre votre ensemble de travail en considération avec votre serveur.

4
Sammaye

pour savoir si MongoDB est bon pour conserver de telles données, qui seront éventuellement interrogées par rapport aux plages de temps (par exemple, récupérer toutes les images d'une caméra particulière entre une heure spécifiée)? Des suggestions sur la conception de schéma basé sur le document pour mon cas?

MongoDB peut le faire. Pour de meilleures performances, vous pouvez définir un index sur votre champ horaire.

Quelles devraient être les spécifications du serveur (CPU, RAM, disque)? toute suggestion?

Je pense que RAM et le disque seraient importants.

  • Si vous ne voulez pas faire sharding à scale out, vous devriez envisager une plus grande taille de disque afin de pouvoir y stocker toutes vos données.
  • Vos données chaudes devraient pouvoir tenir dans votre RAM. Sinon, vous devriez envisager un plus grand RAM parce que les performances de MongoDB dépendent principalement de la RAM.

Dois-je envisager le partage/la réplication pour ce scénario (tout en considérant les performances en écriture pour synchroniser les jeux de réplicas)?

Je ne connais pas beaucoup de caméras, même 1000 insertions/seconde avec un total de 1000 caméras devraient toujours être faciles pour MongoDB. Si vous vous intéressez aux performances des insertions, je ne pense pas que vous ayez besoin de faire du sharding (sauf que la taille des données est trop grande pour que vous deviez les séparer en plusieurs machines).

Un autre problème est la fréquence de lecture de votre application. Si elle est très élevée, vous pouvez envisager de partager ou de répliquer ici. Et vous pouvez utiliser (horodatage + camera_id) comme clé de partitionnement si votre requête ne concerne qu'une seule caméra dans une plage de temps.

Y a-t-il des avantages à utiliser plusieurs bases de données sur la même machine, de sorte qu'une base de données contiendra des images de la journée en cours pour toutes les caméras, et la seconde sera utilisée pour archiver les images de la veille?

Vous pouvez séparer la table en deux collections (archive et current). Et définissez l'index uniquement sur archive si vous interrogez uniquement la date sur archive. Sans la surcharge de la création d'index, la collection current devrait bénéficier de l'insertion.

Et vous pouvez écrire un programme quotidien pour vider les données current dans archive.

3
Chien-Wei Huang