<ph type="x-smartling-placeholder"></ph>
현재 Apigee Edge 문서를 보고 있습니다.
Apigee X 문서. 정보
분석 측정항목, 측정기준, 필터에 대한 참조를 주제로 다룹니다. 자세한 내용은 API 분석 개요를 참조하세요.
이 주제에서는 UI에 표시되고 API 호출에 사용해야 하는 측정항목 및 측정기준의 이름을 보여줍니다.
측정항목
다음은 맞춤 보고서 및 관리 API 호출에서 검색할 수 있는 API 측정항목입니다.
맞춤 보고서 이름 | 관리 API에서 사용할 이름 | 함수 | 설명 |
---|---|---|---|
초당 평균 트랜잭션 수 | tps | 없음 |
초당 API 프록시 요청을 의미하는 평균 트랜잭션 수입니다. 특정 기간 동안 상대적으로 낮은 트랜잭션 수를 가지고 있다면 초당 평균 트랜잭션 수는 숫자가 소수점 두 자리보다 작다면 UI 맞춤 보고서에서 0으로 나타납니다. API 구문: |
캐시에 있음 | cache_hit | 합계 |
API 요청 대신 응답 캐시를 사용하는 성공한 API 요청의 응답을 전송합니다. API 구문: |
L1 캐시 요소 수 | ax_cache_l1_count | avg, min, max |
일정 기간 동안 트랜잭션당 L1(메모리 내) 캐시의 요소 수를 반환합니다. 예를 들어 하루의 특정 기간 동안 API 구문: |
정책 오류 | policy_error | 합계 |
지정된 기간 동안의 총 정책 오류 수입니다. 정책 오류는 일반적으로 설계에 따라 발생하는 계획적인 오류입니다. 예를 들어 Verify API 키 정책은 요청에 잘못된 API 키가 전달되었을 때의 오류 및 Spike Arrest 정책 API 호출 수가 정책에 정의된 한도를 초과하면 오류가 발생합니다. 따라서 이 측정항목은 API에서 잠재적인 문제가 있는 부분을 찾을 때 유용합니다. 예를 들어 developer_app 측정기준으로 그룹화된 policy_error 측정항목을 사용하면 특정 앱의 API 키 또는 OAuth 토큰이 만료된 경우 또는 A/B 테스트를 특정 API 프록시에서 많은 Spike Arrest 오류가 발생하므로 프록시의 급증 저지 한도는 연휴 트래픽 증가를 설명하지 않습니다. 정책 오류는 이 오류로 인해 API 프록시가 실패하는 경우에만 분석에 로깅됩니다.
예를 들어 정책의 오류 정책 이름(ax_execution_fault_policy_name) 측정기준은 정책 이름을 기준으로 정책 오류를 그룹화하는 데 유용합니다. 대상 오류(예시: 404 또는 503)는 정책 실패로 간주되지 않습니다. API 프록시 실패(is_error)로 간주됩니다. API 구문: |
프록시 오류 | is_error | 합계 |
지정된 기간 동안 API 프록시가 실패한 총 횟수입니다. 프록시 실패는 정책이 실패하거나 대상 서비스에서 404 또는 503과 같은 런타임 실패가 발생할 때 발생할 수 있습니다. 프록시(apiproxy) 측정기준은 프록시별로 API 프록시 오류를 그룹화하는 데 유용합니다. API 구문: |
요청 처리 지연 시간 | request_processing_latency | avg, min, max |
시간(평균, 최소 또는 최대)(밀리초) 수신 요청을 처리하는 데 필요합니다 요청이 Edge로, Edge가 요청을 대상 서비스로 전달하면 종료됩니다. 다른 측정기준을 사용하여 API 프록시, 개발자 앱, 리전 등을 기준으로 요청 처리 지연 시간을 검사할 수 있습니다. API 구문: |
요청 크기 | request_size | sum, avg, min, max |
Edge에서 수신한 요청 페이로드의 크기(바이트)입니다. API 구문: |
실행된 응답 캐시 | ax_cache_executed | 합계 |
지정된 기간 동안 응답 캐시 정책이 실행된 총횟수 있습니다. 응답 캐시 정책은 API 프록시의 두 위치(요청에서 한 번, 응답에서 한 번)에 첨부되므로 일반적으로 API 호출에서 두 번 실행됩니다. 캐시 'get'과 캐시 'put'은 각각 하나의 실행으로 집계됩니다. 그러나 정책의 Trace 도구에서 실행된 API 호출의 응답 캐시 아이콘을 클릭하고 API 구문: |
응답 처리 지연 시간 | response_processing_latency | avg, min, max |
시간(평균, 최소 또는 최대)(밀리초) 에지가 API 응답을 처리하는 데 필요합니다 API 프록시가 대상 서비스 응답을 받으면 시간이 시작되고 Apigee가 응답을 원래 발신자에게 전달하면 시간이 종료됩니다. 다른 측정기준을 사용하여 API 프록시, 리전 등을 기준으로 응답 처리 지연 시간을 검사할 수 있습니다. API 구문: |
응답 크기 | response_size | sum, avg, min, max |
클라이언트에 반환된 응답 페이로드의 크기(바이트)입니다. API 구문: |
대상 오류 | target_error | 합계 |
대상 서비스의 총 5xx 응답 수입니다. Apigee로 인해 발생한 것이 아닌 대상 서비스 오류입니다. API 구문: |
대상 응답 시간 | target_response_time | sum, avg, min, max |
시간 (합계, 평균, 최소 또는 최대) 밀리초여야 합니다. 이 측정항목은 대상 서버의 성능을 나타냅니다. Edge에서 요청을 전달하는 시간이 시작됩니다. 대상 서비스에 전달되며 Edge가 응답을 수신하면 종료됩니다. API 호출이 캐시에서 응답을 반환하는 경우(예를 들어 응답 캐시 정책 사용) 호출이 대상 서비스에 도달하지 않으며 대상 응답 시간 측정항목이 로깅되지 않습니다. API 구문: |
Total Response Time(총 대응 시간) | total_response_time | sum, avg, min, max |
시간 (합계, 평균, 최소 또는 최대) 밀리초: Edge가 클라이언트에서 요청을 수신하는 시점부터 이 시간까지 Edge가 응답을 클라이언트로 다시 보냅니다. 이 시간에는 네트워크 오버헤드(예를 들어 부하 분산기와 라우터가 작업을 하는 데 걸리는 시간), 요청 처리 지연 시간, 응답 처리 지연 시간, 대상 응답 시간(응답이 캐시 대신 대상 서비스에서 제공되는 경우)이 포함됩니다. 다른 측정기준을 사용하여 API 프록시, 개발자 앱, 리전 등을 기준으로 처리 지연 시간을 검사할 수 있습니다. API 구문: |
트래픽 | message_count | 합계 |
지정된 기간 동안 Edge에서 처리한 총 API 호출 수입니다. 측정기준을 사용하여 가장 의미있는 방식으로 트래픽 수를 그룹화합니다. API 구문: |
측정기준
측정기준을 사용하여 측정항목을 의미있는 그룹화로 확인할 수 있습니다. 예를 들어 각 개발자 앱 또는 API 프록시에서 총 트래픽 수를 확인할 때 총 트래픽 수가 훨씬 강력해집니다.
다음은 Apigee에서 즉시 사용할 수 있는 측정기준입니다. 또한 자체 측정기준을 참조하세요. 자세한 내용은 맞춤 분석을 사용하여 API 메시지 콘텐츠 분석을 참조하세요.
맞춤 보고서 이름 | 관리 API에서 사용할 이름 | 설명 |
---|---|---|
Apigee 항목 | ||
액세스 토큰 | access_token | 앱 최종 사용자의 OAuth 액세스 토큰입니다. |
API 제품 | api_product |
호출 중인 API 프록시가 포함된 API 제품의 이름입니다. 이 측정기준을 가져오려면 호출을 수행하는 개발자 앱이 API 프록시를 포함하는 하나 이상의 API 제품과 연결되어야 하며 호출되는 프록시가 API 호출로 전송된 API 키 또는 OAuth 토큰을 확인해야 합니다. 키나 토큰은 API 제품과 연결되어 있습니다. 자세한 내용은 가장 먼저 할 일: 완전한 분석 데이터를 생성하는 방법 위의 기준이 충족되지 않으면 '(not set)' 값이 표시됩니다. 분석 항목 값 '(not set)'의 의미도 참조하세요. |
캐시 키 | ax_cache_key |
액세스된 응답 캐시 값이 포함된 키입니다. 자세한 내용은 응답 캐시에 대해 키가 생성되는 방식은 응답 캐시 정책을 참조하세요. Trace 도구에서 캐시를 읽거나 작성하는 응답 캐시 정책을 선택할 때 |
캐시 이름 | ax_cache_name |
응답 캐시 정책에서 사용하는 키/값을 포함한 캐시의 이름으로 orgName__envName__으로 시작합니다. 예를 들어 조직이 'foo'이고 환경은 'test'이며 캐시 이름은 'myCache'인 경우 ax_cache_name은 foo__test__myCache입니다. Trace 도구에서 응답 캐시 정책을 선택할 때 |
캐시 소스: | ax_cache_source |
응답 캐시의 캐시 수준('L1' 인메모리 또는 'L2' 데이터베이스) 있습니다. 이 측정기준에는 'CACHE_MISS'도 표시됩니다. 응답이 전송된 시점 캐시 대신 타겟을 사용하고 응답 캐시가 타겟 응답으로 새로고침되었습니다. 또는 요청의 캐시 키가 유효하지 않은 경우. 캐시 키는 크기가 2KB로 제한됩니다. Trace 도구에서 응답 캐시 정책을 선택할 때 캐시 수준에 대한 자세한 내용은 캐시 내부를 참조하세요. |
클라이언트 ID | client_id |
요청에 API 키로 전달되거나 OAuth 토큰에 포함된 API 호출을 하는 개발자 앱의 고객 키(API 키)입니다. 이 측정기준을 가져오려면 호출을 수신하는 프록시가 유효한 API 키 또는 OAuth 토큰을 확인하도록 구성해야 합니다. 개발자 앱은 다음을 수행하는 데 사용할 수 있는 API 키를 가져옵니다. 앱이 Edge에 등록될 때 OAuth 토큰 생성 자세한 내용은 가장 먼저 할 일: 완전한 분석 데이터를 생성하는 방법 위의 기준이 충족되지 않으면 '(not set)' 값이 표시됩니다. 분석 항목 값 '(not set)'의 의미도 참조하세요. |
개발자 앱 | developer_app |
API를 호출하는 에지 등록 개발자 앱 이 측정기준을 가져오려면 앱이 호출되는 API 프록시를 포함하는 하나 이상의 API 제품과 연결되어야 하며, 프록시는 API 호출과 함께 전송되는 API 키 또는 OAuth 토큰을 확인해야 합니다. 키 또는 토큰은 개발자 앱을 식별합니다. 대상 자세한 내용은 가장 먼저 할 일: 완전한 분석 데이터를 생성하는 방법을 참고하세요. 위의 기준이 충족되지 않으면 '(not set)' 값이 표시됩니다. 분석 항목 값 '(not set)'의 의미도 참조하세요. |
개발자 이메일 | developer_email |
API를 호출한 앱의 에지 등록 개발자의 이메일입니다. 이 측정기준을 가져오려면 개발자는 호출되는 API 프록시를 포함하는 하나 이상의 API 제품과 연결된 앱을 가지고 있어야 하며, 프록시는 API 호출과 함께 전송되는 API 키 또는 OAuth 토큰을 확인해야 합니다. 키 또는 토큰은 개발자를 식별합니다. 있습니다. 자세한 내용은 가장 중요한 작업: 완전한 분석 데이터를 생성하는 방법을 참고하세요. 위의 기준이 충족되지 않으면 '(not set)' 값이 표시됩니다. 분석 항목 값 '(not set)'의 의미도 참조하세요. |
개발자 ID | 개발자 |
다음과 같은 형식의 고유한 에지 생성 개발자 ID입니다. org_name@@@org_name로 변경합니다. 이 측정기준을 가져오려면 개발자는 호출되는 API 프록시를 포함하는 하나 이상의 API 제품과 연결된 앱을 가지고 있어야 하며, 프록시는 API 호출과 함께 전송되는 API 키 또는 OAuth 토큰을 확인해야 합니다. 키 또는 토큰으로 개발자를 식별합니다. 자세한 내용은 가장 중요한 작업: 완전한 분석 데이터를 생성하는 방법을 참고하세요. 위의 기준이 충족되지 않으면 '(not set)' 값이 표시됩니다. 분석 항목 값 '(not set)'의 의미도 참조하세요. |
환경 | 환경 | API 프록시가 배포되는 에지 환경입니다. 예: 'test' 또는 'prod' |
오류 시 오류 코드 | ax_edge_execution_fault_code |
오류의 오류 코드입니다. 예를 들면 다음과 같습니다.
|
오류의 흐름 이름 | ax_execution_fault _flow_name |
오류를 발생시킨 API 프록시에서 이름이 지정된 flow 예를 들어 'PreFlow', 'PostFlow' 또는 생성한 조건부 흐름의 이름입니다. 관리 API에서 사용할 전체 이름은 ax_execution_fault_flow_name 할 수 있습니다. 오류가 발생하지 않으면 '(not set)' 값이 표시됩니다. |
흐름 리소스 | flow_resource | Apigee 전용입니다. 궁금한 점이 있으면 이 커뮤니티 게시물을 참고하세요. |
오류의 흐름 상태 | ax_execution_fault _flow_state |
오류를 일으킨 API 프록시 흐름의 이름입니다(예: 'PROXY_REQ_FLOW'). 또는 'TARGET_RESP_FLOW' 관리 API에서 사용할 전체 이름은 ax_execution_fault_flow_state입니다. 할 수 있습니다. |
게이트웨이 흐름 ID | gateway_flow_id | API 호출이 Edge를 통해 이동하면 각 호출은 자체 게이트웨이 흐름 ID를 가져옵니다. 예시: rrt329ea-12575-114653952-1. 게이트웨이 흐름 ID는 조직, 환경, 타임스탬프와 같은 다른 측정 기준이 모든 호출에서 동일한 높은 TPS가 상황에서 측정항목을 구분하는 데 유용합니다. |
조직 | 조직 | API 프록시가 배포된 에지 조직입니다. |
오류의 정책 이름 | ax_execution_fault _policy_name |
오류가 발생했고 API 호출 실패를 일으킨 정책의 이름입니다. Management API에서 사용할 전체 이름은 ax_execution_fault_policy_name 할 수 있습니다. 정책에서 오류가 발생하지만 정책 루트 속성 |
프록시 | apiproxy | API 프록시의 머신 이름(표시 이름 아님)입니다. |
프록시 기본 경로 | proxy_basepath |
API 프록시 ProxyEndpoint에 구성된 BasePath입니다. 기본 경로에는 API 프록시 URL의 도메인 및 포트 부분이 포함되지 않습니다. 예를 들어 API 프록시의 기본 URL이 https://apigeedocs-test.apigee.net/releasenotes/ 기본 경로는 /releasenotes입니다. 이 값은 |
프록시 경로 서픽스 | proxy_pathsuffix |
API 프록시 기본 경로에 추가된 리소스 경로입니다. 예를 들어 API 프록시의 기본 URL이 pathsuffix를 사용하지 않으면 이 값이 비어 있습니다. 이 값은 |
프록시 버전 | apiproxy_revision | API 호출을 처리한 API 프록시의 버전 번호입니다. 그렇다고 해서 API 프록시의 최신 버전을 의미하지는 않습니다. API 프록시에 10개의 버전이 있는 경우 8번째 버전은 현재 배포될 수 있습니다. 또한 API에 다음과 같이 여러 버전이 배포되어 있을 수 있습니다. 단, UI에서 프록시 배포에 설명된 대로 버전의 기본 경로가 달라야 합니다. |
확인된 클라이언트 IP | ax_resolved_client_ip |
원본 클라이언트 IP 주소를 포함합니다. Akamai와 같은 라우팅 제품을 사용하여 클라이언트의 실제 IP 주소를 캡처하는 경우
클라이언트 IP가 HTTP 헤더
|
응답 상태 코드 | response_status_code | Apigee에서 클라이언트로 전달되는 HTTP 응답 상태 코드(예시: 200, 404, 503 등) Edge에서는 대상의 응답 상태 코드를 메시지 할당 및 오류 발생과 같은 정책으로 인해 따라서 이 측정기준은 타겟 응답 코드 (target_response_code)와 다를 수 있습니다. |
가상 호스트 | virtual_host | 가상 호스트의 이름은
API 호출이 예를 들어 조직에는
가상 호스트: default (http) 및 secure (https) |
인바운드/클라이언트 | ||
클라이언트 IP 주소 | client_ip | 원본 클라이언트(proxy_client_ip) 또는 부하 분산기와 같이 라우터에 도달하는 시스템의 IP 주소입니다. X-Forwarded-For 헤더에 여러 IP가 있으면 이는 나열된 마지막 IP입니다. |
기기 카테고리 | ax_ua_device_category | API 호출이 발생한 기기의 유형(예시: '태블릿' 또는 '스마트폰') |
OS 제품군 | ax_ua_os_family | 호출을 수행하는 기기의 운영체제 제품군입니다(예시: 'Android' 또는 'iOS'). |
OS 버전 | ax_ua_os_version |
호출을 수행하는 기기의 운영체제 버전입니다. 이를 OS 제품군(ax_ua_os_family)과 함께 두 번째 '드릴다운' 측정기준으로 사용하면 운영체제의 버전을 확인하는 데 유용합니다. |
프록시 클라이언트 IP | proxy_client_ip |
|
추천 클라이언트 IP | ax_true_client_ip | Akamai와 같은 라우팅 제품을 사용하여 클라이언트의 실제 IP 주소를 캡처할 때,
클라이언트 IP가 HTTP 헤더 원래 클라이언트 IP 주소를 확인하기 위해 |
요청 경로 | request_path |
쿼리 매개변수를 제외하고 대상 서비스에 대한 리소스 경로(도메인 제외)입니다. 예를 들어 Apigee 샘플 대상 |
URI 요청 | request_uri |
쿼리 매개변수를 포함한 대상 서비스에 대한 리소스 경로(도메인 제외)입니다. 예를 들어 Apigee 샘플 대상 |
요청 동사 | request_verb | API 요청의 HTTP 요청 동사(예: GET, POST, PUT, DELETE) |
사용자 에이전트 | useragent |
API 호출에 사용되는 사용자 에이전트 또는 소프트웨어 에이전트의 이름입니다. 예:
|
사용자 에이전트 제품군 | ax_ua_agent_family | useragent의 제품군(예시: 'Chrome Mobile' 또는 'cURL') |
사용자 에이전트 유형 | ax_ua_agent_type | useragent 유형(예시: 'Browser', 'Mobile Browser', 'Library' 등) |
사용자 에이전트 버전 | ax_ua_agent_version |
useragent의 버전입니다. 이를 사용자 에이전트 제품군(ax_ua_agent_family)과 함께 두 번째 '드릴다운' 측정기준으로 사용하면 에이전트 제품군의 버전을 가져오는 데 유용합니다. |
아웃바운드/대상 | ||
대상 기본 경로 | target_basepath |
프록시의 예를 들어 API 프록시가 다음 대상을 호출한다고 가정해 보겠습니다. <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> 이 예시에서 target_basepath는 대상이 다음과 같은 경우: <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net</URL> </HTTPTargetConnection> target_basepath가 null이 됩니다. Trace 도구에서 흐름 다이어그램의 끝에 있는 AX 아이콘을 선택하면 |
대상 호스트 | target_host | 대상 서비스의 호스트입니다. 예를 들어 API 프록시가 http://mocktarget.apigee.net/help 를 호출하면 target_host는 mocktarget.apigee.net 입니다. |
대상 IP 주소 | target_ip | API 프록시에 응답을 반환하는 대상 서비스의 IP 주소입니다. |
대상 응답 코드 | target_response_code |
대상 서비스에서 API 프록시에 반환한 HTTP 응답 상태 코드입니다. 예를 들면 다음과 같습니다. 200, 404, 503 등 'null' 값 요청이 대상 서비스에 도달하지 않았다는 의미입니다. 이는 다음과 같은 경우에 발생합니다. 응답 캐시 정책에 의해 응답이 제공되거나 요청에 실패했을 때 가장 적합합니다 이는 응답 상태 코드(response_status_code) 측정기준과는 다릅니다. |
대상 URL | target_url |
API 프록시의 TargetEndpoint에 정의된 대상 서비스의 전체 URL입니다. <TargetEndpoint name="default"> ... <HTTPTargetConnection> <URL>http://mocktarget.apigee.net/user?user=Dude</URL> </HTTPTargetConnection> 이 예시에서 target_url은
프록시 체이닝과 스크립트를 사용할 때 대상 (Node.js)의 경우 호출 프록시의 target_url이 null입니다. |
X Forwarded For | x_forwarded_for_ip |
원래 클라이언트 IP 주소를 확인하기 위해 |
시간 | ||
요일 | ax_day_of_week | API 호출이 수행된 요일의 세 글자 약어입니다. 예시: Mon, Tue, Wed |
월 | ax_month_of_year | API 호출이 수행된 월(숫자)입니다. 예: '03' 2024년 3월 |
시간 | ax_hour_of_day |
24시간제를 기준으로 API 호출이 수행된 두 자릿수 시간입니다. 예를 들어 API 호출은 오후 10시에서 11시 사이에 이루어지며 ax_hour_of_day는 22입니다. 시간 값은 UTC 기준입니다. |
시간대 | ax_geo_timezone | API가 작성된 시간대의 일반적인 이름입니다(예시: America/New_York 및 Europe/Dublin). |
월별 주차 | ax_week_of_month | 주의 숫자 표기입니다. 예를 들어 한 달 중 세 번째 주에 수행된 API 호출의 경우 ax_week_of_month는 3입니다. |
Location | ||
시 | ax_geo_city | API 호출이 수행된 도시입니다. |
대륙 | ax_geo_continent | API 호출이 수행된 대륙의 두 글자 코드입니다. 예를 들어 북미의 경우 NA입니다. |
국가 | ax_geo_country | API 호출이 수행된 국가의 두 자리 코드입니다. 예를 들어 미국의 경우 US입니다. |
지역 | ax_geo_region | 하이픈으로 구분된 지리적 지역의 코드(예: STATE-COUNTRY)입니다. 예를 들어 워싱턴-미국의 경우 WA-US입니다. |
리전 | ax_dn_region | API 프록시가 배포된 Apigee 데이터 센터의 이름입니다(예: us-east-1로 이동합니다. |
수익 창출 | ||
민트 거래 무시 메시지 | x_apigee_mint_tx_ignoreMessage | 수익 창출과 관련된 메시지를 무시할지 여부를 지정하는 플래그입니다. 모든 수익 창출 조직에 대해 false 로 설정합니다. |
조폐국 거래 상태 | x_apigee_mint_tx_status | 성공, 실패, 유효하지 않음 또는 없음과 같은 수익 창출 요청의 상태입니다. |
필터
필터를 사용하면 특정 특성이 있는 측정항목으로 결과를 제한할 수 있습니다. 다음은 몇 가지 샘플 필터입니다. 필터를 정의할 때 측정항목 및 측정기준 API 스타일의 이름을 사용합니다.
이름 목록 또는 음악이 있는 API 프록시에 대한 측정항목을 반환합니다.
filter=(apiproxy in 'books','music')
이름이 'm'으로 시작하는 API 프록시에 대한 측정항목을 반환합니다.
filter=(apiproxy like 'm%')
이름이 'm'으로 시작하지 않는 API 프록시에 대한 측정항목을 반환합니다.
filter=(apiproxy not like 'm%')
400에서 599 사이의 응답 상태 코드가 있는 API 호출의 측정항목을 반환합니다.
filter=(response_status_code ge 400 and response_status_code le 599)
응답 상태 코드가 200이고 타겟 응답 코드가 다음과 같은 API 호출에 대한 측정항목을 반환합니다. 404:
filter=(response_status_code eq 200 and target_response_code eq 404)
응답 상태 코드가 500인 API 호출에 대한 측정항목을 반환합니다.
filter=(response_status_code eq 500)
오류가 발생하지 않은 API 호출의 측정항목을 반환합니다.
filter=(is_error eq 0)
다음은 보고서 필터를 빌드하는 데 사용할 수 있는 연산자입니다.
연산자 | 설명 |
---|---|
in |
목록에 포함 |
notin |
목록에서 제외 |
eq |
같음, == |
ne |
같지 않음, != |
gt |
초과, > |
lt |
미만, < |
ge |
이상, >= |
le |
이하, <= |
like |
문자열 패턴이 제공된 패턴과 일치하면 true를 반환합니다. |
not like |
문자열 패턴이 제공된 패턴과 일치하면 false를 반환합니다. |
similar to |
패턴이 지정된 문자열과 일치하는지 여부에 따라 true 또는 false를 반환합니다. 정규 표현식의 SQL 표준 정의를 사용하여 패턴을 해석한다는 점을 제외하면 like 과 유사합니다. |
not similar to |
패턴이 지정된 문자열과 일치하는지 여부에 따라 false 또는 true를 반환합니다. 정규 표현식의 SQL 표준 정의를 사용하여 패턴을 해석한다는 점을 제외하면 not like 와 유사합니다. |
and |
'and' 논리를 사용하여 두 개 이상의 필터 표현식을 포함할 수 있습니다. 필터에는 모든 조건을 충족하는 데이터가 포함됩니다. |
or |
'or' 논리를 사용하여 가능한 여러 필터 표현식을 평가할 수 있습니다. 필터에는 조건 중 하나 이상을 충족하는 데이터가 포함됩니다. |