[Discussion] sled DB 에 관한 논의

[danbi2990]

Discussion 에 해당하는 내용인데 메뉴가 없어서 이슈로 남깁니다.

현재 우리는 sled DB를 사용 중입니다. sled 는 키-밸류 방식으로 데이터를 저장하고 range 메소드를 이용해 해당 키값을 사전 순서대로 탐색할 수 있습니다. 저희는 이슈와 PR을 저장할 때 owner/repo#number 포맷을 키값으로 사용합니다. (e.g. aicers/github-dashboard-server# 145)

1. 통계를 계산할 때 성능 문제

#132 에 명시된 통계는 모두 인원, 기간, 저장소를 필터로 사용하는데 DB에 키값으로 필터를 걸 수 없어 모든 데이터를 먼저 가져온 뒤 순회를 해야됩니다. 이 경우 통계가 늘어났을 때 성능에 문제가 없을지 우려됩니다.

DB 변경 없이 개선하려면 캐싱을 이용할 수 있어 보입니다. (동일한 필터가 입력됐을 때 캐싱된 값을 반환하도록)

2. 페이지네이션을 할 때 필터를 사용할 수 없는 문제

통계값만 계산한다면 구현에 문제는 없습니다. 하지만 페이징된 목록을 보여줄 때 문제가 발생할 것으로 예상됩니다.
개념적으로 보면, 현재 페이지네이션 구현은 DB layer(sled)에서 하는데,
(load_connection 함수에서 커서를 디코딩하여 목록을 순회, Database::issues 메소드에서 디코딩된 커서를 인자로 range 호출)
DB에서 필터링을 제공하지 않기 때문에 페이징과 필터를 동시에 적용할 수 없습니다.
필터링을 어플리케이션에서 하게되면 페이지네이션 결과와 필터링 결과의 카운팅이 다르기 때문에 일관성 있는 결과를 반환할 수 없을 것으로 예상됩니다.

이를 수정하려면 페이지네이션을 DB가 아닌 앱에서 해야될 것으로 보입니다.
(load_connection 함수가 호출하는 콜백에서 range를 호출하는게 아닌 모든 데이터를 가져온 뒤 필터링 및 페이징)

우선은 논의 단계로 두고 #132 를 구현하며 추가적인 이슈 발생 시 공유할 예정입니다.

[sehkone]

When we first designed this project, sled DB appeared to be a good choice. But given that it hasn't seen updates since 2021, I believe it's time to consider migrating to Fjall as a more actively maintained alternative.

[danbi2990]

Closing this discussion, already migrated to Fjall.