> D'ailleurs, je ne comprends pas pourquoi cela n'existe pas plus.
J'aurais tendance à dire de façon provocatrice : parce que ce n'est peut-être pas si utile que ça :)
Ou plus exactement : parce que les solutions actuelles et éprouvées se rapprochent de ce que peuvent fournir les solutions de stockage RAM+BBU :
- Pour les lectures : la RAM "centrale" de la machine produit les mêmes effets car elle est exploitée par le page cache de l'OS ; de plus elle peut être utilisée pour d'autres choses en cas de besoin de l'OS ou des applications. Dans le cas de MySQL par ex., le buffer_pool_cache d'InnoDB est nettement plus rapide d'accès que le cache de l'OS (et probablement, qu'un accès via stockage de masse "ram-based") parce qu'il est "sur mesure" et n'impose pas de passer par la conversion en requètes de lecture/écriture et les diverses couches scsi/block/io_scheduler/... de l'OS pour atteindre les données. Ce n'est généralement pas protégée par batterie, mais ce n'est pas critique (ormi la dégradation initiale des perfs lors d'un cold boot, le temps que le cache de l'OS ou de l'appli se remplisse).
- Pour les écritures, il y a la RAM dans le contrôleur RAID (protégée par BBU). Si elle est de taille suffisante, elle permet souvent d'agréger suffisamment les I/O aléatoire pour s'approcher du débit linéaire du stockage de masse (ce qui est quand même pas mal, le débit linéaire d'un simple agrégat de 4 disques SAS 15krpm en RAID 10 est honorable de nos jours).
En comparaison, le SSD reste intéressant pour les machines ne pouvant intégrer suffisamment de RAM (par ex. les desktop ou serveurs installés en 32 bits), de contrôleur raid moderne (ditto). Et aussi (surtout) pour des questions de place et d'économie d'énergie : les disques durs, ça suce.
[^] # Stockage en RAM
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 1.
J'aurais tendance à dire de façon provocatrice : parce que ce n'est peut-être pas si utile que ça :)
Ou plus exactement : parce que les solutions actuelles et éprouvées se rapprochent de ce que peuvent fournir les solutions de stockage RAM+BBU :
- Pour les lectures : la RAM "centrale" de la machine produit les mêmes effets car elle est exploitée par le page cache de l'OS ; de plus elle peut être utilisée pour d'autres choses en cas de besoin de l'OS ou des applications. Dans le cas de MySQL par ex., le buffer_pool_cache d'InnoDB est nettement plus rapide d'accès que le cache de l'OS (et probablement, qu'un accès via stockage de masse "ram-based") parce qu'il est "sur mesure" et n'impose pas de passer par la conversion en requètes de lecture/écriture et les diverses couches scsi/block/io_scheduler/... de l'OS pour atteindre les données. Ce n'est généralement pas protégée par batterie, mais ce n'est pas critique (ormi la dégradation initiale des perfs lors d'un cold boot, le temps que le cache de l'OS ou de l'appli se remplisse).
- Pour les écritures, il y a la RAM dans le contrôleur RAID (protégée par BBU). Si elle est de taille suffisante, elle permet souvent d'agréger suffisamment les I/O aléatoire pour s'approcher du débit linéaire du stockage de masse (ce qui est quand même pas mal, le débit linéaire d'un simple agrégat de 4 disques SAS 15krpm en RAID 10 est honorable de nos jours).
En comparaison, le SSD reste intéressant pour les machines ne pouvant intégrer suffisamment de RAM (par ex. les desktop ou serveurs installés en 32 bits), de contrôleur raid moderne (ditto). Et aussi (surtout) pour des questions de place et d'économie d'énergie : les disques durs, ça suce.