Subnet capabilities for scaling database services

From the link JaMarco posted above:

“The Internet Computer also ensures the transparency of subnets in other ways. The NNS can split and merge subnets, for example, in order to balance load across the overall network. This is also transparent to the hosted canisters.”

(Accompanied by this image)

@diegop (pinging you b/c I’m not sure who to ask on this one)

Do you know anything about if the functionality mentioned above has actually been implemented?

The reason why I ask, is that for applications that need to auto-scale themselves, it would definitely impact the performance of any inter-canister calls between existing canisters for that specific application. Why not just spin up a new subnet instead of splitting an existing one?

One of the features I’ve been pondering on is the ability to seamlessly scale beyond a subnet, and for a caniste on subnet A to be able to create new canisters on subnet B, and continue creation on subnet B until that fills up and then use subnet C, and so on…

The requirement that the canister which is instantiating the creation of new canisters be located on the same subnet is a bit limiting, and I’m not 100% sure why this was put in place in the first place. We already have the random “round-robin” approach of picking a subnet to create a canister on documented here, so I’m not quite sure why this restriction exists in terms of letting a canister do this directly (both have the ability to pick a random subnet, and to choose the exact subnet).

If DFINITY is concerned about people deploying to “private subnets” like the Bitcoin integration, the dev testing subnet, or to “private” subnets reserved for larger, specific applications, then IC management canister related actions like create_canister on those subnets can be gated by the principal id of the developer or of the canister (i.e. if it is already on that subnet).

I’m making the argument for this feature, because if it exists, then it will become 10 times easier to scale applications past a single subnet, and DFINITY can more easily say/advertise that applications on the IC are infinitely scalable, or at least until they fill up all the node memory on the IC :sweat_smile:.



On a separate note, how much total node/subnet memory capacity currently exists on the entire IC?

It looks like there are 35 subnets in total, of which:

  • 1 subnet is the NNS → 78.21 TB
  • 1 subnet is the SNS → 66.48 TB
  • 2 subnets are “System” subnets, of which one is 25.42TB and the other (System II) is 54.75TB
  • The 31 remaining subnets are all “application” subnets, which are the type of subnet available to all of us devs. All application subnets look to have 25.42TB of memory

25.42TB in an application subnet? But I thought each subnet has a canister memory capacity of 300GB…?

Does anyone have an answer to why this is?

2 Likes