Datalake comparaison - 4 MongoDB

MongoDB est une base de données NoSQL distribuée. La grosse différence de cette base de
données c’est qu’ici on ne parle pas de table mais de collection et que les lignes sont appelées des
documents. Les documents sont des données enregistrées en format Json. Cela permet beaucoup
de souplesse dans le stockage de la donnée car le JSON, en effet le JSON n’a pas de structure
imposée. Le format s’adapte à la donnée : le nombre de colonnes et le type des données sont libres.
En contrepartie cela veut aussi dire qu’il faut gérer le contrôle des données soit même.
Si vous voyez des erreurs commises dans ce comparatif veuillez nous adresser un mail à
contact@domwee.com nous nous efforcerons de corriger le plus rapidement possible.

  1. Architecture simplifiée L’architecture de MongoDB est la suivante, il y a une application ou un client qui se charge de contacter tous les noeuds de l’instance MongoDB. Cela veut dire que l’application connait la liste des noeuds de l’instance MongoDB ou alors qu’il contacte un noeud qui lui communique tous les autres points de l’instance. Cette architecture donne plus de travail à la machine qui lance les requêtes sur l’instance et nécessite forcément d’installer un client lourd ou un driver assez élaboré pour faire fonctionner les requêtes. Nous regrettons l’absence d’index maître sur les collections et nous nous demandons forcément comment se fait la distribution des données sur les noeuds? Et surtout comment agir sur cette répartition? Ce choix n’aboutira qu’à une seule chose : des temps de requêtes inégaux et non contrôlés.
    1. BigData
      C’est pourquoi ce système a été pensé pour le BigData. A contre pieds des autres systèmes étudiés dans ce comparatif. il met en avant les données non structurées. Ce n’est pas le seul mais il se différencie par le choix du format Json. C’est un format simple et efficace et c’est aussi notre avis de la solution simple et efficace.
    2. Datawarehouse
      Pour nous il est Impossible de faire un datawarehouse avec les choix forts qui ont été fait. Le format Json non structuré ne garantit pas la fonction première d’un datawarehouse : l’harmonisation des données, de plus avec les documents à l’intérieur des documents pour réaliser les liens (par exemple un article qui aurait en sous éléments toutes les commandes passées sur cet article ou inversement) on se rend vite compte que les liens ne peuvent pas être parcourus que dans un seul sens et que l’on peut oublier le schéma en étoiles, on se retrouve avec une multitude de schéma à une étoile : une table principale de faits avec tous les liens se trouvant à l’intérieur. La maintenance de cet environnement sera un enfer en revanche MongoDB est très performant pour gérer des datamarts qui seraient formés à partir d’un datawarehouse bien structuré.
    3. Reporting
      Nous ne croyons pas vraiment qu’il soit possible de réaliser du reporting de masse sur des données non structurées. Quand on fait du reporting c’est pour afficher de l’information structurée, les rapports sont aussi structurés et normés. Il nous semble pas approprié de vouloir faire du reporting avec une solution qui se veut spécialisée dans les données non structurées et sur une solution qui ne permette pas de gérer les indexs de répartition des données : l’optimisation des temps de requête semblent être une tâche impossible.
    4. Datalake
      Contrairement au Reporting cette solution a toutes les caractéristiques pour réaliser un bon datalake en terme de possibilité de stockage (données non structurées et données structurées) et de capacité à traiter des gros volumes. Il existe des drivers JDBC et ODBC ce qui permet  à beaucoup d’outils de se connecter à cette solution. Pour les données multimédia en revanche il faudra les mettre ailleurs, cela dit tous ces concurrents font pareil et ce type de données n’est malheureusement pas encore traitable par les bases de données étudiées.
    5. Base de données Applicative
      Dans le cas d’une application cette solution a beaucoup d’atouts (simplicité, efficacité) surtout pour les applications qui traitent de nombreux utilisateurs en accès concurrents. En revanche et encore une fois une solution qui met en oeuvre beaucoup de serveurs est compliquée à installer et à maintenir et il n’existe pas beaucoup de fournisseurs cloud qui proposent cette solution managée.
  2. Utilisateurs
    Autant le dire tout de suite cette solution n’est pas à mettre entre toutes les mains, elle est destinée à être utilisée par des spécialistes ou des développeurs, le langage utilisé est propre à MongoDB et a besoin de boucles FOR qui en rebuteront plus d’un. C’est un vrai frein à son expansion.
  3. Fonctionnalités additionnelles
    - Géographiques : Oui
    - Graphes :
    - IP :
    - Window :
    - ML : 
  4. Administrateur
    Pour administrer ce genre de solutions avec autant de serveurs à maintenir il faut un administrateur au chevet de cette application.
  5. Experts quand pourquoi
    Bien que l’idée de base est ultra simple à savoir exploiter des Json qui est un des formats les plus simples à l’heure actuel et c’est ce qu’il fait son succès aujourd’hui, le choix de faire des requêtes utilisant les boucles FOR et le fait qu’il faille créer des index quelquefois pour optimiser les résultats (index à voir comme ceux utilisés dans les SGBDR classiques, nous ne parlons pas ici des index de répartition des données entre les noeuds) fait que cette solution est à destination d’experts et uniquements d’experts. Cela ne laisse pas la place à des utilisateurs occasionnels.
  6. Droits et sécurité
    Quand les droits d’une solution sont en options comme sur MongoDB cela ne laisse planer aucun doute sur le fait que cette solution est utilisée d’abord et avant tout par un ou deux spécialistes dans chaque entreprise et que système n’est pas ouvert par défaut. Néanmoins les droits sont très complets Premier niveau de droits les ressources : autorisation au niveau base de données, collections et même cluster. Seul le niveau document manque à l’appel mais c’est presque le cas de partout aucun éditeur ne semble voir l’intérêt de partager les données au niveau lignes. Nous avons presque un élément de réponse avec le partage au niveau cluster mais cela voudrait dire qu’il faudrait concentrer toutes les données utiles pour chaque utilisateur sur le même cluster et nous perdrions tout l’intérêt d’une base de données répartie. Il ne semble pas y avoir la possibilité de mettre en place un SSO nativement.
  7. Logs et alertes
    Tout est réparti MongoDB fonctionne aussi en fail over avec des bases de données répliquées en temps réel. Tous ces systèmes de sécurité permettent au système de ne pas avoir de points de vulnérabilité mais hélas cela se paye au niveau des logs ils sont aussi répartis sur tous les serveurs. Il faut donc tout rapatrier au même endroit pour pouvoir avoir une analyse complète ou créer des alertes sur chaque serveur. C’est une tâche à prévoir car l’outil ne le fait pas de manière standard.
  8. Coût et gestion
    Cette solution reste coûteuse pour les petites entreprises parce qu’elle demande d’avoir beaucoup de serveurs mais elle propose une bonne robustesse car il est très facile de répliquer des noeuds ou de les redonder.
  9. Fin d’utilisation
    Tout est en JSON, ce n’est pas le format le plus utilisé dans les outils data mais en revanche il existe de nombreux outils informatiques utilisant ce format que l’on peut considérer comme un format standard. Attention toutefois aux documents qui possèdent des documents lors d’un transfert de données provenant de MongoDB vers une solution structurée.
  10. Documentation et API
    En terme de documentation il y a le strict minimum et côté API c’est bien fournie mais le site de documentation affiche un nombre de publicités qui sont assez imbuvables et cela fait chuter la note.
Les notes vont de 0 à 5 (5 étant la meilleure)

1.1
B
I
G
D
A
T
A
1.2
DWH
1.3
R
E
P
O
R
T
1.4
D
A
T
A
L
A
K
1.5
A
P
P
S
2
U
T
I
L
I
S
A
3
F
O
N
C
T
+
4
A
D
M
5
E
X
P
E
R
T
6
D
R
O
I
T
S
7
L
O
G
S
8
C
O
U
T
9
F
I
N
10
D
O
C
MongoDB
4
1
2,5
5

1

1
2
3
0,5
1
3,5
2,5

Conclusion : Cette solution n’a pas beaucoup de bonnes notes parce que nous jugeons ici les plateformes de gestion de données et qu’elle n’a pas été développée dans ce but. Nous sommes cela dit convaincus que cette solution de par sa robustesse et sa capacité à gérer les gros volumes et les pics de charge qu’elle est une solution très adaptée à l’hébergement d’une application qui a un modèle de données ultra simple et qui gère de nombreux utilisateurs ce qui est d’après nous ce pourquoi elle a été pensée et développée.

 Plan :
1 introduction


Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Datalake comparaison - 10 Conclusion

Franchement nous avions d’énormes à priori avant de commencer ce comparatif et honnêtement le résultat nous surprend nous même. Toutes les solutions analysées présentent des intérêts et aucune ne peut prétendre être la solution ultime, c’est d’ailleurs celle qui veut tout faire à la fois qui pour nous est la moins intéressante. Nous ne pouvons que saluer les efforts d’innovations que les différents éditeurs ont trouvées et nous les remercions de proposer des outils qui permettent de traiter nos chères données. En effet nous parlons toujours comme si LA donnée était une seule entité et devait se traiter de la même manière mais c’est faux il y a plusieurs types de données : les chaudes qui sont consommées immédiatement, les froides qu’on ne va voir qu’une fois de temps en temps, il y a aussi des données qui servent à tirer des tendances, il y a des données qui servent à savoir ce qu’il s’est passé pour trouver une cause au problème, il y a des données confidentielles, il y a d...
Lire la suite

Load Balancer

Image
Le load balancer est un composant majeur dans Google Cloud platform , Il participe comme son nom l’indique à router les utilisateurs sur une ressource disponible. Il participe également à la bonne santé du système complet car son premier rôle est de servir de point d’entrée ce qui simplifie grandement la vie des utilisateurs et des développeurs. C’est un aiguilleur qui dirige les utilisateurs vers la bonne ressource. C’est un organe essentiel  d’une solution cloud. De plus lors d’un changement de logiciel ou de mise à niveau cela évite aux utilisateurs de devoir changer leurs raccourcis et leurs habitudes. Il permet donc de faire des déploiements sans rupture de service. Après le déploiement, les utilisateurs ne changent rien à leurs habitudes et le load balancer envoie toutes leurs demandent à la nouvelle application et un lien direct peut être mis en place pour certains utilisateurs qui ont encore besoin de se connecter à l’ancienne application. ...
Lire la suite

Data loss prevention API

Image
Les entreprises traitent de plus en plus leur données automatiquement. Plusieurs profils peuvent être amenés à “jouer” avec leurs données : data scientists internes, data scientists externes ou entreprises spécialisées dans ce domaine. Par faute de temps ou par manque d’outil les données fournies ne sont pas toujours pré traitées et sont souvent envoyées telles quelles, or cela a deux inconvénients : le premier (que tout le monde avait trouvé) transmettre des informations importantes inutiles et donc augmenter le risque de fuite d’information, Le deuxième c’est qu’une donnée trop riche nuit à son traitement. Je donne un exemple pour un ordinateur un numéro de téléphone est une suite de 4 numéros et s’ils ne sont pas contextualisé il prendra cela pour 4 numéros de 2 chiffres. Dans certains cas il est préférable de remplacer ces 4 séries de chiffres par un libellé comme NumTéléphone pour faire comprendre à l’algorithme que c’est l’information de la présence de numéro...
Lire la suite