Datalake comparaison - 2 les SGBDR classiques

Dans ce chapitre nous allons nous consacrer aux systèmes de gestion de bases de données
relationnelles classiques, toutes ces bases de données ont des moteurs différents mais partagent la
même logique et ont les mêmes contraintes quand il s’agit d’exploiter les données BigData et celles
des Datalakes.
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.
Cela va sembler bizarre à certaines personnes et bien que nous ne soyons pas dupes devant les
tours de passe-passe marketing de Microsoft, nous avons décidé de sélectionner MS Datalake SQL
dans notre étude. En effet et bien que ce soit une myriade de vieux outils rassemblés nous pensons
qu’il est pertinent de l’inclure dans l’étude. Enfin nous ne nous intéresserons qu’à la partie qui nous
concerne, c’est à dire la base de données relationnelle, même si ce n’est au final qu’une base de
données SQL server boostée à l’extrême.
La liste des solutions étudiées est la suivante : 
- PostgresSQL
- MYSQL / MariaDB
- Oracle
- MS Datalake / MS Sql Server
  1. Architecture
    Bien que le moteur soit différent pour chacune de ces bases de données leur logique reste la même, elles utilisent toutes une architecture classique des années 1990 à 2010. Dans ces années là tout était mis sur un seul serveur, il y a eu des améliorations par la suite que nous expliquerons mais voyons l’architecture simplifiée dans un premier temps : Dans ce schéma on retrouve deux types de mémoire la première est le disque dur c’est une mémoire ou les données sont inscrites physiquement cela veut dire que même si l’ordinateur s’éteint les données ne s’effacent pas. Cette mémoire est bon marché et ces disques peuvent stocker un large volume de données. La RAM qui est le deuxième type de mémoire est extrêmement rapide et est de type volatile cela veut dire que les données sont perdues si l’ordinateur est éteint, elle est plus chère à produire que la mémoire de type disque dur et coûte plus cher à maintenir vu que c’est une mémoire active elle consomme de l’électricité constamment. Autre inconvénient elle a une taille limitée dans chaque ordinateur, elle est cependant indispensable car faire des calculs sur un disque dur n’est pas envisageable, ils sont beaucoup plus lents que la mémoire vive pour écrire, remplacer ou chercher l’information. Nous pouvons facilement comparer cela à utiliser son cerveau pour répondre à une question ou utiliser un cahier.
    Vous l’aurez donc compris les données de base avant traitement se trouvent sur le disque dur, ces données sont lues depuis le disque dur et sont envoyées dans le bus de données pour être traitées par le couple CPU+RAM qui traite les données. Deuxième déduction lire les données depuis le disque dur est long. Conclusion pour traiter du BigData avec ce genre de bases de données il faut des bêtes de course (tout se fait sur une seule machine) avec une quantité de RAM faramineuse. C’est une architecture simple qui a fait ses preuves depuis des années et elle est redoutable pour faire des requêtes simples. Sa simplicité est à la fois son principal atout et sa principale faiblesse. Elle a été optimisée en mettant plus de processeurs dans la même machine ou en utilisant un groupe de disque durs (baie de disques) à la place d’un seul pour augmenter le nombre de têtes de lectures, Les SSD ont aussi améliorer l’efficacité mais il reste toujours des goulots d’étranglement comme le bus de données entre les données et le couple processeur + RAM. Généralement il s’agit d’un lien fibre optique qui est limité à 1 Gb/s ce qui correspond environ à 130 Mo/s. L’autre point faible est le nombre d’I/O (input ouput nombre d’entrées sorties par secondes) des disques dur, cela dépend du nombre de disques utilisés et de la répartition des données entre les disques durs. Heureusement cette partie assez complexe est gérée par des professionnels à notre place dans les solutions clés en main comme MS Datalake ou cloud SQL chez GCP. D’ailleurs cela peut paraître surprenant mais Google vous conseille quand vous créez une base de données cloud SQL de réserver beaucoup plus d’espace que nécessaire pour augmenter ce nombre d’I/O. Il vous incite volontairement à ne pas remplir vos disques durs. Bon bref cette partie cruciale ne sera pas jugée ici car elle dépend plus du savoir faire de votre expert stockage de données que du choix de la solution, nous retiendrons comme critère qu’il est nécessaire d’avoir un expert très compétent et ils sont assez rare sur le marché dans ce domaine.
    1. BigData
      Première déduction du schéma d’architecture : il faut avoir assez de RAM pour charger tout le jeu de données à l’intérieur. Si le jeu de données est trop gros pour la RAM l’ordinateur va créer une zone de “mémoire vive” sur le disque dur et il va perdre énormément de son efficacité, c’est exactement ce qu’il se passe quand on ouvre trop d’onglets en même temps de son navigateur web préféré on dit que l’ordinateur “swap”. Le deuxième souci de cette architecture est la lecture des données des disques dur + du bus de données, cela est le goulot d’étranglement. Dans le meilleur des cas, c’est ce qui se passe rarement dans la vraie vie, le traitement  d’un volume d’environ 1 To de données avec un taux de transfert estimé à 130 Mo/s il faut 1000000/130 soit environ 2 heures pour charger les données en mémoire avant de faire le moindre traitement. Il est vrai qu’il existe des moyens de ne pas tout charger grâce aux index mais imaginons que vous vouliez faire une recherche d’un mot dans un texte cela ne vous sera d’aucune utilité. Les index ne sont pas non plus l’arme absolue, il faut les maintenir et un index dans le cas de chargement par streaming est fortement perturbé, il faudra le recréer très souvent et sur des tables assez grosses cela prend du temps. En ce qui concerne l’ingestion de données justement cette architecture centralisée n’est pas l’idéal pour gérer des milliers de sollicitations par seconde que ce soit en batch ou en streaming. En effet les opérations d’écritures ne sont pas parallélisables sur ce type d’architecture.
    2. Datawarehouse
      Cette architecture a fait ses preuves depuis des dizaines d’années dans ce domaine. Que ce soit pour gérer les schémas en étoile, les mises à jour et les requêtes. De plus tous les acteurs du marché savent se connecter à ce type de bases de données et ont des moteurs optimisés pour cette architecture.
    3. Reporting
      Bien que les fondeurs s’amusent à vous dire que leurs processeurs sont les meilleurs et qu’ils savent tout faire en même temps les CPU actuels sont créés pour faire des opérations complexes rapidement et pas pour faire des opérations simples en parallèle donc votre processeur ne pourra s’occuper que d’une seule requête en même temps. Imaginons que votre serveur de base de données ait 8 processeurs il ne pourra traiter que 8 requêtes en parallèle sans perte d’efficacité sinon il va couper un processeur en 2 : 1 action sur 2 sera utilisée pour chaque requête sans compter les opérations de gestion que cela occasionne). Il est évident que faire plusieurs requêtes en même temps divisera aussi la RAM et multipliera les accès aux disques durs. Il est donc possible qu’une super requête qui rentrait dans l’espace RAM il y a un mois ne passe plus depuis 3 jours car une grosse requête est lancée en même temps que celle ci. Donc tout cela est à surveiller et ce n’est malheureusement pas le fournisseur de service cloud qui le fera pour vous. Vous l’aurez compris ces bases de données gèrent assez mal les accès concurrents c’est d’ailleurs pour cela que la réponse la plus utilisée dans ce cas là est de créer un réplica en lecture seule de la base de données principale pour ne pas pénaliser l’outil de production. Côté compatibilité on est au top tous les outils du marché se connectent parfaitement et facilement à ces bases de données. 
    4. Datalake
      Pour les données structurées ces bases de données font très bien le travail. Tous les outils du marché sont compatibles. En revanche nous vous déconseillons de stocker des fichiers en format blob dans les bases de données et nous préférons utiliser des espace de stockage dropbox ou autre pour cette partie là. Pas de stockage de JSON. Aucune fonctionnalités de machine learning intégrées dans ces bases de données. 
    5. Base de données Applicative
      Les SGBDR sont très bons pour héberger des petits aux moyens sites web ou des gros ERP. En revanche ils ne sont pas utilisés pour héberger des twitter, Amazon, youtube ou Gmail. Même constat pour les jeux et c’est lié à l’architecture pour gérer quelques milliers de joueurs en parallèle on se tournera vers une autre solution mais hormis ces cas extrêmes ces bases de données feront un excellent travail.
  2. Utilisateurs
    Le langage utilisé est le SQL ce qui est l’idéal, il est reconnu depuis très longtemps et a fait ses preuves. Bien entendu tous les outils des utilisateurs pourront se connecter à ces SGBDR qui existent depuis des années et sont incontournables.
    En revanche ces SGBDR ne proposent que des outils clients à installer pour faire des requêtes, ce n’est pas l’idéal à déployer ni à maintenir. Seul Mysql peut tirer son épingle du jeu avec des sites web de type LAMP mais l’outil n’est pas génial pour faire des requêtes, d’ailleurs ce n’est pas sa vocation première.
    Les SGBDR étudiés peuvent être bloqués par une grosse requête ou une requête mal écrite et ce n’est pas rare, effectivement il arrive parfois d’oublier une condition de jointure et la requête qui ne devrait durer que 30 secondes durent 10 minutes. Dans ce cas là il n’est généralement pas possible d’annuler la requête directement et le mieux à faire est de tuer l’outil client pour qu’un démon tue les requêtes orphelines. Sinon il faut demander à l’administrateur de tuer la requête directement. 
  3. Fonctionnalités additionnelles
    Ici ne seront traitées que les fonctionnalités natives présentent dans le moteur de la base de données, sinon ce tableau n’aura aucun sens puisqu’avec du développement ou des addons on pourrait tout faire avec n’importe quelle base de données.
    - Géographiques : Sql server, Oracle, Postgres, MySql, MariaDb
    - Graphes :
    - IP :
    - Window : sql server, Oracle, Postgres, MySql, MariaDb
    - ML : MariaDb
  4. Administrateur
    Un administrateur de base de données est essentiel tous les jours pour s’assurer du bon fonctionnement de ces bases de données. Plus les bases en ont besoin plus la note sera basse.
  5. Experts quand pourquoi
    Un expert est vivement conseillé surtout quand on s’attaque au BigData avec ces outils qui n’ont pas été développés dans cette optique, il faut optimiser les requêtes par des index, il faut entretenir ces index, il faut soigner les I/O, il faut organiser les ressources et bien définir les plages d’utilisation des requêtes pour éviter les pics de charge au maximum. 
  6. Droits et sécurité
    Au niveau des droits on a ce qu’il se fait de mieux on peut gérer à l’objet directement. MS Datalake est même en avance par rapport aux autres bases de données car il permet d’utiliser un annuaire d’entreprise l’active directory.
  7. Logs et alertes
    C’est un des points faibles de ces bases de données, les logs au moment de leur création n’était pas aussi importantes que maintenant. En plus ces logs coûtaient cher en stockage et en ressource ) l’époque, c’est moins vrai aujourd’hui mais ils ne sont pas vraiment améliorés depuis. C’est un outil réservé aux experts et ils sont souvent en forme de fichier txt pas toujours très simples à lire. 
  8. Coût et gestion
    Seules les grosses entreprises pourront se payer Oracle puisque le coût de la licence est très élevée. Postgres et MariaDb sont open source et contrôlées par des associations à but non lucratif. Sql server se situe entre les deux il propose une licence abordable pour les petites entreprises.
  9. Fin d’utilisation
    L’énorme reproche que nous ferons à ces bases de données c’est ce point. Ils se sont mis tous d’accord pour utiliser un format presque standard comme langage et ils n’ont pas su se mettre autour d’une table pour trouver un format standard d’échange ou de stockage de données. Chaque solution a son fichier d’export propriétaire (dump, backup…)  qui n’est en général pas utilisable par une autre solution. Dans certains cas il est possible d’exporter la base en SQL mais comme le SQL est un peu différent entre les bases de données il faut le retoucher et c’est une tâche fastidieuse. Heureusement que tous les ETL du marché sont compatibles et permettent de s’en sortir.
  10. Documentation et API
    Postgres est loin devant avec une documentation complète en plusieurs langues et des API bien fournies. MariaDB a une documentation en anglais et des APIS bien expliqués. Nous ne sommes pas fans de la documentation et du site d’Oracle, y a trop d’informations et comme tous leurs produits s’appellent Oracle cela gêne à la recherche, sinon il y a toutes les informations nécessaires. Microsoft a un site de documentation rapide et complet. Sur MariaDB et postgresql les deux bases de données de dernière génération ces bases sont bien dotées en revanche il n’y a pas grand chose pour les bases de données historiques.
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
Postgresql
1
4
3
3

2

1
1.5
4
0.5
5
2,5
5
Oracle
1
4
3
3

3

1
1.5
4
0.5
1
2,5
3
MariaDB
1
4
3
3

2

1
1.5
4
0.5
5
2,5
4,5
Azure Data Lake
Analytics
2
5
3,5
3

3

2
2
5
0.5
2,5
2,5
3,5
Conclusion : Ces bases de données font très bien ce pour quoi elles ont été développées à savoir l’hébergement d’applications standard et l’hébergement de datawarehouse classique avec une volumétrie de quelques millions de lignes. Si vous avez besoin d’autres fonctionnalités il faudra vous tourner vers d’autres solutions.

 Plan :
1 introduction
2 SGBDR classiques

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