You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The building blocks for distributed caching, and an mnesia-based implementation
which is more like a finished house frame than a building block, are all there.
It is time for the next step. We need to distribute our sharding. As a start, we
should introduce a way to start and stop shards dynamically. I imagine an
approach such as one process per shard seems the most sane and manageable, so we
will want a function that allows to bring up a shard and a function that brings
down a shard, and we need a way to see all shards across all nodes in the
system. Potentially, we can use Erlang's :global or :pg for this.
Once we have functions to bring up and down shards, we need to figure out
whether we can (or should?) automatically redistribute shards as nodes go up and
down inside the cluster. If we decide on implementing this, we should utilize
the seq parameter to allow us to resume without losing events. We will need to
track this somewhere.
I presume this issue serves best as a "planning" stage ticket, and we should
create separate tickets for each individual supposed function. Perhaps we could
use a milestone to track all issues related to it.
The text was updated successfully, but these errors were encountered:
The building blocks for distributed caching, and an mnesia-based implementation
which is more like a finished house frame than a building block, are all there.
It is time for the next step. We need to distribute our sharding. As a start, we
should introduce a way to start and stop shards dynamically. I imagine an
approach such as one process per shard seems the most sane and manageable, so we
will want a function that allows to bring up a shard and a function that brings
down a shard, and we need a way to see all shards across all nodes in the
system. Potentially, we can use Erlang's
:global
or:pg
for this.Once we have functions to bring up and down shards, we need to figure out
whether we can (or should?) automatically redistribute shards as nodes go up and
down inside the cluster. If we decide on implementing this, we should utilize
the
seq
parameter to allow us to resume without losing events. We will need totrack this somewhere.
I presume this issue serves best as a "planning" stage ticket, and we should
create separate tickets for each individual supposed function. Perhaps we could
use a milestone to track all issues related to it.
The text was updated successfully, but these errors were encountered: