Événement après scalabilité: Haut n par utilisateur, 1 mise à jour, lecture lourde

Question

Voici la situation. Site Web de plusieurs millions d'utilisateurs. La page de chaque utilisateur a une section de message. Tout le monde peut visiter la page d'un utilisateur, où il peut laisser un message ou afficher les 100 derniers messages.

Les messages sont de courts fragments de texte avec quelques métadonnées supplémentaires. Chaque message doit être stocké en permanence, la seule chose qui doit être rapide en temps réel est la mise à jour des messages et la lecture (les gens l'utilisent comme un chat). Un nombre de messages sera lu très souvent pour vérifier les changements. Périodiquement, vous pouvez archiver les anciens messages (ceux de plus de 100), mais ils doivent être accessibles.

Actuellement tout dans une grande table DB, et la contention entre les personnes lisant les listes de messages et envoyant plus de mises à jour devient un problème.

Si vous deviez réorganiser le système, quel mécanisme de stockage/cache utiliseriez-vous? quel type d'apprentissage en informatique peut être utilisé ici? (par exemple, collections, accès à la liste, etc.)

Answer 1

Quelques réflexions générales, pas particulièrement à une technologie particulière:

1. partition données par ID utilisateur. L'idée est que vous pouvez diviser uniformément l'espace utilisateur en partitions distinctes de la même taille. Vous pouvez utiliser une fonction de hachage appropriée pour répartir les utilisateurs entre les partitions. En fin de compte, chaque partition appartient à une machine distincte. Cependant, même sur des tables/bases de données différentes sur la même machine, ceci éliminera une partie de la contention. Le partitionnement limite la contention et ouvre la porte à une mise à l'échelle "linéaire" dans le futur. Cela aide également à la répartition de la charge et à l'extension.

2. Lorsque vous choisissez une fonction de hachage pour partitionner les enregistrements, recherchez-en une qui minimise le nombre d'enregistrements qui devront être déplacés si des partitions sont ajoutées/supprimées.

3. Comme beaucoup d'autres applications, nous pourrions supposer que l'utilisation du service suit une courbe de loi de puissance: peu de pages utilisateur causent une grande partie du trafic, suivi par une longue queue. Un schéma de mise en cache peut en tirer parti. Plus la courbe est raide, plus la mise en cache sera efficace. Compte tenu des messages courts, si chaque page affiche 100 messages et que chaque message contient en moyenne 100 octets, vous pouvez placer environ 100 000 pages supérieures dans 1 Go de cache RAM. Ces pages mises en cache pourraient être écrites paresseusement dans la base de données. Sur les 10 utilisateurs de Mil, 100 000 sont dans le peloton pour faire la différence.

4. Partitionnez les serveurs Web, en utilisant éventuellement le même schéma de hachage. Cela vous permet de conserver des caches RAM séparés sans conflit. L'avantage potentiel est d'augmenter la taille du cache à mesure que le nombre d'utilisateurs augmente. Si cela est approprié pour votre environnement, une méthode pour s'assurer que les nouveaux messages sont finalement écrits dans la base de données est de les placer dans une file d'attente de messages persistants, juste après les avoir placés dans le cache RAM. La file d'attente ne souffre aucun conflit et permet de garantir que les messages ne sont pas perdus en cas de défaillance de la machine.

Answer 2

Une solution simple pourrait être de dénormaliser vos données et de stocker des agrégats précalculés dans un tableau séparé, par ex. une table MESSAGE_COUNTS qui contient une colonne pour l'ID utilisateur et une colonne pour le nombre de messages. Lorsque la table des messages principaux est mise à jour, recalculez l'agrégat.

C'est simplement déplacer le goulot d'étranglement d'un endroit à l'autre, mais il pourrait le déplacer quelque part qui est moins un fardeau.