Bigtable에서 가비지 컬렉션 정책은 column family 수준에서 설정되며 개발자는 셀 수준 가비지 컬렉션 정책을 지정할 수 없습니다. 하지만 가비지 컬렉션 설정을 변경하여 셀 수준에서 TTL(수명) 정책을 시뮬레이션할 수 있습니다. 이 페이지에서는 사용 가능한 몇 가지 방식을 설명합니다.
이 방식에서는 1초 후에 데이터가 만료되도록 가비지 컬렉션 규칙을 설정합니다. 데이터를 쓸 때마다 셀의 타임스탬프를 값 만료 시간으로 설정합니다. 압축하는 동안 Bigtable은 1초 이상 지난 타임스탬프가 있는 모든 셀을 삭제합니다. 예를 들어 셀의 타임스탬프를 4월 30일 오전 9:00:00으로 설정하면 4월 30일 오전 9:00:01 이후의 셀은 삭제됩니다. 이 방식을 통해 같은 column family에 있는 다양한 셀에 서로 다른 만료 값을 설정할 수 있습니다.
1초 만료의 장점
타임스탬프가 실제 만료 시간입니다.
1초 만료의 단점
이 Bigtable Column Family에 데이터를 쓰는 모든 애플리케이션이 이 규칙을 따르도록 구성해야 합니다. 이를 잊어버리고 쓰기에 기본 서버 타임스탬프를 사용하면 데이터가 즉시 만료되고 다음 압축 시에 삭제됩니다.
타임스탬프가 '실제'가 아니므로 타임스탬프를 다른 사용 사례(예: 값을 쓴 시간 확인)에 사용할 수 없습니다. 이 문제를 해결하기 위해 별도의 열에 실제 타임스탬프를 기록할 수 있지만 이렇게 하면 저장되는 데이터 양이 증가합니다.
실제 타임스탬프가 있는 데이터가 이미 있는 Column Family에서는 이 방식을 구현할 수 없습니다. 기존 데이터에 실제 타임스탬프가 있거나 실수로 실제 타임스탬프가 있는 새 데이터를 쓰면 데이터가 다음 압축 시에 삭제됩니다.
제공된 행과 열의 여러 셀이 동시에 만료되도록 지정할 수 없습니다. 새 데이터는 동일한 타임스탬프를 가진 이전 데이터를 덮어씁니다.
가비지 컬렉션에 최대 일주일이 소요될 수 있으므로 데이터를 읽을 때는 항상 필터를 사용해야 합니다.
기본 만료
대부분의 데이터에 기본 TTL이 있기를 원하지만 일부 데이터에 셀 기준 만료 값을 다르게 설정한다고 가정합니다.
예를 들어 고객 10명의 클릭 이벤트를 테이블 한 개에 저장할 수 있습니다. 대부분의 클릭 이벤트는 2일 후에 만료되지만 1시간 후에 클릭 이벤트가 만료되는 고객이 1명 있고 3일 후에 만료되는 고객이 1명 있습니다.
이 방식에서는 가비지 컬렉션의 저장기간 제한을 기본 TTL로 설정하여 column family를 만듭니다. 데이터를 기본값보다 빨리 만료시키려면 타임스탬프를 데이터의 실제 쓰기 시간보다 이른 시간으로 설정합니다. 데이터를 나중에 만료시키려면 데이터의 실제 쓰기 시간보다 늦은 시간으로 타임스탬프를 설정합니다.
기본 만료의 장점
커스텀 TTL이 없는 쓰기에는 기본 TTL이 사용됩니다.
기존 테이블에 안전하게 적용할 수 있는 방식입니다.
기본 만료의 단점
셀의 타임스탬프가 실제이거나 인위적일 수 있으므로 타임스탬프에는 의미가 없습니다. 즉, 셀의 타임스탬프를 다른 사용 사례(예: 값을 쓴 시간 확인)에 사용할 수 없습니다.
이 문제를 해결하기 위해 별도의 열에 실제 타임스탬프를 기록할 수 있지만 이렇게 하면 저장되는 데이터 양이 증가합니다.
제공된 열의 실제 타임스탬프와 충돌하는 커스텀 타임스탬프를 실수로 쓸 수 있습니다.
가비지 컬렉션은 비동기식이므로 이 방식으로 데이터를 읽을 때는 항상 필터를 사용해야 합니다.
[[["이해하기 쉬움","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 page details methods to simulate cell-level time-to-live (TTL) policies in Bigtable, which natively only supports garbage collection at the column family level.\u003c/p\u003e\n"],["\u003cp\u003eThe "one-second expiration" approach involves setting a column family's garbage collection rule to expire data after one second, with the cell's timestamp set to the desired expiration time.\u003c/p\u003e\n"],["\u003cp\u003eThe "default expiration" strategy involves setting a default TTL at the column family level, while allowing for per-cell adjustments by manipulating the cell's timestamp.\u003c/p\u003e\n"],["\u003cp\u003eBoth expiration approaches use timestamps that may not be semantically meaningful for data creation time and require filters when reading data due to asynchronous garbage collection.\u003c/p\u003e\n"],["\u003cp\u003eBoth approaches have some advantages, such as how default expiration can be safely applied to pre-existing table, but also disadvantages such as the data write process needing to be configured correctly in the one-second approach.\u003c/p\u003e\n"]]],[],null,["Simulate cell-level TTL\n\nIn Bigtable, garbage collection policies are set at the\ncolumn family level, and you cannot specify a cell-level garbage collection\npolicy. However, you can simulate a time to live (TTL) policy at the cell level\nby changing your garbage collection settings. This page explains a few different\napproaches that you can use.\n\nBefore you read this page, you should read the [garbage collection overview](/bigtable/docs/garbage-collection). To learn how to send write requests, which\ninclude timestamps, see [Bigtable writes](/bigtable/docs/writes).\n\nOne-second expiration\n\nIn this approach, set your garbage collection rule to let data expire after one\nsecond. Whenever you write data, set the cell's timestamp to the time you want\nthe value to expire. During compaction, Bigtable deletes any cells\nthat have a timestamp that is at least one second in the past. For example, if\nyou set a cell's timestamp to April 30 at 9:00:00 AM, the cell is deleted\nsometime after April 30 at 9:00:01 AM. This approach enables you to set\ndifferent expiration values for different cells in the same column family.\n\nAdvantages of one-second expiration\n\n- The timestamp has a real meaning: the expiration time.\n\nDisadvantages of one-second expiration\n\n- Every application that writes data to this Bigtable column\n family needs to be configured to follow this rule. If you forget and use a\n default server timestamp on a write, that data expires right away\n and is deleted during the next compaction.\n\n- Because your timestamps aren't \"real\" you cannot use timestamps for any other\n use case, such as determining when a value was written. As a workaround, you can\n write the real timestamp to a separate column, but this will increase the amount\n of data you store.\n\n- **You cannot implement this strategy on a column family that already has data\n with real timestamps.** If existing data has real timestamps, or if you\n accidentally write new data with real timestamps, that data is deleted\n during the next compaction.\n\n- You cannot specify that multiple cells for a given row and column should\n expire at the same time as each other. New data will overwrite old data with the\n same timestamp.\n\n- Because garbage collection can take up to a week, you always need to use\n filters when you read the data.\n\nDefault expiration\n\nLet's say you want most of your data to have a default TTL, but you want to set\ndifferent per-cell expiration values for some of your data.\n\nFor example, you might store click events for ten customers in one table. Most\nof the click events should expire after 2 days, but you have one customer whose\nclick events should expire after an hour, and you have another customer whose\nclick events should expire after 3 days.\n\nIn this approach, create your column family with an age limit for garbage\ncollection set to the default TTL. For data you want to expire sooner than the\ndefault, set the timestamp to be earlier than the time the data is actually\nwritten. For data you want to expire later, set the timestamp to be later than\nthe time the data is actually written.\n\nAdvantages of default expiration\n\n- A default TTL is in place for writes that do not have a custom TTL.\n\n- This approach can safely be applied to a pre-existing table.\n\nDisadvantages of default expiration\n\n- The timestamp is not semantically meaningful because a cell's timestamp\n might be real or artificial. This means you cannot use the cells'\n timestamps for any other use case, such as determining when a value was written.\n As a workaround, you can write the real timestamp to a separate column, but\n this will increase the amount of data you store.\n\n- You can inadvertently write a custom timestamp that clashes with a real\n timestamp in a given column.\n\n- Because garbage collection is asynchronous, you still need to always use\n filters when you read the data when you use this strategy.\n\nWhat's next\n\n- Read about garbage collection with [timestamps that are sequential numbers](/bigtable/docs/gc-sequence-numbers).\n- Learn a strategy to [always read the most recent value of a column](/bigtable/docs/keep-only-latest-value).\n- Review code samples showing how to [configure garbage collection](/bigtable/docs/configuring-garbage-collection).\n- Learn more about [storage pricing](/bigtable/pricing#storage)."]]
