You should create your own datastore for this kind of behaviour but I think will not solve in deep the problem if you really have it.
Consider 1000 concurrent users with write grants do not it means you have at the same time 1000 documents being written at the same time. Here the question is not the number of concurrent users, here the question is the number of concurrent writing actions, and if you want to test this environment you need only a concurrent robot what execute writing calls to the OpenKM API.
In the end, you will have a number that will indicate how many documents can be written during a minute or during a second if you have a good performance. You are only considering the datastore ... but I will be more worried about database than datastore. Are several ways to optimize OpenKM as a data store, for example, remove security and operate always with a single superuser, set Lucene search engine async, etc...
Because information matters
Openkm many uset
- We tried to make OpenKM as intuitive as possible, but an advice is always welcome.
Forum rules: Please, before asking something see the documentation wiki or use the search feature of the forum. And remember we don't have a crystal ball or mental readers, so if you post about an issue tell us which OpenKM are you using and also the browser and operating system version. For more info read How to Report Bugs Effectively.
You should focus on the problem you are trying to solve. In the beginning, you start the discussion talking about you have 1000 users what are writers and it seems you want to split data into several datastore servers because the system will not be able to load that amount of data.
You should start with some numbers, you have a number of users, that is fine, but more important is the number of document, what is the daily increment, the expected during a year, the document must life until the end of the days of periodically might be expurged ( after 1-2-5 years ... some logic for it ). If you have some estimation in terms of the number of files, daily or monthly creation etc... might suggest you some configuration.
Sometimes is useful thinking in daily and yearly documents rather than archived ones and working with two servers, one with less documents what are frequently used by users and another server for the history, what they use less.
Also evaluate it is more easy maintaining one server than 3, and in the same hand control the backup process, everything must be put on the table to evaluate the options.
One of the advantages you have with OpenKM is the export process, you will not be a prisoner of the application if you discover it does not fit as you expected can move to another application. Finally does not expect in community edition the same behaviour you have in the professional edition, where a lot of the efforts have been focused in optimize the application for huge repositories, that does not means community cannot hold them, simply professional edition has improvements what still are not released in the community.
You should start with some numbers, you have a number of users, that is fine, but more important is the number of document, what is the daily increment, the expected during a year, the document must life until the end of the days of periodically might be expurged ( after 1-2-5 years ... some logic for it ). If you have some estimation in terms of the number of files, daily or monthly creation etc... might suggest you some configuration.
Sometimes is useful thinking in daily and yearly documents rather than archived ones and working with two servers, one with less documents what are frequently used by users and another server for the history, what they use less.
Also evaluate it is more easy maintaining one server than 3, and in the same hand control the backup process, everything must be put on the table to evaluate the options.
One of the advantages you have with OpenKM is the export process, you will not be a prisoner of the application if you discover it does not fit as you expected can move to another application. Finally does not expect in community edition the same behaviour you have in the professional edition, where a lot of the efforts have been focused in optimize the application for huge repositories, that does not means community cannot hold them, simply professional edition has improvements what still are not released in the community.