diff --git a/doc/modules/cassandra/pages/architecture/overview.adoc b/doc/modules/cassandra/pages/architecture/overview.adoc index 003f2198bc34..1970b67a680c 100644 --- a/doc/modules/cassandra/pages/architecture/overview.adoc +++ b/doc/modules/cassandra/pages/architecture/overview.adoc @@ -4,15 +4,13 @@ {product} is an open-source, distributed NoSQL database. It implements a partitioned wide-column storage model with eventually consistent semantics. -{cassandra} was initially designed at https://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf[Facebook] using a staged event-driven architecture (http://www.sosp.org/2001/papers/welsh.pdf[SEDA]). +{cassandra} was created at https://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf[Facebook] using a staged event-driven architecture (http://www.sosp.org/2001/papers/welsh.pdf[SEDA]). This initial design implemented a combination of Amazon's https://www.cs.cornell.edu/courses/cs5414/2017fa/papers/dynamo.pdf[Dynamo] distributed storage and replication techniques and Google's https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdf[Bigtable] data and storage engine model. Dynamo and Bigtable were both developed to meet emerging requirements for scalable, reliable and highly available storage systems, but each had areas that could be improved. -{product} was designed as a best-in-class combination of both systems to meet emerging large scale, both in data footprint and query volume, storage requirements. -As applications began to require full global replication and always available low-latency reads and writes, a new kind of database model was required to meet these new requirements. -Relational database systems at that time struggled to meet the requirements. +{product} was designed to combine the strengths of both of these distributed database systems to address scalability, both in terms of data volume and query throughput. As applications increasingly demanded global replication, continuous availability, and low-latency reads and writes, a new database model became necessary, one that traditional relational systems of the time were not well suited to support. -{product} was designed to meet these challenges with the following design objectives in mind: +{product} was created to meet these challenges with the following design objectives: * Full multi-primary database replication * Global availability at low latency @@ -35,9 +33,7 @@ Keyspaces serve as containers for tables. Columns define the typed schema for a single datum in a table. Tables are partitioned based on the columns provided in the partition key. {cassandra} tables can flexibly add new columns to tables with zero downtime. -* Partition: Defines the mandatory part of the primary key all rows in -{cassandra} must have to identify the node in a cluster where the row is stored. -All performant queries supply the partition key in the query. +* Partition Key: The required component of the primary key that determines which node in the Cassandra cluster stores a given row. For efficient execution, queries must include the partition key. * Row: Contains a collection of columns identified by a unique primary key made up of the partition key and optionally additional clustering keys. diff --git a/doc/modules/cassandra/pages/managing/tools/cqlsh.adoc b/doc/modules/cassandra/pages/managing/tools/cqlsh.adoc index 2b5c20b1d9f4..2ae042a85dfa 100644 --- a/doc/modules/cassandra/pages/managing/tools/cqlsh.adoc +++ b/doc/modules/cassandra/pages/managing/tools/cqlsh.adoc @@ -334,7 +334,7 @@ EXPAND OFF === `ELAPSED` -Enables or disables the printing of the elapsed time for a query. Except a quick evalution +Enables or disables the printing of the elapsed time for a query. Except a quick evaluation of how long a CQL statement took, this is also a complementary output to `TRACING` (if enabled). A user can debug if there is a communication delay to a node or not comparing the timestamps as `TRACING` tracks the time elapsed only on the server side. @@ -469,7 +469,7 @@ See `shared-copy-options` for options that apply to both `COPY TO` and `PAGESIZE`:: The number of rows to fetch in a single page. Defaults to 1000. `PAGETIMEOUT`:: - By default the page timeout is 10 seconds per 1000 entries in the page + By default, the page timeout is 10 seconds per 1000 entries in the page size or 10 seconds if pagesize is smaller. `BEGINTOKEN`, `ENDTOKEN`:: Token range to export. Defaults to exporting the full ring.