Good day!
Could you please advise me, I am considering the option of migrating my current architecture based on MongoDB + REST to Dgraph. The current scheme works as follows: I have 6 geo regions, for each region there is a separate database (the DB cluster is located in one place in Europe) and one API instance is launched in corresponding locations. Each API instance is paired with Redis to store cache requests and if the key is not available, the API contacts the DB cluster, gets the response, and then stores it in the cache.
After analyzing the documentation, and particularly the recommendations for setting up cluster Cluster Types - Deploy, I understood that multi-tenancy connection is only available in the enterprise version, and there is no feature for having multiple databases within a cluster. Also, on the forum, I noticed a suggestion to make a tree-like structure of my database and split the nodes at the tree level (kind of like shards). To be honest, I’m at a loss as to how to properly organize data storage. Could anyone possibly have come across a similar situation and found a solution?
Multi-tenancy can be thought of as a security feature where different data is stored together but the system guarantees that no one login can access data from two different “tenants” (aka namespaces).
This is available on Dgraph Cloud for a monthly fee or as an enterprise feature if you run your own servers.
If you do not want to use Dgraph Cloud or the paid enterprise version there are a couple options. One is to enforce security in code - only allow each API to query for the data it is allowed to see. In that approach, the ES or US API will need to add query parameters that ensure only ES or US data is queried.
Another is to make many, smaller databases that are physically separate but share code and configuration. K8s helps with that approach as you can use one large machine but run many, smaller pods. Multi-tenancy is then enforced at the container level instead of within the DB.
Finally, you could create an maintain a different schema per region, and have each API use only that schema. This is still security in the API layer, but with naming conventions to avoid mistakes. E.g. a Person entity with a name might be es_Person with es_name for ES data and us_Person with us_name for US data.
The preferred approach is to use the cloud offering with ACLs (needed for tenants) which handles this more simply and cleanly, however, and avoids extra operations burden.
