docs(various): Improve Readability (#4768)

Signed-off-by: Ryan Russell <git@ryanrussell.org>

Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>

CONTRIBUTING.md

@@ -102,7 +102,7 @@ cargo test --workspace
 ### Enabling logging in tests
 
 To enable logging to stderr during a run of `cargo test` set the Rust
-`RUST_LOG` environment varable. For example, to see all INFO messages:
+`RUST_LOG` environment variable. For example, to see all INFO messages:
 
 ```shell
 RUST_LOG=info cargo test --workspace

README.md

@@ -166,7 +166,7 @@ The rest of these instructions assume you are in this directory.
 
 ### Configure the server
 
-InfluxDB IOx can be configured using either environment variables or a configutation file,
+InfluxDB IOx can be configured using either environment variables or a configuration file,
 making it suitable for deployment in containerized environments.
 
 For a list of configuration options, run `influxdb_iox --help`.
@@ -335,7 +335,7 @@ status: SERVING
 To manually invoke one of the gRPC APIs, use a gRPC CLI client such as [grpcurl](https://github.com/fullstorydev/grpcurl).
 
 Tonic (the gRPC server library we're using) currently doesn't have support for gRPC reflection, hence you must pass all `.proto` files to your client.
-You can find a conventient `grpcurl` wrapper that does that in the `scripts` directory:
+You can find a convenient `grpcurl` wrapper that does that in the `scripts` directory:
 
 ```console
 $ ./scripts/grpcurl -plaintext 127.0.0.1:8082 list
@@ -357,6 +357,6 @@ We welcome community contributions from anyone!
 
 Read our [Contributing Guide](CONTRIBUTING.md) for instructions on how to run tests and how to make your first contribution.
 
-## Architecture and Technical Documenation
+## Architecture and Technical Documentation
 
 There are a variety of technical documents describing various parts of IOx in the [docs](docs) directory.

compactor/src/compact.rs

@@ -441,7 +441,7 @@ impl Compactor {
 
         let mut file_count = 0;
 
-        // Compact, persist,and update catalog accordingly for each overlaped file
+        // Compact, persist,and update catalog accordingly for each overlapped file
         let mut tombstones = BTreeMap::new();
         let mut output_file_count = 0;
         let sequencer_id = compact_and_upgrade
@@ -611,7 +611,7 @@ impl Compactor {
         tombstones
     }
 
-    // Compact given files. The given files are either overlaped or contiguous in time.
+    // Compact given files. The given files are either overlapped or contiguous in time.
     // The output will include 2 CompactedData sets, one contains a large amount of data of
     // least recent time and the other has a small amount of data of most recent time. Each
     // will be persisted in its own file. The idea is when new writes come, they will
@@ -1161,7 +1161,7 @@ mod tests {
         let count = catalog.count_level_0_files(sequencer.sequencer.id).await;
         assert_eq!(count, 1);
 
-        // One overlaped tombstone
+        // One overlapped tombstone
         let tombstone = table
             .with_sequencer(&sequencer)
             .create_tombstone(20, 6000, 12000, "tag1=VT")

docs/dedup_and_sort.md

@@ -72,7 +72,7 @@ Figure 2: A simplified query plan that scans all eight chunks of two partitions
 ```
 
 If many queries read these two partitions, IOx has to build the same query plan above which we think suboptimal because of sort and deduplication. To avoid this suboptimal query plan, IOx is designed to:
-1. Data in each partition is frequently compacted to only contain a few non-overlaped and non-duplicated chunks as shown in Figure 3 which will help scan fewer chunks and eliminate the `Sort` and `Dedup` operators as illustrated in Figure 4.
+1. Data in each partition is frequently compacted to only contain a few non-overlapped and non-duplicated chunks as shown in Figure 3 which will help scan fewer chunks and eliminate the `Sort` and `Dedup` operators as illustrated in Figure 4.
 2. All **persisted chunks of the same partition are sorted on the same key** to avoid resorting before deduplication. So the plan in Figure 2 is only seen sometimes in IOx (mostly in Ingester and Querier with data sent back from Ingester), instead, you will mostly see the plan in Figure 4 (for data in Figure 3) or in Figure 6 (for data of Figure 5)
 
 ```text
@@ -163,7 +163,7 @@ Chunk 4  | tag2, tag3    | tag2, tag3, time | tag1, tag2, tag3, time
 Chunk 5  | tag1, tag4    | tag1, tag4, time | tag1, tag2, tag3, tag4, time (need catalog update)
 ```
 
-Assuming Chunk 2 and Chunk 3 overlap. As explained above, a query that needs to read those two chunks have to deduplicate them. Their sort key will be read from the Partition Sort Key which is `tag1, tag2, tag3, tag4, time`. Since those chunks do not inlcude `tag4`, it will be eliminated and the actually sort key of those 2 chunks is `tag1, tag2, tag3, time`. To ensure those two chunks have the same columns, IOx adds missing columns with all NULL values while scanning them(`tag1` and `tag3` to Chunk 2 and `tag2` to Chunk 3). Even though adding NULL columns `tag1` and `tag3` to Chunk 2 makes its primary key and sort key now `tag1, tag2, tag3, time`, it is still sorted as it was on its original `tag2, time` only. Hence no sorted needed for Chunk 2. Same to Chunk 3. Figure 7 shows the query plan that reads Chunk 2 and Chunk 3.
+Assuming Chunk 2 and Chunk 3 overlap. As explained above, a query that needs to read those two chunks have to deduplicate them. Their sort key will be read from the Partition Sort Key which is `tag1, tag2, tag3, tag4, time`. Since those chunks do not include `tag4`, it will be eliminated and the actually sort key of those 2 chunks is `tag1, tag2, tag3, time`. To ensure those two chunks have the same columns, IOx adds missing columns with all NULL values while scanning them(`tag1` and `tag3` to Chunk 2 and `tag2` to Chunk 3). Even though adding NULL columns `tag1` and `tag3` to Chunk 2 makes its primary key and sort key now `tag1, tag2, tag3, time`, it is still sorted as it was on its original `tag2, time` only. Hence no sorted needed for Chunk 2. Same to Chunk 3. Figure 7 shows the query plan that reads Chunk 2 and Chunk 3.
 
 ```text
                   ┌────────────────────────────────────────────────────────────────┐                 

docs/valgrind.md

@@ -35,14 +35,14 @@ rules, here are some useful links:
 - <https://www.valgrind.org/docs/manual/manual-core.html#manual-core.suppress>
 - <https://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto>
 
-You may also use the `--gen-suppressions=all` to auto-generate supppression rules:
+You may also use the `--gen-suppressions=all` to auto-generate suppression rules:
 
 ```console
 $ ./scripts/valgrind_leak --gen-suppressions=all ./target/debug/influxdb_iox run ...
 ```
 
 Note that Rust symbols like `influxdb_iox::main` are mangled in a way that [Valgrind] cannot parse them (e.g. to
-`_ZN12influxdb_iox4main17h940b8bf02831a9d8E`). The easiest way is to replace `::` w/ `*` and prepand and append an
+`_ZN12influxdb_iox4main17h940b8bf02831a9d8E`). The easiest way is to replace `::` w/ `*` and prepend and append an
 additional wildcard `*`, so `influxdb_iox::main` gets `*influxdb_iox*main*`.
 
 ## Massif

influxdb2_client/README.md

@@ -4,7 +4,7 @@ This crate contains a work-in-progress implementation of a Rust client for the [
 
 This client is not the Rust client for IOx. You can find that [here](../influxdb_iox_client).
 
-The InfluxDB IOx project plans to focus its efforts on the subset of the API which are most relevent to IOx, but we accept (welcome!) PRs for adding the other pieces of functionality.
+The InfluxDB IOx project plans to focus its efforts on the subset of the API which are most relevant to IOx, but we accept (welcome!) PRs for adding the other pieces of functionality.
 
 
 ## Design Notes

ingester/src/test_util.rs

@@ -703,7 +703,7 @@ pub fn make_ingester_data(two_partitions: bool, loc: DataLocation) -> IngesterDa
     let mut sequencers = BTreeMap::new();
     sequencers.insert(seq_id, seq_data);
 
-    // Ingester data that inlcudes one sequencer/shard
+    // Ingester data that includes one sequencer/shard
     IngesterData::new(
         object_store,
         catalog,
@@ -748,7 +748,7 @@ pub async fn make_ingester_data_with_tombstones(loc: DataLocation) -> IngesterDa
     let mut sequencers = BTreeMap::new();
     sequencers.insert(seq_id, seq_data);
 
-    // Ingester data that inlcudes one sequencer/shard
+    // Ingester data that includes one sequencer/shard
     IngesterData::new(
         object_store,
         catalog,
@@ -905,7 +905,7 @@ fn make_first_partition_data(
     table_id: TableId,
     table_name: &str,
 ) -> (PartitionData, SequenceNumber) {
-    // In-memory data inlcudes these rows but split between 3 groups go into
+    // In-memory data includes these rows but split between 3 groups go into
     // different batches of parittion p1
     // let expected = vec![
     //         "+------------+-----+------+--------------------------------+",

iox_catalog/README.md

@@ -2,7 +2,7 @@
 
 This crate contains the code for the IOx Catalog. This includes the definitions of namespaces,
 their tables, the columns of those tables and their types, what Parquet files are in object storage
-and delete tombstones. There's also some configuration information that the overal distributed
+and delete tombstones. There's also some configuration information that the overall distributed
 system uses for operation.
 
 To run this crate's tests you'll need Postgres installed and running locally. You'll also need to

iox_query/src/lib.rs

@@ -317,7 +317,7 @@ impl QueryChunkMeta for Arc<dyn QueryChunk> {
     }
 }
 
-/// return true if all the chunks inlcude statistics
+/// return true if all the chunks include statistics
 pub fn chunks_have_stats(chunks: &[Arc<dyn QueryChunk>]) -> bool {
     // If at least one of the provided chunk cannot provide stats,
     // do not need to compute potential duplicates. We will treat

iox_query/src/provider.rs

@@ -585,7 +585,7 @@ impl Deduplicater {
                     // This happens either:
                     //   . In the Ingester to compact ingesting data that is not sorted and not
                     //     deduplicated yet
-                    //   . In the Querier that also inlcudes data sent from Ingester that is also
+                    //   . In the Querier that also includes data sent from Ingester that is also
                     //     not yet sorted.
                     //        Note: Data sent from Ingester is already deduplicated but if it
                     //        overlaps with other chunks, it may include duplicated data with those
@@ -2908,7 +2908,7 @@ mod test {
             )
             .unwrap();
 
-        // plan should inlcude SortExec because chunks are not yet sorted on the specified sort_key
+        // plan should include SortExec because chunks are not yet sorted on the specified sort_key
         let plan_str = format!("{}", displayable(plan.as_ref()).indent());
         // println!("{}", plan_str);
         // The plan should look like this

parquet_file/src/metadata.rs

@@ -793,7 +793,7 @@ fn read_statistics_from_parquet_row_group(
                 stats,
             });
         } else {
-            debug!(?field, "Provided schema of the field does not inlcude IOx Column Type such as Tag, Field, Time");
+            debug!(?field, "Provided schema of the field does not include IOx Column Type such as Tag, Field, Time");
         }
     }
 

parquet_file/tests/metadata.rs

@@ -195,7 +195,7 @@ async fn test_decoded_many_columns_with_null_cols_iox_metadata() {
     // And the metadata the batch would be encoded with if it came through the
     // IOx write path.
 
-    // sort key inlcudes all columns with time column last
+    // sort key includes all columns with time column last
     let mut sort_key_data = Vec::with_capacity(num_cols);
     for i in 1..num_cols {
         let col = make_col_name(i);

sqlx-hotswap-pool/README.md

@@ -3,7 +3,7 @@
 This crate implements a workaround for the lack of support for password rotation in the `sqlx` crate.
 
 There is an upstream ticket for this [Support rotating passwords #445](https://github.com/launchbadge/sqlx/issues/445).
-This crate offfers a more quick&dirty solution to the problem.
+This crate offers a more quick&dirty solution to the problem.
 
 ## Problem
 
@@ -22,7 +22,7 @@ This workaround has been designed to solve the problem of updating credentials,
 
 If the credentials refresh happen before the existing credentials are invalidated, references to the previous pool can still be used for some time.
 
-If the credentials refresh contextually invalidates the exsting credentials, the process will experience connection errors if they used the pool before it has been updated (and if they cloned the `Arc` before the `update` method has been called).
+If the credentials refresh contextually invalidates the existing credentials, the process will experience connection errors if they used the pool before it has been updated (and if they cloned the `Arc` before the `update` method has been called).
 
 Already open connections will keep working in both cases.