Need to develop the backend for 2 different company applications

DevOps Google Cloud
#1

Hi everyone,
I am starting to design the back end for a couple of application in my company.
App 1 is a dashboard that for partners to visualize some metrics
App 2 is a insights platform that customer sign up for and they are totally separate and not to meant to be used by the same users.
The second app requires analytics capabilities that are now powered on BigQuery but I was thinking to consolidate all in one DB as the query are not very data intensive.
My questions are:

  1. Do I need to use 2 separate DB instances for App 1 and App 2?
  2. It is ok to keep the user informations data and the analytics data in the same instance for App 2
    My plan is to use AlloyDB to implement the new user DB, it is an overkill but it will allow us to than run the analytics workloads in the same place. Otherwise I will use Cloud SQL but I was thinking to consolidate both DB into the same instance. Thoughts?
    Thanks
#2

It all depends on data and requirements. You can use the same AlloyDB instance for both workload and depending on usage patterns potentially add a read pool for the analytical workload if it is read only. If the case 1 data are fully independent from case 2 then you can place them in separate databases in the same instance. If the analytical workload queries are good fit for the columnar engine it would be even better. When you design permissions and access to the data you might start thinking about using the new parameterized secure views (so far only in Omni). One more thing when you choose your approach is requirements for backups and restores. In general the out of box backups are done on the instance level, so the backup and recovery policy would be applied to both databases.

#3

Yes, the 2 apps are separate so I was going to make 2 DB for sure

#4

the analytics for now are read-only

#5

so I was going to use read only pool

#6

We have an API in front of a DB so I tought to just use one DB user and each API request will have parameters to define the actual data the user can access

#7

Simplifying
Let’s say I have a master table and when an user log into the App will get as user parameters an ID. Than the API will use that idea to get the user data info example what value they cna see for a certain column

#8

and use it to craft the SQL query

#9

but also views might works with the params already there

#10

I think both access models have their merits. The new parametrized views may help to reduce the work but you can just do it in your application logic of course.

#11

Do you have a link to these parametrized views? I cannot find it anywhere

#12

Sure. Here it is https://cloud.google.com/alloydb/docs/ai/use-psvs#parameterized_secure_views

#13

weird, why under AI. Does not seems an AI feature

#14

everyone is AI nowadays

#15

The reason to put it there is because it helps to secure data for nl2sql requests when the application logic is fluid, queries are not hard coded.

#16

Interesting, I will look in it