02-19-2020, 11:25 AM
Hi,
Ok, so I have a general but important question regarding scalability and how, let's call it LiveCloud's Array architecture is built and how we should design our apps and software with that in mind.
So first question (A) is: Is each account one very big array? Or is each project one array? Or is each table a separate array?
Let's say I'm building mobile apps that will eventually reach a worldwide audience with potentially millions of users in different countries. We have tables with login info (cdbUsers), others with profile information etc. If we have one million users then they would have 1 million rows. Then let's say that each user has it's own table with contacts, and the number of contacts could be in average 100 contacts for each user.
What would be the best approach designing tables in this case.
1. All contacts (100) for every user (1.000.000) is saved in the same table with some 100.000.000 rows
2. For every user a new table is created and thus these tables will only hold 100 contacts / rows in average.
But if everything is one super Big Array anyway, is there any difference between 1 and 2 above? Nr 2 is what I have in mind designing this, but on the other hand that will create potentially 1 million tables, and perhaps that will cause problems? On the other hand we can fetch the tables directly with the help of tableID so that should be faster right?
If there are limitations it would be good to know if we should, for example, have different projects for each country/state, or even different accounts. And of course we would use different Regional LiveCloud Servers for different parts of the world, and that would mean different accounts as it is now, right?
So in any case, some design guidelines would be helpful, and also if you made some really large tests yourselves with a ridiculous amount of data
Kindly
John
Ok, so I have a general but important question regarding scalability and how, let's call it LiveCloud's Array architecture is built and how we should design our apps and software with that in mind.
So first question (A) is: Is each account one very big array? Or is each project one array? Or is each table a separate array?
Let's say I'm building mobile apps that will eventually reach a worldwide audience with potentially millions of users in different countries. We have tables with login info (cdbUsers), others with profile information etc. If we have one million users then they would have 1 million rows. Then let's say that each user has it's own table with contacts, and the number of contacts could be in average 100 contacts for each user.
What would be the best approach designing tables in this case.
1. All contacts (100) for every user (1.000.000) is saved in the same table with some 100.000.000 rows
2. For every user a new table is created and thus these tables will only hold 100 contacts / rows in average.
But if everything is one super Big Array anyway, is there any difference between 1 and 2 above? Nr 2 is what I have in mind designing this, but on the other hand that will create potentially 1 million tables, and perhaps that will cause problems? On the other hand we can fetch the tables directly with the help of tableID so that should be faster right?
If there are limitations it would be good to know if we should, for example, have different projects for each country/state, or even different accounts. And of course we would use different Regional LiveCloud Servers for different parts of the world, and that would mean different accounts as it is now, right?
So in any case, some design guidelines would be helpful, and also if you made some really large tests yourselves with a ridiculous amount of data
Kindly
John
