Enoch-Kim
commented
2 years ago 데이터 모델과 질의언어
데이터 모델은 소프트웨어가 문제를 해결하는 접근 방식에 지대한 영향을 주기 때문에 중요하다. 데이터 모델에 따라 소프트웨어가 할 수 있는 일이 갈리므로 적합한 데이터 모델을 선택하는 것이 중요하다.
관계형 모델과 문서 모델
-
데이터는 relation으로 구성되고 각 관계는 순서 없는 tuple 모음이다.
-
RDBMS와 SQL은 정규화된 구조로 데이터를 저장하고 질의하는데 용이하다.
-
관계형 데이터베이스의 근원은 비즈니스 데이터 처리(트랜잭션이나 일괄처리)에 있다.
-
현재는 다양한 데이터 처리에 사용되고 있는 표준이다.
NoSQL의 탄생
- NoSQL은 적절한 의미가 아닌 당시 이슈로 떠오르기위해 생성된 이름이다 (like javascript)
- 사실 NoSQL이 아닌 Not Only SQL 로 해석해야 옳다.
- NoSQL이 탄생한 배경은 다음과 같다.
- 대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 RDB보다 쉽게할 수 있는 모델 필요
- RDB의 경우 확장성에 용이하지 못함 -> 확장성 있는 모델이 있을 것인가..
- 오픈소스 소프트웨어에 대한 선호도 확산 -> NoSQL 대부분이 오픈소스로 제공
- RDB에서 제공하지 않는 특수 질의 동작 필요
- 스키마 제한을 벗어난 동적이고 표현력이 풍부한 데이터 모델에 대한 바램
- RDB와 NoSQL이 같이 쓰이는 경우를 보여줄 것이라 예언하는데, 실제 저희팀이 이런 구조를 가지는 것 같습니다.
객체 관계형 불일치
- 임피던스 불일치
- 객체지향 프로그래밍과 SQL 데이터 사이의 불일치
- 애플리케이션 객체와 데이터베이스 모델 객체 사이에 거추장스러운 전환 계층 필요
- 이런 불일치를 알아서 처리해주는 ORM 이 인기가 있으나 완전히 해결해주지는 못한다.
- 관계형 스키마를 기술하는 방식으로 다음과 같은 것들이 있다.
- 전통적인 방식으로 각 테이블로 넣고, 외래키로 다른 테이블을 참조하는 방식
- 구조화된 데이터타입(XML, JSON 활용) 사용
- 전체 스키마의 JSON이나 XML 자체를 text 로 저장 -> 질의가 불가
- JSON 의 장점으로 스키마보다 나은 locality를 뽑을 수 있다.
- 난잡한 다중 조인을 필요로 하지 않는 깔끔한 구조가 임피던스 불일치를 줄인다고 생각하는 개발자들이 있으나 꼭 그렇지만은 않다
다대일과 다대다 관계
-
RDB에서 id로 해당 데이터를 참조하는 방식은 다음과 같은 이점이 있다.
- 프로필 간 일관된 스타일과 절차
- 모호함 회피
- 갱신의 편의성
- 현지화 지원
- 더 나은 검색
-
결국 RDB는 다대일 다대다의 상황에 유리
-
RDB에 반해서 Document 기반 데이터베이스는 다음의 상황에 논쟁이 있다
- 다대일 관계에서 후자의 데이터 변경 시 전자의 모든 데이터를 변경해주어야 하는 점
- 다대다 관계에서 매번 다른 이의 정보를 참조해야하는 경우 조인이 불편하다는 점
문서 데이터베이스는 역사를 반복하고 있나?
- 예전 IBM에서 계층모델을 기반으로한 IMS를 데이터베이스로 많이 사용했는데 이가 도큐먼트기반 데이터베이스와 유사하다.
- 당시의 해결책으론 다음 두가지가 있었다.
- 네트워크 모델 (매장)
- 코다실 모델이라고도 부른다
- 외래키가 아닌 포인터 개념으로 레코드를 참조하여 접근
- root로부터 해당 레코드까지 계속 따라가야한 (접근 경로 발생)
- 관계형 모델 (SQL로 세상을 지배)
- 외래키를 기반으로 레코드 접근
- 쿼리 최적화가 필요 (질의 최적화기가 자동으로 함. 물론 hint 등으로 수동으로 해주는게 필요한 경우도 있음)
- 인덱스 선언을 통해 새로운 질의가 가능하다 -> 애플리케이션 수정에 적합
- 네트워크 모델 (매장)
문서 데이터베이스와 비교
- 문서 데이터베이스는 일대다 관계에 매우 유리하다
- 사실 문서 데이터베이스도 document reference를 통해 다대일과 다대다 관계를 구현해낸다
관계형 데이터베이스와 오늘날의 문서 데이터베이스
- 데이터 모델에 관해서 문서 데이터베이스가 선호되는 이유는 다음과 같다
- 스키마 유연성, 지역성에 기인한 더 나은 성능
- 일부 애플리케이션에서 애플리케이션 구현과 매우 유사
어떤 데이터 모델이 애플리케이션 코드를 더 간단하게 할까?
- 문서 데이터베이스는 일대다 관계이며 상호연결이 많지 않은 경우 사용하도록 하자
문서 모델에서의 스키마 유연성
- schemaless로 오해하기 쉽지만 애플리케이션은 어느정도 스키마를 예상하여 읽는다.
- schema-on-read에 해당하며 읽어올 때 스키마 유효성 검사가 필요하다
- spark에서 mongoDB에 넣을 때 발생한 케이스 예시
- 왜 MySQL만 마이SQL로 표현한건지.. 일부러 강조한 걸까요..ㅋㅋ -> 마이SQL에서는 ALTER 시 테이블 복사가 발생해 좋지 않은데 비해 문서 데이터베이스는 그냥 새로 넣을때 변경해 집어넣고, 기존 데이터에 대한 유효성 검사만 해주면 된다.
- 다음과 같이 모든 데이터가 동일한 구조가 아닐 시 유리하다
- 다른 여러 유형의 오브젝트가 있고 각 유형의 오브젝트별로 자체 테이블에 넣는 방법은 실용적이지 않음 -> 이런경우 스키마리스가 좋음
- 사용자가 제어할 수 없고 언제나 변경 가능한 외부 시스템에 의해 데이터 구조가 결정되는 경우
질의를 위한 데이터 지역성
- 애플리케이션이 자주 전체 문서를 접근해야할 경우 저장소 지역성에 의해 문서 데이터베이스가 유리하다.
- 그러나 이는 한 부분을 수정하기 위해서 전체 문서를 적재해야한다는 의미이다 -> 문서를 작게 유지하면서 문서 크기가 증가하는 쓰기를 피해야한다.
- 지역성의 이점을 가져오기 위해 RDB에서는 다중 테이블 색인 클러스터 테이블이나 칼럼 패밀리 등의 기법을 사용한다. (결국 NoSQL이 좋은게 맞나...)
문서 데이터베이스와 관계형 데이터베이스의 통합
- 서로의 특징을 모두 가지도록 진화해가고 있음 -> 결국 하이브리드다!
데이터를 위한 질의 언어
- SQL은 선언형 언어를 사용하여 질의 최적화기가 쿼리를 최적화하여 실행할 수 있도록 한다.
- 또한 선언형 언어는 병렬처리 구현에 용이하다!
웹에서의 선언형 질의
- CSS도 선언형인데 이게 매우 좋다
- 왜 뜬금없이 웹 내용이 나왔는지 모르겠습니다..
맵리듀스 질의
- 맵리듀스 질의는 선언형과 명령형의 중간 언저리..
- 함수형 프로그래밍에서 주로 사용하는 것 처럼 순수함수를 사용해야한다
- 분산 환경에서 사용하기 위한 저수준 언어이고, 사실 SQL이 분산환경에 분리한 것이 아니다..
- 몽고DB는 쫄려서 aggregation pipline 즉, 선언형 질의를 추가했다.
그래프형 데이터 모델
-
다대다 유형이 복잡하다면 RDB 만으로 이를 구현하는 것이 매우 어렵다.
-
우리가 흔히 아는 그래프를 사용한 DB가 이럴때 쓰인다.
-
대표적으로 속성 그래프 모델과 트리플 저장소 모델이 있다.
-
선언형 질의 언어로 Cypher, SPARQL, Datalog가 있다.
-
명령형 질의 언어로 Gremlin이 있다...
-
전 왜 처음 들어보죠 모두..?
-
이후 내용은 저희에게 불필요한 것 같아 생략.. 은 제가 이해가 잘 안가서 생략합니다
-
p61 에서 네트워크 모델과 비교하는 부분 정도만 보면 되지 않을까 싶네여 ㅎㅎㅎㅎ
Issue Brief
범위