데이터 모델과 질의 언어 NoSql 등장

다양한 유형의 데이터 모델이 있고 각 데이터 모델은 사용 방법에 대한 가정을 나타낸다. 어떤 종류의 사용법은 쉽고 어떤 동작은 지원하지 않는다. 어떤 연산은 빠르지만 또 어떤 연산은 매우 느리게 작동한다.

 

하나의 데이터 모델만을 완전히 익히는 데도 많은 노력이 필요하다. 데이터 모델을 하나만 사용하고 내부 동작에 대한 걱정이 없을지라도 소프트웨어 작성은 그 자체로 충분히 어렵다.

 

그러나 데이터 모델은 그 위에서 소프트웨어가 할 수 있는 일과 할 수 없는 일에 지대한 영향을 주므로 애플리케이션에 적합한 데이터 모델을 선택하는 작업은 상당히 중요하다. !!

 

sql vs noSql

NoSql 의 특징

오늘날 가장 많이 알려진 데이터 모델은 관계형 데이터모델 이다. 웹에서 볼 수 있는 대부분의 서비스 생산은 여전히 관계형 데이터베이스를 통해 제공된다. 

 

2010년대에 NoSQL 은 관계형 모델의 우위를 뒤집으려는 가장 최신 시도다. 

-> noSql 의 의미는 not only sql 이다. no sql 은 아니다.

 

그렇다면 언제 NoSQL 을 채택할 것인가 ? 

 

• 대규모 데이터셋이다 높은 쓰기 처리량 달성을 관계형 데이터베이스보다 쉽게 할 수 있는 뛰어난 확장성이 필요할 때
• 상용 데이터베이스 제품보다 무료 오픈소스 소프트웨어에 대한 선호도 확산
• 관계형 모델에서 지원하지 않는 특수 질의 동작
• 관계형 스키마의 제한에 대한 불만과 더욱 동적이고 표현력이 풍부한 데이터 모델에 대한 바람

애플리케이션은 저마다 요구사항이 다르다.

 한 사용 사례에 맞는 최적의 기술 선택은 또 다른 사용 사례에 맞는 최적의 선택과는 다를 수 있다. 그러므로 가까운 미래에는 관계형 데이터베이스가 폭넓은 다양함을 가진 비관계형 데이터스토어와 함께 사용될 것이다.

 

객체지향 프로그래밍으로 개발하다 보면 애플리케이션 객체를 데이터 모델로 ( 관계형 데이터 베이스 ) 변환하는 작업을 피할 수 없다. 그렇기 때문에 전환 해주는 계층이 필요하게 되고 불필요한 에너지를 소모하게 된다. 

-> 현재 JPA 하이버네이트 ORM 을 해당 인터페이스로 사용하고 있다. ( 나는 )

 

 

• 객체는 JSON 으로 표현할 수 있고 문서지향 데이터베이스는 이런 JSON 표현에 매우 적합하다.  
• 문서 데이터 베이스 ( No Sql ) 은 일대다 관계에서는 잘 동작한다. 하지만 다대다 관계 표현은 어려웠고 조인은 지원하지 않았다. 
  • -> 다대다 관계에서 참조로 표현해야 하는 질의는 조인이 필요하다. 
• 문서데이터베이스는 별도 테이블이 아닌 상위 레코드 내에 중첩된 레코드 같은 ( rdb 일대다 관계 ) 를 저장한다.

 

어떤 데이터 모델이 애플리케이션 코드를 더 간단하게 할까? 

애플리케이션 데이터가 문서와 비슷한 구조 ( 일대다 관계 트리로 보통 한 번에 전체 트리를 적재 하는 구조 ) 라면 문서 모델을 사용하는 것이 좋다. 

-> 어떤 데이터 모델이 애플리케이션 코드를 더 간단하게 만드는지 말할 수 없다. 데이터 간에 존재하는 관계 유형이 다르기 때문이다.

상호 연결이 많은 데이터의 경우 문서 모델은 곤란하지만 관계형 모델은 무난하다.

 

문서 모델에서의 스키마 유연성

대부분의 문서 데이터베이스 관계형 데이터베이스에서 지원하는 JSON 은 문서의 데이터에 어떤 스키마를 강요하지 않는다. 

-> 임의의 키와 값을 문서에 추가할 수 있고 읽을 때 클라이언트는 문서에 포함된 필드의 존재 여부를 보장하지 않는다.

 

sql은 쓰기스키마 라고도 표현한다. 스키마는 명시적이고 데이터 베이스는 쓰여진 모든 데이터가 스키마를 따르고 있음을 보장한다

nosql 은 읽기 스키마 라고도 표현한다. 데이터 구조는 암묵적이고 데이터를 읽을 때만 해석된다.

 

둘다 장단점이 존재하고 옳고 그른 정답은 없다. 

• 여러 유형의 오브젝트가 있고 각 유형의 오브젝트 별로 자체 테이블에 넣는 방법은 실용적이진 않다.
• 사용자가 제어할 수 없고 언제나 변경 가능한 외부 시스템에 의해 데이터 구조가 결정된다.

-> 이 2가지를 고려할때 유리하면 noSql 을 사용하는게 좋다..

 

질의를 위한 데이터 지역성

문서데이터베이스는 보통 Json , xml 로 부호화된 단일 연속 문자열이나 json, xml 의 이진 변형으로 저장된다.

웹 페이지 상에 문서를 보여주는 동작처럼 애플리케이션이 자주 전체 문서에 접근해야 할 때 저장소 지역성을 활용하면 성능 이점이 있다.

 

sql 처럼 테이블이 다중으로 나눠졌으면 전체를 검색하기 위해 다중 색인 검색이 필요하다.

 

문서데이터베이스는 대개 문서의 작은 부분에만 접근해도 전체 문서를 적재해야 하기에 큰 문서에서는 낭비일 수 있다.

-> 결국엔 한 문서이니까

마찬가지로 문서를 갱신할 때도 보통 전체 문서를 재작성해야 한다. 부호화된 문서의 크기를 바꾸지 않는 수정은 쉽게 수행할 수 있다.

지역성을 위해 관련 데이터를 함께 그룹화하는 개념이 문서 모델에만 국한되지는 않는다는 점이 중요하다. 

-> 머 다른 데이터베이스들도 관계형 데이터베이스 뿐만이 아니라 다른 데이터베이스 ..

 

데이터를 위한 질의 언어

SQL 은 선언형 질의언어다. 

SQL 이나 관계 대수 같은 선언형 질의 언어에서는 목표를 달성하기 위한 방법이 아니라 알고자 하는 데이터의 패턴, 즉 결과가 충족해야 하는 조건과 데이터를 어떻게 변환( 예를 들어 정렬, 그룹화 집계) 할지를 지정하기만 하면 된다. 

-> 어떤 색인과 어떤 조인 함수를 사용할지, 질의의 다양한 부분을 어떤 순서로 실행할지를 결정하는 일은 데이터베이스 시스템의 질의 최적화기가 할 일이다.

 

선언형 언어는 결과를 결정하기 위한 알고리즘을 지정하는 게 아니라 결과의 패턴만 지정하기 때문에 병렬 실행으로 더 빨라질 가능성이 크다. 가능한 경우 데이터베이스는 질의 언어의 병렬 구현을 마음껏 사용할 수 있다.

-> 우리가 흔히 자바에서 코딩할 때는 명령형 언어를 사용한다. 하지만 sql 에서 선언형을 쓰면 코드를 이해하는데 더 오래 걸리고 어렵다라고 한다.