Projektujesz kontener Azure Cosmos DB (SQL API), który będzie przechowywał miliony dokumentów, każdy z wieloma właściwościami i bez pojedynczej właściwości, która stanowiłaby wyraźny klucz partycjonowania. Aby równomiernie rozłożyć ruch między partycjami w czasie, które dwa podejścia do klucza partycjonowania są akceptowalne?

Prawidłowe odpowiedzi to "połączenie wielu wartości właściwości z dołączonym losowym sufiksem" i "sufiks skrótu dołączony do wartości właściwości". Oba podejścia mają na celu stworzenie klucza partycjonowania o wysokiej kardynalności i równomiernym rozłożeniu danych, co jest kluczowe dla wydajności Azure Cosmos DB. Dołączenie losowego sufiksu lub sufiksu skrótu pomaga uniknąć gorących partycji, nawet jeśli początkowe wartości właściwości są ograniczone. Nieprawidłowe opcje: "pojedyncza wartość właściwości, która nie pojawia się często w dokumentach" – Niska częstotliwość występowania nie gwarantuje równomiernego rozłożenia, a może prowadzić do gorących partycji, jeśli ta wartość jest często używana w zapytaniach. "wartość zawierająca nazwę kolekcji" – Nazwa kolekcji jest statyczna i taka sama dla wszystkich dokumentów, co spowodowałoby, że wszystkie dokumenty trafiłyby do jednej partycji logicznej, tworząc ekstremalną gorącą partycję. "pojedyncza wartość właściwości, która często pojawia się w dokumentach" – Taka wartość jest bardzo złym kluczem partycjonowania, ponieważ spowoduje, że wiele dokumentów o tej samej wartości trafi do tej samej partycji logicznej, tworząc gorącą partycję.