Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
SSD- oder HDD-Speicher wählen
Beim Erstellen einer Bigtable-Instanz legen Sie fest, ob Daten in den Clustern der Instanz auf SSDs (Solid-State-Laufwerken) oder HDDs (Festplattenlaufwerken) gespeichert werden:
SSD-Speicherung ist die effizienteste und kostengünstigste Wahl für die meisten Anwendungsfälle.
HDD-Speicherung ist manchmal angemessen für große Datensätze, die nicht latenzempfindlich sind und auf die unregelmäßig zugegriffen wird.
Egal, welche Art der Speicherung Sie wählen, Ihre Daten werden auf einem verteilten, replizierten Dateisystem gespeichert, das sich über viele physische Laufwerke erstreckt.
Die Richtlinien auf dieser Seite helfen Ihnen dabei, zwischen SSD und HDD zu wählen.
Im Zweifel SSD wählen
Es gibt einige Gründe, warum SSD normalerweise die beste Speicherart für Ihren Bigtable-Cluster darstellt:
SSD ist deutlich schneller als HDD und die Leistung lässt sich besser vorhersehen.
In einem Bigtable-Cluster bietet SSD-Speicher wesentlich geringere Latenzen für Lese- und Schreibvorgänge als HDD-Speicher.
Der Datendurchsatz bei HDD ist viel stärker begrenzt als der bei SSD. In einem Cluster mit HDD-Speicher ist es möglich, den maximalen Durchsatz zu erreichen, bevor die CPU-Auslastung 100 % erreicht. Das ist eine Situation, die Sie mit dem Messwert Laufwerkslast überwachen können. Für einen höheren Durchsatz müssen Sie mehr Knoten hinzufügen, aber die Kosten für die zusätzlichen Knoten könnten die Ersparnis für die Nutzung der HDD-Speicherung schnell übersteigen. Die SSD-Speicherung ist nicht derartig beschränkt, da sie einen viel höheren Durchsatz pro Knoten bietet. Ein Cluster, der SSD-Speicherung verwendet, erreicht grundsätzlich nur dann das Durchsatzmaximum, wenn er die gesamte verfügbare CPU- und Speicherleistung beansprucht.
Individuelle Zeilen lesen ist sehr langsam auf HDD. Wegen der Festplattensuchzeit unterstützt HDD nur 5 % der APS bei Lesevorgängen von SSD-Speicherung. Große Scans über mehrere Zeilen sind jedoch nicht so stark betroffen.
Die Kostenersparnis von HDD ist minimal im Vergleich zu den Kosten für die Knoten in Ihrem Bigtable-Cluster, außer Sie speichern große Datenmengen. Aus diesem Grund gilt die Faustregel, HDD nicht in Betracht zu ziehen, außer Sie speichern mindestens 10 TB Daten und Ihre Arbeitslast ist nicht latenzempfindlich.
Ein möglicher Nachteil von SSD-Speichern besteht darin, dass abhängig von der Menge der gespeicherten Daten mehr Knoten in Ihren Clustern erforderlich sind. In der Praxis benötigen Sie jedoch möglicherweise diese zusätzlichen Knoten sowieso, damit Ihre Cluster den eingehenden Traffic verarbeiten können, und nicht nur, um die Menge der gespeicherten Daten zu unterstützen.
Anwendungsfälle für HDD-Speicherung
HDD-Speicherung eignet sich für Anwendungsfälle, die alle folgenden Kriterien erfüllen:
Sie gehen davon aus, mehr als 10 TB Daten speichern zu müssen.
Sie werden die Daten nicht verwenden, um eine an die Nutzer gerichtete Anwendung oder eine latenzempfindliche Anwendung zu stützen.
Die Arbeitslast fällt in eine der folgenden Kategorien:
Batch-Arbeitslasten mit Scans und Schreibvorgängen und nicht mehr als gelegentlichen zufälligen Lesevorgängen für eine kleine Anzahl von Zeilen oder für Lesevorgänge
Datenarchivierung, bei der Sie große Datenmengen schreiben und diese Daten selten lesen.
Wenn Sie beispielsweise umfangreiche Verlaufsdaten für eine große Anzahl von Remote-Sensing-Geräten speichern und dann die Daten für das Erstellen von Tagesberichten verwenden möchten, können die Kosteneinsparungen für den Festplattenspeicher den Kompromiss bei der Leistung möglicherweise rechtfertigen. Wenn Sie andererseits planen, die Daten für die Echtzeitanzeige in einem Dashboard zu verwenden, ist es wahrscheinlich nicht sinnvoll, HDD-Speicherung zu verwenden. Lesevorgänge wären in diesem Fall um einiges häufiger und sind mit HDD-Speicherung deutlich langsamer.
Zwischen SSD- und HDD-Speicherung wechseln
Bei der Erstellung einer Bigtable-Instanz ist die Entscheidung zwischen SSD- und HDD-Speicher für die Instanz dauerhaft. Mit derGoogle Cloud Console können Sie nicht den Speichertyp ändern, der für die Instanz verwendet wird.
Wenn Sie den Speichertyp ändern möchten, in dem eine Tabelle gespeichert ist, verwenden Sie die Sicherungsfunktion:
Erstellen oder planen Sie eine Instanz, die den gewünschten Speichertyp verwendet.
Erstellen Sie eine Sicherung der Tabelle.
Stellen Sie die Sicherung aus einer Sicherung in einer neuen Tabelle in der anderen Instanz wieder her.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-27 (UTC)."],[[["\u003cp\u003eSSD storage is generally the preferred choice for Bigtable instances due to its superior speed, performance predictability, and higher throughput compared to HDD.\u003c/p\u003e\n"],["\u003cp\u003eHDD storage can be suitable for large datasets (at least 10 TB) that are not latency-sensitive and are infrequently accessed, such as for batch workloads or data archival.\u003c/p\u003e\n"],["\u003cp\u003eThe cost savings of using HDD storage might be minimal when considering the overall cost of nodes in a Bigtable cluster, making SSD storage a better value in most cases.\u003c/p\u003e\n"],["\u003cp\u003eChoosing between SSD and HDD storage is permanent for a Bigtable instance; switching storage types requires using the backup and restore process to move data to a new instance.\u003c/p\u003e\n"],["\u003cp\u003eHDD storage has significantly slower individual row read performance compared to SSD, making it less suitable for applications requiring frequent or real-time data retrieval.\u003c/p\u003e\n"]]],[],null,["# Choose between SSD and HDD storage\n==================================\n\nWhen you create a Bigtable instance, you choose whether its clusters\nstore data on solid-state drives (SSD) or hard disk drives (HDD):\n\n- SSD storage is the most efficient and cost-effective choice for most use cases.\n- HDD storage is sometimes appropriate for large datasets that are not latency-sensitive or are infrequently accessed.\n\nRegardless of which type of storage you choose, your data is stored on a\ndistributed, replicated file system that spans across many physical drives.\n\nThe guidelines on this page can help you choose between SSD and HDD.\n\nWhen in doubt, choose SSD storage\n---------------------------------\n\nThere are several reasons why it's usually best to use SSD storage for your\nBigtable cluster:\n\n- **SSD is significantly faster and has more predictable performance than HDD.** In a Bigtable cluster, SSD storage delivers significantly lower latencies for both reads and writes than HDD storage.\n- **HDD throughput is much more limited than SSD throughput.** In a cluster that uses HDD storage, it's possible to reach the maximum throughput before CPU usage reaches 100%, a situation you can monitor using the [disk load](/bigtable/docs/monitoring-instance#disk) metric. To increase throughput, you must add more nodes, but the cost of the additional nodes might exceed your savings from using HDD storage. SSD storage does not have this limitation, because it offers much more throughput per node---generally, a cluster that uses SSD storage reaches maximum throughput only when it is using all available CPU and memory.\n- **Individual row reads on HDD are very slow.** Because of disk seek time, HDD storage supports only 5% of the read rows per second of SSD storage. Large multi-row scans, however, are not as adversely impacted.\n- **The cost savings from HDD are minimal, relative to the cost of the nodes in\n your Bigtable cluster, unless you're storing large amounts of\n data.** For this reason, as a rule of thumb, you shouldn't consider using HDD storage unless you're storing at least 10 TB of data and your workload is not latency-sensitive.\n\nOne potential drawback of SSD storage is that it [requires more nodes in your\nclusters](/bigtable/quotas#storage-per-node) based on the amount of data that you store. In\npractice, though, you might need those extra nodes so that your clusters can\nkeep up with incoming traffic, not only to support the amount of data that\nyou're storing.\n\nUse cases for HDD storage\n-------------------------\n\nHDD storage is suitable for use cases that meet all of the following criteria:\n\n- You expect to store at least 10 TB of data.\n- You will not use the data to back a user-facing or latency-sensitive application.\n- You don't plan to enable [2x node\n scaling](/bigtable/docs/scaling#node-scaling-factor).\n- Your workload falls into one of the following categories:\n\n - Batch workloads with scans and writes, and no more than occasional random reads of a small number of rows or point reads.\n - Data archival, where you write large amounts of data and rarely read that data.\n\nFor example, if you plan to store extensive historical data for a large number\nof remote-sensing devices and then use the data to generate daily reports, the\ncost savings for HDD storage might justify the performance tradeoff. On the\nother hand, if you plan to use the data to display a real-time dashboard, it\nprobably *would not* make sense to use HDD storage---reads would be much more\nfrequent in this case, and reads that are not scans are much slower\nwith HDD storage.\n\nSwitching between SSD and HDD storage\n-------------------------------------\n\nWhen you create a Bigtable instance, your choice of\nSSD or HDD storage for the instance is permanent. You cannot use the\nGoogle Cloud console to change the type of storage that is used for the instance.\n\nIf you want to change the storage type that a table is stored on, use the\n[backups feature](/bigtable/docs/managing-backups):\n\n1. Create or plan to use an instance that uses the storage type you want.\n2. Create a backup of the table.\n3. Restore from the backup to a new table in the other instance.\n\nWhat's next\n-----------\n\n[Create an instance with SSD or HDD storage](/bigtable/docs/creating-instance)."]]
