Konfiguration der Beacon-Partitionierung

In diesem Abschnitt wird beschrieben, wie die Beacon-Partitionierung konfiguriert ist und wie sie sich auf die Beacon-Ableitung, das Abfrageverhalten und die Sicherheitsgarantien auswirkt. Die Partitionierung gilt für alle Beacons und bietet ein konsistentes Modell für die Verteilung von Werten, die Begrenzung von Frequenzverlusten und die Steuerung des Abfrage-Fanouts. Wenn Sie wissen, wie Partitionsanzahl und Partitionszuweisung zusammenarbeiten, können Sie Konfigurationen auswählen, die Datenschutz, Leistung und Betriebssicherheit in Einklang bringen.

Überblick über die Partitionskonfiguration

Die Partitionierung wird auf logischer Tabellenebene konfiguriert und gilt einheitlich für alle Standard-Beacons. Jede logische Tabelle definiert ein einzelnes Partitionierungsschema, das durch zwei Parameter gesteuert wird: Maximum und Standard. NumberOfPartitions NumberOfPartitions

maximal NumberOfPartitions

Das maximumNumberOfPartitions Feld definiert die Obergrenze für die Anzahl der Partitionen, die die Tabelle während ihrer Lebensdauer verwenden darf. Dieser Wert:

• Bestimmt den maximal möglichen Abfrage-Fan-Out.

• Kann erhöht werden, wenn sich das Datenvolumen oder die Sicherheitsanforderungen ändern.

• Darf nicht verringert werden, nachdem Daten vorhanden sind.

Standard NumberOfPartitions

Das defaultNumberOfPartitions Feld gibt an, wie viele Partitionen von Standard-Beacons verwendet werden, die ihre eigene Partitionsanzahl nicht explizit angeben. Dieser Wert:

• Muss befriedigen1 ≤ defaultNumberOfPartitions ≤ maximumNumberOfPartitions ≤ 255.

• Kann erhöht werden, darf aber niemals verringert werden, nachdem Artikel geschrieben wurden.

• Setzen Sie diesen Wert auf denselben Wert wie, maximumNumberOfPartitions sofern Sie nicht absichtlich einschränken möchten, wie viele Partitionen ein einzelner Beacon verwenden kann. Die Begrenzung der Anzahl der Partitionen für ein Beacon kann nützlich sein, wenn ein Attribut einen kleinen oder gut verstandenen Wertebereich hat, wenn das Attribut sehr häufig abgefragt wird oder wenn Sie die Abfrageauslastung und die Abfragekosten reduzieren möchten. Durch das Einschränken von Partitionen werden einige Vorteile der Zufälligkeit und Verteilung gegen eine verbesserte Effizienz und Vorhersagbarkeit von Abfragen eingetauscht. Bei den meisten Attributen bietet die Verwendung des gesamten Satzes verfügbarer Partitionen das beste Gleichgewicht zwischen Datenschutz und Flexibilität.

Partitionszuweisung mit einem PartitionSelector

Eine vom Benutzer bereitgestellte Funktion namens PartitionSelector weist jedes Element beim Schreiben einer Partition zu. Sie bestimmt die Partitionsnummer:

GetPartitionNumber(item, numberOfPartitions, logicalTableName) -> PartitionNumber
    

Sie können Domänenwissen im Selektor kodieren, um:

• Verteilen Sie hochfrequente Werte auf mehrere Partitionen.

• Weisen Sie einer einzelnen Partition konsistent seltene Werte zu.

• Verwenden Sie den standardmäßigen Zufallsselektor für allgemeine Workloads.

Die Beacon-Ableitung beinhaltet die ausgewählte Partitionsnummer, die niemals direkt im verschlüsselten Element oder Beacon-Wert offengelegt wird.

Die Konfiguration von Partitionen zählt auf Standard-Beacons

Standardmäßig verwenden alle Standard-Beacons. defaultNumberOfPartitions Sie können optional ein einzelnes Beacon einschränken, indem Sie Folgendes festlegen. numberOfPartitions Dies ist nützlich, wenn:

• Die zugrunde liegenden Daten sind bereits annähernd gleichmäßig verteilt.

• Bei Abfrage-Workloads wird erwartet, dass sehr kleine Ergebnismengen zurückgegeben werden.

• Durch die Reduzierung des Abfrage-Fan-Outs wird die Leistung erheblich verbessert.

Bei eingeschränkten Beacons wird die effektive Partition, die bei der Beacon-Ableitung verwendet wird, wie folgt berechnet:

effectivePartition = itemPartition % numberOfPartitions
    

Wenden Sie Einschränkungen auf Beacon-Ebene nur bei Bedarf und mit entsprechender Sicherheitsüberprüfung an. Falsche Einschränkungen können die Anonymitätsgarantien schwächen oder dazu führen, dass vorhandene Elemente bei Abfragen nicht erreichbar sind.

Beispiel für eine Konfigurationssyntax

Java

List<StandardBeacon> standardBeaconList = new ArrayList<>();
StandardBeacon exampleStandardBeacon = StandardBeacon.builder()
    .name("beaconName")
    .length(beaconLengthInBits)
    .numberOfPartitions(number)
    .build();
standardBeaconList.add(exampleStandardBeacon);

C# / .NET

var standardBeaconList = new List<StandardBeacon>();
StandardBeacon exampleStandardBeacon = new StandardBeacon
  {
    Name = "beaconName",
    Length = 10,
    NumberOfPartitions = number
  };
standardBeaconList.Add(exampleStandardBeacon);
                        

Rust

let standard_beacon_list = vec![
    StandardBeacon::builder()
        .name("beacon_name")
        .length(beacon_length_in_bits)
        .number_of_partitions(number)
        .build()?,