[
https://issues.apache.org/jira/browse/CASSANDRA-18248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686906#comment-17686906
]
Berenguer Blasi commented on CASSANDRA-18248:
---------------------------------------------
Thanks for engaging the discussion!
Happy to amend the title. My concern here is exactly what Josh mentions with
'not considered hot path enough'. Which is also what Andres points to with the
avoidance of streams when dealing with columns or rows. I think that reasoning
makes perfect sense if you think of the classic and correct prepare once and
execute many times for a query.
The question that bothers me is whether in multitenancy hosted envs things
might be different. A node may be serving many different unrelated applications
at the same time. This, personal opinion/experience, will probably result in a
broader set of unrelated queries being prepared rather than when a single app
revolves around a set of a more or less fixed corpus of queries. Yes we can
argue back & forth there's no warranty on that and a 1 query per 10 apps vs an
app with 10 queries counter example etc
My second worry point comes from experience dealing with customer tickets. It
is one thing to control the app querying the nodes. It is a different thing
hosting a node being hit by apps you have no control over. I have seen more
than once misuses where _every_ query was being prepared, nightly batch
processes that result in a prepare storm blowing up the prepare cache, etc. Yes
that is contrary to the intended purpose, the docs, best practices, etc but it
happens.
So my questions is: Given the above multitenenacy worries do we want to draw a
conclusion it would be best stop using streams when adding new code like we do
for cols/rows? I would say yes bc it is a free lunch.
> Consider avoiding streams on query building
> -------------------------------------------
>
> Key: CASSANDRA-18248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18248
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Berenguer Blasi
> Priority: Normal
> Labels: low-hanging-fruit
>
> During the review of CASSANDRA-18068 it was discussed whether preparing
> queries might be considered a hot path or not. Seen in isolation it isn't.
> But given multi-tenancy setups i.e. and coming from the experience of seeing
> how prepare is used by some customers as per some bug reports this might not
> be 100% true
> Let's discuss here if removing streams would make any sense. Most rewrites I
> expect wouldn't impact readability. [~adelapena] took a first stab and
> compiled a first list of candidates:
> *
> [o.a.c.cql3/CQL3Type.java#L840|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/CQL3Type.java#L840]
> *
> [o.a.c.cql3/CQL3Type.java#L876|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/CQL3Type.java#L876]
> *
> [o.a.c.cql3/Lists.java#L133|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/Lists.java#L133]
> *
> [o.a.c.cql3/Sets.java#L123|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/Sets.java#L123]
> *
> [o.a.c.cql3/MultiColumnRelation.java#L225|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/MultiColumnRelation.java#L225]
> *
> [o.a.c.cql3/QueryProcessor.java#L481|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L481]
> *
> [o.a.c.cql3/TokenRelation.java#L138|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/TokenRelation.java#L138]
> *
> [o.a.c.cql3/conditions/ColumnConditions.java#L75|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/conditions/ColumnConditions.java#L75]
> *
> [o.a.c.cql3/functions/AbstractFunction.java#L69|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/functions/AbstractFunction.java#L69]
> *
> [o.a.c.cql3/functions/FunctionResolver.java#L203|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/functions/FunctionResolver.java#L203]
> *
> [o.a.c.cql3/functions/UDAggregate.java#L97|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/functions/UDAggregate.java#L97]
> *
> [o.a.c.cql3/restrictions/StatementRestrictions.java#L380|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java#L380]
> *
> [o.a.c.cql3/selection/AbstractFunctionSelector.java#L72|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/selection/AbstractFunctionSelector.java#L72]
> *
> [o.a.c.cql3/selection/MapSelector.java#L113|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/selection/MapSelector.java#L113]
> *
> [o.a.c.cql3/selection/Selectable.java#L708|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/selection/Selectable.java#L708]
> *
> [o.a.c.cql3/selection/Selectable.java#L793|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/selection/Selectable.java#L793]
> *
> [o.a.c.cql3/selection/Selectable.java#L886|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/selection/Selectable.java#L886]
> *
> [o.a.c.cql3/selection/Selectable.java#L954|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/selection/Selectable.java#L954]
> *
> [o.a.c.cql3/selection/Selectable.java#L1024|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/selection/Selectable.java#L1024]
> *
> [o.a.c.cql3/statements/SelectStatement.java#L1278|https://github.com/apache/cassandra/blob/cassandra-4.1.0/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java#L1278]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
