mirror of https://github.com/apache/cassandra
Reorganizing doc directories using new info arch
patch by Lorina Poland; reviewed by Mick Semb Wever, Štefan Miklošovič for CASSANDRA-18228
This commit is contained in:
Lorina Poland
Mick Semb Wever
parent
63ab8e0928
commit
998a98eae8
2
NEWS.txt
2
NEWS.txt
|
|
@ -667,7 +667,7 @@ Upgrading
|
|||
the node will not start. See CASSANDRA-14477 for details.
|
||||
- CASSANDRA-13701 To give a better out of the box experience, the default 'num_tokens'
|
||||
value has been changed from 256 to 16 for reasons described in
|
||||
https://cassandra.apache.org/doc/latest/getting_started/production.html#tokens
|
||||
https://cassandra.apache.org/doc/latest/getting-started/production.html#tokens
|
||||
'allocate_tokens_for_local_replication_factor' is also uncommented and set to 3.
|
||||
Please note when upgrading that if the 'num_tokens' value is different than what you have
|
||||
configured, the upgraded node will refuse to start. Also note that if a new node joining
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Getting started
|
|||
---------------
|
||||
|
||||
This short guide will walk you through getting a basic one node cluster up
|
||||
and running, and demonstrate some simple reads and writes. For a more-complete guide, please see the Apache Cassandra website's http://cassandra.apache.org/doc/latest/getting_started/[Getting Started Guide].
|
||||
and running, and demonstrate some simple reads and writes. For a more-complete guide, please see the Apache Cassandra website's http://cassandra.apache.org/doc/latest/getting-started/[Getting Started Guide].
|
||||
|
||||
First, we'll unpack our archive:
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ cluster_name: 'Test Cluster'
|
|||
# Specifying initial_token will override this setting on the node's initial start,
|
||||
# on subsequent starts, this setting will apply even if initial token is set.
|
||||
#
|
||||
# See https://cassandra.apache.org/doc/latest/getting_started/production.html#tokens for
|
||||
# See https://cassandra.apache.org/doc/latest/getting-started/production.html#tokens for
|
||||
# best practice information about num_tokens.
|
||||
#
|
||||
num_tokens: 16
|
||||
|
|
|
|||
|
|
@ -15,27 +15,27 @@ to do so by submitting your contribution like any other patch following
|
|||
[cols="a,a"]
|
||||
|===
|
||||
|
||||
| xref:cassandra:getting_started/index.adoc[Getting started] | Newbie starting point
|
||||
| xref:cassandra:getting-started/index.adoc[Getting started] | Newbie starting point
|
||||
|
||||
| xref:cassandra:new/index.adoc[What's new in 5.0] | What's new in Cassandra 5.0
|
||||
|
||||
| xref:cassandra:architecture/index.adoc[Architecture] | Cassandra's big picture
|
||||
|
||||
| xref:cassandra:data_modeling/index.adoc[Data modeling] | Hint: it's not relational
|
||||
| xref:cassandra:developing/data-modeling/index.adoc[Data modeling] | Hint: it's not relational
|
||||
|
||||
| xref:cassandra:cql/index.adoc[Cassandra Query Language (CQL)] | CQL reference documentation
|
||||
| xref:cassandra:developing/cql/index.adoc[Cassandra Query Language (CQL)] | CQL reference documentation
|
||||
|
||||
| xref:cassandra:configuration/index.adoc[Configuration] | Cassandra's handles and knobs
|
||||
| xref:cassandra:getting-started/configuration/index.adoc[Configuration] | Cassandra's handles and knobs
|
||||
|
||||
| xref:cassandra:operating/index.adoc[Operation] | The operator's corner
|
||||
| xref:cassandra:managing/operating/index.adoc[Operation] | The operator's corner
|
||||
|
||||
| xref:cassandra:tools/index.adoc[Tools] | cqlsh, nodetool, and others
|
||||
| xref:cassandra:managing/tools/index.adoc[Tools] | cqlsh, nodetool, and others
|
||||
|
||||
| xref:cassandra:troubleshooting/index.adoc[Troubleshooting] | What to look for when you have a problem
|
||||
|
||||
| xref:cassandra:faq/index.adoc[FAQ] | Frequently asked questions
|
||||
| xref:cassandra:overview/faq/index.adoc[FAQ] | Frequently asked questions
|
||||
|
||||
| xref:cassandra:plugins/index.adoc[Plug-ins] | Third-party plug-ins
|
||||
| xref:cassandra:integrating/plugins/index.adoc[Plug-ins] | Third-party plug-ins
|
||||
|
||||
| xref:master@_:ROOT:native_protocol.adoc[Native Protocols] | Native Cassandra protocol specifications
|
||||
|
||||
|
|
|
|||
|
|
@ -1,87 +1,86 @@
|
|||
* Cassandra
|
||||
** xref:getting_started/index.adoc[Getting Started]
|
||||
*** xref:getting_started/installing.adoc[Installing Cassandra]
|
||||
*** xref:getting_started/configuring.adoc[Configuring Cassandra]
|
||||
*** xref:getting_started/querying.adoc[Inserting and querying]
|
||||
*** xref:getting_started/drivers.adoc[Client drivers]
|
||||
*** xref:getting_started/java11.adoc[Support for Java 11]
|
||||
*** xref:getting_started/production.adoc[Production recommendations]
|
||||
** xref:getting-started/index.adoc[Getting Started]
|
||||
*** xref:installing/installing.adoc[Installing Cassandra]
|
||||
*** xref:getting-started/configuring.adoc[Configuring Cassandra]
|
||||
*** xref:getting-started/querying.adoc[Inserting and querying]
|
||||
*** xref:getting-started/drivers.adoc[Client drivers]
|
||||
*** xref:getting-started/java11.adoc[Support for Java 11]
|
||||
*** xref:getting-started/production.adoc[Production recommendations]
|
||||
|
||||
** xref:new/index.adoc[What's new]
|
||||
|
||||
** xref:architecture/index.adoc[Architecture]
|
||||
*** xref:architecture/overview.adoc[Overview]
|
||||
*** xref:architecture/dynamo.adoc[Dynamo]
|
||||
*** xref:architecture/storage_engine.adoc[Storage engine]
|
||||
*** xref:architecture/storage-engine.adoc[Storage engine]
|
||||
*** xref:architecture/guarantees.adoc[Guarantees]
|
||||
*** xref:architecture/messaging.adoc[Improved internode messaging]
|
||||
*** xref:architecture/streaming.adoc[Improved streaming]
|
||||
|
||||
** xref:data_modeling/index.adoc[Data modeling]
|
||||
*** xref:data_modeling/intro.adoc[Introduction]
|
||||
*** xref:data_modeling/data_modeling_conceptual.adoc[Conceptual data modeling]
|
||||
*** xref:data_modeling/data_modeling_rdbms.adoc[RDBMS design]
|
||||
*** xref:data_modeling/data_modeling_queries.adoc[Defining application queries]
|
||||
*** xref:data_modeling/data_modeling_logical.adoc[Logical data modeling]
|
||||
*** xref:data_modeling/data_modeling_physical.adoc[Physical data modeling]
|
||||
*** xref:data_modeling/data_modeling_refining.adoc[Evaluating and refining data models]
|
||||
*** xref:data_modeling/data_modeling_schema.adoc[Defining database schema]
|
||||
*** xref:data_modeling/data_modeling_tools.adoc[Cassandra data modeling tools]
|
||||
** xref:developing:data-modeling/index.adoc[Data modeling]
|
||||
*** xref:developing:data-modeling/intro.adoc[Introduction]
|
||||
*** xref:developing:data-modeling/data-modeling_conceptual.adoc[Conceptual data modeling]
|
||||
*** xref:developing:data-modeling/data-modeling_rdbms.adoc[RDBMS design]
|
||||
*** xref:developing:data-modeling/data-modeling_queries.adoc[Defining application queries]
|
||||
*** xref:developing:data-modeling/data-modeling_logical.adoc[Logical data modeling]
|
||||
*** xref:developing:data-modeling/data-modeling_physical.adoc[Physical data modeling]
|
||||
*** xref:developing:data-modeling/data-modeling_refining.adoc[Evaluating and refining data models]
|
||||
*** xref:developing:data-modeling/data-modeling_schema.adoc[Defining database schema]
|
||||
*** xref:developing:data-modeling/data-modeling_tools.adoc[Cassandra data modeling tools]
|
||||
|
||||
** xref:cql/index.adoc[Cassandra Query Language (CQL)]
|
||||
*** xref:cql/definitions.adoc[Definitions]
|
||||
*** xref:cql/types.adoc[Data types]
|
||||
*** xref:cql/ddl.adoc[Data definition (DDL)]
|
||||
*** xref:cql/dml.adoc[Data manipulation (DML)]
|
||||
*** xref:cql/operators.adoc[Operators]
|
||||
*** xref:cql/indexes.adoc[Secondary indexes]
|
||||
*** xref:cql/mvs.adoc[Materialized views]
|
||||
*** xref:cql/functions.adoc[Functions]
|
||||
*** xref:cql/json.adoc[JSON]
|
||||
*** xref:cql/security.adoc[Security]
|
||||
*** xref:cql/dynamic_data_masking.adoc[Dynamic data masking]
|
||||
*** xref:cql/triggers.adoc[Triggers]
|
||||
*** xref:cql/appendices.adoc[Appendices]
|
||||
*** xref:cql/changes.adoc[Changes]
|
||||
*** xref:cql/SASI.adoc[SASI]
|
||||
*** xref:cql/cql_singlefile.adoc[Single file of CQL information]
|
||||
** xref:developing:cql/index.adoc[Cassandra Query Language (CQL)]
|
||||
*** xref:developing:cql/definitions.adoc[Definitions]
|
||||
*** xref:developing:cql/types.adoc[Data types]
|
||||
*** xref:developing:cql/ddl.adoc[Data definition (DDL)]
|
||||
*** xref:developing:cql/dml.adoc[Data manipulation (DML)]
|
||||
*** xref:developing:cql/operators.adoc[Operators]
|
||||
*** xref:developing:cql/indexes.adoc[Secondary indexes]
|
||||
*** xref:developing:cql/mvs.adoc[Materialized views]
|
||||
*** xref:developing:cql/functions.adoc[Functions]
|
||||
*** xref:developing:cql/json.adoc[JSON]
|
||||
*** xref:developing:cql/security.adoc[Security]
|
||||
*** xref:developing:cql/triggers.adoc[Triggers]
|
||||
*** xref:developing:cql/appendices.adoc[Appendices]
|
||||
*** xref:developing:cql/changes.adoc[Changes]
|
||||
*** xref:developing:cql/SASI.adoc[SASI]
|
||||
*** xref:developing:cql/cql_singlefile.adoc[Single file of CQL information]
|
||||
|
||||
** xref:configuration/index.adoc[Configuration]
|
||||
*** xref:configuration/cass_yaml_file.adoc[cassandra.yaml]
|
||||
*** xref:configuration/cass_rackdc_file.adoc[cassandra-rackdc.properties]
|
||||
*** xref:configuration/cass_env_sh_file.adoc[cassandra-env.sh]
|
||||
*** xref:configuration/cass_topo_file.adoc[cassandra-topologies.properties]
|
||||
*** xref:configuration/cass_cl_archive_file.adoc[commitlog-archiving.properties]
|
||||
*** xref:configuration/cass_logback_xml_file.adoc[logback.xml]
|
||||
*** xref:configuration/cass_jvm_options_file.adoc[jvm-* files]
|
||||
*** xref:configuration/configuration.adoc[Liberating cassandra.yaml Parameters' Names from Their Units]
|
||||
** xref:managing:configuration/index.adoc[Configuration]
|
||||
*** xref:managing:configuration/cass_yaml_file.adoc[cassandra.yaml]
|
||||
*** xref:managing:configuration/cass_rackdc_file.adoc[cassandra-rackdc.properties]
|
||||
*** xref:managing:configuration/cass_env_sh_file.adoc[cassandra-env.sh]
|
||||
*** xref:managing:configuration/cass_topo_file.adoc[cassandra-topologies.properties]
|
||||
*** xref:managing:configuration/cass_cl_archive_file.adoc[commitlog-archiving.properties]
|
||||
*** xref:managing:configuration/cass_logback_xml_file.adoc[logback.xml]
|
||||
*** xref:managing:configuration/cass_jvm_options_file.adoc[jvm-* files]
|
||||
*** xref:managing:configuration/configuration.adoc[Liberating cassandra.yaml Parameters' Names from Their Units]
|
||||
|
||||
** xref:operating/index.adoc[Operating]
|
||||
*** xref:operating/snitch.adoc[Snitches]
|
||||
*** xref:operating/topo_changes.adoc[Topology changes]
|
||||
*** xref:operating/repair.adoc[Repair]
|
||||
*** xref:operating/read_repair.adoc[Read repair]
|
||||
*** xref:operating/hints.adoc[Hints]
|
||||
*** xref:operating/bloom_filters.adoc[Bloom filters]
|
||||
*** xref:operating/compression.adoc[Compression]
|
||||
*** xref:operating/cdc.adoc[Change Data Capture (CDC)]
|
||||
*** xref:operating/backups.adoc[Backups]
|
||||
*** xref:operating/bulk_loading.adoc[Bulk loading]
|
||||
*** xref:operating/metrics.adoc[Metrics]
|
||||
*** xref:operating/security.adoc[Security]
|
||||
*** xref:operating/hardware.adoc[Hardware]
|
||||
*** xref:operating/compaction/index.adoc[Compaction]
|
||||
*** xref:operating/virtualtables.adoc[Virtual tables]
|
||||
*** xref:operating/auditlogging.adoc[Audit logging]
|
||||
*** xref:operating/audit_logging.adoc[Audit logging 2]
|
||||
*** xref:operating/fqllogging.adoc[Full query logging]
|
||||
*** xref:operating/transientreplication.adoc[Transient replication]
|
||||
** xref:managing:operating/index.adoc[Operating]
|
||||
*** xref:managing:operating/snitch.adoc[Snitches]
|
||||
*** xref:managing:operating/topo_changes.adoc[Topology changes]
|
||||
*** xref:managing:operating/repair.adoc[Repair]
|
||||
*** xref:managing:operating/read_repair.adoc[Read repair]
|
||||
*** xref:managing:operating/hints.adoc[Hints]
|
||||
*** xref:managing:operating/bloom_filters.adoc[Bloom filters]
|
||||
*** xref:managing:operating/compression.adoc[Compression]
|
||||
*** xref:managing:operating/cdc.adoc[Change Data Capture (CDC)]
|
||||
*** xref:managing:operating/backups.adoc[Backups]
|
||||
*** xref:managing:operating/bulk_loading.adoc[Bulk loading]
|
||||
*** xref:managing:operating/metrics.adoc[Metrics]
|
||||
*** xref:managing:operating/security.adoc[Security]
|
||||
*** xref:managing:operating/hardware.adoc[Hardware]
|
||||
*** xref:managing:operating/compaction/index.adoc[Compaction]
|
||||
*** xref:managing:operating/virtualtables.adoc[Virtual tables]
|
||||
*** xref:managing:operating/auditlogging.adoc[Audit logging]
|
||||
*** xref:managing:operating/audit_logging.adoc[Audit logging 2]
|
||||
*** xref:managing:operating/fqllogging.adoc[Full query logging]
|
||||
*** xref:managing:operating/transientreplication.adoc[Transient replication]
|
||||
|
||||
** xref:tools/index.adoc[Tools]
|
||||
*** xref:tools/cqlsh.adoc[cqlsh: the CQL shell]
|
||||
*** xref:tools/nodetool/nodetool.adoc[nodetool]
|
||||
*** xref:tools/sstable/index.adoc[SSTable tools]
|
||||
*** xref:tools/cassandra_stress.adoc[cassandra-stress]
|
||||
** xref:managing:tools/index.adoc[Tools]
|
||||
*** xref:managing:tools/cqlsh.adoc[cqlsh: the CQL shell]
|
||||
*** xref:managing:tools/nodetool/nodetool.adoc[nodetool]
|
||||
*** xref:managing:tools/sstable/index.adoc[SSTable tools]
|
||||
*** xref:managing:tools/cassandra_stress.adoc[cassandra-stress]
|
||||
|
||||
** xref:troubleshooting/index.adoc[Troubleshooting]
|
||||
*** xref:troubleshooting/finding_nodes.adoc[Finding misbehaving nodes]
|
||||
|
|
@ -102,7 +101,7 @@
|
|||
*** xref:master@_:ROOT:development/dependencies.adoc[Dependency management]
|
||||
*** xref:master@_:ROOT:development/release_process.adoc[Release process]
|
||||
|
||||
** xref:faq/index.adoc[FAQ]
|
||||
** xref:overview:faq/index.adoc[FAQ]
|
||||
|
||||
** xref:plugins/index.adoc[Plug-ins]
|
||||
** xref:integrating:plugins/index.adoc[Plug-ins]
|
||||
|
||||
|
|
|
|||
|
|
@ -4,6 +4,6 @@ This section describes the general architecture of Apache Cassandra.
|
|||
|
||||
* xref:architecture/overview.adoc[Overview]
|
||||
* xref:architecture/dynamo.adoc[Dynamo]
|
||||
* xref:architecture/storage_engine.adoc[Storage Engine]
|
||||
* xref:architecture/storage-engine.adoc[Storage Engine]
|
||||
* xref:architecture/guarantees.adoc[Guarantees]
|
||||
* xref:architecture/snitch.adoc[Snitches]
|
||||
|
|
|
|||
|
|
@ -1,178 +0,0 @@
|
|||
= Dynamic Data Masking
|
||||
|
||||
Dynamic data masking (DDM) allows to obscure sensitive information while still allowing access to the masked columns.
|
||||
DDM doesn't change the stored data. Instead, it just presents the data on their obscured form during `SELECT` queries.
|
||||
This aims to provide some degree of protection against accidental data exposure. However, it's important to know that
|
||||
anyone with direct access to the sstable files will be able to read the clear data.
|
||||
|
||||
== Masking functions
|
||||
|
||||
DDM is based on a set of CQL native functions that obscure sensitive information. The available functions are:
|
||||
|
||||
include::partial$masking_functions.adoc[]
|
||||
|
||||
Those functions can be discretionarily used on `SELECT` queries to get an obscured view of the data. For example:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/select_with_mask_functions.cql[]
|
||||
----
|
||||
|
||||
== Attaching masking functions to table columns
|
||||
|
||||
The masking functions can be permanently attached to the columns of a table.
|
||||
In that case, `SELECT` queries will always return the column values in their masked form.
|
||||
The masking will be transparent for the users running `SELECT` queries,
|
||||
so their only way to know that a column is masked will be consulting the table definition.
|
||||
|
||||
This is an optional feature that should be enabled with the `dynamic_data_masking_enabled` property in `cassandra.yaml`,
|
||||
since it's disabled by default.
|
||||
|
||||
The masks of the columns of a table can be defined on `CREATE TABLE` queries:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_create_table.cql[]
|
||||
----
|
||||
|
||||
Note that in the example above we are referencing the `mask_inner` function with two arguments.
|
||||
However, that CQL function actually has three arguments when explicitely used on `SELECT` queries.
|
||||
The first argument is always ommitted when attaching the function to a schema column.
|
||||
The value of that first argument is always interpreted as the value of the masked column, in this case a `text` column.
|
||||
For the same reason the call to `mask_default` attached to the column doesn't have any argument,
|
||||
even when that function requires one argument when explicitely used on `SELECT` queries.
|
||||
|
||||
Data can be inserted into the masked table as usual. For example:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_insert_data.cql[]
|
||||
----
|
||||
|
||||
The attached column masks will make `SELECT` queries automatically return masked data,
|
||||
without the need of including the masking function on the query:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_select_with_masked_columns.cql[]
|
||||
----
|
||||
|
||||
The masking function attached to a column can be changed with an `ALTER TABLE` query:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_alter_mask.cql[]
|
||||
----
|
||||
|
||||
In a similar way, a masking function can be dettached from a column with an `ALTER TABLE` query:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_drop_mask.cql[]
|
||||
----
|
||||
|
||||
== Permissions
|
||||
|
||||
The `UNMASK` permission allows users to retrieve the unmasked values of masked columns.
|
||||
The masks will only be applied to the results of a `SELECT` query if the user doesn't have the `UNMASK` permission.
|
||||
Ordinary users are created without the `UNMASK` permission, whereas superusers do have it.
|
||||
|
||||
As an example, suppose that we have a table with masked columns:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_create_table.cql[]
|
||||
----
|
||||
|
||||
And we insert some data into the table:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_insert_data.cql[]
|
||||
----
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_select_without_unmask_permission.cql[]
|
||||
----
|
||||
|
||||
Then we create two users with `SELECT` permission for the table, but we only grant the `UNMASK` permission to one of
|
||||
the users:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_create_users.cql[]
|
||||
----
|
||||
|
||||
We can now see that the user with the `UNMASK` permission can see the clear data, without any masking:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_select_with_unmask_permission.cql[]
|
||||
----
|
||||
|
||||
However, the user without the `UNMASK` permission can only see the masked data:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_select_without_unmask_permission.cql[]
|
||||
----
|
||||
|
||||
The `UNMASK` permission works as any other permission. Thus, it can be revoked in any moment:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_revoke_unmask.cql[]
|
||||
----
|
||||
|
||||
Please note that the anonymous user that is used when authentication is disabled has all the permissions.
|
||||
Since it includes the `UNMASK` permission, that anonymous user will always see the clear data.
|
||||
In other words, attaching data masking functions to columns only makes sense if authentication is enabled.
|
||||
|
||||
Users without the `UNMASK` permission are not allowed to use masked columns in the `WHERE` clause of a `SELECT` query.
|
||||
This prevents malicious users from figuring out the clear data by running exhaustive queries. For instance:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_select_without_select_masked.cql[]
|
||||
----
|
||||
|
||||
However, there are some use cases where trusted database users just need a useful way to produce masked data
|
||||
that will be served to untrusted external users.
|
||||
For example, a trusted app can connect to the database and extract masked data that will be served to its end users.
|
||||
In that case the trusted user (the app) can be given the `SELECT_MASKED` permission.
|
||||
That permission allows to use masked columns in the `WHERE` clause of a `SELECT` query,
|
||||
while still seeing the masked data in the query results. For instance:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_select_with_select_masked.cql[]
|
||||
----
|
||||
|
||||
== Custom functions
|
||||
|
||||
xref:cql/functions.adoc#user-defined-scalar-functions[User-defined functions (UDFs)] can be attached to a table column.
|
||||
The UDFs used for masking should belong to the same keyspace as the masked table.
|
||||
The column value to mask will be passed as the first argument of the attached UDF.
|
||||
Thus, the UDFs attached to a column should have at least one argument,
|
||||
and that argument should have the same type as the masked column.
|
||||
Also, the attached UDF should return values of the same type as the maked column. For instance:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_create_table_with_udf.cql[]
|
||||
----
|
||||
|
||||
This creates a dependency between the table schema and the functions.
|
||||
Any attempt to drop the function will be rejected while this dependency exists.
|
||||
Thus, to drop the function you should first drop the mask.
|
||||
This can be done with:
|
||||
|
||||
[source,cql]
|
||||
----
|
||||
include::example$CQL/ddm_drop_mask.cql[]
|
||||
----
|
||||
|
||||
Dropping the column, or its containing table, or its containing keyspace would also remove the dependency.
|
||||
|
||||
xref:cql/functions.adoc#aggregate-functions[Aggregate functions] cannot be used as masking functions.
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
= Data Modeling
|
||||
|
||||
* xref:data_modeling/intro.adoc[Introduction]
|
||||
* xref:data_modeling/data_modeling_rdbms.adoc[RDBMS]
|
||||
* xref:data_modeling/data_modeling_conceptual.adoc[Conceptual]
|
||||
* xref:data_modeling/data_modeling_logical.adoc[Logical]
|
||||
* xref:data_modeling/data_modeling_physical.adoc[Physical]
|
||||
* xref:data_modeling/data_modeling_schema.adoc[Schema]
|
||||
* xref:data_modeling/data_modeling_queries.adoc[Queries]
|
||||
* xref:data_modeling/data_modeling_refining.adoc[Refining]
|
||||
* xref:data_modeling/data_modeling_tools.adoc[Tools]
|
||||
|
|
@ -30,7 +30,7 @@ underlined. Relationships between entities are represented as diamonds,
|
|||
and the connectors between the relationship and each entity show the
|
||||
multiplicity of the connection.
|
||||
|
||||
image::data_modeling_hotel_erd.png[image]
|
||||
image::data-modeling_hotel_erd.png[image]
|
||||
|
||||
Obviously, in the real world, there would be many more considerations
|
||||
and much more complexity. For example, hotel rates are notoriously
|
||||
|
|
@ -34,7 +34,7 @@ informative way to visualize the relationships between queries and
|
|||
tables in your designs. This figure shows the Chebotko notation for a
|
||||
logical data model.
|
||||
|
||||
image::data_modeling_chebotko_logical.png[image]
|
||||
image::data-modeling_chebotko_logical.png[image]
|
||||
|
||||
Each table is shown with its title and a list of columns. Primary key
|
||||
columns are identified via symbols such as *K* for partition key columns
|
||||
|
|
@ -51,7 +51,7 @@ dedicated tables for rooms or amenities, as you had in the relational
|
|||
design. This is because the workflow didn’t identify any queries
|
||||
requiring this direct access.
|
||||
|
||||
image::data_modeling_hotel_logical.png[image]
|
||||
image::data-modeling_hotel_logical.png[image]
|
||||
|
||||
Let’s explore the details of each of these tables.
|
||||
|
||||
|
|
@ -127,7 +127,7 @@ shows a logical data model for reservations. You’ll notice that these
|
|||
tables represent a denormalized design; the same data appears in
|
||||
multiple tables, with differing keys.
|
||||
|
||||
image::data_modeling_reservation_logical.png[image]
|
||||
image::data-modeling_reservation_logical.png[image]
|
||||
|
||||
In order to satisfy Q6, the `reservations_by_guest` table can be used to
|
||||
look up the reservation by guest name. You could envision query Q7 being
|
||||
|
|
@ -19,7 +19,7 @@ notation for physical data models. To draw physical models, you need to
|
|||
be able to add the typing information for each column. This figure shows
|
||||
the addition of a type for each column in a sample table.
|
||||
|
||||
image::data_modeling_chebotko_physical.png[image]
|
||||
image::data-modeling_chebotko_physical.png[image]
|
||||
|
||||
The figure includes a designation of the keyspace containing each table
|
||||
and visual cues for columns represented using collections and
|
||||
|
|
@ -61,7 +61,7 @@ As you work to create physical representations of various tables in the
|
|||
logical hotel data model, you use the same approach. The resulting
|
||||
design is shown in this figure:
|
||||
|
||||
image::data_modeling_hotel_physical.png[image]
|
||||
image::data-modeling_hotel_physical.png[image]
|
||||
|
||||
Note that the `address` type is also included in the design. It is
|
||||
designated with an asterisk to denote that it is a user-defined type,
|
||||
|
|
@ -86,7 +86,7 @@ first iteration of your physical data model design, assume you're going
|
|||
to manage this denormalization manually. Note that this design could be
|
||||
revised to use Cassandra’s (experimental) materialized view feature.
|
||||
|
||||
image::data_modeling_reservation_physical.png[image]
|
||||
image::data-modeling_reservation_physical.png[image]
|
||||
|
||||
Note that the `address` type is reproduced in this keyspace and
|
||||
`guest_id` is modeled as a `uuid` type in all of the tables.
|
||||
|
|
@ -53,7 +53,7 @@ to obtain detailed description of the hotel. The act of booking a room
|
|||
creates a reservation record that may be accessed by the guest and hotel
|
||||
staff at a later time through various additional queries.
|
||||
|
||||
image::data_modeling_hotel_queries.png[image]
|
||||
image::data-modeling_hotel_queries.png[image]
|
||||
|
||||
_Material adapted from Cassandra, The Definitive Guide. Published by
|
||||
O'Reilly Media, Inc. Copyright © 2020 Jeff Carpenter, Eben Hewitt. All
|
||||
|
|
@ -12,7 +12,7 @@ relationships from the conceptual model of hotels-to-points of interest,
|
|||
rooms-to-amenities, rooms-to-availability, and guests-to-rooms (via a
|
||||
reservation).
|
||||
|
||||
image::data_modeling_hotel_relational.png[image]
|
||||
image::data-modeling_hotel_relational.png[image]
|
||||
|
||||
== Design Differences Between RDBMS and Cassandra
|
||||
|
||||
|
|
@ -188,7 +188,7 @@ the original design is shown in the figure below. While the `month`
|
|||
column is partially duplicative of the `date`, it provides a nice way of
|
||||
grouping related data in a partition that will not get too large.
|
||||
|
||||
image::data_modeling_hotel_bucketing.png[image]
|
||||
image::data-modeling_hotel_bucketing.png[image]
|
||||
|
||||
If you really felt strongly about preserving a wide partition design,
|
||||
you could instead add the `room_id` to the partition key, so that each
|
||||
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 85 KiB After Width: | Height: | Size: 85 KiB |
|
Before Width: | Height: | Size: 4.3 MiB After Width: | Height: | Size: 4.3 MiB |
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 228 KiB After Width: | Height: | Size: 228 KiB |
|
Before Width: | Height: | Size: 114 KiB After Width: | Height: | Size: 114 KiB |
|
Before Width: | Height: | Size: 117 KiB After Width: | Height: | Size: 117 KiB |
|
Before Width: | Height: | Size: 102 KiB After Width: | Height: | Size: 102 KiB |
|
Before Width: | Height: | Size: 100 KiB After Width: | Height: | Size: 100 KiB |
|
Before Width: | Height: | Size: 119 KiB After Width: | Height: | Size: 119 KiB |
|
Before Width: | Height: | Size: 139 KiB After Width: | Height: | Size: 139 KiB |
|
|
@ -0,0 +1,11 @@
|
|||
= Data Modeling
|
||||
|
||||
* xref:data-modeling/intro.adoc[Introduction]
|
||||
* xref:data-modeling/data-modeling_rdbms.adoc[RDBMS]
|
||||
* xref:data-modeling/data-modeling_conceptual.adoc[Conceptual]
|
||||
* xref:data-modeling/data-modeling_logical.adoc[Logical]
|
||||
* xref:data-modeling/data-modeling_physical.adoc[Physical]
|
||||
* xref:data-modeling/data-modeling_schema.adoc[Schema]
|
||||
* xref:data-modeling/data-modeling_queries.adoc[Queries]
|
||||
* xref:data-modeling/data-modeling_refining.adoc[Refining]
|
||||
* xref:data-modeling/data-modeling_tools.adoc[Tools]
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
= Getting Started
|
||||
|
||||
This section covers how to get started using Apache Cassandra and should
|
||||
be the first thing to read if you are new to Cassandra.
|
||||
|
||||
* xref:installing/installing.adoc[Installing Cassandra]: Installation instructions plus information on choosing a method.
|
||||
** [ xref:installing/installing.adoc#installing-the-docker-image[Docker] ]
|
||||
[ xref:installing/installing.adoc#installing-the-binary-tarball[tarball] ]
|
||||
[ xref:installing/installing.adoc#installing-the-debian-packages[Debian] ]
|
||||
[ xref:installing/installing.adoc#installing-the-rpm-packages[RPM] ]
|
||||
* xref:getting-started/configuring.adoc[Configuring Cassandra]
|
||||
* xref:getting-started/querying.adoc[Inserting and querying data]
|
||||
* xref:getting-started/drivers.adoc[Client drivers]: Drivers for various languages.
|
||||
** [ xref:getting-started/drivers.adoc#java[Java] ]
|
||||
[ xref:getting-started/drivers.adoc#python[Python] ]
|
||||
[ xref:getting-started/drivers.adoc#ruby[Ruby] ]
|
||||
[ xref:getting-started/drivers.adoc#c-net[C# / .NET] ]
|
||||
[ xref:getting-started/drivers.adoc#nodejs[Node.js] ]
|
||||
[ xref:getting-started/drivers.adoc#php[PHP] ]
|
||||
[ xref:getting-started/drivers.adoc#c[C++] ]
|
||||
[ xref:getting-started/drivers.adoc#scala[Scala] ]
|
||||
[ xref:getting-started/drivers.adoc#clojure[Clojure] ]
|
||||
[ xref:getting-started/drivers.adoc#erlang[Erlang] ]
|
||||
[ xref:getting-started/drivers.adoc#go[Go] ]
|
||||
[ xref:getting-started/drivers.adoc#haskell[Haskell] ]
|
||||
[ xref:getting-started/drivers.adoc#rust[Rust] ]
|
||||
[ xref:getting-started/drivers.adoc#perl[Perl] ]
|
||||
[ xref:getting-started/drivers.adoc#elixir[Elixir] ]
|
||||
[ xref:getting-started/drivers.adoc#dart[Dart] ]
|
||||
* xref:getting-started/production.adoc[Production recommendations]
|
||||
|
|
@ -26,6 +26,6 @@ If the command is used without specifying a node, `localhost` is the default. Se
|
|||
|
||||
== Client drivers
|
||||
|
||||
A lot of xref:getting_started/drivers.adoc[client drivers] are provided by the Community and a list of
|
||||
A lot of xref:getting-started/drivers.adoc[client drivers] are provided by the Community and a list of
|
||||
known drivers is provided. You should refer to the documentation of each driver
|
||||
for more information.
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
= Getting Started
|
||||
|
||||
This section covers how to get started using Apache Cassandra and should
|
||||
be the first thing to read if you are new to Cassandra.
|
||||
|
||||
* xref:getting_started/installing.adoc[Installing Cassandra]: Installation instructions plus information on choosing a method.
|
||||
** [ xref:getting_started/installing.adoc#installing-the-docker-image[Docker] ]
|
||||
[ xref:getting_started/installing.adoc#installing-the-binary-tarball[tarball] ]
|
||||
[ xref:getting_started/installing.adoc#installing-the-debian-packages[Debian] ]
|
||||
[ xref:getting_started/installing.adoc#installing-the-rpm-packages[RPM] ]
|
||||
* xref:getting_started/configuring.adoc[Configuring Cassandra]
|
||||
* xref:getting_started/querying.adoc[Inserting and querying data]
|
||||
* xref:getting_started/drivers.adoc[Client drivers]: Drivers for various languages.
|
||||
** [ xref:getting_started/drivers.adoc#java[Java] ]
|
||||
[ xref:getting_started/drivers.adoc#python[Python] ]
|
||||
[ xref:getting_started/drivers.adoc#ruby[Ruby] ]
|
||||
[ xref:getting_started/drivers.adoc#c-net[C# / .NET] ]
|
||||
[ xref:getting_started/drivers.adoc#nodejs[Node.js] ]
|
||||
[ xref:getting_started/drivers.adoc#php[PHP] ]
|
||||
[ xref:getting_started/drivers.adoc#c[C++] ]
|
||||
[ xref:getting_started/drivers.adoc#scala[Scala] ]
|
||||
[ xref:getting_started/drivers.adoc#clojure[Clojure] ]
|
||||
[ xref:getting_started/drivers.adoc#erlang[Erlang] ]
|
||||
[ xref:getting_started/drivers.adoc#go[Go] ]
|
||||
[ xref:getting_started/drivers.adoc#haskell[Haskell] ]
|
||||
[ xref:getting_started/drivers.adoc#rust[Rust] ]
|
||||
[ xref:getting_started/drivers.adoc#perl[Perl] ]
|
||||
[ xref:getting_started/drivers.adoc#elixir[Elixir] ]
|
||||
[ xref:getting_started/drivers.adoc#dart[Dart] ]
|
||||
* xref:getting_started/production.adoc[Production recommendations]
|
||||
|
|
@ -189,7 +189,7 @@ include::example$TEXT/tarball_install_dirs.txt[]
|
|||
<5>location of cassandra-stress tool
|
||||
|
||||
For information on how to configure your installation, see
|
||||
{cass_url}doc/latest/getting_started/configuring.html[Configuring
|
||||
{cass_url}doc/latest/getting-started/configuring.html[Configuring
|
||||
Cassandra].
|
||||
|
||||
[arabic, start=6]
|
||||
|
|
@ -286,7 +286,7 @@ include::example$BASH/apt-get_cass.sh[]
|
|||
----
|
||||
|
||||
NOTE: For information on how to configure your installation, see
|
||||
{cass_url}doc/latest/getting_started/configuring.html[Configuring
|
||||
{cass_url}doc/latest/getting-started/configuring.html[Configuring
|
||||
Cassandra].
|
||||
|
||||
include::partial$tail_syslog.adoc[]
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue