[
https://issues.apache.org/jira/browse/CASSANDRA-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333591#comment-14333591
]
Sylvain Lebresne commented on CASSANDRA-8831:
---------------------------------------------
bq. For 2.1 the USE keyspace might not have any effect. But for 3.0 (UDFs) it
has.
If by "has effect" your mean "for the preparation of the statement given a
query string", then I don't disagree but that's *not* what I'm saying. I'm
saying that _once prepared_, there is only one keyspace that matters, the
statement keyspace, and that's the one I'm talking about. To put it another
way, either the statement has a fully-qualified keyspace, and the {{USE}} one
has no effect, or it doesn't have such FQ keyspace and then only the {{USE}}
one matter. In both case, there is only one keyspace that matter and that's
what I'm suggesting using. But anyway, we might want to change that schema
anyway, see below.
bq. But "table_name" could become a more generic "table_names set<text>", to
properly handle batches.
That's a good point, and in fact, that's true of {{keyspace_name}} too. Which
kind of suck but well, the whole point of having the keyspace and table was to
be able to query for only the prepared statement of a given table, but since
batches screw that, I suggest we keep it simpler and just have:
{noformat}
CREATE TABLE system.prepared_statements (
prepared_id blob PRIMARY KEY,
query_string text,
logged_keyspace text // that one _is_ the "USE keyspace"
)
{noformat}
It's enough information to re-prepare the statement and avoid having to bother
with batches.
bq. so long as we don't whitelist the table as accessible to everyone by default
Except that so far the assumption of this ticket is that drivers would check
that table and so it would have to white-listed. Though I guess we could forget
about drivers being able to check it: if they can assume a restarted node will
have kept it's statement, then they can unconditionally skip re-preparing
statements in that case. They'd still have to do it on newly joined nodes, but
that's a rarer event (so still an improvement) and maybe later we can implement
Robert's idea of having newly joined node query another node to get the
prepared statement (mildly fan of the idea on principle, it feels hacky to me,
but why not) so drivers can skip that case too.
bq. I'd rather this went into 3.0
To be clear, I only mentioned 2.1 to say that this felt simple enough that 2.1
could be considered as not out of question, but I tend to prefer 3.0 for this
too.
> Create a system table to expose prepared statements
> ---------------------------------------------------
>
> Key: CASSANDRA-8831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8831
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Robert Stupp
> Attachments: 8831-v1.txt, 8831-v2.txt
>
>
> Because drivers abstract from users the handling of up/down nodes, they have
> to deal with the fact that when a node is restarted (or join), it won't know
> any prepared statement. Drivers could somewhat ignore that problem and wait
> for a query to return an error (that the statement is unknown by the node) to
> re-prepare the query on that node, but it's relatively inefficient because
> every time a node comes back up, you'll get bad latency spikes due to some
> queries first failing, then being re-prepared and then only being executed.
> So instead, drivers (at least the java driver but I believe others do as
> well) pro-actively re-prepare statements when a node comes up. It solves the
> latency problem, but currently every driver instance blindly re-prepare all
> statements, meaning that in a large cluster with many clients there is a lot
> of duplication of work (it would be enough for a single client to prepare the
> statements) and a bigger than necessary load on the node that started.
> An idea to solve this it to have a (cheap) way for clients to check if some
> statements are prepared on the node. There is different options to provide
> that but what I'd suggest is to add a system table to expose the (cached)
> prepared statements because:
> # it's reasonably straightforward to implement: we just add a line to the
> table when a statement is prepared and remove it when it's evicted (we
> already have eviction listeners). We'd also truncate the table on startup but
> that's easy enough). We can even switch it to a "virtual table" if/when
> CASSANDRA-7622 lands but it's trivial to do with a normal table in the
> meantime.
> # it doesn't require a change to the protocol or something like that. It
> could even be done in 2.1 if we wish to.
> # exposing prepared statements feels like a genuinely useful information to
> have (outside of the problem exposed here that is), if only for
> debugging/educational purposes.
> The exposed table could look something like:
> {noformat}
> CREATE TABLE system.prepared_statements (
> keyspace_name text,
> table_name text,
> prepared_id blob,
> query_string text,
> PRIMARY KEY (keyspace_name, table_name, prepared_id)
> )
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
