API Hour #22 - Clermontech - Aymeric Brisse

1. BIEN CHOISIR SA PARTENAIRE API HOUR #22
*

2. INTRODUCTION
 Applications manipulent des données (I/O)
 Données vivantes destinées à être trouvées
 Stockage intelligent via SGBD
 Données multiformes
 Choisir le bon outil
 Nombre croissant de solutions (> 300)
SOURCE : DB-ENGINES.COM

3. PLAN
 Relational DBMS
 NoSQL
 Key Value Stores
 Document Stores
 Graph DBMS
 Search Engines
 Wide Columns Stores
SOURCE : DB-ENGINES.COM

4. #1 - RELATIONAL DBMS Love Compatibility : 81.4%

5. ORGANISATION
Information organisée dans des tables (relations) à 2 dimensions
 Table : type d’entité avec des attributs typés
 Row / Record : instance
 Column : attribut
 Value : couple (row, column)
Table “towns”
id name population surface
1 Clermont-Ferrand 141463 42.67
2 Lyon 500715 47.87
3 Compiègne 40430 53.10

6. NORMALISATIONS & JOINTURES
 Modélisation “objective” des données
 Vise à supprimer les valeurs non-atomiques et la redondance d’information pour
éviter les anomalies et les pertes d’intégrité des données
 Clés étrangères pointent vers des clés primaires
Table “towns”
id name surface region_id
1 Clermont-Ferrand 42.67 1
2 Lyon 47.87 1
3 Compiègne 53.10 3
Table “regions”
id name prefecture_id
1 Auvergne-Rhône-Alpes 2
2 Nord-Pas-de-Calais-
Picardie
10

7. INDEXES
 Index terminologique (Livre)
 Réduit la complexité de recherche O(n) => O(log(n))
Exemple : log²(1000000) ~ 20
 Appliqués aux clés primaires, clés étrangères, critères de tri, filtres
 Implémentations : B+tree, bitmaps, R-tree

8. SOURCES : WIKIPEDIA / USE-THE-INDEX-LUKE.COM
INDEX B+TREE
SELECT id, name FROM towns WHERE region_id = 4

9. TRANSACTIONS ACID
 Atomicité (tout ou rien)
 Cohérence (passage d’un état à un autre)
 Isolation (indépendance)
 Durabilité (résistance au crashes / erreurs)

10. SELECT id, name
FROM towns
WHERE population > 100000
ORDER BY population DESC
LIMIT 10
LANGAGE STANDARD : SQL
 Langage riche (LDD/LMD/LCD)
 Jointures, agrégations, etc.

11. IMPLEMENTATIONS
Nom Type Date de sortie Licence
Oracle Row/Column 1980 Propriétaire
MySQL Row 1995 GPL / Propriétaire
Microsoft SQL Server Row/Column 1989 Propriétaire
PostgreSQL Row 1989 PostgreSQL (Open Source)
IBM DB2 Row/Column 1983 Propriétaire

12. NOSQL Notions

13. HISTORIQUE
 Géants du Web (Google, Amazon, LinkedIn, Facebook) confrontés aux limitations
intrinsèques des RDBMS (ACID)
 Problèmes de scalabilité (verticale seulement avec 1 master)
 Conception de nouvelles base de données pour architectures matérielles
distribuées pour traiter des volumes importants

14. SOURCE : WIKIPEDIA
SYSTEMES DISTRIBUES
 Incompatible avec la notion de transactions ACID
 Théorème CAP
o Consistency : tous les clients ont la même vue des données
o Availability : clients peuvent lire et écrire tout le temps
o Partition tolerance : le système fonctionne malgré des partitions réseaux
 SQL = Availability + Consistency
 NoSQL = Partition Tolerance + ?
 Si Availability alors Eventual Consistency

15. #2 - KEY VALUE STORES Love Compatibility : 3.1%

16. ORGANISATION
Information organisée sous forme de tableau associatif (Hash)
 Key : identifiant unique
 Value : donnée plus ou moins opaque pour le système
key value
city:1 Clermont-Ferrand|141463|42.67
city:2 { "name":"Lyon", "population":500715, "surface":47.87 }
city:3:population 40430

17. SOURCE : WIKIPEDIA
FONCTIONNALITES
 Très rapide : complexité en temps d’un Hash table O(1)
 Tient en RAM
 Valeurs potentiellement typées (String, Lists, Sets, Sorted set, Hashes, Bitmaps, etc.)

18. LANGAGE
 API ou Protocole diffère pour chaque implémentation
redis> GET “city:3:population”
(nil)
redis> SET “city:3:population” 40430
OK
redis> GET “city:3:population”
40430

19. USE CASES
 Cache de données (TTL, LRU)
 Transient Cache (session, panier, etc.)
 Compteurs, classements
 Queues
 Servir de base à l’implémentation d’autres DBMS NoSQL.

20. IMPLEMENTATIONS
Nom Date de sortie Licence
Redis 2009 BSD
Memcached 2003 BSD
Riak KV 2009 Apache
Hazelcast 2010 Apache
Aerospike 2012 AGPL

21. #3 - DOCUMENT STORES Love Compatibility : 6.8%

22. ORGANISATION
Information organisée dans des collections
 Collection : ensemble de documents
 Document : objet contenant un ensemble d’attributs et de valeurs
 Field / Key : attribut
 Value : valeur d’un field
Le Document encapsule et encode ses attributs dans un standard (JSON, XML, etc.)
{
"id": "110e8400-e29b-11d4-a716-446655440000",
"name": "Clermont-Ferrand",
"population": 141463,
"surface" : 42.67
}

23. DÉNORMALISATION & NESTED DOCUMENTS
 Modélisation “subjective” des données en fonction de la manière dont on va les
consulter (query).
 Vise à supprimer les jointures.
{
"id": "110e8400-e29b-11d4-a716-446655440000",
"name": "Clermont-Ferrand",
"population": 141463,
"surface" : 42.67,
"region" : {
"id": "c65642b5-c46e-46ea-abd7-d27862498f7f",
"name": "Auvergne-Rhône-Alpes"
}
}

24. INDEXES
 Appliqués aux clés primaires, critères de tri, filtres

25. LANGAGE
 API ou Protocole diffère pour chaque implémentation
db.towns.find({ population: { $gt: 100000 } }).sort({ population: -1 }).limit(10)

26. USE CASES
 Gestion de documents complexes (embedded documents)
 Applications utilisant du JSON
 Beaucoup d’écritures concurrentes
 Intégrité et cohérence non cruciales
 Requêtes statiques

27. IMPLEMENTATIONS
Nom Date de sortie Licence
MongoDB 2009 AGPL
Couchbase 2001 Apache
Amazon DynamoDB 2012 Propriétaire / SaaS
CouchDB 2005 Apache
RethinkDB 2009 AGPL

28. #4 - SEARCH ENGINES Love Compatibility : 3.7%

29. ORGANISATION
 SearchEngine = DBMS + outils dédiés à la fouille de texte
2 étapes clés :
 Indexation
 Recherche

30. INDEXATION

31. INDEXES
 Doc 1 : { “title“ : “Adopte un moteur de recherche“ }
 Doc 2 : { “title“ : “Adopte le language ruby“ }
Index inversé “title”
ID Item Document
1 adopte Doc 1, Doc 2
2 language Doc 2
3 moteur Doc 1
4 recherche Doc 1
5 ruby Doc 2

32. RECHERCHE - REQUÊTE
POST /index/document/_search
{
"query": {
"filtered": {
"query": {
"query_string": {
"fields": [
"title^5",
"description^2",
"content"
],
"query": "moteur de recheche en ruby",
"fuzzy_prefix_length": 2,
"fuzziness": 1
}
},
"filter": {
"bool": {
"must": [
{
"match": {
"rights": "public"
},
"should": {
"types": "article"
}
}
]
}
}
}
}
}

33. RECHERCHE – RÉSULTAT AVEC SCORING
{
"hits": {
"total": 2,
"max_score": 0.11843335,
"hits": [
{
"_index": “index",
"_type": “document",
"_id": "1",
"_score": 0.30052114,
"_source": {
“title": "adopte un moteur de recherche"
}
},
{
"_index": " index ",
"_type": " document ",
"_id": "2",
"_score": 0.038161416,
"_source": {
“title": "adopte le language ruby"
}
}
]
}
}

34. FONCTIONNALITES
 Full Text Search
 Racinisation / Lemmatisation
 Mots vides
 Synonymes
 Recherche par phrase
 Recherche de proximité
 Recherche approximative (distance de Levenshtein)
 Auto complétion
 Suggestion
 Classement (td-idf, Okapi BM25, etc.)
 Facettes
 Recherche géospatiale

35. IMPLEMENTATIONS
Nom Date de sortie Licence
Elasticsearch (Lucene) 2010 Apache
Solr (Lucene) 2004 Apache
Splunk 1998 Propriétaire
Sphinx 2001 GPL + Propriétaire
Amazon CloudSearch 2012 Propriétaire / SaaS

36. #5 - GRAPH DBMS Love Compatibility : 0.9%

37. ORGANISATION
Information organisée par des relations orientées
 Node: noeud
 Edge : relation
 Property : propriété sur un noeud
ou sur une relation

38. SOURCE : NEO4J.COM
INDEXES
 Jointures RDBMS nécessite lookups de clés étrangères via des tables d’indexes
 Relations stockées par nature dans la base de données
 Graph DBMS : Adjacent Lists (pointeurs directs)

39. LANGUAGES
 Pas de norme type SQL pour le Query Language. Des efforts de standardisations.
 Gremlin (Graph stores)
 SPARQL (RDF stores)
g.V.has(‘id’, ‘Node_1’).out(‘regions’).out(‘prefecture’).values(‘id’,‘name’)
SELECT ?town ?name
WHERE {
:Node_1 ns:region/ns:prefecture ?town .
?region ns:name ?name
}

40. USE CASES
 Modélisation orientée relations
 Réseaux sociaux
 Recommandation
 Réseau/ IT management
 Algorithmes liés à la théorie des graphes type plus court chemin

41. IMPLEMENTATIONS
Nom Date de sortie Licence
Neo4j 2007 GPL + Propriétaire
Titan 2012 Apache
Virtuoso 1998 GPL + Propriétaire
Apache Giraph 2013 Apache
Stardog 2010 Propriétaire

42. #6 - WIDE COLUMNS STORES Love Compatibility : 3.0%

43. ORGANISATION
Key/Value Store à 2+ dimensions
ColumnFamily “towns”
key value
1
name population surface
Clermont-Ferrand 141463 42.67
1473796134 1473796134 1473796134
2
name population coordonnées
Compiègne 40430 49° 24′ 54″ Nord, 2° 49′ 23″ Est
1473796134 1473796134 1473796134

44. LANGAGE
 Langage diffère pour chaque implémentation
 Exemple : Cassandra CQL = Query Language (SQL like)
RowKey: 1
=> (name=, value=, timestamp=1473796134)
=> (name=name, value=Clermont-Ferrand, timestamp=1473796134)
=> (name=population, value=141463, timestamp=42.67)
=> (name=surface, value=42.67, timestamp=1473796134)
SELECT *
FROM towns
WHERE id = 1

45. INDEXES
 Indexes secondaires déconseillés (maintenance complexe)
 Systèmes répartis, partitionnement par clé primaire (répartition sur les nodes)
 Filtres : clé primaire composites
 Ordre : unique défini lors de la création de la ColumnFamily
 Dénormalisation extrême = 1 ColumnFamily par query

46. USE CASES
 Volumétrie importante (milliards d’enregistrements)
 Performances
 Distribution géographique avec plusieurs data centers
 Données déstructurées / flexibles

47. IMPLEMENTATIONS
Nom Date de sortie Licence
Cassandra 2008 Apache
HBase 2008 Apache
Apache Accumulo 2008 Apache
Hypertable 2009 GPL
Google Cloud Bigtable 2005 Propriétaire / SaaS

48. CONCLUSION So what ?

49. QUESTIONS
 Flexibilité du modèle de données
 Nature des relations entre les entités
 Contraintes transactionnelles et d’intégrité des données
 Disponibilité & Cohérence des réplicas
 Volumétrie lecture / écriture
 Performances / SLA
 OS / Ecosystème / Licence

50. FUTUR ?
 Variété de bases NoSQL pérennisée par le nombre croissant d’applications avec
des contraintes variées et exigeantes en termes de performance & volumétrie
 Multi-model databases (OrientDB, ArangoDB, etc.)
 Evolution constante du NoSQL : NotOnlySQL (ex : jointures)
 NewSQL : performance du NoSQL avec du SQL (VoltDB)

51. QUESTIONS ? @aymericbrisse
SOURCE : GEEK-AND-POKE.COM

52. BONUS

53. ALTERNATIVE : COLUMN-ORIENTED DBMS
Table “town”
id 1 2 3
name Clermont-Ferrand Lyon Compiègne
population 141463 500715 40430
surface 42.67 47.87 53.10
Table “town”
name Compiègne : 3 Clermont-Ferrand : 1 Lyon : 2 Paris : 4,16,18
population 40430 : 3 141463 : 1 500715 : 2
surface 42.67 : 1 47.87 : 2 53.10 : 3

54. ALTERNATIVE : COLUMN-ORIENTED DBMS
Avantages :
 “Toutes les villes dont le nom est Paris" (22) : 1 seule opération
 Stocker l’information sous forme d’indexes
 Colonnes optionnelles (compression)
 Opérations Filtres, Aggrégation, compteurs, etc
 Orientation OLAP
Désavantages :
 Récupérer toutes informations sur une entité est plus lent
 Ecritures