> > 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 <stefan.mikloso...@netapp.com> 于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 <berenguerbl...@gmail.com> > 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 <lewandowski.ja...@gmail.com> > > 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 <name>; > > > > thanks, > > - - -- --- ----- -------- ------------- > > Jacek Lewandowski > > > > > > czw., 6 kwi 2023 o 04:09 guo Maxwell <cclive1...@gmail.com<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 <calebrackli...@gmail.com<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 <alek...@apple.com > <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 <henrik.i...@datastax.com<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&tabs=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<mailto: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 <rahul.xavier.si...@gmail.com > <mailto:rahul.xavier.si...@gmail.com>> 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<mailto:rahul.si...@anant.us> li: > http://linkedin.com/in/xingh< > https://urldefense.com/v3/__http://linkedin.com/in/xingh__;!!PbtH5S7Ebw!afY0-NqkBo2VBXvYyGP5lw6NYraugbMkyajfgaclPqGA_RwsPArxv94zXqkLosh3gEPQic8gVFLDnqRH_j86oWy7IviuNA$> > ca: http://calendly.com/xingh< > https://urldefense.com/v3/__http://calendly.com/xingh__;!!PbtH5S7Ebw!afY0-NqkBo2VBXvYyGP5lw6NYraugbMkyajfgaclPqGA_RwsPArxv94zXqkLosh3gEPQic8gVFLDnqRH_j86oWwrKOuxdg$ > > > > > > We create, support, and manage real-time global data & analytics > platforms for the modern enterprise. > > > > Anant | https://anant.us< > https://urldefense.com/v3/__https://anant.us/__;!!PbtH5S7Ebw!afY0-NqkBo2VBXvYyGP5lw6NYraugbMkyajfgaclPqGA_RwsPArxv94zXqkLosh3gEPQic8gVFLDnqRH_j86oWy4zsWIsA$ > > > > 3 Washington Circle, Suite 301 > > Washington, D.C. 20037 > > > > http://Cassandra.Link< > https://urldefense.com/v3/__http://cassandra.link/__;!!PbtH5S7Ebw!afY0-NqkBo2VBXvYyGP5lw6NYraugbMkyajfgaclPqGA_RwsPArxv94zXqkLosh3gEPQic8gVFLDnqRH_j86oWxYYQnYHg$> > : The best resources for Apache Cassandra > > > > > > On Tue, Apr 4, 2023 at 12:52 PM Jeff Jirsa <jji...@gmail.com<mailto: > jji...@gmail.com>> 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 <jmcken...@apache.org > <mailto:jmcken...@apache.org>> 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 <adelap...@apache.org > <mailto:adelap...@apache.org>> 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 <madam...@datastax.com<mailto: > madam...@datastax.com>> 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]<https://www.datastax.com/> > > Mike Adamson > > Engineering > > +1 650 389 6000<tel:16503896000> | datastax.com< > https://www.datastax.com/> > > Find DataStax Online: > > [LinkedIn Logo]< > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=akx0E6l2bnTjOvA-YxtonbW0M4b6bNg4nRwmcHNDo4Q&e=> > [Facebook Logo] < > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=ncMlB41-6hHuqx-EhnM83-KVtjMegQ9c2l2zDzHAxiU&e=> > [Twitter Logo] <https://twitter.com/DataStax> [RSS Feed] < > https://www.datastax.com/blog/rss.xml> [Github Logo] < > https://github.com/datastax> > > > > > > > > -- > > > > [ > https://lh5.googleusercontent.com/UwlCp-Ixn21QzYv9oNnaGy0cKfFk1ukEBVKSv4V3-nQShsR-cib_VeSuNm4M_xZxyAzTTr0Et7MsQuTDhUGcmWQyfVP801Flif-SGT2x38lFRGkgoMUB4cot1DB9xd7Y0x2P0wJWA-gQ5k4rzytFSoLCP4wJntmJzhlqTuQQsOanCBHeejtSBcBry5v6kw > ] > > > > Henrik Ingo > > > > c. +358 40 569 7354 > > > > w. www.datastax.com<http://www.datastax.com/> > > > > [ > https://lh3.googleusercontent.com/T6MEp9neZySKd-eg-tkz96Yf4qG_Xsgu-IznDkdHfsHCjAnnHQP6OsPCdj8rsDvgKs-GJS6TA7Yx5HlK-zfRlE64j0zDpDG9cI29VaG948x5xLgUU4KKctaHNAhbpJ_pDwzRag9K7yCibGblB5Ix5z6Xj99Vc92V9nYSmR4HIj5F9T_TVI7ayW2n2_lp5Q > ]<https://www.facebook.com/datastax> [ > https://lh3.googleusercontent.com/Xrju2UthJiMtMS5jFknV8AhVO45tfhXSR6U0F8Qam1Mu2taE2SeVcl5ExaxU5l6pG0fHjv2b6vvUOe12WQldMqsOHknC7wQtBVYiX9ff3fLMtFAbjVRM0MGTKvPsjAcMI_FNvcIcuWIBP_zwRuh3b3g6hjHOW0ik9bDPuuYMvdLWIF8C8YgKDYQ-nV9dlQ] > <https://twitter.com/datastax> [ > https://lh5.googleusercontent.com/OS41kMrzmJhmkvdmkHU-pq69Nzy1tOz36NIwGs61oz9cGj42TTggsXk58MY1Lqn5FyIK77jedKh3UN-1RMCgCqduMQeUNU5fVKjCBNvSOpp6NjBLZp-2NMypQnw7JoyPoeI_iXfygfzquE89GLoel7Tiq1Jtz6ueaaVA9goEhUn2rWIJMQ28DPrEj4xqfg] > <https://www.linkedin.com/company/datastax/> [ > https://lh3.googleusercontent.com/AVBOsupbzcVirw6fNWEIerGj-CT9XuzDmGpAa5KimxCLGAICw7_TV040RngH0I_0Z9ZEWERsQOiCSqD4ORslxJdqFiuFc1qgIoA9QMXW_yRklRJrrrCO0rQ47Hvt9QtfAz7swR_Vn6N8wZPYE2APUJAo-oB_X71omearuZFBjL9VKbhbrZXn9HQ7aGSxIA] > <https://github.com/datastax/> > > > > > > > > > > -- > > you are the apple of my eye ! > -- you are the apple of my eye !
