Vitess - 1. overview
뜨문뜨문 NoSQL ⇒ RDB 로 돌아간다(조인 쿼리 성능으로 인해)는 얘기와 함께
ORACLE, Mysql로 가는게 아니라 vitess를 쓴다고 한다.
What is Vitess?
Scalable. Reliable. MySQL-compatible. Cloud-native. Database
란다.
https://vitess.io/docs/18.0/overview/whatisvitess/
대형 클러스터 환경에서 배포, 운영, 스케일링을 위한 데이터베이스 솔루션.
온프레미스 환경에서처럼 퍼블릭, 프라이빗 클라우드 아키텍처에서도 효율적으로 실행되도록 설계되었다.
SQL의 많은 특징들을 확장하면서 NoSQL의 확장성을 결합했다.
다음과 같은 문제들을 해결할 수 있다.
- 샤딩을 통해 SQL 데이터베이스를 확장하는데, 애플리케이션의 변경은 최소화한다.
- Bare-metal, VM 환경에서 클라우드 환경으로의 이관
- 많은 양의 데이터베이스 인스턴스를 배포하고 관리
Vitess는 기존 MySQL 서버 프로토콜을 구현하여 다른 모든 언어와 호환된다.
특징
Performance
- Connection Pooling - 프론트엔드 어플리케이션 쿼리를 하나의 연결 풀위에서 multiplex(HTTP/2의 그 multiplex인듯, 한 연결에 여러번 요청)하여 성능을 최적화한다.
- Query de-duping - in-flight query(아직 수행중인 쿼리)가 계속 실행되는 동안 수신된 동일한 요청에 대해 In-flight query의 결과를 재사용
- Transaction manager - 동시 트랜잭션 수를 제한하고 timeout을 관리하여 전체 처리량을 최적화
Protection
- Query rewriting and sanitization - 비결정적(동일한 입력에 매번 결과가 다른) 수정을 제한하고 피한다.
- Query Blocking - 잠재적으로 문제있는 쿼리가 데이터베이스에 수행되기전에 막아주는 규칙 커스터마이징
- Query Killing - 데이터를 응답받는데 너무 오래걸리는 쿼리 종료
- Table ACLs - 연결된 유저에 기반 테이블에 대한 접근 가능 리스트 제어
Sharding
- 원할한 동적 재 샤딩
- 수직, 수평 샤딩 지원
- 사용자 정의를 플러그인 할 수 있는 다중 샤딩 스키마
MySQL vs Vitess
Vanilla MySQL | Vitess |
---|---|
버전에 따라, 모든 커넥션은 256KB - 3MB의 메모리 오버헤드를 가짐. 즉, 커넥션이 늘어날 때 RAM을 추가로 필요로 함. | 매우 작은 비용으로 커넥션 생성함. |
LIMIT을 작성하지 않은 쿼리와 같이 잘못된 쿼리는 데이터베이스의 모든 유저들에게 영향 | 데이터베이스 성능에 영향을 줄 수 있는 쿼리는 다시 작성하는 SQL 파서를 사용 |
기본적으로 샤딩을 지원하지 않아서 샤딩을 위한 코드와 로직을 어플리케이션에서 작성해야함 | 다양한 샤딩 체계를 지원한다. 테이블을 다른 디비로 이관할 수 있고, 샤딩의 수를 늘리거나 줄일 수 있다. 이 기능은 몇 초의 read-only 중단시간으로 완료됨 |
레플리케이션을 운영할 때 하나의 프라이머리 디비와 몇개의 레플리카로 이뤄진다. 이를 위해 데이터베이스의 라이프사이클과 각 인스턴스간에 상태 통신을 관리해야한다. | Vitess가 데이터베이스 서버의 라이프사이클 관리에 도움을 준다. 프라이머리의 실패 감지와 회복 등 다양한 시나리오를 처리한다. 데이터 백업과 복구도 지원한다. |
MySQL 클러스터는 다양한 목적으로 커스텀된 설정을 가질 수 있다. 하지만, 수평 샤딩이 있는 경우 각 샤딩에 대해 동일한 설정을 반복하여 설정해야하고, 올바른 데이터베이스를 찾기 위한 로직이 필요하다 | etcd, ZooKeeper와 같은 데이터 베이스가 지원하는 토폴로지를 이용한다. 클러스터는 항상 최신화 되어있고(모든 커스텀한 설정이 동시에 이뤄지나봄) 다른 클라이언트에 대해 일관성을 가진다. 또한 쿼리에 대해 적합한 Mysql 인스턴스를 찾기위한 Proxy를 제공한다. |
NoSQL vs Vitess
는 그냥 SQL과 NoSQL 차이인듯