오늘의 목표
- 1000만건 데이터 저장/조회 전략 확정
- NoSQL를 사용을 할 것 인지?
- 사용이유, 장점, 단점 구분
- 기술 선택
데이터베이스 기술 선택
MySQL와 PostgreSQL는 서로 다른 영역에서 성능을 발휘
Mysql
- 스토리지 엔진의 유연성
- 속도와 안정성
- 서버 최적화를 위한 옵션이 필요할 때
- 가장 사용하기 쉬운 데이터베이스 시스템
- 클라우드 지원 DBMS
- 다중 버전 동시성 제어(MVCC) 및 ACID 규정 준수가 필요하고 테이블이 손상될 위험을 감수할 수 있을 때
PostgreSQL
- RDBMS가 아닌 ORDBMS가 필요할 때
- 복잡한 읽기-쓰기 작업을 수행
- 가장 다양한 데이터 유형에 대한 최고의 NoSQL 지원과 지원을 원할 때
- 초대형 데이터베이스를 관리
- 최상의 다중 버전 동시성 제어(MVCC)가 필요할 때, 최고 수준의 ACID 규정 준수
Benchw Result
첫 번째 결과 세트는 로드, 인덱스 및 쿼리의 전체 실행으로 구성되었습니다.
로드 및 인덱스 단계의 일부 데이터 캐싱이 쿼리에 영향을 줬음
두 번째 실행은 모든 캐시를 강제로 지우기 위해 시스템을 재시작한 후 쿼리로만 구성
PostgreSQL과 MySQL 비교: 주요 차이점
Benchw Results - Open Source 3
DB2 vs PostgreSQL
- 샤딩을 사용 할 경우에는 이점이 있는걸로 보임
Difference between IBM DB2 and PostgreSQL - GeeksforGeeks
compare-db2-postgresql
PostgreSQL 사용 이유
- 왜 선택을 했나요 ?
- 대규모 서비스에 특화가 돼서 사용을 합니다.
- 왜 대규모 서비스에서 사용 하나요?
- MySQL, InnoDB 및 Oracle에서처럼 롤백 세그먼트가 소진되지 않았는지 확인할 필요가 없습니다.
강력한 ACID, 즉 데이터가 안정적이다.
대규모 데이터를 조회 할 때 속도가 Mysql보다 압도적으로 빠르다.
- MySQL, InnoDB 및 Oracle에서처럼 롤백 세그먼트가 소진되지 않았는지 확인할 필요가 없습니다.
PostgreSQL
MySQL
why-use-postgresql-for-your-next-project
1000만건 데이터 저장/조회 동시성 제어
동시성제어를 어떻게 할 건지?
- 카프카
제어를 했다쳐도 스레드의 순서 보장은 어떻게 할 건지?
- 한 파티션으로 진행을 하거나
- 파티션을 여러개로 해서 하나의 키로 컨슈머가 받으면 되는 것 같음
동시성제어를 어떤 기술로 할 것인지 사유는?
- Redis vs Kafka에서 Kafka를 사용 하는게 맞다고 생각
- 사유는 Redis는 저장을 안하지만 Kafka는 저장을 하기 때문(데이터)
- 저장 하나로 선택하는 이유는 티켓의 누락이 절대 되면 안되기 때문 Redis는 데이터의 누락이 생길수도 있어서 Kafka로 하는게 좋아보임
선착순 이벤트 시스템에서 발생가능한 동시성 문제와 해결 방안 탐구(redis, kafka)
Spring Boot, Reactor Kafka 에서의 순서보장과 중복방지에 대한 기록 (feat. redis)
Kafka vs Redis 게시/구독
Apache Kafka | Redis | |
---|---|---|
메시지 크기 | 압축 및 계층형 스토리지로 최대 1GB의 메시지 크기를 지원합니다. | 더 작은 메시지 크기를 지원합니다. |
메시지 전송 | 구독자는 대기열에서 메시지를 가져옵니다. | Redis 서버는 연결된 가입자에게 메시지를 푸시합니다. |
메시지 보존 | 검색 후 메시지를 보존합니다. | 메시지를 보관하지 않습니다. |
오류 처리 | 메시징 수준에서의 강력한 오류 처리. 배달 못한 편지 대기열, 이벤트 재시도 및 리디렉션. | 제한 시간, 클라이언트 제한 및 메모리 버퍼 용량을 사용하여 애플리케이션 수준에서 Redis 예외를 처리해야 합니다. |
병렬 처리 | Kafka는 병렬 처리를 지원합니다. 여러 소비자가 동일한 메시지를 동시에 검색할 수 있습니다. | 병렬 처리를 지원하지 않습니다. |
처리량 | 비동기 읽기/쓰기로 인해 처리량이 더 높습니다. | Redis 서버가 다른 구독자에게 메시지를 보내기 전에 회신을 기다려야 하기 때문에 처리량이 줄어듭니다. |
지연 시간 | 짧은 지연 시간. 기본적으로 데이터 복제로 인해 Redis보다 약간 느립니다. | 작은 크기의 메시지를 배포할 때 지연 시간이 매우 짧습니다. |
내결함성 | 파티션을 다른 브로커에 자동으로 백업합니다. | 기본적으로 백업되지 않습니다. 사용자는 Redis 지속성을 수동으로 활성화할 수 있습니다. 소규모 데이터 손실 위험. |
Redis와 Kafka 비교 - 게시/구독 메시징 시스템 간의 차이점 - AWS
1000만건을 빠르게 조회 방법은?
- Redis 캐시 전략으로 사용하면 될 듯 하다.
- 쓰기 전략에서 Around 방식으로 가도 괜찮을거 같다.
제어를 했다쳐도 스레드의 순서 보장은 어떻게 할 건지?
- 한 파티션으로 진행을 하거나
- 파티션을 여러개로 해서 하나의 키로 컨슈머가 받으면 되는 것 같음
kafka 순서 보장
선착순 이벤트 시스템에서 발생가능한 동시성 문제와 해결 방안 탐구(redis, kafka)
Spring Boot, Reactor Kafka 에서의 순서보장과 중복방지에 대한 기록 (feat. redis)
동시성제어를 어떤 기술로 할 것인지 사유는?
- Redis vs Kafka에서 Kafka를 사용 하는게 맞다고 생각
- 사유는 Redis는 저장을 안하지만 Kafka는 저장을 하기 때문(데이터)
- 저장 하나로 선택하는 이유는 티켓의 누락이 절대 되면 안되기 때문 Redis는 데이터의 누락이 생길수도 있어서 Kafka로 하는게 좋아보임
- Kafka vs Redis 게시/구독
Apache Kafka | Redis | |
---|---|---|
메시지 크기 | 압축 및 계층형 스토리지로 최대 1GB의 메시지 크기를 지원합니다. | 더 작은 메시지 크기를 지원합니다. |
메시지 전송 | 구독자는 대기열에서 메시지를 가져옵니다. | Redis 서버는 연결된 가입자에게 메시지를 푸시합니다. |
메시지 보존 | 검색 후 메시지를 보존합니다. | 메시지를 보관하지 않습니다. |
오류 처리 | 메시징 수준에서의 강력한 오류 처리. 배달 못한 편지 대기열, 이벤트 재시도 및 리디렉션. | 제한 시간, 클라이언트 제한 및 메모리 버퍼 용량을 사용하여 애플리케이션 수준에서 Redis 예외를 처리해야 합니다. |
병렬 처리 | Kafka는 병렬 처리를 지원합니다. 여러 소비자가 동일한 메시지를 동시에 검색할 수 있습니다. | 병렬 처리를 지원하지 않습니다. |
처리량 | 비동기 읽기/쓰기로 인해 처리량이 더 높습니다. | Redis 서버가 다른 구독자에게 메시지를 보내기 전에 회신을 기다려야 하기 때문에 처리량이 줄어듭니다. |
지연 시간 | 짧은 지연 시간. 기본적으로 데이터 복제로 인해 Redis보다 약간 느립니다. | 작은 크기의 메시지를 배포할 때 지연 시간이 매우 짧습니다. |
내결함성 | 파티션을 다른 브로커에 자동으로 백업합니다. | 기본적으로 백업되지 않습니다. 사용자는 Redis 지속성을 수동으로 활성화할 수 있습니다. 소규모 데이터 손실 위험. |
'항해99' 카테고리의 다른 글
항해99 실전 프로젝트 (6일차) (0) | 2024.02.01 |
---|---|
항해99 실전 프로젝트 (5일차) (0) | 2024.01.31 |
항해99 실전 프로젝트 (3일차) (0) | 2024.01.29 |
항해99 실전 프로젝트 (2일차) (0) | 2024.01.27 |
항해99 실전 프로젝트 (1일차) (0) | 2024.01.26 |