[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448021#comment-16448021
]
Benjamin Lerer commented on CASSANDRA-7622:
-------------------------------------------
I have always been frustrated by that JIRA ticket and that frustration has only
grown with time. The root of my frustration is in fact the {{Virtual Table}}
name.
What every administrator would like to have when it start using C* is a way to
access the system information through CQL (ask [~pmcfadin] about it ;)). Every
major relational database provide that functionality. Oracle has [Dynamic
Performance
Views|https://docs.oracle.com/cd/B19306_01/server.102/b14237/dynviews_1.htm],
MSSQL has [System Views/Dynamic Management
Views|https://technet.microsoft.com/en-us/library/ms177862(v=sql.110).aspx] and
PostgreSQL has [System
Views|https://www.postgresql.org/docs/9.5/static/views-overview.html].
{{Virtual Table}} is a form of pluggable storage as used by
[SQLite|https://www.sqlite.org/vtab.html].
The idea of this ticket was lets add some form of pluggable storage and use it
to expose system information. At first glance, it looks like killing two bird
with one stone but after some time thinking about it, I tend to believe that we
could simply end up with 2 broken features.
Adding support for pluggable storages is a complex challenge that requires a
large number of changes all around the code base as outlined in the
{{Rocksandra}} discussion. On the other hand, as system information
(configuration, metrics, ring state ...) are locals, exposing them to the user
require much less changes to the code base but more reflection towards user
usability.
It should be easy for administrator to navigate through system information
tables/views but the {{Virtual Table}} syntax does not play well with it. If an
administrator wants an idea of what columns are returned by the
{{compaction_stats}} table and use {{DESCRIBE}} for it, what it will get will
be {{CREATE TABLE USING CompactionStats compaction_stats}}.
The tables should also be meaningful and easy to use. As we work a lot with the
different metrics (counters, gauges, timers, histograms...) we tend to assume
that it is also the case of the users but it is not so we should not rely on
the user knowing it.
As there is already some effort going on for a proper pluggable storage
solution, I came to the conclusion that we should drop that idea of {{Virtual
Table}} and simply expose the system information through what we could call
{{System Views}}. It will make the transition easier for people coming from the
relational word and will help us to focus on what is really important for users
which is the usability of the all thing.
[~adelapena] and I have been working on a patch on our side to expose most of
the system information through system views. We have done our best to make the
exposed views as useful as possible. Taking into account the fact that metrics
have been added without any constraint, making them fit to table was not always
easy :(.
I do not want to hijacke that ticket but if our approach make sense and people
are interested. I am willing to port our patch to C*.
> Implement virtual tables
> ------------------------
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
> Reporter: Tupshin Harper
> Assignee: Chris Lohfink
> Priority: Major
> Fix For: 4.x
>
>
> There are a variety of reasons to want virtual tables, which would be any
> table that would be backed by an API, rather than data explicitly managed and
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml
> configuration information. So it would be an alternate approach to
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not
> presupposing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
