Open DaehunGwak opened 2 years ago
MD5
함수를 사용해 해시 값을 계산하고 그 값을 MOD
연산해서 데이터를 각 파티션에 분배한다는 것이 유일한 차이이다.MD5
함수를 이용하므로 파티션 키가 반드시 정수 타입이 아니어도 된다. 해시 파티션으로 파티셔닝이 어렵다면 키 파티션을 고려해볼 수 있다.Power-of-two
라는 2의 승수 알고리즘을 이용하게 되는데, 이 알고리즘은 파티션의 추가나 통합 시 다른 파티션에 미치는 영향을 최소화할 수 있다.SQL로 모든 것을 해결하자!
와 같은 발상은 구시대적인 발상이 되어버렸다.DB에서 다 처리하자!
와 같은 생각은, 분산 시스템이 보편화된 모던 아키텍처에서 더더욱 환영받지 못하는 아이디어이다.DB
입장에서 썼는데... 솔직히 하나도 공감 안됐다. 여러 언어를 쓸 때 DB에 스토어드 프로그램을 쓰면 개발 언어나 도구와 관계 없이 일관된 기능(일련 번호 생성)을 사용할 수 있다
는 대목이 킬링 포인트. ( 스노플레이크를 쓰세요... )레인지 파티션
리스트 파티션
해시 파티션
키 파티션
해시 파티션과 비슷한데 해시값 계산에 쓸 값이나 표현식을 사용자가 지정한다.
정수 아니라도 된다는 것
해당 키값을 MD5 해싱하고 그 값을 다시 모듈러 연산해서 분배함.
데이터베이스 내적으로 절차적 처리를 제공하는 프로그램. 장단이 있음.
장점 중 그럴싸했던 것
네트워크 경유 횟수를 줄일 수 있다.
로직 처리 일부를 DB쪽에 이양해서 패킷이 오가는 횟수를 줄일 수 있다.
이를 통해 로직 복잡도를 줄일 수 있으면서도 처리 전체에서의 원자성을 로직 없이도 보장하고, (교환 횟수 x 레이턴시 x 2) 만큼의 지연을 (레이턴시 x 2)로 감소시킬 수 있음.
기능의 추상화
애플리케이션 딴에서 코드 중복을 줄일수 있다는 건 어거지로 짜맞춘 내용 같고(오히려 단점일 수 있다), 그보다는 DB 내적으로 처리를 완결하고 애플리케이션 쪽에 불필요한 인터페이스를 노출하지 않을 수 있다는 점에서 공감.
장점 중 위험하다고 느껴졌던 것
단점
처리 속도가 느리다.
경우에 따라 치명적일 수 있으니 잘 측정하고 판단해서 껴넣어야 할 듯. 다만 대체로 복잡도가 있는 로직은 애플리케이션 레벨에서 처리하지 않을까 싶어서 큰 단점은 아닐 것 같다.
속도가 느린 것도 사실 스토어드 프로그램이 느려서 문제가 되는 경우보단 그냥 슬로우 쿼리라서 문제인 경우가 더 많을 듯?
코드 파편화
위험하다고 느껴졌던 장점 쪽에서 언급했던, 망할 수 있는 대표적인 사례 중 하나.
너무 많아... 프로그래밍이 거기서 거기지 같은 느낌으로 대충 훑고 넘김. 개념만 몇가지 정리한다.
CREATE PROCEDURE로 프로시저, CREATE FUNCTION으로 함수
BEGIN / END가 블록을 열고 닫는다.
CALL로 프로시저 호출, 함수는 그냥 함수 호출하듯이..
트리거 : 특정 상황에서 자동으로 지정한 작업을 수행하는 일종의 훅 펑션 같은것
이벤트: 스케줄러에 따른 정기적 프로그램 호출. 뭔가 이벤트 리스닝은 아님.
진도
일시
2022.08.14.(일) 21:00