CH#5. Write scale-out(2)

아직·2024년 3월 30일
0

Galera Cluster

목록 보기
4/5
post-thumbnail

Xpand

1. Spider engine보다 고성능, 고가용성에 힘을 주고 합병(Clustrix DB, 2018)한 것이 Xpand로 보인다. 단순히 MariaDB에 InnoDB/spider engine을 쓰냐의 문제가 아니라, distributed SQL RDBMS를 표방하고 있다. Spider engine처럼 하나의 primary node가 중앙 집중적으로 처리하는 구조가 아니라, 각 노드가 분산적으로 처리하므로 샤딩과 다르다고 한다.
2. 첫 번째 특징은 자동 데이터 분산인데 테이블과 인덱스이 생성될 때 자동으로 consistent hashing을 거쳐 sliced 되는 구조여서, 'slice의' 위치와 그것이 포함하는 값을 cluster(hop) 내에서 '예측 가능'하다고 한다. 이때 조회(lookup)를 위해서는 RDBMS의 in-memory table이 활용된다고 한다.
3. 이 때, 테이블에 여러 개의 인덱스가 있다면 테이블의 표현형(representation)으로서 각 인덱스들은 스스로의 분산 키를 갖고 이것이 쿼리의 평가 계획에 도움을 준다고 한다.
4. 위 내용이 다음으로 자동 데이터 분산이 두 번째 특징인 query fan-out을 가능하게 하는 것으로 보인다. Metadata map으로부터 'slice의' 위치와 포함 데이터가 예측 가능하고, 이 작업이 in-memory table에서 충분히 빠르게 수행될 수 있으므로 쿼리를 사전 분석해서 컴파일된 쿼리 조각을 예상된 위치로 넘겨 주는 것으로 이해됐다. 아래 문장이 이를 잘 표현한다고 생각한다. "Bringing the query to the data, rather than the reverse."

MaxScale

1. 당장은 샤딩 이상의 기능이 필요하지도 않거니와, 현재 Xpand는 라이센스 구입도 필요하고 proxy인 MaxScale과 같이 제공되는 것으로 보인다.
2. MaxScale, HA proxy, proxySQL 간 성능을 비교한 자료들이 대부분 6~7년 전의 자료들이어서 벤치마크는 직접 진행해봐야 할 것 같긴한데, MaxScale이 proxySQL을 저격하고 있는 것으로 보이긴 한다.

참고

https://mariadb.com/resources/blog/how-clustrixdb-accomplishes-horizontal-scaling-of-both-writes-reads-without-sharding/
https://mariadb.com/resources/blog/the-clustrixdb-rebalancer-automatically-distributing-balancing-data/
https://severalnines.com/blog/overview-mariadb-xpand-formerly-clustrixdb/
https://www.youtube.com/watch?v=y3uGbtzsKZI&list=PLtdCVrYKVn4FeDGrWarYOkqwRhBZvi6XA&index=3&t=509s
https://www.youtube.com/watch?v=cNIU8jyoEe8
https://severalnines.com/blog/sql-load-balancing-benchmark-comparing-performance-maxscale-vs-haproxy/
https://groups.google.com/g/maxscale/c/wUwZnWW7Rw0
https://mariadb.com/resources/datasheets/mariadb-maxscale-proxysql-comparison/

0개의 댓글