[질문] 백엔드 DB Create나 Patch할 때 락 거는 편임?

[익명(110.9)]

전 회사 코드에선 딱히 CRUD에 레디스 같은거로 락 거는 거 없었고 과제전형도 동시성 문제 생길 상황 없을거 같아서 걍 안 걸었는데 면접에서 API 구현 초보적인 수준이라고 탈탈 털림 ㅡ; 코드 짤때 성능 고려하면서 짠다고 생각했는데 딴 사람들 눈엔 다른가봄

[익명(211.114)]

락을 거는건 정합성을 지켜주기 위함이지 성능을 향상시키기 위함이 아님

[익명(211.114)]

근데 면접관쪽에서 그냥 그러고 끝났음? API 구현이 초보적이다 하고 어떤 부분이 초보적인지 구체적으로 명시를 안해줌?

[익명(110.9)]

걍 성능 신경 쓰면서 하라고만 하고 구체적으론 안 알려줌. 실수로 db단에서 try catch랑 rollback 안해놓은 메소드 한개 있긴 했었는데. 한번도 안 써본 FastAPI로 과제했어야 됐어서 좀 정신없이 하긴 했음. DB에 where 문 들어가는 칼럼에 인덱스 설정 깜빡하고 안한것도 있고

[익명(211.114)]

fastAPI는 API 서버를 위한 프레임워크인데, 넌 DB쪽만 계속 이야기하고 있네. API구현이 초보적이다 했을떈, API의 설정, 미들웨어, 컨트롤러 부분부터 봐야하는게 아닐까 싶은데, 면접관쪽이 DB쪽을 지적한것?

[익명(110.9)]

SQLAlchemy 써서 service layer에 회원가입 메소드 만들때 내가 깜빡하고 에러 처리해서 실패하면 트랜잭션 롤백하는 걸 안 넣긴 했음. 다른 Create나 Patch 메소드들은 트랜잭션 롤백 처리해놨는데 면접관은 회원가입 쪽만 에러 처리 안된거 지적함 ㅇㅇ

[익명(110.9)]

내가 말을 이상하게 했네 ㅇㅇ. 면접관은 API 부분뿐만 아니라 전체적으로 성능을 고려하고 짜라고 말한듯

[익명(211.114)]

그렇군 -ㅅ-;;

[Zuto(chotnt741)]

경력이면 그렇게 느낄수도 있지

[MetaFibonacci(equivalence)]

[탄소배출컨테이너공장(e2882fhjrzeg)]

락거는건 말한대로 정합성의 문제고 API 구현이 초보적이라는건 구체적으로 좀더 들어보고싶네 대략적으로 어떤 시스템 아키텍처에서 어떤 코드레벨로 짯는지 설명좀 해줄수잇어?

[익명(110.9)]

아키텍처까지 갈 것도 없이 회원가입, 로그인, 로그아웃 구현하고 백엔드 서버 대신 레디스에 세션 정보 저장하고 권한 분리된 게시판에 게시글 페이지네이션 정도 구현하는 거 였음. 다른 CRUD 로직은 별 거 없는건데 면접관들이 공통적으로 물어본 부분이 게시판 리스트를 받아오는 메소드였거든? 게시판 리스트는 게시글이 많은 순서대로 Sorting이 가능해야되는 조건이었음

[익명(110.9)]

에러처리는 위에 언급했다시피 처음에 구현하느라 깜빡하고 회원가입 쪽에서 트랜잭션 롤백 에러 처리 안해놓은거만 지적했고 게시판 리스트 받아오는거만 중점적으로 질문했는데 게시판 별로 게시글 개수를 구해야 되서 난 먼저 서브쿼리로 각 게시판 별 게시글 수 구하고 게시글 많은 순서대로 정렬 가능해야 되서 order_by(게시글수) desc로 구현했음. DESC로 정렬하면 성능저하 있지 않을까요 정도 질문 들어와서 난 성능 저하는 어느정도 있을 수 밖에 없다고밖에 대답함

[익명(110.9)]

아 게시글 리스트 페이지네이션도 질문 있었다. 내가 거기서 order_by를 게시글 작성 시간 역순으로 해서 최신글부터 조회되게 구현했는데 그 게시글 작성 시간 컬럼에 인덱스를 안 걸어놨어서 그거 때문에 order_by desc 성능이 낮아질 수 있다고 대답함. 성능 면에서는 전반적으로 쿼리들 중에 인덱스 사용 안된 부분들에 관해서 질문 들어왔었음. 컬럼당 인덱스 유무의 성능 차이 묻길래 당연히 where 문에 들어가는 컬럼에 인덱스를 생성하면 데이터베이스 힙 부분을 다 돌 필요 없이 인덱스만 조회하면 되니까 읽기 성능은 향상되는데 Create나 Patch는 데이터를 삽입하거나 수정할때마다 인덱스도 추가로 생성해줘야 되기 때문에 그 부분은 성능이 저하된다고 대답함 ㅇㅇ

[익명(110.9)]

또 인덱스 설정 깜빡한 컬럼들은 왜 인덱스 설정 안했냐 그래서 Postgres는 MySQL 하고 다르게 외래키나 Where에서 참조되는 컬럼에 대해 인덱스가 자동으로 생성되지 않는데 내가 그걸 까먹었다고 대답했고 ㅇㅇ 지금 생각해보니 대답 진짜 중구난방으로 했다

[익명(220.117)]

근데 mysql도 where에서 참조되는 칼럼에 대하여 인덱스가 자동으로 생성되진 않잖아

[익명(118.235)]

Desc가 왜 느림?? 궁금해서 물어봄

[익명(110.9)]

desc 자체가 느리다기보단 게시글 목록을 desc로 정렬하는데 created_at 컬럼 DESC로 정렬을 했었음. 근데 내가 그 created_at 컬럼에 인덱스를 안 걸어놨었음. 난 그래서 그게 성능 이슈 생긴다고 대답했음 ㅇㅇ;;

[익명(110.9)]

MySQL where 인덱스 생성도 착각했네

[익명(220.117)]

댓글 보면, 알긴 아는데 엄청 긴장을해서 조금 횡설수설하게 된것처럼보이네. 잘 복기해서 다음엔 더 잘하자

[탄소배출컨테이너공장(e2882fhjrzeg)]

0. primary key 로 쓰는 auto increment id 를 사용햇다면 그거로 정렬 거는거도 나쁘지 않앗을듯. created_at 도 cardinality 가 좋아서 인덱스로 쓰기에 나쁘진 않지만 잇는거 쓰면 별도의 index 를 추가할필요가 없어지니까. 1. 게시판 리스트를 받아오는 행위는 빈도로 봣을때 각 게시판에 글을 작성하는 것보다 더 잦은 호출이 이뤄질게 일반적이라고 생각함(방송 중계 달리는 야갤같은 게시판이 아닌이상) 그렇다면 모든 게시판에 대한 서브쿼리를 매번 호출하는거보다는 forum_info 같은 메타데이터성 테이블을 만들어놓고, 글이 작성될때 그 테이블에 잇는 num_of_total_articles 같은 컬럼을 업데이트하고 조회하는게 좋지않앗을까 함.

[탄소배출컨테이너공장(e2882fhjrzeg)]

과제전형 기간이 좀 넉넉햇다면 더미데이터 대충 100만개쯤 만들어서 데이터베이스 채워보고 EXPLAIN ANALYZE 같은거로 퍼포먼스 테스트 해본다음, 어떤 쿼리가 이러한 방식으로 인해 더 나아서 그 방식을 선택햇다로 의사결정 근거를 적어주면 설득력이 잇지 않앗을까 도 생각해봄.

[익명(110.9)]

다들 ㄱㅅㄱㅅ DB 좀 다시 봐야겠네

[익명(220.76)]

order by desc를 쓴다면 인덱스를 desc로 생성하면 성능문제는 해결됨. order by 자체가 코스트로는 최상위권에 위치하는 성능저하 포인트기도 함. 물론 사용패턴에 따라 다르겠지만 게시글 목록 정렬이라면, 당연히 위의 말처럼 PK를 게시글 넘버로 하는것이 더 좋을것임. 글고 인덱스 있으면 dml 성능 좀 느려질 순 있는데, 그건 일반적으로 성능누수에서 배제하는 요소긴함. 인덱스 없이 디비 못쓰니까...