본문 바로가기

좋아하는 것_매직IT/9.redis

4.Redis, NoSQL에 대해서 전반적으로 알아볼께요.

반응형

NoSQL의 유래

  • 영국 소프트웨어 개발자 조핸 오스카슨(Johan Oskarsson) 이 오픈소스 분산 데이터베이스의 토론을 위해 주관한 모임의 이름에서 유래됨.
    • 참조 
      • http://en.wikipedia.org/wiki/NoSQL 
        • History 
          • The term NoSQL was used by Carlo Strozzi in 1998 to name his lightweight Strozzi NoSQL open-source relational database that did not expose the standard Structured Query Language (SQL) interface, but was still relational.[16] His NoSQL RDBMS is distinct from the circa-2009 general concept of NoSQL databases. Strozzi suggests that, because the current NoSQL movement "departs from the relational model altogether, it should therefore have been called more appropriately 'NoREL',[17] referring to 'No Relational'.

            Johan Oskarsson, then a developer at Last.fm, reintroduced the term NoSQL in early 2009 when he organized an event to discuss "open source distributed, non relational databases".[18] The name attempted to label the emergence of an increasing number of non-relational, distributed data stores, including open source clones of Google's Bigtable/MapReduce and Amazon's DynamoDB.

  • 마틴 파울러의 "NoSQL : 빅데이터세상으로 떠나는 간결한 안내서(2013)" 에는 NoSQL이 아래 조건을 만족하는 데이터 저장소라고 기술됨.
    • 대용량 웹 서비스를 위하여 만들어진 데이터 저장소
    • 관계형 데이터 모델을 지양하며, 대량의 분산된 데이터를 저장하고 조회하는 데 특화된 저장소
    • 스키마 없이 사용 가능하거나 느슨한 스키마를 제공하는 저장소

NoSQL의 정의

  • 빅데이터를 처리하기 위한 분산 데이터 저장소의 통칭

NoSQL 의 일반적 특징

  • NoSQL 은 저마다 쓰기/읽기 성능 특화, 2차인덱스 지원, 자동샤딩지원, 기타 등등 각각의 고유한 특징을 가지고 있음.

NoSQL 탄생배경

  • 2010년 이전에는 기업용 애플리케이션을 작성할 때 사용할 데이터 저장소로 관계형데이터 베이스를 선택함.
    • 예) 오라클, 알티베이스등등
  • 2000년대 중반부터 전 세계적인 웹 서비스가 다수 등장함.
    • 기존의 관계 데이터베이스를 사용하여 처리할 수 없을 만큼의 데이터를 생산하기 시작함.
      • 관계형 데이터베이스는 저장된 데이터의 양이 많아질수록, 읽기/쓰기 성능저하가 심해짐.
        • 이유 : 인덱스처리 방식인 B트리의 한계임.
      • 중앙 집중식 데이터 관리패턴에 해당
        • 단일 하드웨어의 성능에 따라전체시스템의 성능이 결정됨.
    • 상용 데이터베이스 개발자들은 분산 환경에서 동작하도록 관게형 데이터베이스의 트랜잭션을 느슨하게 처리하는 솔루션을 개발하게됨.
      • but, 애플리케이션의 복잡도가 증가하고, 하드웨어와 소프트웨어 개발 비용 증가로 이어지게되었음.
        • 추가적으로, 관계형 데이터베이스의 기본적인 특성들이 훼손되므로 동시에 분산 환경헤서도 최적화가 안되는 딜레마에 빠짐.
    • 한편에서는, 데이터를 다른 관점에서 바라보고 처리하는 기술에 대한 연구가 활발하게 진행됨.
      • 구글, 페이스북, 아마존등등 글로벌 서비스 업체들은 더 이상 관계형 데이터베이스만으로는 서비스 트래픽을 감당하기 어렵다고 판단하게됨.
  • 시간이 지나면서, 연구한 자료를 바탕으로 실시간 분산 처리를 위한 오픈소스 솔루션들이 속속 개발되어 발표됨.
    • 이것에 대한 노력의 결과물이, 바로 NoSQL 임.
    • but, NoSQL은 분산환경에서 대량의 데이터를 빠르게 처리하기 위해서, 한두가지 단점을 가진채로 개발됨.
      • 관계형 데이터베이스가 제공하는 쿼리와 트랜잭션 같은 편의 기능을 제공하지 않음.
      • 제공하는 데이터의 일관성 레벨도 NoSQL별로 천차만별임.
      • 솔루션을 도입하기 위해서는, NoSQL에 대한 설계사상과 내부구조를 우선 파악해야함.
        • NoSQL 도입 사례가 많지 않음.
    • 그럼에도 불구하고, NoSQL를 선택하는 이유
      • 하드웨어 추가에 따른 성능의 선형 증가를 얻을 수 있다는 장점.
      • 다양한 NoSQL이 존재하므로, 선택의 폭이 넓어짐.

NoSQL 탄생으로 패러다임 변화

  • 데이터베이스 중심의 애플리케이션 개발 -> 서비스 중심의 개발로 변화됨.

NoSQL의 대량 데이터 처리를 위한 방식

  • 메모리에 임시 저장하고 응답하는 등의 방법을 사용함.
  • 동적인 스케일 아웃을 지원함.
  • 가용성을 위하여 데이터 복제 방법으로 관계형 데이터베이스가 제공하지 못하는 성능과 특징또한 제공함.
  • 시스템의 정지 없이 저장소 소프트웨어의 업그레이드를 제공함.
  • but, 위의 특징을 적절히 사용하려면, NoSQL에 대한 많은 노하우가 필요함.
    • 결국 사용자의 능력에 따라 같은 솔루션을 사용하더라도, 성능과 비용에서 많은 차이가 발생하게됨.
      • 즉, NoSQL 를 사용하기 앞서, 설계사상과 내부구조를 파악하는 작업이 선행되야함.

결론

  • NoSQL은 빅데이터를 처리하기 위한 분산 데이터 저장소
  • NoSQL은 대용량 데이터 처리를 위해서 관계형 데이터베이스의 대안으로 개발됨.
  • 같은 솔루션을 사용하더라도 성능과 비용에서 많은 차이가 발생
    • 즉, 설계사상과 내부구조를 선행적으로 주도면밀하게 파악해야함.
728x90
300x250