no SQL 의 확장성에 관해서

[익명(106.240)]

대표적으로 no SQL DB인 몽고 DB, Redis 등이 있는데

이러한 DB특징으로는 master / slave 기반으로한 서버 확장성을 많이 거론한다.

하지만 RDB는 확장성있는 서버로 만드는것은 가능하고 서버간의 정합성을 판별성에서도 하나의 트랜잭션에 대해서 잘유지해준다면 문제 없을 것 같은데

RDB로는 여러 분산서버의 트랜잭션에 대한 정합성을 따지기 힘든 이유가 뭔가요?

[익명(lpiecel)]

속도문제. 참고로 정합성 맞춰주는 디비도 있긴함 국내에도있다 ㅋ 단 트랜잭션 정합성을 맞춰주기 위한 기법들이 모두 속도에 치명적인 영향을 주기 때문임 그래서 async로 갈수밖에없고. 근데 a/s 시스템이라면 현 대부분의 알디비가 지원할걸? - dc App

[익명(106.240)]

SAGA 패턴 2 phase commit 이런기법들 말하는건가요?

[익명(106.240)]

근데 궁금한게 현업에서 확장성때문에 기존에 있던 RDB -> No SQL로 바꾸기 어렵지않나요??

[익명(lpiecel)]

그러합니다. 네트워크 속도만 빠르면 되는데… 네트워크가 ㅋㅋ 속도 절대 못따라감 wan환경은 완벽히 불가능이고 lan은 어느정도 속도 하에선 일관성 유지하는 시스템을 만들 수 있음. - dc App

[익명(106.240)]

그렇군요 nosql처럼 그냥 디비에 저장하는게 확실히 빠르겟네요

[익명(lpiecel)]

사실 이론 자체는 sharding 등등 애저녁에 다 나온 얘긴데 현실성이 많이없긴했음. 10g 나오면서 한정된 조건 하에서는 분산시스템 구조 가능한 디비가 나오고 있음 한 5년 후엔 스탠다드 취급받을거임 - dc App

[익명(106.240)]

최근에 두개 혼합된거 나오고 있긴하던데 ㅋㅋㅋ 기술나오면 공부해봐야겟네요

[취준생(175.197)]

정합성을 따진다는게 트랜섹션 ACID를 따져서 바뀌면 commit하고 실패하면 rollback하는 과정을 말하는건가요?

[익명(106.240)]

맞죠 근데 서버 트래픽때문에 DB자체를 확장해야될경우 이때 문제가 되니깐요!

[익명(lpiecel)]

그정도면 그나마 다행인데 commit 이전에도 글로벌 시스템의 보는 시점(스냅샷, 글로벌 뷰 등등으로 얘기하는) 을 맞춰 줘야 됨. 단순히 커밋하면 끝 이런거면 그나마 덜 어려움 ㅋㅋ - dc App