🚀 우선 메인 키와 인덱스를 고려합니다🐘

Nikolay Samokhvalov은 최근 데이터베이스 구조의 중요성을 이해하는 데 주의를 기울여 달라는 트윗을 올렸다.

니콜라 사모흐바로프--박사후 훌륭

이 선은 사람을 놀라게 한다.1100만 줄, 3초 동안 실행되는 테이블에 대한 간단한 검색을 최적화하는 1001가지 방법을 알고 있다. 클릭하우스로 이동하는 것부터 절분에 이르기까지 소수의 사람들만이 btree가 무엇인지, 그리고 그것이 어떻게 작동하는지 알고 있다.🤷🏻‍♂️ twitter.com/jlongster/stat…
2021년 11월 6일 오후 22:57
제임스 랑
존스터
PostgreSQL의 신축성 문제.맞아요!가장 좋은 문제!
지금 나는 어떻게 3초도 안 되는 시간 안에 11644420줄을 조회하는지 확실히 알아야 한다.
앤디 파블로는 사람들이 정확한 색인을 이해하지 못하는 상황에서 많은 근본적인 변화를 제기했다고 지적했다.

앤디 파블로
# 앤디 파블로

이 단서는 저자가 오토매틱 데이터베이스를 연구하는 동기다.James는 쿼리 옵션 문제가 있습니다. 적당한 인덱스만 필요하지만, 분포식이나 NosQL DBMS로 전환하고, MatView를 추가하고, 유형을 UUID로 변경하는 것을 권장합니다. H/T twitter.com/jlongster/stat…
2021년 11월 7일 오후 13:58
제임스 랑
존스터
PostgreSQL의 신축성 문제.맞아요!가장 좋은 문제!
지금 나는 어떻게 3초도 안 되는 시간 안에 11644420줄을 조회하는지 확실히 알아야 한다.
이 글에서 나는 이 예로 색인을 생각하는 것이 그리 어렵지 않을 것이라고 설명할 것이다.어쨌든, 이 작업은 분포식 데이터베이스로 확장되기 전에 끝내야 한다.이 문제는 PostgreSQL에서 만났습니다.분산 데이터베이스에서의 개념이 똑같다는 것을 보여주기 위해 YugabyteDB에서 제 프레젠테이션을 실행할 것입니다.SQL도 마찬가지다.
James Long 방법은 다음과 같습니다. 커뮤니티에 문의하여 필요한 모든 정보, 실행 계획 및 색인 정의를 제공합니다. https://gist.github.com/jlongster/4b31299dcb622aa7e29b59d889db2b2c#file-gistfile1-txt
이러한 정보가 있으면 문제가 재현되기 쉽다.

yugabyte=# \c yugabyte yugabyte

psql (15devel, server 11.2-YB-2.9.1.0-b0)
You are now connected to database "yugabyte" as user "yugabyte".

yugabyte=# create table messages_binary (
            "timestamp" text,
            "group_id" uuid,
            "other_column" int,
            primary key("timestamp","group_id")
           );
CREATE TABLE

yugabyte=# EXPLAIN SELECT * FROM messages_binary
           WHERE group_id = 'e7e46753-2e99-4ee4-b77f-17136b01790e'
           AND timestamp > '1970-01-01T00:00:00.000Z-0000-ae26b84edae7349e';
                                                                    QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------
------------------
 Seq Scan on messages_binary  (cost=0.00..105.00 rows=1000 width=52)
   Filter: (("timestamp" > '1970-01-01T00:00:00.000Z-0000-ae26b84edae7349e'::text) AND (group_id = '983d5259-97ff-49e3-8829-101a
b8dead92'::uuid))
(2 rows)

이것은 전체 테이블 스캔이다.이것은 우리가 원하는 것이 아닙니다. 왜냐하면 읽는 모든 줄에 '그룹 id' 가 필요하기 때문입니다.우리가 필요한 것은 범위 스캐닝이다.
몇 행(3 그룹 3 타임 스탬프)을 삽입합니다.

yugabyte=# create extension pgcrypto;
CREATE EXTENSION

yugabyte=# insert into messages_binary
           with groups as (
            select gen_random_uuid() group_id from generate_series(1,3)
           )
           select
            to_char(now()+(generate_series(1,3)*interval'1 second')
             ,'yyyy-mm-ddThh24:mi:ss.000Z-')
             ||substr(gen_random_uuid()::text,25) "timestamp"
            ,group_id, 42 as "value"
           from groups;
INSERT 0 9

yugabyte=# select * from messages_binary;

               timestamp               |               group_id               | other_column
--------------------------------------------+--------------------------------------+--------------
 2021-11-07T20:00:23.000Z-c533a5e5623e | e7e46753-2e99-4ee4-b77f-17136b01790e |           42
 2021-11-07T20:00:24.000Z-b879daca6cb7 | f27ac68f-2a10-46f0-a8fe-77b99c0c5a66 |           42
 2021-11-07T20:00:23.000Z-ca98dd4de397 | f27ac68f-2a10-46f0-a8fe-77b99c0c5a66 |           42
 2021-11-07T20:00:22.000Z-c440295c4500 | 9c3d61e1-6d3f-4b95-9e08-46f485d10b75 |           42
 2021-11-07T20:00:24.000Z-631b45e66aba | e7e46753-2e99-4ee4-b77f-17136b01790e |           42
 2021-11-07T20:00:22.000Z-ad01842bb691 | e7e46753-2e99-4ee4-b77f-17136b01790e |           42
 2021-11-07T20:00:24.000Z-90342717a0c8 | 9c3d61e1-6d3f-4b95-9e08-46f485d10b75 |           42
 2021-11-07T20:00:22.000Z-933f552d0159 | f27ac68f-2a10-46f0-a8fe-77b99c0c5a66 |           42
 2021-11-07T20:00:23.000Z-1dcde16fc472 | 9c3d61e1-6d3f-4b95-9e08-46f485d10b75 |           42
(9 rows)

YugabyteDB에서 줄은 분리되어 주 인덱스에 저장됩니다.PostgreSQL에서, 그것들은 하나의 무더기에 추가되고, 메인 키에 추가 인덱스가 있습니다.이 두 가지 상황에서 범위 스캔 접근은 메인 키에 달려 있으며, 여기는 ("timestamp","group_id")으로 정의됩니다.우리는 내가 필요로 하는 group_id = 'e7e46753-2e99-4ee4-b77f-17136b01790e줄이 이 Seq 스캔 결과에서 분산된 것을 볼 수 있다.
메인 키의 순서, 선택을 알아보자...같은 열을 순서대로 정렬하려면 다음과 같이 하십시오.

yugabyte=# select * from messages_binary
            order by "timestamp","group_id";

               timestamp               |               group_id               | other_column
--------------------------------------------+--------------------------------------+--------------
 2021-11-07T20:00:22.000Z-933f552d0159 | f27ac68f-2a10-46f0-a8fe-77b99c0c5a66 |           42
 2021-11-07T20:00:22.000Z-ad01842bb691 | e7e46753-2e99-4ee4-b77f-17136b01790e |           42
 2021-11-07T20:00:22.000Z-c440295c4500 | 9c3d61e1-6d3f-4b95-9e08-46f485d10b75 |           42
 2021-11-07T20:00:23.000Z-1dcde16fc472 | 9c3d61e1-6d3f-4b95-9e08-46f485d10b75 |           42
 2021-11-07T20:00:23.000Z-c533a5e5623e | e7e46753-2e99-4ee4-b77f-17136b01790e |           42
 2021-11-07T20:00:23.000Z-ca98dd4de397 | f27ac68f-2a10-46f0-a8fe-77b99c0c5a66 |           42
 2021-11-07T20:00:24.000Z-631b45e66aba | e7e46753-2e99-4ee4-b77f-17136b01790e |           42
 2021-11-07T20:00:24.000Z-90342717a0c8 | 9c3d61e1-6d3f-4b95-9e08-46f485d10b75 |           42
 2021-11-07T20:00:24.000Z-b879daca6cb7 | f27ac68f-2a10-46f0-a8fe-77b99c0c5a66 |           42
(9 rows)

현재, 당신은 WHERE group_id = 'e7e46753-2e99-4ee4-b77f-17136b01790e' AND timestamp > '1970-01-01T00:00:00.000Z-0000-ae26b84edae7349e' 술어를 사용하는 검색 효율이 얼마나 낮은지 이해할 수 있습니다.우리는 첫 줄부터 시작합니다. timestamp > '1970-01-01T00:00:00.000Z-0000-ae26b84edae7349e'을 검증했기 때문에 모든 줄을 스캔해서 필터해야 합니다.단독으로 읽을 수 있는 작은 범위 내에서 관심 있는 줄을 찾을 수 있는 데이터 구조는 없다.이것이 바로 Seq 스캔을 설명합니다.
먼저 그룹 id를 기준으로 정렬하는 구조가 필요합니다.

yugabyte=# select * from messages_binary
            order by "group_id","timestamp";

               timestamp               |               group_id               | other_column
--------------------------------------------+--------------------------------------+--------------
 2021-11-07T20:00:22.000Z-c440295c4500 | 9c3d61e1-6d3f-4b95-9e08-46f485d10b75 |           42
 2021-11-07T20:00:23.000Z-1dcde16fc472 | 9c3d61e1-6d3f-4b95-9e08-46f485d10b75 |           42
 2021-11-07T20:00:24.000Z-90342717a0c8 | 9c3d61e1-6d3f-4b95-9e08-46f485d10b75 |           42
 2021-11-07T20:00:22.000Z-ad01842bb691 | e7e46753-2e99-4ee4-b77f-17136b01790e |           42
 2021-11-07T20:00:23.000Z-c533a5e5623e | e7e46753-2e99-4ee4-b77f-17136b01790e |           42
 2021-11-07T20:00:24.000Z-631b45e66aba | e7e46753-2e99-4ee4-b77f-17136b01790e |           42
 2021-11-07T20:00:22.000Z-933f552d0159 | f27ac68f-2a10-46f0-a8fe-77b99c0c5a66 |           42
 2021-11-07T20:00:23.000Z-ca98dd4de397 | f27ac68f-2a10-46f0-a8fe-77b99c0c5a66 |           42
 2021-11-07T20:00:24.000Z-b879daca6cb7 | f27ac68f-2a10-46f0-a8fe-77b99c0c5a66 |           42
(9 rows)

데이터베이스 엔진은 이 구조(행 순서를 볼 때 열 순서를 변경하지 않음)에서 다음을 수행할 수 있습니다.
첫 번째 group_id='e7e46753-2e99-4ee4-b77f-17136b01790e'10 찾기

최초 timestamp > '1970-01-01T00:00:00.000Z-0000-ae26b84edae7349e',

추가

다음 줄을 순서대로 읽기,

, 마지막 group_id='e7e46753-2e99-4ee4-b77f-17136b01790e'에 멈췄다.

어떻게 이런 구조를 얻습니까?다른 색인 정의를 사용하기 쉽습니다.

yugabyte=# create index messages_binary_key2 
            on messages_binary ("group_id","timestamp");
CREATE INDEX

다음은 실행 계획입니다.

yugabyte=# EXPLAIN SELECT * FROM messages_binary
           WHERE group_id = 'e7e46753-2e99-4ee4-b77f-17136b01790e'
           AND timestamp > '1970-01-01T00:00:00.000Z-0000-ae26b84edae7349e';
                                                                      QUERY PLAN

-------------------------------------------------------------------------------------------------------------------------------------
---------------------------
 Index Scan using messages_binary_key2 on messages_binary  (cost=0.00..5.25 rows=10 width=52)
   Index Cond: ((group_id = 'e7e46753-2e99-4ee4-b77f-17136b01790e'::uuid) AND ("timestamp" > '1970-01-01T00:00:00.000Z-0000-ae26
b84edae7349e'::text))
(2 rows)

이것은 매우 효과가 있다.INCLUDE 자구를 사용하여 선택한 모든 열을 색인에 추가하면 다음과 같은 효과를 얻을 수 있습니다.

yugabyte=# create index messages_binary_key2 
           on messages_binary ("group_id","timestamp")
           include ("other_column");
CREATE INDEX

yugabyte=# EXPLAIN SELECT * FROM messages_binary
           WHERE group_id = 'e7e46753-2e99-4ee4-b77f-17136b01790e'
           AND timestamp > '1970-01-01T00:00:00.000Z-0000-ae26b84edae7349e';
                                                                      QUERY PLAN

-------------------------------------------------------------------------------------------------------------------------------------
---------------------------
 Index Only Scan using messages_binary_key2 on messages_binary  (cost=0.00..5.15 rows=10 width=52)
   Index Cond: ((group_id = 'e7e46753-2e99-4ee4-b77f-17136b01790e'::uuid) AND ("timestamp" > '1970-01-01T00:00:00.000Z-0000-ae26
b84edae7349e'::text))
(2 rows)

다음 단원에서는 이러한 색인 전용 검색 기술에 대해 자세히 설명합니다.
https://blog.yugabyte.com/how-a-distributed-sql-database-boosts-secondary-index-queries-with-index-only-scan/
진일보한 분석을 통해'시간 스탬프','그룹 id'의 인덱스는 전혀 쓸모가 없을 수 있다. 왜냐하면 우리는 timestamp만 조회하고 group_id은 조회하지 않을 가능성이 낮기 때문이다.
그러면 이 테이블을 다음과 같이 정의하는 것이 좋습니다.

yugabyte=# create table messages_binary (
            "timestamp" text,
            "group_id" uuid,
            "other_column" int,
            primary key("group_id","timestamp")
            );
CREATE TABLE

추가 행을 삽입하고 실행 계획을 보려면 다음과 같이 하십시오.

yugabyte=# insert into messages_binary
           with groups as (
            select gen_random_uuid() group_id from generate_series(1,1e3)
           )
           select
            to_char(now()+(generate_series(1,1e4)*interval'1 second')
             ,'yyyy-mm-ddThh24:mi:ss.000Z-')
             ||substr(gen_random_uuid()::text,25) "timestamp"
            ,group_id, 42 as "value"
           from groups;

yugabyte=# analyze messages_binary;
ANALYZE

yugabyte=# EXPLAIN (analyze)
           SELECT * FROM messages_binary
           WHERE group_id = 'e7e46753-2e99-4ee4-b77f-17136b01790e'
           AND timestamp > '1970-01-01T00:00:00.000Z-0000-ae26b84edae7349e';
                                                                                                                                                                                                                  QUERY PLAN

-------------------------------------------------------------------------------------------------------------------------------------
---------------------------
 Index Scan using messages_binary_pkey on messages_binary  (cost=0.00..1214.95 rows=10530 width=52) (actual time=10.588..100.838
 rows=10000 loops=1)
   Index Cond: ((group_id = 'e7e46753-2e99-4ee4-b77f-17136b01790e'::uuid) AND ("timestamp" > '1970-01-01T00:00:00.000Z-0000-ae26
b84edae7349e'::text))
 Planning Time: 0.067 ms
 Execution Time: 101.711 ms
(4 rows)

나의 소형 8VCPU 실험실에서 1000만 줄의 시계에서 100밀리초 안에 10000줄을 검색하였으나, 이것은 시계의 크기에 달려 있지 않다는 것을 말씀드릴 수 있습니다.이것은 접근 패턴을 이해하는 또 다른 장점이다. 어떻게 확장되는지 알고 있다.이 색인 스캔은 테이블 크기에서 O (1) 에 가깝다.이것은 실제로는'logn'이지만, 큰 범위의 스캔에 대해서는 B 트리에서 잎으로 갈라지거나 LSM 트리의 SST 파일의seek을 무시할 수 있습니다.결과 크기는 O(n)입니다.
니콜라이 사모흐바로프(postgres.ai)와 논의한 뒤 사체로 업데이트했다.YugabyteDB와 PostgreSQL의 결과도 비교했다.내 조회가 생성한 줄은 '그룹 id' 순서로 삽입됩니다. 이것은 YugabyteDB의 어떤 내용도 바꾸지 않습니다. 줄은 메인 키로 구성되어 있지만, PostgreSQL 컬렉션의 성능은 색인/테이블의 관련성에 달려 있습니다.다음은 PostgreSQL에서 타임 스탬프에 더 진실한 상황이 있는 예입니다.

postgres=# truncate table messages_binary;
TRUNCATE TABLE
postgres=# insert into messages_binary
           with groups as (
                       select gen_random_uuid() group_id from generate_series(1,1e3)
                      ), timestamps as (
                       select to_char(now()+(generate_series(1,1e4)*interval'1 second')
                        ,'yyyy-mm-ddThh24:mi:ss.000Z-')
                        ||substr(gen_random_uuid()::text,25) "timestamp"
                      )
                      select
                       "timestamp",group_id, 42 as "value"
                      from timestamps,groups;
INSERT 0 10000000

postgres=# select * from messages_binary limit 1;
               timestamp               |               group_id               | other_column
--------------------------------------------+--------------------------------------+--------------
 2021-11-08T08:34:14.000Z-6bb27dbe2723 | 91ee7381-eb92-48cd-bb82-9ed939dc3a13 |           42
(1 row)

postgres=# EXPLAIN (analyze,buffers)
           SELECT * FROM messages_binary
           WHERE group_id = '91ee7381-eb92-48cd-bb82-9ed939dc3a13'
           AND timestamp > '1970-01-01T00:00:00.000Z-0000-ae26b84edae7349e';
                                                                         QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on messages_binary  (cost=778.61..30792.78 rows=9956 width=58) (actual time=3.021..43.141 rows=10000 loops=1)
   Recheck Cond: ((group_id = '91ee7381-eb92-48cd-bb82-9ed939dc3a13'::uuid) AND ("timestamp" > '1970-01-01T00:00:00.000Z-0000-ae26b84edae7349e'::text))
   Heap Blocks: exact=10000
   Buffers: shared hit=2006 read=8167 written=2249
   ->  Bitmap Index Scan on messages_binary_pkey  (cost=0.00..776.12 rows=9956 width=0) (actual time=1.897..1.897 rows=10000 loops=1)
         Index Cond: ((group_id = '91ee7381-eb92-48cd-bb82-9ed939dc3a13'::uuid) AND ("timestamp" > '1970-01-01T00:00:00.000Z-0000-ae26b84edae7349e'::text))
         Buffers: shared hit=11 read=162
 Planning Time: 0.086 ms
 Execution Time: 43.832 ms

메모리 지연과 버퍼 사용 가능한 메모리가 숫자를 바꿉니다.YugabyteDB의 LSM 트리 자동 압축, PostgreSQL의 수동 pg 재포장이 도움이 됩니다.기본적으로 우리는 같은 구장에 있다.응답 시간이 예상보다 몇 등급 높을 때, 우리는 데이터 접근의 설계를 고려해야 한다.그리고 엔진마다 약간의 추가 최적화가 있을 수 있다.
이것은 이 검색이 할 수 있는 가장 좋은 일이다. 추가 인덱스가 필요하지 않고, 키의 정확한 열 순서만 정의할 수 있다.PostgreSQL에서, 이것은 테이블에서 무작위로 읽어야 하지만, 적어도 모든 내용은 메인 키 인덱스의 범위 스캔에서 필터됩니다.YugabyteDB의 모든 행은 순차적 읽기를 통해 검색됩니다.

은 기본 키에서 분리되며 하나의 태블릿에서만

을 읽습니다.

SST 파일에는 bloom 필터가 있어 많은 파일을 건너뛸 수 있습니다.

이러한 인덱스 블록은 필요한

만 읽습니다.
알바로 엘난데스(Alvaro Hernández)의 또 다른 말은 이 검색이 검색한 줄의 수를 의심했다.

알바로 엘난데스

이거 너무 많을 거야.왜 이렇게 많은 줄을 되돌려야 합니까?색인이 있든 없든 간에 이것은 확장하기 쉽지 않다.
2021년 11월 6일 오후 23:18
그리고 하나 더, 제임스 롱의 실행 계획은 색인 조건에서 (group_id = '983d5259-97ff-49e3-8829-101ab8dead92'::text)으로 표시됩니다.UUID를 TXT로 저장하는 것은 효율적이지 않습니다. 여기서 UUID 데이터 형식을 사용했습니다.

yugabyte=# select pg_column_size(
           'e7e46753-2e99-4ee4-b77f-17136b01790e'::uuid);

 pg_column_size
---------------------
             16
(1 row)

yugabyte=# select pg_column_size(
           'e7e46753-2e99-4ee4-b77f-17136b01790e'::text);

 pg_column_size
---------------------
             40
(1 row)

한 마디로 하면 '데이터베이스 신축 불가' 를 설명하기 전에 사용자의 접근 패턴을 이해할 수 있는 지름길이 없습니다. 예상 결과의 크기와 유효한 접근 구조입니다.제임스 랑처럼: 집행 계획을 읽고 지역 사회에 물어보기👍