🤖 Backend/Database

소마 멘토님과 배포 DB의 데이터를 직접 수정하는 일에 대해 이야기하는 도중에 터미널을 켜는 나를 보고 깜짝 놀라며 터미널로 관리를 하고 있냐고 물었던 것이 아직도 기억난다. 컬럼명 조차도 제대로 보이지 않는 mysql cli를 썼던 이유를 생각해봤더니, 백엔드 개발을 여기저기서 배울 때 이렇게 하는 것만 봐왔고 프로젝트 개발까지만 하고 유지보수 단계까지 가보지 않아 불편함을 크게 느껴보지 못해서 였던 것 같다. Datagrip을 배우면서 신세계를 맛보고 여기저기에 츄라이해왔는데, 불호하는 사람은 못본 것 같다. 하나 아쉬운 점은 public subnet에 있어야만 가능해서 보안적으로 아쉽다는 것이었는데, 내가 모르는 것이였다.... SSH Tunneling을 통해 안전하면서도 편하게 DB를 다룰 수 있..

이전 노션 블로그의 SQL Tutorial (2021.01.17)로부터 마이그레이션된 글입니다. Aggreate Functions aggregate functions(집계 함수)은 항상 사용하게 될 것이니 익숙해져야 한다. arithmetic operators는 한 행의 열간의 연산만 수행하지만, aggregate functions은 행 전체에 걸쳐서 수행할 수 있다. COUNT Counting all rows COUNT 는 특정 열의 숫자를 세리는 aggregate function이다.. 아래의 두 SQL 문의 결과는 같다. SELECT COUNT(*) FROM tutorial.aapl_historical_stock_price SELECT * FROM tutorial.aapl_historical_sto..

이전 노션 블로그의 [MySQL] DB Authentication 문제 | ERROR 1698 | Access denied for user 'root' (2021.07.26)로부터 마이그레이션된 글입니다. MariaDB 10.0 버전부터는 보안 방식이 'Unix Socket' 방식이 적용된다. mysql -u root -p password spring datasource 접속 따라서 이 두 가지를 위해서는 plugin 을 바꿔야한다. 만약 초기 접속이라면, 비밀번호도 설정해줘야한다. $ sudo mysql mysql> use mysql; mysql> CREATE USER 'user'@'localhost' IDENTIFIED BY 'password'; mysql> CREATE USER 'user'@'%' ..

이전 Velog의 대용량 데이터베이스의 조회 성능을 개선해보자 (2) : 인덱스 튜닝 (2023.11.12) 로부터 마이그레이션된 글입니다. Github main repo / Github server repo 동기 1편의 카테고리별 리뷰 조회를 시작으로 500ms가 넘어가는 요청들을 위주로 Cardinality/Selectivity를 고려하여 인덱스를 생성했다. 하지만 1편까지는 진짜 대용량 데이터베이스는 아니였다. 2편부터 여기어때컴퍼니 벤처 프로젝트인만큼 여기어때 홍보자료에 있는 데이터 규모에서 성능을 측정해보고 필요하다면 개선까지 진행해보자. 기존 테스트 데이터 스케일 여행상품: 30 (각 카테고리 10개씩, 숙소, 식당, 렌터카) 예약: 540,000 (카테고리 별 180,000) - 여행상품 마..

이전 Velog의 대용량 데이터베이스의 조회 성능을 개선해보자 (1) : 인덱스 적용 (2023.10.27) 로부터 마이그레이션된 글입니다. Github main repo / Github server repo 동기 지난 번에 다양한 JPA 문제를 해결하고 비효율적으로 생성되는 쿼리를 최적화해 전체적인 서버 성능이 대폭 향상되었다. 하지만 리뷰 조회 API의 일부 요청의 경우 대폭 향상되었음에도 만족스러운 쿼리 처리 시간에 도달하지 못했다. 다양한 정렬과 필터링을 지원하는 조회 쿼리인만큼 대량의 데이터를 조건절, 정렬 적용하는데 많은 비용이 들고, 특히 리뷰의 분석 결과 중 '청결' 속성이 포함된 리뷰들이나 리뷰의 분석 결과 중 '청결' 속성의 '먼지' 키워드가 포함된 리뷰들과 같이 review 테이블과..

디프만 14기에서 참여 중인 프로젝트에서 백엔드 리드 분이 엔티티의 id를 UUID, ULID로 설정한 것을 보았다. 늘 IDENTITY로 설정하여 MySQL이 AUTO_INCREMENT로 관리하도록 위임했기 때문에 기존 방식과 대비해서 어떤 장점이 있길래 사용하는지 알아보았다. AUTO_INCREMENT 전략의 단점 외부에서 예측하기 쉬운 PK PK가 선형적으로 증가하는 정수이기 때문에, 특정 데이터의 PK를 예측하기 쉬워진다. 실제로 request들의 파라미터를 테스트할 때 종종 느꼈던 것이다. 현재 유저의 id 2000이면 1 ~ 1999까지의 id를 가진 유저가 존재할 확률도 높은 것이다. 이는 단순히 노출된다의 문제를 넘어 SQL Injection 공격에도 취약해진다. DB에 의존적인 PK 개발..