NoSQL 과 SQL의 차이를 알아야만 할까?
네. 아쉽게도 알아야 합니다.
두 개의 차이를 알고 있어야 서비스에 적합한 DB를 고를 수 있습니다. 적합한 DB를 고른다는 것은 서비스를 운영하면서 굉장히 큰 차이를 가져옵니다. 똑같은 문제를 풀 때도 다르게 접근할 수 있고, 그 성능 차이도 무시할 수 없기 때문이죠.
어쩌면 원래 코드를 이것저것 짜야하는데, DB 하나로 해결되는 경우도 있을 지 모릅니다. DB를 일종의 자료구조라고 생각하고 생각하시면 좋을 것 같습니다.
단순히 NoSQL, SQL을 비교하기 보다는 CAP 이론을 생각하면서 읽으면 이해에 도움이 될 것 같아서 CAP 를 살짝 넣어보았습니다.
CAP
일관성Consistency, 가용성Availability, 분할Partition Tolerance 를 줄여서 CAP라고 부르죠.
기술이 발전하고 서비스가 거대해지면서 분산 데이터 베이스 시스템이 중요성이 대두되었습니다. 서비스가 거대해지는 만큼 데이터도 그만큼 많이 발생하기 때문에 이를 반드시 대응해야 했죠. Scale-up 보다는 Scale-out이 저렴하고 이런 문제에 대응하기 좋기 때문에 분산 데이터 베이스가 필요해진 것입니다.
분산 데이터베이스는 트래픽이 증가하면 수평 확장하여 대응해 낮은 지연시간을 유지하는 것이 목표입니다.
CAP는 이런 분산 데이터베이스의 성격을 의미합니다.
분산 데이터베이스 시스템을 구성하는 여러 대의 노드는 사용자의 관점에서는 하나의 DB를 이용하는 것처럼 보여야 합니다. 그를 위해서 노드끼리 지속적으로 통신하며 데이터를 공유하고 있습니다.
일관성은 데이터베이스 상의 어떤 노드와 통신하든지 같은 데이터를 조회할 수 있어야 한다는 것입니다. 일관성의 목표는 데이터간의 동기화가 충분히 빨라서 사용할 때 문제가 없도록 만드는 것이죠.
가용성은 모든 요청이 응답을 받을 수 있어야한다는 것입니다. 언제든지 시스템이 작동해야하고 중단되어서는 안됩니다.
분할은 노드간 통신이 끊어지는 것을 의미합니다. 즉 한 노드가 장애가 발생해 다른 노드와 통신할 수 없는 경우, 분할이 생겼다고 할 수 있죠. 분할 허용성은 시스템 내부에서 오류가 발생했을 때에도 시스템이 작동하는 것을 의미합니다. 노드 하나가 문제가 생겨도 다른 노드가 대처할 수 있어야 합니다.
CAP 이론은 분산 데이터베이스 시스템은 C,A,P 중 하나를 희생해야만 한다는 것입니다. 완벽한 시스템은 없다는 것이죠. 물론 이것이 C가 0이고 AP가 100의 비율을 가진다는 의미는 아니라 비교적 중요도가 낮다는 의미입니다.
SQL
흔히 말하는 RDB(Relational DB) 를 의미합니다. RDB는 이름에서부터 알 수 있듯이 `관계(Relationship)` 를 굉장히 중요시합니다.
이는 데이터간의 관계, 스키마 간의 관계를 의미합니다. 따라서 RDB에서는 스키마가 변하지 않는 상황에서 사용하는 것이 좋다고 할 수 있죠. Schema가 계속 변화한다면, 다른 스키마와의 관계가 어긋나기 굉장히 쉬워집니다.
(사실 자주 변하는 스키마는 설계부터가 문제가 있거나 비지니스 요구사항이 변화하는 경우입니다.)
RDB는 자체적으로 유연하지 않는 스키마구조를 특징으로 가져가고 있습니다.
이를 통해서 데이터의 무결성을 보장하고, 데이터를 중복없이 저장하는 것이 목적입니다. 그래서 테이블을 설계하면서 규칙에 따라 정규화를 진행하여 중복을 최소화하려고 하는 것이죠.
이 일관성을 위해서 SQL에서는 ACID 와 Transaction 을 보장하려고 합니다. 따라서 DB를 수평적 확장하는 것이 어렵습니다.
수평적 확장이라고 함은 여러 데이터를 물리적으로 분산 저장하는 것을 의미합니다. 데이터를 분산 저장하게 되면 RDB가 일관성을 지키기 위해서 다른 DB 인스턴스와 연결되는 시간이 필요해집니다. 따라서 업데이트 시 지연이 발생할 수 있는 것이죠.
이렇게 ACID, Transaction을 통해 엄격한 일관성을 준수하면서 확장하는 것이 굉장히 어렵습니다. 그리고 확장하게 되면 Join을 하는 것도 굉장히 복잡해지고요.
다시 말하면, RDB는 데이터의 일관성에 가장 큰 초점을 두고 있으니 데이터의 일관성이 보장되어야 하거나, 여러번의 조인이 필요한 경우에는 RDB를 사용하는 편이 낫습니다.
예를 들자면, 은행과 같이 언제 어디서 갱신하고 조회해도 데이터가 일정해야하는 경우에는 RDB를 이용하는 것이죠.
NoSQL
RDB를 제외한 그 모든 DB를 의미합니다. 따라서 Document, Graph와 같이 여러 종류가 있죠.
RDB의 장점이 일관성이니 NoSql의 장점은 당연히 일관성이 아닙니다.
NoSQL은 어느 정도의 일관성을 포기했습니다. 위에서 말한 것처럼 일관성을 엄격하게 지키다 보면 데이터를 분산 저장하는 것이 굉장히 어려워집니다. 따라서 NoSql은 일관성을 어느정도 포기하고 수평적 확장에 이점을 가지려고 기획되었다고 보시면 됩니다.
(물론 일관성을 완전 포기한 것은 아니고 언젠가는 데이터의 기록이 동일해지는 최종 일관성을 지향하는 것이죠.)
NoSql은 스키마가 유연합니다. 이런 Schema-less한 특성 때문에 새로운 필드를 추가하거나 데이터 구조를 바꾸는 것이 편리합니다. 따라서 데이터 구조가 명확하지 않은 경우에도 쓰일 수 있죠.
NoSQL은 대량의 데이터를 다뤄 수평적으로 확장해야하거나, 읽기 작업이 많고 쓰기 작업이 없는 경우에 적합합니다.
예를 들어, NoSQL은 구매내역, 게임로그 같은 데이터들은 많은 양이 생성되지만 수정될 일이 거의 없는 경우에 주로 사용되고 있습니다.
한번 생각해봅시다.
지난 글이 궁금하다면?
댓글
의견을 남겨주세요