분류 전체보기
8.0 버전에 들어오면서 기존 MyISAM 스토리지 엔진에서만 제공하던 전문 검색이나 위치 기반 검색 기능도 모두 InnoDB 스토리지 엔진에서 사용할 수 있게 개선되었다. 8.1 디스크 읽기 방식: 전기적 특성을 띤 CPU, 메모리는 매우 빠른 속도로 발전했지만 디스크 같은 기계식 장치의 성능은 상당히 제한적으로 발전했다. 데이터베이스의 성능 튜닝은 어떻게 디스크 I/O를 줄이느냐가 관건임. 8.1.1 하드 디스크 드라이브(HDD)와 솔리드 스테이트 드라이브(SSD) : 기계식 HDD를 대체하기 위해 전자식 저장 매체인 SSD가 출시됨. SSD도 기존 HDD와 같은 인터페이스(SATA, SAS)를 지원하므로 내장 디스크나 DAS 또는 SAN에 그대로 사용할 수 있다.SATA, SAS, DAS, SAN?..
MySQL 서버는 사람의 머리 역할을 하는 MySQL 엔진과 손발 역할을 하는 스토리지 엔진으로 구분할 수 있다.4.1 MySQL 엔진 아키텍처4.1.1 MySQL의 전체 구조 : C API, JDBC, ODBC, .NET의 표준 드라이버를 제공하여 모든 언어로 MYSQL 서버에서 쿼리를 사용할 수 있게 지원한다.4.1.1.1 MySQL 엔진 : 클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서 및 전처리기, 옵티마이저로 구성됨. 또한 MYSQL은 표준 SQL 문법(ANSI SQL)을 지원하기 때문에 표준 문법에 따라 작성된 쿼리는 타 DBMS와 호환되어 실행될 수 있다.ANSI SQL이란? American National Standards Institute가 각기 다른 DBM..
무중단 배포 도입 이유진행중인 프로젝트에서 Github Actions를 통해 CI/CD를 구축한 상태이다. main 브랜치에 merge될 때마다 자동 배포가 진행되는데, 이때 필연적으로 서버가 종료되고 다시 시작되는 시간(Downtime)이 발생했다. 최소 30초에서 길면 60초 정도가 걸렸는데, 지금은 개발기간이라 큰 문제는 없지만 이후 운영 상황에서의 이 Downtime은 사용자 경험 측면에서도 안좋고 서비스가 성장할 수록 손실이 커질 것이라 판단하여 무중단배포 도입을 결정하였다.Nginx를 선택한 이유무중단 배포를 구현하는 여러 가지 방식이 있다. Kubernetes, AWS ELB, Nginx 등K8s는 학습 비용이 높고, AWS ELB는 인스턴스를 생성, 관리(과금 위험)해야 했다. Nginx는..
무중단 배포 도입 과정과 배포 전략에 관한 내용은 Nginx , Docker, Github Actions로 무중단배포 진행 를 참고하면 된다. 1. 문제 원인 파악현재 사용중인 서버는 AWS EC2 t2.micro(프리티어)이고, 메모리는 1GB이다. 배포 전략으로 선택한 Green/Blue 는 green과 blue WAS가 동시에 실행되는 시간이 발생하며 이때 RAM 프리티어 한도인 1GB를 넘어가게 되고, 이로 인해 서버의 작동 불가로 이어졌다. 그 이유는1. 모든 메모리가 사용되면 시스템은 새로운 프로세스나 기존 프로세스를 위한 충분한 메모리를 확보할 수 없게 된다.2. 이로 인해 여러 프로세스가 제한된 메모리 자원을 놓고 경쟁하게 만들고,3. 이러한 리소스 경합은 CPU가 효율적으로 프로세스를 ..
먼저 테스트 데이터 총 500만개 (caregivers=간병인), 지역은 총 20개 지역으로 나눠서 동일한 비율로 (지역당 약 25만개씩) 더미데이터를 추가한 뒤 환자 -> 간병인 찾기 기능을 진행하였습니다. 찾기 기능을 원활하게 하려면 적절한 인덱스 설정 + 페이지네이션 구현이 필수입니다.현재 프로젝트는 무한스크롤 방식인 No-Offset 방식의 페이지네이션을 채택하였고, 동적 조건 검색을 원활히 하기 위한 Querydsl을 도입하였습니다. 하지만 구현하는 과정에서 예상치 못한 상황들을 만났고, 해결해 나간 과정을 기록하려 합니다. No-Offset 적용 방식은 여기 입니다. (정렬 복합키 해결) 먼저 프로젝트 구조에 대해 설명드릴 내용이 있습니다. 진행중인 프로젝트는 JPA InheritanceT..
프로젝트를 진행하며 검색 기능을 할 때가 되었습니다. 매칭 신청을 보내기 위해서는 먼저 상대측 리스트를 검색할 필요가 있습니다.다양한 방법이 있었고, 먼저 MySQL의 Full Text Search를 적용해보기로 하였습니다.사용자의 원활한 검색을 위해 Querydsl을 이용해 동적 검색을 할 수 있게 하고 정렬 또한 최신순, 조회순, 후기순으로 가능하도록 진행하였습니다. 1. 첫 번째 문제 발생 : Full Text Search를 하기 위해서는 Match (1)... against (2)...라는 문법을 사용하여야 합니다. (2)-검색어에 해당하는 (1)-컬럼 을 조회하는 것입니다. 하지만 JPA은 full text search 문법을 지원하지 않습니다. 만약 사용한다면 직접 NativeQuery를 날..
조회수를 구현할 때는 1. 중복 카운팅 2. 동시성 3. 속도 4. 락위 부분을 고려해야 합니다. 먼저 조회수를 구현하는 방법에는 여러 방법이 있습니다.1. IP or Mac AddressIP는 같은 IP에서 여러 번 조회하는 경우에 조회수 중복 문제가 방지된다는 장점이 있지만, 여러 사용자가 같은 IP에서 조회한다면 조회수가 1만 올라간다는 단점이 있습니다. 또한 Mac Address는 같은 유저라도 다른 기기라면 다른 유저로 인식한다는 단점 또한 존재하죠. 2. 쿠키브라우저 의존성 : 쿠키는 브라우저에 저장됩니다. 그렇다면 크롬으로 조회하고, edge로 조회했을 때 같은 사용자임에도 조회수가 중복 카운팅 된다는 단점이 있습니다. 또한 정확한 카운팅을 위해 쿠키에 사용자가 방문한 페이지들을 저장한다고 ..
지역 or 이름 or 나이 or 경력 으로 진행할 전체 검색 남음. 검색 결과 정렬도 가능해야함아마 성별은 빼고 특이사항 추가하고경력 빼고 조회수 남음 (락 학습, 도입) 조회수 구현1. redis의 hyperloglog를 이용하여 구현하기로 하였다. 왜냐하면 조회수 특성상 정확도가 100%일 필요가 없고, 기존 세션, 쿠키, ip 등으로 진행하면 단점들이 각각 존재. 특히 메모리 용량을 많이 차지함. but, hyperloglog는 매우 낮은 메모리 사용 & 정확도 100은 아니지만 상당히 일치함. 하지만 redis를 이용하는 것이다보니 redis가 이용 불가능할 시, 조회수를 이용 못함. 즉, 백업을 해두어야 함.이는 rdb로 진행을 해야 한다. 스케쥴러를 통해 하는게 좋다. ===========..
변화에 유연하게 ! 기존에는 검색 결과 리스트 반환은 Offset-Paging 방식으로 구현했었습니다. 하지만 한 주간 회의 진행 후 , 찾기는 무한 스크롤로 변경하기로 결정이 났습니다.그 이유는 검색 결과 리스트가 화면 구조상 최대 5개 정도 밖에 나오지 않는다. => 페이지를 넘길 때 무한스크롤 방식이 편리 (기존 페이징이라면 사용자가 페이지 버튼을 일일히 눌러야 하니 사용자 경험 하락 예상) 때문이였습니다. 이렇듯 기획과 요구사항은 시시각각 달라지고, 그것을 해결하기 위해 개발자가 필요하다고 생각합니다. 코드를 계속 리팩토링 하고 구조를 개선하고 이러한 과정들은 다 이런 변화에 비교적 쉽게 대처하기 위해 진행하는 것 같습니다. 우선 커서 기반 페이지네이션을 적용하는 데 있어서 그리 쉽지만은 않았습..