Ausführen von Apache Cassandra auf Azure-VMsRun Apache Cassandra on Azure VMs

Dieser Artikel enthält Überlegungen zur Leistung beim Ausführen von Apache Cassandra auf virtuellen Azure-Computern.This article describes performance considerations for running Apache Cassandra on Azure virtual machines.

Diese Empfehlungen basieren auf den Ergebnissen von Leistungstests, die Sie auf GitHub finden.These recommendations are based on the results of performance tests, which you can find on GitHub. Nutzen Sie diese Empfehlungen als Baseline, und führen Sie Tests für ihre eigene Workload aus.You should use these recommendations as a baseline and then test against your own workload.

VM-Größen und Datenträgertypen in AzureAzure VM sizes and disk types

Cassandra-Workloads in Azure verwenden im Allgemeinen virtuelle Computer mit Standard_DS14_v2 oder Standard_DS13_v2.Cassandra workloads on Azure commonly use either Standard_DS14_v2 or Standard_DS13_v2 virtual machines. Cassandra-Workloads profitieren von einem größeren Arbeitsspeicher in der VM, erwägen Sie daher, virtuelle Computer mit arbeitsspeicheroptimierter Größe wie Standard_DS14_v2 oder mit lokal datenspeicheroptimierter Größe wie Standard_L16s_v2 zu verwenden.Cassandra workloads benefit from having more memory in the VM, so consider memory optimized virtual machine sizes, such as Standard_DS14_v2, or local-storage optimized sizes such as Standard_L16s_v2.

Aus Gründen der Robustheit werden Daten- und Commitprotokolle häufig auf einem Stripeset von zwei bis vier 1-TB-Managed Disks Premium (P30) gespeichert.For durability, data and commit logs are commonly stored on a stripe set of two to four 1-TB premium managed disks (P30).

Cassandra-Knoten sollten keine zu große Datendichte aufweisen.Cassandra nodes should not be too data-dense. Es wird empfohlen, höchstens 1–2 TB Daten pro VM zu verwalten und ausreichend freien Speicherplatz für die Komprimierung bereitzustellen.We recommend having at most 1 – 2 TB of data per VM and enough free space for compaction. Um den höchstmöglichen kombinierten Durchsatz und IOPS mit Managed Disks Premium zu erreichen, empfehlen wir, ein Stripeset mit verschiedenen 1-TB-Datenträgern zu erstellen und keinen einzigen Datenträger mit einer Größe von 2 TB oder 4 TB.To achieve the highest possible combined throughput and IOPS using premium managed disks, we recommend creating a stripe set from a few 1-TB disks, instead of using a single 2-TB or 4-TB disk. Auf einer DS14_v2-VM haben beispielsweise vier 1-TB-Datenträger einen maximalen IOPS von 4 × 5000 = 20 K, im Gegensatz zu 7,5 K für einen einzigen 4-TB-Datenträger.For example, on a DS14_v2 VM, four 1-TB disks have a maximum IOPS of 4 × 5000 = 20 K, versus 7.5 K for a single 4-TB disk.

Da die Verfügbarkeit von Azure Ultra Disks in Regionen immer zunimmt, ziehen Sie sie für Cassandra-Workloads in Betracht, bei denen eine geringere Datenträgerkapazität erforderlich ist.As Azure Ultra Disks become more widely available across regions, evaluate them for Cassandra workloads that need smaller disk capacity. Sie können einen höheren IOPS/Durchsatz bei geringerer Latenz für VM-Größen wie Standard_D32s_v3 und Standard_D16s_v3 sicherstellen.They can provide higher IOPS/throughput and lower latency on VM sizes like Standard_D32s_v3 and Standard_D16s_v3.

Für Cassandra-Workloads, die keinen permanenten Speicher benötigen, d. h., wenn Daten auf einfache Weise von einem anderen Speichermedium rekonstruiert werden können, erwägen Sie die Verwendung von Standard_L32s_v2- oder Standard_L16s_v2-VMs.For Cassandra workloads that don't need durable storage — that is, where data can be easily reconstructed from another storage medium — consider using Standard_L32s_v2 or Standard_L16s_v2 VMs. Diese VMs-Größen weisen große und schnelle lokale temporäre NVMe-Datenträger auf.These VMs sizes have large and fast local temporary NVMe disks.

Weitere Informationen finden Sie unter Comparing performance of Azure local/ephemeral vs attached/persistent disks (Vergleichen der Leistung auf lokalen/kurzlebigen mit angefügten/persistenten Datenträgern in Azure) auf GitHub.For more information, see Comparing performance of Azure local/ephemeral vs attached/persistent disks (GitHub).

Beschleunigter NetzwerkbetriebAccelerated Networking

Cassandra-Knoten verwenden das Netzwerk intensiv, um Daten von der Client-VM zu senden und zu empfangen und um für Replikationszwecke zwischen Knoten zu kommunizieren.Cassandra nodes make heavy use of the network to send and receive data from the client VM and to communicate between nodes for replication. Zum Optimieren der Leistung profitieren Cassandra-VMs von hohem Durchsatz und einem Netzwerk mit niedriger Latenz.For optimal performance, Cassandra VMs benefit from high-throughput and low-latency network.

Es wird empfohlen, den beschleunigten Netzwerkbetrieb auf der NIC des Cassandra-Knotens und auf VMs mit Clientanwendungen zu aktivieren, die auf Cassandra zugreifen.We recommended enabling Accelerated Networking on the NIC of the Cassandra node and on VMs running client applications accessing Cassandra.

Für den beschleunigten Netzwerkbetrieb wird eine moderne Linux-Distribution mit den aktuellen Treibern benötigt, z. B. Cent OS 7.5+ oder Ubuntu 16.x/18.x.Accelerated networking requires a modern Linux distribution with the latest drivers, such as Cent OS 7.5+ or Ubuntu 16.x/18.x. Weitere Informationen hierzu finden Sie unter Erstellen eines virtuellen Linux-Computers mit beschleunigtem Netzwerkbetrieb.For more information, see Create a Linux virtual machine with Accelerated Networking.

Zwischenspeichern von Azure-VM-DatenträgernAzure VM data disk caching

Für Cassandra-Leseworkloads ist die beste Leistung zu beobachten, wenn die Latenz für Datenträger mit wahlfreiem Zugriff niedrig ist.Cassandra read workloads perform best when random-access disk latency is low. Wir empfehlen, verwaltete Azure-Datenträger mit aktivierter ReadOnly-Zwischenspeicherung zu verwenden.We recommend using Azure managed disks with ReadOnly caching enabled. Die ReadOnly-Zwischenspeicherung bietet eine niedrigere durchschnittliche Latenz, da die Daten aus dem Cache auf dem Host gelesen und nicht an den Back-End-Speicher gesendet werden.ReadOnly caching provides lower average latency, because the data is read from the cache on the host instead of going to the backend storage.

Leseintensive Workloads mit zufälligen Lesevorgängen wie Cassandra profitieren von der niedrigeren Leselatenz, obgleich der zwischengespeicherte Modus niedrigere Durchsatzgrenzen als der nicht zwischengespeicherte Modus aufweist.Read-heavy, random-read workloads like Cassandra benefit from the lower read latency even though cached mode has lower throughput limits than uncached mode. (Virtuelle DS14_v2-Computer haben einen maximalen zwischengespeicherten Durchsatz von 512 MB/s, im Vergleich zu einem nicht zwischengespeicherten Durchsatz von 768 MB/s.)(For example, DS14_v2 virtual machines have a maximum cached throughput of 512 MB/s versus uncached of 768 MB/s.)

Die ReadOnly-Zwischenspeicherung ist besonders hilfreich für Cassandra-Zeitreihen und andere Workloads, bei denen das Arbeitsdataset in den Hostcache passt und die Daten nicht ständig überschrieben werden.ReadOnly caching is particularly helpful for Cassandra time-series and other workloads where the working dataset fits in the host cache and data is not constantly overwritten. DS14_v2 bietet z. B. eine Cachegröße von 512 GB; damit könnten bis zu 50 % der Daten von einem Cassandra-Knoten mit einer Datendichte von 1 bis 2 TB gespeichert werden.For example, DS14_v2 provides a cache size of 512 GB, which could store up to 50% of the data from a Cassandra node with 1-2 TB data density.

Bei aktivierter ReadOnly-Zwischenspeicherung gibt es keine wesentlichen Leistungseinbußen aufgrund von Cachefehlern. Daher empfiehlt sich der zwischengespeicherte Modus für sämtliche Workloads, außer für höchst schreibintensive Workloads.There is no significant performance penalty from cache-misses when ReadOnly caching is enabled, so cached mode is recommended for all but the most write-heavy workloads.

Weitere Informationen finden Sie unter Comparing Azure VM data disk caching configurations (Vergleichen der Konfigurationen für das Zwischenspeichern von Azure-VM-Datenträgern) auf GitHub.For more information, see Comparing Azure VM data disk caching configurations (GitHub).

Linux-Read-AheadLinux read-ahead

In den meisten Linux-Distributionen im Azure Marketplace ist die Read-Ahead-Standardeinstellung für Blockgeräte 4.096 KB.In most Linux distributions in the Azure Marketplace, the default block device read-ahead setting is 4096 KB. Die von Cassandra gelesenen E/As sind im Allgemeinen zufällig und relativ klein.Cassandra's read IOs are usually random and relatively small. Daher wird durch einen großen Read-Ahead Durchsatz vergeudet, da Teile von Dateien gelesen werden, die nicht benötigt werden.Therefore, having a large read-ahead wastes throughput by reading parts of files that aren't needed.

Um den unnötigen Lookahead zu minimieren, legen Sie die Read-Ahead-Einstellung für Linux-Blockgeräte auf 8 KB fest.To minimize unnecessary lookahead, set the Linux block device read-ahead setting to 8 KB. (Siehe Recommended production settings (Empfohlene Produktionseinstellungen) in der Datastax-Dokumentation.)(See Recommended production settings in the Datastax documentation.)

Konfigurieren Sie einen Read-Ahead von 8 KB für alle Blockgeräte im Stripeset und auf dem Arraygerät selbst (z. B. /dev/md0).Configure 8 KB read-ahead for all block devices in the stripe set and on the array device itself (for example, /dev/md0).

Weitere Informationen finden Sie unter Comparing impact of disk read-ahead settings (Vergleichen der Auswirkungen von Read-Ahead-Einstellungen für Datenträger) auf GitHub.For more information, see Comparing impact of disk read-ahead settings (GitHub).

mdadm-Blockgröße für DatenträgerarraysDisk array mdadm chunk size

Beim Ausführen von Cassandra in Azure wird häufig ein mdadm-Stripeset (d. h. RAID 0) von mehreren Datenträgern erstellt, um den Gesamtdurchsatz für Datenträger und IOPS in Richtung der VM-Grenzwerte zu steigern.When running Cassandra on Azure, it's common to create an mdadm stripe set (that is, RAID 0) of multiple data disks to increase the overall disk throughput and IOPS closer to the VM limits. Die optimale Datenträger-Stripegröße ist eine anwendungsspezifische Einstellung.Optimal disk stripe size is an application-specific setting. Für SQL Server-OLTP-Workloads wird beispielsweise ein Wert von 64 KB empfohlen.For example, for SQL Server OLTP workloads, the recommendation is 64 KB. Für Data Warehousing-Workloads beträgt die empfohlene Einstellung 256 KB.For data warehousing workloads, the recommendation is 256 KB.

Unsere Tests haben keinen signifikanten Unterschied zwischen Blockgrößen von 64 KB, 128 KB und 256 KB für Cassandra-Leseworkloads ergeben.Our tests found no significant difference between chunk sizes of 64k, 128k, and 256k for Cassandra read workloads. Die Blockgröße 128 KB scheint einen kleinen, kaum feststellbaren Vorteil zu bieten.There seems to be a small, slightly noticeable, advantage to the 128k chunk size. Daher empfehlen wir Folgendes:Therefore, we recommend the following:

  • Wenn Sie bereits eine Blockgröße von 64 KB oder 256 KB verwenden, ist es nicht sinnvoll, das Datenträgerarray neu zu erstellen und eine Größe von 128 KB zu konfigurieren.If you're already using a chunk size of 64 K or 256 K, it doesn't make sense rebuild the disk array to use 128 K size.

  • Bei einer neuen Konfiguration ist es sinnvoll, 128 KB von Anfang an zu verwenden.For a new configuration, it makes senses to use 128 K from the beginning.

Weitere Informationen finden Sie unter Measuring impact of mdadm chunk sizes on Cassandra performance (Messen der Auswirkung von mdadm-Blockgrößen auf die Cassandra-Leistung) auf GitHub.For more information, see Measuring impact of mdadm chunk sizes on Cassandra performance (GitHub).

Commitprotokoll-DateisystemCommitlog filesystem

Für Cassandra-Schreibvorgänge wird die beste Leistung erzielt, wenn sich Commitprotokolle auf Datenträgern mit hohem Durchsatz und niedriger Latenz befinden.Cassandra writes perform best when commit logs are on disks with high throughput and low latency. In der Standardkonfiguration leert Cassandra 3.x etwa alle 10 Sekunden Daten aus dem Arbeitsspeicher in die Commitprotokolldatei, und auf den Datenträger wird nicht bei jedem Schreibvorgang zugegriffen.In the default configuration, Cassandra 3.x flushes data from memory to the commit log file every ~10 seconds and doesn't touch the disk for every write. In dieser Konfiguration ist kein Unterschied hinsichtlich der Schreibleistung zu beobachten, egal, ob sich das Commitprotokoll auf angefügten Premium-Datenträgern oder auf lokalen/kurzlebigen Datenträgern befindet.In this configuration, write performance is almost identical whether the commit log is on premium attached disks versus local/ephemeral disks.

Commitprotokolle müssen permanent sein, damit ein neu gestarteter Knoten noch nicht in den Datendateien enthaltene Daten aus den geleerten Commitprotokollen wiederherstellen kann.Commit logs must be durable, so that a restarted node can reconstruct any data not yet in data files from the flushed commit logs. Um die Dauerhaftigkeit zu verbessern, speichern Sie Commitprotokolle auf Managed Disks Premium und nicht im lokalen Speicher, der verloren gehen kann, wenn die VM zu einem anderen Host migriert wird.For better durability, store commit logs on premium managed disks and not on local storage, which can be lost if the VM is migrated to another host.

Laut unseren Tests kann Cassandra unter CentOS 7.x eine niedrigere Schreibleistung haben, wenn sich Commitprotokolle auf dem xfs-Dateisystem und nicht auf dem ext4-Dateisystem befinden.Based on our tests, Cassandra on CentOS 7.x may have lower write performance when commit logs are on the xfs versus ext4 filesystem. Durch Aktivieren der Komprimierung von Commitprotokollen wird die xfs-Leistung an die von ext4 angeglichen.Turning on commit log compression brings xfs performance in line with ext4. Unsere Tests haben ergeben, dass die Leistung von xfs mit Komprimierung ebenso gut wie die Leistung von ext4 mit und ohne Komprimierung ist.Compressed xfs performs as well as compressed and non-compressed ext4 in our tests.

Weitere Informationen finden Sie unter Observations on ext4 and xfs filesystems and compressed commit logs (Beobachtungen zu den Dateisystemen ext4 und xfs und komprimierten Commitprotokollen) auf GitHub.For more information, see Observations on ext4 and xfs filesystems and compressed commit logs (GitHub).

Messen der VM-BaselineleistungMeasuring baseline VM performance

Führen Sie nach dem Bereitstellen der VMs für den Cassandra-Ring einige synthetische Tests aus, um die Netzwerk- und Datenträger-Baselineleistung zu ermitteln.After deploying the VMs for the Cassandra ring, run a few synthetic tests to establish baseline network and disk performance. Vergewissern Sie sich anhand dieser Tests, dass die Leistung hinsichtlich der VM-Größe den Erwartungen entspricht.Use these tests to confirm that performance is in line with expectations, based on the VM size.

Wenn Sie später die tatsächliche Workload ausführen, erleichtert Ihnen die ermittelte Baselineleistung das Untersuchen potenzieller Engpässe.Later, when you run the actual workload, knowing the performance baseline makes it easier to investigate potential bottlenecks. Wenn Ihnen beispielsweise die Baselineleistung für den ausgehenden Netzwerkdatenverkehr auf der VM bekannt ist, können Sie das Netzwerk möglicherweise als Engpass ausschließen.For example, knowing the baseline performance for network egress on the VM can help to rule out network as a bottleneck.

Weitere Informationen zum Ausführen von Leistungstests finden Sie unter Validating baseline Azure VM Performance (Validieren der Azure-VM-Baselineleistung) auf GitHub.For more information about running performance tests, see Validating baseline Azure VM Performance (GitHub).

DokumentgrößeDocument size

Die Lese- und Schreibleistung von Cassandra hängt von der Dokumentgröße ab.Cassandra read and write performance depends on the document size. Beim Lesen oder Schreiben größerer Dokumente ist davon auszugehen, dass eine höhere Latenz und weniger Vorgänge/Sekunde zu beobachten sind.You can expect to see higher latency and lower operations/second when reading or writing with larger documents.

Weitere Informationen finden Sie unter Comparing relative performance of various Cassandra document sizes (Vergleichen der relativen Leistung für verschiedene Cassandra-Dokumentgrößen) auf GitHub.For more information, see Comparing relative performance of various Cassandra document sizes (GitHub).

ReplikationsfaktorReplication factor

Für die meisten Cassandra-Workloads gilt ein Replikationsfaktor (RF) von 3, wenn angefügte Premium-Datenträger verwendet werden; der Faktor beträgt sogar 5, wenn temporäre/kurzlebige lokale Datenträger verwendet werden.Most Cassandra workloads use a replication factor (RF) of 3 when using attached premium disks and even 5 when using temporary/ephemeral local disks. Die Anzahl der Knoten im Cassandra-Ring muss einem Vielfachen des Replikationsfaktors entsprechen.The number of nodes in the Cassandra ring should be a multiple of the replication factor. RF 3 impliziert beispielsweise einen Ring von 3, 6, 9 oder 12 Knoten, bei RF 5 hingegen sind 5, 10, 15 oder 20 Knoten vorhanden.For example, RF 3 implies a ring of 3, 6, 9, or 12 nodes, while RF 5 would have 5, 10, 15, or 20 nodes. Wird ein RF größer als 1 bei einer Konsistenzebene von LOCAL_QUORUM verwendet, ist die Lese- und Schreibleistung normalerweise geringer als die derselben Workload, die mit RF 1 ausgeführt wird.When using RF greater than 1 and a consistency level of LOCAL_QUORUM, it's normal for read and write performance to be lower than the same workload running with RF 1.

Weitere Informationen finden Sie unter Comparing relative performance of various replication factors (Vergleichen der relativen Leistung verschiedener Replikationsfaktoren) auf GitHub.For more information, see Comparing relative performance of various replication factors (GitHub).

Zwischenspeichern von Seiten unter LinuxLinux page caching

Beim Lesen von Datendateien verwendet der Java-Code in Cassandra reguläres Datei-E/A und profitiert vom Zwischenspeichern von Seiten unter Linux.When reading data files, Cassandra's Java code uses regular file IO and benefits from Linux page caching. Nachdem Teile der Datei einmalig gelesen wurden, wird der gelesene Inhalt im Betriebssystem-Seitencache gespeichert.After parts of the file are read one time, the read content is stored in the OS page cache. Der nachfolgende Lesezugriff auf dieselben Daten ist viel schneller.Subsequent read access to the same data is much faster.

Daher erscheinen beim Durchführen von Tests zur Leseleistung für dieselben Daten der zweite und nachfolgende Lesevorgänge viel schneller als der ursprüngliche Lesevorgang, bei dem auf Daten auf dem Remotedatenträger bzw. bei Aktivierung von ReadOnly im Hostcache zugegriffen werden musste.For this reason, when executing read performance tests against the same data, the second and subsequent reads will appear to be much faster than the original read, which needed to access data on the remote data disk or from the host cache when ReadOnly is enabled. Um ähnliche Leistungsmesswerte in nachfolgenden Ausführungen zu erhalten, leeren Sie den Linux-Seitencache, und starten Sie den Cassandra-Dienst neu, um dessen internen Speicher zu leeren.To get similar performance measurements on subsequent runs, clear the Linux page cache and restart the Cassandra service to clear its internal memory. Bei Aktivierung der ReadOnly-Zwischenspeicherung befinden sich die Daten möglicherweise im Hostcache, und nachfolgende Lesevorgänge sind selbst nach dem Leeren des Betriebssystem-Seitencaches und dem Neustarten des Cassandra-Diensts schneller.When ReadOnly caching is enabled, the data might be in the host cache, and subsequent reads will be faster even after clearing the OS page cache and restarting the Cassandra service.

Weitere Informationen finden Sie unter Observations on Cassandra usage of Linux page caching (Beobachtungen zur Cassandra-Verwendung des Zwischenspeicherns von Seiten in Linux) auf GitHub.For more information, see Observations on Cassandra usage of Linux page caching (GitHub).

Replikation in mehreren RechenzentrenMulti-datacenter replication

Cassandra unterstützt nativ das Konzept mehrerer Rechenzentren. Dies erleichtert das Konfigurieren eines Cassandra-Rings über mehrere Azure-Regionen hinweg oder über Verfügbarkeitszonen in einer Region hinweg.Cassandra natively supports the concept of multiple data centers, making it easy to configure one Cassandra ring across multiple Azure regions or across availability zones within one region.

Verwenden Sie für eine Bereitstellung über mehrere Regionen das globale VNET-Peering von Azure, um die virtuellen Netzwerke in den verschiedenen Regionen miteinander zu verbinden.For a multiregion deployment, use Azure Global VNet-peering to connect the virtual networks in the different regions. Wenn VMs in derselben Region, aber in separaten Verfügbarkeitszonen bereitgestellt werden, können sich die VMs im selben virtuellen Netzwerk befinden.When VMs are deployed in the same region but in separate availability zones, the VMs can be in the same virtual network.

Die Baseline-Roundtrip-Latenz zwischen Regionen muss unbedingt gemessen werden.It's important to measure the baseline roundtrip latency between regions. Die Netzwerklatenz zwischen Regionen kann 10- bis 100-mal höher als die Latenz innerhalb einer Region sein.Network latency between regions can be 10-100 times higher than latency within a region. Erwarten Sie eine Verzögerung der Anzeige von Daten in der zweiten Region, wenn die Schreibkonsistenz LOCAL_QUORUM verwendet wird, oder eine erheblich reduzierte Leistung von Schreibvorgängen, wenn EACH_QUORUM verwendet wird.Expect a lag between data appearing in the second region when using LOCAL_QUORUM write consistency, or significantly decreased performance of writes when using EACH_QUORUM.

Beim Ausführen von Apache Cassandra im gewünschten Umfang und insbesondere in einer Umgebung mit mehreren Domänencontrollern ist das Reparieren von Knoten eine Herausforderung.When running Apache Cassandra at scale, and specifically in a multi-DC environment, node repair becomes challenging. Mithilfe von Tools wie Reaper können Sie Reparaturen im gewünschten Umfang koordinieren (z. B. für sämtliche Knoten in einem Rechenzentrum, jeweils ein Rechenzentrum, um die Last für den gesamten Cluster zu begrenzen).Tools such as Reaper can help to coordinate repairs at scale (for example, across all the nodes in a data center, one data center at a time, to limit the load on the whole cluster). Das Reparieren von Knoten für große Cluster ist jedoch weiterhin problematisch, und dies gilt für alle Umgebungen, seien es lokale oder Cloudumgebungen.However, node repair for large clusters is not yet a fully solved problem and applies in all environments, whether on-premises or in the cloud.

Beim Hinzufügen von Knoten zu einer sekundären Region wird die Leistung nicht linear skaliert, da eine bestimmte Menge von Bandbreiten- und CPU/Datenträger-Ressourcen beim Senden und Empfangen von Replikationsdatenverkehr zwischen den Regionen genutzt wird.When nodes are added to a secondary region, performance will not scale linearly, because some bandwidth and CPU/disk resources are spent on receiving and sending replication traffic across regions.

Weitere Informationen finden Sie unter Measuring impact of multi-dc cross-region replication (Messen der Auswirkung der regionsüberschreitenden Replikation in einer Umgebung mit mehreren Domänencontrollern) auf GitHub.For more information, see Measuring impact of multi-dc cross-region replication (GitHub).

Hinted Handoff-KonfigurationHinted-handoff configuration

In einem Cassandra-Ring über mehrere Regionen können bei Schreibworkloads mit der Konsistenzebene LOCAL_QUORUM Daten in der sekundären Region verloren gehen.In a multiregion Cassandra ring, write workloads with consistency level of LOCAL_QUORUM may lose data in the secondary region. Standardmäßig wird Cassandra-Hinted Handoff auf einen relativ niedrigen maximalen Durchsatz und eine Hint-Lebensdauer von drei Stunden gedrosselt.By default, Cassandra hinted handoff is throttled to a relatively low maximum throughput and three-hour hint lifetime. Für Workloads mit intensiven Schreibvorgängen empfiehlt es sich, die Hinted Handoff-Drosselung zu erhöhen und das Hint-Zeitfenster zu vergrößern, um zu verhindern, dass Hints vor ihrer Replikation nicht gelöscht werden.For workloads with heavy writes, we recommended increasing the hinted handoff throttle and hint window time to ensure hints are not dropped before they are replicated.

Weitere Informationen finden Sie unter Observations on hinted handoff in cross-region replication (Beobachtungen zu Hinted Handoffs bei der regionsüberschreitenden Replikation) auf GitHub.For more information, see Observations on hinted handoff in cross-region replication (GitHub).

Nächste SchritteNext steps

Weitere Informationen zu diesen Leistungsergebnissen finden Sie unter Cassandra on Azure VMs Performance Experiments (Leistungsexperimente für Cassandra auf Azure-VMs).For more information about these performance results, see Cassandra on Azure VMs Performance Experiments.

Informationen zu allgemeinen Cassandra-Einstellungen, die nicht spezifisch für Azure sind, finden Sie hier:For information on general Cassandra settings, not specific to Azure, see:

In der folgenden Referenzarchitektur wird Cassandra als Teil einer n-schichtigen Konfiguration bereitgestellt:The following reference architecture deploys Cassandra as part of an n-tier configuration: