Skip to content

lego-technix/test-split-tables-based-on-read-write-frequency

Repository files navigation

test-splitting-up-tables-based-on-read-write-frequency

Principe

L'objectif est de comparer 2 manières de faire : monolithic vs split

Sont créées 2 bases de données distinctes, l'une avec une table monolithique et l'autre avec deux tables séparées, chacune avec avec 1 million de lignes.

Ensuite sont comparés avec time le temps que mettent 1 million de fois un update (sur lastLoggedAt et updatedAt) suivi d'un select pour chacune des bases de données. L'objectif est de savoir si la modification de lignes de users influe sur la récupération de lignes de users récupérées par le biais d'un index.

Procédure

./create-db-monolithic
./populate-db-monolithic
time ./test-db-monolithic
./create-db-split
./populate-db-split
time ./test-db-split

Valeurs et résultats

Voici les valeurs et résultats obtenus sur mon système.

Temps

La manière monolithic prend 68,376 secondes et la manière split prend 50,986 secondes.

time ./test-db-monolithic
real    1m8,376s
user    0m0,020s
sys     0m0,009s
time ./test-db-split
real    0m50,986s
user    0m0,022s
sys     0m0,008s

Tailles des différentes tables

La manière monolithic prend 507 MB et la manière split prend 546 MB.

postgres=# select pg_size_pretty(pg_database_size('test_monolithic'));
 pg_size_pretty 
----------------
 499 MB
test_monolithic=# select pg_size_pretty(pg_relation_size('users'::regclass));
 pg_size_pretty 
----------------
 270 MB
postgres=# select pg_size_pretty(pg_database_size('test_split'));
 pg_size_pretty 
----------------
 562 MB
test_split=# select pg_size_pretty(pg_relation_size('users'::regclass));
 pg_size_pretty 
----------------
 128 MB
test_split=# select pg_size_pretty(pg_relation_size('user-logins'::regclass));
 pg_size_pretty 
----------------
 146 MB

Conclusion

Avec la manière split il y a donc une diminution des temps d'accès notable.

Avec la manière split il y a donc une augmentation de taille notable mais pas rédhibitoire.

Choisir la manière split est donc avantageux en terme de rapidité sans présenter d'inconvénient bloquant. Et surtout elle permet de regrouper dans une table dédiée user-logins toutes les données relatives au login, ce qui a beaucoup de sens en terme d'architecture notamment pour faciliter la compréhension et le travail des développeurs.

Articles parlant du sujet

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages