Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Bewährte Methoden für das Abfragen und Scannen von Daten in DynamoDB
In diesem Abschnitt werden einige bewährte Methoden für `Query` und `Scan`-Vorgänge in Amazon DynamoDB behandelt.
## Leistungsüberlegungen für Scans
Im Allgemeinen sind `Scan`-Vorgänge weniger effizient als andere Operationen in DynamoDB. Ein `Scan`-Vorgang scannt immer die gesamte Tabelle oder den Sekundärindex. Anschließend werden die Werte herausgefiltert, um das gewünschte Ergebnis zu erhalten, wobei im Wesentlichen ein zusätzlicher Schritt zur Entfernung von Daten aus dem Ergebnissatz erfolgt.
Vermeiden Sie, falls möglich, die Verwendung eines `Scan`-Vorgangs für eine große Tabelle oder einen Index mit einem Filter, der viele Ergebnisse entfernt. Außerdem verlangsamt sich der `Scan`-Vorgang, während eine Tabelle oder ein Index wächst. Die `Scan`-Operation untersucht jedes Element auf die angeforderten Werte und kann den bereitgestellten Durchsatz für eine große Tabelle oder Index in einer einzigen Operation verbrauchen. Für schnellere Reaktionszeiten sollten Sie Ihre Tabellen und Indizes so entwerfen, dass Ihre Anwendungen `Query` anstatt `Scan` verwenden können. (Für Tabellen können Sie auch die Verwendung von `GetItem` und in Betracht ziehen `BatchGetItem` APIs.)
Alternativ können Sie eine Anwendung so entwickeln, dass bei der Nutzung der `Scan`-Operationen die Auswirkung auf Ihre Anforderungsrate minimiert wird. Dies kann auch Modellierungen beinhalten, bei denen es möglicherweise effizienter ist, einen globalen sekundären Index anstelle eines `Scan`-Vorgangs zu verwenden. Weitere Informationen zu diesem Vorgang finden Sie im folgenden Video.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/LM84N-E_b_M)
## Vermeiden Sie plötzliche Spitzen in der Leseaktivität
Wenn Sie eine Tabelle erstellen, legen Sie ihre Anforderungen der Lese- und Schreibkapazitätseinheiten fest. Die Kapazitätseinheiten werden für Lesevorgänge als die Anzahl der Strongly-Consistent-4-KB-Datenleseanforderungen pro Sekunde ausgedrückt. Für Eventually-Consistent-Lesevorgänge besteht eine Kapazitätseinheit aus zwei 4-KB-Leseanforderungen pro Sekunde. Ein `Scan`-Vorgang führt standardmäßig letztendliche-Lesekonsistenz-Lesevorgänge durch und kann bis zu 1 MB (eine Seite) an Daten zurückgeben. Daher kann eine einzelne -`Scan`Anforderung (1 MB Seitengröße/ 4 KB Elementgröße)/2 (Eventually-Consistent-Lesevorgänge) = 128 Leseoperationen verbrauchen. Wenn Sie stattdessen Strongly-Consistent-Lesevorgänge anfordern würden, würde die `Scan`-Operation doppelt so viel bereitgestellten Durchsatz verbrauchen – 256 Leseoperationen.
Das stellt eine plötzliche Nutzungsspitze im Vergleich zu der konfigurierten Lesekapazität für die Tabelle dar. Diese Nutzung von Kapazitätseinheiten durch einen Scan verhindert, dass andere potenziell wichtigere Anforderungen für dieselbe Tabelle die verfügbaren Kapazitätseinheiten verwenden. Daher erhalten Sie wahrscheinlich eine `ProvisionedThroughputExceeded`-Ausnahme für diese Anforderungen.
Beachten Sie, dass nicht nur die plötzliche Erhöhung der Kapazitätseinheiten, die `Scan` verwendet, ein Problem darstellt. Der Scan wird wahrscheinlich auch alle seine Kapazitätseinheiten von derselben Partition verbrauchen, da er Leseelemente anfordert, die auf der Partition nebeneinander liegen. Dies bedeutet, dass die Anforderung auf dieselbe Partition trifft, sodass alle Kapazitätseinheiten verbraucht werden und andere Anforderungen an die Partition gedrosselt werden. Wenn die Anforderung zum Lesen von Daten über mehrere Partitionen verteilt ist, dann würde die Operation eine bestimmte Partition nicht drosseln.
Das folgende Diagramm veranschaulicht die Auswirkung einer plötzlichen Nutzungsspitze der Kapazitätseinheiten durch `Query` und `Scan`-Operationen und deren Auswirkung auf andere Anforderungen für dieselbe Tabelle.
![\[Vier verschiedene Szenarien, die bereitgestellte Durchsatzintervalle, Anforderungen sowie gute und schlechte Ergebnisse in einer Tabelle zeigen.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/ThroughputIntervals.png)
Wie hier dargestellt, kann sich die Auslastungsspitze auf verschiedene Weise auf den bereitgestellten Durchsatz der Tabelle auswirken:
1. Gut: Gleichmäßige Verteilung von Anfragen und Größe
1. Nicht so gut: Häufige Anfragen in Spitzenlasten
1. Schlecht: Ein paar zufällige große Anfragen
1. Schlecht: Große Scan-Operationen
Anstatt eine große `Scan`-Operation zu nutzen, können Sie die folgenden Techniken verwenden, um die Auswirkung auf einen Scan eines bereitgestellten Durchsatzes einer Tabelle zu minimieren.
+ **Reduzieren der Seitengröße**
Da eine Scan-Operation eine ganze Seite (standardmäßig 1 MB) liest, können Sie die Auswirkung auf die Scan-Operation verringern, indem Sie eine kleinere Seitengröße festlegen. Die `Scan`-Operation bietet den Parameter *Limit* an, den Sie verwenden können, um die Seitengröße für Ihre Anforderung festzulegen. Jede `Query` oder `Scan`-Anforderung, die über eine kleinere Seitengröße verfügt, verwendet weniger Leseoperationen und erzeugt eine „Pause“ zwischen jeder Anforderung. Angenommen, jedes Element hat eine Größe von 4 KB und Sie legen die Seitengröße auf 40 Elemente fest. Eine `Query`-Anforderung würde dann nur 20 schließlich konsistente Lesevorgänge oder 40 stark konsistente Lesevorgänge verbrauchen. Mit einer größeren Anzahl von kleineren `Query`- oder `Scan`-Operationen können die anderen wichtigen Anforderungen ohne Einschränkung erfolgreich sein.
+ **Isolieren von Scan-Operationen**
DynamoDB ist für eine einfache Skalierbarkeit ausgelegt. Daher kann eine Anwendung Tabellen für unterschiedliche Zwecke erstellen, möglicherweise sogar Inhalte über mehrere Tabellen duplizieren. Sie möchten Scans in einer Tabelle durchführen, die keinen „unternehmenskritischen“ Datenverkehr annimmt. Einige Anwendungen bearbeiten diese Last, indem sie den Datenverkehr stündlich zwischen zwei Tabellen austauschen – eine für den kritischen Datenverkehr und eine für die Buchhaltung. Andere Anwendungen können dies tun, indem Sie jeden Schreibvorgang in zwei Tabellen durchführen: eine "unternehmenskritische"- und eine "Schatten"-Tabelle.
Konfigurieren Sie Ihre Anwendung so, dass jede Anforderung wiederholt wird, die einen Antwortcode empfängt, der anzeigt, dass Sie Ihren bereitgestellten Durchsatz überschritten haben. Oder erhöhen Sie den bereitgestellten Durchsatz für Ihre Tabelle mithilfe der `UpdateTable`-Operation. Wenn Ihr Workload temporäre Spitzen aufweist, die dazu führen, dass der Durchsatz gelegentlich die bereitgestellte Stufe überschreitet, wiederholen Sie die Anforderung mit einem exponentiellen Backoff. Weitere Informationen zum Implementieren eines exponentiellen Backoff finden Sie unter [Wiederholversuche bei Fehlern und exponentielles Backoff](Programming.Errors.md#Programming.Errors.RetryAndBackoff).
## Nutzen von parallelen Scans
Viele Anwendungen können von parallelen `Scan`-Operationen eher profitieren als sequenzielle Scans. Zum Beispiel kann eine Anwendung, die eine große Tabelle historischer Daten verarbeitet, einen parallelen Scan viel schneller durchführen als einen sequenziellen Scan. Mehrere Worker-Threads in einem Hintergrund-„Sweeper“-Prozess könnten eine Tabelle mit einer niedrigen Priorität scannen, ohne den Datenverkehr der Produktion zu beeinflussen. In jedem dieser Beispiele wird ein paralleler `Scan` so verwendet, dass die bereitgestellten Durchsatzressourcen für andere Anwendungen nicht behindert werden.
Obwohl parallele Scans nützlich sein können, stellen sie möglicherweise hohe Ansprüche an den bereitgestellten Durchsatz. Bei einem parallelen Scan verfügt Ihre Anwendung über mehrere Worker, die alle gleichzeitig `Scan`-Vorgänge ausführen. Dies kann die bereitgestellte Lesekapazität Ihrer Tabelle schnell verbrauchen. In diesem Fall werden andere Anwendungen, die auf die Tabelle zugreifen müssen, möglicherweise eingeschränkt.
Ein paralleler Scan kann die richtige Wahl sein, wenn die folgenden Bedingungen erfüllt sind:
+ Die Tabellengröße ist 20 GB oder größer.
+ Der bereitgestellte Lesedurchsatz der Tabelle wird nicht voll ausgeschöpft.
+ Sequenzielle `Scan`-Operationen sind zu langsam.
### Wählen TotalSegments
Die beste Einstellung für `TotalSegments` hängt ab von Ihren spezifischen Daten, den Einstellungen des bereitgestellten Durchsatzes der Tabelle und Ihren Leistungsanforderungen. Sie müssen wahrscheinlich experimentieren, um alles so hinzubekommen, dass es passt. Wir empfehlen, dass Sie mit einem einfachen Verhältnis beginnen, z. B. ein Segment pro 2 GB Daten. Beispiel: Sie können für eine 30 GB Tabelle `TotalSegments` auf 15 (30 GB/2 GB) festlegen. Ihre Anwendung verwendet dann 15 Workers, wobei jeder Worker ein anderes Segment scannt.
Sie können auch einen Wert für `TotalSegments` auswählen, der auf Client-Ressourcen basiert. Sie können `TotalSegments` auf eine beliebige Zahl von 1 bis 1 000 000 festlegen und DynamoDB ermöglicht Ihnen diese Anzahl von Segmenten zu scannen. Wenn beispielsweise Ihr Client die Anzahl der Threads begrenzt, die parallel ausgeführt werden können, ist es möglich `TotalSegments` schrittweise zu erhöhen, bis Sie mit Ihrer Anwendung die beste `Scan`-Leistung erzielen.
Überwachen Sie Ihre parallelen Scans, um die Nutzung des bereitgestellten Durchsatzes zu optimieren, während sichergestellt werden muss, dass Ihren anderen Anwendungen die Ressourcen nicht ausgehen. Erhöhen Sie den Wert für `TotalSegments`, wenn Sie nicht den gesamten bereitgestellten Durchsatz verbrauchen, aber immer noch Einschränkungen in Ihren `Scan`-Anforderungen wahrnehmen. Reduzieren Sie den Wert für `TotalSegments`, wenn die `Scan`-Anforderungen mehr bereitgestellten Durchsatz verbrauchen als Sie verwenden möchten.