doc: escape tags in markdown in prepration for docusaurus2 (#14379)

Co-authored-by: Victoria Lim <vtlim@users.noreply.github.com>
This commit is contained in:
317brian 2023-06-08 11:26:18 -07:00 committed by GitHub
parent 12e8fa5c97
commit ff577a69a5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 4 additions and 4 deletions

View File

@ -29,7 +29,7 @@ Druid has a distributed architecture that is designed to be cloud-friendly and e
The following diagram shows the services that make up the Druid architecture, how they are typically organized into servers, and how queries and data flow through this architecture.
<img src="../assets/druid-architecture.png" width="800"/>
![Druid architecture](../assets/druid-architecture.png)
The following sections describe the components of this architecture.
@ -107,7 +107,7 @@ example, a single day, if your datasource is partitioned by day). Within a chunk
[_segments_](../design/segments.md). Each segment is a single file, typically comprising up to a few million rows of data. Since segments are
organized into time chunks, it's sometimes helpful to think of segments as living on a timeline like the following:
<img src="../assets/druid-timeline.png" width="800" />
![Segment timeline](../assets/druid-timeline.png)
A datasource may have anywhere from just a few segments, up to hundreds of thousands and even millions of segments. Each
segment is created by a MiddleManager as _mutable_ and _uncommitted_. Data is queryable as soon as it is added to

View File

@ -43,7 +43,7 @@ Druid processes can be deployed any way you like, but for ease of deployment we
* **Query**
* **Data**
<img src="../assets/druid-architecture.png" width="800"/>
![Druid architecture](../assets/druid-architecture.png)
This section describes the Druid processes and the suggested Master/Query/Data server organization, as shown in the architecture diagram above.

View File

@ -237,7 +237,7 @@ Dimension objects can have the following components:
| Field | Description | Default |
|-------|-------------|---------|
| type | Either `auto`, `string`, `long`, `float`, `double`, or `json`. For the `auto` type, Druid determines the most appropriate type for the dimension and assigns one of the following: STRING, ARRAY<STRING>, LONG, ARRAY<LONG>, DOUBLE, ARRAY<DOUBLE>, or COMPLEX<json> columns, all sharing a common 'nested' format. When Druid infers the schema with schema auto-discovery, the type is `auto`. | `string` |
| type | Either `auto`, `string`, `long`, `float`, `double`, or `json`. For the `auto` type, Druid determines the most appropriate type for the dimension and assigns one of the following: STRING, ARRAY<STRING\>, LONG, ARRAY<LONG\>, DOUBLE, ARRAY<DOUBLE\>, or COMPLEX<json\> columns, all sharing a common 'nested' format. When Druid infers the schema with schema auto-discovery, the type is `auto`. | `string` |
| name | The name of the dimension. This will be used as the field name to read from input records, as well as the column name stored in generated segments.<br /><br />Note that you can use a [`transformSpec`](#transformspec) if you want to rename columns during ingestion time. | none (required) |
| createBitmapIndex | For `string` typed dimensions, whether or not bitmap indexes should be created for the column in generated segments. Creating a bitmap index requires more storage, but speeds up certain kinds of filtering (especially equality and prefix filtering). Only supported for `string` typed dimensions. | `true` |
| multiValueHandling | For `string` typed dimensions, specifies the type of handling for [multi-value fields](../querying/multi-value-dimensions.md). Possible values are `array` (ingest string arrays as-is), `sorted_array` (sort string arrays during ingestion), and `sorted_set` (sort and de-duplicate string arrays during ingestion). This parameter is ignored for types other than `string`. | `sorted_array` |