이 페이지에서는 쿼리 성능을 위해 BigQuery 스토리지를 최적화하기 위한 권장사항을 제공합니다. 또한, 비용에 맞게 스토리지를 최적화할 수도 있습니다.
이러한 권장사항은 주로 BigQuery 스토리지를 사용하는 테이블에 중점을 두지만 외부 테이블에도 적용할 수 있습니다.
BigQuery는 데이터를 열 형식으로 저장합니다. 열 기반 데이터베이스는 수많은 레코드에 데이터를 집계하는 분석 워크로드에 최적화되어 있습니다. 열은 일반적으로 행보다 중복성이 더 높으므로 이러한 특성 때문에 런 렝스 인코딩 같은 기법을 사용하면 데이터 압축률이 올라갑니다. BigQuery가 데이터를 저장하는 방법에 대한 자세한 내용은 BigQuery 스토리지 개요를 참조하세요.
BigQuery 스토리지를 최적화하면 쿼리 성능이 개선되고 비용이 제어됩니다.
BigQuery는 리소스의 스토리지 소비에 대한 세부정보를 제공합니다.
테이블 스토리지 메타데이터를 보려면 다음 INFORMATION_SCHEMA 뷰를 쿼리합니다.
데이터 세트에서 새로 생성된 테이블의 기본 테이블 만료를 설정하여 스토리지 비용을 제어하고 스토리지 사용을 최적화할 수 있습니다. 테이블이 만료되면 테이블에 포함된 모든 데이터와 함께 테이블이 삭제됩니다. 데이터 세트가 생성될 때 이 속성을 설정하면 만료 기간이 지난 후에 데이터 세트에서 생성된 테이블이 삭제됩니다. 데이터 세트가 생성된 후에 이 속성을 설정하면 만료 기간이 지난 후에 새로운 테이블만 삭제됩니다.
예를 들어 기본 테이블 만료를 7일로 설정하면 1주일 후에 이전 데이터가 자동으로 삭제됩니다.
이 옵션은 최신 데이터에만 액세스가 필요한 경우에 유용합니다. 또한 데이터를 보존할 필요 없이 사용하기만 하는 경우에도 유용합니다.
날짜로 파티션을 나눈 테이블에서는 데이터 세트의 기본 테이블 만료 시간이 개별 파티션에 적용됩니다. bq 명령줄 도구에서 time_partitioning_expiration 플래그를 사용하거나 API에서 expirationMs 구성 설정을 사용하여 파티션 만료 시간을 제어할 수도 있습니다. 파티션이 만료되면 해당 파티션의 데이터가 삭제되지만 파티션을 나눈 테이블은 테이블이 비어 있더라도 삭제되지 않습니다.
권장사항: 행 수준 데이터를 장기간 저장해야 하는지 확인하고, 해당하지 않으면 합산 데이터만 장기 저장하세요.
일반적으로 트랜잭션 또는 행 수준 데이터에 포함된 세부정보는 단기적으로 유용하지만 장기간 참조되는 경우는 별로 없습니다. 이러한 상황일 때는 집계 쿼리를 빌드하여 이 데이터와 연결된 측정항목을 계산하고 저장한 후 테이블/파티션 만료 시간을 사용하여 행 수준 데이터를 체계적으로 삭제하면 됩니다. 그러면 측정항목을 계속해서 장기간 사용할 수 있으며 스토리지 비용이 줄어듭니다.
[[["이해하기 쉬움","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\u003eThis document outlines best practices for optimizing BigQuery storage to enhance query performance, which also impacts cost control.\u003c/p\u003e\n"],["\u003cp\u003eClustering frequently used columns in tables reduces the amount of data scanned, improving query performance.\u003c/p\u003e\n"],["\u003cp\u003ePartitioning large tables by characteristics like time or integer columns improves performance and reduces costs by limiting the data read during a query.\u003c/p\u003e\n"],["\u003cp\u003eSetting expiration policies for datasets, tables, and partitions automatically deletes old data, optimizing storage usage and costs.\u003c/p\u003e\n"],["\u003cp\u003eAggregating long-term data instead of storing all row-level details can significantly reduce storage charges while keeping key metrics available.\u003c/p\u003e\n"]]],[],null,["# Optimize storage for query performance\n======================================\n\nThis page provides best practices for optimizing BigQuery\nstorage for query performance. You can also [optimize storage for cost](/bigquery/docs/best-practices-costs#control-storage-cost).\nWhile these best practices are primarily focused on tables using BigQuery\nstorage, they can be applied to external tables as well.\n\nBigQuery stores data in columnar format. Column-oriented\ndatabases are optimized for analytic workloads that aggregate data over a very\nlarge number of records. As columns have typically more redundancy than rows,\nthis characteristic allows for greater data compression by using techniques such\nas run-length encoding. For more information about how BigQuery\nstores data, see [Overview of BigQuery storage](/bigquery/docs/storage_overview).\nOptimizing BigQuery storage improves\n[query performance](/bigquery/docs/best-practices-performance-compute)\nand [controls cost](/bigquery/docs/best-practices-costs).\n\nBigQuery provides details about the storage consumption of your\nresources.\nTo view the table storage metadata, query the following `INFORMATION_SCHEMA` views:\n\n- [`INFORMATION_SCHEMA.TABLE_STORAGE`](/bigquery/docs/information-schema-table-storage)\n- [`INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION`](/bigquery/docs/information-schema-table-storage-by-organization)\n- [`INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE`](/bigquery/docs/information-schema-table-storage-usage)\n- [`INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE_BY_ORGANIZATION`](/bigquery/docs/information-schema-table-storage-usage-by-organization)\n\nCluster table data\n------------------\n\n**Best practice:** Create clustered tables.\n\nTo optimize storage for queries, start by clustering table data. By clustering\nfrequently used columns, you can reduce the total volume of data scanned by the\nquery. For information about how to create clusters, see\n[Create and use clustered tables](/bigquery/docs/creating-clustered-tables).\n\nPartition table data\n--------------------\n\n**Best practice:** Divide large tables with partitions.\n\nWith partitions, you can group and sort your data by a set of defined\ncolumn characteristics, such as an integer column, a time-unit column, or the\ningestion time. Partitioning improves the query performance and control\ncosts by reducing the number of bytes read by a query.\n\nFor more information about partitions, see [Introduction to partitioned tables](/bigquery/docs/partitioned-tables).\n\nUse the table and partition expiration settings\n-----------------------------------------------\n\n**Best practice:** To optimize storage, configure the default expiration\nsettings for [datasets](/bigquery/docs/updating-datasets#table-expiration),\n[tables](/bigquery/docs/managing-tables#updating_a_tables_expiration_time),\nand [partitioned tables](/bigquery/docs/managing-partitioned-tables#partition-expiration).\n\nYou can control storage costs and optimize storage usage by setting the default\ntable expiration for newly created tables in a dataset. When a table expires,\nit gets deleted along with all of the data that the table contains. If you set\nthe property when the dataset is created, any table created in the dataset is\ndeleted after the expiration period. If you set the property after the dataset\nis created, only new tables are deleted after the expiration period.\n\nFor example, if you set the default table expiration to seven days, older data is\nautomatically deleted after one week.\n\nThis option is useful if you need access to only the most recent data. It is\nalso useful if you are experimenting with data and don't need to preserve it.\n\nIf your tables are partitioned by date, the dataset's default table expiration\napplies to the individual partitions. You can also control partition expiration\nusing the `time_partitioning_expiration` flag in the bq command-line tool or\nthe `expirationMs` configuration setting in the API. When a partition expires,\ndata in the partition is deleted but the partitioned table is not dropped even\nif the table is empty.\n\nFor example, the following command expires partitions after three days: \n\n```bash\nbq mk \\\n--time_partitioning_type=DAY \\\n--time_partitioning_expiration=259200 \\\nproject_id:dataset.table\n```\n\nAggregate long-term data\n------------------------\n\n**Best practice:** Identify if row-level data needs to be stored long term, and\nif not, only store aggregated data long term.\n\nIn many cases, details contained in transactional or row-level data are useful\nin the short term, but are referenced less over the long term. In these\nsituations, you can build aggregation queries to compute and store the metrics\nassociated with this data, and then use table or partition expiration to\nsystematically remove the row-level data. This reduces storage charges\nwhile keeping metrics available for long-term consumption.\n\nWhat's next\n-----------\n\n- Learn how to [optimize cost](/bigquery/docs/best-practices-costs).\n- Learn how to [optimize query](/bigquery/docs/best-practices-performance-compute).\n- Learn how to [optimize functions](/bigquery/docs/best-practices-performance-functions)."]]
