1. Architecture répartie en environnement Web

3. « Haute disponibilité » Capacité des systèmes informatiques à fournir le service prévu à tout moment, même en cas de panne d'une partie conséquente de leurs moyens matériels.

4. Hébergement mutualisé Partage de ressources Bon marché Fiable Possibilités et ressources limitées

5. Serveur dédié Ressources dédiées Puissant Mauvaise fiabilité Administration ?

6. Évolution verticale ( scaling in ) Augmentation des capacités du serveur Facile à mettre en œuvre Fiabilité limitée Repousse juste la limite

7. Évolution horizontale ( scaling out ) Augmentation du nombre de serveurs Théoriquement illimité Fiabilité par redondance Complexe à mettre en œuvre

8. Anatomie d'un serveur Matériel Processeur(s) Mémoire vive Disque(s) dur(s)

9. Anatomie d'un serveur Système d'exploitation Linux, Windows, Mac OS X, Solaris, BSD, ...

10. Anatomie d'un serveur Applicatif Serveur HTTP (Apache, Lighttpd, Nginx, …) Application (JEE, PHP, Perl, Ruby, .NET, ...)

11. Anatomie d'un serveur Stockage de fichiers Disque dur local

12. Anatomie d'un serveur Base de données MySQL, PostgreSQL, Oracle, SQL Server, DB2, Informix, ...

13. Applicatif : bonne scalabilité Installation identique sur chaque serveur Répartition de charge Haute disponibilité

14. Problèmes ? Base de données Stockage de fichiers

17. Le vrai problème ? Le coût !

18. Les solutions existent (il suffit d'être millionnaire) Cluster base de données (ex : Oracle RAC sur serveurs SUN) Baies de stockage (ex : NetApp)

19. Frontaux web Serveurs de fichiers (NAS / SAN) Base de données (Oracle RAC, MySQL cluster, ...)

20. Réplication mono-directionnelle

21. Ces solutions sont chères Impossible de démarrer un projet en utilisant ces technologies

22. Ces solutions sont chères Impossible de démarrer un projet en utilisant ces technologies Concrètement, on fait quoi ?

23. Scale in + scale out Lectures Écritures

24. Scale in + scale out + réplication Écritures Lectures en local Réplication

25. Mais les requêtes SQL sont très gourmandes en ressources On essaye d'en faire le moins souvent possible On exécute les requêtes une fois puis on stocke leurs résultats en cache pour les accès suivants

26. Scale in + scale out + cache Écritures Lectures en cache Requêtes pour remplir le cache

27. Avec le cache, les données sont agrégées telles qu'on les utilise dans l'application Pourquoi ne pas stocker directement les données sous ce format ? En réduisant les fonctionnalités des bases de données, on peut augmenter leur scalabilité.

28. Avec le cache, les données sont agrégées telles qu'on les utilise dans l'application Pourquoi ne pas stocker directement les données sous ce format ? En réduisant les fonctionnalités des bases de données, on peut augmenter leur scalabilité. Bases de données non relationnelles

29. User - id - name - login Article - id - title - content - user_id Comment - id - date - text - article_id { name: "Amaury Bouchard" , login: "amaury" , articles: [ { title: "Article de test" , content: "Bla bla bla" , comments: [ { date: "2010-05-20" , text: "Super !" }, { date: "2010-05-21" , text: "Génial !" } ] }, { ... } , { ... } ] }

30. Solutions SQL alternatives Sharding Découper une base en plusieurs morceaux pour alléger et paralléliser les traitements Dénormalisation Dupliquer les données pour réduire le nombre de jointures nécessaires

31. Solutions SQL alternatives Sharding Découper une base en plusieurs morceaux pour alléger et paralléliser les traitements Dénormalisation Dupliquer les données pour réduire le nombre de jointures nécessaires Amélioration des performances Inutile pour la haute-disponibilité Est-ce encore un modèle relationnel ?

32. Théorème de Brewer Dans un environnement distribué, il est impossible de garantir à la fois : La consistance La disponibilité La tolérance aux pannes

33. Théorème de Brewer Dans un environnement distribué, il est impossible de garantir à la fois : La consistance La disponibilité La tolérance aux pannes Haute-disponibilité : consistance réduite

34. Modèles de duplication de données Centralisé Serveur de méta-données unique Multiples serveurs de données Décentralisé Données réparties sur plusieurs serveurs en fonction d'une clé de hachage

35. Et le cloud computing ? Virtualisation des serveurs Utilisation de ressources à la demande

36. Participer à des projets intéressants ? FineFS Système de fichiers redondé écrit en PHP Complètement décentralisé Synchrone et asynchrone Plus rapide que Memcache en lecture FineDB Base de données non relationnelle Orienté document (stockage JSON) Stockage basé sur FineFS

37. geek-directeur-technique.com/udm finefs.googlecode.com finedb.googlecode.com [email_address]