데이터는 어떤 형식을 사용하나요? 가능한 형식은 원시 바이트, 문자열, protobuf, json입니다.
데이터의 항목은 어떻게 구성되나요? 예를 들어 페이지 조회수, 주가, 광고 게재위치, 기기 측정치, 다른 유형의 항목을 저장하나요? 항목은 어떻게 구성되어 있나요?
데이터는 시간을 기반으로 하나요?
필요한 데이터를 가져오는 데 사용할 쿼리를 식별하고 순위를 결정합니다. 저장할 항목을 고려해 데이터를 사용할 때 데이터 정렬 및 그룹화 방법을 생각해 보세요. 스키마 설계가 모든 쿼리를 충족하는 것은 아니지만 가장 중요하거나 가장 자주 사용되는 쿼리를 충족하는 것이 가장 바람직합니다. 쿼리의 예시는 다음과 같습니다.
한 달 동안의 IoT 객체 온도 판독값
IP 주소의 일일 광고 조회수
휴대기기의 가장 최근 위치
사용자당 일일 애플리케이션 이벤트 수
디자인
초기 스키마 설계를 결정합니다. 즉, row key가 따라야 하는 패턴, 테이블에서 사용할 column family, 그리고 해당 column family 내에 있는 열의 column qualifier를 계획합니다.
일반 스키마 설계 가이드라인을 따릅니다. 데이터가 시간을 기반으로 하는 경우 시계열 데이터 가이드라인도 따라야 합니다.
Bigtable Data API ReadRows 메서드 대신 SQL을 사용하여 테이블을 쿼리하려면 다음 문서를 참고하세요.
SQL을 사용하여 테이블 자체뿐만 아니라 테이블의 뷰를 쿼리하려면 테이블 및 뷰를 검토하세요.
테스트
스키마에 대해 작성한 column family와 column qualifier를 사용하여 테이블을 만듭니다.
임시 계획에서 식별한 row key를 사용하여 최소 30GB의 테스트 데이터가 있는 테이블을 로드합니다. 노드당 스토리지 사용량 한도 미만으로 유지합니다.
몇 분 동안 과도한 부하가 발생하는 테스트를 실행합니다. 이 단계를 통해 Bigtable은 관측된 액세스 패턴에 따라 노드 간에 데이터를 균등화할 수 있습니다.
일반적으로 테이블에 보내는 읽기 및 쓰기에 대해 1시간 시뮬레이션을 실행합니다.
Key Visualizer 및 Cloud Monitoring을 사용하여 시뮬레이션 결과를 검토합니다.
Bigtable용 Key Visualizer 도구는 클러스터의 각 테이블에 대한 사용 패턴을 표시하는 일일 검사를 제공합니다.
Key Visualizer를 사용하면 특정 행의 핫스팟과 같은 스키마 설계 및 사용 패턴으로 인해 원치 않는 결과가 발생하는지 확인할 수 있습니다.
Monitoring을 통해 클러스터에서 사용량 상위 노드의 CPU 사용률과 같은 측정항목을 확인하여 스키마 설계로 인해 문제가 발생하는지 확인할 수 있습니다.
상세검색
Key Visualizer로 학습한 내용을 기반으로 필요에 따라 스키마 설계를 수정합니다. 예를 들면 다음과 같습니다.
부하 집중 증거가 보이면 다른 row key를 사용합니다.
지연 시간이 보인다면 행이 행당 100MB 한도를 초과하는지 확인합니다.
필요한 데이터를 가져오기 위해 필터를 사용해야 하는 경우, row key별로 단일 행 또는 범위를 읽는 더 간단하고 빠른 읽기 방식으로 데이터를 정규화합니다.
스키마를 수정한 후 결과를 다시 테스트하고 검토합니다.
Key Visualizer의 검사에서 스키마 설계가 최적이라고 판단할 때까지 스키마 설계 및 테스트를 계속 수정합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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)."]]
