mirror of https://github.com/apache/cassandra
Merge branch 'cassandra-5.0' into trunk
* cassandra-5.0: Several doc fixes, particularly developing/cql/ , developing/data-modeling/ and managing/
This commit is contained in:
mck
commit
bfea5446d7
|
|
@ -1,2 +1,2 @@
|
|||
CREATE KEYSPACE some_keyspace
|
||||
WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1' : '3/1'', 'DC2' : '5/2'};
|
||||
WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1' : '3/1', 'DC2' : '5/2'};
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
* `system_schema.keyspaces`
|
||||
* `system_schema.columns`
|
||||
* `system_schema.tables`
|
||||
* `system.local`
|
||||
* `system.peers`
|
||||
* system_schema.keyspaces
|
||||
* system_schema.columns
|
||||
* system_schema.tables
|
||||
* system.local
|
||||
* system.peers
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ WITH CLUSTERING ORDER BY (created_at DESC);
|
|||
|
||||
// tag::alter-vs-table[]
|
||||
ALTER TABLE cycling.comments_vs
|
||||
ADD comment_vector VECTOR <FLOAT, 5>; <1>
|
||||
ADD comment_vector VECTOR <FLOAT, 5>;
|
||||
// end::alter-vs-table[]
|
||||
|
||||
// tag::create-vs-index[]
|
||||
|
|
@ -116,4 +116,4 @@ SELECT comment, similarity_cosine(comment_vector, [0.2, 0.15, 0.3, 0.2, 0.05])
|
|||
FROM cycling.comments_vs
|
||||
ORDER BY comment_vector ANN OF [0.1, 0.15, 0.3, 0.12, 0.05]
|
||||
LIMIT 1;
|
||||
// end::select-vector-data-similarity-cycling[]
|
||||
// end::select-vector-data-similarity-cycling[]
|
||||
|
|
|
|||
|
|
@ -1 +1,7 @@
|
|||
TBD
|
||||
CREATE TABLE cycling.birthday_list (
|
||||
cyclist_name text PRIMARY KEY,
|
||||
.
|
||||
.
|
||||
.
|
||||
|
||||
CREATE INDEX blist_values_idx ON cycling.birthday_list (values(blist));
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
== SASI Index
|
||||
= SASI Index
|
||||
|
||||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/SASIIndex.java[`SASIIndex`],
|
||||
or ``SASI`` for short, is an implementation of Cassandra's `Index`
|
||||
|
|
@ -9,7 +9,7 @@ has superior performance in cases where queries would previously require
|
|||
filtering. In achieving this performance, SASI aims to be significantly
|
||||
less resource intensive than existing implementations, in memory, disk,
|
||||
and CPU usage. In addition, SASI supports prefix and contains queries on
|
||||
strings (similar to SQL's `LIKE = "foo*"` or `LIKE = "*foo*"'`).
|
||||
strings (similar to SQL's ``LIKE = "foo\*"`` or ``LIKE = "*foo*"`` ).
|
||||
|
||||
The following goes on describe how to get up and running with SASI,
|
||||
demonstrates usage with examples, and provides some details on its
|
||||
|
|
@ -357,7 +357,7 @@ parts: Indexing and Querying. Further, Cassandra makes it possible to
|
|||
divide those responsibilities into the memory and disk components. SASI
|
||||
takes advantage of Cassandra's write-once, immutable, ordered data model
|
||||
to build indexes along with the flushing of the memtable to disk – this
|
||||
is the origin of the name ``SSTable Attached Secondary Index''.
|
||||
is the origin of the name `SSTable Attached Secondary Index`.
|
||||
|
||||
The SASI index data structures are built in memory as the SSTable is
|
||||
being written and they are flushed to disk before the writing of the
|
||||
|
|
@ -405,15 +405,15 @@ or more page-sized blocks. The
|
|||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java[`OnDiskIndex`]
|
||||
is structured as a tree of arrays, where each level describes the terms
|
||||
in the level below, the final level being the terms themselves. The
|
||||
`PointerLevel`s and their `PointerBlock`s contain terms and pointers to
|
||||
``PointerLevel``s and their ``PointerBlock``s contain terms and pointers to
|
||||
other blocks that _end_ with those terms. The `DataLevel`, the final
|
||||
level, and its `DataBlock`s contain terms and point to the data itself,
|
||||
level, and its ``DataBlock``s contain terms and point to the data itself,
|
||||
contained in
|
||||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/disk/TokenTree.java[`TokenTree`]s.
|
||||
|
||||
The terms written to the
|
||||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java[`OnDiskIndex`]
|
||||
vary depending on its ``mode'': either `PREFIX`, `CONTAINS`, or
|
||||
vary depending on its `mode` : either `PREFIX`, `CONTAINS`, or
|
||||
`SPARSE`. In the `PREFIX` and `SPARSE` cases, terms' exact values are
|
||||
written exactly once per `OnDiskIndex`. For example, when using a
|
||||
`PREFIX` index with terms `Jason`, `Jordan`, `Pavel`, all three will be
|
||||
|
|
@ -428,14 +428,14 @@ is built merging all the
|
|||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/disk/TokenTree.java[`TokenTree`]s
|
||||
for each term into a single one. This copy of the data is used for
|
||||
efficient iteration of large ranges of e.g. timestamps. The index
|
||||
``mode'' is configurable per column at index creation time.
|
||||
`mode` is configurable per column at index creation time.
|
||||
|
||||
===== TokenTree(Builder)
|
||||
|
||||
The
|
||||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/disk/TokenTree.java[`TokenTree`]
|
||||
is an implementation of the well-known
|
||||
https://en.wikipedia.org/wiki/B%2B_tree[B+-tree] that has been modified
|
||||
https://en.wikipedia.org/wiki/B%2B_tree[B+ tree] that has been modified
|
||||
to optimize for its use-case. In particular, it has been optimized to
|
||||
associate tokens, longs, with a set of positions in an SSTable, also
|
||||
longs. Allowing the set of long values accommodates the possibility of a
|
||||
|
|
@ -519,7 +519,7 @@ execution.
|
|||
|
||||
During the analysis phase,
|
||||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/plan/QueryPlan.java[`QueryPlan`]
|
||||
converts from Cassandra's internal representation of `IndexExpression`s,
|
||||
converts from Cassandra's internal representation of ``IndexExpression``s,
|
||||
which has also been modified to support encoding queries that contain
|
||||
ORs and groupings of expressions using parentheses (see the
|
||||
link:#cassandra-internal-changes[Cassandra Internal Changes] section
|
||||
|
|
@ -653,8 +653,8 @@ like this:
|
|||
The last type of optimization applied, for this query, is to merge range
|
||||
expressions across branches of the tree – without modifying the meaning
|
||||
of the query, of course. In this case, because the query contains all
|
||||
`AND`s the `age` expressions can be collapsed. Along with this
|
||||
optimization, the initial collapsing of unneeded `AND`s can also be
|
||||
``AND``s the `age` expressions can be collapsed. Along with this
|
||||
optimization, the initial collapsing of unneeded ``AND``s can also be
|
||||
applied once more to result in this final tree using to execute the
|
||||
query:
|
||||
|
||||
|
|
@ -683,7 +683,7 @@ class, more specifically, can have zero, one, or two
|
|||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/plan/Operation.java[`Operation`]s
|
||||
as children and an unlimited number of expressions. The iterators used
|
||||
to perform the queries, discussed below in the
|
||||
``Range(Union|Intersection)Iterator'' section, implement the necessary
|
||||
`Range(Union|Intersection)Iterator` section, implement the necessary
|
||||
logic to merge results transparently regardless of the
|
||||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/plan/Operation.java[`Operation`]s
|
||||
children.
|
||||
|
|
@ -706,14 +706,14 @@ the code].
|
|||
The abstract `RangeIterator` class provides a unified interface over the
|
||||
two main operations performed by SASI at various layers in the execution
|
||||
path: set intersection and union. These operations are performed in a
|
||||
iterated, or ``streaming'', fashion to prevent unneeded reads of
|
||||
iterated, or `streaming`, fashion to prevent unneeded reads of
|
||||
elements from either set. In both the intersection and union cases the
|
||||
algorithms take advantage of the data being pre-sorted using the same
|
||||
sort order, e.g. term or token order.
|
||||
|
||||
The
|
||||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/utils/RangeUnionIterator.java[`RangeUnionIterator`]
|
||||
performs the ``Merge-Join'' portion of the
|
||||
performs the `Merge-Join` portion of the
|
||||
https://en.wikipedia.org/wiki/Sort-merge_join[Sort-Merge-Join]
|
||||
algorithm, with the properties of an outer-join, or union. It is
|
||||
implemented with several optimizations to improve its performance over a
|
||||
|
|
@ -733,7 +733,7 @@ between them based on some properties of the data.
|
|||
|
||||
`BounceIntersectionIterator`, and the `BOUNCE` strategy, works like the
|
||||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/utils/RangeUnionIterator.java[`RangeUnionIterator`]
|
||||
in that it performs a ``Merge-Join'', however, its nature is similar to
|
||||
in that it performs a `Merge-Join`, however, its nature is similar to
|
||||
a inner-join, where like values are merged by a data-specific merge
|
||||
function (e.g. merging two tokens in a list to lookup in a SSTable
|
||||
later). See the
|
||||
|
|
@ -742,7 +742,7 @@ for more details on its implementation.
|
|||
|
||||
`LookupIntersectionIterator`, and the `LOOKUP` strategy, performs a
|
||||
different operation, more similar to a lookup in an associative data
|
||||
structure, or ``hash lookup'' in database terminology. Once again,
|
||||
structure, or `hash lookup` in database terminology. Once again,
|
||||
details on the implementation can be found in the
|
||||
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/utils/RangeIntersectionIterator.java#L199-L208[javadoc].
|
||||
|
||||
|
|
@ -794,7 +794,7 @@ The following are items that can be addressed in future updates but are
|
|||
not available in this repository or are not currently implemented.
|
||||
|
||||
* The cluster must be configured to use a partitioner that produces
|
||||
`LongToken`s, e.g. `Murmur3Partitioner`. Other existing partitioners
|
||||
``LongToken``s, e.g. `Murmur3Partitioner`. Other existing partitioners
|
||||
which don't produce LongToken e.g. `ByteOrderedPartitioner` and
|
||||
`RandomPartitioner` will not work with SASI.
|
||||
* Not Equals and OR support have been removed in this release while
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
= Changes
|
||||
= CQL Changes
|
||||
|
||||
The following describes the changes in each version of CQL.
|
||||
|
||||
|
|
@ -63,15 +63,15 @@ explicitly set.
|
|||
* `ALTER TABLE` `ADD` and `DROP` now allow multiple columns to be
|
||||
added/removed.
|
||||
* New `PER PARTITION LIMIT` option for `SELECT` statements (see
|
||||
https://issues.apache.org/jira/browse/CASSANDRA-7017)[CASSANDRA-7017].
|
||||
https://issues.apache.org/jira/browse/CASSANDRA-7017[CASSANDRA-7017]).
|
||||
* `User-defined functions <cql-functions>` can now instantiate
|
||||
`UDTValue` and `TupleValue` instances via the new `UDFContext` interface
|
||||
(see
|
||||
https://issues.apache.org/jira/browse/CASSANDRA-10818)[CASSANDRA-10818].
|
||||
https://issues.apache.org/jira/browse/CASSANDRA-10818[CASSANDRA-10818]).
|
||||
* `User-defined types <udts>` may now be stored in a non-frozen form,
|
||||
allowing individual fields to be updated and deleted in `UPDATE`
|
||||
statements and `DELETE` statements, respectively.
|
||||
(https://issues.apache.org/jira/browse/CASSANDRA-7423)[CASSANDRA-7423]).
|
||||
(https://issues.apache.org/jira/browse/CASSANDRA-7423[CASSANDRA-7423]).
|
||||
|
||||
== 3.4.1
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ and `UPDATE` supports `IF` conditions.
|
|||
|
||||
* `SELECT`, `UPDATE`, and `DELETE` statements now allow empty `IN`
|
||||
relations (see
|
||||
https://issues.apache.org/jira/browse/CASSANDRA-5626)[CASSANDRA-5626].
|
||||
https://issues.apache.org/jira/browse/CASSANDRA-5626[CASSANDRA-5626]).
|
||||
|
||||
== 3.0.4
|
||||
|
||||
|
|
|
|||
|
|
@ -283,7 +283,7 @@ following modifiers:
|
|||
|
||||
Some columns can be declared as `STATIC` in a table definition. A column
|
||||
that is static will be “shared” by all the rows belonging to the same
|
||||
partition (having the same xref:cassandra:developing/cql/ddl.adoc#partition-key[partition key].
|
||||
partition (having the same xref:cassandra:developing/cql/ddl.adoc#partition-key[partition key]).
|
||||
|
||||
For example:
|
||||
|
||||
|
|
|
|||
|
|
@ -527,7 +527,7 @@ UDFs can be _overloaded_, so that multiple UDFs with different argument types ca
|
|||
[NOTE]
|
||||
====
|
||||
_JavaScript_ user-defined functions have been deprecated in Cassandra 4.1. In preparation for Cassandra 5.0, their removal is
|
||||
already in progress. For more information - CASSANDRA-17281, CASSANDRA-18252.
|
||||
already in progress. For more information - https://issues.apache.org/jira/browse/CASSANDRA-17281[CASSANDRA-17281], https://issues.apache.org/jira/browse/CASSANDRA-18252[CASSANDRA-18252].
|
||||
====
|
||||
|
||||
For example:
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ The `WHERE` clause has the following restrictions:
|
|||
** no other restriction is allowed
|
||||
** cannot have columns that are part of the _view_ primary key be null, they must always be at least restricted by a `IS NOT NULL`
|
||||
restriction (or any other restriction, but they must have one).
|
||||
* cannot have an xref:cassandra:developing/cql/dml.adoc#ordering-clause[ordering clause], a xref:cassandra:developing/cql/dml.adoc#limit-clause[limit], or xref:cassandra:developing/cql/dml.adoc#allow-filtering[ALLOW FILTERING
|
||||
* cannot have an xref:cassandra:developing/cql/dml.adoc#ordering-clause[ordering clause], a xref:cassandra:developing/cql/dml.adoc#limit-clause[limit], or xref:cassandra:developing/cql/dml.adoc#allow-filtering[ALLOW FILTERING]
|
||||
|
||||
=== MV primary key
|
||||
|
||||
|
|
@ -152,5 +152,5 @@ Removal of columns not selected in the Materialized View (via
|
|||
`DELETE unselected_column FROM base`) may shadow missed updates to other
|
||||
columns received by hints or repair. For this reason, we advise against
|
||||
doing deletions on base columns not selected in views until this is
|
||||
fixed on CASSANDRA-13826.
|
||||
fixed on https://issues.apache.org/jira/browse/CASSANDRA-13826[CASSANDRA-13826].
|
||||
====
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ xref:cassandra:developing/cql/security.adoc#authorization[authorization].
|
|||
However, if authorization is enabled, xref:cassandra:developing/cql/security.adoc#cql-permissions[permissions] of the dropped role are also revoked,
|
||||
subject to the xref:cassandra:developing/cql/security.adoc#auth-caching[caching options] configured in xref:cassandra:developing/cql/configuring.adoc#cassandra.yaml[cassandra-yaml] file.
|
||||
Should a dropped role be subsequently recreated and have new xref:security.adoc#grant-permission-statement[permissions] or
|
||||
xref:security.adoc#grant-role-statement[roles]` granted to it, any client sessions still
|
||||
xref:security.adoc#grant-role-statement[roles] granted to it, any client sessions still
|
||||
connected will acquire the newly granted permissions and roles.
|
||||
====
|
||||
|
||||
|
|
@ -344,7 +344,7 @@ Existing users can be listed using the `LIST USERS` statement:
|
|||
include::cassandra:example$BNF/list_users_statement.bnf[]
|
||||
----
|
||||
|
||||
Note that this statement is equivalent to xref:security.adoc#list-roles-statement[`LIST ROLES], but only roles with the `LOGIN` privilege are included in the output.
|
||||
Note that this statement is equivalent to xref:security.adoc#list-roles-statement[LIST ROLES], but only roles with the `LOGIN` privilege are included in the output.
|
||||
|
||||
== Data Control
|
||||
|
||||
|
|
@ -660,5 +660,5 @@ which were directly granted to `bob` or one of `bob`'s roles:
|
|||
include::cassandra:example$CQL/list_select_perm.cql[]
|
||||
----
|
||||
|
||||
Show any permissions granted to `carlos` or any of `carlos`'s roles,
|
||||
Show any permissions granted to `carlos` or any roles assigned to `carlos`,
|
||||
limited to `SELECT` permissions on any resource.
|
||||
|
|
|
|||
|
|
@ -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::cassandra:developing/data-modeling/data-modeling_chebotko_logical.png[image]
|
||||
image::cassandra:developing/data-modeling/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::cassandra:developing/data-modeling/data-modeling_hotel_logical.png[image]
|
||||
image::cassandra:developing/data-modeling/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::cassandra:developing/data-modeling/data-modeling_reservation_logical.png[image]
|
||||
image::cassandra:developing/data-modeling/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::cassandra:developing/data-modeling/data-modeling_chebotko_physical.png[image]
|
||||
image::cassandra:developing/data-modeling/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::cassandra:developing/data-modeling/data-modeling_hotel_physical.png[image]
|
||||
image::cassandra:developing/data-modeling/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::cassandra:developing/data-modeling/data-modeling_reservation_physical.png[image]
|
||||
image::cassandra:developing/data-modeling/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::cassandra:developing/data-modeling/data-modeling_hotel_queries.png[image]
|
||||
image::cassandra:developing/data-modeling/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
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ See each file for examples of settings.
|
|||
|
||||
[NOTE]
|
||||
====
|
||||
The `jvm-*` files replace the `cassandra-envsh` file used in Cassandra
|
||||
The `jvm-\*` files replace the `cassandra-env.sh` file used in Cassandra
|
||||
versions prior to Cassandra 3.0. The `cassandra-env.sh` bash script file
|
||||
is still useful if JVM settings must be dynamically calculated based on
|
||||
system settings. The `jvm-*` files only store static JVM settings.
|
||||
|
|
|
|||
|
|
@ -87,5 +87,5 @@ tables will be rejected unless some consumption process is in place.
|
|||
|
||||
== Further Reading
|
||||
|
||||
* https://issues.apache.org/jira/browse/CASSANDRA-8844[JIRA ticket]
|
||||
* https://issues.apache.org/jira/browse/CASSANDRA-12148[JIRA ticket]
|
||||
* Change Data Capture ( https://issues.apache.org/jira/browse/CASSANDRA-8844[CASSANDRA-8844 JIRA ticket] )
|
||||
* Improve determinism of CDC data availability ( https://issues.apache.org/jira/browse/CASSANDRA-12148[CASSANDRA-12148 JIRA ticket] )
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ This kind of deleted but persistent object is called a https://cassandra.apache.
|
|||
== Grace period
|
||||
|
||||
To prevent the reappearance of zombies, {cassandra} gives each tombstone a grace period.
|
||||
The grace period for a tombstone is set with the table property ` WITH gc_grace_seconds`.
|
||||
The grace period for a tombstone is set with the table property `WITH gc_grace_seconds`.
|
||||
Its default value is 864000 seconds (ten days), after which a tombstone expires and can be deleted during compaction.
|
||||
Prior to the grace period expiring, {cassandra} will retain a tombstone through compaction events.
|
||||
Each table can have its own value for this property.
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ in `nodetool netstats`.
|
|||
The replacing node will now start to bootstrap the data from the rest of
|
||||
the nodes in the cluster. A replacing node will only receive writes
|
||||
during the bootstrapping phase if it has a different ip address to the
|
||||
node that is being replaced. (See CASSANDRA-8523 and CASSANDRA-12344)
|
||||
node that is being replaced. ( See https://issues.apache.org/jira/browse/CASSANDRA-8523[CASSANDRA-8523] and https://issues.apache.org/jira/browse/CASSANDRA-12344[CASSANDRA-12344] )
|
||||
|
||||
Once the bootstrapping is complete the node will be marked "UP".
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ results will occur. Note: the script does not verify that Cassandra is
|
|||
stopped.
|
||||
|
||||
== WARNING
|
||||
See CASSANDRA-9947 and CASSANDRA-17017 for discussion around risks with this tool. Specifically: "We mark sstables that fail verification as unrepaired, but that's not going to do what you think. What it means is that the local node will use that sstable in the next repair, but other nodes will not. So all we'll end up doing is streaming whatever data we can read from it, to the other replicas. If we could magically mark whatever sstables correspond on the remote nodes, to the data in the local sstable, that would work, but we can't."
|
||||
See https://issues.apache.org/jira/browse/CASSANDRA-9947[CASSANDRA-9947] and https://issues.apache.org/jira/browse/CASSANDRA-17017[CASSANDRA-17017] for discussion around risks with this tool. Specifically: "We mark sstables that fail verification as unrepaired, but that's not going to do what you think. What it means is that the local node will use that sstable in the next repair, but other nodes will not. So all we'll end up doing is streaming whatever data we can read from it, to the other replicas. If we could magically mark whatever sstables correspond on the remote nodes, to the data in the local sstable, that would work, but we can't."
|
||||
|
||||
This tool requires the use of a -f or --force flag to indicate that the user understands the risks and would like to attempt its usage anyway.
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ sstableverify <options> <keyspace> <table>
|
|||
|-e, --extended |extended verification
|
||||
|-h, --help |display this help message
|
||||
|-v, --verbose |verbose output
|
||||
|-f, --force |allow use of tool (see CASSANDRA-17017 for risks)
|
||||
|-f, --force |allow use of tool (see https://issues.apache.org/jira/browse/CASSANDRA-17017[CASSANDRA-17017] for risks)
|
||||
|===
|
||||
|
||||
== Basic Verification
|
||||
|
|
|
|||
|
|
@ -240,7 +240,7 @@ include::cassandra:example$RESULTS/sai/select_all_from_cyclist_career_teams-team
|
|||
|
||||
You can create an index on xref:cassandra:developing/cql/indexing/2i/_2i-create-on-collection.adoc[map collection keys].
|
||||
If an index of the map values of the collection exists, drop that index before creating an index on the map collection keys.
|
||||
Assume a cyclist table contains this map data where `nation is the map key and `Canada` is the map value`:
|
||||
Assume a cyclist table contains this map data where `nation` is the map key and `Canada` is the map value:
|
||||
|
||||
[source,no-highlight]
|
||||
----
|
||||
|
|
@ -471,4 +471,4 @@ SELECT result::
|
|||
include::cassandra:example$RESULTS/sai/race_starts-queries.result[]
|
||||
----
|
||||
--
|
||||
====
|
||||
====
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ CDC logging must be enabled in cassandra.yaml.
|
|||
====
|
||||
Before enabling CDC logging, have a plan for moving and consuming the log information.
|
||||
After the disk space limit is reached, writes to CDC-enabled tables are rejected until more space is freed.
|
||||
See https://docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/config/configCassandra_yaml.html#configCassandra_yaml__cdcSpaceSection[Change-data-capture (CDC) space settings] for information about available CDC settings.
|
||||
See https://docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/config/configCassandra_yaml.html#cdcSpaceSection[Change-data-capture (CDC) space settings] for information about available CDC settings.
|
||||
====
|
||||
|
||||
== Storing data in descending order
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
:description: In a table that uses clustering columns, non-clustering columns can be declared static in the table definition.
|
||||
|
||||
Static column values are shared among the rows in the partition.
|
||||
In a table that uses https://cassandra.apache.org/_/glossary.html#clustering-column[clustering columns], non-clustering columns can be declared static in the table definition.
|
||||
In a table that uses https://cassandra.apache.org/\_/glossary.html#clustering-column[clustering columns], non-clustering columns can be declared static in the table definition.
|
||||
https://cassandra.apache.org/_/glossary.html#static-column[Static columns] are only static within a given partition.
|
||||
|
||||
In the following example, the `flag` column is static:
|
||||
|
|
|
|||
|
|
@ -18,10 +18,10 @@ stacks.
|
|||
|
||||
[arabic]
|
||||
. By default Cassandra ships with `-XX:+PerfDisableSharedMem` set to
|
||||
prevent long pauses (see `CASSANDRA-9242` and `CASSANDRA-9483` for
|
||||
prevent long pauses (see https://issues.apache.org/jira/browse/CASSANDRA-9242[CASSANDRA-9242] and https://issues.apache.org/jira/browse/CASSANDRA-9483[CASSANDRA-9483] for
|
||||
details). If you want to use JVM tooling you can instead have `/tmp`
|
||||
mounted on an in memory `tmpfs` which also effectively works around
|
||||
`CASSANDRA-9242`.
|
||||
https://issues.apache.org/jira/browse/CASSANDRA-9242[CASSANDRA-9242] .
|
||||
. Make sure you run the tools as the same user as Cassandra is running
|
||||
as, e.g. if the database is running as `cassandra` the tool also has to
|
||||
be run as `cassandra`, e.g. via `sudo -u cassandra <cmd>`.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
= Data Modeling
|
||||
= Vector Search : Data Modeling
|
||||
|
||||
As you develop AI and Machine Learning (ML) applications using Vector Search, here are some data modeling considerations.
|
||||
These factors help effectively leverage vector search to produce accurate and efficient search responses within your application.
|
||||
|
|
@ -162,4 +162,4 @@ While the vector embeddings can replace or augment some functions of a tradition
|
|||
|
||||
* Vector embeddings are not human-readable. Embeddings are not recommended when seeking to
|
||||
directly retrieve data from a table.
|
||||
* The model might not be able to capture all relevant information from the data, leading to incorrect or incomplete results.
|
||||
* The model might not be able to capture all relevant information from the data, leading to incorrect or incomplete results.
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ Use single quotation marks to preserve upper case.
|
|||
Braces (`{ }`) enclose map collections or key value pairs.
|
||||
A colon separates the key and the value.
|
||||
|
||||
| `<<datatype1>,<datatype2>>`
|
||||
| `< <datatype1>,<datatype2> >`
|
||||
| Set, list, map, or tuple.
|
||||
Angle brackets ( `< >` ) enclose data types in a set, list, map, or tuple.
|
||||
Separate the data types with a comma.
|
||||
|
|
@ -60,4 +60,4 @@ This syntax is useful when arguments might be mistaken for command line options.
|
|||
|
||||
| `@<xml_entity>='<xml_entity_type>'`
|
||||
| Search CQL only: Identify the entity and literal value to overwrite the XML element in the schema and solrConfig files.
|
||||
|===
|
||||
|===
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Each column is defined using the following syntax: `+column_name cql_type_defini
|
|||
*Restriction:*
|
||||
|
||||
* A table must have at least one `PRIMARY KEY`.
|
||||
* When `PRIMARY KEY` is at the end of a column definition, that column is the only primary key for the table, and is defined as the https://cassandra.apache.org/_/glossary.html#[partition-key][partition key].
|
||||
* When `PRIMARY KEY` is at the end of a column definition, that column is the only primary key for the table, and is defined as the https://cassandra.apache.org/_/glossary.html#partition-key[partition key].
|
||||
* A static column cannot be a primary key.
|
||||
* Primary keys can include frozen collections.
|
||||
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ Tombstoned records within the grace period are excluded from xref:managing/opera
|
|||
====
|
||||
+
|
||||
In a single-node cluster, this property can safely be set to zero.
|
||||
You can also reduce this value for tables whose data is not explicitly deleted -- for example, tables containing only data with https://cassandra.apache.org/_/glossary.html#gloss_ttl[TTL] set, or tables with `default_time_to_live` set.
|
||||
You can also reduce this value for tables whose data is not explicitly deleted -- for example, tables containing only data with https://cassandra.apache.org/_/glossary.html#ttl[TTL] set, or tables with `default_time_to_live` set.
|
||||
However, if you lower the `gc_grace_seconds` value, consider its interaction with these operations:
|
||||
+
|
||||
|
||||
|
|
@ -127,7 +127,7 @@ The max_index_interval is the sparsest possible sampling in relation to memory p
|
|||
|
||||
*speculative_retry* ::
|
||||
Configures https://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2[rapid read protection].
|
||||
Normal read requests are sent to just enough replica nodes to satisfy the https://cassandra.apache.org/_/glossary.html#gloss_consistency_level[consistency level].
|
||||
Normal read requests are sent to just enough replica nodes to satisfy the https://cassandra.apache.org/_/glossary.html#consistency-level[consistency level].
|
||||
In rapid read protection, extra read requests are sent to other replicas, even after the consistency level has been met.
|
||||
The speculative retry property specifies the trigger for these extra read requests.
|
||||
+
|
||||
|
|
|
|||
Loading…
Reference in New Issue