Systèmes

d’information
Ecole Nationale Supérieure de
Génie Mathématiques et
Modélisation (ENSGMM)

M. Abel KONNON
Maître de Conférences

Cours de Semestre 9/ Cycle d’ingénieur

E-mail: mkonnon@gmail.com
© 2024
 De nouveaux besoins en gestion de données

• Nouveaux besoins en gestion de données

• Limites des SGBD Relationnels-transactionnels

• Le théorème de Brewer ou de CAP

• Le grand paysage des bases de données

• Caractéristiques générales des BD NoSQL

AABD©mkonnon@gmail.com 2
 II- De nouveaux besoins en gestion de données

2.4 Le grand paysage des bases de données

Rappel: Architecture multi-tiers

AABD©mkonnon@gmail.com 3
 II- De nouveaux besoins en gestion de données
2.4.1 Rappel: Architecture multi-tiers

Les services en ligne et, par extension, les applications web

reposent souvent sur une pile de technologies dont chaque

niveau est le middleware d’un tiers donné.

On distingue 3-tiers:
• la présentation,
• le métier et
• la persistance.
 II- De nouveaux besoins en gestion de données
2.4.1 Rappel: Architecture multi-tiers

Le tiers de présentation expose à l’utilisateur une IHM

dynamique et interprète les actions de l’utilisateur en termes

d’événements métier.

Illustration: Le tiers de présentation pour les applications web:

le front-end est un serveur hébergeant un serveur web Apache

qui exécute du PHP pour le rendu des pages web

 II- De nouveaux besoins en gestion de données
2.4.1 Rappel: Architecture multi-tiers

Le tiers métier traduit les événements métier en activités

métier dont la conséquence directe sont des changements

d’état sur les entités du métier.

Illustration: Le tiers de logique métier (le back-end) pour les

applications web est un serveur Apache comportant du code

PHP (ou du Java, ou du Python)

 II- De nouveaux besoins en gestion de données
2.4.1 Rappel: Architecture multi-tiers

Le tiers de persistance assure que ces changements d’états

seront récupérables en cas d’arrêt du système.

Illustration: Le tiers de persistance pour les applications web est

une base de données: MySQL ou autres

 II- De nouveaux besoins en gestion de données

2.4 Le grand paysage des bases de données

BD alternatives aux BD relationnelles

AABD©mkonnon@gmail.com 8
 II- De nouveaux besoins en gestion de données
2.4.2 BD alternatives aux BD relationnelles

Des BD alternatives avec des architectures distribuées :

▪ NoSQL BD : BD avec schéma dynamique ou sans schéma, BD
magasins de clés-valeur, BD de documents et de données graphiques

▪ NewSQL DB : amélioration des performances grâce à de nouveaux

moteurs de stockage, des technologies transparentes de
fragmentation, de nouveaux logiciels et matériels : des BD
radicalement nouvelles

▪ Data Grid/Cache Products : amélioration des performances des

applications et de la BD par stockage des données en mémoire :
données persistantes en cache, réplication des données distribuées, et
calcul exploitant le Grid.
 II- De nouveaux besoins en gestion de données
2.4.3 SPRAINed relational DB

BD alternatives pouvant de traiter de très grands volumes de données, et

supporter des applications hautement distribuées ou très complexes
SPRAIN : acronyme qui désigne les 6 facteurs clés de l'adoption de
technologies de gestion de données alternatives aux
traditionnelles BDR :

• Scalability (évolutivité) – hardware economics (économie de

matériel)
• Performance – BDR limitations
• Relaxed consistency – CAP theorem (cohérence relachée)
• Agility – polyglot persistence (agilité, persistance polyglotte)
• Intricacy (intrication) – big data, total data
• Necessity (nécessité) – open source
 II- De nouveaux besoins en gestion de données

2.4 Le grand paysage des bases de données

SPRAINed relational DB: Scalabilité

AABD©mkonnon@gmail.com 11
 II- De nouveaux besoins en gestion de données
2.4.3 SPRAINed relational DB: SCALABILITE

Définitions (1)

La « scalabilité » (l’extensibilité voire « croissance » ou

« évolutivité » ) est l’aptitude d’un système à maintenir un

même niveau de performance face à l’augmentation de charge

ou de volumétrie, par augmentation des ressources matérielle

et sans impact global sur le système,

 II- De nouveaux besoins en gestion de données
2.4.3 SPRAINed relational DB: SCALABILITE

Définitions (2)

Il existe deux manières de réaliser une extension à un système

existant :

• la scalabilité horizontale (dite externe)

• la scalabilité verticale (dite interne).

 II- De nouveaux besoins en gestion de données
2.4.3 SPRAINed relational DB: SCALABILITE

Définitions (3)

Scalabilité horizontale : possibilité d’ajouter des machines

(serveurs) d’un type donné à un système existant.

Exemple : ajout possible de serveurs d'application web avec

répartition de charge.
 II- De nouveaux besoins en gestion de données
2.4.3 SPRAINed relational DB: SCALABILITE

Définitions (4)

Scalabilité verticale : possibilité de rajouter des ressources

supplémentaires (CPU, RAM, disque ou carte réseau) à un

système (machine ) existant.

Avant le « scale up » Après le « scale up »

 II- De nouveaux besoins en gestion de données
2.4.3 SPRAINed relational DB: SCALABILITE

Avantages de la Scalabilité horizontale :

• On ne paye les machines qu’au fur et à mesure au besoin

• La panne d’une machine ne pénalise pas le système
(tolérance à la panne)
• Le système est globalement plus flexible
• La mise à jour sans interruption de service est possible
 II- De nouveaux besoins en gestion de données
2.4.3 SPRAINed relational DB: SCALABILITE

Inconvénients de la Scalabilité horizontale :

• Il faut trouver un moyen de répartir les demandes (une
application particulière doit gérer la répartition de charge en
envoyant la demande au serveur le moins occupé à l’instant t).
• Il faut payer des licences pour chaque machine
• L’administration de n serveur consomme n fois plus de temps
(sauf à disposer d’un outil spécifique de gestion multi serveur…)
• A long terme des machines identiques ne sont plus
commercialisées.
 II- De nouveaux besoins en gestion de données
2.4.3 SPRAINed relational DB: SCALABILITE

Avantages de la Scalabilité verticale :

• Aucun outil de répartition de charge n’est pas nécessaire
• Une seule licence à payer.
• Une administration simplifiée et moins coûteuse.
• Facilité de transfert à long terme:
même si les ressources matérielles peuvent devenir obsolètes, il
est plus facile de transférer un seul serveur qu’une multitude.
 II- De nouveaux besoins en gestion de données
2.4.3 SPRAINed relational DB: SCALABILITE

Problématique de la scalabilité horizontale

Dans un environnement distribué, Il faut trouver le moyen de

synchroniser la présence des éléments à partager sur chacune
des machines.

Il y a donc nécessité de rajouter un mécanisme de

communication entre les différentes machines et plus on tend
vers la présence synchrone des éléments partagés, plus ce
mécanisme devient coûteux.