En premier lieu, il est important de comprendre que si les
fins de chacune de ces approchent sont similaires (Prévision, optimisation,
Risque,...), L'espace temps d'application n'a plus rien à voir. Un peu comme si
l'on comparait l'équation d'attraction universelle de Newton et l'approche
relativiste d'Einstein. Cette dernière tend vers la première pour des vitesses
négligeables par rapport à la célérité de la lumière.
Ainsi ceux qui prédisent la mort de la BI traditionnelle au
profit de BigData s'enflamment un peu vite où se trompent partiellement. Des
systèmes comme par exemple le SI Comptable, impose une consistance absolue qu'il n'est pas envisageable de traiter avec du Big Data.
NOSQL vs SGBDR
Avec des base de données NOSQL, comme MongoDB, Cassandra,
HBASE, BigTable, Dynamo, un langage universel de requête comme SQL n'existe
pas (Hive est un outil de requête avec une interface SQL adaptée). Cette fonctionnalité est obtenu ad'hoc par programmation en Java ou en
Pithon, en utilisant les API. L'importance du schéma des données, formalisé en
Data Définition Language (DDL), n'est plus le sujet côté NOSQL, et les forte contraintes relationnelles (index, clés primaire, jointures,...) sont justement volontairement bannies pour traiter massivement les données. On raisonne
plutôt par liste par composition de colonnes ou documents, bannissant ainsi la nécessaire intégrité référentielle en 3eme forme normale et
plus.
Mais alors, que faire avec des données suspectées par
construction d'être "éventuellement intègres" ?
Ci-dessous, différents éléments de réponses théoriques.
Ci-dessous, différents éléments de réponses théoriques.
ACID
Atomicité
|
Une transaction s'exécute complètement ou pas du tout. Si
une partie de l'opération échoue, la totalité de la transaction échoue.
|
Consistance
|
Le système est dans un état cohérent à chaque instant,
avant et après une transaction.
|
Isolation
|
2 transactions "simultanées" sont
indépendantes. Elles n'interfèrent pas l'une sur l'autre.
|
Durabilité
|
Le système est capable de se remettre dans un état
cohérent après une perte ou une panne.
|
BASE
- Basically Available
- Soft - state
- Eventual consistency
BA : se réfère à la disponibilité perçue des données distribués. Si un nœud échoue, une partie des données ne sera pas disponible, mais la couche de données entière reste opérationnel.
S : État mou: Les données ont besoin d'une période de rafraîchissement (asynchronisme). Sans un rafraîchissement, les données seront expirer ou être supprimé.
E : La cohérence éventuelle signifie que les mises à jour finiront par se répercuter sur tous les serveurs, étant donné le temps de rafraîchissement .
BA : se réfère à la disponibilité perçue des données distribués. Si un nœud échoue, une partie des données ne sera pas disponible, mais la couche de données entière reste opérationnel.
S : État mou: Les données ont besoin d'une période de rafraîchissement (asynchronisme). Sans un rafraîchissement, les données seront expirer ou être supprimé.
E : La cohérence éventuelle signifie que les mises à jour finiront par se répercuter sur tous les serveurs, étant donné le temps de rafraîchissement .
Basically Available
Consistency
|
Cohérence : Tous les nœuds
du système voient exactement les mêmes données au même moment.
|
Available
|
Disponibilité : garantie
que toutes les requêtes reçoivent une réponse.
|
Partition-Tolerance
|
Tolérance au partitionnement
: aucune panne moins importante qu'une coupure totale du réseau ne doit
empêcher le système de répondre correctement (ou encore : en cas de
morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière
autonome).
|
Le
Théorème de CAP nous dit qu'il est impossible pour un système informatique
de calcul distribué de garantir en même temps ces 3 contraintes. On ne peut en garantir
que 2 à la fois, selon 3 combinaisons distinctes à un instant t : {CA ; CP ; AP}.
CALM : - Consistency As
Logical Monotonicity
Une application
cliente doit elle même compenser l'éventuelle inconsistance de la base NOSQL
qu'elle requête, ce qui peut s'avérer complexe et sources d'erreurs. Une
solution de contournement est de considérer une base de données CALM, C'est à
dire une base ou les faits massivement volumineux jouissent d'une totale
invariance, c'est-à-dire, pas d'opération UPDATE et DELETE atomique. C'est le
cas par exemple des logs que produisent
les systèmes de surveillance et d'alertes, et plus généralement toute
information produite par une machine, un robot ou un objet connecté.FLUCTUAT NEC MERGITUR