Mise à jour notes formation NoSQL
This commit is contained in:
parent
8a06e036a1
commit
912314e24f
|
|
@ -41,20 +41,11 @@
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Les familles de bases NoSQL
|
|
||||||
|
|
||||||
* Clé-valeur (Berkeley DB, memcached, Redis, Apache Ignite, etc.)
|
|
||||||
* Document (MongoDB, Apache CouchDB, etc.)
|
|
||||||
* Colonnes ou "wide column" (Cassandra, HBase, etc.)
|
|
||||||
* Graph (Neo4j, Apache Giraph…)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### Quand utiliser une BDD noSQL ?
|
### Quand utiliser une BDD noSQL ?
|
||||||
|
|
||||||
* Besoin de très grosses performances
|
* Besoin de très grosses performances
|
||||||
* … ou stockage de très grosses données
|
* … ou stockage de très gros volume de données
|
||||||
* Données non adaptées à un RDBM
|
* Données très spécifiques et non-relationnelles
|
||||||
* Et surtout : pas de besoins relationnels !
|
* Et surtout : pas de besoins relationnels !
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
@ -65,6 +56,45 @@
|
||||||
* Et un RDBM supporte aussi de très grandes quantités de données et de bonnes performances… si vous savez bien l'utiliser :)
|
* Et un RDBM supporte aussi de très grandes quantités de données et de bonnes performances… si vous savez bien l'utiliser :)
|
||||||
* Vous n'êtes pas Google, Amazon ou Alibaba !
|
* Vous n'êtes pas Google, Amazon ou Alibaba !
|
||||||
* Une solution SQL (Postgre, MySQL, SQL Server, Oracle…) sera adaptée à 95% des besoins
|
* Une solution SQL (Postgre, MySQL, SQL Server, Oracle…) sera adaptée à 95% des besoins
|
||||||
|
* Sinon : petit projet, "pour tester", qui ne sera pas amené à évoluer, car changer de BDD est lourd !
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## NoSQL : une solution parmi d'autres
|
||||||
|
|
||||||
|
* Les bases NoSQL ont été créées pour répondre à des besoins de très gros acteurs
|
||||||
|
* Besoins qui sont rarement atteints ailleurs
|
||||||
|
* NoSQL est une solution, pas LA solution
|
||||||
|
* Bien évaluer le problème avant de choisir la ou les solutions :)
|
||||||
|
* Le bon côté : NoSQL a initié une modernisation des RDBMs
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Google abandonne NoSQL
|
||||||
|
|
||||||
|
* Google, à l'origine de BigTable et MapReduce, premières solutions NoSQL
|
||||||
|
* … sont repassés à SQL avec [Spanner et le "Standard SQL"](https://blog.timescale.com/blog/why-sql-beating-nosql-what-this-means-for-future-of-data-time-series-database-348b777b847a/) commun à plusieurs outils internes.
|
||||||
|
* Car SQL facilite l'arrivée de nouveaux développeurs et la possibilité de communiquer avec des outils différents mais avec le même langage.
|
||||||
|
* Résultat : solutions NoSQL requêtables en SQL :)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## NoSQL dans SQL, le meilleur des deux mondes ?
|
||||||
|
|
||||||
|
* Stockage JSON dans PostgreSQL (depuis la version 9.2), MySQL (5.7.8), SQLite (3.9.0), SQL Server
|
||||||
|
* Recherche plein texte, index sur les données JSON, jointures !
|
||||||
|
* Implémentation légèrement différente dans SQLite
|
||||||
|
* Performance : pas forcément lent
|
||||||
|
* PostgreSQL est plus rapide avec JSONB que MongoDB par exemple (mais nécessite plus d'optimisation de la configuration)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Les familles de bases NoSQL
|
||||||
|
|
||||||
|
* Clé-valeur (Berkeley DB, memcached, Redis, Apache Ignite, etc.)
|
||||||
|
* Document (MongoDB, Apache CouchDB, etc.)
|
||||||
|
* Colonnes ou "wide column" (Cassandra, HBase, etc.)
|
||||||
|
* Graph (Neo4j, Apache Giraph…)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -198,36 +228,11 @@
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## NoSQL : une solution parmi d'autres
|
### Exemples de NoSQL chez Skyrock
|
||||||
|
|
||||||
* Les bases NoSQL ont été créées pour répondre à des besoins de très gros acteurs
|
* Skyrock : 20+ millions d'utilisateurs, 4+ milliards de commentaires, 500.000 articles / jour, 2 millions de commentaires / jour… 2ème site de France 2007-2010
|
||||||
* Besoins qui sont rarement atteints ailleurs
|
* [Sharedance](https://github.com/jedisct1/sharedance) (clé-valeur, ancêtre de memcached) : stockage de sessions PHP dans un système de fichier en ramdisk
|
||||||
* NoSQL est une solution, pas LA solution
|
* Topy : serveur de statistiques en RAM (avec autodump sur disque). Exemple : utilisateurs les plus actifs, blogs les plus consultés, etc.
|
||||||
* Bien évaluer le problème avant de choisir la ou les solutions :)
|
* [Fluxy](http://zmoo.fr/fluxy.php) : serveur de newsfeed en RAM (avec autodump). Liste des événements liés à un utilisateur. 2 serveurs pour 20+ millions d'utilisateurs
|
||||||
* Le bon côté : NoSQL a initié une modernisation des RDBMs
|
* memcached puis Redis : cache de résultats MySQL, liste des utilisateurs connectés, cache des images uploadées en cours de traitement…
|
||||||
|
* MongoDB : application mobile de chat Smax
|
||||||
---
|
|
||||||
|
|
||||||
## Google abandonne NoSQL
|
|
||||||
|
|
||||||
* Google, à l'origine de BigTable et MapReduce, premières solutions NoSQL
|
|
||||||
* … sont repassés à SQL avec [Spanner et le "Standard SQL"](https://blog.timescale.com/blog/why-sql-beating-nosql-what-this-means-for-future-of-data-time-series-database-348b777b847a/) commun à plusieurs outils internes.
|
|
||||||
* Car SQL facilite l'arrivée de nouveaux développeurs et la possibilité de communiquer avec des outils différents mais avec le même langage.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## NoSQL dans SQL
|
|
||||||
|
|
||||||
* Stockage JSON dans PostgreSQL (depuis la version 9.2), MySQL (5.7.8), SQLite (3.9.0), SQL Server
|
|
||||||
* Recherche plein texte, index sur les données JSON, jointures !
|
|
||||||
* Implémentation légèrement différente dans SQLite
|
|
||||||
* Performance : pas forcément lent
|
|
||||||
* PostgreSQL est plus rapide avec JSONB que MongoDB par exemple, mais nécessite plus d'optimisation de la configuration
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Dans quel cas utiliser une BDD NoSQL ?
|
|
||||||
|
|
||||||
* Gros volume de données
|
|
||||||
* Données très spécifiques et non-relationnelles
|
|
||||||
* Petit projet, "pour tester", qui ne sera pas amené à évoluer, car changer de BDD est lourd !
|
|
||||||
|
|
@ -1,6 +1,7 @@
|
||||||
# Exercices Redis
|
# Exercices Redis
|
||||||
|
|
||||||
Utiliser redis-cli et copier/coller le résultat de chaque exercice (commandes et retours de Redis) dans un fichier texte.
|
* Utiliser redis-cli et copier/coller le résultat de chaque exercice (commandes et retours de Redis) dans un fichier texte.
|
||||||
|
* [Installer Redis sous Windows](https://www.supinfo.com/articles/single/8843-redis-installation-windows)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -65,13 +66,10 @@ Utiliser redis-cli et copier/coller le résultat de chaque exercice (commandes e
|
||||||
|
|
||||||
## Mini-projet : newsfeed de réseau social
|
## Mini-projet : newsfeed de réseau social
|
||||||
|
|
||||||
Note : tout le monde doit utiliser le même serveur Redis au final !
|
* Note : tout le monde doit utiliser le même serveur Redis au final !
|
||||||
|
* Travail en équipe (groupes et classe).
|
||||||
Travail en équipe (groupes et classe).
|
* Prérequis avant de coder : se mettre d'accord avec le reste de la classe de la structure des données à stocker dans Redis (types, noms des clés, etc.) !
|
||||||
|
* Pour rendre les choses plus faciles : la base Redis contiendra une liste unique non ordonnée "utilisateurs" contenant la liste des noms/pseudo des utilisateurs du réseau social.
|
||||||
Prérequis avant de coder : se mettre d'accord avec le reste de la classe de la structure des données à stocker dans Redis (types, noms des clés, etc.) !
|
|
||||||
|
|
||||||
Pour rendre les choses plus faciles : la base Redis contiendra une liste unique non ordonnée "utilisateurs" contenant la liste des noms/pseudo des utilisateurs du réseau social.
|
|
||||||
|
|
||||||
* L'application doit permettre d'ajouter des posts à sa propre timeline
|
* L'application doit permettre d'ajouter des posts à sa propre timeline
|
||||||
* Les posts doivent contenir : date, nom de l'utilisateur, contenu du post
|
* Les posts doivent contenir : date, nom de l'utilisateur, contenu du post
|
||||||
|
|
@ -80,6 +78,6 @@ Pour rendre les choses plus faciles : la base Redis contiendra une liste unique
|
||||||
* L'application doit propager ces posts aux utilisateurs inscrits à sa propre timeline
|
* L'application doit propager ces posts aux utilisateurs inscrits à sa propre timeline
|
||||||
* L'application doit permettre de lire les derniers posts des utilisateurs auxquels on s'est inscrit
|
* L'application doit permettre de lire les derniers posts des utilisateurs auxquels on s'est inscrit
|
||||||
|
|
||||||
Note : l'implémentation de la gestion des utilisateurs et de l'inscription aux timelines des autres utilisateurs est facultative (création d'utilisateur et inscription aux timelines sont possibles à la main avec redis-cli).
|
* Note : l'implémentation de la gestion des utilisateurs et de l'inscription aux timelines des autres utilisateurs est facultative (création d'utilisateur et inscription aux timelines sont possibles à la main avec redis-cli).
|
||||||
|
|
||||||
Note 2 : certaines données associatives peuvent être doublonnées (présence dans plusieurs clés) si besoin.
|
* Note 2 : certaines données associatives peuvent être doublonnées (présence dans plusieurs clés) si nécessaire.
|
||||||
|
|
@ -1,6 +1,5 @@
|
||||||
body {
|
body {
|
||||||
color: #666;
|
color: #000;
|
||||||
font-size: .8em;
|
|
||||||
}
|
}
|
||||||
|
|
||||||
sup {
|
sup {
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue