SlideShare uma empresa Scribd logo
1 de 58
Penser en termes de
documents
Buzz Moschetti
Architecte d'entreprise, MongoDB
buzz.moschetti@mongodb.com
@buzzmoschetti
Avant de commencer
• Ce webinaire est enregistré
• Utilisez la fenêtre de discussion pour :
• obtenir une assistance technique ;
• poser des questions et obtenir des
réponses.
• L'équipe MongoDB répondra
rapidement aux questions en
temps réel.
• Les questions les plus courantes
seront examinées à la fin de ce
webinaire.
Thème 1 :
Pour établir une conception de
données efficace, il ne suffit pas
d'avoir une base de données
• Des structures facilement
compréhensibles
• Une harmonisation avec les logiciels
• Une connaissance des problèmes
hérités
Thème°2 :
Les solutions d'aujourd'hui
doivent prendre en compte les
besoins de demain
• Fin de l'obligation de suivre une
configuration requise
• Possibilité de monter en charge de
façon économique
• Des solutions de cycles de vie plus
rapides
Thème°3 :
MongoDB vous donne le choix
RDBMS MongoDB
Base de données Base de données
Table Collection
Index Index
Ligne Document
Colonne Champ
Jointure Intégration et liaison
Terminologie
{
_id: “123”,
title: "MongoDB: The Definitive Guide",
authors: [
{ _id: "kchodorow", name: "Kristina Chodorow“ },
{ _id: "mdirold", name: “Mike Dirolf“ }
],
published_date: ISODate(”2010-09-24”),
pages: 216,
language: "English",
thumbnail: BinData(0,"AREhMQ=="),
publisher: {
name: "O’Reilly Media",
founded: 1980,
locations: ["CA”, ”NY” ]
}
}
Qu'est-ce qu'un document ?
// Java: maps
DBObject query = new BasicDBObject(”publisher.founded”, 1980));
Map m = collection.findOne(query);
Date pubDate = (Date)m.get(”published_date”); // java.util.Date
// Javascript: objects
m = collection.findOne({”publisher.founded” : 1980});
pubDate = m.published_date; // ISODate
year = pubDate.getUTCFullYear();
# Python: dictionaries
m = coll.find_one({”publisher.founded” : 1980 });
pubDate = m[”pubDate”].year # datetime.datetime
Les documents mènent à des constructions
de langages
9
Conception de données
traditionnelle
• Données scalaires
uniformes et statiques
• Rectangles
• Représentation physique
de bas niveau
10
Conception de données
par document
• Formes enrichies et
flexibles
• Objets
• Représentation
d'entreprise de niveau
supérieur
Exemple de
conception de schéma
12
Application de gestion de bibliothèques
• Clients/utilisateurs
• Livres
• Auteurs
• Éditeurs
13
Question :
Quelle est l'adresse d'un
client ?
Client + adresse : Tentative initiale
> db.patrons.find({ _id : “joe” })
{
_id: "joe“,
name: "Joe Bookreader”,
favoriteGenres: [ ”mystery”, ”programming” ]
}
> db.addresses.find({ _id : “joe” })
{
_id: "joe“,
street: "123 Fake St.",
city: "Faketon",
state: "MA",
zip: “12345”
}
Client + adresse : La méthode MongoDB
> db.patrons.find({ _id : “joe” })
{
_id: "joe",
name: "Joe Bookreader",
favoriteGenres: [ ”mystery”, ”programming” ]
address: {
street: "123 Fake St. ",
city: "Faketon",
state: "MA",
zip: “12345”
}
}
Projection : renvoyez uniquement ce dont
vous avez besoin
> db.patrons.find({ _id : “joe” }, {“_id”: 0, ”address”:1})
{
address: {
street: "123 Fake St. ",
city: "Faketon",
state: "MA",
zip: “12345”
}
}
> db.patrons.find({ _id : “joe” }, {“_id”: 0, “name”:1,
”address.state”:1})
{
name: "Joe Bookreader",
address: {
state: "MA”
}
}
17
La sous-structure fonctionne parfaitement
avec le code
> addr = db.patrons.find({_id :“joe”},{“_id”: 0,”address”:1})
{
address: {
street: "123 Fake St. ",
city: "Faketon",
state: "MA",
zip: “12345”
}
}
// Pass the whole Map to this function:
doSomethingWithOneAddress(addr);
// Somewhere else in the code is the actual function:
doSomethingWithOneAddress(Map addr)
{ // Look for state }
N'oubliez pas : les formes des documents
peuvent varier
> db.patrons.insert({ _id : “bob”,
name: ”Bob Nobooks",
address: {
street: ”139 W45 St. ",
city: ”NY",
state: ”NY",
country: ”USA”
}
}
> db.patrons.find({},{“_id”: 1, ”address”:1})
{ _id: “joe”,
address: {
street: "123 Fake St. ",
city: "Faketon",
state: "MA",
zip: “12345”
}
}
{ _id: ”bob",
address: {
street: ”139 W45 St. ",
city: ”NY",
state: ”NY",
country: ”USA”
}
}
19
La sous-structure améliore l'agilité
> addr = db.patrons.find({_id :“bob”},{“_id”: 0,”address”:1})
{
address: {
street: ”139 W45 St. ",
city: ”NY",
state: ”NY",
country: ”USA”
}
}
// Pass the whole Map to this function:
doSomethingWithOneAddress(addr);
doSomethingWithOneAddress(Map addr)
{ // Look for state and optional country }
AUCUNE MODIFICATION
apportée aux requêtes
Seule l'implémentation
unique recherchant le
pays doit être modifiée
PAS DE DÉPENDANCES
DE DURÉE DE
COMPILATION lors du
transfert des mappages
20
Avantage par rapport aux rectangles
resultSet = select street, state, city, country, …
Map addr = processIntoMap(resultSet);
// Pass the whole Map to this function:
doSomethingWithOneAddress(addr);
doSomethingWithOneAddress(Map addr)
{ // Look for state and optional country }
Il faut modifier les requêtes
pour sélectionner de
nouvelles colonnes.
Il existe une dépendance
de durée de compilation
pour traiter de nouvelles
colonnes vers le mappage.
21
Montées en charge de la sous-structure pour
la modification
MongoDB
db.patrons.find({},
{”myAddress”:1,”yourAddress”:1,”brokerAddress”:1,
“momsAddress”:1, …})
Traditional SQL
resultSet = select mystreet, mystate, mycity, mycountry,
yourstreet, yourstate, yourcity, yourcountry, brokerstreet,
brokerstate, brokercity, brokercountry, momsstreet,
momsstate, momscity, momscountry, …
22
Relations un-à-un
• Les relations de type « Appartient à » sont
souvent intégrées.
• Représentation holistique des entités avec leurs
attributs et relations intégrés
• Performances de lecture exceptionnelles
Le plus important :
• Insistez sur la simplicité.
• Libérez du temps pour résoudre des
problèmes de conception de schéma plus
difficiles.
23
Question :
Quelles sont les adresses d'un
client ?
Un client et ses adresses
> db.patrons.find({ _id : “bob” })
{
_id: “bob",
name: “Bob Knowitall",
addresses: [
{street: "1 Vernon St.", city: "Newton", …},
{street: "52 Main St.", city: "Boston", …}
]
}
Un client et ses adresses
> db.patrons.find({ _id : “bob” })
{
_id: “bob",
name: “Bob Knowitall",
addresses: [
{street: "1 Vernon St.", city: "Newton", …},
{street: "52 Main St.", city: "Boston", …}
]
}
> db.patrons.find({ _id : “joe” })
{
_id: "joe",
name: "Joe Bookreader",
address: { street: "123 Fake St. ", city: "Faketon", …}
}
26
Options de migration
• Migrez tous les documents lorsque le schéma est
modifié.
• Migration à la demande
– L'extraction du document d'un client est une
modification.
– Les clients qui ne fréquentent pas la bibliothèque ne
sont jamais mis à jour.
• Ne rien faire
– La couche de code sait utiliser les champs pour une
ou plusieurs adresses
27
Laisser le code traiter les documents
Map d = collection.find(new BasicDBObject(”_id”,”bob”));
// Contract: Return either a List of addresses or a null
// if no addresses exist
// Try to get the new “version 2” shape:
List addrl = (List) d.get(”addresses”);
// If not there, try to get the old one:
if(addrl == null) {
Map oneAddr = (Map) d.get(”address”);
if(oneAddr != null) {
addrl = new List();
addrl.append(oneAddr);
}
}
// addrl either exists with 1 or more items or is null
28
Question :
qui a publié ce livre ?
29
Livre
• MongoDB : le guide absolu,
• par Kristina Chodorow et Mike Dirolf
• Date de publication : 24/09/2010
• Pages : 216
• Langue : anglais
• Éditeur : O’Reilly Media, CA
Livre avec éditeur intégré
> book = db.books.find({ _id : “123” })
{
_id: “123”,
title: "MongoDB: The Definitive Guide",
authors: [ "Kristina Chodorow", "Mike Dirolf" ],
published_date: ISODate(”2010-09-24”),
pages: 216,
language: "English",
publisher: {
name: "O’Reilly Media",
founded: 1980,
locations: ["CA”, ”NY” ]
}
}
N'oubliez pas la sous-structure !
> book = db.books.find({ _id : “123” })
{
_id: “123”,
title: "MongoDB: The Definitive Guide",
authors: [
{ first: "Kristina”, last: “Chodorow” },
{ first: ”Mike”, last: “Dirolf” }
],
published_date: ISODate(”2010-09-24”),
pages: 216,
language: "English",
publisher: {
name: "O’Reilly Media",
founded: 1980,
locations: ["CA”, ”NY” ]
}
}
32
Relation un à plusieurs via l'intégration
• Optimisée pour les performances de lecture des livres
• Nous acceptons la duplication de données
• Un index basé sur « publisher.name » permet :
– une recherche efficace de tous les livres du même
éditeur ;
– Une recherche efficace de tous les noms d'éditeurs
(différents).
• Cela ne veut pas dire qu'il n'existe pas de collection
d'éditeurs « principale » (depuis laquelle les données
sont copiées lors de la création d'un livre)
Éditeurs en tant qu'entités distinctes
> publishers = db.publishers.find()
{
_id: “oreilly”,
name: "O’Reilly Media",
founded: 1980,
locations: ["CA”, ”NY” ]
}
{
_id: “penguin”,
name: ”Penguin”,
founded: 1983,
locations: [ ”IL” ]
}
Livre unique avec éditeur associé
> book = db.books.find({ _id: “123” })
{
_id: “123”,
publisher_id: “oreilly”,
title: "MongoDB: The Definitive Guide",
…
}
> db.publishers.find({ _id : book.publisher_id })
{
_id: “oreilly”,
name: "O’Reilly Media",
founded: 1980,
locations: ["CA”, ”NY” ]
}
Plusieurs livres avec éditeur associé
db.books.find({ pages: {$gt:100}} ).forEach(function(book) {
// Do whatever you need with the book document, but
// in addition, capture publisher ID uniquely by
// using it as a key in an object (Map)
tmpm[book.publisher.name] = true;
});
uniqueIDs = Object.keys(tmpm); // extract ONLY keys
db.publishers.find({"_id": {"$in": uniqueIDs } });
Produit cartésien = structure de votre choix
resultSet = “select B.name, B.publish_date, P.name, P.founded
from Books B, Publisher P
where P.name = B.publisher_name
and B.pages > 100”
B.Name B.publish_date P.name P.founded
More Jokes 2003 Random House 1843
Perl Tricks 1998 O’Reilly 1980
More Perl 2000 O’Reilly 1980
Starting Perl 1996 O’Reilly 1980
Flying Kites 1980 Random House 1843
Using Perl 2002 O’Reilly 1980
Bad Food 2011 Random House 1843
…Difficile à utiliser sans la clause ORDER BY
resultSet = “select B.name, B.publish_date, P.name, P.founded
from Books B, Publisher P
where P.name = B.publisher_name
and B.pages > 100
order by P.name”;
B.Name B.publish_date P.name P.founded
Perl Tricks 1998 O’Reilly 1980
More Perl 2000 O’Reilly 1980
Using Perl 2002 O’Reilly 1980
Starting Perl 1996 O’Reilly 1980
Flying Kites 1980 Random House 1843
Bad Food 2011 Random House 1843
More Jokes 2003 Random House 1843
SQL repose sur le désassemblage
resultSet = “select B.name, B.publish_date, P.name, P.founded
from Books B, Publisher P
where P.name = B.publisher_name
and B.pages > 100
order by P.name”;
prev_name = null;
while(resultSet.next()) {
if(!resultSet.getString(“P.name”).equals(prevName)) {
// “next” publisher name found. Process material
// accumulated and reset for next items.
makeNewObjects(); //etc.
prev_name = resultSet.getString(“P.name”)
}
}
39
Méthode « one-to-many » avec liaisons
• Optimisée pour une gestion efficace des données
pouvant évoluer
• Méthode familière pour organiser des entités de base
• Le code permet d'assembler des documentations
récupérées dans d'autres objets, et non pas de
désassembler un objet ResultSet unique.
– Il peut être plus simple de coder et de maintenir des requêtes
plus complexes lors d'un assemblage que lors d'un
désassemblage.
40
Question :
Quels sont tous les livres
publiés par un éditeur ?
Éditeur avec des livres associés
> publisher = db.publishers.find({ _id : “oreilly” })
{
_id: “oreilly”,
name: "O’Reilly Media",
founded: 1980,
locations: [ "CA“, ”NY” ],
books: [“123”, “456”, “789”, “10112”, …]
}
> books = db.books.find({ _id: { $in : publisher.books } })
42
Question :
Qui sont les auteurs d'un livre
précis ?
Livres avec auteurs associés
> book = db.books.find({ _id : “123” })
{
_id: “123”,
title: "MongoDB: The Definitive Guide",
…
authors: [
{ _id: “X12”, first: "Kristina”, last: “Chodorow” },
{ _id: “Y45”, first: ”Mike”, last: “Dirolf” }
],
}
> a2 = book.authors.map(function(r) { return r._id; });
> authors = db.authors.find({ _id : { $in : a2}})
{_id:”X12”,name:{first:"Kristina”,last:”Chodorow”},hometown: …
}
{_id:“Y45”,name:{first:”Mike”,last:”Dirolf”}, hometown: … }
44
Question :
Quels sont tous les livres qu'un
auteur a écrits ?
> db.authors.find({ _id : “X12” })
{
_id: ”X12",
name: { first: "Kristina”, last: “Chodorow” } ,
hometown: "Cincinnati",
books: [ {id: “123”, title : "MongoDB: The Definitive
Guide“ } ]
}
> db.books.find({ _id : “123” })
{
_id: “123”,
title: "MongoDB: The Definitive Guide",
…
authors: [
{ _id: “X12”, first: "Kristina”, last: “Chodorow” },
{ _id: “Y45”, first: ”Mike”, last: “Dirolf” }
],
}
Double lien entre les livres et les auteurs
> db.books.find({ _id : “123” })
{
authors: [
{ _id: “X12”, first: "Kristina”, last: “Chodorow” },
{ _id: “Y45”, first: ”Mike”, last: “Dirolf” }
],
}
> db.books.ensureIndex({“authors._id”: 1});
> db.books.find({ “authors._id” : “X12” }).explain();
{
"cursor" : "BtreeCursor authors.id_1",
…
"millis" : 0,
}
Autre approche : Indexation du tableau
47
Comparaison entre intégration et liaison
• Intégration
– Parfait pour les performances de lecture
• « Pages d'accueil » d'applications Web et documentations
pré-agrégées
• Structures complexes
– Idéal pour les conceptions immuables ou avec insertion seule
– Les insertions peuvent être plus lentes que les liaisons.
– L'intégrité des données externes (« not-belongs-to ») doit être
gérée.
• Liaison
– Flexibilité
– L'intégrité des données est intégrée.
– Le travail est effectué durant les lectures.
• N'implique pas forcément davantage de travail que pour un
RDBMS.
48
Question :
Quels sont les attributs
personnalisés pour chaque
auteur ?
> db.authors.find()
{
_id: ”X12",
name: { first: "Kristina”, last: “Chodorow” },
personalData: {
favoritePets: [ “bird”, “dog” ],
awards: [ {name: “Hugo”, when: 1983}, {name: “SSFX”,
when: 1992} ]
}
}
{
_id: ”Y45",
name: { first: ”Mike”, last: “Dirolf” } ,
personalData: {
dob: ISODate(“1970-04-05”)
}
}
Attribuer une structure dynamique à un nom
connu
> db.events.find()
{ type: ”click", ts: ISODate(“2015-03-03T12:34:56.789Z”,
data: { x: 123, y: 625, adId: “AE23A” } }
{ type: ”click", ts: ISODate(“2015-03-03T12:35:01.003Z”,
data: { x: 456, y: 611, adId: “FA213” } }
{ type: ”view", ts: ISODate(“2015-03-03T12:35:04.102Z”,
data: { scn: 2, reset: false, … } }
{ type: ”click", ts: ISODate(“2015-03-03T12:35:05.312Z”,
data: { x: 23, y: 32, adId: “BB512” } }
{ type: ”close", ts: ISODate(“2015-03-03T12:35:08.774Z”,
data: { snc: 2, logout: true, mostRecent: [ … ] } }
{ type: ”click", ts: ISODate(“2015-03-03T12:35:10.114Z”,
data: { x: 881, y: 913, adId: “F430” } }
Polymorphisme : Étude nécessaire
51
Question :
Quels livres traitent des bases
de données ?
Catégories en tant que tableau
> db.books.find({ _id : “123” })
{
_id: “123”,
title: "MongoDB: The Definitive Guide",
categories: [“MongoDB”, “Databases”, “Programming”]
}
> db.book.ensureIndex({categories:1});
> db.books.find({ categories: “Databases” })
Catégories sous forme de chemin d'accès
> db.books.find({ _id : “123” })
{
_id: “123”,
title: "MongoDB: The Definitive Guide",
category: “Programming/Databases/MongoDB”
}
> db.books.find({ category: ^Programming/Databases/* })
À venir dans la version 3.2 : la validation de
documents
> db.createCollection("books", { "validator":
{ $and: [
{ "title": {$type: “string”} },
{ "publishDate": {$type: “date”} },
{ $or: [
{ "thumbnail": {$exists: False}},
{ "thumbnail": {$type: “binary”}}
]
}
]
}
});
Validation de documents et schémas légers
> db.createCollection("books", { "validator":
{ $or: [
{ $and: [ { "v": 1},
{ "title": {$type: “string”} }
]
},
{ $and: [ { "v": 2},
{ "title": {$type: “string”} },
{ "publishDate": {$type: “date”} },
{ $or: [
{ "thumbnail": {$exists: False}},
{ "thumbnail": {$type: “binary”}}
]
}
]
}
]
});
56
Résumé
• La conception physique est différente dans MongoDB.
– Les principes de conception de données de base
restent toutefois les mêmes.
• L'important est la méthode employée par une application
pour accéder aux données ou les manipuler.
• La recherche et la capture sont liées aux relations 1:1.
• Utilisez une sous-structure pour améliorer l'alignement
des objets du code.
• Soyez polymorphe !
• Faites évoluer le schéma pour suivre l'évolution des
exigences.
Questions et réponses
Merci

Mais conteúdo relacionado

Mais procurados

Les modèles NoSQL
Les modèles NoSQLLes modèles NoSQL
Les modèles NoSQL
ebiznext
 
Java et les bases de données
Java et les bases de donnéesJava et les bases de données
Java et les bases de données
Guillaume Harry
 
Les nouveautés de MongoDB 3.6
Les nouveautés de MongoDB 3.6Les nouveautés de MongoDB 3.6
Les nouveautés de MongoDB 3.6
MongoDB
 

Mais procurados (20)

introduction à MongoDB
introduction à MongoDBintroduction à MongoDB
introduction à MongoDB
 
[Breizhcamp 2015] MongoDB et Elastic, meilleurs ennemis ?
[Breizhcamp 2015] MongoDB et Elastic, meilleurs ennemis ?[Breizhcamp 2015] MongoDB et Elastic, meilleurs ennemis ?
[Breizhcamp 2015] MongoDB et Elastic, meilleurs ennemis ?
 
Modélisation de données pour MongoDB
Modélisation de données pour MongoDBModélisation de données pour MongoDB
Modélisation de données pour MongoDB
 
Toutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDBToutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDB
 
ToursJUG mongoDB
ToursJUG mongoDBToursJUG mongoDB
ToursJUG mongoDB
 
Event: Petit-déjeuner MongoDB France
Event: Petit-déjeuner MongoDB FranceEvent: Petit-déjeuner MongoDB France
Event: Petit-déjeuner MongoDB France
 
Webinaire 1 de la série Retour aux fondamentaux : Introduction à NoSQL
Webinaire 1 de la série Retour aux fondamentaux : Introduction à NoSQLWebinaire 1 de la série Retour aux fondamentaux : Introduction à NoSQL
Webinaire 1 de la série Retour aux fondamentaux : Introduction à NoSQL
 
NoSQL et Big Data
NoSQL et Big DataNoSQL et Big Data
NoSQL et Big Data
 
Les modèles NoSQL
Les modèles NoSQLLes modèles NoSQL
Les modèles NoSQL
 
Base NoSql et Python
Base NoSql et PythonBase NoSql et Python
Base NoSql et Python
 
Webinaire 4 de la série Retour aux fondamentaux : Indexation avancée, index d...
Webinaire 4 de la série Retour aux fondamentaux : Indexation avancée, index d...Webinaire 4 de la série Retour aux fondamentaux : Indexation avancée, index d...
Webinaire 4 de la série Retour aux fondamentaux : Indexation avancée, index d...
 
Java et les bases de données
Java et les bases de donnéesJava et les bases de données
Java et les bases de données
 
Zenika MongoDB Tour - REX Amadeus
Zenika MongoDB Tour - REX AmadeusZenika MongoDB Tour - REX Amadeus
Zenika MongoDB Tour - REX Amadeus
 
NoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisationNoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisation
 
L'expérience client au centre de la donnée @AirFrance
L'expérience client au centre de la donnée @AirFranceL'expérience client au centre de la donnée @AirFrance
L'expérience client au centre de la donnée @AirFrance
 
Les nouveautés de MongoDB 3.6
Les nouveautés de MongoDB 3.6Les nouveautés de MongoDB 3.6
Les nouveautés de MongoDB 3.6
 
Tout ce que le getting started mongo db ne vous dira pas
Tout ce que le getting started mongo db ne vous dira pasTout ce que le getting started mongo db ne vous dira pas
Tout ce que le getting started mongo db ne vous dira pas
 
Big Data: Hadoop Map / Reduce sur Windows et Windows Azure
Big Data: Hadoop Map / Reduce sur Windows et Windows AzureBig Data: Hadoop Map / Reduce sur Windows et Windows Azure
Big Data: Hadoop Map / Reduce sur Windows et Windows Azure
 
Introduction aux bases de données NoSQL
Introduction aux bases de données NoSQLIntroduction aux bases de données NoSQL
Introduction aux bases de données NoSQL
 
Apache Kafka, Un système distribué de messagerie hautement performant
Apache Kafka, Un système distribué de messagerie hautement performantApache Kafka, Un système distribué de messagerie hautement performant
Apache Kafka, Un système distribué de messagerie hautement performant
 

Semelhante a Retour aux fondamentaux : Penser en termes de documents

2014 04-09-fr - app dev series - session 4 - indexing
2014 04-09-fr - app dev series - session 4 - indexing2014 04-09-fr - app dev series - session 4 - indexing
2014 04-09-fr - app dev series - session 4 - indexing
MongoDB
 
MongoDB_presentation_tts.pptx
MongoDB_presentation_tts.pptxMongoDB_presentation_tts.pptx
MongoDB_presentation_tts.pptx
ZALIMAZA
 
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01-rev.
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01-rev.2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01-rev.
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01-rev.
MongoDB
 
MongoDB_presentation_p.pptx
MongoDB_presentation_p.pptxMongoDB_presentation_p.pptx
MongoDB_presentation_p.pptx
ZALIMAZA
 
MongoDB_presentation_example.pptx
MongoDB_presentation_example.pptxMongoDB_presentation_example.pptx
MongoDB_presentation_example.pptx
ZALIMAZA
 
MongoDB_presentation_ye.pptx
MongoDB_presentation_ye.pptxMongoDB_presentation_ye.pptx
MongoDB_presentation_ye.pptx
ZALIMAZA
 
MongoDB_presentation_o.pptx
MongoDB_presentation_o.pptxMongoDB_presentation_o.pptx
MongoDB_presentation_o.pptx
ZALIMAZA
 
MongoDB_presentation_Moyou.pptx
MongoDB_presentation_Moyou.pptxMongoDB_presentation_Moyou.pptx
MongoDB_presentation_Moyou.pptx
ZALIMAZA
 
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp012014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01
MongoDB
 
2014 03-12-fr schema design and app architecture-2
2014 03-12-fr schema design and app architecture-22014 03-12-fr schema design and app architecture-2
2014 03-12-fr schema design and app architecture-2
MongoDB
 

Semelhante a Retour aux fondamentaux : Penser en termes de documents (20)

2014 04-09-fr - app dev series - session 4 - indexing
2014 04-09-fr - app dev series - session 4 - indexing2014 04-09-fr - app dev series - session 4 - indexing
2014 04-09-fr - app dev series - session 4 - indexing
 
MongoDB_presentation_tts.pptx
MongoDB_presentation_tts.pptxMongoDB_presentation_tts.pptx
MongoDB_presentation_tts.pptx
 
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01-rev.
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01-rev.2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01-rev.
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01-rev.
 
MongoDB_presentation_xmls.pptx
MongoDB_presentation_xmls.pptxMongoDB_presentation_xmls.pptx
MongoDB_presentation_xmls.pptx
 
MongoDB_presentation_p.pptx
MongoDB_presentation_p.pptxMongoDB_presentation_p.pptx
MongoDB_presentation_p.pptx
 
MongoDB_presentation_example.pptx
MongoDB_presentation_example.pptxMongoDB_presentation_example.pptx
MongoDB_presentation_example.pptx
 
Tout ce que le getting started mongodb ne vous dira pas
Tout ce que le getting started mongodb ne vous dira pasTout ce que le getting started mongodb ne vous dira pas
Tout ce que le getting started mongodb ne vous dira pas
 
MongoDB_presentation_ye.pptx
MongoDB_presentation_ye.pptxMongoDB_presentation_ye.pptx
MongoDB_presentation_ye.pptx
 
MongoDB_presentation.pptx
MongoDB_presentation.pptxMongoDB_presentation.pptx
MongoDB_presentation.pptx
 
MongoDB_presentation_o.pptx
MongoDB_presentation_o.pptxMongoDB_presentation_o.pptx
MongoDB_presentation_o.pptx
 
MongoDB_presentation_Moyou.pptx
MongoDB_presentation_Moyou.pptxMongoDB_presentation_Moyou.pptx
MongoDB_presentation_Moyou.pptx
 
MongoDB.pptx
MongoDB.pptxMongoDB.pptx
MongoDB.pptx
 
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp012014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01
2014 03-26-appdevseries-session3-interactingwiththedatabase-fr-phpapp01
 
Présentation mongoDB et mongoId
Présentation mongoDB et mongoIdPrésentation mongoDB et mongoId
Présentation mongoDB et mongoId
 
Cours dao
Cours daoCours dao
Cours dao
 
Cours jdbc
Cours jdbcCours jdbc
Cours jdbc
 
Tech day hadoop, Spark
Tech day hadoop, SparkTech day hadoop, Spark
Tech day hadoop, Spark
 
Techday Arrow Group: Hadoop & le Big Data
Techday Arrow Group: Hadoop & le Big DataTechday Arrow Group: Hadoop & le Big Data
Techday Arrow Group: Hadoop & le Big Data
 
Tout ce que le getting started MongoDB ne vous dira pas
Tout ce que le getting started MongoDB ne vous dira pasTout ce que le getting started MongoDB ne vous dira pas
Tout ce que le getting started MongoDB ne vous dira pas
 
2014 03-12-fr schema design and app architecture-2
2014 03-12-fr schema design and app architecture-22014 03-12-fr schema design and app architecture-2
2014 03-12-fr schema design and app architecture-2
 

Mais de MongoDB

Mais de MongoDB (20)

MongoDB SoCal 2020: Migrate Anything* to MongoDB Atlas
MongoDB SoCal 2020: Migrate Anything* to MongoDB AtlasMongoDB SoCal 2020: Migrate Anything* to MongoDB Atlas
MongoDB SoCal 2020: Migrate Anything* to MongoDB Atlas
 
MongoDB SoCal 2020: Go on a Data Safari with MongoDB Charts!
MongoDB SoCal 2020: Go on a Data Safari with MongoDB Charts!MongoDB SoCal 2020: Go on a Data Safari with MongoDB Charts!
MongoDB SoCal 2020: Go on a Data Safari with MongoDB Charts!
 
MongoDB SoCal 2020: Using MongoDB Services in Kubernetes: Any Platform, Devel...
MongoDB SoCal 2020: Using MongoDB Services in Kubernetes: Any Platform, Devel...MongoDB SoCal 2020: Using MongoDB Services in Kubernetes: Any Platform, Devel...
MongoDB SoCal 2020: Using MongoDB Services in Kubernetes: Any Platform, Devel...
 
MongoDB SoCal 2020: A Complete Methodology of Data Modeling for MongoDB
MongoDB SoCal 2020: A Complete Methodology of Data Modeling for MongoDBMongoDB SoCal 2020: A Complete Methodology of Data Modeling for MongoDB
MongoDB SoCal 2020: A Complete Methodology of Data Modeling for MongoDB
 
MongoDB SoCal 2020: From Pharmacist to Analyst: Leveraging MongoDB for Real-T...
MongoDB SoCal 2020: From Pharmacist to Analyst: Leveraging MongoDB for Real-T...MongoDB SoCal 2020: From Pharmacist to Analyst: Leveraging MongoDB for Real-T...
MongoDB SoCal 2020: From Pharmacist to Analyst: Leveraging MongoDB for Real-T...
 
MongoDB SoCal 2020: Best Practices for Working with IoT and Time-series Data
MongoDB SoCal 2020: Best Practices for Working with IoT and Time-series DataMongoDB SoCal 2020: Best Practices for Working with IoT and Time-series Data
MongoDB SoCal 2020: Best Practices for Working with IoT and Time-series Data
 
MongoDB SoCal 2020: MongoDB Atlas Jump Start
 MongoDB SoCal 2020: MongoDB Atlas Jump Start MongoDB SoCal 2020: MongoDB Atlas Jump Start
MongoDB SoCal 2020: MongoDB Atlas Jump Start
 
MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]
MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]
MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]
 
MongoDB .local San Francisco 2020: Using Client Side Encryption in MongoDB 4.2
MongoDB .local San Francisco 2020: Using Client Side Encryption in MongoDB 4.2MongoDB .local San Francisco 2020: Using Client Side Encryption in MongoDB 4.2
MongoDB .local San Francisco 2020: Using Client Side Encryption in MongoDB 4.2
 
MongoDB .local San Francisco 2020: Using MongoDB Services in Kubernetes: any ...
MongoDB .local San Francisco 2020: Using MongoDB Services in Kubernetes: any ...MongoDB .local San Francisco 2020: Using MongoDB Services in Kubernetes: any ...
MongoDB .local San Francisco 2020: Using MongoDB Services in Kubernetes: any ...
 
MongoDB .local San Francisco 2020: Go on a Data Safari with MongoDB Charts!
MongoDB .local San Francisco 2020: Go on a Data Safari with MongoDB Charts!MongoDB .local San Francisco 2020: Go on a Data Safari with MongoDB Charts!
MongoDB .local San Francisco 2020: Go on a Data Safari with MongoDB Charts!
 
MongoDB .local San Francisco 2020: From SQL to NoSQL -- Changing Your Mindset
MongoDB .local San Francisco 2020: From SQL to NoSQL -- Changing Your MindsetMongoDB .local San Francisco 2020: From SQL to NoSQL -- Changing Your Mindset
MongoDB .local San Francisco 2020: From SQL to NoSQL -- Changing Your Mindset
 
MongoDB .local San Francisco 2020: MongoDB Atlas Jumpstart
MongoDB .local San Francisco 2020: MongoDB Atlas JumpstartMongoDB .local San Francisco 2020: MongoDB Atlas Jumpstart
MongoDB .local San Francisco 2020: MongoDB Atlas Jumpstart
 
MongoDB .local San Francisco 2020: Tips and Tricks++ for Querying and Indexin...
MongoDB .local San Francisco 2020: Tips and Tricks++ for Querying and Indexin...MongoDB .local San Francisco 2020: Tips and Tricks++ for Querying and Indexin...
MongoDB .local San Francisco 2020: Tips and Tricks++ for Querying and Indexin...
 
MongoDB .local San Francisco 2020: Aggregation Pipeline Power++
MongoDB .local San Francisco 2020: Aggregation Pipeline Power++MongoDB .local San Francisco 2020: Aggregation Pipeline Power++
MongoDB .local San Francisco 2020: Aggregation Pipeline Power++
 
MongoDB .local San Francisco 2020: A Complete Methodology of Data Modeling fo...
MongoDB .local San Francisco 2020: A Complete Methodology of Data Modeling fo...MongoDB .local San Francisco 2020: A Complete Methodology of Data Modeling fo...
MongoDB .local San Francisco 2020: A Complete Methodology of Data Modeling fo...
 
MongoDB .local San Francisco 2020: MongoDB Atlas Data Lake Technical Deep Dive
MongoDB .local San Francisco 2020: MongoDB Atlas Data Lake Technical Deep DiveMongoDB .local San Francisco 2020: MongoDB Atlas Data Lake Technical Deep Dive
MongoDB .local San Francisco 2020: MongoDB Atlas Data Lake Technical Deep Dive
 
MongoDB .local San Francisco 2020: Developing Alexa Skills with MongoDB & Golang
MongoDB .local San Francisco 2020: Developing Alexa Skills with MongoDB & GolangMongoDB .local San Francisco 2020: Developing Alexa Skills with MongoDB & Golang
MongoDB .local San Francisco 2020: Developing Alexa Skills with MongoDB & Golang
 
MongoDB .local Paris 2020: Realm : l'ingrédient secret pour de meilleures app...
MongoDB .local Paris 2020: Realm : l'ingrédient secret pour de meilleures app...MongoDB .local Paris 2020: Realm : l'ingrédient secret pour de meilleures app...
MongoDB .local Paris 2020: Realm : l'ingrédient secret pour de meilleures app...
 
MongoDB .local Paris 2020: Upply @MongoDB : Upply : Quand le Machine Learning...
MongoDB .local Paris 2020: Upply @MongoDB : Upply : Quand le Machine Learning...MongoDB .local Paris 2020: Upply @MongoDB : Upply : Quand le Machine Learning...
MongoDB .local Paris 2020: Upply @MongoDB : Upply : Quand le Machine Learning...
 

Retour aux fondamentaux : Penser en termes de documents

  • 1. Penser en termes de documents Buzz Moschetti Architecte d'entreprise, MongoDB buzz.moschetti@mongodb.com @buzzmoschetti
  • 2. Avant de commencer • Ce webinaire est enregistré • Utilisez la fenêtre de discussion pour : • obtenir une assistance technique ; • poser des questions et obtenir des réponses. • L'équipe MongoDB répondra rapidement aux questions en temps réel. • Les questions les plus courantes seront examinées à la fin de ce webinaire.
  • 3. Thème 1 : Pour établir une conception de données efficace, il ne suffit pas d'avoir une base de données • Des structures facilement compréhensibles • Une harmonisation avec les logiciels • Une connaissance des problèmes hérités
  • 4. Thème°2 : Les solutions d'aujourd'hui doivent prendre en compte les besoins de demain • Fin de l'obligation de suivre une configuration requise • Possibilité de monter en charge de façon économique • Des solutions de cycles de vie plus rapides
  • 5. Thème°3 : MongoDB vous donne le choix
  • 6. RDBMS MongoDB Base de données Base de données Table Collection Index Index Ligne Document Colonne Champ Jointure Intégration et liaison Terminologie
  • 7. { _id: “123”, title: "MongoDB: The Definitive Guide", authors: [ { _id: "kchodorow", name: "Kristina Chodorow“ }, { _id: "mdirold", name: “Mike Dirolf“ } ], published_date: ISODate(”2010-09-24”), pages: 216, language: "English", thumbnail: BinData(0,"AREhMQ=="), publisher: { name: "O’Reilly Media", founded: 1980, locations: ["CA”, ”NY” ] } } Qu'est-ce qu'un document ?
  • 8. // Java: maps DBObject query = new BasicDBObject(”publisher.founded”, 1980)); Map m = collection.findOne(query); Date pubDate = (Date)m.get(”published_date”); // java.util.Date // Javascript: objects m = collection.findOne({”publisher.founded” : 1980}); pubDate = m.published_date; // ISODate year = pubDate.getUTCFullYear(); # Python: dictionaries m = coll.find_one({”publisher.founded” : 1980 }); pubDate = m[”pubDate”].year # datetime.datetime Les documents mènent à des constructions de langages
  • 9. 9 Conception de données traditionnelle • Données scalaires uniformes et statiques • Rectangles • Représentation physique de bas niveau
  • 10. 10 Conception de données par document • Formes enrichies et flexibles • Objets • Représentation d'entreprise de niveau supérieur
  • 12. 12 Application de gestion de bibliothèques • Clients/utilisateurs • Livres • Auteurs • Éditeurs
  • 13. 13 Question : Quelle est l'adresse d'un client ?
  • 14. Client + adresse : Tentative initiale > db.patrons.find({ _id : “joe” }) { _id: "joe“, name: "Joe Bookreader”, favoriteGenres: [ ”mystery”, ”programming” ] } > db.addresses.find({ _id : “joe” }) { _id: "joe“, street: "123 Fake St.", city: "Faketon", state: "MA", zip: “12345” }
  • 15. Client + adresse : La méthode MongoDB > db.patrons.find({ _id : “joe” }) { _id: "joe", name: "Joe Bookreader", favoriteGenres: [ ”mystery”, ”programming” ] address: { street: "123 Fake St. ", city: "Faketon", state: "MA", zip: “12345” } }
  • 16. Projection : renvoyez uniquement ce dont vous avez besoin > db.patrons.find({ _id : “joe” }, {“_id”: 0, ”address”:1}) { address: { street: "123 Fake St. ", city: "Faketon", state: "MA", zip: “12345” } } > db.patrons.find({ _id : “joe” }, {“_id”: 0, “name”:1, ”address.state”:1}) { name: "Joe Bookreader", address: { state: "MA” } }
  • 17. 17 La sous-structure fonctionne parfaitement avec le code > addr = db.patrons.find({_id :“joe”},{“_id”: 0,”address”:1}) { address: { street: "123 Fake St. ", city: "Faketon", state: "MA", zip: “12345” } } // Pass the whole Map to this function: doSomethingWithOneAddress(addr); // Somewhere else in the code is the actual function: doSomethingWithOneAddress(Map addr) { // Look for state }
  • 18. N'oubliez pas : les formes des documents peuvent varier > db.patrons.insert({ _id : “bob”, name: ”Bob Nobooks", address: { street: ”139 W45 St. ", city: ”NY", state: ”NY", country: ”USA” } } > db.patrons.find({},{“_id”: 1, ”address”:1}) { _id: “joe”, address: { street: "123 Fake St. ", city: "Faketon", state: "MA", zip: “12345” } } { _id: ”bob", address: { street: ”139 W45 St. ", city: ”NY", state: ”NY", country: ”USA” } }
  • 19. 19 La sous-structure améliore l'agilité > addr = db.patrons.find({_id :“bob”},{“_id”: 0,”address”:1}) { address: { street: ”139 W45 St. ", city: ”NY", state: ”NY", country: ”USA” } } // Pass the whole Map to this function: doSomethingWithOneAddress(addr); doSomethingWithOneAddress(Map addr) { // Look for state and optional country } AUCUNE MODIFICATION apportée aux requêtes Seule l'implémentation unique recherchant le pays doit être modifiée PAS DE DÉPENDANCES DE DURÉE DE COMPILATION lors du transfert des mappages
  • 20. 20 Avantage par rapport aux rectangles resultSet = select street, state, city, country, … Map addr = processIntoMap(resultSet); // Pass the whole Map to this function: doSomethingWithOneAddress(addr); doSomethingWithOneAddress(Map addr) { // Look for state and optional country } Il faut modifier les requêtes pour sélectionner de nouvelles colonnes. Il existe une dépendance de durée de compilation pour traiter de nouvelles colonnes vers le mappage.
  • 21. 21 Montées en charge de la sous-structure pour la modification MongoDB db.patrons.find({}, {”myAddress”:1,”yourAddress”:1,”brokerAddress”:1, “momsAddress”:1, …}) Traditional SQL resultSet = select mystreet, mystate, mycity, mycountry, yourstreet, yourstate, yourcity, yourcountry, brokerstreet, brokerstate, brokercity, brokercountry, momsstreet, momsstate, momscity, momscountry, …
  • 22. 22 Relations un-à-un • Les relations de type « Appartient à » sont souvent intégrées. • Représentation holistique des entités avec leurs attributs et relations intégrés • Performances de lecture exceptionnelles Le plus important : • Insistez sur la simplicité. • Libérez du temps pour résoudre des problèmes de conception de schéma plus difficiles.
  • 23. 23 Question : Quelles sont les adresses d'un client ?
  • 24. Un client et ses adresses > db.patrons.find({ _id : “bob” }) { _id: “bob", name: “Bob Knowitall", addresses: [ {street: "1 Vernon St.", city: "Newton", …}, {street: "52 Main St.", city: "Boston", …} ] }
  • 25. Un client et ses adresses > db.patrons.find({ _id : “bob” }) { _id: “bob", name: “Bob Knowitall", addresses: [ {street: "1 Vernon St.", city: "Newton", …}, {street: "52 Main St.", city: "Boston", …} ] } > db.patrons.find({ _id : “joe” }) { _id: "joe", name: "Joe Bookreader", address: { street: "123 Fake St. ", city: "Faketon", …} }
  • 26. 26 Options de migration • Migrez tous les documents lorsque le schéma est modifié. • Migration à la demande – L'extraction du document d'un client est une modification. – Les clients qui ne fréquentent pas la bibliothèque ne sont jamais mis à jour. • Ne rien faire – La couche de code sait utiliser les champs pour une ou plusieurs adresses
  • 27. 27 Laisser le code traiter les documents Map d = collection.find(new BasicDBObject(”_id”,”bob”)); // Contract: Return either a List of addresses or a null // if no addresses exist // Try to get the new “version 2” shape: List addrl = (List) d.get(”addresses”); // If not there, try to get the old one: if(addrl == null) { Map oneAddr = (Map) d.get(”address”); if(oneAddr != null) { addrl = new List(); addrl.append(oneAddr); } } // addrl either exists with 1 or more items or is null
  • 28. 28 Question : qui a publié ce livre ?
  • 29. 29 Livre • MongoDB : le guide absolu, • par Kristina Chodorow et Mike Dirolf • Date de publication : 24/09/2010 • Pages : 216 • Langue : anglais • Éditeur : O’Reilly Media, CA
  • 30. Livre avec éditeur intégré > book = db.books.find({ _id : “123” }) { _id: “123”, title: "MongoDB: The Definitive Guide", authors: [ "Kristina Chodorow", "Mike Dirolf" ], published_date: ISODate(”2010-09-24”), pages: 216, language: "English", publisher: { name: "O’Reilly Media", founded: 1980, locations: ["CA”, ”NY” ] } }
  • 31. N'oubliez pas la sous-structure ! > book = db.books.find({ _id : “123” }) { _id: “123”, title: "MongoDB: The Definitive Guide", authors: [ { first: "Kristina”, last: “Chodorow” }, { first: ”Mike”, last: “Dirolf” } ], published_date: ISODate(”2010-09-24”), pages: 216, language: "English", publisher: { name: "O’Reilly Media", founded: 1980, locations: ["CA”, ”NY” ] } }
  • 32. 32 Relation un à plusieurs via l'intégration • Optimisée pour les performances de lecture des livres • Nous acceptons la duplication de données • Un index basé sur « publisher.name » permet : – une recherche efficace de tous les livres du même éditeur ; – Une recherche efficace de tous les noms d'éditeurs (différents). • Cela ne veut pas dire qu'il n'existe pas de collection d'éditeurs « principale » (depuis laquelle les données sont copiées lors de la création d'un livre)
  • 33. Éditeurs en tant qu'entités distinctes > publishers = db.publishers.find() { _id: “oreilly”, name: "O’Reilly Media", founded: 1980, locations: ["CA”, ”NY” ] } { _id: “penguin”, name: ”Penguin”, founded: 1983, locations: [ ”IL” ] }
  • 34. Livre unique avec éditeur associé > book = db.books.find({ _id: “123” }) { _id: “123”, publisher_id: “oreilly”, title: "MongoDB: The Definitive Guide", … } > db.publishers.find({ _id : book.publisher_id }) { _id: “oreilly”, name: "O’Reilly Media", founded: 1980, locations: ["CA”, ”NY” ] }
  • 35. Plusieurs livres avec éditeur associé db.books.find({ pages: {$gt:100}} ).forEach(function(book) { // Do whatever you need with the book document, but // in addition, capture publisher ID uniquely by // using it as a key in an object (Map) tmpm[book.publisher.name] = true; }); uniqueIDs = Object.keys(tmpm); // extract ONLY keys db.publishers.find({"_id": {"$in": uniqueIDs } });
  • 36. Produit cartésien = structure de votre choix resultSet = “select B.name, B.publish_date, P.name, P.founded from Books B, Publisher P where P.name = B.publisher_name and B.pages > 100” B.Name B.publish_date P.name P.founded More Jokes 2003 Random House 1843 Perl Tricks 1998 O’Reilly 1980 More Perl 2000 O’Reilly 1980 Starting Perl 1996 O’Reilly 1980 Flying Kites 1980 Random House 1843 Using Perl 2002 O’Reilly 1980 Bad Food 2011 Random House 1843
  • 37. …Difficile à utiliser sans la clause ORDER BY resultSet = “select B.name, B.publish_date, P.name, P.founded from Books B, Publisher P where P.name = B.publisher_name and B.pages > 100 order by P.name”; B.Name B.publish_date P.name P.founded Perl Tricks 1998 O’Reilly 1980 More Perl 2000 O’Reilly 1980 Using Perl 2002 O’Reilly 1980 Starting Perl 1996 O’Reilly 1980 Flying Kites 1980 Random House 1843 Bad Food 2011 Random House 1843 More Jokes 2003 Random House 1843
  • 38. SQL repose sur le désassemblage resultSet = “select B.name, B.publish_date, P.name, P.founded from Books B, Publisher P where P.name = B.publisher_name and B.pages > 100 order by P.name”; prev_name = null; while(resultSet.next()) { if(!resultSet.getString(“P.name”).equals(prevName)) { // “next” publisher name found. Process material // accumulated and reset for next items. makeNewObjects(); //etc. prev_name = resultSet.getString(“P.name”) } }
  • 39. 39 Méthode « one-to-many » avec liaisons • Optimisée pour une gestion efficace des données pouvant évoluer • Méthode familière pour organiser des entités de base • Le code permet d'assembler des documentations récupérées dans d'autres objets, et non pas de désassembler un objet ResultSet unique. – Il peut être plus simple de coder et de maintenir des requêtes plus complexes lors d'un assemblage que lors d'un désassemblage.
  • 40. 40 Question : Quels sont tous les livres publiés par un éditeur ?
  • 41. Éditeur avec des livres associés > publisher = db.publishers.find({ _id : “oreilly” }) { _id: “oreilly”, name: "O’Reilly Media", founded: 1980, locations: [ "CA“, ”NY” ], books: [“123”, “456”, “789”, “10112”, …] } > books = db.books.find({ _id: { $in : publisher.books } })
  • 42. 42 Question : Qui sont les auteurs d'un livre précis ?
  • 43. Livres avec auteurs associés > book = db.books.find({ _id : “123” }) { _id: “123”, title: "MongoDB: The Definitive Guide", … authors: [ { _id: “X12”, first: "Kristina”, last: “Chodorow” }, { _id: “Y45”, first: ”Mike”, last: “Dirolf” } ], } > a2 = book.authors.map(function(r) { return r._id; }); > authors = db.authors.find({ _id : { $in : a2}}) {_id:”X12”,name:{first:"Kristina”,last:”Chodorow”},hometown: … } {_id:“Y45”,name:{first:”Mike”,last:”Dirolf”}, hometown: … }
  • 44. 44 Question : Quels sont tous les livres qu'un auteur a écrits ?
  • 45. > db.authors.find({ _id : “X12” }) { _id: ”X12", name: { first: "Kristina”, last: “Chodorow” } , hometown: "Cincinnati", books: [ {id: “123”, title : "MongoDB: The Definitive Guide“ } ] } > db.books.find({ _id : “123” }) { _id: “123”, title: "MongoDB: The Definitive Guide", … authors: [ { _id: “X12”, first: "Kristina”, last: “Chodorow” }, { _id: “Y45”, first: ”Mike”, last: “Dirolf” } ], } Double lien entre les livres et les auteurs
  • 46. > db.books.find({ _id : “123” }) { authors: [ { _id: “X12”, first: "Kristina”, last: “Chodorow” }, { _id: “Y45”, first: ”Mike”, last: “Dirolf” } ], } > db.books.ensureIndex({“authors._id”: 1}); > db.books.find({ “authors._id” : “X12” }).explain(); { "cursor" : "BtreeCursor authors.id_1", … "millis" : 0, } Autre approche : Indexation du tableau
  • 47. 47 Comparaison entre intégration et liaison • Intégration – Parfait pour les performances de lecture • « Pages d'accueil » d'applications Web et documentations pré-agrégées • Structures complexes – Idéal pour les conceptions immuables ou avec insertion seule – Les insertions peuvent être plus lentes que les liaisons. – L'intégrité des données externes (« not-belongs-to ») doit être gérée. • Liaison – Flexibilité – L'intégrité des données est intégrée. – Le travail est effectué durant les lectures. • N'implique pas forcément davantage de travail que pour un RDBMS.
  • 48. 48 Question : Quels sont les attributs personnalisés pour chaque auteur ?
  • 49. > db.authors.find() { _id: ”X12", name: { first: "Kristina”, last: “Chodorow” }, personalData: { favoritePets: [ “bird”, “dog” ], awards: [ {name: “Hugo”, when: 1983}, {name: “SSFX”, when: 1992} ] } } { _id: ”Y45", name: { first: ”Mike”, last: “Dirolf” } , personalData: { dob: ISODate(“1970-04-05”) } } Attribuer une structure dynamique à un nom connu
  • 50. > db.events.find() { type: ”click", ts: ISODate(“2015-03-03T12:34:56.789Z”, data: { x: 123, y: 625, adId: “AE23A” } } { type: ”click", ts: ISODate(“2015-03-03T12:35:01.003Z”, data: { x: 456, y: 611, adId: “FA213” } } { type: ”view", ts: ISODate(“2015-03-03T12:35:04.102Z”, data: { scn: 2, reset: false, … } } { type: ”click", ts: ISODate(“2015-03-03T12:35:05.312Z”, data: { x: 23, y: 32, adId: “BB512” } } { type: ”close", ts: ISODate(“2015-03-03T12:35:08.774Z”, data: { snc: 2, logout: true, mostRecent: [ … ] } } { type: ”click", ts: ISODate(“2015-03-03T12:35:10.114Z”, data: { x: 881, y: 913, adId: “F430” } } Polymorphisme : Étude nécessaire
  • 51. 51 Question : Quels livres traitent des bases de données ?
  • 52. Catégories en tant que tableau > db.books.find({ _id : “123” }) { _id: “123”, title: "MongoDB: The Definitive Guide", categories: [“MongoDB”, “Databases”, “Programming”] } > db.book.ensureIndex({categories:1}); > db.books.find({ categories: “Databases” })
  • 53. Catégories sous forme de chemin d'accès > db.books.find({ _id : “123” }) { _id: “123”, title: "MongoDB: The Definitive Guide", category: “Programming/Databases/MongoDB” } > db.books.find({ category: ^Programming/Databases/* })
  • 54. À venir dans la version 3.2 : la validation de documents > db.createCollection("books", { "validator": { $and: [ { "title": {$type: “string”} }, { "publishDate": {$type: “date”} }, { $or: [ { "thumbnail": {$exists: False}}, { "thumbnail": {$type: “binary”}} ] } ] } });
  • 55. Validation de documents et schémas légers > db.createCollection("books", { "validator": { $or: [ { $and: [ { "v": 1}, { "title": {$type: “string”} } ] }, { $and: [ { "v": 2}, { "title": {$type: “string”} }, { "publishDate": {$type: “date”} }, { $or: [ { "thumbnail": {$exists: False}}, { "thumbnail": {$type: “binary”}} ] } ] } ] });
  • 56. 56 Résumé • La conception physique est différente dans MongoDB. – Les principes de conception de données de base restent toutefois les mêmes. • L'important est la méthode employée par une application pour accéder aux données ou les manipuler. • La recherche et la capture sont liées aux relations 1:1. • Utilisez une sous-structure pour améliorer l'alignement des objets du code. • Soyez polymorphe ! • Faites évoluer le schéma pour suivre l'évolution des exigences.
  • 58. Merci

Notas do Editor

  1. Bonjour, Je me présente, Buzz Moschetti. Je travaille chez MongoDB et je vais vous présenter le webinaire d'aujourd'hui, « Penser en termes de documents », qui fait partie de notre série « Retour aux fondamentaux ». Si votre planning du jour ne vous permet pas d'étudier le modèle basé sur des documents dans MongoDB, inutile de poursuivre. Revenez quand vous serez plus disponible. Dans le cas contraire, bienvenue ! Ce webinaire dure environ une heure.
  2. Je vais à présent définir certains termes. JOINTURES : Les systèmes de gestion de bases de données relationnelles (RDBMS) utilisent les jointures pour associer des éléments simples afin de former des données plus complexes et volumineuses. Pour obtenir le même résultat, MongoDB utilise l'intégration des données au sein d'autres données et la création de liens.
  3. Voici trois thèmes qu'il faut connaître lorsque l'on pense en termes de documents dans MongoDB. Nous les étudierons donc de façon plus approfondie durant cette présentation. Tout d'abord, pour une conception de schéma efficace…. Je répète : efficace… Ce point n'est pas nouveau ni révolutionnaire pour MongoDB. Il a toujours été notre objectif lors de l'élaboration de nos solutions. Nous avons parfois rencontré des problèmes. Cependant, les structures de données et les API utilisées par MongoDB permettent de répondre beaucoup plus facilement à nos deux premiers points. Pour les ingénieurs en informatique utilisant des logiciels à structures de données empilées, la facilité et l'efficacité d'une harmonisation adéquate de la persistance avec le code (java, javascript, perl, python) sont essentielles pour garantir la robustesse d'une architecture d'informations globale. Au cours de cet exercice, nous nous intéresserons également aux problèmes de systèmes de gestion de bases de données relationnelles (RDBMS) auxquels nous sommes régulièrement confrontés depuis une quarantaine d'années, tels que les explosions de schémas, ainsi que les saturations et les aplatissements de champs. Pour résumer, on peut utiliser la formule : réussite = « schéma » + code
  4. Ceci est peut-être très provoquant. Auparavant, les cycles de configurations requises étaient longs, ce qui donnait lieu à l'une ou l'autre des situations suivantes, ou des deux : Les configurations requises changeaient en cours de processus, invalidant une grande partie de la conception de schéma déjà effectuée, notamment lors de certaines relations d'entités 1:1. Un sérieux problème de qualité : la solution devait passer par une montée en charge allant au-delà de ses objectifs initiaux Il est de moins en moins acceptable que la phase de configuration requise dure 6, 12 ou 18 mois alors que le système développé offre une durée de vie de 10 ans environ. Chacun souhaite que l'architecture d'informations initiale soit opérationnelle en deux semaines, qu'il soit possible de l'étendre de façon incrémentielle et qu'un système puisse être développé sans que sa durée de vie ne dépasse pas nécessairement 10 ans pour « justifier son délai de développement ».
  5. Comme MongoDB s'adapte aux logiciels qui l'entourent, vous disposez d'une grande flexibilité de conception, voire d'innovation pour créer l'ensemble de votre solution. Aujourd'hui, nous étudierons certaines des meilleures pratiques qui vous permettront réellement de « penser en termes de documents ».
  6. Je vais à présent définir certains termes. JOINTURES : Les systèmes de gestion de bases de données relationnelles (RDBMS) utilisent les jointures pour associer des éléments simples afin de former des données plus complexes et volumineuses. Pour obtenir le même résultat, MongoDB utilise l'intégration des données au sein d'autres données et la création de liens.
  7. Ici, le terme de « document » ne désigne pas un objet de type PDF ou MS Word. Pour nous, un « document » correspond à une forme enrichie. Il s'agit de structures de structures de listes de structures dont les ramifications aboutissent à des variables scalaires familières telles que : « int », « double », « datetimes » et « string ». Dans cet exemple, nous pouvons aussi constater que nous transportons une photo miniature dans un type de tableau d'octets binaires ; ceci est également pris en charge de façon native. Cette approche n'est pas la même que celle des RDBMS, qui consiste en un croisement de lignes et de colonnes. Autre différence importante, dans MongoDB, il n'est pas nécessaire que chaque document d'une collection ait la même forme ; celles-ci peuvent VARIER. Dans la version 3.2 à venir, nous prendrons en charge la validation de documentation. Dans les conceptions où certains champs et leurs types sont obligatoires, nous serons donc en mesure de mettre cela en application au niveau du moteur de base de données, un peu (mais pas complètement) comme les schémas traditionnels. À vrai dire, dans la plupart des systèmes non triviaux, même avec un RDBMS et des procédures stockées, etc., de nombreuses validations et logiques sont gérées en dehors de la base de données. À présent, notez bien ce qui suit : Pour les besoins de ce webinaire, nous allons voir cette représentation « en chaînes » d'un document lorsqu'il est émis à partir de l'interface de ligne de commande MongoDB. Ainsi, il sera plus facile de lire et de comprendre les différents points de cette conception structurelle. Mais ne vous y trompez pas : il vaut mieux que la majeure partie de l'interaction entre vos logiciels et MongoDB (ou n'importe quelle autre base de données) se déroule via une fidélité élevée, et non pas via une chaîne volumineuse comprenant des espaces blancs, des retours chariot, des guillemets, etc.
  8. Dans chaque langage, les pilotes représentent les documents sous une forme native la plus adaptée au langage choisi. Java a des mappages, Python a des dictionnaires. Vous devez gérer des objets réels, tels que des dates, et non des chaînes à construire ou à analyser. Autre remarque importante : Nous allons utiliser une fonctionnalité de requête pour faire d'une pierre deux coups : Pour afficher la forme du document Pour afficher un fragment du langage de requête MongoDB lui-même incluant la notation dotpath pour « creuser » les structures secondaires Notez également que dans MongoDB, lorsque les documents entrent ou sortent des collections, ils gardent la même forme. Nous ne nous pencherons donc pas sur l'insertion. Ce paradigme de conception diffère considérablement de celui d'un RDBMS, où, par exemple, la partie Lecture d'une opération implémentée en tant que jointure à 8 voies diffère énormément d'un jeu d'instructions d'insertion (certaines d'entre-elles étant en boucle) requises pour la partie Écriture.
  9. Revenons à la conception de données. … La conception traditionnelle de données se caractérise par certains des points précédents. Ceci est généralement dû aux objectifs de la conception et aux contraintes des moteurs RDBMS hérités qui influencent fortement les données qu'ils reçoivent. Ces plateformes ont été conçues lorsque les CPU étaient lents et que la mémoire était TRÈS coûteuse. Ce qui est intéressant, c'est que les langages de l'époque (COBOL, FORTRAN, APL, PASCAL, C) étaient grandement orientés vers la durée de compilation et adoptaient une expression de structure de données pour le moins rectangulaire. On pourrait alors penser que les schémas rigides combinés à ces langages permettaient d'obtenir une harmonisation adéquate. Cependant, ces plateformes étaient TRÈS orientées vers la représentation physique des données. Par exemple, même si la plupart ont été combinés, les types hérités char, varchar, text, CLOB, etc. pour la représentation des chaînes suggèrent une forte orientation vers le stockage octet par octet.
  10. De leur côté, les documents peuvent être considérés davantage comme des entités commerciales. Vous pouvez vous représenter le transfert entrant et sortant de vos données en tant qu'objets. Les types et fonctionnalités des API de documents sont conçus pour obtenir une harmonisation adéquate avec les langages de programmation d'aujourd'hui : Java, C#, python, node.js, Scala, C++. L'objectif de ces langages n'est plus tant d'obtenir le meilleur délai de compilation que de permettre une manipulation dynamique des données et des réflexions/introspections à ce sujet.
  11. Quoi de mieux pour appréhender ce que nous venons d'aborder que de nous intéresser à un problème concret ?
  12. Aujourd'hui, nous nous pencherons sur les structures de données et le schéma d'une application de gestion de bibliothèques. Cet exemple est parfait. En effet, en général, la majeure partie d'entre vous possède des notions de base sur les entités impliquées, ce qui nous permet d'explorer le 1:1, 1:n, ainsi que d'autres éléments de conception.
  13. Pour pimenter un peu les choses, nous allons établir nos besoins émergeants sous la forme de questions que notre application doit poser à la base de données. Ce point est important car, une fois encore, cela nous permet de surveiller la couche logicielle au-delà de la base de données. Imaginez qu'un client s'approche du comptoir et présente sa carte de bibliothèque pour emprunter des livres. La première chose qu'un bibliothécaire va vouloir faire, c'est de valider l'adresse de ce client, afin de pouvoir lui envoyer une notification s'il ne rend pas son livre à temps.
  14. Voici la première division à établir : 2 collections, une pour les clients et une autre pour leurs adresses. Toutes deux partagent un espace clé commun : le champ d'ID unique _id. L'obtention d'un nom et d'une adresse nécessite alors 2 requêtes. Attention : Notez ici qu'une liste de genres favoris a été configurée. Il s'agit d'une LISTE de chaînes, et non pas d'une chaîne délimitée par un point-virgule ou une virgule. Chaque élément de cette liste peut être entièrement adressé, interrogé et mis à jour via la notation dotpath. Ceci est aussi le cas pour l'intégralité de la liste. En cas de besoin, vous pouvez également l'indexer. Mais n'allons pas trop vite. Pouvons-nous faire mieux ?
  15. Je pense que oui : nous pouvons intégrer la sous-structure d'adresse dans le document du client. Il nous suffit pour cela d'une seule requête. Vous remarquerez que nous avons traité l'adresse en tant qu'objet. Nous n'avons pas tout « mis à plat » dans des champs, tels que addr_street, addr_city, addr_state, etc. Nous reviendrons plus tard sur cet aspect, dans d'autres diapositives, pour découvrir les avantages que cette technique procure. Cet exemple simple nous permet déjà de mettre en avant deux aspects importants de la méthode « Penser en termes de documents » : les tableaux et les structures secondaires.
  16. À ce stade, notre principal problème est que chaque requête agira comme la commande « SELECT * », ce qui peut renvoyer une ÉNORME quantité de données. La fonctionnalité de projection de MongoDB vous permet de contrôler cet aspect. Comme nous pouvons le constater ici, il est possible d'inclure ou d'exclure des champs de manière explicite. Cette opération est traitée côté serveur de façon efficace. Notez qu'il est possible d'utiliser une « notation par points » pour sélectionner l'intégralité d'une sous-structure en tant qu'unité OU UNIQUEMENT des champs secondaires spécifiques. Cette possibilité est très utile.
  17. J'ai indiqué précédemment que nous allions nous pencher un peu plus sur l'efficacité de la sous-structure. La « sous-structure » représente le concept qui permet à votre schéma d'être parfaitement harmonisé avec vos logiciels. En étant capable d'extraire l'intégralité de la structure d'adresse, vous pouvez la transmettre vers une fonctionnalité effectuant un travail intéressant, indépendamment des champs définis. Le plus intéressant avec ces sous-structures, c'est qu'il s'agit de mappages ou de dictionnaires génériques : donc PAS de dépendances de DURÉE DE COMPILATION !
  18. Si vous pensez en termes de documents, n'oubliez pas que les formes des documents peuvent varier. Désolé pour les petits caractères. Mais ici, nous insérons un nouveau document où l'adresse contient un champ supplémentaire nommé « country » (« pays »). Si vous l'observez attentivement, vous constaterez qu'il ne contient pas de champ « zipcode » (« code postal »). Lorsque vous lancez une recherche et demandez le champ d'adresse, deux formes légèrement semblables s'affichent.
  19. Mais, plus important, seul un emplacement « doit » changer : l'emplacement où le nouveau champ « country » est réellement consommé. Ni la requête ni les parties intermédiaires de la pile d'appel ne sont modifiées : le nouveau champ « country » vient simplement s'ajouter.
  20. Si l'on considère que vous n'utilisez pas un environnement « select * » qui contient déjà de nombreux problèmes, il s'agit de l'approche traditionnelle utilisée pour traiter pour le même problème. Pour être bref, je ne vais pas aborder l'intégralité du problème touchant l'instruction ALTER TABLE et les scripts de migration de données, car il peut être évité dans MongoDB. Ici, nous allons nous concentrer sur l'agilité et la précision des modules Day 2 requis et les emplacements disponibles pour eux. Ici, chaque instruction SQL permettant d'extraire la ville, le pays et le code postal doit être validée par rapport au contexte de doSomethingWithOneAddress(). En d'autres termes, si l'appel vers doSomethingWithOneAddress() est présent dans le code (l'appel, PAS l'implémentation), alors l'instruction SQL et l'élément qui la convertit en un objet utile (par chance, situé à proximité) doivent être modifiés. Cette opération peut être très fastidieuse.
  21. Le problème est amplifié par le nombre d'adresses que vous devez extraire. Dans SQL et les rectangles, vous devez suivre tout ce qui semble appartenir à une adresse et à l'instruction ALTER TABLE, puis ajouter des colonnes aux instructions sélectionnées. Dans MongoDB et les documents, la documentation supplémentaire est automatiquement collectée et transmise en aval sans DDL ou délai de compilation. Nous verrons sous peu comment les listes de documents peuvent faciliter cette procédure.
  22. Synthétisons les relations un-à-un. Performances de lecture : spécialement pour les formes complexes de documents qui impliqueraient autrement des JOINTURES. Optimisées, car seule une requête et une correspondance disque/mémoire sont requises. MongoDB est particulièrement utile lors de la résolution des relations d'appartenance 1:1. Seules certaines données non scalaires vous contraindront à créer une table, une clé étrangère et la gestion des clés. Cela permet de maintenir les choses simples.
  23. Les besoins des entreprises ont changé ! Vos contacts peuvent avoir plusieurs adresses. De même, nous savons que la procédure traditionnelle qui consiste à se baser sur de petits groupes d'instances précis et à décomposer une adresse complète en deux champs (address1 et address2) posera problème dans le cas d'une personne dont l'adresse doit se décomposer en 3 champs. Nous avons vu où cela mène la conception de schémas traditionnelle. Nous ne souhaitons pas réitérer cela.
  24. À présent, la modélisation des adresses sous forme de tableau. C'était facile. Nous n'avons pas besoin de créer de table, de configurer les clés étrangères, de gérer les clés, etc. Nous associons la puissance des tableaux avec celle des sous-structures. Parfois, il est plus long de décrire la modification que de l'implémenter et de la mettre à disposition dans le cadre de l'architecture des informations, notamment via l'interrogation et l'indexation. Une fois encore, ces structures enrichies sont présentées dans le pilote côté client sous forme de listes, mappages, dictionnaires, tableaux et autres types haute fidélité.
  25. À présent, supposons que ce changement de conception soit survenu le 2e jour, après le placement du système dans un environnement de production. Que deviennent les anciens documents ayant une adresse et non pas plusieurs ? Ce problème présente deux aspects. Le paradigme de MongoDB est que la couche de code juste au-dessus de la base de données est chargée de la gestion de ces types de choses. Le même code responsable de la validation et des vérifications d'entreprise à plus haut niveau est également responsable de l'utilisation sélective (sur une base de lecture et d'écriture) du champ de l'adresse ou des adresses. Il est possible d'employer plusieurs stratégies de migration conjointement à une fonctionnalité au niveau du code. N'oubliez pas que « penser en termes de documents » revient à concevoir des documents de formes diverses.
  26. Migration lors de la publication : si l'adresse existe, écrivez dans un nouveau tableau de taille 1 les nouveaux champs pour plusieurs adresses et supprimez l'ancien champ pour une seule adresse.
  27. Par « laissez le code s'en occuper », nous voulons dire que le code de couche d'accès aux données coopérant avec le modèle de document simplifie considérablement la modification d'architecture des informations du 2e jour. Une fois encore, il est important de prendre en compte ce point pour penser en termes de documents.
  28. Nous allons continuer en observant une autre relation dans notre architecture des informations émergeante : l'éditeur et les livres.
  29. Ne croyez pas que je fasse de la publicité. Un livre peut avoir plusieurs auteurs….
  30. Voici un premier aspect de la conception. Ici, la relation d'appartenance 1: entre le livre et l'éditeur n'est pas aussi forte que celle associant un client à une adresse. Pour le moment, nous allons choisir de dupliquer le nom de l'éditeur dans chaque livre qu'il a publié. La duplication des données ne pose pas de problème, car l'éditeur ne change pas.
  31. Vous pouvez encore améliorer les choses en augmentant la granularité du nom de l'auteur. Il vous suffit pour cela d'en faire une sous-structure divisée en deux éléments : son prénom et son nom de famille. En règle générale, il est recommandé de supprimer les espaces vides ou les signes de ponctuation intégrés dans un champ en les réduisant en sous-structures.
  32. Cette conception permet d'afficher très rapidement les informations concernant un livre. Il est toujours possible de rechercher rapidement tous les livres d'un éditeur donné.
  33. Imaginons que les informations relatives aux éditeurs ne sont pas statiques. Il est alors possible d'utiliser une méthode plus conventionnelle et de séparer les informations relatives aux éditeurs en différentes collections. Nous devons alors attribuer des _ids : pour cela, nous allons utiliser des exemples simplifiés ici. Notez que dans MongoDB, chaque document doit avoir un _id unique. Cependant, comme le sujet d'aujourd'hui ne concerne pas la construction de paramètres _id avancée, nous ne l'aborderons pas ici. Si vous ne fournissez pas de paramètre _id, il sera créé automatiquement. Voici une information qui vous sera utile plus tard : il n'est pas obligatoire que le paramètre _id soit une chaîne, un chiffre ou une variable scalaire. Il peut s'agir d'une structure à plusieurs champs. Notez que la relation d'appartenance 1:1 des emplacements permet une transition simple.
  34. L'extraction des informations nécessite à présent 2 requêtes. Ce n'est pas très compliqué. Cela ne demande pas plus de travail de codage qu'une JOINTURE. Au lieu de décomposer un objet resultset ou de transmettre le résultat dans un mappage objet-relationnel (ou ORM, pour Object-Relational Mapping), votre couche de code traite directement avec la base de données.
  35. Nous pouvons sans problème obtenir plusieurs livres. Récupérez les livres et, tandis que vous traitez les données de chacun, saisissez l'ID de l'éditeur. Nous allons le stocker dans un mappage pour supprimer les ID en double. Nous procédons ensuite à une recherche efficace en utilisant la clé primaire dans la collection des éditeurs. Ceci fonctionne sans problème, que la liste contienne 1 ou 10 000 éditeurs. Il s'agit là d'une JOINTURE à plusieurs valeurs. Bien entendu, cette approche permet de lier n'importe quelle quantité de collections, pas seulement les deux que nous voyons ici. Dans MongoDB, l'application assemble les documentations à partir de plusieurs requêtes. Avant que la fenêtre de notre discussion soit remplie de questions et de remarques, prenons le temps de comparer rapidement cette méthode avec la méthode SQL.
  36. Cet exemple sera parlant pour la plupart d'entre vous. Comme vous le savez, le comportement de base d'une jointure entraîne quelques complications subtiles : Le produit cartésien de l'objet ResultSet est un rectangle géant contenant des valeurs de colonnes récurrentes. Vous devez effectuer une modification pour que votre application puisse l'assimiler plus facilement. Selon la quantité de colonnes de jointure et la cardinalité, vous risquez de récupérer une GRANDE quantité de données redondantes via votre réseau. De plus, il est difficile de traiter efficacement ce rectangle géant, car les données de jointure se répandent partout.
  37. Il nous faut donc utiliser la clause ORDER BY pour traiter plus facilement ce rectangle géant. Quel est le rapport avec les performances ? Et si notre jointure comportait plus de 2 voies ? Disons, 4 ou 8 ?
  38. Au final, dans toutes les situations (à l'exception des jointures les plus simples), la quantité de travail requise pour démêler ou désassembler ce rectangle géant correspond à la quantité de code requis par MongoDB pour assembler les documentations. Dans le cas des requêtes sophistiquées pour les formes complexes, on pourrait faire valoir que l'assemblage est plus simple à écrire ET à maintenir au 2e jour.
  39. Cette conception permet d'afficher très rapidement les informations concernant un livre. Il est toujours possible de rechercher rapidement tous les livres d'un éditeur donné.
  40. Nous avons déjà vu qu'il existe une méthode pour répondre à cette question : en exécutant une commande find() sur la collection des livres en utilisant un nom OU un ID d'éditeur précis. Mais existe-t-il une autre méthode ?
  41. Même si les tableaux sont très pratiques dans MongoDB, il ne faut pas les utiliser comme des « lignes ». La croissance de vos tableaux doit être « lente » et limitée. Par exemple, ne placez pas un système de transactions d'enregistrements client dans un tableau. Cependant, vous POUVEZ, pour accélérer la montée en charge, dupliquer les 3 dernières transactions sous la forme d'un tableau dans un enregistrement client, mais ce tableau ne débordera pas de ses limites. D'un point de vue technologique sous-jacent, cette situation pose moins de problème maintenant que le moteur de stockage WiredTiger est disponible dans la version 3.0, mais vous devez toujours garder ces limites à l'esprit.
  42. Tandis que notre schéma évolue, nous pouvons voir qu'il est possible de répondre à bon nombre de questions via un jeu d'entités et de relations. Cela fonctionne aussi pour les auteurs : rappelez-vous que nous avons configuré la sous-structure des prénoms et des noms de famille... À présent, que faire si nous voulons détailler davantage nos fiches d'auteurs ?
  43. Nous allons créer la collection des auteurs, avant de la lier à un ID d'auteur. Nous allons utiliser un code plus élaboré pour extraire les ID d'auteurs, mais au final, il s'agit toujours de 2 requêtes. Le code élaboré que nous utilisons ici inclut une opération map() pour extraire uniquement les ID d'auteurs, qui seront transmis à l'opérateur $in. Les documents des auteurs contiennent toutes sortes d'informations sur chaque auteur. Pour ne pas ralentir nos opérations, nous avons laissé le prénom et le nom de famille dans le document des livres. Mais, le cas échéant, nous pourrions les supprimer. Notre choix repose sur un équilibre entre l'intégrité et la vitesse de récupération.
  44. Bien évidemment, nous retournons la question pour commencer à aborder l'approche PLUSIEURS À PLUSIEURS.
  45. Voici comment procéder : Étant donné que la plupart des auteurs ne sont pas aussi productifs que Stephen King ou Danielle Steele, nous pouvons placer un double lien entre les collections de livres et d'auteurs. En général, de telles données sont statiques. L'intégrité référentielle ne risque donc pas de nuire aux performances. Encore une fois, nous avons gardé le titre dans la structure dans le champ « books » (livres), pour des besoins de performance (pour en rester à une seule requête) lors de notre recherche d'informations de base à propos d'un auteur. Mais si nous voulions procéder autrement, il nous suffirait d'organiser les livres selon un tableau d'ID de livres et de mettre en place une approche à 2 requêtes, comme nous l'avons vu dans les diapositives précédentes. Notez que cela ne revient pas à établir un tableau de livres par rapport aux éditeurs, car la limite supérieure pour les auteurs par rapport aux livres est bien plus faible que pour les éditeurs par rapport aux livres.
  46. Rappel : vous pouvez indexer tous les champs, notamment ceux compris dans les structures des tableaux. Nous avons déjà vu un exemple de cette situation, lors de l'indexation à partir de publisher.name.
  47. Structures complexes, telles que les tableaux de paires de coordonnées, les données profondément imbriquées, etc. Pour des conceptions qui ne changeront pas, la méthode la plus sûre/rapide consiste parfois à déréférencer les données. Notez qu'avec l'émergence des tableaux de stockage d'élimination des doublons, cette solution s'avère de plus en plus pratique.
  48. Supposons que la bibliothèque souhaite ajouter une valeur pour exploiter des informations personnalisées fournies par des clubs de lecture. Nous faisons alors face à 3 difficultés : 1. Le club de lecture opère de façon semi-indépendante par rapport aux concepteurs du système principal. Pour être clair, il n'est pas possible de savoir à l'avance quels types d'informations seront apportés par le club de lecture. Chaque auteur peut générer différents jeux d'informations, créés par différents membres d'un club de lecture.
  49. Nous abordons ici un côté particulièrement intéressant de MongoDB. Vous n'avez plus besoin de mettre en place les colonnes 1, 2, etc. pour l'objet userDefined. Ici, nous pouvons voir que Kristina et Mike ont des sous-structures très différentes dans le champ personalData. Nous appelons ceci le polymorphisme, à savoir les changements de forme d'un document dans une même collection. La logique de l'application de la bibliothèque recherche uniquement un champ nommé « personalData ». Des actions seront entreprises de manière dynamique en fonction de la forme et des types de la sous-structure. Par exemple, l'un des exercices les plus basiques consiste à « parcourir » de manière récursive la structure et à construire un volet dans une interface utilisateur (notamment si vous utilisez AngularJS et la pile MEAN). (MongoDB / Express / Angular / Node.js) Vous n'avez pas besoin d'utiliser le XML ou des objets blob/sérialisés. MongoDB les intègre de façon native : les documents sont alors représentés dans la forme que votre langage de programmation peut manipuler le plus facilement en mode natif. Vous pouvez interroger (et indexer) chaque champ. Les documents ne contenant pas de champs dans un prédicat de requête sont simplement traités comme s'ils n'étaient pas définis.
  50. Le polymorphisme est tellement important pour penser en termes de documents qu'il mérite bien de s'y attarder sur une autre diapositive. Voici une collection d'événements. Nous avons retiré le paramètre _id pour gagner de la place. Les champs « type », « ts » et « data » sont bien connus, et il y a probablement un index sur « type » et « ts ». Les contenus des champs « data » varient toutefois selon chaque type. Plus besoin de tables complexes, d'objets blob ou de langage XML. Il est, par ailleurs, très simple d'étendre cette structure à de nouveaux types qui peuvent s'avérer nécessaire le 2e jour. Ce modèle s'étend aux produits, transactions et acteurs d'une conception de données. Si vous considérez vos données comme des entités, vous vous rendrez compte qu'il ne vous en faut pas beaucoup. Ceci, ajouté au polymorphisme dans l'entité, permet bien des choses. En raison de cette approche conceptuelle, il est rare qu'une base de données MongoDB contienne plusieurs centaines de collections.
  51. Voici un exemple de recherche par facettes ou de marquage global.
  52. Nous pouvons simplement commencer par implémenter des catégories sous la forme d'un tableau. Ces dernières ne sont pas très nombreuses, ne changent pas souvent et ont une limite de croissance naturelle. Un index sur les catégories permet une récupération rapide. Là encore, nous faisons face à une utilisation adéquate de la relation 1:1.
  53. Si nous voulons accentuer la hiérarchie, il nous suffit d'utiliser des opérations regex. Le champ « category » est indexé comme avant, mais à présent, en tant que chaîne Un index est utilisé en raison de l'expression régulière ancrée. Cette technique présente toutefois un inconvénient. Lorsqu'une hiérarchie de catégorie est modifiée, il faut établir de nouvelles catégories pour tous les documents.
  54. À présent, voici un petit aperçu d'une nouvelle technologie : la validation de documents. Disponible à partir de la version 3.2, la validation de documents « inverse » l'utilisation d'un langage de requête MongoDB existant. Les documents insérés ou mis à jour seront validés en fonction d'un paramètre de validation, le cas échéant. Il existe plusieurs fonctionnalités spécifiques, telles que « la rigueur lors de la mise à jour », qui sortent du cadre de notre présentation, mais il est important de les connaître.
  55. Nous terminerons cette présentation par une information utile : la validation de documents s'adapte aux modifications au fil du temps. Par exemple, si vous utilisez une « version allégée » de vos documents en incluant un ID de version logique (ici, un simple nombre entier dans le champ v), vous pouvez conserver plusieurs formes de documents dans une collection, la validation leur étant appliquée selon les règles de version du moment. Cet aspect intervenant au niveau du moteur de la base de données, l'application est garantie pour tous les pilotes. Pratique, non ?
  56. Toute l'équipe de MongoDB vous remercie d'avoir participé à ce webinaire. J'espère que ce que vous avez vu et entendu aujourd'hui vous a permis d'acquérir les informations dont vous aurez besoin pour mener à bien la conception de vos données. N'oubliez pas que vous pouvez toujours contacter MongoDB si vous avez besoin d'aide. Ceci étant dit, bonne journée et bon codage.