Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Concevoir un schéma
Le schéma idéal pour une table Bigtable dépend fortement d'un certain nombre de facteurs, parmi lesquels le cas d'utilisation, les modèles d'accès aux données et les types de données que vous prévoyez de stocker. Cette page présente le processus de conception de schémas Bigtable.
Créez ou identifiez une instance Bigtable que vous pouvez utiliser pour tester votre schéma.
Recueillir des informations
Identifiez les données que vous prévoyez de stocker dans Bigtable.
Voici quelques questions à vous poser :
Quel est le format utilisé par les données ? Les formats possibles incluent les octets bruts, les chaînes, les protobufs et JSON.
Qu'est-ce qu'une entité dans vos données ? Par exemple, stockez-vous les pages vues, les cours des actions, les emplacements des annonces, les mesures sur l'appareil ou un autre type d'entité ? De quoi les entités sont-elles composées ?
Les données sont-elles basées sur le temps ?
Identifiez et classez les requêtes que vous utilisez pour obtenir les données dont vous avez besoin. En tenant compte des entités que vous allez stocker, réfléchissez à la façon dont vous souhaitez que les données soient triées et regroupées lorsque vous les utilisez. La conception de votre schéma peut ne pas satisfaire à toutes vos requêtes, mais idéalement, elle doit permettre de traiter les requêtes les plus importantes ou les plus fréquemment utilisées. Voici quelques exemples de requêtes :
Mois de relevé de températures pour les objets IoT.
Visionnage quotidien des annonces pour une adresse IP.
Dernière position d'un appareil mobile.
Tous les événements d'application par jour et par utilisateur.
Conception
Choisissez une conception de schéma initiale. Cela implique de planifier le modèle suivi par vos clés de ligne, les familles de colonnes de votre table et les qualificatifs de des colonnes souhaitées dans ces familles de colonnes.
Suivez les consignes générales de conception de schéma. Si vos données sont de type temporelles, suivez également les consignes relatives aux données de séries temporelles.
Si vous prévoyez d'interroger votre table à l'aide de SQL au lieu de la méthode ReadRows de l'API Bigtable Data, consultez les documents suivants :
Effectuez un test de charge intensif pendant plusieurs minutes. Cette étape permet à Bigtable d'équilibrer les données entre les nœuds en fonction des modèles d'accès observés.
Exécutez une simulation d'une heure des lectures et des écritures que vous devez normalement envoyer à la table.
Examinez les résultats de votre simulation à l'aide de Key Visualizer et de Cloud Monitoring.
L'outil Key Visualizer pour Bigtable fournit des analyses qui présentent les modèles d'utilisation de chaque table d'un cluster.
Key Visualizer vous aide à vérifier si la conception de votre schéma et vos modèles d'utilisation génèrent des résultats indésirables, tels que des hotspots sur des lignes spécifiques.
Monitoring vous aide à vérifier les métriques, telles que l'utilisation du processeur du nœud le plus sollicité dans un cluster, afin de déterminer si la conception du schéma est à l'origine des problèmes.
Affiner
Modifiez la conception de votre schéma si nécessaire, en fonction de ce que Key Visualizer vous a appris. Exemple :
Si vous constatez un phénomène de hotspotting, utilisez différentes clés de ligne.
Si vous remarquez une latence, vérifiez si les lignes dépassent la limite de 100 Mo par ligne.
Si vous avez besoin de filtres pour obtenir les données dont vous avez besoin, envisagez de normaliser les données de manière à faciliter les lectures (et à les rendre plus rapides) : lisez une ligne ou des plages de lignes par clé de ligne.
Une fois que vous avez révisé votre schéma, testez et vérifiez à nouveau les résultats.
Continuez à modifier et à tester votre conception de schéma jusqu'à ce qu'une inspection de Key Visualizer vous indique qu'elle est optimale.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (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)."]]
