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 <berenguerbl...@gmail.com> 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 <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 !
