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 <lewandowski.ja...@gmail.com> 于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 <name>; > > thanks, > - - -- --- ----- -------- ------------- > Jacek Lewandowski > > > czw., 6 kwi 2023 o 04:09 guo Maxwell <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> 于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> >>> 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> 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> 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> 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 >>>>> <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> 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> >>>>>>> >>>>>>> >>>>>>> >>> >>> -- >>> >>> Henrik Ingo >>> >>> c. +358 40 569 7354 >>> >>> w. www.datastax.com >>> <https://www.facebook.com/datastax> <https://twitter.com/datastax> >>> <https://www.linkedin.com/company/datastax/> >>> <https://github.com/datastax/> >>> >>> >>> >> >> -- >> you are the apple of my eye ! >> > -- you are the apple of my eye !
