Performances Redshift: requêtes SQL et normalisation de table

Question

Je travaille à la création d'une base de données redshift en écoutant des événements provenant de différentes sources et en pompant ces données dans un cluster redshift.

L'idée est d'utiliser Kinesis firehose pour pomper des données vers redshift en utilisant la commande COPY. Mais j'ai un dilemme: Je voudrais d'abord interroger des informations à partir redshift à l'aide d'une requête de sélection tel que celui ci-dessous:

select A, B, C from redshift__table where D='x' and E = 'y'; 

Après avoir obtenu les informations nécessaires à partir redshift, je vais combiner cette information avec ma notification d'événements données et émettre une requête à kinésis. Kinesis fera alors son travail et lancera la commande COPY requise. Maintenant, ma question est que c'est une bonne idée d'interroger à plusieurs reprises redshift comme dire chaque seconde puisque c'est l'heure prévue après laquelle je vais recevoir des notifications d'événements?

Maintenant, permettez-moi de décrire un scénario alternatif:

Si je normalise ma table et séparer certains champs dans une table séparée puis, je vais devoir effectuer moins de requêtes redshift avec la conception normalisée (peut être une fois tous les 30 secondes)

Mais l'inconvénient de cette approche est qu'une fois que j'ai les données dans redshift, je vais devoir effectuer des jointures de table tout en effectuant des analyses en temps réel sur mes données redshift.

Je souhaite donc savoir à un niveau élevé qui approche serait mieux:

1. ont une table à plat unique, mais requête avant l'émission d'une demande de Kinesis sur une notification d'événement. Il n'y aura pas de jointures de table lors de l'analyse.

2. Avoir 2 tables et requête redshift moins souvent. Mais effectuez une jointure de table tout en affichant les résultats à l'aide d'outils BI/analytiques.

Lequel de ces 2 pensez-vous est une meilleure option? Supposons que j'utiliserai les clés de tri/clés de distribution appropriées dans les deux cas.

Answer 1

Je choisirais certainement votre deuxième option, qui implique JOINING avec des requêtes. C'est ce qu'Amazon Redshift est capable de faire (surtout si vous avez correctement défini vos SORTKEY et DISTKEY). Laissez les données de streaming entrer dans Redshift de la manière la plus efficace possible, puis joignez-vous lorsque vous faites des requêtes. Vous aurez beaucoup moins de requêtes de cette façon. Vous pouvez également exécuter un travail régulier (par exemple, toutes les heures) pour traiter les données par lots dans une table étendue. Cela dépend de la rapidité avec laquelle vous devrez interroger les données après le chargement.