PostgreSQL 날짜&시간 사용하기

www.postgresql.org/docs/8.4/functions-datetime.html

www.postgresql.org/docs/8.4/functions-formatting.html

해당 날짜의 데이터 

select count(watt_max) from tbl_test_watt3_sm2ch_min
where to_char(regdate, 'YYYY-MM-DD') = '2016-10-17'

소요시간 : 124초  (150만건)  (하루: 20*60*60*24 = 1,728,000)   이렇게 하면 망함!

해당 날짜의 데이터 

select count(watt) from tbl_test_watt_lsh where 

regdate >= date '2016-10-17'

and regdate < date '2016-10-17' + integer '1'   // 여기선 하루 

소요시간 : 634ms  (150만건)  (하루: 20*60*60*24 = 1,728,000)

해당 날짜의 데이터 

select count(watt) from tbl_test_watt_lsh where 

regdate >=  current_date 

and regdate < current_date + 1

소요시간 : 634ms  (150만건)  (하루: 20*60*60*24 = 1,728,000)

해당 시간의 데이터 

select count(watt) from tbl_test_watt_lsh where regdate

between  to_timestamp('2016-10-17 07:40:00' , 'YYYY-MM-DD HH24:MI:SS')  and   to_timestamp('2016-10-17 07:43:00', 'YYYY-MM-DD HH24:MI:SS')

소요시간 : 14ms  (3600건)  (하루: 20*60*60*24 = 1,728,000)

select count(watt) from tbl_test_watt_lsh where regdate

between  to_timestamp('2016-10-17 07:40:00' , 'YYYY-MM-DD HH24:MI:SS')  and   to_timestamp('2016-10-17 07:43:00', 'YYYY-MM-DD HH24:MI:SS') + interval '1'    // 여기선 1초 

소요시간 : 14ms  (3620건)

select count(watt) from tbl_test_watt_lsh where regdate

between  to_timestamp('2016-10-17 07:40:00' , 'YYYY-MM-DD HH24:MI:SS')  and   to_timestamp('2016-10-17 07:43:00', 'YYYY-MM-DD HH24:MI:SS') + interval '1' HOUR   // 여기선 1 시간  

소요시간 : 23ms  (63340건)

select count(watt) from tbl_test_watt_lsh where regdate

between  to_timestamp('2016-10-17 00:00:00' , 'YYYY-MM-DD HH24:MI:SS')  and   to_timestamp('2016-10-17 00:00:00', 'YYYY-MM-DD HH24:MI:SS') + '1-1 00:00:00' // 여기선 하루 , 인터벌 값을 이렇게 나타낼 수 있다 

'10-10' 는 10년 10개월 

소요시간 : 433ms  (1496720건)

select * from tbl_test_watt_lsh where to_char(regdate , 'YYYY-MM-DD HH24;MI:SS') > '2016-10-17 07:40:00' AND  to_char(regdate , 'YYYY-MM-DD HH24;MI:SS') < '2016-10-17 07:43:00'

역시 to_char 사용하면 망함!

-- 오늘 (date)
select current_date;
 
-- 현재시각 (timestamp)
select now();
select current_timestamp;
 
-- 어제/오늘/내일
select
  current_date - 1 "어제",
  current_date     "오늘",
  current_date + 1 "내일"
;
 
-- day of week
select extract(dow from current_date);    -- 일요일(0) ~ 토요일(6)
select extract(isodow from current_date); -- 월요일(1) ~ 일요일(7)
 
-- day of year
select extract(doy from current_date);
 
-- week of year
select extract(week from current_date);
 
-- 두 날짜 사이의 날수
select '2010-07-05'::date - '2010-06-25'::date;
 

■ 마이그레이션 : SQL Server → PostgreSQL

▶ 데이터 타입

▶ 함수

------------------------------------------------------------------------------------------------------------------------

출처: https://icodebroker.tistory.com/6429 [ICODEBROKER]

PostgreSQL의 프로세스 구조

클라이언트는 인터페이스 라이브러리(libpg, JDBC, ODBC 등의 다양한 인터페이스)를 통해 서버와의 연결을 요청(1)하면, Postmaster 프로세스가 서버와의 연결을 중계(2)한다. 이후 클라이언트는 할당된 서버와의 연결을 통해 질의를 수행(3)한다(그림 5).

서버 내부의 질의 수행 과정을 간단히 살펴보면 다음과 같다.

*** 한눈에 살펴보는 PostgreSQL : d2.naver.com/helloworld/227936

쿠팡 데이터 플랫폼의 진화

medium.com/coupang-tech/%EC%BF%A0%ED%8C%A1-%EB%8D%B0%EC%9D%B4%ED%84%B0-%ED%94%8C%EB%9E%AB%ED%8F%BC%EC%9D%98-%EC%A7%84%ED%99%94-26c827c1ec09

Phase IV — 서비스형 빅데이터, 클라우드 스토리지를 사용하는 EDW, 완전히 새로운 데이터 수집 프레임워크 (2018~2019)

2019년에 이르자 데이터 플랫폼에 대한 이해가 깊어지고 규모가 확대되어 다양한 비즈니스 사용 케이스 및 시나리오에 확장할 수 있게 진화됐습니다. 진화된 데이터 플랫폼이 지원하는 몇 가지 흥미로운 사례를 설명하겠습니다.

빅데이터 플랫폼 : 빅데이터팀은 그동안 여러 종류의 롱 러닝 하둡 클러스터를 운영해 왔지만, 폭발적인 사업 성장을 뒷받침하기 위해 클러스터 관리 정책 및 배포 전략을 대폭 수정해야만 했습니다. 고객을 위해서 더욱 안정적이고 확장 가능한 플랫폼을 제공할 수 있도록 머신 이미지를 미리 빌드했으며, 컴퓨팅 리소스 특성에 맞춘 다양한 최적화, 유연한 스케일링 정책, 클러스터 추상화 레이어 추가 등 다양한 분야를 개선했습니다.

• 클러스터 라이프사이클 : 고객의 워크로드를 기반으로 다양한 라이프 사이클을 지원하는 하둡 클러스터를 제공합니다. 각 클러스터의 라이프 사이클은 비용 효율 및 비즈니스 작업량에 따라 엄격히 관리됩니다. 이러한 클러스터는 공용 하이브 메타 스토어와 클라우드 저장소에 접근하기 때문에, 모든 고객은 동일한 하이브 테이블을 일관성 있게 사용할 수 있습니다.
• 스케일링 정책: 대부분의 클라우드 플랫폼에서는 시스템 지표에 따라 오토 스케일링 (Auto-scaling)을 처리합니다. 빅데이터팀도 처음에는 클라우드 서비스에서 제공하는 오토 스케일링을 사용했지만, 실제 고객의 필요를 충족시키기엔 부족했습니다. 그래서 트래픽이 집중되는 시간대를 분석한 후 해당 시간에 앞서 미리 확장할 수 있도록 해주는 스케줄 기반의 스케일링 기능을 적용했습니다. 스케줄 기반의 스케일링 기능과 오토 스케일링 기능을 조합하여 사용한 덕분에 고객의 플랫폼 경험이 크게 개선됐습니다.
• 머신 이미지 사전 빌드: 하둡 클러스터용 컴퓨팅 서버에는 OS를 포함한 다양한 소프트웨어와 하둡 에코시스템, 모니터링과 보안 에이전트가 설치됩니다. 빅데이터팀은 이러한 소프트웨어와 다양한 플러그인을 탑재한 서버 이미지를 미리 빌드합니다. 고객의 워크로드에 따라서 다양한 머신 이미지를 제공하며, 머신 이미지는 오픈소스Packer로 관리 합니다. 참고로 머신 이미지를 도입한 후, 하둡 클러스터 설치 시간이 60% 이상 단축됐습니다.

웹 로깅 플랫폼 : 쿠팡 초기 고객의 상호작용 데이터를 수집하는 플랫폼은 외부 솔루션을 기반으로 구축되었으나, 이 플랫폼에는 결함도 많고 기능도 부족했습니다. 그래서 많은 도메인 팀에서 메트릭을 집계하고 시각화하기 위해 또 다른 외부 서비스를 이용해야 했습니다. 이러한 문제를 근본부터 해결하기 위해 새로운 프레임워크를 구축했습니다. 장기간에 걸쳐 마이그레이션과 데이터 검증이 이뤄진 후, 신규 로깅 플랫폼이 레거시 로깅 플랫폼을 완전히 대체했습니다.

여기서 잠시, 로그의 여정에 대해 간략히 살펴보겠습니다. 시작하기에 앞서, 프로듀서가 메타데이터 서비스에 스키마를 등록합니다. 사람이 만들어내는 오류를 방지하기 위해 대개 스키마로부터 (정적 타이핑) 코드를 생성한 이후 해당 코드를 앱 또는 웹페이지에 넣어 줍니다. 앱이 릴리즈된 후, 클라이언트는 실제 로그를 생산하여 수집 파이프라인에 보냅니다. 수집 서버는 파이프라인 상에서 모든 로그를 받아 메시지를 생산한 후 메시지 큐로 보내고, 컨슈머가 작성한 다운스트림 잡을 위해 데이터 로더가 메시지들을 읽어들여 클라우드 저장소에 저장합니다. 이 데이터의 첫 컨슈머인 세션 배치 잡은 세션 구분 및 속성들이 추가된 세션 데이터 테이블을 생성하여 일반적인 배치 컨슈머들을 위한 표준 데이터를 제공합니다.

• 수집 파이프라인(수집 서버, 메시지 큐 및 데이터 로더): 쿠팡 플랫폼 서비스 팀에서 관리하는 메시지 큐 서비스를 이용, 실시간 컨슈머를 위한 실시간 데이터 스트림 및 배치 컨슈머를 위한 준 실시간 데이터를 손실, 중복 및 오염 없이 제공합니다. 컨슈머들은 또한 메시지 큐에 직접 접근하여 자체 SLA 및 ETL 로직을 구현한 로더를 직접 작성할 수도 있습니다. 배치 파이프라인은 실시간 파이프라인으로 적재된 로그 데이터를 이용하여 구현합니다.
• 메타데이터 서비스: 모든 로그 데이터에 스키마가 등록되어 있어야 하며 스키마 변경을 검토하고 알림을 받을 오너 및 컨슈머 정보가 있어야 합니다. 로그 데이터 구조에서 이 단일 데이터 소스(single source of truth)는 다른 서비스, 프로듀서의 UI 코드 및 컨슈머 쿼리의 근간이 됩니다.
• 로그 검증 서비스: 플랫폼상의 데이터 전송을 방해하지 않으면서 메타데이터 서비스에 있는 스키마를 토대로 파이프라인상의 모든 로그를 확인합니다. 모든 결과는 저장되고 해당 로그의 프로듀서 및 컨슈머에게 주기적으로 리포팅 되며 실시간으로 알림이 발송됩니다.
• 모니터링 및 테스팅 서비스 : QA 테스팅 및 프로덕션을 위해 실시간으로 모든 지정된 사용자나 디바이스의 로그를 추적 및 검증하기 위한 서비스가 제공되며, 사용자들은 구문 뿐만 아니라 의미까지 확인하기 위한 시나리오 기반 검증 기능을 사용할 수 있습니다.

엔터프라이즈 데이터웨어하우스(EDW): 데이터 플랫폼의 주요 데이터 웨어하우스 환경은 ORC 파일이며 하이브/휴(Hive/Hue), 프레스토/제플린(Presto/Zeppelin)을 통해 접속할 수 있습니다. 여전히 EDW 고객에게 MPP 기반의 샌드박스가 제공되지만 이는 EDW의 일부분에 불과합니다. 주요 기능은 고객이 프로덕션에 앞서 샌드박스 테이블을 빌드 하고 이를 통해 도메인 비즈니스를 관리할 수 있는 환경을 제공하는 것입니다. 더불어 고객의 샌드박스 테이블이 리포팅에 필요할 경우, 이 환경에서 단기적인 리포팅을 할 수 있다. 다만 장기간 리포팅을 하거나 공유해야 할 경우, 사용자가 관리하는 테이블을 클라우드 스토리지 기반의 테이블로 이관할 것을 권장합니다.

서브 컴포넌트

이번에는 쿠팡의 데이터 플랫폼에 포함된 다른 주요 기능에 대해서 소개하겠습니다.

데이터 품질

데이터 팀은 데이터 정확성 보장을 위해 열(row)의 HASH를 사용하여 전체 열 데이터와 열의 개수를 비교해주는 프레임워크를 구축했습니다. 기술적 테스팅의 일환으로, 프라이머리 키(primary key)와 빈 값(null value) 등의 DQ 체크도 실행합니다. 해당 프레임워크는 개발자의 비즈니스 관련 SQL 구문 플러그인을 지원할 뿐 아니라, 실제와 동일한 데이터 정확성도 제공합니다. 특히 빅데이터 테이블의 경우에는 제약사항 처리 및 임계치 기반의 데이터 확인을 위해 오픈소스 프레임워크도 활용하고 있습니다.

데이터 이상 알림 서비스

기술이 급변하는 추세에 발맞춰 우리도 빠르게 움직여야 했습니다. 데이터 알림 서비스 (Data Notifier)는 데이터 입력된 직후 가능한 최단 시간 내 이상 현상을 감지하여 알려 줍니다. 예를 들어, 지난달 신규 버전 안드로이드 앱이 출시되었는데 로그 기록에 버그가 발생하여 데이터가 유실되었다고 가정합니다. 과거에는 이러한 이상 현상을 감지하려면 고객이 앱을 설치할 때까지 기다려야 했기 때문에 데이터 유실을 알아채기까지 3일이 걸렸습니다. 하지만 데이터 이상 알림 서비스를 통해 앱 릴리즈로부터 2시간 내로 이상 감지가 가능하게 됐습니다.

SLA (Service Level Agreement)

신규 데이터 플랫폼에서는 매일 한국 시간 오전 9시에 데이터 마트 테이블의 준비 완료 여부가 고객에게 이메일로 공지합니다. 추가로 데이터 SLA 투명성 제고를 위해 데이터 플랫폼 사용자들이 SLA에 관한 정보를 쉽게 읽을 수 있도록, 가독성 높은 온라인 보고서도 개발 중에 있습니다.

데이터 디스커버리 툴

데이터 플랫폼의 테이블/칼럼에 관한 태그 및 설명을 등록할 수 있는 플랫폼으로, 다른 고객이 이를 검색 및 조회할 수 있으며 유기적 성장이 가능한 오픈 플랫폼입니다. 데이터 디스커버리는 쿠팡의 모든 데이터 고객이 자체적으로 데이터 발견(discovery)을 할 수 있도록 해주었고, 해당 기능을 통해 데이터를 찾는 수백 명의 사용자는 한층 편리해진 데이터 라이프와 향상된 생산성을 누릴 수 있게 됐습니다.

EDW 관리 시스템 (EMS)

데이터 파이프라인의 생성 및 관리, 데이터 수집 자동화 그리고 메타데이터를 사용한 자동화된 Airflow DAG 생성을 지원하는 프레임워크입니다. 이 프레임워크는 데이터 엔지니어가 필요한 모니터링, 재적재(backfill) , 다운스트림 디펜던시 기능을 지원합니다. 또한, EMS는 온콜 엔지니어를 위해 초기 SLA 감지 기능도 제공합니다.

Split 유형의 함수로 구분자로 몇번째 위치의 문자열 가져오기 

-----------------------------------------------------------------------------------------------------------  
--  Split 유형의 함수  
--  문자열에서 구분자(@iSeparator)로 몇번째 단어 가져오기  
--  예: SELECT 데이터베이스명.소유자명.fn_GetIdxDataLikeSplit('가-나-다',2,'-') --> '나'  
-----------------------------------------------------------------------------------------------------------  
-----------------------------------------------------------------------------------------------------------  
-- 프로시저 생성  
-----------------------------------------------------------------------------------------------------------  
ALTER   FUNCTION  [dbo].[fn_GetIdxDataLikeSplit]   
    (  
        @iText          VARCHAR(200),  
        @idx                INT,  
        @iSeparator     VARCHAR(10) = '-'  
    )  
RETURNS  VARCHAR(200)   
AS  
BEGIN  
    DECLARE @wData          VARCHAR(200)  
    DECLARE @wText          VARCHAR(200)  
    DECLARE @wSeparator VARCHAR(10)  
    DECLARE @wNum           INT  
  
    SET @wData          = ''  
    SET @wNum           = 1;  
    SET @wSeparator = LTRIM(RTRIM(@iSeparator));  
    SET @wText          = LTRIM(RTRIM(@iText)) + @wSeparator;   
  
    IF CHARINDEX(@wSeparator, @iText) > 0  
    BEGIN  
        WHILE    @idx >= @wNum  
        BEGIN  
            IF CHARINDEX(@wSeparator, @wText) > 0  
            BEGIN  
                   -- 문자열의 인덱스 위치의 요소를 반환  
                   SET @wData   = SUBSTRING(@wText, 1, CHARINDEX(@wSeparator, @wText) - 1);  
                   SET @wData   = LTRIM(RTRIM(@wData));  
  
                -- 반환된 문자는 버린후 좌우공백 제거     
                    SET @wText  = LTRIM(RTRIM(RIGHT(@wText, LEN(@wText) - (LEN(@wData) + LEN(@iSeparator)))))  
            END   
            ELSE  
            BEGIN  
                    SET @wData  = ''  
            END  
            SET @wNum = @wNum + 1  
        END  
    END  
    ELSE  
    BEGIN  
        SET @wData  = @iText  
    END  
      
      
    RETURN(@wData)  
      
END  

 

DB Browser for SQLite

sqlitebrowser.org/

MSSQL - JSON 데이터 인덱싱

https://docs.microsoft.com/ko-kr/sql/relational-databases/json/index-json-data?view=sql-server-ver15

SQL Server 및 SQL Database에서 JSON은 기본 제공 데이터 형식이 아니며 SQL Server에는 사용자 지정 JSON 인덱스가 없습니다. 그러나 표준 인덱스를 사용하여 JSON 문서에 대한 쿼리를 최적화할 수 있습니다.

데이터베이스 인덱스는 필터 및 정렬 작업의 성능을 향상합니다. 인덱스를 사용하지 않으면 SQL Server는 데이터를 쿼리할 때마다 전체 테이블을 검색해야 합니다.

계산된 열을 사용하여 JSON 속성 인덱싱

SQL Server에 JSON 데이터를 저장하는 경우 JSON 문서 속성 하나 이상을 기준으로 쿼리 결과를 필터링하거나 정렬하는 것이 일반적입니다.

예제

이 예제에서는 AdventureWorks SalesOrderHeader 테이블에 판매 주문에 대한 다양한 정보가 JSON 형식으로 포함되어 있는 Info 열이 있다고 가정합니다. 예를 들어 이 열은 고객, 영업 사원, 배송 및 대금 청구 주소 등에 대한 정보를 포함합니다. Info 열의 값을 사용하여 고객의 판매 주문을 필터링하려고 합니다.

최적화할 쿼리

다음은 인덱스를 사용하여 최적화할 쿼리 형식의 예제입니다.

SQL복사

SELECT SalesOrderNumber, OrderDate, JSON_VALUE(Info, '$.Customer.Name') AS CustomerName FROM Sales.SalesOrderHeader WHERE JSON_VALUE(Info, '$.Customer.Name') = N'Aaron Campbell'

예제 인덱스

JSON 문서에서 속성에 대한 ORDER BY 절 또는 필터링의 속도를 향상하려면 다른 열에서 이미 사용 중인 동일한 인덱스를 사용할 수 있습니다. 그러나 JSON 문서에서는 속성을 직접 참조할 수 없습니다.

1. 먼저 필터링에 사용할 값을 반환하는 “가상 열”을 만들어야 합니다.
2. 그런 다음 해당 가상 열에 인덱스를 만들어야 합니다.

다음 예제에서는 인덱싱에 사용할 수 있는 계산 열을 만듭니다. 그런 다음 새 계산 열에서 인덱스를 만듭니다. 이 예제에서는 JSON 데이터의 $.Customer.Name 경로에 저장된 고객 이름을 표시하는 열을 만듭니다.

SQL복사

ALTER TABLE Sales.SalesOrderHeader ADD vCustomerName AS JSON_VALUE(Info,'$.Customer.Name') CREATE INDEX idx_soh_json_CustomerName ON Sales.SalesOrderHeader(vCustomerName)

계산 열에 대한 자세한 정보

계산 열은 지속형이 아닙니다. 인덱스를 다시 작성해야 하는 경우에만 계산됩니다. 테이블에서 추가 공간을 차지하지 않습니다.

쿼리에서 사용할 동일한 식으로 계산 열을 만드는 것이 중요합니다. 이 예제의 식은 JSON_VALUE(Info, '$.Customer.Name')입니다.

쿼리를 다시 작성할 필요가 없습니다. 위 예제 쿼리와 같이 JSON_VALUE 함수가 포함된 식을 사용하는 경우 SQL Server는 같은 식을 사용하는 동일한 계산 열이 있는지 확인한 후 해당하는 경우 인덱스를 적용합니다.

이 예제에 대한 실행 계획

다음은 이 예제의 쿼리 실행 계획입니다.

SQL Server는 전체 테이블을 검색하지 않고 비클러스터형 인덱스에서 인덱스 검색하여 지정된 조건을 충족하는 행을 찾습니다. 그런 다음 SalesOrderHeader 테이블에서 키 조회를 사용하여 쿼리에서 참조된 다른 열(이 예제에서는 SalesOrderNumber 및 OrderDate)을 가져옵니다.

포괄 열을 사용하여 추가로 인덱스 최적화

인덱스에 필요한 열을 추가하는 경우 테이블에서 이러한 조회를 추가로 수행할 필요가 없습니다. 위의 CREATE INDEX 예제를 확장하는 다음 예제처럼 이러한 열을 표준형 포괄 열로 추가할 수 있습니다.

SQL복사

CREATE INDEX idx_soh_json_CustomerName ON Sales.SalesOrderHeader(vCustomerName) INCLUDE(SalesOrderNumber,OrderDate)

이 경우 비클러스터형 JSON 인덱스에 필요한 모든 사항이 있기 때문에 SQL Server는 SalesOrderHeader 테이블에서 데이터를 추가로 읽을 필요가 없습니다. 이러한 인덱스 유형은 쿼리에서 JSON과 열 데이터를 결합하고 작업에 대한 최적의 인덱스를 생성하기 위한 좋은 방법입니다.

JSON 인덱스는 데이터 정렬 인식 인덱스입니다.

JSON 데이터에 대한 중요한 인덱스 기능은 인덱스의 데이터 정렬 인식 기능입니다. 계산 열을 만들 때 사용하는 JSON_VALUE 함수의 결과는 입력 식에서 데이터 정렬을 상속하는 텍스트 값입니다. 따라서 인덱스의 값은 원본 열에 정의된 데이터 정렬 규칙을 사용하여 정렬됩니다.

인덱스가 데이터 정렬을 인식한다는 것을 보여주기 위해 다음 예제에서는 기본 키와 JSON 콘텐츠가 있는 단순한 컬렉션 테이블을 만듭니다.

SQL복사

CREATE TABLE JsonCollection ( id INT IDENTITY CONSTRAINT PK_JSON_ID PRIMARY KEY, json NVARCHAR(MAX) COLLATE SERBIAN_CYRILLIC_100_CI_AI CONSTRAINT [Content should be formatted as JSON] CHECK(ISJSON(json)>0) )

이전 명령은 JSON 열에 대하여 세르비아어 키릴 자모 데이터 정렬을 지정합니다. 다음 예제에서는 테이블을 자동으로 채우고 이름 속성에 대한 인덱스를 만듭니다.

SQL복사

INSERT INTO JsonCollection VALUES (N'{"name":"Иво","surname":"Андрић"}'), (N'{"name":"Андрија","surname":"Герић"}'), (N'{"name":"Владе","surname":"Дивац"}'), (N'{"name":"Новак","surname":"Ђоковић"}'), (N'{"name":"Предраг","surname":"Стојаковић"}'), (N'{"name":"Михајло","surname":"Пупин"}'), (N'{"name":"Борислав","surname":"Станковић"}'), (N'{"name":"Владимир","surname":"Грбић"}'), (N'{"name":"Жарко","surname":"Паспаљ"}'), (N'{"name":"Дејан","surname":"Бодирога"}'), (N'{"name":"Ђорђе","surname":"Вајферт"}'), (N'{"name":"Горан","surname":"Бреговић"}'), (N'{"name":"Милутин","surname":"Миланковић"}'), (N'{"name":"Никола","surname":"Тесла"}') GO ALTER TABLE JsonCollection ADD vName AS JSON_VALUE(json,'$.name') CREATE INDEX idx_name ON JsonCollection(vName)

앞의 명령은 JSON $.name 속성의 값을 나타내는 계산 열 vName에 표준 인덱스를 만듭니다. 세르비아어-키릴 자모 코드 페이지에서 문자 순서는 'А', 'Б', 'В', 'Г', 'Д', 'Ђ', 'Е' 등의 순서입니다. JSON_VALUE 함수의 결과는 원본 열에서 데이터 정렬을 상속하므로 인덱스에서 항목의 순서는 세르비아어 키릴 자모 규칙을 따릅니다. 다음 예제에서는 이 컬렉션을 쿼리하고 이름을 기준으로 결과를 정렬합니다.

SQL복사

SELECT JSON_VALUE(json,'$.name'),* FROM JsonCollection ORDER BY JSON_VALUE(json,'$.name')

실제 실행 계획을 보면 비클러스터형 인덱스에서 정렬된 값을 사용함을 확인할 수 있습니다.

쿼리에 ORDER BY 절이 있지만 실행 계획은 Sort 연산자를 사용하지 않습니다. JSON 인덱스는 이미 세르비아어 키릴 자모 규칙에 따라 정렬됩니다. 따라서 SQL Server는 결과가 이미 정렬된 비클러스터형 인덱스를 사용합니다.

그러나 ORDER BY 식의 데이터 정렬을 변경하면(예: JSON_VALUE 함수 뒤에 COLLATE French_100_CI_AS_SC 추가) 다른 쿼리 실행 계획이 제공됩니다.

인덱스 값 순서는 프랑스어 데이터 정렬 규칙을 따르지 않으므로 SQL Server는 정렬 결과에 대한 인덱스를 사용할 수 없습니다. 따라서 프랑스어 데이터 정렬 규칙을 사용하여 결과를 정렬하는 정렬 연산자를 추가합니다.