Nous avons effectivement fait le choix d'optimiser les lectures, ce qui tient debout pour des applications web. Il faut voir que sur la plupart des architectures Web, c'est le trafic externe qui coûte, pas le trafic interne.
Il est complètement illusoire de faire un système qui fonctionne à la perfection aussi bien en écriture qu'en lecture, sur des petits fichiers comme sur des gros ensembles de données, qui soit à la fois distribué et réparti, avec une charge CPU proche du zéro, une consommation réseau pratiquement nulle,et une latence inférieure à celle d'un disque SSD.
Désactiver la réplication asynchrone n'est absolument pas à l'ordre du jour. Cela permettrait juste de réduire une partie du trafic réseau, mais on risquerait la perte de données. Non, cela va complètement à l'encontre des buts de FineFS.
Ce serait comme demander au GoogleFS (je parle du filesystem utilisé en interne dans les datacenters de Google, pas du montage de GMail) d'être efficace sur des petits fichiers, alors qu'il a été conçu pour des fichiers pesant des centaines de mégas voire des gigas. Ou de demander à la base Dynamo d'Amazon de gérer les données de manière relationnelle, alors que son but est justement de ne pas être relationnel pour gagner en performance.
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 4.
Il est complètement illusoire de faire un système qui fonctionne à la perfection aussi bien en écriture qu'en lecture, sur des petits fichiers comme sur des gros ensembles de données, qui soit à la fois distribué et réparti, avec une charge CPU proche du zéro, une consommation réseau pratiquement nulle,et une latence inférieure à celle d'un disque SSD.
Désactiver la réplication asynchrone n'est absolument pas à l'ordre du jour. Cela permettrait juste de réduire une partie du trafic réseau, mais on risquerait la perte de données. Non, cela va complètement à l'encontre des buts de FineFS.
Ce serait comme demander au GoogleFS (je parle du filesystem utilisé en interne dans les datacenters de Google, pas du montage de GMail) d'être efficace sur des petits fichiers, alors qu'il a été conçu pour des fichiers pesant des centaines de mégas voire des gigas. Ou de demander à la base Dynamo d'Amazon de gérer les données de manière relationnelle, alors que son but est justement de ne pas être relationnel pour gagner en performance.