POSTGRES Indexing

POSTGRES 선택이유:

• 다른 SQL 과는 달리 extension이 굉장히 많고 아주 강력한 RDMS이다
• POSTGIS , Concurrency Control , Complex Query 를 다루는데 다른
  RDMS보다 더 강력하다고 한다.

Full Scan / Seq Scan “끙…”

• 성능: 대량의 데이터를 처리할때 테이블이 큰 경우 실행 시간이 길어질 수 있습니다.
  자원: 데이터 서버의 리소를 많이 사용합니다. 모든 행을 검색하므로 비효율적이다

B Tree Indexing “빠르다 미치도록”

CREATE INDEX "idx_category" ON stores ("category" text_pattern_ops)

• 정렬된 키-값 쌍을 유지하며 효율적인 검색을 위해 만들어졌습니다
• 검색 성능: 효율적인 이진 검색을 통해 빠르게 검색을 가능하게 해줍니다

단점:

• 공간 사용 :
• 업데이트 비용 : 데이터 수정시 인덱스를 업데이트 해야 하므로 갱신 삽입 삭제 작업의 성능이 영향을 받을수있습니다.
  
• ‘LIKE%’ 검색은 가능하지만 ‘%LIKE%’ 부분에서 결과값을 다 불러 오지 못했다.
  

Full Text Index “효과적이다”

CREATE INDEX "idx_category" ON stores USING gin ("category" gin_trgm_ops)
SELECT * FROM your_table_name WHERE your_column_name @@ to_tsquery('keyword')

• 인덱싱을 통해 Textual data 를 빠르게 반환해 줍니다.
• Full-text 인덱스는 자연어 처리를 지원하여 자연어 쿼리에 적합한 결과를 반환합니다. 예를 들어, 단어의 유사한 형태나 동의어를 포함한 검색이 가능합니다.
• B tree 에서 못 찾아온 데이터를 빠르게 포함해서 찾아와 줍니다.
• 하지만

단점:

• 추가적인 공간을 요구합니다. 인덱싱 옵션에 따라 인덱스의 크기가 증가할 수 있습니다
• 처리속도가 조금 느릴수도 있습니다. btree 만큼의 속도를 내지는 못하고 특히 대량의
  데이터일 경우 속도가 늦을 수도 있습니다.
• BTREE에서 prefix% 만 가져올수 있다면, Postgres의 full text search 는 해당 단어가 딱 들어가야 찾아올수 있었다. ex 용산구 - 서울시 용산구 ( 0 ) 용산구 - 용산구로 ( X )

찾아보니 postgres 도 설정이 다양하다. extension plugin , 라이브러리를 잘 사용하면 원하는 값을 얻을수 있을 것 '같다 51%'. 세상에 쉬운일 하나 없다.

Trouble Shoot:

• 작은 데이터를 조회하거나 Indexing 을 하면 Btree 혹은 Full Text Index 로 빠르게 값을 받아왔다

• 어느 순간, 데이터 대략 1만 4천에서 부터 BITMAP INDEXING 으로 POSTGRES가 다른 인덱싱 보 다 더 효율적이라고 판단하면서 값을 반환했다. 왜지? 왜 BITMAP SCAN BITMAP INDEX 2번 과정을 걸치는데 효율적이라는거지?

시도 방법:

• 메모리 늘리기 (일정 메모리를 늘리면 인덱스 범위가 넓어진다고 했다 by ChatGPT )
• shared_Buffers 수정하기
• VACUUM ANALYZE 실행
• force index

  	```
  	SELECT *
  	FROM stores
  	WHERE 조건
  	AND stores USING INDEX (category_gin_index)
  	``` 잘 안된다.. ㅠㅠ

배운점 :

• 사실 BITMAP INDEX SCAN (누구냐 넌 ) 효율이 굉장히 좋다. 느리게 느껴졌지만 그만큼 데이터를 추가 했기 때문이였다. 인덱싱과 아닌 그 어딘가에 사이. 우리에게 순차적인 인덱싱 성능을 제공해준다. 기능이 워낙 많아서 따로 다뤄볼 예정이다

• 기본적인 Index를 사용하기에는 데이터가 많고, SeqScan를 돌리기엔 적을 때가 있을 수 있다.
  그럴 때 사용되는 것이 바로 비트맵 스캔이다.

• 비트맵은 Heap Scan 과 비트맵 Index를 EXPLAIN AND ANALYZE로 확인 할 수 있었다.
  처음에는 2번의 과정을 걸쳐서 인덱싱보다 느리고 성능도 안좋을지 알았는데,
  - BitMap Index통해 비트맵에 인덱싱을 BITMAP에 기록하고
  - HEAP SCAN BITMAP을 사용해서 결과를 리턴하는 것이다.
  HEAP이니 메모리에서 가져오는듯한다. 아직 비트맵의 생김새를 파악하지 못해서 공부중이다.
  

아무래도 POSTGRES의 선택은 직접적으로 제어하기 힘들었고 적당한 데이터로 TEST를 끝냈기 때문에 데이터가 많을때 postgres FULLTEXT INDEX보다 효율적이라고 생각되는 ELK 로 넘어가기로 했다. inverted indexing은 검색 능력에 중점을 두기 때문에 N-gram 설정 등으로 postgres 보다는 더 간단하게 설정해둘수 있다.