바쁜듯 안바쁜듯 정신없는 일주일
심화주차의 1주일이 지나가고있다.
JWT와 미들웨어를 이용한 회원가입, 로그인, 댓글 수정.삭제 기능을 구현해야하는데
뭔가 알쏭달쏭한것들이 많아 다음주에 좀더 확실하게 개념을 잡아야겠다고 생각중이다.
핵심에 다가간듯 보여도 조금 주변을 돌아보면 모르는것투성이기에 자만하지말고 열심히 달려야한다.
ORM???
심화주차는 이전부터 써오던 몽고DB에서 갑작스럽게 Mysql Sequelize를 다루게 되었다.
새로운 지식을 살펴보기도 전에 빠르게 진도를 나가 정신 없었지만
일단 최대한 기본적 지식을 취한다음 며칠 후에 정리내용을 포스팅해야겠다.
물론 Sequelize는 새로운 데이터 베이스의 이름이 아니라 ORM의 종류중 하나다.
ORM(Object Relational Mapping)’은 ‘객체로 연결을 해준다’는 의미로, 어플리케이션과 데이터베이스 연결 시 SQL언어가 아닌 어플리케이션 개발언어로 데이터베이스를 접근할 수 있게 해주는 툴이다
ORM은 SQL문법 대신 어플리케이션의 개발언어를 그대로 사용할 수 있게 함으로써, 개발시 언어의 일관성과 가독성을 높여준다는 장점을 가지고있다.
왜 Sequelize같은 ORM을 사용하냐 묻냐면 간단하다.
쉽게 설명하자면
MySql, ORACLE과 같은 데이터베이스를 가지고 코딩을 하다보면 당연하게도 클라이언트단에서 서버로 어떠한 데이터를 요청하거나 수정하거나 삭제하거나 등록을 하게된다
이와같은 DBMS(DataBase Management System) 을 사용하게 되면 서버와 클라이언트는 SQL을 보내 통신해야하는데 그때마다 그에 맞는 SQL문을 날려야한다.
즉 프로그램 안에 SQL Query문이 필연적으로 들어가는 상황이 발생하여, 데이터베이스의 변동이 일어날 시, 해당되는 모든 코드들 역시 변경해야하는 많은 작업이 필요해진다.
ORM!!!
그렇기에 이를 좀더 쉽게 도와주는 ORM이 등장하게 된다.
ORM은 객체 지향 프로그래밍에서 객체(Object)와 관계형 데이터베이스의 데이터(Table)을 맵핑시켜준다.
Node.js는 Sequalize라는 대표적 ORM이 있다. 이는 MySQL, PostgreSQL, MariaDB 등 많은 RDBMS를 지원하고 Promise 기반으로 구현되었기 때문에 비동기 로직을 편리하게 작성할 수 있다.
https://sequelize.org/ 에서 자세한 내용을 참고하면 좋겠으나...
아직 배운 지식이 적어 좀더 공부하고 해당 내용을 작성해야겠다.
NoSQL / SQL
여태껏 NodeJs로는 Mongodb와 같은 Nosql을 사용했기에 Sequelize의 존재가 무엇인지도 생각지 않았다.
하지만 나중에 실전 프로젝트에서는 어떤 데이터베이스를 선택할것이냐에 따라 모든것이 달라질수 있기에 많은 생각을 해야겠다.
데이터베이스란 단순히 자신이 어떤 프레임워크냐, 어떤 언어를 선택했느냐에 국한되어 제한된것이 아니라, 어떤 형식의 서비스를 구현할것이냐의 대전제에 달린것이기에...
SQL
대학생활 내내 배운 끔찍하지만 아름다운 친구.
간단한 특징은 다음과 같다.
- 데이터는 정해진 데이터 스키마에 따라 테이블에 저장된다.
- 데이터는 관계를 통해 여러 테이블에 분산된다.
- 각 테이블마다 명확하게 정의된 구조가 있다
- 스키마를 준수하지 않은 레코드는 테이블에 추가할 수 없다
- 데이터의 중복을 피하기 위해 관계(Relationship)를 이용한다
Mysql이나 Oracle 데이터 베이스를 주로 사용했기에 익숙한 친구지만, 현재 내가 선택한 주특기인 Nodejs를 배우면서 계속해서 다루는 데이터베이스는 조금 틀린 친구였다.
NoSQL
말 그대로 정 반대였다.
스키마가 존재하긴 하지만 비유하자면 골격같은 느낌이다.
그 골격위에 올려진 근육량과 구성요소에 따라 사람이라는 특징있는 존재가 만들어지듯, 나중에 새로운 속성을 마음대로 추가하거나 삭제할 수 있다.
즉 스키마도 없고, 관계도 없다
NoSQL에서는 레코드를 문서(documents) 라고 부른다.
앞서 말한것처럼 SQL은 정해진 스키마를 따르지 않으면 데이터 추가가 불가능하지만,
NoSQL에서는 다른 구조의 데이터를 같은 컬렉션에 추가가 가능하다.
위의 그림과 같이
SQL은 하나의 거대한 구조안에, 정해진 규약을 지키는 수직적인 데이터베이스 이고
NoSQL은 그저 넓은 공간에, 자유롭게 데이터가 뛰어다니는 수평적 데이터베이스다
그렇다면 실전에서는?
실전에서는 어떤 서비스냐에 따라 데이터베이스의 종류를 잘 선택해야할것이다. 따라서 정리하면 다음과 같다.
SQL의 장점:
- 명확하게 스키마가 정의되어 데이터의 무결성을 보장해준다.
- 관계는 각 데이터를 중복없이 하나의 규약으로 묶어줄수있다.
SQL의 단점:
- 처음 설계시 최대한 완벽하게 구현해야 나중에 구현하기가 쉽다.
- Join문이 많아질수록 성능이 하락할수 있으며, 그에 따라 Query의 깊이와 양이 많아진다.
NoSQL의 장점:
- 유연하게 언제든 데이터에 새로운 속성을 추가하거나 삭제할 수 있다.
- 요청한 데이터를 원하는 형태로 가공하여 가져올 수 있기에 데이터를 로드하는 속도가 빠른 편이다.
- 구현에 따라 수직적(Subdocument)확장도 가능하기에 상황에 맞게 조정할 수 있다.
NoSQL의 단점:
- 유연성의 단점으로 인해, 새로운 속성들을 계속해서 추가해나가서 데이터베이스의 완성이 힘들어 질 수 있다.
- 데이터가 여러 컬렉션에 중복되어 있기 때문에 수정 시 해당 데이터가 필요한 컬렉션 모두를 수정해야한다.
따라서 관계를 맺고 있는 데이터가 자주 변경되는 서비스를 구현할 경우 혹은 명확한 스키마구현이 매우 중요한 서비스를 구현할때는 SQL이 유용하고,
데이터를 읽어 들이는 요청은 많으나 변경 요청은 적은 서비스, 많은 양의 데이터를 다루어야하는 서비스, 정확하게 데이터의 스키마를 정의할수 없을 경우에는 NoSQL이 유용할 것이다.
한주를 돌아보며
새로운 주가 시작되었고, 관계자 분이 내 과제를 좋게 평가해 주셔서 감히 다른 분들에게 코드를 설명 할 수 있는 기회를 얻었다.
덕분에 발표를 하는 내내 미처 내가 생각하지 못했던 부분도 알게 되었고, 새로운 심화과제 강의를 보며, 새로운 배움에 대해 감탄하게 되었다.
프론트 단에서의 JWT, 백엔드단에서의 JWT는 요청과 생성은 비슷해보였으나 실상은 많은 미묘한 차이점이 느껴졋다.
좀더 코드를 분해하여 내것으로 만들고 과제를 마친후 빨리 포스팅을 하고싶다...
휘발성의 기억을 이곳에 빨리 새기고싶다.
