[질문] 분산형 서버에 db 질문있슴

[익명(121.55)]

분산 서버에는 nosql의 몽고, 카산드라 같은게 좋다고 하는데 

여러 분산서버에 데이터를 복제해서 넣는거라면

mysql이나 oracle 같은 sql db를 써도 상관없는거 아님?

여러가지 db 프로그램을 보면서 문뜩 생각나서 질문해봄

[익명(223.38)]

이건 글하나 쓰면 재밋는주제일듯

[퇴물(219.254)]

분산형은 샤딩을 말하는건데, 도서관으로 치면 책들이 존나 많은데, 어차피 사람들은 가는 곳만 가는 특성이 있음. IT쪽이면 IT쪽 서적으로, 문학 좋아하는 애들은 문학쪽으로 자세히보면 층별로 분리되어 있는거지. 마찬가지로 분산형은 알아서 분리해서 로드벨런서처럼 적당히 분산해서 쿼리를 처리함. 근데 이게 SQL이랑 다른점은 SQL은 그 뭐냐 정규화 그런걸로 Join으로 참조를 되게 많이 하는편, 근데 MongoDB는 하나의 Document(Row Record)에 다 때려박는게 보통이라서 Join 잘 안씀. (되긴 됨) Join이 없으니까 서로 참고할일이 적어서 느슨한 결합이 되어있어서 서버 여러대가 독립적인 쿼리를 처리해도 무방하다 이거임.

[익명(121.55)]

오.. 완전 이해 잘되는데, 질문 하나만 더할게. 카산드라같은 컬럼형 db를 너가말한 방식에 비유하면 IT면 IT, 문학이면 문학 column으로 리퀘스트를 분산시켜서 연산속도를 sql보다 빠르게 할 수 있단 거지??

[퇴물(219.254)]

column 단위로 분산이 아니라 사실상 테이블(Collection) 과 테이블 내에서 인덱스 단위로 게시판 페이지 처럼 뭉텅이로 관리한다고 보는게 좀더 이해하기 편할꺼야. 뭔가 조회하는데, 이건 대략 200페이지 쯤이니까, 난 1~100페이지까지니까. 옆에있는 B서버로 가봐. 이렇게 접근할 수 있는 개념.

[퇴물(219.254)]

카산드라는 안써봐서 잘 모름. 어쌔신크리드에서 썰기만 썰어봐서..

[익명(121.55)]

설명 넘 잘해줘서 메모해놨다.. ㄳㄳ

[퇴물(219.254)]

그리고 Document 타입이 테이블 스키마 정의 같은게 없다보니 걍 자유 포맷이고, id로 가장 많이 쓰는 Auto Increase Key Column이 없다. 그냥 박으면 _id는 uuid처럼 겹치지 않는 고유 id가 부여됨. Auto Increase Column이 없어서 순서를 지켜야하는 락도 없다보니 그냥 다 때려박아도 됨. 그래서 빠름. 그래서 분산에 유리하다는거지 설계와 정합성, 일관성면에서는 SQL을 사용하는게 이득이고, 대규모 데이터인데 빠른 조회속도가 목적이고 자주 스키마가 변환되는 상황이라면 Document 방식이 이득.

[퇴물(219.254)]

개인적으로는 MongoDB를 선호하는 SQL은 테이블 스키마 바꾸면 코드에서 뿜뿜한다. 그래서 라이브 서비스에서 테이블 스키마 바꾸는게 굉장히 조심스러울 수 밖에 없고, 진짜 무중단이면 부담 백배임. MongoDB는 필드에 version:1, version:2 이렇게 적어서 record에 박혀있는 버전보고 스키마를 유추할수 있어서 기존 레거시 데이터와 신규데이터등 호환이 가능해서 이점 때매 좋아함.

[퇴물(219.254)]

그리고 Aggregate Pipeline 딱 써보면, 랭귀지는 거지같지만 맛들리면 뽕에 취해서 이거 아님 못쓴다.

[익명(58.122)]

분산 서버에서 가장 중요한 점은 분산도임. cassandra같은건 ring hash같은 알고리즘을 이용해서 최대한 균등적으로 분산되게 함. 당연히 이런 분산 처리없이 깡으로 복제해서 넣으면 뭐..rdb도 충분히 안 될건 없지. rdb도 사실 rdb"ms"인 것처럼 데이터를 어떤 식으로 잘 알아서 엔진이 처리해주느냐가 관건임 모든게 어떤 형태라도 안될건 없음. 그게 효율적인지가 중요한거지. CAP Theorem 한번 찾아보셈

[익명(220.94)]

mysql은 horizontal scaling이 안됨 그래서 좆나 무식하게 id modular 아니면 range로 샤드 만드는데 이렇게 일단 나누면 조인도 못함 글고 샤드 늘리거나 줄이는것도 매우 제한적임 모듈러로 했으면 곱하기 나누기밖에 안되고. 그래서 여러 노드에 레플리카 3벌이상 쌓는 mongodb나 hbase 같은걸 선호하는거임

[익명(175.209)]

RDB 핵심이 조인되는 트랜잭션인데 분산 키는 순간 이거 못하거나 제한당함

[익명(118.235)]

Nosql 급 갈라면 진짜 완전 개 초거대 정도여야 특수목적으로 쓰는거고 울나라 발생하는 트래픽이면 그냥 오라클로도 다 커버 가능

[익명(lpiecel)]

되긴 해. 실제로 그런 컨셉의 RDB도 있어. 그런데 RDBMS의 기본 사상인 Join, 정합성, 트랜잭션 등 때문에 트레이드오프가 큼 네트워크라는게 존나 느린새끼라서 join, 트랜잭션 개념만 들어가기 시작해도 네트워크 코스트가 상당히 부담되기 시작함 잘만 쓰면 RDB에서도 좋을 수 있음. 근데 그 사용처가 한정적이고 힘들어서 잘안쓰는거. 못할 건 없음.