Commentaires sur : Des alternatives aux bases de données relationnelles… http://blog.octo.com/des-alternatives-aux-bases-de-donnees-relationnelles%e2%80%a6/ Le blog d'OCTO Technology, cabinet d'architectes en systèmes d'information Mon, 15 Mar 2010 11:44:45 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Par : oliv http://blog.octo.com/des-alternatives-aux-bases-de-donnees-relationnelles%e2%80%a6/comment-page-1/#comment-2044 oliv Tue, 02 Feb 2010 17:47:10 +0000 http://blog.octo.com/?p=7370#comment-2044 Notes on Distributed Programming and CAP http://nosql.mypopescu.com/post/319486206/notes-on-distributed-programming-and-cap une explication de Théorème de CAP, des transactions de type BASE (par opposition à ACID) J'aime le slide 39 qui propose des chiffres - Data returned to Shopping Cart 24h profiling : 0,00057% of requests saw 2 versions; 0.00047% of requests saw 3 versions and 0.00009% of requests saw 4 versions. en absolu et même ces faibles pourcentages, il y a qd même moyen que ça soit énorme... Notes on Distributed Programming and CAP
http://nosql.mypopescu.com/post/319486206/notes-on-distributed-programming-and-cap

une explication de Théorème de CAP, des transactions de type BASE (par opposition à ACID)

J’aime le slide 39 qui propose des chiffres
- Data returned to Shopping Cart 24h profiling : 0,00057% of requests saw 2 versions; 0.00047% of requests saw 3 versions and 0.00009% of requests saw 4 versions.

en absolu et même ces faibles pourcentages, il y a qd même moyen que ça soit énorme…

]]> Par : Olivier Mallassi http://blog.octo.com/des-alternatives-aux-bases-de-donnees-relationnelles%e2%80%a6/comment-page-1/#comment-1851 Olivier Mallassi Thu, 03 Dec 2009 21:05:49 +0000 http://blog.octo.com/?p=7370#comment-1851 les 10 secrets d'ebay pour la scalabilité 1.Partition Everything - if you can't split it, you can't scale it. Split everything into manageable chunks by function and data. 2. Asynchrony Everywhere - connect independent components through event queues 3. Automate Everything - components should automatically adjust and the system should learn and improve itself. 4. Remember Everything Fails - monitor everything, provide service even when parts start failing. 5. Embrace Inconsistency - pick for each feature where you need to be on the CAP continuum, no distributed transactions, inconsistency can be minimized by careful operation ordering, become eventually consistent through async recovery and reconciliation. 6. Expect (R)evolution - change is constant, design for extensibility, incrementally deploy changes. 7. Dependencies Matter - minimize and control dependencies, use abstract interfaces and virtualization, components have an SLA, consumers responsible for recovering from SLA violations. 8. Be Authoritative - Know which data is authoritative, which data isn't, and treat it accordingly. 9. Never Enough Data - data drives finding optimization opportunities, predictions, recommendations, so save it all. 10. Custom Infrastructure - maximize the utilization of every resource. Que cela a l'air simple...la suite ici http://highscalability.com/blog/2009/11/17/10-ebay-secrets-for-planet-wide-scaling.html et surtout ici http://www.hpts.ws/session9/shoup.pdf les 10 secrets d’ebay pour la scalabilité
1.Partition Everything – if you can’t split it, you can’t scale it. Split everything into manageable chunks by function and data.
2. Asynchrony Everywhere – connect independent components through event queues
3. Automate Everything – components should automatically adjust and the system should learn and improve itself.
4. Remember Everything Fails – monitor everything, provide service even when parts start failing.
5. Embrace Inconsistency – pick for each feature where you need to be on the CAP continuum, no distributed transactions, inconsistency can be minimized by careful operation ordering, become eventually consistent through async recovery and reconciliation.
6. Expect (R)evolution – change is constant, design for extensibility, incrementally deploy changes.
7. Dependencies Matter – minimize and control dependencies, use abstract interfaces and virtualization, components have an SLA, consumers responsible for recovering from SLA violations.
8. Be Authoritative – Know which data is authoritative, which data isn’t, and treat it accordingly.
9. Never Enough Data – data drives finding optimization opportunities, predictions, recommendations, so save it all.
10. Custom Infrastructure – maximize the utilization of every resource.

Que cela a l’air simple…la suite ici http://highscalability.com/blog/2009/11/17/10-ebay-secrets-for-planet-wide-scaling.html et surtout ici http://www.hpts.ws/session9/shoup.pdf

]]> Par : Olivier Mallassi http://blog.octo.com/des-alternatives-aux-bases-de-donnees-relationnelles%e2%80%a6/comment-page-1/#comment-1850 Olivier Mallassi Thu, 03 Dec 2009 20:55:30 +0000 http://blog.octo.com/?p=7370#comment-1850 L'informatique comme la biologie est basée sur des matériaux composites : une agrégation de différentes briques élémentaires qui permettent de faire une autre brique à plus forte valeur. La question n'est donc pas de savoir quel est LE bon outil qui repondra à toutes les spécificités du système informatique mais quels sont les bons outils et leur bon agencement qui permettra d'etre optimum car chaque brique/outil a son cadre d'utilisation privilégié, ses limites propres Le corps humain est ainsi fait : des centaines de cellules de différents types le compose je ne peux que vous inviter à continuer le voyage ici http://highscalability.com/blog/2009/11/16/building-scalable-systems-using-data-as-a-composite-material.html C'est que quelque sorte, la voie de la sagesse... Au dela de cet article de Todd Hoff. j'aime également la comparaison que l'on peut faire entre organismes vivants et nos organisations/systèmes informatiques. Peut-être aurai-je l'occasion d'en reparler. L’informatique comme la biologie est basée sur des matériaux composites : une agrégation de différentes briques élémentaires qui permettent de faire une autre brique à plus forte valeur.

La question n’est donc pas de savoir quel est LE bon outil qui repondra à toutes les spécificités du système informatique mais quels sont les bons outils et leur bon agencement qui permettra d’etre optimum car chaque brique/outil a son cadre d’utilisation privilégié, ses limites propres

Le corps humain est ainsi fait : des centaines de cellules de différents types le compose

je ne peux que vous inviter à continuer le voyage ici http://highscalability.com/blog/2009/11/16/building-scalable-systems-using-data-as-a-composite-material.html
C’est que quelque sorte, la voie de la sagesse…

Au dela de cet article de Todd Hoff. j’aime également la comparaison que l’on peut faire entre organismes vivants et nos organisations/systèmes informatiques. Peut-être aurai-je l’occasion d’en reparler.

]]> Par : David Rousselie http://blog.octo.com/des-alternatives-aux-bases-de-donnees-relationnelles%e2%80%a6/comment-page-1/#comment-1826 David Rousselie Thu, 26 Nov 2009 09:15:56 +0000 http://blog.octo.com/?p=7370#comment-1826 Petite remarque tout de même, l'accès aux données sur ce type de stockage n'est pas limité à GET sur la clef de la donnée que l'on veut récupérer. Par exemple, [MongoDB|http://www.mongodb.org] permet de faire une recherche par pattern matching : http://www.mongodb.org/display/DOCS/Advanced+Queries ou encore [CouchDB|http://couchdb.apache.org/] permet de créer des vues (qui s'appuient sur des fonctions de mapping) pour remplacer des requêtes complexes : http://books.couchdb.org/relax/design-documents/views. Petite remarque tout de même, l’accès aux données sur ce type de stockage n’est pas limité à GET sur la clef de la donnée que l’on veut récupérer. Par exemple, [MongoDB|http://www.mongodb.org] permet de faire une recherche par pattern matching : http://www.mongodb.org/display/DOCS/Advanced+Queries ou encore [CouchDB|http://couchdb.apache.org/] permet de créer des vues (qui s’appuient sur des fonctions de mapping) pour remplacer des requêtes complexes : http://books.couchdb.org/relax/design-documents/views.

]]> Par : Dom Derrien http://blog.octo.com/des-alternatives-aux-bases-de-donnees-relationnelles%e2%80%a6/comment-page-1/#comment-1789 Dom Derrien Fri, 13 Nov 2009 17:57:59 +0000 http://blog.octo.com/?p=7370#comment-1789 Re: « eventually consistent » - Cela devrait être traduit « consistent à la fin » ou « consistent au final », car dans la technique, il n'y a pas d'incertitude : tout sera consistent à un moment donné. « eventually » fait partie des faux-amis ;) Re: tout remonte dans l’espace applicatif - Très vrai ! Mais avec le bon effet, à mon avis, de mettre en évidence la complexité inhérente de certaines requêtes que SQL permet de coder en 1 ligne. Plus d'excuse donc pour les développeurs qui seraient surpris par les problèmes de performance de leur application ;) Re: gestion des backups - S'il est vrai que les solutions <i>officielles</i> se font attendre, des alternatives existent, comme celle de <a href="http://code.google.com/appengine/articles/gae_backup_and_restore.html" rel="nofollow">Aral Balkan pour App Engine</a>. Bonne continuation, A+, Dom Re: « eventually consistent »
- Cela devrait être traduit « consistent à la fin » ou « consistent au final », car dans la technique, il n’y a pas d’incertitude : tout sera consistent à un moment donné. « eventually » fait partie des faux-amis ;)

Re: tout remonte dans l’espace applicatif
- Très vrai ! Mais avec le bon effet, à mon avis, de mettre en évidence la complexité inhérente de certaines requêtes que SQL permet de coder en 1 ligne. Plus d’excuse donc pour les développeurs qui seraient surpris par les problèmes de performance de leur application ;)

Re: gestion des backups
- S’il est vrai que les solutions officielles se font attendre, des alternatives existent, comme celle de Aral Balkan pour App Engine.

Bonne continuation,
A+, Dom

]]> Par : omallassi http://blog.octo.com/des-alternatives-aux-bases-de-donnees-relationnelles%e2%80%a6/comment-page-1/#comment-1788 omallassi Fri, 13 Nov 2009 15:32:16 +0000 http://blog.octo.com/?p=7370#comment-1788 La problématique de modélisation des données dans un espace non relationnel : tout un programme qui début ici http://highscalability.com/blog/2009/10/29/paper-no-relation-the-mixed-blessings-of-non-relational-data.html J'avoue ne pas avoir encore lu l'étude référencée mais ce n'est qu'une question de temps... La problématique de modélisation des données dans un espace non relationnel : tout un programme qui début ici
http://highscalability.com/blog/2009/10/29/paper-no-relation-the-mixed-blessings-of-non-relational-data.html

J’avoue ne pas avoir encore lu l’étude référencée mais ce n’est qu’une question de temps…

]]> Par : omallassi http://blog.octo.com/des-alternatives-aux-bases-de-donnees-relationnelles%e2%80%a6/comment-page-1/#comment-1787 omallassi Fri, 13 Nov 2009 15:26:01 +0000 http://blog.octo.com/?p=7370#comment-1787 De chouettes articles qui causent de memcached, MySQL et Tokyo Tyrant (en tant qu'espace de stockage non relationnel). http://highscalability.com/blog/2009/10/28/and-the-winner-is-mysql-or-memcached-or-tokyo-tyrant.html La encore des chiffres (attention aux conditions qui ont permis de tels chiffres). "- When memcached has enough memory (so records being accessed are in RAM), memcached + MySQL can provide a 10x performance boost over MySQL alone - When the database is removed and memcached serves both reads and writes the result is a 2.5x more performance over MySQL + memcached and 100x over MySQL alone - Tokyo Tyrant is a disk based key-value store. Tyrant was nearly 2x faster than MySQL + memcached and about 20% slower than a memcached only solution" je ne peux que vous conseillez de lire les articles originaux : simples, efficaces et qui posent bien les problématiques/limitations - http://www.mysqlperformanceblog.com/2009/10/15/mysql-memcached-or-nosql-tokyo-tyrant-part-1/ - http://www.mysqlperformanceblog.com/2009/10/16/mysql_memcached_tyrant_part2/ - http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/ De chouettes articles qui causent de memcached, MySQL et Tokyo Tyrant (en tant qu’espace de stockage non relationnel).
http://highscalability.com/blog/2009/10/28/and-the-winner-is-mysql-or-memcached-or-tokyo-tyrant.html

La encore des chiffres (attention aux conditions qui ont permis de tels chiffres).
« - When memcached has enough memory (so records being accessed are in RAM), memcached + MySQL can provide a 10x performance boost over MySQL alone
- When the database is removed and memcached serves both reads and writes the result is a 2.5x more performance over MySQL + memcached and 100x over MySQL alone
- Tokyo Tyrant is a disk based key-value store. Tyrant was nearly 2x faster than MySQL + memcached and about 20% slower than a memcached only solution »

je ne peux que vous conseillez de lire les articles originaux : simples, efficaces et qui posent bien les problématiques/limitations
- http://www.mysqlperformanceblog.com/2009/10/15/mysql-memcached-or-nosql-tokyo-tyrant-part-1/
- http://www.mysqlperformanceblog.com/2009/10/16/mysql_memcached_tyrant_part2/
- http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/

]]> Par : omallassi http://blog.octo.com/des-alternatives-aux-bases-de-donnees-relationnelles%e2%80%a6/comment-page-1/#comment-1786 omallassi Fri, 13 Nov 2009 14:29:21 +0000 http://blog.octo.com/?p=7370#comment-1786 des retours d'exp. de Digg. Toujours intéressant à prendre http://blog.digg.com/?p=966 surtout que là ils exposent un vrai cas. des retours d’exp. de Digg.

Toujours intéressant à prendre
http://blog.digg.com/?p=966 surtout que là ils exposent un vrai cas.

]]>