이번 주 힌트와 테크닉 블로그에 오신 것을 환영합니다. 여기서 PostgreSQL과 Oracle DBA의 초급과 고급 YugabyteDB 주제를 탐색합니다.우선 분산 SQL이나 YugabyteDB에 익숙하지 않을 수 있는 분들은 계속 읽어 주십시오.

분산 SQL이란 무엇입니까?

분포식 SQL 데이터베이스는 데이터 인프라를 클라우드나 클라우드 네이티브 환경으로 이동하려는 조직에서 점점 유행하고 있다.이는 일반적으로 Oracle, MySQL 및 SQL Server와 같은 단일 관계형 데이터베이스에서 TCO를 절감하거나 확장을 제한하려는 의도에서 비롯됩니다.분산 SQL의 기본 특징은 다음과 같습니다.

은 데이터를 조회하고 모델링하는 데 사용되는 SQL API로 기본 키, 외부 키, 인덱스, 저장 프로세스와 트리거 등 전통적인 RDBMS 기능을 지원합니다.

자동 분포식 조회가 실행되기 때문에 단일 노드가 병목이 되지 않습니다.

분산 SQL 데이터베이스는 자동 분산 데이터 저장소를 지원해야 합니다.이것은 하나의 노드가 고성능과 고가용성을 확보하는 병목이 되지 않도록 집단의 여러 노드에 자동으로 분포해야 하는 인덱스를 포함한다.

분포식 SQL 시스템은 고도로 일치하는 복제와 분포식 ACID 사무를 제공해야 한다.
분산 SQL에 대한 자세한 내용은 "분산 SQL이란?"을 참조하십시오.

Yugabyte DB가 뭐예요?

YugabyteDB은 오픈소스, 고성능의 분포식 SQL 데이터베이스로 구글 스패너의 계발을 바탕으로 확장과 용량 오류 설계를 구축한다.YugabyteDB는 PostgreSQL wire와 호환되며 저장 프로세스, 트리거, UDF 등 고급 RDBMS 기능을 지원합니다.
문제가 있습니까?저희 YugabyteDB Slack channel에서 꼭 물어보세요.본고의 대다수 예시는 Northwind 예시 데이터베이스를 사용하고 있음을 주의하십시오.그것을 어떻게 설치하는지에 대한 설명은 here입니다.
좋아, 잠입하자..

PostgreSQL 또는 YugabyteDB에는 Oracle의 NVL과 같은 기능이 있습니까?

요컨대, Oracle의 NVL은 NULL을 대체할 수 있으며, 검색 결과에 빈 문자열을 되돌려줍니다.예를 들어, NULL 열에 region이 있는 고객의 경우 "해당되지 않음"으로 바꾸십시오.

SELECT company_name, country, NVL(region, 'Not Applicable')
FROM customers
ORDER BY country;

PostgreSQL과 YugabyteDB에서 유사한 결과를 얻기 위해 COALESCE 함수를 사용할 수 있습니다.우선, 이것은 customers 표의 일부 출력이다.아르헨티나, 오스트리아, 벨기에는 지역열에 NULL개가 있음을 주의하십시오.
COALESCE 함수를 사용하면 교환할 수 있습니다.

SELECT company_name, country, COALESCE (region, 'Not Applicable')
FROM customers 
ORDER BY country;

YugabyteDB는 PostgreSQL의 보기, 물체 보기 및 요약을 지원합니까?

VIEW과 ROLLUP을 지원하며 현재 물화시도 지원을 개발하고 있습니다.너는 이 GitHub issue으로 그것의 발전을 추적할 수 있다.
PostgreSQL의 보기는 가상 테이블로 간주될 수 있으며, 한 개 이상의 조회 가능한 테이블에서 나온 데이터를 일반 테이블처럼 한데 모을 수 있다.다른 한편, 물화 보기는'가상적'이 아니기 때문에 우리는 방문할 때마다 보기를 다시 계산할 필요가 없다.이로 인해 물화 보기의 조회 효율이 더욱 높고 추가 저장이 필요하며 보기의 기본 테이블이 업데이트될 때 물화 보기도 업데이트를 유지해야 한다.
마지막으로 PostgreSQL의 ROLLUP은 GROUP BY의 하위 클래스로 여러 개의 그룹 집합을 정의할 수 있습니다.이것은 분석 용례에서 특히 유용합니다. 이 용례에서 "요약"날짜, 화폐 값 또는 다른 유형의 데이터를 원할 수도 있습니다. 그 중 일부 계산은 유용할 수 있습니다.모든 예시를 훑어봅시다.
YugabyteDB에서 VIEW을 만드는 것은 PostgreSQL에서 만드는 것과 같습니다.이 예에서 우리는 VIEW과 customers 표에 orders을 만들었다.이런 상황에서 VIEW은 매우 유용하다. 비록 customer_id과 orders표에 모두 customers열이 존재하지만 company_name표는 orders표에 존재하지 않기 때문이다.우리는 그것을 한 번에 주문 디테일과 customer_name을 얻을 수 있도록 매우 간단하게 하고 싶다.

CREATE VIEW orders_by_company_name AS
SELECT orders.order_id, orders.order_date, customers.company_name, orders.ship_country
FROM orders, customers 
WHERE orders.customer_id = customers.customer_id;

현재 우리가 필요로 하는 데이터를 검색하기 위해 간단한 SELECT문장을 보냅니다.

SELECT * FROM orders_by_company_name;

YugabyteDB에서 ROLLUP을 만드는 것은 PostgreSQL에서 만드는 것과 같습니다.예를 들어 orders표의 데이터를 요약하여 customer_id(주문한 사람), employee_id(주문한 사람), 발송한 운임 총액에 따라 그룹을 나누도록 한다.

SELECT
customer_id,    
COALESCE(employee_id, '0') as employee_id,
    SUM (freight) as "Rollup Sum of Freight by Customer and Employee"
FROM
    orders
GROUP BY
    ROLLUP (customer_id, employee_id)
ORDER BY customer_id, employee_id;

위의 수출에서 알 수 있듯이 결과집은 운임을 합치면 customer_id과 employee_id이다.

YugabyteDB는 해석 분석을 지원합니까?

맞다PostgreSQL의 EXPLAIN은 데이터베이스에 대한 조회의 잠재적인 성능 조정 기회를 확인하는 데 유용한 도구입니다.ANALYZE 옵션을 추가하면 계획 실행뿐만 아니라 문장이 실제로 실행됩니다.EXPLAIN ANALYZE 예시 데이터베이스에 있는 orders 표를 대상으로 간단한 northwind을 발표합니다.이 예에서는 복제 인자가 3인 YugabyteDB 클러스터에 대한 질의를 수행합니다.

EXPLAIN ANALYZE SELECT customer_id, order_id, ship_country 
FROM orders 
WHERE order_date BETWEEN '1997-01-01' and '1999-12-31';

QUERY PLAN                                                                                                 
----------
Foreign Scan on orders
(cost=0.00..105.00 rows=1000 width=82) 
(actual time=4.865..27.046 rows=678 loops=1)

Filter: ((order_date >= '1997-01-01'::date) AND (order_date <= '1999-12-31'::date)

Rows Removed by Filter: 152                                                                             
Planning Time: 31.899 ms                                                                                  
Execution Time: 29.078 ms 

다음은 order_date열에 색인을 만들어서 조회 시간을 절약할 수 있는지 봅시다.

CREATE INDEX idx_order_date 
ON orders(order_date ASC);

우리는 같은 조회를 실행하고 다음과 같은 결과를 얻었다.

QUERY PLAN                                                                                                                 
----------
Index Scan using idx_order_date on orders  
(cost=0.00..5.25 rows=10 width=82) 
(actual time=10.350..11.607 rows=678 loops=1)

Index Cond: ((order_date >= '1997-01-01'::date) AND (order_date <= '1999-12-31'::date))                                  
Planning Time: 13.608 ms                                                                                                   Execution Time: 11.913 ms

보시다시피, order_date열에 색인을 만들면 계획 시간과 실행 시간을 개선할 수 있습니다.이 예 중의 삼각주는 결코 사람들의 주목을 끌지 못하지만, 너는 알았다.더욱 복잡한 조회와 더 큰 데이터 집합에 따라 EXPLAIN과 ANALYZE은 반드시 없어서는 안 될 성능 조정 도구가 되었다.