Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Aleksey Yeshchenko]

Dig deeper :)

It’s existed since day one in both CQL2 and CQL3. 
https://github.com/apache/cassandra/blob/cassandra-1.0/src/java/org/apache/cassandra/cql/Cql.g#L526-L527

> On 10 Apr 2023, at 00:35, Patrick McFadin  wrote:
> 
> I was trying to remember when SCHEMA got added to the CQL parser. With a 
> quick 'git blame' I was taken back to this beast: 
> https://issues.apache.org/jira/browse/CASSANDRA-14825

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Jon Haddad]

Good suggestion Mike.  I'm +1 on the idea and agree the name KEYSPACE is 
confusing to new users.

Jon

On 2023/04/04 15:48:26 Mike Adamson wrote:
> Hi,
> 
> I'd like to propose that we add DATABASE to the CQL grammar as an
> alternative to KEYSPACE.
> 
> Background: While TABLE was introduced as an alternative for COLUMNFAMILY
> in the grammar we have kept KEYSPACE for the container name for a group of
> tables. Nearly all traditional SQL databases use DATABASE as the container
> name for a group of tables so it would make sense for Cassandra to adopt
> this naming as well.
> 
> KEYSPACE would be kept in the grammar but we would update some logging and
> documentation to encourage use of the new name.
> 
> Mike Adamson
> 
> -- 
> [image: DataStax Logo Square]  *Mike Adamson*
> Engineering
> 
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online: [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS Feed]
>    [image: Github Logo]
> 
> 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Patrick McFadin]

I love the debate that surfaces occasionally, but I have to agree that
KEYSPACE and SCHEMA are doing the job. There is a learning curve with
Cassandra data modeling, and keywords are a minor problem.

Issues that hit every user:
1. Creating the correct primary key
2. Avoiding the urge to index all-the-things(see item 1)
3. Migrating schema because of 1 and 2

4th bonus issue. Grokking consistency level. "EACH_QUORUM sounds perfect
for me."

I was trying to remember when SCHEMA got added to the CQL parser. With a
quick 'git blame' I was taken back to this beast:
https://issues.apache.org/jira/browse/CASSANDRA-14825

One huge area that was never addressed in the Jira: any documentation that
the official CQL parser now supported SCHEMA. So if anything, we should use
this opportunity to update some docs.

Patrick


On Thu, Apr 6, 2023 at 5:28 PM Dinesh Joshi  wrote:

> I’m strongly in favor of leaving terminology as-is.
>
> On Apr 6, 2023, at 7:20 AM, Bowen Song via dev 
> wrote:
>
> 
>
> *> I'm quite happy to leave things as they are if that is the consensus.*
>
> +1 to the above
>
>
> On 06/04/2023 14:54, Mike Adamson wrote:
>
> My apologies. I started this discussion off the back of a usability
> discussion around new user accessibility to Cassandra and the premise that
> there is an initial steep learning curve for new users. Including new users
> who have worked for a long time in the traditional DBMS field.
>
> On the basis of the reason for the discussion,  TABLEGROUP doesn't sit
> well because of user types / functions / indexes etc. which are not
> strictly tables and is also yet another Cassandra only term.
>
> NAMESPACE could work but it's different usage in other systems could be
> just as confusing to new users.
>
> And, I certainly don't think having multiple names for the same thing just
> to satisfy different parties is a good idea at all.
>
> I'm quite happy to leave things as they are if that is the consensus.
>
> On Thu, 6 Apr 2023 at 14:16, Josh McKenzie  wrote:
>
>> KEYSPACE is fine. If we want to introduce a standard nomenclature like
>> DATABASE that’s also fine. Inventing brand new ones is not fine, there’s no
>> benefit.
>>
>> I'm with Benedict in principle, with Aleksey in practice; I think
>> KEYSPACE and SCHEMA are actually fine enough.
>>
>> If and when we get to any kind of multi-tenancy, having a more
>> metaphorical abstraction that users are familiar with like these becomes
>> more valuable; it's pretty clear that things in different keyspaces,
>> different databases, or even different schemas could have different access
>> rules, resourcing, etc from one another.
>>
>> While the off-the-cuff logical TABLEGROUP thing is a *literal* statement
>> about what the thing is, it'd be another unique term to us;  we have enough
>> things in our system where we've charted our own path. My personal .02 is
>> we don't need to go adding more. :)
>>
>> On Thu, Apr 6, 2023, at 8:54 AM, Mick Semb Wever wrote:
>>
>>
>> … but that should be a different discussion about how we evolve config.
>>
>>
>>
>> I disagree. Nomenclature being difficult can benefit from holistic and
>> forward thinking.
>> Sure you can label this off-topic if you like, but I value our discuss
>> threads being collaborative in an open-mode. Sometimes the best idea is on
>> the tail end of a sequence of bad and/or unpopular ideas.
>>
>>
>>
>>
>>
>>
>
> --
> [image: DataStax Logo Square]  *Mike Adamson*
> Engineering
>
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online: [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS
> Feed]    [image: Github Logo]
> 
>
>

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Dinesh Joshi]

I’m strongly in favor of leaving terminology as-is. On Apr 6, 2023, at 7:20 AM, Bowen Song via dev  wrote:
  

  
  
> I'm quite happy to leave things as they are if that is
the consensus.
+1 to the above



On 06/04/2023 14:54, Mike Adamson
  wrote:


  
  My apologies. I started this discussion off the
back of a usability discussion around new user accessibility to
Cassandra and the premise that there is an initial steep
learning curve for new users. Including new users who have
worked for a long time in the traditional DBMS field.


On the basis of the reason for the discussion,  TABLEGROUP
  doesn't sit well because of user types / functions / indexes
  etc. which are not strictly tables and is also yet another
  Cassandra only term. 


NAMESPACE could work but it's different usage in
  other systems could be just as confusing to new users. 


And, I certainly don't think having multiple names for the
  same thing just to satisfy different parties is a good idea at
  all. 


I'm quite happy to leave things as they are if that is the
  consensus.
  
  
  
On Thu, 6 Apr 2023 at 14:16,
  Josh McKenzie 
  wrote:


  

  
KEYSPACE is fine. If we want to introduce
  a standard nomenclature like DATABASE that’s also
  fine. Inventing brand new ones is not fine, there’s no
  benefit.

  
  I'm with Benedict in principle, with
Aleksey in practice; I think KEYSPACE and SCHEMA are
actually fine enough.
  
  
  
  If and when we get to any kind of
multi-tenancy, having a more metaphorical abstraction
that users are familiar with like these becomes more
valuable; it's pretty clear that things in different
keyspaces, different databases, or even different
schemas could have different access rules, resourcing,
etc from one another.
  
  
  
  While the off-the-cuff logical TABLEGROUP
thing is a literal statement about what the thing
is, it'd be another unique term to us;  we have enough
things in our system where we've charted our own path.
My personal .02 is we don't need to go adding more. :)
  
  
  
  On Thu, Apr 6, 2023, at 8:54 AM, Mick Semb Wever
wrote:
  
  

  


  
  

  
… but that should be a different discussion
  about how we evolve config.

  



 


  I
disagree. Nomenclature being difficult can
benefit from holistic and forward thinking.
  


  Sure you
can label this off-topic if you like, but I
value our discuss threads being collaborative in
an open-mode. Sometimes the best idea is on the
tail end of a sequence of bad and/or unpopular
ideas.
  






  


  

  
  
  

  
  
  

  

  
  
  
  
  -- 
  

  

  

Mike
  Adamson
  
  
Engineering

  
  
  
+1 650 389 6000 | datastax.com
  

  
  

  
Find DataStax
Online:
        
  

  

  

  

  

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Henrik Ingo]

On Thu, Apr 6, 2023 at 4:16 PM Josh McKenzie  wrote:

> KEYSPACE is fine. If we want to introduce a standard nomenclature like
> DATABASE that’s also fine. Inventing brand new ones is not fine, there’s no
> benefit.
>
> I'm with Benedict in principle, with Aleksey in practice; I think KEYSPACE
> and SCHEMA are actually fine enough.
>
>
Having learned that SCHEMA already exists as a synonym for KEYSPACE, I
think everything is good here. If Cassandra evolves to a richer database
(transactions and queries beyond just key based access) then gradually
adopting SCHEMA as the primary name might feel natural. Once we get there.


> If and when we get to any kind of multi-tenancy, having a more
> metaphorical abstraction that users are familiar with like these becomes
> more valuable; it's pretty clear that things in different keyspaces,
> different databases, or even different schemas could have different access
> rules, resourcing, etc from one another.
>
>
At Datastax I've tried, with some success actually, to ban the use of the
word "Database" in our cloud service, because it was too overloaded.
Various people, one group of which were the UI designers that expose their
point of view to actual users, had completely different ideas of what a
"database" is. I remember at least:
 - the cluster of servers / VMs in the cloud that together contain a
Cassandra database. => It's a cluster.
 - One tenant in a multi-tenanant cluster => It's a tenant
 - A KEYSPACE. This would have been most correct in my world view, but was
actually the least used. => KEYSPACE or SCHEMA
 - The software product: Cassandra, DSE, or Astra

I think the first two were the ones actually used in the UI.

Now that I think about this email thread, the different expectations of
what the word "database" means might correlate with whether the speaker's
background is in the Oracle/Postgresql/Microsoft camp, or the MySQL/MongoDB
camp.


So it's like me trying to order a bisquit in a US cafe.

henrik





> While the off-the-cuff logical TABLEGROUP thing is a *literal* statement
> about what the thing is, it'd be another unique term to us;  we have enough
> things in our system where we've charted our own path. My personal .02 is
> we don't need to go adding more. :)
>
> On Thu, Apr 6, 2023, at 8:54 AM, Mick Semb Wever wrote:
>
>
> … but that should be a different discussion about how we evolve config.
>
>
>
> I disagree. Nomenclature being difficult can benefit from holistic and
> forward thinking.
> Sure you can label this off-topic if you like, but I value our discuss
> threads being collaborative in an open-mode. Sometimes the best idea is on
> the tail end of a sequence of bad and/or unpopular ideas.
>
>
>
>
>
>

-- 

Henrik Ingo

c. +358 40 569 7354

w. www.datastax.com

  
  

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Bowen Song via dev]

/> I'm quite happy to leave things as they are if that is the consensus./

+1 to the above


On 06/04/2023 14:54, Mike Adamson wrote:
My apologies. I started this discussion off the back of a usability 
discussion around new user accessibility to Cassandra and the premise 
that there is an initial steep learning curve for new users. Including 
new users who have worked for a long time in the traditional DBMS field.


On the basis of the reason for the discussion,  TABLEGROUP doesn't sit 
well because of user types / functions / indexes etc. which are not 
strictly tables and is also yet another Cassandra only term.


NAMESPACE could work but it's different usage in other systems could 
be just as confusing to new users.


And, I certainly don't think having multiple names for the same thing 
just to satisfy different parties is a good idea at all.


I'm quite happy to leave things as they are if that is the consensus.

On Thu, 6 Apr 2023 at 14:16, Josh McKenzie  wrote:


KEYSPACE is fine. If we want to introduce a standard nomenclature
like DATABASE that’s also fine. Inventing brand new ones is not
fine, there’s no benefit.

I'm with Benedict in principle, with Aleksey in practice; I think
KEYSPACE and SCHEMA are actually fine enough.

If and when we get to any kind of multi-tenancy, having a more
metaphorical abstraction that users are familiar with like these
becomes more valuable; it's pretty clear that things in different
keyspaces, different databases, or even different schemas could
have different access rules, resourcing, etc from one another.

While the off-the-cuff logical TABLEGROUP thing is a /literal/
statement about what the thing is, it'd be another unique term to
us;  we have enough things in our system where we've charted our
own path. My personal .02 is we don't need to go adding more. :)

On Thu, Apr 6, 2023, at 8:54 AM, Mick Semb Wever wrote:


… but that should be a different discussion about how we
evolve config.



I disagree. Nomenclature being difficult can benefit from
holistic and forward thinking.
Sure you can label this off-topic if you like, but I value our
discuss threads being collaborative in an open-mode.
Sometimes the best idea is on the tail end of a sequence of bad
and/or unpopular ideas.








--
DataStax Logo Square   *Mike Adamson*
Engineering

+1 650 389 6000 |datastax.com 



Find DataStax Online: 	LinkedIn Logo 
 
Facebook Logo 
 
Twitter Logo  RSS Feed 
 Github Logo 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Mike Adamson]

My apologies. I started this discussion off the back of a usability
discussion around new user accessibility to Cassandra and the premise that
there is an initial steep learning curve for new users. Including new users
who have worked for a long time in the traditional DBMS field.

On the basis of the reason for the discussion,  TABLEGROUP doesn't sit well
because of user types / functions / indexes etc. which are not strictly
tables and is also yet another Cassandra only term.

NAMESPACE could work but it's different usage in other systems could be
just as confusing to new users.

And, I certainly don't think having multiple names for the same thing just
to satisfy different parties is a good idea at all.

I'm quite happy to leave things as they are if that is the consensus.

On Thu, 6 Apr 2023 at 14:16, Josh McKenzie  wrote:

> KEYSPACE is fine. If we want to introduce a standard nomenclature like
> DATABASE that’s also fine. Inventing brand new ones is not fine, there’s no
> benefit.
>
> I'm with Benedict in principle, with Aleksey in practice; I think KEYSPACE
> and SCHEMA are actually fine enough.
>
> If and when we get to any kind of multi-tenancy, having a more
> metaphorical abstraction that users are familiar with like these becomes
> more valuable; it's pretty clear that things in different keyspaces,
> different databases, or even different schemas could have different access
> rules, resourcing, etc from one another.
>
> While the off-the-cuff logical TABLEGROUP thing is a *literal* statement
> about what the thing is, it'd be another unique term to us;  we have enough
> things in our system where we've charted our own path. My personal .02 is
> we don't need to go adding more. :)
>
> On Thu, Apr 6, 2023, at 8:54 AM, Mick Semb Wever wrote:
>
>
> … but that should be a different discussion about how we evolve config.
>
>
>
> I disagree. Nomenclature being difficult can benefit from holistic and
> forward thinking.
> Sure you can label this off-topic if you like, but I value our discuss
> threads being collaborative in an open-mode. Sometimes the best idea is on
> the tail end of a sequence of bad and/or unpopular ideas.
>
>
>
>
>
>

-- 
[image: DataStax Logo Square]  *Mike Adamson*
Engineering

+1 650 389 6000 <16503896000> | datastax.com 
Find DataStax Online: [image: LinkedIn Logo]

   [image: Facebook Logo]

   [image: Twitter Logo]    [image: RSS Feed]
   [image: Github Logo]

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Josh McKenzie]

> KEYSPACE is fine. If we want to introduce a standard nomenclature like 
> DATABASE that’s also fine. Inventing brand new ones is not fine, there’s no 
> benefit.
I'm with Benedict in principle, with Aleksey in practice; I think KEYSPACE and 
SCHEMA are actually fine enough.

If and when we get to any kind of multi-tenancy, having a more metaphorical 
abstraction that users are familiar with like these becomes more valuable; it's 
pretty clear that things in different keyspaces, different databases, or even 
different schemas could have different access rules, resourcing, etc from one 
another.

While the off-the-cuff logical TABLEGROUP thing is a *literal* statement about 
what the thing is, it'd be another unique term to us;  we have enough things in 
our system where we've charted our own path. My personal .02 is we don't need 
to go adding more. :)

On Thu, Apr 6, 2023, at 8:54 AM, Mick Semb Wever wrote:
> 
>> … but that should be a different discussion about how we evolve config.
> 
>  
> I disagree. Nomenclature being difficult can benefit from holistic and 
> forward thinking.
> Sure you can label this off-topic if you like, but I value our discuss 
> threads being collaborative in an open-mode. Sometimes the best idea is on 
> the tail end of a sequence of bad and/or unpopular ideas.
> 
> 
>> 
> 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Mick Semb Wever]

> … but that should be a different discussion about how we evolve config.
>


I disagree. Nomenclature being difficult can benefit from holistic and
forward thinking.

Sure you can label this off-topic if you like, but I value our discuss
threads being collaborative in an open-mode. Sometimes the best idea is on
the tail end of a sequence of bad and/or unpopular ideas.

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Ekaterina Dimitrova]

“ KEYSPACE is fine. If we want to introduce a standard nomenclature like
DATABASE that’s also fine. Inventing brand new ones is not fine, there’s no
benefit.

I think it would be fine to introduce some arbitrary unrelated concept for
assigning tables with similar behaviours some configuration that is
orthogonal to replication, but that should be a different discussion about
how we evolve config.”

+1


On Thu, 6 Apr 2023 at 5:26, Benedict  wrote:

> KEYSPACE is fine. If we want to introduce a standard nomenclature like
> DATABASE that’s also fine. Inventing brand new ones is not fine, there’s no
> benefit.
>
> I think it would be fine to introduce some arbitrary unrelated concept for
> assigning tables with similar behaviours some configuration that is
> orthogonal to replication, but that should be a different discussion about
> how we evolve config.
>
> On 6 Apr 2023, at 09:40, Mick Semb Wever  wrote:
>
> 
>
> Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically* better
>> satisfy point 1 and 2 above but subjectively I kind of recoil at both
>> equally. So there's that.
>>
>
>
>
> TABLEGROUP would work for me.  Immediately intuitive.
>
> brain-storming…
>
> A keyspace today defines replication strategy, rf, and durable_writes. If
> they also had the table options that could be defined as defaults for all
> tables in that group, and one tablegroup could be a child and inherit
> settings from another tablegroup, you could logically group tables in ways
> that both benefit your application platform's taxonomy and the spread of
> keyspace/table settings. DATABASE, NAMESPACE, whatever, can be aliases to
> it too, if you like.
>
>
>
>
>

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Benedict]

KEYSPACE is fine. If we want to introduce a standard nomenclature like DATABASE 
that’s also fine. Inventing brand new ones is not fine, there’s no benefit.

I think it would be fine to introduce some arbitrary unrelated concept for 
assigning tables with similar behaviours some configuration that is orthogonal 
to replication, but that should be a different discussion about how we evolve 
config.

> On 6 Apr 2023, at 09:40, Mick Semb Wever  wrote:
> 
> 
>> Something like "TABLESPACE" or 'TABLEGROUP" would theoretically better 
>> satisfy point 1 and 2 above but subjectively I kind of recoil at both 
>> equally. So there's that.
> 
> 
> 
> TABLEGROUP would work for me.  Immediately intuitive.
> 
> brain-storming…
> 
> A keyspace today defines replication strategy, rf, and durable_writes. If 
> they also had the table options that could be defined as defaults for all 
> tables in that group, and one tablegroup could be a child and inherit 
> settings from another tablegroup, you could logically group tables in ways 
> that both benefit your application platform's taxonomy and the spread of 
> keyspace/table settings. DATABASE, NAMESPACE, whatever, can be aliases to it 
> too, if you like.
> 
> 
>  

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Miklosovic, Stefan]

I just do not share your concerns, Berenguer. Maybe you have a different 
experience but I have never seen anybody who judged if they are going to use so 
and so database based on the fact if the startup logs are easy to parse, 
conceptually and mentally. Lets talk about simplifying the startup logs then 
and not logging what is not necessary. We might probably find such cases 
already which are not needed.


From: Berenguer Blasi 
Sent: Thursday, April 6, 2023 10:22
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




No beginner is going to look for keyspace in logs imo, that's not what I
was pointing at. But upon starting C* you get a wall of logs which is
less user friendly imo than having a nice simple message saying you just
started. Then you go to cqlsh and keyspace and RF are the first things
he is going to hit. He might think 'Too mush overall hassle, I'll go
check sthg else instead'

On 6/4/23 10:01, Miklosovic, Stefan wrote:
> So lets rename Keyspace (Java class) to Database then. If we are concerned 
> that looking into logs would be full of "keyspaces" but a user created 
> "database" and it is a source of inconsistencies, should not it be somehow 
> resolved and unified?
>
> I think that it is just too late to rename keyspace to something else. That 
> term is so entrenched over the years in Cassandra-verse that it just does not 
> make sense to try to get rid of that.
>
> Also, a "beginner" might not look into the logs at all. I think that they 
> will be all over CQL trying to load there some data etc rather than looking 
> into the logs  not important. Who is looking into the actual logs while 
> logging into the console, whatever DB they are using? These are not beginners 
> imho.
>
> BTW keep in mind that all nodetool commands which are using "keyspace" 
> terminology would have to be probably accommodated to "database" term as well.
>
> ____
> From: Berenguer Blasi 
> Sent: Thursday, April 6, 2023 9:47
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE
>
> NetApp Security WARNING: This is an external email. Do not click links or 
> open attachments unless you recognize the sender and know the content is safe.
>
>
>
>
> One aspect to take into account is that we might not go even get as far
> as having a chance to educate the user. They start the thing up, see a
> wall of logs and then start seeing 'keyspace' (what is that?), etc.
> Everything seems so foreign and out of band to their 'normal' experience
> they just move on to the next option they had in mind.
>
> My 2cts.
>
> On 6/4/23 9:30, Miklosovic, Stefan wrote:
>> I am against simplifying that so much, up to the point that there is some 
>> implicit replication strategy. While I understand the preferences towards 
>> having it all "easier", what is wrong with knowing that there are some 
>> replication strategies and my data will be replicated just once? There is 
>> also an educational aspect to that.
>>
>> Also, having 4 ways how to create "keyspace" (keyspace, schema, database, 
>> namespace) feels pretty confusing to me. Are they equal? Why four? Is not it 
>> just better to have one way of doing that? Having 4 ways to do that feels 
>> like we do not know how to name it.
>>
>> Somebody already mentioned in this thread that Postgres is quite complex in 
>> this. Maybe adding "DATABASE" would be OK but anything beyond that 
>> (NAMESPACE etc) is just too much imo.
>>
>> 
>> From: Jacek Lewandowski 
>> Sent: Thursday, April 6, 2023 8:36
>> To: dev@cassandra.apache.org
>> Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE
>>
>> NetApp Security WARNING: This is an external email. Do not click links or 
>> open attachments unless you recognize the sender and know the content is 
>> safe.
>>
>>
>>
>> Haha... we have opinions against each name :)
>>
>> According to what Caleb said, I don't think all new users start learning 
>> Cassandra from understanding the replication.
>> There are probably many small projects where Cassandra is used on a single 
>> node, or bigger projects where people
>> try different things to make some PoC. Understanding the internals, 
>> architecture of Cassandra is not crucial - they
>>want to start wr

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Mick Semb Wever]

>
> Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically* better
> satisfy point 1 and 2 above but subjectively I kind of recoil at both
> equally. So there's that.
>



TABLEGROUP would work for me.  Immediately intuitive.

brain-storming…

A keyspace today defines replication strategy, rf, and durable_writes. If
they also had the table options that could be defined as defaults for all
tables in that group, and one tablegroup could be a child and inherit
settings from another tablegroup, you could logically group tables in ways
that both benefit your application platform's taxonomy and the spread of
keyspace/table settings. DATABASE, NAMESPACE, whatever, can be aliases to
it too, if you like.

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[guo Maxwell]

>
> So lets rename Keyspace (Java class) to Database then. If we are concerned
> that looking into logs would be full of "keyspaces" but a user created
> "database" and it is a source of inconsistencies, should not it be somehow
> resolved and unified?
>
> I think that it is just too late to rename keyspace to something else.
> That term is so entrenched over the years in Cassandra-verse that it just
> does not make sense to try to get rid of that.
>
> Also, a "beginner" might not look into the logs at all. I think that they
> will be all over CQL trying to load there some data etc rather than looking
> into the logs  not important. Who is looking into the actual logs while
> logging into the console, whatever DB they are using? These are not
> beginners imho.
>
> BTW keep in mind that all nodetool commands which are using "keyspace"
> terminology would have to be probably accommodated to "database" term as
> well.
>

+1

Miklosovic, Stefan  于2023年4月6日周四 16:01写道：

> So lets rename Keyspace (Java class) to Database then. If we are concerned
> that looking into logs would be full of "keyspaces" but a user created
> "database" and it is a source of inconsistencies, should not it be somehow
> resolved and unified?
>
> I think that it is just too late to rename keyspace to something else.
> That term is so entrenched over the years in Cassandra-verse that it just
> does not make sense to try to get rid of that.
>
> Also, a "beginner" might not look into the logs at all. I think that they
> will be all over CQL trying to load there some data etc rather than looking
> into the logs  not important. Who is looking into the actual logs while
> logging into the console, whatever DB they are using? These are not
> beginners imho.
>
> BTW keep in mind that all nodetool commands which are using "keyspace"
> terminology would have to be probably accommodated to "database" term as
> well.
>
> 
> From: Berenguer Blasi 
> Sent: Thursday, April 6, 2023 9:47
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
>
> One aspect to take into account is that we might not go even get as far
> as having a chance to educate the user. They start the thing up, see a
> wall of logs and then start seeing 'keyspace' (what is that?), etc.
> Everything seems so foreign and out of band to their 'normal' experience
> they just move on to the next option they had in mind.
>
> My 2cts.
>
> On 6/4/23 9:30, Miklosovic, Stefan wrote:
> > I am against simplifying that so much, up to the point that there is
> some implicit replication strategy. While I understand the preferences
> towards having it all "easier", what is wrong with knowing that there are
> some replication strategies and my data will be replicated just once? There
> is also an educational aspect to that.
> >
> > Also, having 4 ways how to create "keyspace" (keyspace, schema,
> database, namespace) feels pretty confusing to me. Are they equal? Why
> four? Is not it just better to have one way of doing that? Having 4 ways to
> do that feels like we do not know how to name it.
> >
> > Somebody already mentioned in this thread that Postgres is quite complex
> in this. Maybe adding "DATABASE" would be OK but anything beyond that
> (NAMESPACE etc) is just too much imo.
> >
> > 
> > From: Jacek Lewandowski 
> > Sent: Thursday, April 6, 2023 8:36
> > To: dev@cassandra.apache.org
> > Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE
> >
> > NetApp Security WARNING: This is an external email. Do not click links
> or open attachments unless you recognize the sender and know the content is
> safe.
> >
> >
> >
> > Haha... we have opinions against each name :)
> >
> > According to what Caleb said, I don't think all new users start learning
> Cassandra from understanding the replication.
> > There are probably many small projects where Cassandra is used on a
> single node, or bigger projects where people
> > try different things to make some PoC. Understanding the internals,
> architecture of Cassandra is not crucial - they
> >   want to start writing queries as soon as possible and the less prior
> knowledge is required to do that the better.
> >
> > That being said, we should ma

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Berenguer Blasi]

No beginner is going to look for keyspace in logs imo, that's not what I 
was pointing at. But upon starting C* you get a wall of logs which is 
less user friendly imo than having a nice simple message saying you just 
started. Then you go to cqlsh and keyspace and RF are the first things 
he is going to hit. He might think 'Too mush overall hassle, I'll go 
check sthg else instead'


On 6/4/23 10:01, Miklosovic, Stefan wrote:

So lets rename Keyspace (Java class) to Database then. If we are concerned that looking into logs 
would be full of "keyspaces" but a user created "database" and it is a source 
of inconsistencies, should not it be somehow resolved and unified?

I think that it is just too late to rename keyspace to something else. That 
term is so entrenched over the years in Cassandra-verse that it just does not 
make sense to try to get rid of that.

Also, a "beginner" might not look into the logs at all. I think that they will 
be all over CQL trying to load there some data etc rather than looking into the logs  
not important. Who is looking into the actual logs while logging into the console, 
whatever DB they are using? These are not beginners imho.

BTW keep in mind that all nodetool commands which are using "keyspace" terminology would 
have to be probably accommodated to "database" term as well.


From: Berenguer Blasi 
Sent: Thursday, April 6, 2023 9:47
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




One aspect to take into account is that we might not go even get as far
as having a chance to educate the user. They start the thing up, see a
wall of logs and then start seeing 'keyspace' (what is that?), etc.
Everything seems so foreign and out of band to their 'normal' experience
they just move on to the next option they had in mind.

My 2cts.

On 6/4/23 9:30, Miklosovic, Stefan wrote:

I am against simplifying that so much, up to the point that there is some implicit 
replication strategy. While I understand the preferences towards having it all 
"easier", what is wrong with knowing that there are some replication strategies 
and my data will be replicated just once? There is also an educational aspect to that.

Also, having 4 ways how to create "keyspace" (keyspace, schema, database, 
namespace) feels pretty confusing to me. Are they equal? Why four? Is not it just better 
to have one way of doing that? Having 4 ways to do that feels like we do not know how to 
name it.

Somebody already mentioned in this thread that Postgres is quite complex in this. Maybe 
adding "DATABASE" would be OK but anything beyond that (NAMESPACE etc) is just 
too much imo.


From: Jacek Lewandowski 
Sent: Thursday, April 6, 2023 8:36
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



Haha... we have opinions against each name :)

According to what Caleb said, I don't think all new users start learning 
Cassandra from understanding the replication.
There are probably many small projects where Cassandra is used on a single 
node, or bigger projects where people
try different things to make some PoC. Understanding the internals, 
architecture of Cassandra is not crucial - they
   want to start writing queries as soon as possible and the less prior 
knowledge is required to do that the better.

That being said, we should maybe even go further and assume some default 
replication config, like simple 1, so that
creating a names boils down to a simply CREATE KEYSPACE|SCHEMA|DATABASE|NAMESPACE 
;

thanks,
- - -- --- -  -
Jacek Lewandowski


czw., 6 kwi 2023 o 04:09 guo Maxwell 
mailto:cclive1...@gmail.com>> napisał(a):
either KEYSPACE or DATABASE or SCHEMA is better than NAMESPACE
NAMESPACE is always used in hbase which is a table store in my mind.
For existing users, NAMESPACE may take some time to be accepted. For hbase and 
cassandra users, it may be necessary to mix the corresponding terms.
  From the terminology standard of the database， DATABASE or SCHAME may be 
better , for terminology standard of the nosql database (cassandra), KESYACEP 
is better.


Caleb Rackliffe mailto:calebrackli...@gmail.com>> 
于2023年4月6日周四 07:09写道：
KEYSPACE isn’t a terrible name for a namespace that also configures how keys 
are replicated. NAMESPACE is accurate but not comprehensive. DATABASE doesn’t 
seem to have the advantages of either.

I’m neutral on NAMESPACE and slightly -1 on DATABASE. It’s hard for me to 
believ

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Miklosovic, Stefan]

So lets rename Keyspace (Java class) to Database then. If we are concerned that 
looking into logs would be full of "keyspaces" but a user created "database" 
and it is a source of inconsistencies, should not it be somehow resolved and 
unified?

I think that it is just too late to rename keyspace to something else. That 
term is so entrenched over the years in Cassandra-verse that it just does not 
make sense to try to get rid of that.

Also, a "beginner" might not look into the logs at all. I think that they will 
be all over CQL trying to load there some data etc rather than looking into the 
logs  not important. Who is looking into the actual logs while logging into 
the console, whatever DB they are using? These are not beginners imho.

BTW keep in mind that all nodetool commands which are using "keyspace" 
terminology would have to be probably accommodated to "database" term as well.


From: Berenguer Blasi 
Sent: Thursday, April 6, 2023 9:47
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




One aspect to take into account is that we might not go even get as far
as having a chance to educate the user. They start the thing up, see a
wall of logs and then start seeing 'keyspace' (what is that?), etc.
Everything seems so foreign and out of band to their 'normal' experience
they just move on to the next option they had in mind.

My 2cts.

On 6/4/23 9:30, Miklosovic, Stefan wrote:
> I am against simplifying that so much, up to the point that there is some 
> implicit replication strategy. While I understand the preferences towards 
> having it all "easier", what is wrong with knowing that there are some 
> replication strategies and my data will be replicated just once? There is 
> also an educational aspect to that.
>
> Also, having 4 ways how to create "keyspace" (keyspace, schema, database, 
> namespace) feels pretty confusing to me. Are they equal? Why four? Is not it 
> just better to have one way of doing that? Having 4 ways to do that feels 
> like we do not know how to name it.
>
> Somebody already mentioned in this thread that Postgres is quite complex in 
> this. Maybe adding "DATABASE" would be OK but anything beyond that (NAMESPACE 
> etc) is just too much imo.
>
> ________________
> From: Jacek Lewandowski 
> Sent: Thursday, April 6, 2023 8:36
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE
>
> NetApp Security WARNING: This is an external email. Do not click links or 
> open attachments unless you recognize the sender and know the content is safe.
>
>
>
> Haha... we have opinions against each name :)
>
> According to what Caleb said, I don't think all new users start learning 
> Cassandra from understanding the replication.
> There are probably many small projects where Cassandra is used on a single 
> node, or bigger projects where people
> try different things to make some PoC. Understanding the internals, 
> architecture of Cassandra is not crucial - they
>   want to start writing queries as soon as possible and the less prior 
> knowledge is required to do that the better.
>
> That being said, we should maybe even go further and assume some default 
> replication config, like simple 1, so that
> creating a names boils down to a simply CREATE 
> KEYSPACE|SCHEMA|DATABASE|NAMESPACE ;
>
> thanks,
> - - -- --- -  -
> Jacek Lewandowski
>
>
> czw., 6 kwi 2023 o 04:09 guo Maxwell 
> mailto:cclive1...@gmail.com>> napisał(a):
> either KEYSPACE or DATABASE or SCHEMA is better than NAMESPACE
> NAMESPACE is always used in hbase which is a table store in my mind.
> For existing users, NAMESPACE may take some time to be accepted. For hbase 
> and cassandra users, it may be necessary to mix the corresponding terms.
>  From the terminology standard of the database， DATABASE or SCHAME may be 
> better , for terminology standard of the nosql database (cassandra), KESYACEP 
> is better.
>
>
> Caleb Rackliffe mailto:calebrackli...@gmail.com>> 
> 于2023年4月6日周四 07:09写道：
> KEYSPACE isn’t a terrible name for a namespace that also configures how keys 
> are replicated. NAMESPACE is accurate but not comprehensive. DATABASE doesn’t 
> seem to have the advantages of either.
>
> I’m neutral on NAMESPACE and slightly -1 on DATABASE. It’s hard for me to 
> believe KEYSPACE is really a stumbling block for new users, especially when 
> it connotes something those users should un

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Berenguer Blasi]

One aspect to take into account is that we might not go even get as far 
as having a chance to educate the user. They start the thing up, see a 
wall of logs and then start seeing 'keyspace' (what is that?), etc. 
Everything seems so foreign and out of band to their 'normal' experience 
they just move on to the next option they had in mind.


My 2cts.

On 6/4/23 9:30, Miklosovic, Stefan wrote:

I am against simplifying that so much, up to the point that there is some implicit 
replication strategy. While I understand the preferences towards having it all 
"easier", what is wrong with knowing that there are some replication strategies 
and my data will be replicated just once? There is also an educational aspect to that.

Also, having 4 ways how to create "keyspace" (keyspace, schema, database, 
namespace) feels pretty confusing to me. Are they equal? Why four? Is not it just better 
to have one way of doing that? Having 4 ways to do that feels like we do not know how to 
name it.

Somebody already mentioned in this thread that Postgres is quite complex in this. Maybe 
adding "DATABASE" would be OK but anything beyond that (NAMESPACE etc) is just 
too much imo.


From: Jacek Lewandowski 
Sent: Thursday, April 6, 2023 8:36
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



Haha... we have opinions against each name :)

According to what Caleb said, I don't think all new users start learning 
Cassandra from understanding the replication.
There are probably many small projects where Cassandra is used on a single 
node, or bigger projects where people
try different things to make some PoC. Understanding the internals, 
architecture of Cassandra is not crucial - they
  want to start writing queries as soon as possible and the less prior 
knowledge is required to do that the better.

That being said, we should maybe even go further and assume some default 
replication config, like simple 1, so that
creating a names boils down to a simply CREATE KEYSPACE|SCHEMA|DATABASE|NAMESPACE 
;

thanks,
- - -- --- -  -
Jacek Lewandowski


czw., 6 kwi 2023 o 04:09 guo Maxwell 
mailto:cclive1...@gmail.com>> napisał(a):
either KEYSPACE or DATABASE or SCHEMA is better than NAMESPACE
NAMESPACE is always used in hbase which is a table store in my mind.
For existing users, NAMESPACE may take some time to be accepted. For hbase and 
cassandra users, it may be necessary to mix the corresponding terms.
 From the terminology standard of the database， DATABASE or SCHAME may be 
better , for terminology standard of the nosql database (cassandra), KESYACEP 
is better.


Caleb Rackliffe mailto:calebrackli...@gmail.com>> 
于2023年4月6日周四 07:09写道：
KEYSPACE isn’t a terrible name for a namespace that also configures how keys 
are replicated. NAMESPACE is accurate but not comprehensive. DATABASE doesn’t 
seem to have the advantages of either.

I’m neutral on NAMESPACE and slightly -1 on DATABASE. It’s hard for me to 
believe KEYSPACE is really a stumbling block for new users, especially when it 
connotes something those users should understand about them (the replication 
configuration).

On Apr 5, 2023, at 4:16 AM, Aleksey Yeshchenko 
mailto:alek...@apple.com>> wrote:

FYI we support SCHEMA as an alias to KEYSPACE today (have since always). Can 
use CREATE SCHEMA in place of CREATE KEYSPACE, etc.

On 4 Apr 2023, at 19:23, Henrik Ingo 
mailto:henrik.i...@datastax.com>> wrote:

I find the Postgres terminology overly complex. Where most SQL databases will 
have several *databases*, each containing several *tables*, in Postgres we have 
namespaces, databases, schemas and tables...

Oracle seems to also use the words database, schema and tables. I don't know if 
it has namespaces.

Ah, ok, so SQL Server actually is like Oracle too!


So in MySQL, referring unambiguously (aka full path) to a table would be:

 SELECT * FROM mydb.mytable;

Whereas in Postgresql and Oracle and SQL Server you'd have to:

 SELECT * FROM mydb.myschema.mytable;   /* And I don't even know what to do 
with the namespace! */


https://www.postgresql.org/docs/current/catalog-pg-namespace.html
https://www.postgresql.org/docs/current/ddl-schemas.html
https://docs.oracle.com/database/121/ADMQS/GUID-6E0CE8C9-7DC4-450C-BAE0-2E1CDD882993.htm#ADMQS0821
https://docs.oracle.com/database/121/ADMQS/GUID-8AC1A325-3542-48A0-9B0E-180D633A5BD1.htm#ADMQS081
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-ver16
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-ver16=sqlpool

The Microsoft docs perhaps best explain the role of each: The Database contains th

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Miklosovic, Stefan]

I am against simplifying that so much, up to the point that there is some 
implicit replication strategy. While I understand the preferences towards 
having it all "easier", what is wrong with knowing that there are some 
replication strategies and my data will be replicated just once? There is also 
an educational aspect to that.

Also, having 4 ways how to create "keyspace" (keyspace, schema, database, 
namespace) feels pretty confusing to me. Are they equal? Why four? Is not it 
just better to have one way of doing that? Having 4 ways to do that feels like 
we do not know how to name it.

Somebody already mentioned in this thread that Postgres is quite complex in 
this. Maybe adding "DATABASE" would be OK but anything beyond that (NAMESPACE 
etc) is just too much imo.


From: Jacek Lewandowski 
Sent: Thursday, April 6, 2023 8:36
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



Haha... we have opinions against each name :)

According to what Caleb said, I don't think all new users start learning 
Cassandra from understanding the replication.
There are probably many small projects where Cassandra is used on a single 
node, or bigger projects where people
try different things to make some PoC. Understanding the internals, 
architecture of Cassandra is not crucial - they
 want to start writing queries as soon as possible and the less prior knowledge 
is required to do that the better.

That being said, we should maybe even go further and assume some default 
replication config, like simple 1, so that
creating a names boils down to a simply CREATE 
KEYSPACE|SCHEMA|DATABASE|NAMESPACE ;

thanks,
- - -- --- -  -
Jacek Lewandowski


czw., 6 kwi 2023 o 04:09 guo Maxwell 
mailto:cclive1...@gmail.com>> napisał(a):
either KEYSPACE or DATABASE or SCHEMA is better than NAMESPACE
NAMESPACE is always used in hbase which is a table store in my mind.
For existing users, NAMESPACE may take some time to be accepted. For hbase and 
cassandra users, it may be necessary to mix the corresponding terms.
From the terminology standard of the database， DATABASE or SCHAME may be better 
, for terminology standard of the nosql database (cassandra), KESYACEP is 
better.


Caleb Rackliffe mailto:calebrackli...@gmail.com>> 
于2023年4月6日周四 07:09写道：
KEYSPACE isn’t a terrible name for a namespace that also configures how keys 
are replicated. NAMESPACE is accurate but not comprehensive. DATABASE doesn’t 
seem to have the advantages of either.

I’m neutral on NAMESPACE and slightly -1 on DATABASE. It’s hard for me to 
believe KEYSPACE is really a stumbling block for new users, especially when it 
connotes something those users should understand about them (the replication 
configuration).

On Apr 5, 2023, at 4:16 AM, Aleksey Yeshchenko 
mailto:alek...@apple.com>> wrote:

FYI we support SCHEMA as an alias to KEYSPACE today (have since always). Can 
use CREATE SCHEMA in place of CREATE KEYSPACE, etc.

On 4 Apr 2023, at 19:23, Henrik Ingo 
mailto:henrik.i...@datastax.com>> wrote:

I find the Postgres terminology overly complex. Where most SQL databases will 
have several *databases*, each containing several *tables*, in Postgres we have 
namespaces, databases, schemas and tables...

Oracle seems to also use the words database, schema and tables. I don't know if 
it has namespaces.

Ah, ok, so SQL Server actually is like Oracle too!


So in MySQL, referring unambiguously (aka full path) to a table would be:

SELECT * FROM mydb.mytable;

Whereas in Postgresql and Oracle and SQL Server you'd have to:

SELECT * FROM mydb.myschema.mytable;   /* And I don't even know what to do 
with the namespace! */


https://www.postgresql.org/docs/current/catalog-pg-namespace.html
https://www.postgresql.org/docs/current/ddl-schemas.html
https://docs.oracle.com/database/121/ADMQS/GUID-6E0CE8C9-7DC4-450C-BAE0-2E1CDD882993.htm#ADMQS0821
https://docs.oracle.com/database/121/ADMQS/GUID-8AC1A325-3542-48A0-9B0E-180D633A5BD1.htm#ADMQS081
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-ver16
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-ver16=sqlpool

The Microsoft docs perhaps best explain the role of each: The Database contains 
the configuration of physical things like where on disk is the database stored. 
The Schema on the other hand contains "logical" objects like tables, views 
andprocedures.

MongoDB has databases and collections. As an easter egg / inside joke, it also 
supports the command `SHOW TABLES` as a synonym for collections.

A TABLESPACE btw is something else completely: 
https://docs.oracle.com/database/12

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[guo Maxwell]

I think replication_factor or replication is important. This concepts
will correspondingly lead to the concept of read and write consistency(ie :
ONE/QUORUM/ALL and so on) that users need to care about.
And the consistency level is very important to cassandra in my opinion.

Our experience is that there are many users who may not initially care
about replication factor and consistency level，then latter a lot of
explanation costs are introduced, and users will also feel that your
database is not easy to use.

So, why not educate users well from the beginning, and there are not many
of these concepts. Just like some data tell users from the beginning that
we are cloud-native, and we separate storage and computing.I think the
replication factor  should be easier to understand than these.


Jacek Lewandowski  于2023年4月6日周四 14:37写道：

> Haha... we have opinions against each name :)
>
> According to what Caleb said, I don't think all new users start learning
> Cassandra from understanding the replication.
> There are probably many small projects where Cassandra is used on a single
> node, or bigger projects where people
> try different things to make some PoC. Understanding the internals,
> architecture of Cassandra is not crucial - they
>  want to start writing queries as soon as possible and the less prior
> knowledge is required to do that the better.
>
> That being said, we should maybe even go further and assume some default
> replication config, like simple 1, so that
> creating a names boils down to a simply CREATE
> KEYSPACE|SCHEMA|DATABASE|NAMESPACE ;
>
> thanks,
> - - -- --- -  -
> Jacek Lewandowski
>
>
> czw., 6 kwi 2023 o 04:09 guo Maxwell  napisał(a):
>
>> either KEYSPACE or DATABASE or SCHEMA is better than NAMESPACE
>> NAMESPACE is always used in hbase which is a table store in my mind.
>> For existing users, NAMESPACE may take some time to be accepted. For
>> hbase and cassandra users, it may be necessary to mix the corresponding
>> terms.
>> From the terminology standard of the database， DATABASE or SCHAME may be
>> better , for terminology standard of the nosql database (cassandra),
>> KESYACEP is better.
>>
>>
>> Caleb Rackliffe  于2023年4月6日周四 07:09写道：
>>
>>> KEYSPACE isn’t a terrible name for a namespace that also configures how
>>> keys are replicated. NAMESPACE is accurate but not comprehensive. DATABASE
>>> doesn’t seem to have the advantages of either.
>>>
>>> I’m neutral on NAMESPACE and slightly -1 on DATABASE. It’s hard for me
>>> to believe KEYSPACE is really a stumbling block for new users, especially
>>> when it connotes something those users should understand about them (the
>>> replication configuration).
>>>
>>> On Apr 5, 2023, at 4:16 AM, Aleksey Yeshchenko 
>>> wrote:
>>>
>>> FYI we support SCHEMA as an alias to KEYSPACE today (have since
>>> always). Can use CREATE SCHEMA in place of CREATE KEYSPACE, etc.
>>>
>>> On 4 Apr 2023, at 19:23, Henrik Ingo  wrote:
>>>
>>> I find the Postgres terminology overly complex. Where most SQL databases
>>> will have several *databases*, each containing several *tables*, in
>>> Postgres we have namespaces, databases, schemas and tables...
>>>
>>> Oracle seems to also use the words database, schema and tables. I don't
>>> know if it has namespaces.
>>>
>>> Ah, ok, so SQL Server actually is like Oracle too!
>>>
>>>
>>> So in MySQL, referring unambiguously (aka full path) to a table would be:
>>>
>>> SELECT * FROM mydb.mytable;
>>>
>>> Whereas in Postgresql and Oracle and SQL Server you'd have to:
>>>
>>> SELECT * FROM mydb.myschema.mytable;   /* And I don't even know what
>>> to do with the namespace! */
>>>
>>>
>>> https://www.postgresql.org/docs/current/catalog-pg-namespace.html
>>> https://www.postgresql.org/docs/current/ddl-schemas.html
>>>
>>> https://docs.oracle.com/database/121/ADMQS/GUID-6E0CE8C9-7DC4-450C-BAE0-2E1CDD882993.htm#ADMQS0821
>>>
>>> https://docs.oracle.com/database/121/ADMQS/GUID-8AC1A325-3542-48A0-9B0E-180D633A5BD1.htm#ADMQS081
>>>
>>> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-ver16
>>>
>>> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-ver16=sqlpool
>>>
>>> The Microsoft docs perhaps best explain the role of each: The Database
>>> contains the configuration of physical things like where on disk is the
>>> database stored. The Schema on the other hand contains "logical" objects
>>> like tables, views andprocedures.
>>>
>>> MongoDB has databases and collections. As an easter egg / inside joke,
>>> it also supports the command `SHOW TABLES` as a synonym for collections.
>>>
>>> A TABLESPACE btw is something else completely:
>>> https://docs.oracle.com/database/121/ADMQS/GUID-F05EE514-FFC6-4E86-A592-802BA5A49254.htm#ADMQS12053
>>>
>>>
>>>
>>> Personally I would be in favor of introducing `DATABASE` as a synonym
>>> for KEYSPACE. The latter could remain the "official" usage.
>>>
>>> henrik

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Jacek Lewandowski]

Haha... we have opinions against each name :)

According to what Caleb said, I don't think all new users start learning
Cassandra from understanding the replication.
There are probably many small projects where Cassandra is used on a single
node, or bigger projects where people
try different things to make some PoC. Understanding the internals,
architecture of Cassandra is not crucial - they
 want to start writing queries as soon as possible and the less prior
knowledge is required to do that the better.

That being said, we should maybe even go further and assume some default
replication config, like simple 1, so that
creating a names boils down to a simply CREATE
KEYSPACE|SCHEMA|DATABASE|NAMESPACE ;

thanks,
- - -- --- -  -
Jacek Lewandowski


czw., 6 kwi 2023 o 04:09 guo Maxwell  napisał(a):

> either KEYSPACE or DATABASE or SCHEMA is better than NAMESPACE
> NAMESPACE is always used in hbase which is a table store in my mind.
> For existing users, NAMESPACE may take some time to be accepted. For hbase
> and cassandra users, it may be necessary to mix the corresponding terms.
> From the terminology standard of the database， DATABASE or SCHAME may be
> better , for terminology standard of the nosql database (cassandra),
> KESYACEP is better.
>
>
> Caleb Rackliffe  于2023年4月6日周四 07:09写道：
>
>> KEYSPACE isn’t a terrible name for a namespace that also configures how
>> keys are replicated. NAMESPACE is accurate but not comprehensive. DATABASE
>> doesn’t seem to have the advantages of either.
>>
>> I’m neutral on NAMESPACE and slightly -1 on DATABASE. It’s hard for me to
>> believe KEYSPACE is really a stumbling block for new users, especially when
>> it connotes something those users should understand about them (the
>> replication configuration).
>>
>> On Apr 5, 2023, at 4:16 AM, Aleksey Yeshchenko  wrote:
>>
>> FYI we support SCHEMA as an alias to KEYSPACE today (have since always).
>> Can use CREATE SCHEMA in place of CREATE KEYSPACE, etc.
>>
>> On 4 Apr 2023, at 19:23, Henrik Ingo  wrote:
>>
>> I find the Postgres terminology overly complex. Where most SQL databases
>> will have several *databases*, each containing several *tables*, in
>> Postgres we have namespaces, databases, schemas and tables...
>>
>> Oracle seems to also use the words database, schema and tables. I don't
>> know if it has namespaces.
>>
>> Ah, ok, so SQL Server actually is like Oracle too!
>>
>>
>> So in MySQL, referring unambiguously (aka full path) to a table would be:
>>
>> SELECT * FROM mydb.mytable;
>>
>> Whereas in Postgresql and Oracle and SQL Server you'd have to:
>>
>> SELECT * FROM mydb.myschema.mytable;   /* And I don't even know what
>> to do with the namespace! */
>>
>>
>> https://www.postgresql.org/docs/current/catalog-pg-namespace.html
>> https://www.postgresql.org/docs/current/ddl-schemas.html
>>
>> https://docs.oracle.com/database/121/ADMQS/GUID-6E0CE8C9-7DC4-450C-BAE0-2E1CDD882993.htm#ADMQS0821
>>
>> https://docs.oracle.com/database/121/ADMQS/GUID-8AC1A325-3542-48A0-9B0E-180D633A5BD1.htm#ADMQS081
>>
>> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-ver16
>>
>> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-ver16=sqlpool
>>
>> The Microsoft docs perhaps best explain the role of each: The Database
>> contains the configuration of physical things like where on disk is the
>> database stored. The Schema on the other hand contains "logical" objects
>> like tables, views andprocedures.
>>
>> MongoDB has databases and collections. As an easter egg / inside joke, it
>> also supports the command `SHOW TABLES` as a synonym for collections.
>>
>> A TABLESPACE btw is something else completely:
>> https://docs.oracle.com/database/121/ADMQS/GUID-F05EE514-FFC6-4E86-A592-802BA5A49254.htm#ADMQS12053
>>
>>
>>
>> Personally I would be in favor of introducing `DATABASE` as a synonym for
>> KEYSPACE. The latter could remain the "official" usage.
>>
>> henrik
>>
>>
>> On Tue, Apr 4, 2023 at 8:32 PM Jacek Lewandowski <
>> lewandowski.ja...@gmail.com> wrote:
>>
>>> While for someone who already knows Cassandra keyspace is something
>>> natural, for newcomers it is yet another concept to understand.
>>>
>>> If namespace is used in PostgreSQL, it sounds even better to me.
>>>
>>> Thanks,
>>> - - -- --- -  -
>>> Jacek Lewandowski
>>>
>>>
>>> wt., 4 kwi 2023 o 19:07 Rahul Xavier Singh 
>>> napisał(a):
>>>
 My 2 cents:

 Keeping it keyspace works for me, namespace could be cool also since we
 decide where that namespace exists in relation to Datacenters, etc.  In our
 case, a Keyspace is more similar to a namespace than it is to a database
 since we expect all the UDTs,/UDFs, indexes to refer to only the tables in
 that keyspace/namespace.

 Alternatively interesting to observe and throw some fuel into the
 discussion , looking at the Postgres 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[guo Maxwell]

either KEYSPACE or DATABASE or SCHEMA is better than NAMESPACE
NAMESPACE is always used in hbase which is a table store in my mind.
For existing users, NAMESPACE may take some time to be accepted. For hbase
and cassandra users, it may be necessary to mix the corresponding terms.
>From the terminology standard of the database， DATABASE or SCHAME may be
better , for terminology standard of the nosql database (cassandra),
KESYACEP is better.


Caleb Rackliffe  于2023年4月6日周四 07:09写道：

> KEYSPACE isn’t a terrible name for a namespace that also configures how
> keys are replicated. NAMESPACE is accurate but not comprehensive. DATABASE
> doesn’t seem to have the advantages of either.
>
> I’m neutral on NAMESPACE and slightly -1 on DATABASE. It’s hard for me to
> believe KEYSPACE is really a stumbling block for new users, especially when
> it connotes something those users should understand about them (the
> replication configuration).
>
> On Apr 5, 2023, at 4:16 AM, Aleksey Yeshchenko  wrote:
>
> FYI we support SCHEMA as an alias to KEYSPACE today (have since always).
> Can use CREATE SCHEMA in place of CREATE KEYSPACE, etc.
>
> On 4 Apr 2023, at 19:23, Henrik Ingo  wrote:
>
> I find the Postgres terminology overly complex. Where most SQL databases
> will have several *databases*, each containing several *tables*, in
> Postgres we have namespaces, databases, schemas and tables...
>
> Oracle seems to also use the words database, schema and tables. I don't
> know if it has namespaces.
>
> Ah, ok, so SQL Server actually is like Oracle too!
>
>
> So in MySQL, referring unambiguously (aka full path) to a table would be:
>
> SELECT * FROM mydb.mytable;
>
> Whereas in Postgresql and Oracle and SQL Server you'd have to:
>
> SELECT * FROM mydb.myschema.mytable;   /* And I don't even know what
> to do with the namespace! */
>
>
> https://www.postgresql.org/docs/current/catalog-pg-namespace.html
> https://www.postgresql.org/docs/current/ddl-schemas.html
>
> https://docs.oracle.com/database/121/ADMQS/GUID-6E0CE8C9-7DC4-450C-BAE0-2E1CDD882993.htm#ADMQS0821
>
> https://docs.oracle.com/database/121/ADMQS/GUID-8AC1A325-3542-48A0-9B0E-180D633A5BD1.htm#ADMQS081
>
> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-ver16
>
> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-ver16=sqlpool
>
> The Microsoft docs perhaps best explain the role of each: The Database
> contains the configuration of physical things like where on disk is the
> database stored. The Schema on the other hand contains "logical" objects
> like tables, views andprocedures.
>
> MongoDB has databases and collections. As an easter egg / inside joke, it
> also supports the command `SHOW TABLES` as a synonym for collections.
>
> A TABLESPACE btw is something else completely:
> https://docs.oracle.com/database/121/ADMQS/GUID-F05EE514-FFC6-4E86-A592-802BA5A49254.htm#ADMQS12053
>
>
>
> Personally I would be in favor of introducing `DATABASE` as a synonym for
> KEYSPACE. The latter could remain the "official" usage.
>
> henrik
>
>
> On Tue, Apr 4, 2023 at 8:32 PM Jacek Lewandowski <
> lewandowski.ja...@gmail.com> wrote:
>
>> While for someone who already knows Cassandra keyspace is something
>> natural, for newcomers it is yet another concept to understand.
>>
>> If namespace is used in PostgreSQL, it sounds even better to me.
>>
>> Thanks,
>> - - -- --- -  -
>> Jacek Lewandowski
>>
>>
>> wt., 4 kwi 2023 o 19:07 Rahul Xavier Singh 
>> napisał(a):
>>
>>> My 2 cents:
>>>
>>> Keeping it keyspace works for me, namespace could be cool also since we
>>> decide where that namespace exists in relation to Datacenters, etc.  In our
>>> case, a Keyspace is more similar to a namespace than it is to a database
>>> since we expect all the UDTs,/UDFs, indexes to refer to only the tables in
>>> that keyspace/namespace.
>>>
>>> Alternatively interesting to observe and throw some fuel into the
>>> discussion , looking at the Postgres (only because there are many
>>> distributed databases that are now PG compliant) :
>>> From the interwebs:
>>> *In PostgreSQL, a schema is a namespace that contains named database
>>> objects such as tables, views, indexes, data types, functions, stored
>>> procedures and operators. A database can contain one or multiple schemas
>>> and each schema belongs to only one database.*
>>> I used to gripe about this but as a platform gets more complex it is
>>> useful to organize PG DBs into schemas. In C* world, I found myself doing
>>> similar things by having a prefix : e.g. appprefix_system1
>>> appprefix_system2 ...
>>>
>>>
>>> Rahul Singh
>>> Chief Executive Officer | Business Platform Architect m: 202.905.2818
>>> e: rahul.si...@anant.us li: http://linkedin.com/in/xingh
>>> 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Caleb Rackliffe]

KEYSPACE isn’t a terrible name for a namespace that also configures how keys are replicated. NAMESPACE is accurate but not comprehensive. DATABASE doesn’t seem to have the advantages of either.I’m neutral on NAMESPACE and slightly -1 on DATABASE. It’s hard for me to believe KEYSPACE is really a stumbling block for new users, especially when it connotes something those users should understand about them (the replication configuration).On Apr 5, 2023, at 4:16 AM, Aleksey Yeshchenko  wrote:FYI we support SCHEMA as an alias to KEYSPACE today (have since always). Can use CREATE SCHEMA in place of CREATE KEYSPACE, etc. On 4 Apr 2023, at 19:23, Henrik Ingo  wrote:I find the Postgres terminology overly complex. Where most SQL databases will have several *databases*, each containing several *tables*, in Postgres we have namespaces, databases, schemas and tables...Oracle seems to also use the words database, schema and tables. I don't know if it has namespaces.Ah, ok, so SQL Server actually is like Oracle too!So in MySQL, referring unambiguously (aka full path) to a table would be:    SELECT * FROM mydb.mytable;Whereas in Postgresql and Oracle and SQL Server you'd have to:    SELECT * FROM mydb.myschema.mytable;   /* And I don't even know what to do with the namespace! */https://www.postgresql.org/docs/current/catalog-pg-namespace.htmlhttps://www.postgresql.org/docs/current/ddl-schemas.htmlhttps://docs.oracle.com/database/121/ADMQS/GUID-6E0CE8C9-7DC4-450C-BAE0-2E1CDD882993.htm#ADMQS0821https://docs.oracle.com/database/121/ADMQS/GUID-8AC1A325-3542-48A0-9B0E-180D633A5BD1.htm#ADMQS081https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-ver16https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-ver16=sqlpoolThe Microsoft docs perhaps best explain the role of each: The Database contains the configuration of physical things like where on disk is the database stored. The Schema on the other hand contains "logical" objects like tables, views andprocedures.MongoDB has databases and collections. As an easter egg / inside joke, it also supports the command `SHOW TABLES` as a synonym for collections. A TABLESPACE btw is something else completely: https://docs.oracle.com/database/121/ADMQS/GUID-F05EE514-FFC6-4E86-A592-802BA5A49254.htm#ADMQS12053Personally I would be in favor of introducing `DATABASE` as a synonym for KEYSPACE. The latter could remain the "official" usage.henrikOn Tue, Apr 4, 2023 at 8:32 PM Jacek Lewandowski  wrote:While for someone who already knows Cassandra keyspace is something natural, for newcomers it is yet another concept to understand. If namespace is used in PostgreSQL, it sounds even better to me.Thanks,- - -- --- -  -Jacek Lewandowskiwt., 4 kwi 2023 o 19:07 Rahul Xavier Singh  napisał(a):My 2 cents: Keeping it keyspace works for me, namespace could be cool also since we decide where that namespace exists in relation to Datacenters, etc.  In our case, a Keyspace is more similar to a namespace than it is to a database since we expect all the UDTs,/UDFs, indexes to refer to only the tables in that keyspace/namespace. Alternatively interesting to observe and throw some fuel into the discussion , looking at the Postgres (only because there are many distributed databases that are now PG compliant) :From the interwebs: In PostgreSQL, a schema is a namespace that contains named database objects such as tables, views, indexes, data types, functions, stored procedures and operators. A database can contain one or multiple schemas and each schema belongs to only one database.I used to gripe about this but as a platform gets more complex it is useful to organize PG DBs into schemas. In C* world, I found myself doing similar things by having a prefix : e.g. appprefix_system1 appprefix_system2 ...Rahul SinghChief Executive Officer | Business Platform Architect
m: 202.905.2818 e: rahul.si...@anant.us li: http://linkedin.com/in/xingh ca: http://calendly.com/xinghWe create, support, and manage real-time global data & analytics platforms for the modern enterprise.Anant | https://anant.us3 Washington Circle, Suite 301Washington, D.C. 20037http://Cassandra.Link : The best resources for Apache CassandraOn Tue, Apr 4, 2023 at 12:52 PM Jeff Jirsa  wrote:KEYSPACE at least makes sense in the context that it is the unit that defines how those partitions keys are going to be treated/replicatedDATABASE may be ambiguous, but it's ambiguity shared across the industry. Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because it'll be unique to us in the world, and therefore unintuitive for new users.On Tue, Apr 4, 2023 at 9:36 AM Josh McKenzie  wrote:I think there's competing dynamics here.1) KEYSPACE isn't that great of a name; it's not a space in which keys are necessarily unique, and you can't 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Aleksey Yeshchenko]

FYI we support SCHEMA as an alias to KEYSPACE today (have since always). Can 
use CREATE SCHEMA in place of CREATE KEYSPACE, etc. 

> On 4 Apr 2023, at 19:23, Henrik Ingo  wrote:
> 
> I find the Postgres terminology overly complex. Where most SQL databases will 
> have several *databases*, each containing several *tables*, in Postgres we 
> have namespaces, databases, schemas and tables...
> 
> Oracle seems to also use the words database, schema and tables. I don't know 
> if it has namespaces.
> 
> Ah, ok, so SQL Server actually is like Oracle too!
> 
> 
> So in MySQL, referring unambiguously (aka full path) to a table would be:
> 
> SELECT * FROM mydb.mytable;
> 
> Whereas in Postgresql and Oracle and SQL Server you'd have to:
> 
> SELECT * FROM mydb.myschema.mytable;   /* And I don't even know what to 
> do with the namespace! */
> 
> 
> https://www.postgresql.org/docs/current/catalog-pg-namespace.html
> https://www.postgresql.org/docs/current/ddl-schemas.html
> https://docs.oracle.com/database/121/ADMQS/GUID-6E0CE8C9-7DC4-450C-BAE0-2E1CDD882993.htm#ADMQS0821
> https://docs.oracle.com/database/121/ADMQS/GUID-8AC1A325-3542-48A0-9B0E-180D633A5BD1.htm#ADMQS081
> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-ver16
> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-ver16=sqlpool
> 
> The Microsoft docs perhaps best explain the role of each: The Database 
> contains the configuration of physical things like where on disk is the 
> database stored. The Schema on the other hand contains "logical" objects like 
> tables, views andprocedures.
> 
> MongoDB has databases and collections. As an easter egg / inside joke, it 
> also supports the command `SHOW TABLES` as a synonym for collections. 
> 
> A TABLESPACE btw is something else completely: 
> https://docs.oracle.com/database/121/ADMQS/GUID-F05EE514-FFC6-4E86-A592-802BA5A49254.htm#ADMQS12053
> 
> 
> 
> Personally I would be in favor of introducing `DATABASE` as a synonym for 
> KEYSPACE. The latter could remain the "official" usage.
> 
> henrik
> 
> 
> On Tue, Apr 4, 2023 at 8:32 PM Jacek Lewandowski  > wrote:
>> While for someone who already knows Cassandra keyspace is something natural, 
>> for newcomers it is yet another concept to understand. 
>> 
>> If namespace is used in PostgreSQL, it sounds even better to me.
>> 
>> Thanks,
>> - - -- --- -  -
>> Jacek Lewandowski
>> 
>> 
>> wt., 4 kwi 2023 o 19:07 Rahul Xavier Singh > > napisał(a):
>>> My 2 cents: 
>>> 
>>> Keeping it keyspace works for me, namespace could be cool also since we 
>>> decide where that namespace exists in relation to Datacenters, etc.  In our 
>>> case, a Keyspace is more similar to a namespace than it is to a database 
>>> since we expect all the UDTs,/UDFs, indexes to refer to only the tables in 
>>> that keyspace/namespace. 
>>> 
>>> Alternatively interesting to observe and throw some fuel into the 
>>> discussion , looking at the Postgres (only because there are many 
>>> distributed databases that are now PG compliant) :
>>> From the interwebs: In PostgreSQL, a schema is a namespace that contains 
>>> named database objects such as tables, views, indexes, data types, 
>>> functions, stored procedures and operators. A database can contain one or 
>>> multiple schemas and each schema belongs to only one database.
>>> 
>>> I used to gripe about this but as a platform gets more complex it is useful 
>>> to organize PG DBs into schemas. In C* world, I found myself doing similar 
>>> things by having a prefix : e.g. appprefix_system1 appprefix_system2 ...
>>> 
>>> 
>>> Rahul Singh
>>> Chief Executive Officer | Business Platform Architect
>>> m: 202.905.2818 e: rahul.si...@anant.us  li: 
>>> http://linkedin.com/in/xingh 
>>> 
>>>  ca: http://calendly.com/xingh 
>>> 
>>> We create, support, and manage real-time global data & analytics platforms 
>>> for the modern enterprise.
>>> 
>>> Anant | https://anant.us 
>>> 
>>> 3 Washington Circle, Suite 301
>>> Washington, D.C. 20037
>>> 
>>> http://Cassandra.Link 
>>> 
>>>  : The best resources for Apache Cassandra
>>> 
>>> 
>>> On Tue, Apr 4, 2023 at 12:52 PM Jeff 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Henrik Ingo]

I find the Postgres terminology overly complex. Where most SQL databases
will have several *databases*, each containing several *tables*, in
Postgres we have namespaces, databases, schemas and tables...

Oracle seems to also use the words database, schema and tables. I don't
know if it has namespaces.

Ah, ok, so SQL Server actually is like Oracle too!


So in MySQL, referring unambiguously (aka full path) to a table would be:

SELECT * FROM mydb.mytable;

Whereas in Postgresql and Oracle and SQL Server you'd have to:

SELECT * FROM mydb.myschema.mytable;   /* And I don't even know what to
do with the namespace! */


https://www.postgresql.org/docs/current/catalog-pg-namespace.html
https://www.postgresql.org/docs/current/ddl-schemas.html
https://docs.oracle.com/database/121/ADMQS/GUID-6E0CE8C9-7DC4-450C-BAE0-2E1CDD882993.htm#ADMQS0821
https://docs.oracle.com/database/121/ADMQS/GUID-8AC1A325-3542-48A0-9B0E-180D633A5BD1.htm#ADMQS081
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql?view=sql-server-ver16
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-ver16=sqlpool

The Microsoft docs perhaps best explain the role of each: The Database
contains the configuration of physical things like where on disk is the
database stored. The Schema on the other hand contains "logical" objects
like tables, views andprocedures.

MongoDB has databases and collections. As an easter egg / inside joke, it
also supports the command `SHOW TABLES` as a synonym for collections.

A TABLESPACE btw is something else completely:
https://docs.oracle.com/database/121/ADMQS/GUID-F05EE514-FFC6-4E86-A592-802BA5A49254.htm#ADMQS12053



Personally I would be in favor of introducing `DATABASE` as a synonym for
KEYSPACE. The latter could remain the "official" usage.

henrik


On Tue, Apr 4, 2023 at 8:32 PM Jacek Lewandowski <
lewandowski.ja...@gmail.com> wrote:

> While for someone who already knows Cassandra keyspace is something
> natural, for newcomers it is yet another concept to understand.
>
> If namespace is used in PostgreSQL, it sounds even better to me.
>
> Thanks,
> - - -- --- -  -
> Jacek Lewandowski
>
>
> wt., 4 kwi 2023 o 19:07 Rahul Xavier Singh 
> napisał(a):
>
>> My 2 cents:
>>
>> Keeping it keyspace works for me, namespace could be cool also since we
>> decide where that namespace exists in relation to Datacenters, etc.  In our
>> case, a Keyspace is more similar to a namespace than it is to a database
>> since we expect all the UDTs,/UDFs, indexes to refer to only the tables in
>> that keyspace/namespace.
>>
>> Alternatively interesting to observe and throw some fuel into the
>> discussion , looking at the Postgres (only because there are many
>> distributed databases that are now PG compliant) :
>> From the interwebs:
>> *In PostgreSQL, a schema is a namespace that contains named database
>> objects such as tables, views, indexes, data types, functions, stored
>> procedures and operators. A database can contain one or multiple schemas
>> and each schema belongs to only one database.*
>> I used to gripe about this but as a platform gets more complex it is
>> useful to organize PG DBs into schemas. In C* world, I found myself doing
>> similar things by having a prefix : e.g. appprefix_system1
>> appprefix_system2 ...
>>
>>
>> Rahul Singh
>>
>> Chief Executive Officer | Business Platform Architect m: 202.905.2818 e:
>> rahul.si...@anant.us li: http://linkedin.com/in/xingh
>> 
>> ca: http://calendly.com/xingh
>> 
>>
>> *We create, support, and manage real-time global data & analytics
>> platforms for the modern enterprise.*
>>
>> *Anant | https://anant.us
>> *
>>
>> 3 Washington Circle, Suite 301
>>
>> Washington, D.C. 20037
>>
>> *http://Cassandra.Link
>> *
>>  :
>> The best resources for Apache Cassandra
>>
>>
>> On Tue, Apr 4, 2023 at 12:52 PM Jeff Jirsa  wrote:
>>
>>> KEYSPACE at least makes sense in the context that it is the unit that
>>> defines how those partitions keys are going to be treated/replicated
>>>
>>> DATABASE may be ambiguous, but it's ambiguity shared across the
>>> industry.
>>>
>>> Creating a new name like TABLESPACE or TABLEGROUP sounds horrible
>>> because it'll be unique to us in the world, and therefore unintuitive for
>>> new users.
>>>
>>>
>>>

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Jacek Lewandowski]

While for someone who already knows Cassandra keyspace is something
natural, for newcomers it is yet another concept to understand.

If namespace is used in PostgreSQL, it sounds even better to me.

Thanks,
- - -- --- -  -
Jacek Lewandowski


wt., 4 kwi 2023 o 19:07 Rahul Xavier Singh 
napisał(a):

> My 2 cents:
>
> Keeping it keyspace works for me, namespace could be cool also since we
> decide where that namespace exists in relation to Datacenters, etc.  In our
> case, a Keyspace is more similar to a namespace than it is to a database
> since we expect all the UDTs,/UDFs, indexes to refer to only the tables in
> that keyspace/namespace.
>
> Alternatively interesting to observe and throw some fuel into the
> discussion , looking at the Postgres (only because there are many
> distributed databases that are now PG compliant) :
> From the interwebs:
> *In PostgreSQL, a schema is a namespace that contains named database
> objects such as tables, views, indexes, data types, functions, stored
> procedures and operators. A database can contain one or multiple schemas
> and each schema belongs to only one database.*
> I used to gripe about this but as a platform gets more complex it is
> useful to organize PG DBs into schemas. In C* world, I found myself doing
> similar things by having a prefix : e.g. appprefix_system1
> appprefix_system2 ...
>
>
> Rahul Singh
>
> Chief Executive Officer | Business Platform Architect m: 202.905.2818 e:
> rahul.si...@anant.us li: http://linkedin.com/in/xingh ca:
> http://calendly.com/xingh
>
> *We create, support, and manage real-time global data & analytics
> platforms for the modern enterprise.*
>
> *Anant | https://anant.us *
>
> 3 Washington Circle, Suite 301
>
> Washington, D.C. 20037
>
> *http://Cassandra.Link * : The best resources for
> Apache Cassandra
>
>
> On Tue, Apr 4, 2023 at 12:52 PM Jeff Jirsa  wrote:
>
>> KEYSPACE at least makes sense in the context that it is the unit that
>> defines how those partitions keys are going to be treated/replicated
>>
>> DATABASE may be ambiguous, but it's ambiguity shared across the industry.
>>
>> Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because
>> it'll be unique to us in the world, and therefore unintuitive for new users.
>>
>>
>>
>> On Tue, Apr 4, 2023 at 9:36 AM Josh McKenzie 
>> wrote:
>>
>>> I think there's competing dynamics here.
>>>
>>> 1) KEYSPACE isn't that great of a name; it's not a space in which keys
>>> are necessarily unique, and you can't address things just by key w/out
>>> their respective tables
>>> 2) DATABASE isn't that great of a name either due to the aforementioned
>>> ambiguity.
>>>
>>> Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically*
>>> better satisfy point 1 and 2 above but subjectively I kind of recoil at
>>> both equally. So there's that.
>>>
>>> On Tue, Apr 4, 2023, at 12:30 PM, Abe Ratnofsky wrote:
>>>
>>> I agree with Bowen - I find Keyspace easier to communicate with. There
>>> are plenty of situations where the use of "database" is ambiguous (like
>>> "Could you help me connect to database x?"), but Keyspace refers to a
>>> single thing. I think more software is moving towards calling these things
>>> "namespaces" (like Kubernetes), and while "Keyspaces" is not a term used in
>>> this way elsewhere, I still find it leads to clearer communication.
>>>
>>> --
>>> Abe
>>>
>>>
>>> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña 
>>> wrote:
>>>
>>> I think supporting DATABASE is a great idea.
>>>
>>> It's better aligned with SQL databases, and can save new users one of
>>> the first troubles they find.
>>>
>>> Probably anyone starting to use Cassandra for the first time is going to
>>> face the what is a keyspace? question in the first minutes. Saving that to
>>> users with a more common name would be a victory for usability IMO.
>>>
>>> On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:
>>>
>>> Hi,
>>>
>>> I'd like to propose that we add DATABASE to the CQL grammar as an
>>> alternative to KEYSPACE.
>>>
>>> Background: While TABLE was introduced as an alternative for
>>> COLUMNFAMILY in the grammar we have kept KEYSPACE for the container name
>>> for a group of tables. Nearly all traditional SQL databases use DATABASE as
>>> the container name for a group of tables so it would make sense for
>>> Cassandra to adopt this naming as well.
>>>
>>> KEYSPACE would be kept in the grammar but we would update some logging
>>> and documentation to encourage use of the new name.
>>>
>>> Mike Adamson
>>>
>>> --
>>> [image: DataStax Logo Square] 
>>> *Mike Adamson*
>>> Engineering
>>> +1 650 389 6000 <16503896000> | datastax.com 
>>> Find DataStax Online:
>>> [image: LinkedIn Logo]
>>> 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Rahul Xavier Singh]

My 2 cents:

Keeping it keyspace works for me, namespace could be cool also since we
decide where that namespace exists in relation to Datacenters, etc.  In our
case, a Keyspace is more similar to a namespace than it is to a database
since we expect all the UDTs,/UDFs, indexes to refer to only the tables in
that keyspace/namespace.

Alternatively interesting to observe and throw some fuel into the
discussion , looking at the Postgres (only because there are many
distributed databases that are now PG compliant) :
>From the interwebs:
*In PostgreSQL, a schema is a namespace that contains named database
objects such as tables, views, indexes, data types, functions, stored
procedures and operators. A database can contain one or multiple schemas
and each schema belongs to only one database.*
I used to gripe about this but as a platform gets more complex it is useful
to organize PG DBs into schemas. In C* world, I found myself doing similar
things by having a prefix : e.g. appprefix_system1 appprefix_system2 ...


Rahul Singh

Chief Executive Officer | Business Platform Architect m: 202.905.2818 e:
rahul.si...@anant.us li: http://linkedin.com/in/xingh ca:
http://calendly.com/xingh

*We create, support, and manage real-time global data & analytics platforms
for the modern enterprise.*

*Anant | https://anant.us *

3 Washington Circle, Suite 301

Washington, D.C. 20037

*http://Cassandra.Link * : The best resources for
Apache Cassandra


On Tue, Apr 4, 2023 at 12:52 PM Jeff Jirsa  wrote:

> KEYSPACE at least makes sense in the context that it is the unit that
> defines how those partitions keys are going to be treated/replicated
>
> DATABASE may be ambiguous, but it's ambiguity shared across the industry.
>
> Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because
> it'll be unique to us in the world, and therefore unintuitive for new users.
>
>
>
> On Tue, Apr 4, 2023 at 9:36 AM Josh McKenzie  wrote:
>
>> I think there's competing dynamics here.
>>
>> 1) KEYSPACE isn't that great of a name; it's not a space in which keys
>> are necessarily unique, and you can't address things just by key w/out
>> their respective tables
>> 2) DATABASE isn't that great of a name either due to the aforementioned
>> ambiguity.
>>
>> Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically* better
>> satisfy point 1 and 2 above but subjectively I kind of recoil at both
>> equally. So there's that.
>>
>> On Tue, Apr 4, 2023, at 12:30 PM, Abe Ratnofsky wrote:
>>
>> I agree with Bowen - I find Keyspace easier to communicate with. There
>> are plenty of situations where the use of "database" is ambiguous (like
>> "Could you help me connect to database x?"), but Keyspace refers to a
>> single thing. I think more software is moving towards calling these things
>> "namespaces" (like Kubernetes), and while "Keyspaces" is not a term used in
>> this way elsewhere, I still find it leads to clearer communication.
>>
>> --
>> Abe
>>
>>
>> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña 
>> wrote:
>>
>> I think supporting DATABASE is a great idea.
>>
>> It's better aligned with SQL databases, and can save new users one of the
>> first troubles they find.
>>
>> Probably anyone starting to use Cassandra for the first time is going to
>> face the what is a keyspace? question in the first minutes. Saving that to
>> users with a more common name would be a victory for usability IMO.
>>
>> On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:
>>
>> Hi,
>>
>> I'd like to propose that we add DATABASE to the CQL grammar as an
>> alternative to KEYSPACE.
>>
>> Background: While TABLE was introduced as an alternative for COLUMNFAMILY
>> in the grammar we have kept KEYSPACE for the container name for a group of
>> tables. Nearly all traditional SQL databases use DATABASE as the container
>> name for a group of tables so it would make sense for Cassandra to adopt
>> this naming as well.
>>
>> KEYSPACE would be kept in the grammar but we would update some logging
>> and documentation to encourage use of the new name.
>>
>> Mike Adamson
>>
>> --
>> [image: DataStax Logo Square] 
>> *Mike Adamson*
>> Engineering
>> +1 650 389 6000 <16503896000> | datastax.com 
>> Find DataStax Online:
>> [image: LinkedIn Logo]
>> 
>>[image: Facebook Logo]
>> 
>>[image: Twitter Logo]    [image: RSS
>> Feed] 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Jeff Jirsa]

KEYSPACE at least makes sense in the context that it is the unit that
defines how those partitions keys are going to be treated/replicated

DATABASE may be ambiguous, but it's ambiguity shared across the industry.

Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because
it'll be unique to us in the world, and therefore unintuitive for new users.



On Tue, Apr 4, 2023 at 9:36 AM Josh McKenzie  wrote:

> I think there's competing dynamics here.
>
> 1) KEYSPACE isn't that great of a name; it's not a space in which keys are
> necessarily unique, and you can't address things just by key w/out their
> respective tables
> 2) DATABASE isn't that great of a name either due to the aforementioned
> ambiguity.
>
> Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically* better
> satisfy point 1 and 2 above but subjectively I kind of recoil at both
> equally. So there's that.
>
> On Tue, Apr 4, 2023, at 12:30 PM, Abe Ratnofsky wrote:
>
> I agree with Bowen - I find Keyspace easier to communicate with. There are
> plenty of situations where the use of "database" is ambiguous (like "Could
> you help me connect to database x?"), but Keyspace refers to a single
> thing. I think more software is moving towards calling these things
> "namespaces" (like Kubernetes), and while "Keyspaces" is not a term used in
> this way elsewhere, I still find it leads to clearer communication.
>
> --
> Abe
>
>
> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña 
> wrote:
>
> I think supporting DATABASE is a great idea.
>
> It's better aligned with SQL databases, and can save new users one of the
> first troubles they find.
>
> Probably anyone starting to use Cassandra for the first time is going to
> face the what is a keyspace? question in the first minutes. Saving that to
> users with a more common name would be a victory for usability IMO.
>
> On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:
>
> Hi,
>
> I'd like to propose that we add DATABASE to the CQL grammar as an
> alternative to KEYSPACE.
>
> Background: While TABLE was introduced as an alternative for COLUMNFAMILY
> in the grammar we have kept KEYSPACE for the container name for a group of
> tables. Nearly all traditional SQL databases use DATABASE as the container
> name for a group of tables so it would make sense for Cassandra to adopt
> this naming as well.
>
> KEYSPACE would be kept in the grammar but we would update some logging and
> documentation to encourage use of the new name.
>
> Mike Adamson
>
> --
> [image: DataStax Logo Square] 
> *Mike Adamson*
> Engineering
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online:
> [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS
> Feed]    [image: Github Logo]
> 
>
>
>

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Josh McKenzie]

I think there's competing dynamics here.

1) KEYSPACE isn't that great of a name; it's not a space in which keys are 
necessarily unique, and you can't address things just by key w/out their 
respective tables
2) DATABASE isn't that great of a name either due to the aforementioned 
ambiguity.

Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically* better 
satisfy point 1 and 2 above but subjectively I kind of recoil at both equally. 
So there's that.

On Tue, Apr 4, 2023, at 12:30 PM, Abe Ratnofsky wrote:
> I agree with Bowen - I find Keyspace easier to communicate with. There are 
> plenty of situations where the use of "database" is ambiguous (like "Could 
> you help me connect to database x?"), but Keyspace refers to a single thing. 
> I think more software is moving towards calling these things "namespaces" 
> (like Kubernetes), and while "Keyspaces" is not a term used in this way 
> elsewhere, I still find it leads to clearer communication.
> 
> --
> Abe
> 
> 
>> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña  wrote:
>> 
>> I think supporting DATABASE is a great idea. 
>> 
>> It's better aligned with SQL databases, and can save new users one of the 
>> first troubles they find. 
>> 
>> Probably anyone starting to use Cassandra for the first time is going to 
>> face the what is a keyspace? question in the first minutes. Saving that to 
>> users with a more common name would be a victory for usability IMO.
>> 
>> On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:
>>> Hi,
>>> 
>>> I'd like to propose that we add DATABASE to the CQL grammar as an 
>>> alternative to KEYSPACE. 
>>> 
>>> Background: While TABLE was introduced as an alternative for COLUMNFAMILY 
>>> in the grammar we have kept KEYSPACE for the container name for a group of 
>>> tables. Nearly all traditional SQL databases use DATABASE as the container 
>>> name for a group of tables so it would make sense for Cassandra to adopt 
>>> this naming as well.
>>> 
>>> KEYSPACE would be kept in the grammar but we would update some logging and 
>>> documentation to encourage use of the new name. 
>>> 
>>> Mike Adamson
>>> 
>>> --
>>> DataStax Logo Square 
>>> *Mike Adamson*
>>> Engineering
>>> +1 650 389 6000  | datastax.com 
>>> Find DataStax Online:
>>> LinkedIn Logo 
>>> 
>>>Facebook Logo 
>>> 
>>>Twitter Logo    RSS Feed 
>>>    Github Logo 
>>> 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Abe Ratnofsky]

I agree with Bowen - I find Keyspace easier to communicate with. There are 
plenty of situations where the use of "database" is ambiguous (like "Could you 
help me connect to database x?"), but Keyspace refers to a single thing. I 
think more software is moving towards calling these things "namespaces" (like 
Kubernetes), and while "Keyspaces" is not a term used in this way elsewhere, I 
still find it leads to clearer communication.

--
Abe


> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña  wrote:
> 
> I think supporting DATABASE is a great idea. 
> 
> It's better aligned with SQL databases, and can save new users one of the 
> first troubles they find. 
> 
> Probably anyone starting to use Cassandra for the first time is going to face 
> the what is a keyspace? question in the first minutes. Saving that to users 
> with a more common name would be a victory for usability IMO.
> 
> On Tue, 4 Apr 2023 at 16:48, Mike Adamson  > wrote:
>> Hi,
>> 
>> I'd like to propose that we add DATABASE to the CQL grammar as an 
>> alternative to KEYSPACE. 
>> 
>> Background: While TABLE was introduced as an alternative for COLUMNFAMILY in 
>> the grammar we have kept KEYSPACE for the container name for a group of 
>> tables. Nearly all traditional SQL databases use DATABASE as the container 
>> name for a group of tables so it would make sense for Cassandra to adopt 
>> this naming as well.
>> 
>> KEYSPACE would be kept in the grammar but we would update some logging and 
>> documentation to encourage use of the new name. 
>> 
>> Mike Adamson
>> 
>> -- 
>>   Mike Adamson
>> Engineering
>> 
>> +1 650 389 6000  | datastax.com 
>> Find DataStax Online: 
>> 
>> 
>> 
>> 
>> 
>> 

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Andrés de la Peña]

I think supporting DATABASE is a great idea.

It's better aligned with SQL databases, and can save new users one of the
first troubles they find.

Probably anyone starting to use Cassandra for the first time is going to
face the what is a keyspace? question in the first minutes. Saving that to
users with a more common name would be a victory for usability IMO.

On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:

> Hi,
>
> I'd like to propose that we add DATABASE to the CQL grammar as an
> alternative to KEYSPACE.
>
> Background: While TABLE was introduced as an alternative for COLUMNFAMILY
> in the grammar we have kept KEYSPACE for the container name for a group of
> tables. Nearly all traditional SQL databases use DATABASE as the container
> name for a group of tables so it would make sense for Cassandra to adopt
> this naming as well.
>
> KEYSPACE would be kept in the grammar but we would update some logging and
> documentation to encourage use of the new name.
>
> Mike Adamson
>
> --
> [image: DataStax Logo Square]  *Mike Adamson*
> Engineering
>
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online: [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS
> Feed]    [image: Github Logo]
> 
>
>

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

[Bowen Song via dev]

I personally prefer to use the name "keyspace", because it avoids the 
confusion between the "database software/server" and the "collection of 
tables in a database". "An SQL database" can mean different things in 
different contexts, but "a Cassandra keyspace" always mean the same thing.


On 04/04/2023 16:48, Mike Adamson wrote:

Hi,

I'd like to propose that we add DATABASE to the CQL grammar as an 
alternative to KEYSPACE.


Background: While TABLE was introduced as an alternative for 
COLUMNFAMILY in the grammar we have kept KEYSPACE for the container 
name for a group of tables. Nearly all traditional SQL databases use 
DATABASE as the container name for a group of tables so it would make 
sense for Cassandra to adopt this naming as well.


KEYSPACE would be kept in the grammar but we would update some logging 
and documentation to encourage use of the new name.


Mike Adamson

--
DataStax Logo Square   *Mike Adamson*
Engineering

+1 650 389 6000 |datastax.com 



Find DataStax Online: 	LinkedIn Logo 
 
Facebook Logo 
 
Twitter Logo  RSS Feed 
 Github Logo