Bigtable에서 데이터를 읽을 때 특정 행 또는 행 범위를 읽을 수 있습니다. 하지만 모든 행의 모든 데이터가 항상 필요한 것은 아닙니다. row key에 특정 값이 포함된 행이나 특정 column family 내의 셀만 필요할 수 있습니다.
읽기 요청의 결과를 제한하려면 요청에 필터를 포함하세요. 필터는 응답이 전송되기 전에 데이터에 적용되므로 반환되는 데이터의 양이 줄어듭니다. 따라서 필터를 사용하면 네트워크 비용이 절감되고 처리 속도가 빨라집니다. 이 페이지에서는 Bigtable 필터의 작동 방식과 사용 가능한 필터 목록을 설명합니다.
읽기 요청에 필터가 포함되어 있으면 Bigtable은 테이블에서 행 또는 행 범위를 검색합니다. Bigtable은 검색하는 입력 행마다 필터를 사용하여 행을 평가한 다음 필터 결과를 기반으로 출력 행을 생성합니다.
Bigtable은 다음 섹션에 설명된 대로 여러 유형의 필터를 제공합니다. 기본 필터는 제한과 수정이라는 두 가지 범주로 나뉩니다. 기본 필터를 구성 필터로 결합할 수 있습니다.
대부분의 경우 필터는 row key, 행 범위 또는 필터를 적용해야 하는 행 수를 지정하지 않는 한 모든 행에 적용됩니다. 예외적으로 row key 정규식 필터는 정규식이 고정된 프리픽스인 경우 행 범위를 제한할 수 있습니다. 일반적으로 전체 테이블 검색이 느려지지 않도록 하려면 항상 필터 행을 지정합니다.
제한 필터
제한 필터는 특정 기준과 일치하는지 여부에 따라 응답에 포함될 행 또는 셀을 제어합니다. 예를 들어 row key가 정규 표현식과 일치하는 행만 응답에 포함되어야 한다거나 특정 column family의 셀만 필요하다고 지정할 수 있습니다.
제한 필터 중 다수는 출력 행에서 셀을 제외할 수 있습니다. 모든 셀이 제외된 출력 행은 응답에 포함되지 않습니다.
값 제거 필터는 각 셀의 값을 빈 문자열로 바꿉니다. 이 필터는 기준과 일치하는 행의 데이터가 아니라 그 행의 수 또는 row key 목록만 필요할 때 유용합니다.
라벨 적용 필터는 각 셀에 라벨을 적용하여 응답에서 각 셀을 생성한 필터를 식별합니다. 애플리케이션은 이 라벨을 사용하여 클라이언트 측에서 추가 필터링을 수행할 수 있습니다.
구성 필터
구성 필터를 사용하면 여러 기본 필터를 하나로 결합하여 단일 읽기 요청에 둘 이상의 필터를 적용할 수 있습니다.
예를 들어 서버의 CPU 사용량 데이터를 가져오려면 필터 하나를 사용하여 row key가 SERVER로 시작하는 행만 포함한 다음, 두 번째 필터를 사용하여 CPU column family 내의 셀만 포함할 수 있습니다.
Bigtable은 다음과 같은 구성 필터를 제공합니다.
체인은 각 입력 행에 필터 시퀀스를 적용하고 출력 행을 반환합니다. 체인 필터는 논리곱을 사용하는 것과 같습니다.
인터리브는 여러 필터를 통해 각 입력 행을 전송한 다음 입력 행의 모든 필터 결과를 단일 출력 행으로 결합합니다. 인터리브 필터는 논리합을 사용하는 것과 같습니다.
조건은 입력 행에 가능한 두 필터 중 하나를 적용하여 출력 행을 생성합니다. 입력 행에 조건자 필터를 적용한 다음 조건자 필터의 출력 행에 셀이 포함되어 있는지 확인하여 조건 필터가 선택됩니다.
필터 및 성능
필터를 사용하면 실제로 필요한 데이터만 검색할 수 있습니다. 따라서 필터 사용을 통해 애플리케이션으로 전송되는 데이터의 양을 줄일 수 있습니다.
하지만 필터가 모든 성능 문제의 만능 해법은 아닙니다. 일반적으로 필터는 요청 전송과 응답 수신 간의 지연 시간을 줄이기 위해서가 아니라 처리량 효율을 제어하기 위해 사용해야 합니다. 필터를 적절히 사용하면 읽기 성능 개선 전략에서 효율성 측면을 개선할 수 있습니다.
특히 조건 필터는 다른 필터보다 훨씬 느리기 때문에 지연 시간을 늘릴 수 있습니다. 읽기 요청이 성능에 매우 민감하다면 요청에 조건을 사용하지 마세요.
필터 요약
다음 표에는 Bigtable이 제공하는 필터와 각 필터의 세부정보 및 코드 샘플 링크가 나와 있습니다.
[[["이해하기 쉬움","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\u003eFilters in Bigtable refine read requests by limiting the data returned, thus reducing network costs and improving throughput.\u003c/p\u003e\n"],["\u003cp\u003eBigtable filters fall into three categories: limiting filters, which control the inclusion of rows or cells based on criteria; modifying filters, which alter cell data or metadata; and composing filters, which combine multiple filters.\u003c/p\u003e\n"],["\u003cp\u003eLimiting filters can exclude rows or cells based on row keys, column families, timestamps, or values, and many will result in a whole row being excluded if all the cells are excluded.\u003c/p\u003e\n"],["\u003cp\u003eModifying filters, such as the strip value filter and apply label filter, will change the output of a read request by either removing the value of each cell or by adding a label respectively.\u003c/p\u003e\n"],["\u003cp\u003eComposing filters, including chain, interleave, and condition, enable complex filtering by applying multiple filters sequentially, combining results from multiple filters, or conditionally selecting one of two filters.\u003c/p\u003e\n"]]],[],null,["# Filters\n=======\n\nWhen you read data from Bigtable, you can read specific rows or ranges\nof rows. However, you don't always need all of the data in all of the rows. You\nmight only need rows that contain a specific value in their row key, or cells\nwithin a specific column family.\n\nTo limit the results of a read request, include *filters* in the request. A\nfilter is applied to the data before the response is sent, reducing the amount\nof data that is returned. As result, using filters can mean lower network costs\nand faster throughput. This page provides an overview of how\nBigtable filters work and a list of available filters.\n\nFor details and code samples for each filter, see [Filter examples](/bigtable/docs/using-filters).\n\n\n| **Note:** The HBase client for Java uses HBase's filter APIs instead of the Bigtable Data API. To learn about HBase's filter APIs, see the [HBase documentation](https://hbase.apache.org/book.html#client.filter).\n\n\u003cbr /\u003e\n\nHow filters work\n----------------\n\nWhen your read request includes a filter, Bigtable retrieves a row\nor a range of rows from your table. For each of the *input rows* that it\nretrieves, Bigtable evaluates the row using your filter, then\ngenerates an *output row* based on the filter results.\n\nBigtable provides several types of filters, as described in the\nfollowing sections. Basic filters fall under two categories: *limiting* and\n*modifying* . You can combine basic filters into *composing* filters.\n\nIn most cases, a filter is applied to *all rows* unless you specify row key,\nrow range, or number of rows that the filter should be applied to. One exception\nis the [row key regex](/bigtable/docs/using-filters#row-key-regex) filter, which\ncan restrict the row range in certain cases if the regex is a fixed prefix. In\ngeneral, to avoid the slowness of a full table scan, always specify the rows for\na filter.\n\n### Limiting filters\n\nA *limiting filter* controls which rows or cells are included in the response,\nbased on whether they match specific criteria. For example, you can say that\nthe response should include only rows in which the row key matches a regular\nexpression, or that you want only cells from a specific column family.\n\nMany limiting filters can exclude cells from an output row. If all of the cells\nare excluded from an output row, the row is not included in the response.\n\nSee the [Summary of filters](#summary) for a complete list of limiting filters.\n\n### Modifying filters\n\nA *modifying filter* affects the data or metadata for individual cells.\n| **Note:** Modifying filters affect the data that is returned in the read request, *not* the data in the table.\n\nBigtable provides the following modifying filters:\n\n- The [**strip value filter**](/bigtable/docs/using-filters#strip-value), which replaces each cell's value\n with an empty string. This filter is useful when you only need the number of\n rows or the list of row keys that meet your criteria, rather than the data from\n those rows.\n\n- The [**apply label filter**](/bigtable/docs/using-filters#apply-label), which applies a label to each cell\n to identify which filter produced each cell in the response. Your application\n can use these labels to perform additional filtering on the client side.\n\n### Composing filters\n\nA *composing filter* allows you to combine multiple basic filters into one,\nwhich makes it possible to apply more than one filter to a single read request.\nFor example, to get CPU usage data for your servers, you could use one filter to\ninclude only rows where the row key starts with `SERVER`, followed by a second\nfilter to include only cells within the `CPU` column family.\n\nBigtable provides the following composing filters:\n\n- A [**chain**](/bigtable/docs/using-filters#chain), which applies a sequence of filters to each input row and returns an output row. A chain filter is like using a logical AND.\n- An [**interleave**](/bigtable/docs/using-filters#interleave), which sends each input row through multiple filters, then combines all of the filter results for the input row into a single output row. An interleave filter is like using a logical OR.\n- A [**condition**](/bigtable/docs/using-filters#condition), which generates an output row by applying one of two possible filters to the input row. The filter is chosen by applying a predicate filter to the input row, then checking to see whether the predicate filter's output row contains any cells.\n\nFilters and performance\n-----------------------\n\nFilters allow you to retrieve only the data you actually need. As a result,\nfilters can improve performance by reducing the amount of data that is sent to\nyour application.\n\nHowever, filters are not an all-purpose solution to every performance issue. In\ngeneral, filters should be used to control *throughput efficiency* , not to\nreduce the latency between sending a request and receiving a response. Used\ncorrectly, filters can be an effective part of a strategy to [improve read\nperformance](/bigtable/docs/reads#performance).\n\nThe [conditions](/bigtable/docs/using-filters#condition) filter, in particular, can increase latency,\nbecause conditions are much slower than other filters. If your read request is\nextremely performance-sensitive, do not use conditions in the request.\n| **Warning:** Using a regex rowkey filter without also specifying a start, end, prefix, or number of rows results in a full table scan, which can be slow.\n\nSummary of filters\n------------------\n\nThe following tables list the filters that Bigtable provides,\nincluding links to details and code samples for each filter.\n\nWhat's next\n-----------\n\n- [See samples of read requests.](/bigtable/docs/reads)\n- [Explore samples of write requests.](/bigtable/docs/writes)"]]
