2022.06.05 WIL / 회고록

Seong Hyeon Kim·2022년 6월 5일
ORMWILnosqlsql항해99
0

항해99

목록 보기
6/16

ORM(Object Relational Mapping)

ORM(Object Relational Mapping)이란, 객체지향 패러다임을 이용하여 데이터베이스로부터 데이터를 쿼리하고 조작할 수 있도록 해주는 기술이다.

즉, 객체와 데이터베이스를 연결(매핑)해주는 역할을 한다.

ORM에 대해서 말할 때, 대부분의 사람들은 ORM 기술을 구현하는 '하나의' 라이브러리를 지칭하고 있는 것이다. 그러므로 '하나의' ORM('an' ORM)으로 표현하는 것이다.

ORM 라이브러리는 우리가 사용하는 언어로 쓰인 완전히 평범한 라이브러리로, 데이터를 조작하기 위해 필요한 코드를 캡슐화 하고 있기 때문에 데이터를 조작하기 위해 더 이상 SQL 쿼리문을 사용하지 않아도 된다.

우리가 사용하고 있는 그 언어를 통해서 객체와 직접적으로 상호작용하게 되는 것이다. SQL 쿼리문 작성의 기술적인 부분은 ORM 라이브러리가 맡아준다.

ORM을 쓰면 좋은 이유

1) 시간을 많이 절약할 수 있다

중복 배제(Don't Repeat Yourself; DRY): 우리는 데이터 모델을 오직 한 곳에서만 작성하게 되고, 이는 코드의 유지보수와 재사용을 보다 쉽게 한다.
DB 핸들링부터 국제화와 현지화(i18N)까지 많은 일들이 자동적으로 처리된다
ORM은 우리가 MVC 코드를 쓰도록 강제하고, 이는 결국 우리의 코드를 조금 더 클린하게 만든다.
SQL문을 형편없이 작성할 필요가 없다.

  • 대부분의 웹 프로그래머들은 SQL문 작성에 젬병이라고 한다. 이는 SQL이 마치 "서브" 언어처럼 다뤄지기 때문인데, 사실 SQL은 굉장히 강력하고 복잡한 언어이다.
    코드를 무해하게 만들어 준다(Sanitazation): 미리 준비된 표현이나 트랜잭션은 메소드를 호출하는 것만큼이나 쉽다.
  • 참고로 Sanitization은 형식은 올바르지만, 실제로 DB에 전달되어 실행될 때 DB에 악영향을 미칠 수 있는 내용이 inject 되어 있는 경우 이를 걸러내는 작업과 같이, 코드를 '무해'하게 하는, 즉 코드에 대한 위생처리라고 할 수 있다.
  • 이와 달리, Validation은 사용자의 입력이 올바른 '형식'으로 되어 있는지를 확인하는 작업이다.

2) 더 유연하다

우리가 코딩하는 자연스러운 방식에 잘 맞는다(원래 주로 사용하는 언어로!)
DB 시스템을 추상화하기 때문에 언제든 우리가 원할 때 변경할 수 있다.
모델이 애플리케이션의 나머지 부분에 느슨하게 묶여있기 때문에, 다른 어디서든 이를 변경하거나 사용할 수 있다.
데이터 상속과 같은 객체 지향 프로그래밍의 장점을 이용할 수 있게 해준다.
하지만 ORM이 고통이 될 수도 있는 이유
일단 배워야 하고, 세팅해야 한다. ORM 라이브러리들은 가벼운 툴이 아니다.
일반적인 쿼리들의 경우 성능이 괜찮은 수준이지만, 큰 프로젝트에서는 직접 SQL 문을 작성하는 SQL 마스터가 항상 더 나을 것이다.
ORM은 DB를 추상화한다.

  • 그 이면에서 어떤 일들이 일어나는지를 알고 있다면 괜찮지만, 굉장히 탐욕적인 표현들을 작성할 수 있는 프로그래밍 입문자들에게는 함정이 될 수 있다.

SQL

SQL 은 Structured Query Language의 약자로 말그대로 구조적인 쿼리 언어로 관계형 데이터베이스를 제어하는 언어이다.

관계형 데이터베이스 (RDBMS)

SQL을 통해 데이터를 제어한다.

특징

  • 데이터는 정해진 데이터 스키마(=structure)에 따라 테이블에 저장된다.
  • 데이터는 관계를 통해 여러 테이블에 분산된다.

1. 정해진 데이터 스키마

  • 각 Table에는 명확하게 정의된 Structure(스키마)가 존재한다.

  • 그리고 데이터는 Table에 Record로 저장이 된다.

  • 여기서, Structure(스키마)를 지키지 않는 Record는 절대절대 테이블에 들어갈 수 없다.

2. 관계

  • 관계형 데이터베이스답게 관계가 중요하다.

  • 관계란 테이블들을 서로 관계가 있는 테이블들을 연관지어 잇는 것이다.

  • 만약 Product(쇼핑 상품들), Orders(주문한 상품들), Users(사용자)가 존재한다면, 각각의 테이블들은 관계를 지어서 생각해야 한다.

3. 장점

명확하게 정의된 스키마, 데이터 무결성 보장
관계는 각 데이터를 중복없이 한 번만 저장된다.

4. 단점

  • 덜 유연하다. 데이터 스키마는 사전에 계획되어야 하기에 수정하기가 번거롭다.

  • 관계를 맺고 있기 때문에, Join문이 많은 매우 복잡한 쿼리가 만들어질 수 있다.

  • 수평적 확장이 어렵고, 대체로 수직적 확장만 가능하다.

  • 사용하는 시기

  • 관계를 맺고 있는 데이터가 자주 변경되는 경우에 사용한다.
    명확한 스키마가 사용자와 데이터에게 중요한 경우

NoSQL

  • NOSQL 은 SQL과 반대되는 접근방식이기 때문에 이름이 NoSQL이다. 말그대로 비관계형 데이터베이스이다.

특징

  • 스키마 없음
  • 관계 없음
  • 특징도 SQL과 반대되는 특징이다.

1. 스키마가 없으면 어떤 형식으로?

이걸 알려면 NoSQL의 구조를 알아야 한다.
먼저 DB - Collections - Document형식으로 되어있다.

  • Collections : 우리가 RDBMS에서 알던 Table인데 Structure가 없는 Table

  • Document : RDBMS에서 Records

  • Document는 JSON데이터와 비슷한 형식으로 구성되어있다.

  • 실수로 Orders 컬렉션에서 User의 데이터를 수정한다면 자동으로 Users컬렉션에도 반영이 되는 원치않는 데이터가 될 수 있다.

장점

  • 스키마가 없기 때문에 유연하다.

  • 데이터는 필요로 하는 형식으로 저장이 된다. 그렇기에 데이터를 읽어오는 속도가 빨라진다.

  • 수직 및 수평적 확장에 용이하다.

단점

  • 유연성 때문에, 데이터 구조를 결정하기 힘들다.

  • 데이터 중복은 문서(레코드)가 변경된 경우 그와 관련된 문서를 갖고 있는 컬렉션을 찾아 하나하나 업데이트를 해줘야 한다.

  • 사용하는 시기

  • 정확한 데이터 구조가 정해지지 않은 경우, 변경/확장이 될 수 있는 경우

  • 읽기는 자주 하지만, 변경이 잦지 않는 경우

  • 막대한 양의 트래픽을 다뤄야 하는 경우 => 수평적 확장에 용이하기에

수직적(Vertical) & 수평적(Horizontal) & 확장(Scaling)

NoSQL에서 확장이 쉽다고 했다. DB를 어떤식으로 확장을 시켜야 하는 걸까?
확장에는 수직적(Vertical) 확장과 수평적(horizontal) 확장이 있다.

수직적 확장

  • "Scale up방식으로 확장한다." 라고도 한다.말 그대로 DB서버의 성능을 확장 시키는 것입니다. DB서버에 CPU를 더 좋은 것으로 바꾸는 원초적인 방식이다.

  • 성능 확장에 한계가 존재하고, 성능 증가에 대한 비용 증가폭이 매우 크다.
    SQL, NoSQL 둘 다 가능한 방식입니다.

수평적 확장

_ "Scale out방식으로 확장한다." 라고도 한다. 서버를 여러대 만들어서 확장하는 것이다.

  • 각 서버에 걸리는 부하를 균등하게 해주는 로드밸런싱이 필수적으로 동반된다.
  • 서버가 여러대가 있기 때문에 한 대가 장애로 다운되어도 다른 서버로 서비스 제공이 가능하다는 장점이 있다.
  • SQL도 가능하지만, 매우 어렵고 비용이 많이 발생한다.
  • 하지만 NoSQL은 이러한 수평적 확장을 기반으로 만들어졌기 때문에 쉽게 확장이 가능하다.

출처 : https://velog.io/@jeong-god/SQL%EA%B3%BC-NoSQL%EC%9D%98-%EC%B0%A8%EC%9D%B4

회고록

Chapter 3-2에서 스스로 가장 많이 성장했다고 느낀 부분이 있다면 자유롭게 적어주세요.

영성님을 비롯한 다른 조원들의 도움을 많이 받긴 했지만, api에 대한 이해도가 조금 더 올라갔고 새롭게 배운 router 작성시 사용하는 middelware를 이용해서 토큰값을 받아서 특정한 값이 있을때 사용할 수 있는 댓글쓰기 댓글삭제 등등 특별한 기능구현등을 제 스스로 많이 해봤다는 점이 저에게 잇어서는 가장 큰 성장이였던 것 같습니다.
알고리즘 주차는 10단계중 2-3 단계까지의 내용을 습득한 느낌이라면,
이번주차는 그래도 8-9단계 까지의 내용을 습득한 느낌이라서 좀더 지식도 풍부해지고 할 수 있는게 늘어났고 조금씩이라도 쓰던 TIL 을 통해서 내가 어떤 것을 배웠고 어떤것을 할 수 있게 되었구나라는 것들을 정리할 수 잇어서 더욱 좋았던 시간이였습니다.

Chapter 3-2에서 스스로 더 많이 성장하기 위해, 어떤 노력을 더 할 수 있었을까요?

기능 구현을 할때 좀 더 추가할만한 기능들이 많았었지만, 아무래도 시간적인 여유가 없어서 좀더 풍부한 기능구현을 하지 못한게 조금 아쉬웠던 것 같습니다.
개인 과제의 기능구현을 우선순위로 생각하다보니 충분히 할 수 있었을것 같아도 완성도를 위해서
피해야 했던 추가적인 기능 구현들을 다 하지 못하고 마무리한게 조금 아쉬웠던 것 같습니다.

그 외에도 깃이나 스스로 부족하다고 여긴것들을 공부해서 좀더 채울 시간이 있었더라면 좋았을텐데 개인과제의 완성을 위해서 시간들을 많이 소모하느라 채우지 못한게 조금 아쉽습니다.

profile
Seong Hyeon Kim
삽질도 100번 하면 요령이 생긴다. 부족한 건 경험으로 채우는 백엔드 개발자
이전 포스트

항해톡 발표 - 프로세스 & 스레드 (Process & Thread)

다음 포스트

2022.06.22 - WIL [클론 코딩을 마치며]

0개의 댓글