현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보
분석 측정항목, 측정기준, 필터에 대한 참조를 주제로 다룹니다. 자세한 내용은 API 분석 개요를 참조하세요.
이 주제에서는 UI에 표시되고 API 호출에 사용해야 하는 측정항목 및 측정기준의 이름을 보여줍니다.
측정항목
다음은 맞춤 보고서 및 관리 API 호출에서 검색할 수 있는 API 측정항목입니다.
맞춤 보고서 이름 | 관리 API에서 사용할 이름 | 함수 | 설명 |
---|---|---|---|
초당 평균 트랜잭션 수 | tps | 없음 |
초당 API 프록시 요청을 의미하는 평균 트랜잭션 수입니다. 특정 기간 동안 상대적으로 낮은 트랜잭션 수를 가지고 있다면 초당 평균 트랜잭션 수는 숫자가 소수점 두 자리보다 작다면 UI 맞춤 보고서에서 0으로 나타납니다. API 구문: |
캐시에 있음 | cache_hit | 합계 |
타겟 서비스의 응답 대신 응답 캐시를 사용하는 성공적인 API 요청 수입니다. API 구문: |
L1 캐시 요소 수 | ax_cache_l1_count | avg, min, max |
일정 기간 동안 트랜잭션당 L1(메모리 내) 캐시의 요소 수를 반환합니다. 예를 들어 하루의 특정 기간 동안 API 구문: |
정책 오류 | policy_error | 합계 |
지정된 기간 동안의 총 정책 오류 수입니다. 정책 오류는 일반적으로 설계에 따라 발생하는 계획적인 오류입니다. 예를 들어 잘못된 API 키가 요청에 전달되면 API 키 인증 정책에서 오류가 발생하며, API 호출 수가 정책에 정의된 한도를 초과하면 Spike Arrest 정책에서 오류가 발생합니다. 따라서 이 측정항목은 API에서 잠재적인 문제가 있는 부분을 찾을 때 유용합니다. 예를 들어 developer_app 측정기준별로 그룹화된 policy_error 측정항목은 특정 앱에서 API 키 또는 OAuth 토큰이 만료되었는지 확인하는 데 도움이 될 수 있습니다. 또는 특정 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에 도달할 때 시작되고 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 |
Edge가 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 | sum, avg, min, max |
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 토큰을 확인하도록 구성해야 합니다. 개발자 앱은 앱이 Edge에 등록될 때 OAuth 토큰을 생성하는 데 사용할 수 있는 API 키를 가져옵니다. 자세한 내용은 먼저 할 일: 완전한 분석 데이터를 생성하는 방법을 참고하세요. 위의 기준이 충족되지 않으면 '(not set)' 값이 표시됩니다. 분석 항목 값 '(not set)'의 의미도 참조하세요. |
개발자 앱 | developer_app |
API를 호출하는 Edge 등록 개발자 앱입니다. 이 측정기준을 가져오려면 앱이 호출되는 API 프록시를 포함하는 하나 이상의 API 제품과 연결되어야 하며, 프록시는 API 호출과 함께 전송되는 API 키 또는 OAuth 토큰을 확인해야 합니다. 키 또는 토큰은 개발자 앱을 식별합니다. 자세한 내용은 먼저 할 일: 완전한 분석 데이터를 생성하는 방법을 참조하세요. 위의 기준이 충족되지 않으면 '(not set)' 값이 표시됩니다. 분석 항목 값 '(not set)'의 의미도 참조하세요. |
개발자 이메일 | developer_email |
앱에서 API를 호출한 Edge 등록 개발자의 이메일입니다. 이 측정기준을 가져오려면 개발자는 호출되는 API 프록시를 포함하는 하나 이상의 API 제품과 연결된 앱을 가지고 있어야 하며, 프록시는 API 호출과 함께 전송되는 API 키 또는 OAuth 토큰을 확인해야 합니다. 키 또는 토큰은 개발자 앱을 식별합니다. 자세한 내용은 먼저 할 일: 완전한 분석 데이터를 생성하는 방법을 참조하세요. 위의 기준이 충족되지 않으면 '(not set)' 값이 표시됩니다. 분석 항목 값 '(not set)'의 의미도 참조하세요. |
개발자 ID | 개발자 |
Edge에서 생성된 고유한 개발자 ID로, org_name@@@unique_id 형식입니다. 이 측정기준을 가져오려면 개발자는 호출되는 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 호출 실패를 야기한 정책의 이름입니다. 관리 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번째 버전은 현재 배포될 수 있습니다. 또한 UI에서 프록시 배포에 설명된 대로 버전의 기본 경로가 다르면 API에 여러 버전이 배포될 수 있습니다. |
확인된 클라이언트 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)라는 2개의 가상 호스트가 있습니다. |
인바운드/클라이언트 | ||
클라이언트 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 헤더
|
요청 경로 | 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 |
사용자 에이전트의 버전입니다. 이를 사용자 에이전트 제품군(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 |
|
시간 | ||
요일 | ax_day_of_week | API 호출이 수행된 요일의 세 글자 약어입니다. 예시: Mon, Tue, Wed |
월 | ax_month_of_year | API 호출이 수행된 월(숫자)입니다. 예를 들어 3월의 경우 '03'입니다. |
시간 | 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)입니다. |
수익 창출 | ||
Mint 거래 무시 메시지 | x_apigee_mint_tx_ignoreMessage | 수익 창출과 관련된 메시지를 무시할지 지정하는 플래그입니다. 모든 수익 창출 조직에 대해 false 로 설정합니다. |
Mint 거래 상태 | 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이고 타겟 응답 코드가 404인 API 호출의 측정항목을 반환합니다.
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' 논리를 사용하여 가능한 여러 필터 표현식을 평가할 수 있습니다. 필터에는 조건 중 하나 이상을 충족하는 데이터가 포함됩니다. |