위코드 기업 협업에 참여하며 공부한 내용을 정리 & 회고한 내용입니다.
기업협업 1주차 미션은 SQL 과 NoSQL 공부였는데, 특이한 점은 공부하는 과정에서 떠오른 모든 생각을 정리하지 않고 적어보라는 것이었다. 이 블로그의 SQL, NoSQL 관련 몇몇 게시물은 그 과정에서 정리한 것인데 그런 표면적인 리서치로 1차 생각을 정리하고 2차로 정리한 내용을 아래 옮긴다. 1차를 정리하고 들었던 피드백은 how 가 아닌 what 에 더 집중해야 한다는 거였다. 계속 새로운 것을 배워야 하는 개발 분야에서 how 만 알고 what을 유추하는 것에는 한계가 있다. what 을 제대로 알면, 다양하게 변주되는 how 를 익히고 사용하는 것이 편하다. 코어 개념을 알면 발산이 쉽다는 말이다. how 를 익히기 전에 시간을 들여 what 을 고민하는 것은 느리게 배운다기 보단 더 빠르게, 편하게 가기 위함이다. what 을 고민할 때 중요한 것은 그 기술이 어떤 문제를 해결했나에서 멈추지 말고 그 문제를 어떻게 해석했나까지 보라는 것이다.(무엇에 포커스를 맞추었는지) 무엇을 보다 질문이 생겼다면 그 답까지 찾아보고 답이 없다면 맥락을 보고 유추해보아도 좋다.
생각정리
의식의 흐름대로 정리한 글에, 멘토님의 코멘트까지 첨부
멘토 코멘트 박스처리
데이터베이스는 데이터를 모아서 저장해둔 곳, 저장하는 방법(구조화)을 고민하는 이유는 다시 꺼내와서 쓰기 위함. 상황에 맞게, 데이터에 맞게 더 잘 사용할 수 있는 방법이 계속 발전하는 것...
여기서 데이터를 꺼내와서 쓴다는 것에 포커스를 맞추면 쿼리에 집중하는 것, 저장하는 것에 포커스를 맞추면 구조에 더 집중. NoSQL은 가져오는 것, 쿼리에 더 포커스를 맞추었다. SQL 도 가져오는 것을 고려하긴 하지만 그보다 저장, 관리에 더 포커스가 맞추어져 있다. 데이터베이스를 정의하는 단계에서는 일단 두가지를 같은 레벨에 두고 생각하는 것이 좋다. 각 포커스에 따른 분리는 하위 단계에서 이루어진다. 데이터베이스란 기본적으로 두가지 기능을 다 잘 수행해야 한다.
결국 데이터를 어떻게 가져다 쓸지에 따라 바뀌는, 데이터를 저장하는 방식도 결국 어떻게 꺼내 쓸 것인지를 고려해 그에 맞게 변화하는.
데이터베이스가 계층형 - 네트워크 - 관계형 으로 변화한 것도 변화를 수용하기 어려운 수직적인 구조를 조금 더 유연하게 만들어온 과정이 아닐까. 관계형이 어느정도 틀을 유지하면서 자유롭게 데이터를 꺼내올 수 있는 최적의 합의 수준이 아니었을지.
최적의 합의 수준, 결국 인간의 기준, 사람이 보기 편하고 쓰기 편하게, 기계친화적보다는 관리하기 편하게 포커스 맞춰진 느낌. SQL은 저장에 포커스를 맞춘 느낌, 과거에는 메가바이트도 간당간당 했다. 가져다 쓰는 것보다 저장하는 것에 더 많은 비용이 들었다. 저장 비용을 줄이기 위해 저장하는 구조를 최적화하고 중복을 제거했다. 요즘은 다르다. 하드보다 램이 더 비싸다. 저장 비용이 훨씬 싸졌다. 저장에 포커스를 맞추기 보다는 쿼리에 포커스를 두는 시대다. SQL 특성상 구조에 포커스를 맞춘다. 효율을 따진다. 저장에 관한.. 죽은 공을 아까워한다. NoSQL 은 땅 남으니까 막 짓고 도로 막 까느 느낌.
SQL 과의 합이 잘 맞아서 관계형 데이터베이스를 잘 써오다가
소셜 네트워크 처럼 고정된 틀로 감당할 수 없는 다양하고 방대한 데이터가 등장했고, 이를 처리하기 위해서는 확장성이 좋은 데이터베이스가 필요해졌고, 그것에 맞춰 NoSQL 이 등장한 것
관계형 데이터 베이스가 무조건 SQL은 아니다. SQL 은 데이터베이스의 정보를 관리하는 프로그래밍 언어, 데이터를 관리하는 다양한 질의어, 명령어를 모아둔 것. 대부분의 관계형 데이터베이스가 SQL 을 사용하고 있어서, 관계형 데이터베이스를 SQL 로 치환해서 생각하는 게 있다. 아무튼 NoSQL 은 SQL 을 제외한 모든 것을 말하는 데, 그렇다고 쿼리문을 안 쓰는 것도 아니다.
NoSQL 도 쿼리를 쓴다. 대신 구조와 쿼리 중 어떤 것에 포커스를 맞추었냐가 다르다... 이 말과 다른 맥락으로.. SQL은 테이블을 조인하고 가져와서 묶고.. 연산 비용이 크다. NoSQL은 연산이 필요없다. 조인한 데이터를 그대로 저장하고 그것을 가져다 쓴다. 때문에 저장된 데이터가 정의되지 않는다. 나중에 바뀔 수 있으니까. 자유롭게 저장하기 때문에 데이터를 가져와서 연산해야 하는 경우가 더 생긴다. 프론트엔드의 비중이 올라간다.
몽고디비의 경우 파이어베이스와 다르게 쿼리문을 사용해 데이터를 가져올 수 있다. 파이어베이스가 api 와 자체 메서드로 데이터를 검색하는 것과는 다른 방식이다. (다시 찾아보니 파이어베이스 자체 쿼리문을 쓴다고??!!) 몽고DB 와 파이어베이스가 다른 방식으로 데이터를 검색하는 이유는 서로 문제를 해석한 맥락이 달라서 일 것, (그럼 이 부분도 고민 필요한)
그 다른 맥락은 내가 직접 두가지 디비를 써봐야 더 정확한 감이 올 것 같다. 각각 방식의 장단점이 무엇인지 봐야 할 것.
몽고디비와 파이어베이스는 문제를 해석한 방향이 다르다. NoSQL 진영은 서비스마다 쿼리문이 다른데, 몽고디비의 쿼리문이 파이어베이스보다 활용성이 좋다. 몽고디비는 하나의 계층만 가지지만, 파이어베이스의 계층은 제한이 없다. 파이어베이스는 쿼리 개념을 패스에 집중했고, 몽고디비는 where 절에 집중했다. 몽고디비는 모든 데이터를 한 계층에 모아놓고, where 절을 잘 만들어서 제공한다. 파이어베이스는 그래도 기본적인 구조는 필요하다는 해석으로 계층구조를 유지한다.
SQL 은 데이터 구조를 짤 때 데이터를 가져오는 방식을 고민하지 않고, NoSQL 은 데이터를 짤 때부터 어떻게 데이터를 가져올지 고민해야 한다는 말을 다시 생각해보면,
SQL 은 처음 구조를 짤 때 NoSQL보다 시간이 많이 걸린다. 테이블을 하나하나 만들고 서로 참조해나가는 과정. 그렇게 시간을 들이는 이유는 데이터의 중복을 없애는 것도 있고, 이후 쿼리문으로 접근해서 데이터를 쉽게 처리하기 위함일 것. NoSQL 은 그런것을 고려하지 않고, 비교적 자유롭게 데이터를 저장한다. 그럼에도 NoSQL 중 파이어베이스는 몽고디비보다 데이터 모델링에 신경을 더 쓴다. 파이어베이스의 자체 쿼리문은 비교적 단순해서 데이터 모델링 자체를 잘 해야 한다. 어떤 트리구조로, 경로로 저장할 것인지. 데이터를 편하게 저장한 후 필요한 것을 합쳐서 바로 불러올 수 있지만, 그 합쳤을 때의 데이터를 제한적인 쿼리문으로 읽어와야 한다. 그렇게 불러온 데이터가 쓰기 불편한 상태라면 데이터 모델 자체를 다시 잡아야 한다.
모든 건 비용 때문이다. 데이터베이스가 계속 발전하는 것도, 작업 방식을 더 자유롭게 정의하는 것도. 어떻게 하면 더 적게 열람하고 덜 수정하고 적게 쓸 수 있는지 고민해 온 것이다. 정답은 없지만 회사마다 정해둔 답이 있다. 자신들의 서비스가 데이터를 어떻게 저장하고 관리해야 가장 적은 비용이 들지, 최적의 쓰기 효과를 낼지 고민한 결과다. DB 는 비용을 줄이기 위해 계속 바뀔 수 있다. 이런 과정을 거친 최적화가 오히려 제약이 될 수도 있다. 10개의 것만 받아서 최적의 루트를 만들었는데, 1개가 더 추가되면.. 대응이 어려울 수 있다.
몽고디비와 파이어베이스를 기준으로 생각해보면 몽고디비는 하나의 계층에 데이터를 다 넣어두고 강력한 자체 쿼리문을 제공한다. 반대로 파이어베이스는 트리형식의 계층구조를 어느정도 갖춘다. 파이어베이스 자체 쿼리문을 제공하지만 몽고디비만큼 강력하지 않다. NoSQL이 SQL과 비교헸을 때 구조화보다 쿼리에 더 신경을 썼지만, 그 안에서도 저장보다 쿼리에 더 집중한 몽고디비가 있다.
데이터, 고유명사, 해석
데이터는 추상적 개념이다. 이런 고유 명사는 시대마다 해석이 다르다. 계산기를 만들던 시절에는 데이터가 높은 수준의 개념이었고, 지금은 데이터가 기반인(모든 것의 아래에 깔리는) 시대다. 지난간 고유 명사의 해석을 알 필요는 없다. 지금을 기점으로 앞을 생각하면 된다. 과거의 개념을 너무 깊게 알 필요는 없다.
자료형 구조
트리구조(계층형 구조)는 피라미드 구조를 말하고 네트워크 구조는 sns 처럼 사람들의 관계가 다 연결된 구조다. 네트워크 구조는 퍼포먼스가 높은 시스템이지만 너무 어렵고 복잡한 구조라 구현 및 관리가 어렵다. 지금의 소셜 네트워크의 데이터도 관리가 쉽지 않다. 지금 이야기하는 NoSQL 은 계층형 구조인데, 그 다음으로 인공지능이 일하는 네트워크 구조의 시대가 올 수 있다. 데이터를 마음대로 저정하면 ai 가 알아서 찾아주는 것이다. 관계형은 아직 현역이지만 이전 세대로 넘어가는 느낌이 있다.
NoSQL
계층형, 트리 구조, 폴더 구조다. 파일 경로를 따라가면 폴더 안의 파일에 접근할 수 있다. 이 파일 경로라는 개념이 쿼리와 같다. 어디 안에 어디 안에 어디로 가라.. 이런 식으로 명령문을 줄 수 있다. where 절을 이용해 어디 도착해서 무엇을 찾아라 할 수 있다. 별도 연산 없이 테이블을 조인시킨 후 거기에 바로 접속해서 내가 필요한 것만 가져온다. 유저 정보 테이블과 유저가 올린 피드테이블이 분리되어 있을 때 두 데이터를 합쳐서 가져오고 싶다면, 두개를 조인한 형태의 데이터를 별도로 만든다다. 이렇게 하면 중복이 많아진다. (여기 있는게 저기에도 있는) 중복되면 업데이트가 어렵다. 하나가 바뀌면 그 값이 중복 적용된 곳에 가서 다 바꿔줘야 한다. 그래서 온디맨드란 방식이 생겨나기도 했다. 저장된 데이터를 업데이트 안된 채로 뿌려두었다가 열람할 때 가져와서 업데이트 한다. 이런 식으로 NoSQL 업데이트의 사용성을 높이기도 한다.
what 에 집중했다면 이제 how 를 보자.
파이어베이스 공식문서를 보면, 데이터 모델이 앞단에 나온다. 그 만큼 데이터 모델링이 중요하다는 말이다. 살펴보면 모델링 예시들도 제시해준다. 몽고디비는 데이터베이스 다음에 바로 서치가 나온다. 검색을 쉽게 하라는 카피도 있다. DB 를 하나의 계층에 다 넣어두고 where 절을 특화해서 잘 찾을 수 있게 만들었기 때문이다. 모델링에 포커스를 맞추지 않는다. 파이어베이스의 쿼리는 쓰기 쉽지만 지원하는 것 자체가 별로 없다. 데이터를 가져오는 것(쿼리) 자체가 제한적이니 처음 구조 설계가 중요하다. 구조를 잘못 짜면 기존 쿼리로 적합한 데이터를 가져오지 못할 수도 있다. 몽고디비는 일단 넣어두면 쿼리를 사용해 다 찾을 수 있다.
찾아본 것
데이터베이스
여러 사람이 공유하여 사용할 목적으로 체계화해 통합 관리하는 데이터 집합. 논리적으로 연관된 하나 이상의 자료 모음으로 그 내용을 고도로 구조화해 검색과 갱신의 효율화를 꽤함. 몇 개의 자료 파일들을 통합해 중복을 없애고 자료를 구조화해 기억시켜 놓은 자료의 집합체. 이런 데이터베이스를 관리하는 시스템을 데이터베이스 관리 시스템이라고 함
관계형 이전의 데이터베이스 들
계층형 - 계층적 상하 종속적 관계 구성, 데이터 엑세스 속도 빠르고, 사용량 예측 쉬운, 초기 세팅후 변화 수용이 어려운
네트워크형 - 데이터를 노드 형태의 네으워크로 구성, 각각의 노드를 서로 대등한 관계로 구성. 상하 종속관계는 해결했으나 구성과 설계가 복잡하고 데이터의 종속성 해결 못함
관계형 - 수학적 논리 관계?를 테이블 형태로 구성한 구조. 테이블 내 컬럼 중 일부를 다른 테이블과 중복해 각 테이블 간 상관관계 정의... 업무 변화에 적응력 높아 유지보수 편리, 생산성 향상, 다른 DBMS 보다 많은 자원 소모, 시스템 부하 높음
SQL - Structured Query Language
쿼리(Query)는 DBMS 에 요청한다는 뜻, 한국말로 질의. 애초에 주로 질문하는 용도였지만 의미가 확장되어 명령까지 포괄. 응용 프로그램은 쿼리를 통해 DBMS 에 명령 내리고 실행 결과를 돌려 받는다. 이런 쿼리 명령을 체계적으로 정리해서 구조적인 언어로 집대성한 것이 SQL.
SQL 은 관계형 데이터베이스 관리 시스템의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어. 자료 검색과 관리, 스키마 생성과 수정, 객체 접근 조정 관리를 위해 고안. 많은 데이터베이스 관련 프로그램들이 SQL 을 표준으로 채택해서 관계형 데이터베이스를 SQL 로 분류하기도 함
NoSQL
데이터의 폭발적인 증가로 빅데이터 분산 처리 및 저장 기술과 함께 발달된 분산 데이터베이스 기술. 다양한 빅데이터 처리기술 가운데 비관계형 데이터 저장소 역할을 함. 관계형 데이터베이스처럼 데이터베이스를 구축하지만 사용되는 용도가 다름
NoSQL로 기대하는 효과(해결하려는 문제) 키밸류 형식으로 데이터를 분산 저장해서 기존 관계형 데이터베이스에서 처리하기 힘들었던 테라바이트, 엑사바이트 단위의 데이터베이스 구축이 가능함. 키 밸류 속성정보를 메타데이터 구조정보에 별도로 보관하므로 데이터 용량이 방대해도 빠르게 조회 가능. 데이터를 다수의 서버에 분산, 저장하기 때문에 동시 접속 클라이언트 수가 많더라도 디스크 및 네트워크 병목 현상 없이 우수한 성능의 서비스 기대할 수 있음
궁극적인 일관성,
데이터베이스의 변경사항이 모든 노드에 궁극적으로 전파되어, 모든 쿼리들이 즉각 업데이트된 데이터를 반환하지 않을 수도?
NoSQL 활용
나중에 커질 데이터를 미리 대비하기 위해 NoSQL 을 선택한다?
데이터베이스 시스템을 RDB 에서 NoSQL 로 변경해서 얻을 수 있는 가장 큰 이점은 분산 환경. 데이터를 하나 이상의 서버로 분산시켜서 스토리지 공간을 늘리고 한 서버에 집중되던 디스크 및 네트워크 I/O 분산으로 전체적인 데이터 처리 속도가 올라간다. 노드 하나가 단절되어도 나머지 노드가 요청에 응답하므로 서비스 가용성도 올라감
NoSQL 특징
join과 같은 복잡한 쿼리 수행이 어렵다. 데이터 모델이 없다고 생각할 수 있지만 그렇지 않다. 키-디자인 또는 컬럼-디자인 같은 데이터 모델링은 NoSQL 성능과 데이터 크게이 직접적 영향을 주므로 전문성이 필요하다.
NoSQL 왜 만들어졌나. 등장 배경
NoSQL 은 SQL 이 아닌 것이 아니라 Not Only SQL 로, 말의 의미를 보면 기존 관계형 DBMS 가 갖는 특성 뿐만 아니라 다른 특성들을 지원한다는 의미. 초반에는 뛰어난 확장성과 성능 등의 특성으로 수많은 비관계형, 분산 데이터 베이스 등장했지만,
SQL 이라는 데이터 처리 언어의 편의성 때문에 바로 넘어가지 않음
데이터의 정확한 처리가 필수적인 시스템에서는 아직도 관게형 데이터베이스 사용.
그러나 2000년 후반부터 인터넷 활성화, 소셜네트워크 등장으로 비정형 데이터를 보다 쉽게 담아서 저장하고 처리할 수 있는 구조의 데이터베이스에 관심이 가게 되었고, 해당 기술이 발전하면서, NoSQL 데이터 베이스가 각광을 받게 됨.
어떤 엔지니어들은 NoSQL 을 Modern web-scale databases 라고 정의. 융통성 있는 데이터 모델, 데이터 저장 및 검색에 특화된 매커니즘 제공. 검색 및 추가 작업에 최적화된 키값 저장 기법 사용. 응답속도, 처리 효율 뛰어남
파이어베이스,
실시간 데이터베이스, 클라우드 호스팅 데이터베이스. 데이터는 JSON으로 저장되며 연결된 모든 클라이언트에 실시간 동기화된다. 크로스 플랫폼 앱을 개발해도 모든 클라이언트가 하나의 실시간 데이터베이스 인스턴스를 공유하고 자동 업데이트로 최신 데이터를 수신한다.
ㄴ 이런식으로 기존 문제를 해결했다.
ㄴ 문제의 해석은? 웹 어플리케이션의 규모가 커지고 사용자의 수나 움직이는 데이터의 양이 커진 시대에 중요한 것은 데이터베이스를 잘 정리해서 운영하는 것보다 사용자가 수정한 정보 혹은 추가한 삭제한 정보들, 혹은 각종 이벤트에 대응해 빠르게 화면에 대응해야 하는 것이 중요해졌다. 그것에 민첩하게 대응해야 한다. 그런 방향으로..
Firestore 소개
Cloud Firestore 는 글로벌 규모의 모바일 및 웹 앱용 데이터의 저장, 동기화, 쿼리를 간소화하는 NoSQL 문서 데이터베이스. 클라이언트 라이브러리는 실시간 동기화와 오프라인 지원을 제공.. 보안 기능..
몽고디비 _ 리액트 책에서 참고,
관계형 데이터베이스의 문제, 한계
데이터 스키마가 고정적, (스키마는 데이터베이스에 어떤 형식의 데이터를 넣을지에 대한 정보) 회원 정보 스키마에 이메일, 이름이 들어갈 경우, 새로 등록하는 데이터 형식이 기존 데이터와 다르다면 기존 데이터를 모두 수정해야 새로운 데이터를 등록할 수 있다. 데이터 양이 많을 경우 데이터베이스의 스키마를 변경하는 작업은 매우 번거로움.
확장성 문제. 관계형 데이터베이스 는 저장하고 처리할 데이터 양이 늘어나면 여러 컴퓨터에 분산시키는 것이 아니라, 해당 데이터 서버의 성능을 업그레이드 하는 방식으로 확장해야 함
몽고디비는 이런 한계를 극복한 문서 지향적 NoSQL 데이터베이스, 유동적인 스키마를 가진다. 종류가 같은 데이터라도 새로 등록해야 할 데이터 형식이 바뀐다고 하더라도 기존 데이터까지 수정할 필요는 없음. 서버의 데이터 양이 늘어나도 여러 컴퓨터로 분산하여 처리 가능, 확장하기 쉬움
데이터의 구조가 자주 바뀐다면, 스키마가 고정적이지 않다면, 몽고디비가 유리하다. 하지만 까다로운 조건으로 데이터를 필터링하거나 ACID 특성을 지켜야 한다면 관계형 데이터베이스가 유리할 수 있다 (ACID, 원자성-일관성-고립성-지속성 의 앞글자를 딴 용어, 데이터베이스 트랜잭션이 안전하게 처리되는 것을 보장하기 위한 성질)
몽고디비, 조금만 배워도 유용하게 활용 가능, 관계형 데이터베이스는 설정할 것도 배워야 할 것도 많다.
몽고디비와 파이어베이스
둘 다 사후 관계형 데이터베이스. - 사용하고 나면 관계가 생긴다..?
몽고디비는 데이터 검색을 위한 쿼리 언어를 허용하지만, 파이어스토어는 이를 위한 자체 메서드와 api 를 호출하는 방식. 파이어베이스의 실시간 데이터베이스는 데이터의 신속한 수집 및 처리를 위해 설계, 클라우드 파이어스토어는 장기 데이터 저장 및 검색을 위해 설계...
규모가 크고 입맛에 맞게 설계를 하여 쓸 수 있는 곳은 몽고디비 선호, 규모가 작고 개발자가 최소한의 노력으로 빠른 시일에 NoSQL 을 사용하여 구축하고 싶을 때는 보통 파이어베이스 사용.
파이어베이스
데이터를 객체 형태로 저장, 이때 데이터를 객체 형태로 저장하는 공간을 문서 document 라고 하고 이런 문서들을 저장하는 문서의 컨테이너인 컬렉션이 존재. 테이블이나, 행의 개념은 존재하지 않는다.
Firebase 와 MongoDB .. 몽고디비 사이트
둘 다 JSON 과 유사한 문서 데이터 모델과 스키마가 유사한 사후 관계형 데이터베이스. 모두 개발자가 빠르게 시작하고 데이터 구조를 구축하면서 반복할 수 있도록 하며 확장 가능한 데이터베이스 클러스터를 쉽게 배포할 수 있게 데이터를 컬렉션으로 분리할 수 있다.
실시간 데이터베이스는 데이터의 신속한 수집 및 처리를 위해 설계, 클라우드 파이어스토어는 장기 데이터 저장 및 검색을 위해 설계. 클라우드 파이어스토어는 SQL 과 유사한 쿼리 구문을 사용해 '참조' 기반으로 데이터 먹색하는 프로그래밍 방식 인터페이스 제공...?!!!
몽고 디비는 온프레미스, 클라우드.. 두가지 선택지가 있지만, 파이어베이스는 무조건 클라우드 데이터베이스.
몽고디비 쿼리 언어는 이런 두 데이터 저장소의 중심에 있는 JSON 과 유사한 문서 구조에 대한 쿼리 업데이트를 수행하기 위해 처음부터 설계..
MongoDB 와 Firebase 는 둘 다 단일 목적의 NoSQL 솔류션이라기 보단 관계형 조상과 유사???!
Firebase 는 모바일 애플리케이션 개발을 위해 명시적으로 설계됨.
소규모 프로젝트나 전용 모바일 애플리케이션을 구축 중이고 하나의 클라우드 제공업체에 종속되는 것이 싫다면 Firebase 를 시작하는 것이 좋고. 보다 일반적인 목적의 데이터 솔루션, 규모에 따른 성능, 고급 쿼리를 찾는다면 MongoDB 가 적합할 것/
참고자료
오라클 페이지
위키백과 - 데이터베이스
데이터 인사이트
삼성 SDS 인사이트 리포트
데이터 베이스 종류
SQL 역사
파이어베이스 몽고디비 차이
Firebase 와 MongoDB 비교
