50/50 inserts et sélectionne. Créer deux tables ou une table

Question

Maintenant, les structures de table proposées sont les suivantes: -

data_table
->impressions
->clicks
->ctr

ou

data_table_1
->ctr

data_table_2
->impressions
->clicks

Qu'est-ce que les requêtes sont exécutées? Il y a environ 500 mises à jour par seconde pour les impressions. Il y a environ 1 mise à jour pour les clics à chaque seconde. Il y a environ 500 mises à jour par seconde pour le ctr.

Maintenant mon application trie les données en utilisant le ctr. Le ctr est le taux de clic qui est élaboré par ctr = clicks/impressions. Maintenant, je me suis rendu compte que si il y a une mise à jour, cliquez le ctr n'a pas besoin de mise à jour que toutes les impressions d'articles sont augmentés qui diminue le taux de clics dans la même relation, donc à moins d'un clic le ctr n'a pas besoin de être mis à jour.

Actuellement, la requête de mise à jour est comme « UPDATE impressions data_table SET = impressions + 1, = ctr clics / impressions où quelque chose = quelque chose

Cela signifie que bien que 2 champs sont mis à jour une seule fois 1 requête est exécutée.

Maintenant, le goulot d'étranglement est que ces 500 mises à jour sur ce faisant le ralentissement sur ce tableau sélectionne. Il y a environ 20 par seconde sélectionne. Donc, je pensais à séparer les tables. Le nouveau style de table propose que les mises à jour se produisent sur une table séparée et les sélections se produisent sur une table séparée. Le tableau de données contenant les impressions est mis à jour très fréquemment afin d'avoir les mises à jour pour les impressions effectuées sur elle accélère vraiment la performance sur ce tableau. Cela signifie que les sélectionne sur le data_table_2 sera plus rapide aussi, et le ctr peuvent être mis à jour chaque fois que quelqu'un fait un clic.

Alors, je voulais juste savoir si je devrais utiliser la nouvelle structure de la table ou non. Quelles sont vos suggestions? Avantages et inconvénients de mes propositions!

Answer 1

Peut-être que ce n'est pas une réponse directe à votre question, mais je pense qu'il est important de noter.

Je pense que vous devriez envisager d'utiliser des bases de données NoSQL comme Redis, memcachedb, MongDB, CouchDB. SGBD Relatational ne sont pas bien adaptés à ce type d'utilisation. Par exemple, chaque fois que vous mettez à jour la colonne (UPDATE data_table SET impressions = impressions + 1) les caches sont effacés, et la DB doit frapper le disque.

D'autres pensent que vous pouvez envisager est d'utiliser Memcache et en vrac que les données sur le disque après un certain temps.

Par exemple, si vous pouvez vous permettre de perdre quelques Impresions (rappelez-vous que memcache ne persiste pas de données), vous pouvez faire les Impresions ++ dans memcache et les données de mise à jour dans la base de données toutes les 5 minutes. Il considérablement diminuer votre charge.

Je l'espère vous aide.

EDIT :

CTR est une Mémorisation bonne idée, on l'appelle « dénormalisation », et peut travailler dans votre application si elle est une valeur souvent nécessaire.

Answer 2

D'abord, je suppose que la table est bien indexé de sorte que le prédicat something = something entraînera rapidement dans la ligne correspondante, à droite?

De plus en supposant que votre goulot d'étranglement est le disque débit en raison du taux de mise à jour élevé, ce de ne pas stocker la valeur de ctr du tout, car il peut être facilement calculée à la volée? Puisque vous semblez être limité par votre mise à jour, la mise à jour un seul champ devrait à peu près la moitié de l'impact d'avoir à écrire des données sur le disque. Compte tenu de ce scénario, où le CPU est probablement relativement inactif, le calcul de clic / impressions pour chaque résultat devrait être un non-problème. Votre approche rembourserait (disque en supposant à nouveau est le facteur limitant, ce qui suppose qu'il est et peut être trouvé facilement en regardant l'utilisation du processeur), votre approche donnera des avantages considérables, ssi les tables ou sur deux disques différents.

Si la CPU se révèle être le facteur limitant, alors il est probablement parce que le prédicat something = something est assez compliqué d'évaluer dans ce cas, simplifier cela devrait être la principale préoccupation, et non diviser les tables.