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 <https://anant.us/>* 3 Washington Circle, Suite 301 Washington, D.C. 20037 *http://Cassandra.Link <http://cassandra.link/>* : The best resources for Apache Cassandra On Tue, Apr 4, 2023 at 12:52 PM Jeff Jirsa <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> 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> >> 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> 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] <https://www.datastax.com/> >> *Mike Adamson* >> Engineering >> +1 650 389 6000 <16503896000> | datastax.com <https://www.datastax.com/> >> Find DataStax Online: >> [image: 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=> >> [image: 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=> >> [image: Twitter Logo] <https://twitter.com/DataStax> [image: RSS >> Feed] <https://www.datastax.com/blog/rss.xml> [image: Github Logo] >> <https://github.com/datastax> >> >> >>
