Passer d'une base de données relationnelle au Big Data

Question

Actuellement, j'ai une application hébergée sur Google Cloud Platform qui offre des analyses web et fournit l'activité de la session (clics, téléchargements, etc.) et relie cette activité web aux enregistrements web.

Actuellement, nous stockons toutes nos données de clic et de profil de session dans MySQL et utilisons des requêtes SQL pour générer des rapports globaux et par utilisateur. Cependant, comme la quantité de données a augmenté, nous constatons un réel ralentissement des réponses aux requêtes, ce qui ralentit les temps de chargement des pages.

En cherchant à résoudre ce problème, nous avons étudié les outils disponibles sur Google Cloud Platform comme Dataproc et Dataflow ainsi que les solutions NoSQL, mais j'ai du mal à comprendre comment nous pourrions appliquer notre solution actuelle à l'une ou l'autre de ces solutions.

Actuellement, notre schéma de données est approximativement le suivant :

User table
- id
- name
- email

Profile table (web browser/device)
- id
- user id
- user agent string

Session table
- id
- profile id
- session string

Action table
- id
- session id
- action type
- action details
- timestamp

D'après mes recherches, la meilleure solution consisterait à stocker les données d'action dans une solution de base de données NoSQL telle que BigTable, qui alimente une solution telle que DataProc ou DataFlow, qui génère les rapports. Cependant, étant donné que notre schéma actuel est une structure hautement relationnelle, il semble que l'option d'évoluer vers une solution NoSQL ne soit pas envisageable, car toutes mes recherches indiquent qu'il ne faut pas déplacer des données relationnelles vers une solution NoSQL.

Ma question est la suivante : ma compréhension de la manière d'appliquer ces outils est-elle correcte ? Ou existe-t-il de meilleures solutions ? Est-il même nécessaire d'envisager de s'éloigner de MySQL ? Et si ce n'est pas le cas, quelles sont les solutions disponibles qui nous permettraient éventuellement de prétraiter/générer des données de reporting en arrière-plan ?

Answer 1

En supposant que sessions et actions les valeurs de la table ne sont pas mises à jour et seules des insertions sont effectuées. La meilleure solution consiste à séparer les bases de données en deux parties. Gardez la base de données MySQL pour user et profile et utiliser les tableaux BigQuery para actions et sessions .

De cette manière, vous avez un suivi :

• minimiser la quantité de changements à effectuer de part et d'autre (ingestion et extraction de données)
• vous réduirez considérablement le coût du stockage des données
• les temps d'interrogation seront nettement améliorés
• avant que vous ne le sachiez, vous serez dans le territoire du big data et BigQuery est exactement la solution qu'il vous faut

BigQuery est la meilleure solution. Mais si vous disposez de trop de ressources supplémentaires et de temps, vous pouvez envisager de les stocker dans une base de données NoSQL, puis d'exécuter un travail de pipeline sur cette base à l'aide de DataFlow pour extraire des données analytiques que vous devrez à nouveau stocker dans une base de données à des fins d'interrogation.

Answer 2

Quelques questions / solutions potentielles :

1. Profil ! Si ce sont les mêmes requêtes qui encombrent la base de données, l'optimisation de vos requêtes ou la mise en cache de certains résultats pour vos pages les plus fréquentes peuvent contribuer à décharger le traitement. Il en va de même pour les paramètres de la base de données, la mémoire vive, etc.
2. Quelle est la taille de votre base de données ? Si elle est inférieure à 64 Go, le passage à un serveur plus grand où la base de données peut tenir dans la mémoire vive pourrait être une solution rapide.
3. Comment vos données sont-elles utilisées ? S'il s'agit uniquement de données historiques, vous pouvez éventuellement réduire vos clics à un tableau de consultation, par exemple les actions par session, par semaine ou par utilisateur, par semaine. Si les données sont collectées toutes les 5 minutes ou toutes les heures, il est également possible de télécharger les données brutes et de les traiter localement.
4. Vous pouvez dénormaliser, par exemple en combinant l'agent utilisateur, la session, le type d'action, les détails et l'horodatage en une seule ligne, mais vous risquez d'augmenter vos besoins en stockage et le temps de recherche.
5. Par ailleurs, une normalisation plus poussée peut également s'avérer utile. La séparation de la chaîne de l'agent utilisateur dans son propre tableau réduira les besoins en données de ce tableau et pourrait accélérer les choses.
6. Il semble que vos données puissent être divisées par utilisateur, ce qui pourrait être une autre option.

En général, le moyen le plus rapide de répondre à ces questions est de faire un essai avec vos charges de travail spécifiques, par exemple, combien de requêtes typiques (ou de tableaux de bord aléatoires) pouvez-vous effectuer sur une machine de développement avec une quantité raisonnable de mémoire vive (ou faites tourner un serveur/créez une base de données de test différente).

Par ailleurs, si vous êtes principalement habitué aux bases de données relationnelles, le passage à une autre solution entraînera des frais généraux (en particulier pour les solutions de pointe). Vous devez donc être certain que les coûts l'emportent sur les avantages avant de passer à une autre solution, ou passer à une autre solution un petit peu à la fois afin de pouvoir revenir en arrière si cela ne fonctionne pas. Là encore, les tests sont utiles.

Answer 3

Dans la mesure du possible, ne stockez pas du tout la quantité massive de données !

Au lieu de cela, il faut résumer (agréger) les données au fur et à mesure qu'elles arrivent, puis stocker les résumés.

Avantages :

• Peut-être un dixième de l'espace disque nécessaire ;
• Les rapports sont peut-être dix fois plus rapides,
• Peut être réalisé dans le SGBDR existant.

Inconvénients :

• Il n'est pas possible d'adapter une synthèse différente. (D'accord, vous pouvez conserver les données brutes et recommencer ; cela peut être mieux de toute façon).
• Plus de complexité dans le code.

Discussion des tableaux de synthèse.