TL: DR Je voudrais combiner la puissance de BigQuery avec mon application MERN-stack. Vaut-il mieux (a) utiliser nodejs-biquery pour écrire une API Node / Express directement avec BigQuery, ou (b) créer une tâche quotidienne qui écrit ma (entière) base de données BigQuery sur MongoDB, puis utiliser mangouste pour écrire une API Node / Express avec MongoDB?

Je dois déterminer la meilleure approche pour combiner un flux de travail ETL de données qui crée une base de données BigQuery, avec une application Web react / node. L'ETL de données utilise Airflow pour créer un flux de travail qui (a) sauvegarde les données quotidiennes dans GCS, (b) écrit ces données dans la base de données BigQuery et (c) exécute un tas de SQL pour créer des tables supplémentaires dans BigQuery. Il me semble que mes deux seules options sont les suivantes:

  1. Effectuez une écriture / conversion / transfert / migration quotidienne (quel que soit le verbe correct) de la base de données BigQuery vers MongoDB. J'ai déjà une API node / express écrite en utilisant mongoose, connectée à un cluster MongoDB, et cette approche me permettrait de conserver cette API.
  2. Utilisez la bibliothèque nodejs-biquery pour créer une API de nœud directement connectée à BigQuery. Mon application changerait de la pile ERN de la pile MERN (BQ). Je devrais réécrire l'API node / express pour travailler avec BigQuery, mais je n'aurais plus besoin de MongoDB (ni de transfert quotidien de données de BigQuery vers Mongo). Cependant, BigQuery peut être une base de données très lente si je recherche une seule entrée, car elle n'est pas destinée à être utilisée comme Mongo ou une base de données SQL (elle n'a pas d'index, la requête de récupération d'une ligne est lente lors de l'analyse complète de la table). La plupart de mes appels d'API concernent très peu de données de la base de données.

Je ne sais pas quelle approche est la meilleure. Je ne sais pas si avoir 2 bases de données pour 1 application Web est une mauvaise pratique. Je ne sais pas s'il est possible de faire (1) les transferts quotidiens d'une base de données à l'autre, et je ne sais pas à quel point BigQuery sera lent si je l'utilise directement avec mon API. Je pense que s'il est facile d'ajouter (1) à mon flux de travail d'ingénierie de données, c'est préférable, mais encore une fois, je ne suis pas sûr.

3
Canovice 20 avril 2020 à 22:02

2 réponses

Meilleure réponse

Je vais avec (1). Écrire un script Python qui interroge les tables de BigQuery, transforme et écrit des collections dans Mongo ne devrait pas être trop compliqué. Il y a certaines choses à gérer (changements incrémentiels, etc.), mais c'est beaucoup plus facile à gérer que d'écrire une toute nouvelle API node / bigquery.

4
halfer 26 avril 2020 à 13:14

FWIW dans une vie antérieure, j'ai travaillé sur un site de commerce électronique Web qui avait 4 back-ends DB différents. (Mongo, MySql, Redis, ElasticSearch) donc plus de 1 n'est pas du tout un problème, mais vous devez en considérer un comme la base de données d'enregistrement, c'est-à-dire si quelque chose ne correspond pas entre eux, l'un est la source de la vérité, l'autre est suspect. Pour mon exemple, Redis et ElasticSearch étaient presque éphémères - Soufflez-les et ils sont recréés à partir des sources mysql et mongo sous-jacentes. Maintenant mySql et Mongo en même temps était un peu étrange et que nous étions en train de migrer lentement. Cela signifie que divers types d'enregistrements étaient en cours de transition de MySql vers Mongo. Ce processus ressemblait un peu à: - La couche ORM écrit à la fois sur mysql et mongo, les lectures proviennent toujours de MySql. - les données sont régulièrement comparées. - quelques mois se sont écoulés sans irrégularités et les écritures sur MySql sont désactivées et les lectures sont déplacées vers Mongo.

Le but final n'était plus MySql, tout était Mongo. J'ai descendu cette tangente parce qu'il semble que vous pourriez faire la même chose - écrire dans les deux DB dans la couche d'abstraction DB que vous avez utilisée (ORM, DAO, autres choses avec lesquelles je ne me tiens pas à jour, etc.) et finalement déplacer les lectures comme approprié à l'endroit où ils doivent aller. Si vous avez besoin de gros lots pour les écritures, vous pouvez mettre en mémoire tampon sur cette couche d'abstraction jusqu'à ce qu'un seuil de votre choix soit atteint avant de l'envoyer.

Cela dit, en fonction de la complexité de vos données, un travail ETL nocturne serait également tout à fait faisable, mais vous vous heurtez à la complexité supplémentaire de la gestion et de la surveillance de ce processus supplémentaire. Un autre inconvénient potentiel est que les données sont toujours périmées d'un jour.

1
Jared Chmielecki 29 avril 2020 à 20:25