title: How to choose a good value set for CosmosDB id field?
body: <p><a href="https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.documents.resource.id?view=azure-dotnet" rel="nofollow noreferrer">According to docs</a>, the property <code>id</code> is special in Azure CosmosDB documents as it must always be set and have unique value per partition. Also it has additional restrictions on its content : </p>
  
  <blockquote>
    <p>The following characters are restricted and cannot be used in the Id
    property: '/', '\', '?', '#'</p>
  </blockquote>
  
  <p>Obviously, this field is one of document "keys" (in addition to <code>_rid</code>) and used somehow in internal plumbing. Other than the restrictions above, it is unclear how exactly is this key used internally and more importantly for practitioners,<strong>which values constitute technically better ids than others?</strong></p>
  
  <p><strong>Wild guess 1:</strong> For example, from some DB worlds, one would prefer short primary key values, since the PK would be included in index entries and shorter keys would allow more compact index for storage and lookup. Would id field length matter at all besides the one-time storage cost?</p>
  
  <p><strong>Wild guess 2:</strong> in some systems better throughput is achieved if common prefixes are avoided in names (i.e. <a href="https://docs.microsoft.com/en-us/azure/storage/common/storage-performance-checklist#subheading47" rel="nofollow noreferrer">azure storage container/blob names</a>) and even suggest to add a small random hash as prefix. Does cosmosDB care about id prefix similarities?</p>
  
  <p>Anything else one should consider?</p>
  
  <p><strong>EDIT:</strong> Clarification, I'm interested in what's good for the cosmosDB server storage/execution side, provided my data model is still in design and/or has multiple keys available the data designer can choose from.</p>