> There is no reason it should ever be more capable than SAI for any > partition/token-restricted query use-case, and I don't really see how there's > any short-term path for any local 2i implementation in C* to be efficient for > anything else
While I am not personally aware of much evidence presented that SAI performs better than 2i for the partition-restricted case, I do believe it is theoretically likely to. But any deprecation discussion should include evidence of this as a preamble. However, there are users that want queries not restricted by partition or token, and SAI is unlikely to serve these use cases as well. Yes, neither perform this use case well, but I cannot support deprecating a feature when its replacement is very likely inferior for some workloads. Since it is hard to prove that nobody is using 2i this way (and I recall from the distant past that such users were known to exist), we need instead to prove SAI can serve these workloads acceptably before we declare it a suitable replacement. I think there exists a near future world where we can offer proper global secondary indexes, at which point it would be acceptable to deprecate 2i and recommend users switch to either global secondary indexes or SAI. Until then, I cannot see a good argument for it if we want to be considered a stable and mature product. > On 10 Dec 2024, at 09:28, Caleb Rackliffe <calebrackli...@gmail.com> wrote: > > > I’m not convinced SAI has demonstrated a practical or theoretical > > capability to fully replace secondary indexes anyway. So it would be very > > premature to mark them deprecated. > > > If 2i indexes are to be marked as deprecated and SAI is beta, then what is > > actually the index implementation we stand behind in the production? It is > > like we are "abandoning" the former but the latter is not bullet-proof yet. > > The table-based 2i implementation has never been safe to use, and I don't > think it ever will be, however we label it. (ex. CASSANDRA-18656, it's > on-disk bloat, post-streaming rebuilds, etc.) There is no reason it should > ever be more capable than SAI for any partition/token-restricted query > use-case, and I don't really see how there's any short-term path for any > local 2i implementation in C* to be efficient for anything else. There are > presently no feature gaps on the query side. > > Anyway, there are still a lot of things we can improve about SAI (and things > that already exist and are just waiting in the DS public fork)...I'm just not > sure what reasonable use case the old 2i will be able to serve better. > > On Tue, Dec 10, 2024 at 5:41 AM Benedict <bened...@apache.org > <mailto:bened...@apache.org>> wrote: >> I’m not convinced SAI has demonstrated a practical or theoretical capability >> to fully replace secondary indexes anyway. So it would be very premature to >> mark them deprecated. >> >>> On 10 Dec 2024, at 06:29, Štefan Miklošovič <smikloso...@apache.org >>> <mailto:smikloso...@apache.org>> wrote: >>> >>> >>> ... then we should NOT mark it to be deprecated. >>> >>> On Tue, Dec 10, 2024 at 12:27 PM Štefan Miklošovič <smikloso...@apache.org >>> <mailto:smikloso...@apache.org>> wrote: >>>> I have a hard time getting used to the "terminology" here. If 2i indexes >>>> are to be marked as deprecated and SAI is beta, then what is actually the >>>> index implementation we stand behind in the production? It is like we are >>>> "abandoning" the former but the latter is not bullet-proof yet. The signal >>>> it sends is that we don't have a non-deprecated bullet-proof index impl. >>>> >>>> Maybe it is just about the wording and people are just fine running >>>> deprecated things knowing they are production-ready, what I am used to is >>>> that if something is deprecated, then there is always a replacement which >>>> is recommended. If there isn't a recommended replacement which can fully >>>> superseed the current implementation then we should mark it to be >>>> deprecated. >>>> >>>> I understand that you are trying to find some "common ground" / expressing >>>> that we are moving towards SAI but I am not sure the wording is entirely >>>> correct or we should be careful how we frame it. >>>> >>>> On Tue, Dec 10, 2024 at 12:01 PM Mick Semb Wever <m...@apache.org >>>> <mailto:m...@apache.org>> wrote: >>>>> > A possibility with SAI is to mark it beta while also marking 2i as >>>>> > deprecated (and leaving SASI as marked). This sends a clear signal >>>>> > (imho) that SAI is the recommended solution forward but also being >>>>> > honest about its maturity and QA. >>>>> >>>>> >>>>> (and leaving SASI as marked *experimental*)
