Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Schema entwerfen
Das ideale Schema für eine Bigtable-Tabelle hängt stark von einer Reihe von Faktoren ab, darunter Anwendungsfall, Datenzugriffsmuster und die zu speichernden Daten. Auf dieser Seite erhalten Sie einen Überblick über den Schemadesignprozess von Bigtable.
Identifizieren Sie die Daten, die Sie in Bigtable speichern möchten.
Sie können sich folgende Fragen stellen:
Welches Format verwenden die Daten? Zu den möglichen Formaten gehören Rohbyte, Strings, Protokollpuffer und JSON.
Was macht eine Entität in Ihren Daten aus? Speichern Sie beispielsweise Seitenaufrufe, Aktienkurse, Anzeigenplatzierungen, Gerätemessungen oder einen anderen Entitätstyp? Woraus bestehen die Entitäten?
Sind die Daten zeitbasiert?
Identifizieren und stufen Sie die Abfragen ein, die Sie zum Abrufen der benötigten Daten verwenden. Überlegen Sie bei den zu speichernden Entitäten, wie die Daten sortiert und gruppiert werden sollen, wenn Sie sie verwenden. Ihr Schemadesign erfüllt möglicherweise nicht alle Ihre Abfragen, erfüllt jedoch idealerweise die wichtigsten oder am häufigsten verwendeten Abfragen. Beispiele für Abfragen können folgendes enthalten:
Die Temperaturwerte eines Monats für IoT-Objekte.
Tägliche Anzeigenaufrufe für eine IP-Adresse.
Der aktuellste Standort eines Mobilgeräts.
Alle Anwendungsereignisse pro Tag und Nutzer.
Design
Legen Sie ein anfängliches Schemadesign fest. Planen Sie also das Muster, dem Ihre Zeilenschlüssel folgen sollen, die Spaltenfamilien, die Ihre Tabelle haben soll, und die Spaltenqualifizierer für die gewünschten Spalten innerhalb dieser Spaltenfamilien.
Beachten Sie die allgemeinen Richtlinien für das Schemadesign. Wenn Ihre Daten zeitbasiert sind, folgen Sie außerdem den Richtlinien für Zeitachsendaten.
Wenn Sie Ihre Tabelle mit SQL anstelle der Bigtable Data API-Methode ReadRows abfragen möchten, lesen Sie die folgenden Dokumente:
Führen Sie einen intensiven Lasttest über mehrere Minuten aus. Dieser Schritt bietet Bigtable die Möglichkeit, Daten auf Knoten basierend auf den beobachteten Zugriffsmustern zu verteilen.
Führen Sie eine einstündige Simulation der Lese- und Schreibvorgänge aus, die Sie normalerweise an die Tabelle senden würden.
Ergebnisse von Simulation mit Key Visualizer und Cloud Monitoring überprüfen
Das Key Visualizer-Tool für Bigtable erstellt täglich Scans, aus denen die Nutzungsmuster der einzelnen Tabellen in einem Cluster ersichtlich sind.
Mit Key Visualizer können Sie überprüfen, ob das Schemadesign und die Nutzungsmuster unerwünschte Ergebnisse wie Hotspots in bestimmten Zeilen verursachen.
Mit Monitoring können Sie Messwerte wie die CPU-Auslastung des am stärksten genutzten Knotens in einem Cluster prüfen und so feststellen, ob das Schemadesign Probleme verursacht.
Filtern
Passen Sie das Schemadesign an, entsprechend den Ergebnissen von Key Visualizer. Beispiel:
Wenn Sie Anzeichen für eine Überlastung erkennen, verwenden Sie verschiedene Zeilenschlüssel.
Wenn Sie Latenz feststellen, prüfen Sie, ob die Zeilen das Limit von 100 MB pro Zeile überschreiten.
Wenn Sie Filter benötigen, um die benötigten Daten zu erhalten, sollten Sie die Daten auf eine Weise normalisieren, die einfachere (und schnellere) Lesevorgänge ermöglicht: Lesen Sie einzelne Zeilen oder Zeilenbereiche nach Zeilenschlüssel.
Nachdem Sie Ihr Schema überarbeitet haben, testen und prüfen Sie die Ergebnisse erneut.
Ändern Sie das Schemadesign und testen Sie weiterhin, bis eine Prüfung in Key Visualizer Ihnen sagt, dass das Schemadesign optimal ist.
[[["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\u003eThe optimal Bigtable schema is dependent on factors such as use case, data access patterns, and the nature of the data being stored.\u003c/p\u003e\n"],["\u003cp\u003eBefore designing a schema, it's crucial to identify the data format, entity types, and whether the data is time-based, alongside defining the queries needed to retrieve the data.\u003c/p\u003e\n"],["\u003cp\u003eThe design process involves planning row key patterns, column families, and column qualifiers, following general schema guidelines and any time-series data-specific guidelines.\u003c/p\u003e\n"],["\u003cp\u003eTesting the schema requires creating a table, loading it with a significant amount of data, running load tests, and simulating normal usage patterns to identify potential issues.\u003c/p\u003e\n"],["\u003cp\u003eSchema refinement involves revising the design based on insights from tools like Key Visualizer and Cloud Monitoring, addressing issues such as hotspotting, latency, or complex filtering requirements.\u003c/p\u003e\n"]]],[],null,["# Design a schema\n===============\n\nThe ideal schema for a Bigtable table is highly dependent on a\nnumber of factors, including use case, data access patterns, and the data you\nplan to store. This page provides an overview of the Bigtable\nschema design process.\n\nBefore you read this page, you should understand [schema design](/bigtable/docs/schema-design)\nconcepts and best practices. If applicable, also read\n[Schema design for time series data](/bigtable/docs/schema-design-time-series).\n\nBefore you begin\n----------------\n\n**[Create](/bigtable/docs/creating-instance) or identify a Bigtable instance** that\nyou can use to test your schema.\n\nGather information\n------------------\n\n1. **Identify the data that you plan to store in Bigtable** . Questions to ask include:\n - What format does the data use? Possible formats include raw bytes, strings, protobufs, and json.\n - What constitutes an *entity* in your data? For example, are you storing page views, stock prices, ad placements, device measurements, or some other type of entity? What are the entities composed of?\n - Is the data time-based?\n2. **Identify and rank the queries that you use to get the data you\n need** . Considering the entities you will be storing, think about how you will want the data to be sorted and grouped when you use it. Your schema design might not satisfy all your queries, but ideally it satisfies the most important or most frequently used queries. Examples of queries might include the following:\n - A month's worth of temperature readings for IoT objects.\n - Daily ad views for an IP address.\n - The most recent location of a mobile device.\n - All application events per day per user.\n\nDesign\n------\n\n**Decide on an initial schema design** . This means planning the pattern that\nyour row keys will follow, the column families your table will have, and\nthe column qualifiers for the columns you want within those column families.\nFollow the general [schema design guidelines](/bigtable/docs/schema-design). If your data\nis time-based, also follow the [guidelines for time series data](/bigtable/docs/schema-design-time-series).\n\nIf you plan to query your table using SQL instead of the Bigtable\nData API `ReadRows` method, consult the following documents:\n\n- [GoogleSQL for Bigtable overview](/bigtable/docs/googlesql-overview)\n- [Manage row key schemas](/bigtable/docs/manage-row-key-schemas)\n\nIf you want to use SQL to query views of your table as well as the table itself,\nreview [Tables and views](/bigtable/docs/tables-and-views).\n\nTest\n----\n\n1. **Create a table** using the column families and column qualifiers that you came up with for your schema.\n2. **[Load the table](https://github.com/GoogleCloudPlatform/PerfKitBenchmarker/tree/master/tutorials/bigtable_walkthrough) with at least 30 GB of test data** , using row keys that you identified in your draft plan. **Stay below the\n [storage utilization per node](/bigtable/quotas#storage-per-node) limits.**\n3. **Run a heavy load test for several minutes.** This step gives Bigtable a chance to balance data across nodes based on the access patterns that it observes.\n4. **Run a one-hour simulation** of the reads and writes you would normally send to the table.\n5. **Review the results of your simulation using Key Visualizer and\n Cloud Monitoring**.\n\n - The [Key Visualizer tool for Bigtable](/bigtable/docs/keyvis-overview)\n provides scans that show the usage patterns for each table in a cluster.\n Key Visualizer helps you check whether your schema design and usage\n patterns are causing undesirable results, such as hotspots on specific rows.\n\n - [Monitoring](/bigtable/docs/monitoring-instance) helps you check metrics,\n such as CPU utilization of the hottest node in a cluster, to help you\n determine if the schema design is causing problems.\n\nRefine\n------\n\n1. **Revise your schema design** as necessary, based on what you learned with Key Visualizer. For instance:\n - If you see evidence of hotspotting, use different row keys.\n - If you notice latency, find out whether your rows exceed the 100 MB per row limit.\n - If you find that you have to use filters to get the data you need, consider normalizing the data in a way that allows simpler (and faster) reads: reading a single row or ranges of rows by row key.\n2. **After you've revised your schema, test and review the results again**.\n3. **Continue modifying your schema design and testing** until an inspection in Key Visualizer tells you that the schema design is optimal.\n\nWhat's next\n-----------\n\n- Watch a presentation on the [iterative design process](/bigtable/docs/media#visualizing-cloud-bigtable-access-patterns-at-twitter-for-optimizing-analytics-google-cloud-next-18) that Twitter used for Bigtable.\n- Learn more about [Bigtable performance](/bigtable/docs/performance)."]]
