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 QUANTITE DE DONNEES TRANSITANT ENTRE VOTRE SERVEUR ET VOTRE BASE DE DONNEES D'ECRITURE (lors d'une opération d'écriture)