Designing an Azure Cosmos DB (SQL API) container that will hold millions of documents, each with many properties and no single property that provides a clear partitioning key. To evenly distribute traffic across partitions over time, which two partition key approaches are acceptable?

The correct approaches, concatenating multiple property values with a random suffix and appending a hash suffix to a property value, both create high-cardinality partition keys that distribute data and requests evenly across logical partitions. This prevents hot partitions and ensures scalability. A single property value that does not appear frequently can still lead to hot partitions if its values are not uniformly accessed. A value containing the collection name is a static value and would place all documents into a single logical partition, severely limiting scalability. A single property value that appears frequently would result in a small number of logical partitions, each containing many documents, leading to hot partitions and poor performance.