Recommend schema v9 and v10 for production (cortexproject#2896)

* Recommend schema v10 for production

Signed-off-by: Marco Pracucci <marco@pracucci.com>

* Updated recommended schema

Signed-off-by: Marco Pracucci <marco@pracucci.com>

* Clarified recommended version

Signed-off-by: Marco Pracucci <marco@pracucci.com>

Author: pracucci

docs/architecture.md

@@ -48,7 +48,7 @@ Internally, the access to the chunks storage relies on a unified interface calle
 
 The chunk and index format are versioned, this allows Cortex operators to upgrade the cluster to take advantage of new features and improvements. This strategy enables changes in the storage format without requiring any downtime or complex procedures to rewrite the stored data. A set of schemas are used to map the version while reading and writing time series belonging to a specific period of time.
 
-The current schema recommendation is the **v10 schema** (v11 is still experimental). For more information about the schema, please check out the [Schema](configuration/schema-config-reference.md) documentation.
+The current schema recommendation is the **v9 schema** for most use cases and **v10 schema** if you expect to have very high cardinality metrics (v11 is still experimental). For more information about the schema, please check out the [Schema](configuration/schema-config-reference.md) documentation.
 
 ### Blocks storage (experimental)
 

docs/configuration/schema-config-reference.md

@@ -7,7 +7,7 @@ slug: schema-configuration
 
 Cortex uses a NoSQL Store to store its index and optionally an Object store to store its chunks. Cortex has overtime evolved its schema to be more optimal and better fit the use cases and query patterns that arose.
 
-Currently there are 9 schemas that are used in production but we recommend running with `v9` schema when possible. You can move from one schema to another if a new schema fits your purpose better, but you still need to configure Cortex to make sure it can read the old data in the old schemas.
+Currently there are 11 schemas that are used in production but we recommend running with the **v9 schema** for most use cases and **v10 schema** if you expect to have very high cardinality metrics. You can move from one schema to another if a new schema fits your purpose better, but you still need to configure Cortex to make sure it can read the old data in the old schemas.
 
 You can configure the schemas using a YAML config file, that you can point to using the `-schema-config-file` flag. It has the following YAML spec:
 
@@ -23,7 +23,7 @@ from: <string>
 store: <string>
 # The object client to use. If none is specified, `store` is used for storing chunks as well. Valid options: s3, aws-dynamo, bigtable, bigtable-hashed, gcs, cassandra, filesystem.
 object_store: <string>
-# The schema version to use. Valid ones are v1, v2, v3,... v6, v9, v10, v11. Recommended for production: v9.
+# The schema version to use. Valid ones are v1, v2, v3,... v6, v9, v10, v11. Recommended for production: v9 for most use cases or v10 if you expect to have very high cardinality metrics.
 schema: <string>
 index: <periodic_table_config>
 chunks: <periodic_table_config>