4 ms·
Yep, relevant pieces, thanks for bringing this! Our performance become a little better since then. And also we'll update our fulltext search algorithm using Lu
by michwill 11y ago
Yep, relevant pieces, thanks for bringing this!
Our performance become a little better since then. And also we'll update our fulltext search algorithm using Lucene's practical scoring function: that makes it more scalable and will also help with performance.
As number of clients grows, things actually become better for read queries (as long as we support MVCC). However, multiple writing clients can create congestion if they write data to the same place which can affect the performance indeed.
- saganus 11y agoDo you have a specific use case in mind for this? I ask because apparently there would be a practical limit on the size of the DB. So considering that you would probably need to restrict the DB use to something specific, what would that be? (at least while performance gets better/practical for very big datasets)
- michwill 11y agoI don't think it's so much of a size issue. I'd use it for applications where you don't have too many simultaneous users of the same dataset (in future - that constraint would be only about simultaneous writing users). When users have their own private datasets, that's ok to scale up number of users though. This limitation comes from a) invalidation requests and b) limited ability to do server-side conflict resolution