나는 책을 정말 좋아한다. 아니 정확하게 말하면 텍스트 매체 자체를 사랑한다.
그러다보니 디지털화가 되어있는 전자책보다도 무겁고 보관도 불편하지만 종이 책을 좋아한다.
누군가는 멍청하다고 이야기를 할 수도 있겠지만 종이 책을 한장 한장 넘기는 그 소리가 난 너무 좋다.
책에는 누군가가 반복된 고민 끝에 집약되어있는 정보들이 모여있다.
보는 사람들이 편하게 읽을 수 있도록 맨 앞에는 대주제를 필두로 소주제와 함께 목차가 나와있고
키워드를 더 쉽게 찾기 위하여 맨 뒤에는 단어에 대하여 어떤 페이지에 적혀있는지 나와있는 페이지도 존재한다.
무언가를 찾기 위하여 정보의 바다인 인터넷에서 헤매는 것보다
내가 알고 싶은 정보를 찾기 위하여 영상을 훑어봐야하는 영상매체보다
컨트롤 F 혹은 책갈피로 찾아갈 수 있는 책이라는 매체를 좋아한다.
그 덕분에 어렸을 때 꿈이 사서였던 적도 있었다.
혹은 책에 둘러쌓인 방에서 책을 읽어나가면서 지식을 쌓아가고 싶다는 상상도 했던 적이 있었다.
데이터베이스 (database)란?
일반인도 많이 들어볼 법 한 명칭이 바로 데이터베이스라고 생각한다. 흔히 DB, 디비라고도 많이 부른다.
데이터베이스란 다양한 데이터들이 들어가있는 데이터의 집합체라고 생각할 수 있다.
즉, 책도 한개의 데이터베이스라고도 부를 수 있을 것이다.
- 회원가입을 위해 정보를 입력한 것들이 저장되는 공간
- 내가 하는 게임에서 내 캐릭터의 정보가 저장되는 공간
- 카톡의 채팅방 속 대화가 저장되는 공간
이 모든 것이 데이터베이스다.
그리고 정보 가 담겨있기 때문에 그만큼 조심스럽고, 안전하게 다뤄야만 하는 것이기도 하다.
(뭐 개인정보를 워낙 털려서 내 주민등록번호 10원이라고 하던데)
그리고 이러한 데이터베이스는 결국은 두가지의 분류로 나눠지게 되는데, 먼저 DBMS와 RDMBS에 대해서 살짝만 맛보자.
RDBMS (Relational Database Management system)란?
- 용어 정리
- DBMS : 데이터베이스 관리 시스템
- RDBMS : 관계형 데이터베이스 관리 시스템
그리고 지금에 와서는 DBMS(Database Management system)라는 것이 생기면서
다양한 종류의 DBMS가 나왔지만 대부분 사장되었고 이 시점에서 제일 많이 사용하고 있는 것은 RDBMS이다.
그리고 RDBMS를 제일 쉽게 이해를 하는 방법이 존재하는데, 그것은 회사업무에서 많이 쓰이는 엑셀이다.
세로 줄을 행(row)라고 부르며, 가로 줄을 열(column)이라고 부르는데
1번 열(column)에 적혀있는 내용을 보면 API 상위 카테고리, API 이름, API 명세, 토큰여부, 리턴타입이 명시되어있는 것을 확인할 수 있다.
이것을 보통 컬럼명 이라는 이름으로 부르게 된다.
그리고 컬럼명이 존재하는 것만 데이터를 담을 수 있고
2번열을 확인하면 각 컬럼명이 한개씩 들어가있는 것을 볼 수 있는데, 이것이 결국 한개의 데이터가 된다.
조금 더 쉬운 이해를 하기 위해서 우리가 익숙한 표를 하나 만들어봤다.
| 치킨 브랜드 | 치킨 이름 | 가격 |
|---|---|---|
| BBQ | 황금올리브 | 22000원 |
| BHC | 뿌링클 | 20000원 |
| 치킨매니아 | 왕새우치킨 | 19000원 |
| 후라이드참잘하는집 | 후라이드치킨 | 13000원 |
| BBQ | 자메이카통다리 | 21000원 |
| ...중략 | ...중략 | ...중략 |
(가격은 틀릴 수 있습니다..^^)
이렇게 데이터가 컬럼명에 맞게 들어간 형태를 테이블이라고 부르며 치킨의 테이블이라고도 이야기를 할 수 있다.
이런 데이터베이스에 데이터를 생성 조회 수정 삭제를 하기 위해서는 그것을 다루는 무언가가 필요할 것이다.
그리고 이것을 SQL이라고 부른다.
SQL(Structured Query Language)
SQL은 RDBMS에서 디비에 접근하여 조회 생성 수정 삭제 같은 작업을 하기 위해 사용되는 언어다.
관계형 데이터베이스에는 중요한 두가지의 특징이 존재한다.
- 데이터는 정해진 스키마(형식)에 따라 테이블에 저장된다.
- 데이터는 관계를 통해 여러개의 테이블에 분산되어 저장된다.
첫번째는 치킨 브랜드라는 테이블에는 문자만 적히라고 지정을 해놨으면 숫자는 못들어간다는 것이다.
그렇기 때문에 처음에 지정을 해놓고 데이터가 많이 쌓인 후에 변경하려고 하면 정말 머리가 폭발하는 것을 확인할 수 있다(....)
그래서 처음 짤 때 정말 신중하게 짜고 시작해야한다.
확장성을 고려해서 짜는 것도 방법이라곤 하는데 그렇게 멀리 볼 수 있나....?
두번째는 관계가 존재할 경우 새로운 열이 다양한 테이블에 저장된다는 것이다.
말이 어려운데 풀어서 이야기하면 이렇게 된다.
내(User)가 존재하는데 주문조회(Order)를 할 수 있다고 생각해보자.
나는 한명만 존재하지만, 치킨을 여러번 주문해먹을 수 있을 것이다.
그리고 주문내역을 확인하기 위해서는 이러한 형식의 데이터가 필요할 것이다
- yukina1418은 BBQ에서 황올을 2022년 6월 19일 10시에 시켜먹었다.
- yukina1418은 BBQ에서 황올을 2022년 6월 20일 11시에 시켜먹었다.
- yukina1418은 BBQ에서 황올을 2022년 6월 21일 11시에 시켜먹었다.
(비비큐 홍보 아닙니다 저희쪽 매장 별로임)
이렇게 될 경우 유저와 치킨이 서로 의존하게 되는데, 이것을 관계(Relation)라고 부른다.
그리고 이러한 정보는 새로운 테이블로 빠져서 데이터가 저장된다.
하지만 이렇게 새로운 테이블로 빠진다면 정보를 받아오는 것이 상당히 불편할 것이다.
한명이 치킨을 1000번 시켜먹었다면 1000개의 줄을 불러와야 할텐데
불러오는 1000개의 줄에는 유저정보와 치킨의 정보가 중복되기 때문이다.
그래서 이러한 것을 한 줄로 만들어주는 SQL 쿼리가 존재하고
관계가 없던 것을 새롭게 Join(관계형성)을 시켜주는 SQL 쿼리 또한 존재한다.
그래서 RDBMS에서는 SQL 쿼리를 배우는 것이 정말 중요하다.
과거에는 정말 생 쿼리를 사용해야했지만 요즘에는 ORM같은 것들이 생겨나면서 접근성이 상당히 좋아졌다고 생각한다.
대표적으로는 TypeORM, Sequelize, Prisma 같은 것들이 있다.
ORM이 뭐길래 쓰나요? : [DB] ORM (Object Relational Mapping) 사용 이유, 장단점
RDBMS의 대표격인 DB들
이런 RDBMS에도 다양한 DB가 존재하는데 대표적으로 많이 사용되고 있는 것들은 4개정도가 있다고 생각한다.
- Oracle
- MySQL
- PostgreSQL
- Maria DB
결국은 한개에서 파생된 SQL문이 존재하기에 한개를 다룰 줄 안다면 대부분은 다룰 수 있게 된다.
하.지.만 각 DB마다의 특성이 약간씩 차이가 존재해서 새로운 문법을 배울 수 밖에 없다는 문제도 있다.
아무튼 위의 RDBMS의 특징에 단점이 부각되는 점이 많았고
관계가 없는 형태로 데이터를 담아야할 필요성을 느낀 개발자들은 새로운 것을 만들어냈다.
(정말 없으면 다 만드는구나)
NoSQL
SQL을 사용하지 않아서 NoSQL이라고 부른다고 알고 있는데
이렇게 부르는 명칭에 대해서도 뭔가 논쟁이 있다고 들었다. (자세히 알아보진 못했다.)
SQL이 없다는 것은 DB에 데이터를 넣는 것에 특별한 제약이 없다는 것과 다름없다.
그래서 타입을 지정하는 스키마도 존재하지 않고 테이블과 테이블 사이의 관계도 존재하지 않는다.
SQL같은 경우에는 데이터가 매핑되어있는 레코드가 테이블(Table) 이라는 이름을 사용하는 것에 반하여
NoSQL같은 경우에는 문서(Documents) 이라고 부른다.
위의 사진을 보면 조금 더 구체화시킬 수 있는데 NoSQL은 말그대로 문서라서 자유롭게 데이터를 넣을 수 있다.
또, 형식이 존재하지 않는다는 장점을 이용하여 필요한 데이터만을 넣을 수 있기 때문에 장점이 있다.
이러한 이유로 흔히 말하는 블록체인이나 NFT같이 유일한 정보임을 알리는 데이터를 구현할 때 NoSQL로 LinkedList의 형태를 만들어서
거래가 있으면 전에 가지고 있던 데이터 + 구매한 유저의 데이터 이런식으로 유일한 것임을 증명한다고 알고만 있다. (분산 DB?)
그래서 최근에 블록체인 시장이 상당히 커지면서 NoSQL에서 대표주자이자 오픈소스인 MongoDB의 인기가 정말 뜨거운 것 같다.
그래서 뭘 쓰는게 좋은데?
SQL과 NoSQL은 서로 다른 역할이 가지고 있기 때문에, 이게 좋아! 라고 말하는 것은 어렵다.
이 차이를 알기 전에 약간의 상식으로 한가지를 더 알아둬야할 것이 있다.
바로 확장성이라는 개념이다.
확장성 (Scalability)
확장성이란 바로 DB서버의 성능의 향상을 하는 방법에 대한 이야기라고 할 수 있다. (다양한 방면에서 활용되는 단어긴 하다.)
첫번째는 서버 자체의 성능을 향상시키는 방법이다, 수직적 확장이라고도 부른다.
게임을 하는 사람이라면 이해가 빠를텐데, 내가 지금 VGA를 1080TI를 사용하고 있다.
그런데 프레임이 밀리는 것 같아서 3080TI를 사서 낌으로써 프레임이 밀리는 것을 방지할 수 있게 된 것과도 같다.
두번째는 서버의 개수를 늘리는 방법이다, 수평적 확장이라고도 부른다.
이것도 똑같이 컴퓨터로 비유를 하자면 갑자기 8K를 지원하는 모니터가 나왔다고 한다.
하지만 3080TI 한개만으로는 10프레임도 안나와서 3080TI를 4개를 사용하면서 해결을 했다. (4개가 꽂히긴하던가?)
그럼 이제 확장성이 어떤 것인지 알게 되었으니 SQL과 NoSQL의 차이를 알아보자.
SQL의 장점
- 고정적인 스키마, ACID로 인한 트랜잭션 및 데이터 무결성 보장
- 관계의 경우 중복 없이 한번만 저장(테이블 한개를 할당해서)
SQL의 단점
- 고정적인 스키마로 인한 변환 작업의 어려움. (추가 수정 삭제 전부 다 복잡함)
- 관계가 엄청 많아질 경우 SQL 쿼리의 복잡도 +++++
- 수직적 확장만 가능하다. 샤딩이라는 개념이 있긴 하지만 구현하는 것이 매-우 어렵다.
ACID에 대한 설명은 여기서 볼 수 있다 => https://velog.io/@yukina1418/Transaction
SQL은 데이터끼리간의 관계가 존재하기 때문에 DB서버를 한개 더 사온다고 해서 해결이 되지 않는다.
그래서 성능만 향상시킬 수 있는 수직적 확장만 가능하다는 것이 큰 단점이다. (슈퍼컴으로도 해결이 안되면 거기서 끝)
NoSQL의 장점
- 스키마가 없는 것으로 인한 유연성, 자유로운 추가 수정 삭제가 가능하다.
- 필요한 데이터만을 저장할 수 있기에 데이터를 읽어오는 속도가 상대적으로 빠르다.
- SQL과는 다르게 수직적 수평적 확장이 모두 가능하기 때문에 업그레이드를 하는 것이 용이하다.
NoSQL의 단점
- 데이터 중복에 대한 업데이트를 계속 해야한다.
- SQL에서 관계를 형성한 것처럼 만들기 위해서는 만약 1개가 업데이트 되었다면 모조리 관련된 데이터를 전부 다 바꿔줘야한다.
결론
- SQL
- 스키마가 고정적일때, 데이터 무결성이 필요할 때, 업데이트가 자주 필요할 경우
- NoSQL
- 스키마가 불규칙할때, 데이터가 중복되어도 상관없을 때, 업데이트가 필요 없고 읽기와 쓰기가 중요한 상황의 경우
이러한 차이가 있어서 정말 뭐가 좋다! 는 모르겠고 그냥 둘 다 섞어서 쓸 줄 아는 사람이 되는게 최고라고 생각한다(...)
막간의 Elasticsearch와 NoSQL의 차이
보통 이렇게 쓰는 사람은 없는데 걍 써보고 싶었다.
Elasticsearch는 현재 서비스되고 있는 검색엔진의 대표주자다.
엘라스틱서치는 NoSQL과도 같은 모양을 하고 있어서 데이터를 마음대로 넣을 수도 있다(템플릿이 엉망일 순 있겠지만)
하지만 NoSQL과는 약간의 차이가 존재한다.
바로 역인덱싱이라는 것을 지원해서 자신이 원하는 모양으로 데이터를 잘라서 토큰화를 시킨 후 그것으로 데이터를 불러올 수 있기 때문이다.
디폴트값으로는 공백을 기준으로 분리를 해서 보통 아래와 같이 책장의 맨 뒷부분처럼 나눈다고들 설명을 한다.
만약 엘라스틱서치에 대해 궁금한 점이 생긴다면 역인덱싱과 엘라스틱서치에 대해서 검색하면 된다!
글 끝!
