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
Currently, Data Index is deployed as a vanilla Kubernetes Deployments. This approach leads administrators and users to assume that it's safe to scale the .spec.dataIndex.podTemplate.replicas to a number greater than 1.
This is not necessarily true in all cases. The data index is not designed for multiple writers unless the new "Eventing Grouping" feature is enabled. In this situation, it might work.
So, the documentation must reflect the following:
The data index should be deployed with sharding in mind. For example, a namespace for Finance workflows should have a Data Index specifically for that data cluster.
The cluster-wide deployment can be used and only scale vertically (Hardware Resources); since that can be a single point of failure, the database layer must be robust and designed for the expected load for the whole workflows in the cluster.
We need more information to document the horizontal scale with grouping events. So, in the near future, when @gmunozfe and @fjtirado come up with the solution and the benchmark, we can document and recommend this architectural deployment approach.
The text was updated successfully, but these errors were encountered:
Currently, Data Index is deployed as a vanilla Kubernetes Deployments. This approach leads administrators and users to assume that it's safe to scale the
.spec.dataIndex.podTemplate.replicas
to a number greater than 1.This is not necessarily true in all cases. The data index is not designed for multiple writers unless the new "Eventing Grouping" feature is enabled. In this situation, it might work.
So, the documentation must reflect the following:
We need more information to document the horizontal scale with grouping events. So, in the near future, when @gmunozfe and @fjtirado come up with the solution and the benchmark, we can document and recommend this architectural deployment approach.
The text was updated successfully, but these errors were encountered: