MEME SUJET POUR PLUSIEURS QUESTIONS
Vous disposez d'une base de données en documents lourds (1 document/row contient 1Mo de données). Vous remarquez que le goulot d’étranglement de votre base de données n'est pas le nombre de requêtes de lecture/écriture mais la quantité de données transitant pour chacune des requêtes (1Mo).
Votre base de données permet d'effectuer des opérations atomiques sur plusieurs tables/collections.
L'écriture de documents/rows se fait en 1 write. La lecture quant à elle est partielle (les utilisateurs n'ont besoin que de sous ensembles des informations des documents/rows en même temps). Vous identifiez 3 sous ensembles, de taille respectives 0.2Mo 0.6Mo 0.5Mo. Le ratio lecture / écriture étant de 5, vous décidez de différentier les canaux utilisés à l'écriture de ceux de lecture pour profiter du fait que les lectures font moins transiter de données.
L'idée A est la redondance physique. Vous attachez une base de données esclave à votre base de données actuelle. Cette dernière recevra les opérations d'écriture, qui seront répliquées sur la base esclave. Les opérations de lecture seront dirigées directement sur les tables esclaves.
L'idée B est de conserver des tables pour chacun des sous ensembles (en plus de la table principale). Ces tables sont donc des caches persistants, en base de données. 1 opération d'écriture écrit donc le document/row principal + 1 petit document/row prêt à l'emploi pour chacune des opérations de lecture (3).
L'idée C est d'écrire des requêtes SQL/mapReduce sur mesure pour chacune des opérations de lecture afin de ne retourner que les sous ensembles nécessaires à chacune des lectures. Votre base de donnée n'est donc pas modifiée et vous disposez de trois interfaces sur mesures pour chacun des sous ensembles.
EN TERMES DE RAPIDITE DE D'ECRITURE :