Stratégies pour travailler avec des bases de données lentes avec des applications Web

Question

Nous essayons de trouver la meilleure solution pour travailler avec une base de données lente sur un site Web en direct.

L'architecture des systèmes de base est la suivante:

• lent (certains lectures et la plupart des écritures sont rapides, d'autres prennent plusieurs secondes) DB Postgres. Nous n'avons aucun contrôle sur cela.
• Un système hors ligne monolithique qui accède à la base de données Postgres. Nous n'avons aucun contrôle sur cela.
• Serveur (s) interne (s) rapide (s) pouvant accéder à la base de données Postgres. Nous pouvons développer et installer des logiciels pour ce serveur.
• Serveur (s) Web rapide exécutant une pile LAMP qui ne peut pas accéder à la base de données Postgres, mais qui peut accéder au serveur interne. Nous pouvons développer des logiciels pour ce serveur.
• Base (s) de données MySQL rapide (s) accessible (s) par tout. Nous avons un contrôle total sur cela.

Nous développons une nouvelle application Web pour fonctionner sur les serveurs Web en utilisant Symfony 2.

Notre plan initial était de créer une API RESTful pour s'asseoir sur le serveur interne, qui est consommé par l'application Web . Le problème majeur auquel nous sommes confrontés est que la vitesse de l'application Web est limitée par la vitesse de la base de données Postgres, ce qui est inacceptable pour les utilisateurs.

Est-ce que quelqu'un connaît des stratégies pour contourner ce problème de vitesse? La mise en cache est la solution évidente et nous pouvons certainement avoir des discussions sur la façon dont les données doivent être à jour, mais dans certaines circonstances, elles doivent être absolument à la minute près. Par exemple, si un utilisateur enregistre des modifications, celles-ci doivent apparaître immédiatement. Nous avons envisagé de doter l'API de son propre magasin de données rapide qu'elle met à jour de manière asynchrone depuis Postgres. Nous pourrions alors effectuer toutes les lectures sur ce stockage rapide, en validant les écritures à la fois et Postgres. L'inquiétude est bien sûr la cohérence des données et une complexité accrue du système. Nous explorons l'utilisation de JSON-LD pour représenter les données car elles correspondent bien à ce que nous travaillons. L'utilisation d'une norme, même si elle est relativement récente, devrait faciliter les changements architecturaux majeurs à venir. bien arriver. Comme il pourrait être placé directement dans un magasin de documents, cela pourrait simplifier le processus.

Nos objectifs clés sont:

• offrir une bonne expérience pour les utilisateurs.
• Créez un système facile à gérer et facile à comprendre.

Toutes les recommandations ou suggestions seraient les bienvenues!

Answer 1

Je pense que la principale question à poser est la suivante: pourquoi la Postgres DB est-elle si lente? D'après votre explication, il n'est pas clair non plus ce que tous ces systèmes font et quelles sont les dépendances/exigences. Par exemple, les données de PostgresDB doivent-elles être à jour? Est-ce la base de données principale? Est-ce un DB d'intégration pour le système hors ligne monolithique?

Si vous ne pouvez pas modifier la base de données Postgres lente, elle doit être à jour et le site Web en dépend et doit être à la minute (dans certains cas), vous avez un problème parce que ce ne sera pas possible. Si la base de données Postgres n'a pas besoin d'être à la minute car elle est simplement utilisée par l'application hors ligne, vous pouvez la mettre à jour de manière asynchrone et utiliser vos bases de données MySQL de manière à obtenir les performances nécessaires. Etant donné que vous prévoyez d'utiliser JSON-LD, j'aimerais en savoir plus sur le système que vous construisez. Pouvez-vous partager plus d'informations?

Answer 2

Hm, vous pourriez potentiellement utiliser couchdb. Le principe de couch est qu'il est finalement cohérent, mais vous disposez d'une copie locale des données avec lesquelles vous devez travailler, et revenez à l'application en un instant, puis mettez à jour le référentiel central aussi vite que possible.

C'est aussi RESTful prêt à l'emploi. La seule chose que vous avez besoin de combler est la connexion postgres - couchdb.

Answer 3

Par exemple, si un utilisateur enregistre certaines modifications, celles-ci doivent apparaître immédiatement.

Ceci est également mise en cache, de sorte que lorsqu'un utilisateur de mettre à jour des données, des caches (qui contient maintenant les anciennes données) arrive à expiration (soit Etag ou supprimer manuellement le cache)