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 !
