You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
이 메소드는 roomId 에 기반하여 최대 1000개의 row 를 createdAt ascending 순서로 가져오는 메소드입니다.
findAllByRoomId 메소드 지연시간이 매우 높게 나오네요 😂. (약 2초 소요...)
1000개 row 가져오면서 order by 로 created_at asc 정렬 시 1400 ms 가 소요되었습니다.
id 는 자동 generate 되도록 설정되었구요!
제 생각에는 created_at 정렬 시 인덱싱이 되어있지 않아서 시간소요가 길다고 생각합니다. 따라서 범위쿼리를 효율적으로 수행할 수 있도록 created_at 에 btree 를 인덱싱 해주겠습니다!
그리고 이전 select ... order by 를 실행하게 된다면!!!!!
... 무친 빠르기를 확인할 수 있었습니다!(위는 postgresql 쿼리 캐싱 이전 실제 쿼리값이구요. 동일쿼리 반복 수행 시 내부 메모리에 쿼리결과가 캐싱되어 훠어어얼씬 빠른 동작을 확인할 수 있었습니다) 역시 btree 는 범위쿼리에 매우 효과적이군요! 이러면 궁금증이 하나 생기죠. 만약 hash 나 다른 인덱싱 전략을 구성한다면? 과연 어떤 차이가 있을까요?
BRIN 인덱싱 - 1618ms 소요
BRIN 은 해당 칼럼의 값이 물리적인 저장 순서에 따라 비교적 균일하게 분포되어 있을 때 가장 효과적입니다. 그래서 created_at 에 적용하면 빠른 인덱싱을 수행할 수 있겠죠?
그러나 데이터가 빈번하게 업데이트되거나 값의 분포가 균일하지 않은 경우에는 적합하지 않다고해요.
order by 에 인덱싱 적용되어 나타나지 않고, sort plan 이 실행되는 걸 확인하였습니다.
이상합니다... 분명 indexing 은 생성되었는데 말이죠.
그래서 찾아보니 order by 에서 인덱싱 지원은 되지 않는다고합니다. 대신 where 절에서는 아래와 같이 인덱싱이 적용된다고 하네요!
따라서 BRIN 인덱싱을 created_at 에 적용한다면 초기 sort 가 일어날 수 밖에 없기때문에 제외해야합니다!
B tree 와 BRIN Order by 지원여부
HASH 인덱싱 - 1864ms 소요
마찬가지로 order by 에 인덱싱 적용되어 나타나지 않고, sort plan 이 실행되는 걸 확인하였습니다. 예상된 결과로 Hash 는 범위쿼리에 전혀 적합하지 않았습니다!
결론은 order by 에서 인덱싱을 활용할 수 있도록 btree 를 적용시킴으로써 쿼리성능을 46배 이상 개선시킬 수 있었습니다!
The text was updated successfully, but these errors were encountered:
ghkdqhrbals
changed the title
[Performance] POST /api-chat/chat
[Performance] 288만건 채팅기록 order by ASC 쿼리 시 indexing 을 통한 성능개선확인! POST /api-chat/chatJan 16, 2024
ghkdqhrbals
changed the title
[Performance] 288만건 채팅기록 order by ASC 쿼리 시 indexing 을 통한 성능개선확인! POST /api-chat/chat
[Performance] 288만건 채팅기록 order by ASC 쿼리 시 indexing 을 통한 성능개선확인! GET /api-chat/roomsJan 16, 2024
ghkdqhrbals
changed the title
[Performance] 288만건 채팅기록 order by ASC 쿼리 시 indexing 을 통한 성능개선확인! GET /api-chat/rooms
[Performance] 288만건 채팅기록 order by ASC 쿼리 시 indexing 을 통한 성능개선확인! GET /api-chat/roomJan 16, 2024
ghkdqhrbals
changed the title
[Performance] 288만건 채팅기록 order by ASC 쿼리 시 indexing 을 통한 성능개선확인! GET /api-chat/room
[Performance] 288만건이 저장된 채팅기록 order by ASC limit 1000 쿼리 시 indexing 을 통한 성능개선확인! GET /api-chat/roomJan 16, 2024
ghkdqhrbals
changed the title
[Performance] 288만건이 저장된 채팅기록 order by ASC limit 1000 쿼리 시 indexing 을 통한 성능개선확인! GET /api-chat/room
[Performance] 288만건이 저장된 채팅기록 order by created_at ASC limit 1000 쿼리 시 indexing 을 통한 성능개선확인! GET /api-chat/roomJan 16, 2024
ghkdqhrbals
changed the title
[Performance] 288만건이 저장된 채팅기록 order by created_at ASC limit 1000 쿼리 시 indexing 을 통한 성능개선확인! GET /api-chat/room
[Performance] 288만건이 저장된 채팅기록 order by 쿼리 성능개선을 위한 인덱스 알고리즘 별 비교
Jan 22, 2024
findAllByRoomId
메소드 지연시간이 매우 높게 나오네요 😂. (약 2초 소요...)1000개 row 가져오면서 order by 로 created_at asc 정렬 시 1400 ms 가 소요되었습니다.
id 는 자동 generate 되도록 설정되었구요!
그리고 이전
select ... order by
를 실행하게 된다면!!!!!... 무친 빠르기를 확인할 수 있었습니다!(위는 postgresql 쿼리 캐싱 이전 실제 쿼리값이구요. 동일쿼리 반복 수행 시 내부 메모리에 쿼리결과가 캐싱되어 훠어어얼씬 빠른 동작을 확인할 수 있었습니다) 역시 btree 는 범위쿼리에 매우 효과적이군요! 이러면 궁금증이 하나 생기죠. 만약 hash 나 다른 인덱싱 전략을 구성한다면? 과연 어떤 차이가 있을까요?
BRIN 인덱싱 - 1618ms 소요
BRIN 은 해당 칼럼의 값이 물리적인 저장 순서에 따라 비교적 균일하게 분포되어 있을 때 가장 효과적입니다. 그래서
created_at
에 적용하면 빠른 인덱싱을 수행할 수 있겠죠?order by 에 인덱싱 적용되어 나타나지 않고, sort plan 이 실행되는 걸 확인하였습니다.
이상합니다... 분명 indexing 은 생성되었는데 말이죠.
![image](https://private-user-images.githubusercontent.com/29156882/297002175-f3c7fd4a-05ae-45dd-967a-5493e4d8a1ee.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzg5MDc1NjMsIm5iZiI6MTczODkwNzI2MywicGF0aCI6Ii8yOTE1Njg4Mi8yOTcwMDIxNzUtZjNjN2ZkNGEtMDVhZS00NWRkLTk2N2EtNTQ5M2U0ZDhhMWVlLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA3VDA1NDc0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTQzMWU1MDgyNWVkYTJlZmY5NWFmNGFhNWI0NzhlMzEzODg5MTY3ZWZmMmFkZWEzMzczNjljMzM2MWNiODAzMTUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.MZAf7BkC8rQmnBVzdO3cjKzMagDyfD0RyyP61ANPdgI)
그래서 찾아보니 order by 에서 인덱싱 지원은 되지 않는다고합니다. 대신 where 절에서는 아래와 같이 인덱싱이 적용된다고 하네요!
따라서 BRIN 인덱싱을 created_at 에 적용한다면 초기 sort 가 일어날 수 밖에 없기때문에 제외해야합니다!
HASH 인덱싱 - 1864ms 소요
마찬가지로 order by 에 인덱싱 적용되어 나타나지 않고, sort plan 이 실행되는 걸 확인하였습니다. 예상된 결과로 Hash 는 범위쿼리에 전혀 적합하지 않았습니다!
결론은 order by 에서 인덱싱을 활용할 수 있도록 btree 를 적용시킴으로써 쿼리성능을 46배 이상 개선시킬 수 있었습니다!
The text was updated successfully, but these errors were encountered: