Replies: 1 comment
-
Current Decision: To get reasonable performance we can't have data calls taking 100 msec, so we go with centralized storage, but make it easy to have mirrors of the database. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
In both cases, (federated and centralized) storage, we can achieve some desirable properties for storage such as:
Also, modern orchestration (of containers) tools enable the use of many different nodes, that appear as a single entry point, with the advantage of having on-demand creation of new nodes to provide a service
ILCDN (from PEF) as well as GLAD are examples of "federated" nodes providing data (not models).
Does it make any difference to store "models" and to store data? Are there any specific properties from these two types of assets that would make having a different (federated or centralized) storage type ?
Choosing a paradigm (federated or centralized) right now, can slow-down future developments. Is it safer to go with centralized for the moment and move to federated later on, or the other way around?
Beta Was this translation helpful? Give feedback.
All reactions