multi-tenancy indexing #36
-
|
Hello, |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
This is mentioned in the docs https://lnx.rs/#tag/Managing-indexes which gives a bit more info on this, but yes this will open 10,000 * (calculated number of threads) which is generally something I wouldn't advise doing. I do plan on working on some sort of shared / dynamic size executor but for the most part, It's just really not recommended to make lots of small indexes as it is unbelievably inefficient to do so in lnx, you're better of making one index and merging all the data together as best you can, at least in lnx's case. If you need a lot of very small indexes something like sonic might be better suited as it's a lot more optimised for small resources footprint vs performance on large indexes. Hopefully, this clears up any questions you might have. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, this clears things out for me, I'm building an indexing server that should support multi-tenancy and checked out the architecture to learn so this is why I've asked about this matter. |
Beta Was this translation helpful? Give feedback.
This is mentioned in the docs https://lnx.rs/#tag/Managing-indexes which gives a bit more info on this, but yes this will open 10,000 * (calculated number of threads) which is generally something I wouldn't advise doing.
I do plan on working on some sort of shared / dynamic size executor but for the most part, It's just really not recommended to make lots of small indexes as it is unbelievably inefficient to do so in lnx, you're better of making one index and merging all the data together as best you can, at least in lnx's case.
If you need a lot of very small indexes something like sonic might be better suited as it's a lot more optimised for small resources footprint vs performance on l…