Je me demandais s'il y a quelqu'un ici qui a de l'expérience avec des données intensives en écriture en raison de l'importation de fichiers.Mise à l'échelle de l'application intensive d'écriture (LAMP, MySQL) (application de style de catalogue)
L'exigence principale est que les utilisateurs métier puissent importer une donnée représentant les relations entre les tables principales. Ils devraient être en mesure d'exporter le même en temps réel (autant que possible).
Setup:
- demande frontal (php) écrit sur une base de données maître.
- Configuration de la réplication - La base de données principale est répliquée sur deux serveurs de base de données SLAVE.
- l'un des serveurs SLAVE est utilisé comme base de données "read" pour les interactions de l'interface utilisateur frontale (requêtes lourdes).
- Le même serveur SLAVE est également utilisé pour les données "EXPORTING" basées sur une requête qui a été prévisualisée sur le frontal. (Beaucoup de tableau JOIN).
Le principal défi a été le journal de réplication. Les utilisateurs ne sont pas satisfaits des données de performance & qui ne sont pas disponibles sur le frontal même si les fichiers qu'ils ont importés ont déjà été traités. La réplication LAG est le coupable.
Passer à NoSQL, c'est-à-dire l'objectif à long terme. Toujours envie d'améliorer la performance pour le moment. En passant, l'application est utilisée en interne mais est hébergée dans une société d'hébergement bien connue. Le nombre d'utilisateurs est d'environ 150 utilisateurs.
Les données importées sont d'environ 200k - 800k lignes. Chaque ligne représente une seule ligne.
Toutes les entrées seraient appréciés :)
Avez-vous étudié pourquoi le décalage se produit, et je me demande quel est le décalage? – Wrikken
Pourquoi le passage à "NoSQL" est-il un objectif à long terme? (La divulgation complète, je questionne le terme "NoSQL" - quel est le problème avec un langage de requête standardisé qui fonctionne avec de nombreuses bases de données?Je peux apprécier les gens qui veulent des bases de données plus souples pour le développement d'applications Web et d'autres utilisations, mais le problème à mon humble avis n'est pas le fait qu'une base de données supporte SQL - c'est la performance, la modélisation et les caractéristiques d'intégrité. Pensez-vous pouvoir modéliser vos données plus efficacement dans une base de données non relationnelle? –
Pour les performances et l'évolutivité, nous avons considéré NoSQL (c'est-à-dire MongoDB) comme notre chemin à long terme. Nos données sont assez simples pour être modélisées dans une base de données sans relation. La quantité de données et les exigences de disponibilité des données n'est pas simple. – rmartinez