코린이형준

기술스택 선정

시작전, 기술스택에 관하여 알아보던중 django, AWS정도만 결정했음 된거 아냐? 라고 생각했는데 구글링을 하다보니 그게 아니였다... 클라우드 서버, 웹 서버, 웹 프레임워크, 데이터베이스 이렇게 크게 4가지를 결정해야 했다.

-클라우드 서버

AWS vs GCP 여기서 결정을 해야했다. 전세계적으로 인지도 AWS승! 서버다운 시간 AWS승! 성능은 무승부!(성능의 판단요소가 너무 많다.) 사실상 뭐든 클라우드 서버 특성상 비슷하기 때문에 많이쓰는 AWS를 써보자 라고 결정했다. GCP같은경우는 나중에 경험해 보기로ㅎㅎ

-웹 서버

사실 이부분이 가장 어려웠다. 왜냐! 장고는 python manage.py runserver만 입력하게 되면 이미 웹서버를 구동시켰고 따로 웹서버가 필요 한걸까? 라는 생각을했다. 자세히 알아보니 장고 github를 통해 힌트를 얻을수 있었다.

HTTP server that implements the Python WSGI protocol (PEP 333, rev 1.21).
Based on wsgiref.simple_server which is part of the standard library since 2.5.
This is a simple server for use in testing or debugging Django apps. It hasn't
been reviewed for security issues. DON'T USE IT FOR PRODUCTION USE!

해당 runserver는 보안 이슈에 대해 체크 하지 않았으면 배포용으로 사용하지 말라고 경고 하고 있습니다. 즉, runserver를 통해 실행되는것은 테스트 용으로만 사용하라는 뜻이였습니다.

그래서 알아본 결과 apache, NginX를 알게 되었습니다.

-apache

아파치는 가장 전톡적인 웹서버이며, 이에따라 웹서버 점유율또한 다른것들과 비교불가능한 독보적인 프로그램입니다. 클라이언트의 요청하나당 스레드 하나가 처리하는 구조이기 때문에 메모리와 cpu소비량이 많습니다. 하지만 점유율과 역사가 있다보니 제공되는 모듈도 많고 호환성과 안정성이 뛰어납니다.

-NginX(엔진엑스)

만년 2등의 포지션이지만 현재 신흥강자로 취급받고 있습니다. 비동기 이벤트 기반으로 요청을 처리하며 무엇보다 아파치보다 효율적으로 요청을 처리할 수 있는 아키텍쳐입니다. 

-웹 프레임워크

Django, Django restfreamwork를 사용하기로 하였습니다. spring, express.js와 같은 프레임워크이 선택지또한 있긴하지만 현재로서는 저 포함 팀원이 익숙하게 사용가능한 웹프레임워크는 django라서 선택하게 되었습니다.

-데이터베이스

ORM을 사용하는 django의 특성상 RDMS를 사용하는것이 적절한데 선택지는 크게 Postgersql, Mysql 2가지였다. 

-Postgresql

• 오픈소스로 무료로 사용 가능하다.
• 다양한 join방법을 제공한다.
  • nested loop join, hash join, sort merge join등
• update를 할때 과거행 삭제후 변경된 데이터를 가진 새로운 행을 추가하는 형태라서 update가 느리다.
• 처리속도를 빠르게 하기 위해 여러 cpu를 활용한 쿼리를 실행한다.

-MYSQL

• update기능이 postgresql보다 우수하다.
• nested loop join기능이 postgre보다 우수하다.
• 문자열 비교에서 대소 문자를 구분하지 않는다.
• 간단한 처리 속도를 향상시키는것을 추구한다.

등의 2가지 sql의 특장점이 있는데 결론적으로 간단한 동작을 구현하는 서비스- mysql, 복잡한 쿼리를 요구하고 insert위주의 대규모 서비스인 경우 Postgresql이라는 결론이다. 우리가 만들 서비스가 복잡하지는 않겠지만 새로운것에 대한 초점을 맞췄을때 Postgresql을 사용하여 프로젝트를 진행하기로 결정하였다.

+) redis

-캐시의 필요성

캐시는 필수가 아닌 선택이다. 기본적으로 서비스는 WEB-WAS-DB의 3구조를 띄고 있는데 사용자가 늘어나게 되면 DB에 무리가 가기 시작한다. 데이터베이스는 물리 디스크를 직접 쓰기 때문에 서버에문제가 발생하여 죽더라도 데이터가 손상되지는 않지만 매 요청마다 물리 디스크에 접근해야 하기 대문에 부하가 상당히 많아진다.

이때, DB서버의 부담을 덜어주기위해 등장한것이 캐시서버의 도입인데 캐시는 한번 읽어온 데이터를 임의의 공간에 저장하여 다음에 읽을 때는 빠르게 결과값을 받을 수 있도록 도와주는 공간이다. 같은 요청이 여러번 들어오면 캐시서버에서 바로 결과 값을 반환해주기 때문에 DB부하를 줄일수 있음과 동시에 속도또한 빨라지게된다.

물론, 캐시서버는 물리디스크가 아닌 주로 메모리를 사용하기 때문에 속도가 빨라지는 장점의 이면에 서버에 장애가 날경우 메모리가 날아갈수 있는 단점이 존재한다. 그렇더라도 캐시는 거의 필수적으로 알아야하는 개념이기와 캐시서버로 널리 쓰이고 있는 redis에 대해 알아봐야한다.

-redis란?

redis는 키-값으로 이뤄진 캐시시스템으로

• List, Set, Sorted Set, Hash등과 같은 collection지원
• Race Condition에 빠질수 있는것을 방지
  • Single Thred기때문에 Atomic보장
• 캐시의 단점을 커버할수 있는 persistance를 지원하여 서버가 꺼지더라도 다시 데이터를 불러들일수 있음

위와 같은 기능과 장점이 있다. 즉, redis는 다시말해 하나의 캐시시스템이며 우리가 사용할 postgre를 도와주는 역할 정도로 이해할수 있다. 캐싱을 전체에 적용하기보단 간단한 로직에 선택적으로 도입하는것이 적절할것으로 판단된다.

django-redis 사용법

-firebase

firebase는 채팅앱을 구현할때 사용하려고 한다. socket형식의 realtime db로 구현을 해야하는것인데 이러한 어려움을 쉽게 해결해주는것이 firebase이다. 기본적으로 서버에 채팅서버db만 따로 빼놨다고 생각할수 있는것 같은데 이것같은경우는 백엔드단에서 처리도 가능하겠지만 프론트단에서 전부 처리하는것이 편리해보인다. 

1. MYSQL설치

다운로드 방법에 대해서는 

이블로그에 자세히 설명되어 있으므로 참고하면 될듯하다.

2. 실행

다운로드를 모두 받고 나면 실행방법은 총 2가지가 존재한다.

-cmd창

시작메뉴의 cmd창을 켠후 해당 디렉터리로 이동해야하므로

cd C:\Program Files\MySQL\MySQL Server 8.0\bin 입력하여 실행해준다(위블로그대로 했다면 문제없이 진행될거다.  만약 되지않는다면 경로상의 문제이므로 직접 위치를 찾아서 경로를 설정해주면 된다.)

그후 mysql -u계정명 -p 를 입력하면 다운로드하면서 설정한 비밀번호를 입력해주면 클라이언트를 실행할수있다.

-직접 실행

필자는 이방법을 많이 사용한다.(편하기때문)

시작 메뉴에서 클라이언트를 클릭해 직접실행하는방식이다. 방법설명은 따로없다 이미지를 참고하자.

이제 모두 다운로드및 실행방법을 알아봤으니 다음부터 제대로 실습을 시작해보면 되겠다.

1. 데이터베이스에있어 KEY란?

MYSQL과 같은 관계형 데이터베이스에는 중요한 키라는 것이 존재한다.

  여러 종류 키에 관해 설명하기전, 릴레이션(realation)에 관해 간단히 정리하자면 같은 성격의 데이터들의 집합을 의미하며 릴레이션은 각행을 의미하는 튜플(tuple)과 이름을 가진 하나의 열을 말하는 에트리뷰트(attribute)로 데이터를 정렬하여 관리한다.

  이러한 릴레이션의 특징 중 이번 과제와 관련이 있는 키(key)가 있는데 키란, 릴레이션을 구성하는 튜플을 고유하게 식별할 수 있는 하나 이상의 애트리뷰트들의 모임을 뜻한다. 키의 종류는 수퍼키(super key), 후보키(candidate key), 기본키(primary key), 대체키(alternate key), 외래키(foreign key)로 총 5가지가 있다.

  첫번째, 수퍼키는 한 릴레이션 내의 특정 튜플을 고유하게 식별하는 애트리뷰트 또는 애트리뷰트들의 집합으로, 예를 들어 회사의 사원의 릴레이션에서 사원번호+이름 또는 사원번호가 수퍼키가 될 수 있다. 하지만 이러한 수퍼키는 투플들을 고유하게 식별하는데 꼭 필요하지 않은 애트리뷰트들을 포함할 수 있다는 점이 있다.

  두번째, 후보키는 각 튜플을 고유하게 식별하는 최소한의 애트리뷰트들의 모임으로 사원번호는 사원 릴레이션의 후보 키가 되지만 사원번호+이름은 사원 릴레이션의 후보키가 아니다. 따라서, 후보키는 유일성만 만족하는 슈퍼키와는 다르게 유일성, 최소성을 모두 만족해야 하며 모든 릴레이션에는 최소 한 개 이상의 후보 키가 있고 후보키는 두개 이상의 복합 애트리뷰트로 이루어 질 수가 있다.

  세번째, 기본키는 한 릴레이션에 후보 키가 두 개 이상 있으면 설계자 또는 데이터베이스 관리자가 이들 중에서 하나를 기본 키로 선정하는 것으로, 사원 릴레이션에서 사원번호와 이메일 주소가 후보키가 될 수 있는데 관리자의 임의로 사원번호를 기본키로 선정할 수 있다. 만약 한 릴레이션에서 기본키를 찾을 수 없는 경우에는 레코드 번호와 같이 종종 인위적인 키 애트리뷰트를 릴레이션에 추가할 수 있으며, 기본 키로 지정된 애트리뷰트들은 모든 튜플에 대해 널(null)값을 가질 수가 없다. 따라서, 기본키는 후보키가 만족해야 하는 유일성, 최소성 뿐만 아니라 값에 대해 not null또한 만족하여야 한다.

  네번째, 대체키는 간단하게 기본키가 아닌 후보키로 관리자가 사원번호와 이메일 주소 중에 사원번호를 기본 키로 선정하면 이메일 주소가 대체키가 되는 것이다.

  마지막, 외래키는 다른 릴레이션의 기본키를 참조하는 애트리뷰트이며 릴레이션 간의 관계를 나타내기 위해 사용되는 키로 이를 유형과 함께 설명할 수 있다. 외래키는 사원 릴레이션에서 기본키가 사원 번호이고 부서명이 기본키는 아니지만 회사의 조직도를 나타내는 릴레이션에서 부서명이 기본키가 되어 참조되어 다른 릴레이션의 기본키를 참조하는 역할을 한다. 또한 사원 릴레이션에서 사수의 사원번호가 애트리뷰트로 존재한다면 이는 기본키가 될 수는 없겠지만 일반사원의 사원번호는 일반키가 되고 사수의 사원번호키가 기본키의 값을 가져와 하나의 릴레이션에서 외래키가 기본키를 참조하는 역할을 한다.

  정리하자면, 튜플과 애트리뷰트로 구성되어 있는 릴레이션에서 키는 이들을 구별해주는 중요한 역할을 한다는 것이다.

2. 무결성이란?

  키에 관해 공부하다보면 중요한 개념이 개체 무결성, 참조 무결성이 있다.

  개체 무결성(Entity Integrity)은 릴레이션의 기본키를 구성하는 속성은 NULL일수 없다는 것이다. 기본키는 하나의 릴레이션에서 속성들을 구별해주는 가장 중요한 대표 역할을 하므로 유일성, 최소성 뿐만 아니라 값에 대해 not null또한 만족해야 하는데 이것이 개체 무결성과 연관 지어지는 이유이다. 정리하자면 개체 무결성은 기본키에 속해 있는 속성은 절대 널(Null)값을 가질수 없다는것과 기본키에 속해 있는 속성은 중복 값을 가질 수 없음을 뜻하는 것이다.

  참조 무결성(Referential Integrity)은 릴레이션은 참조할 수 없는 외래키 값을 가질 수 없다는 것을 말한다. 외래키는 다른 릴레이션의 기본키를 참조하나는 애트리뷰트이며 릴레이션 간의 관계를 나타내기 위해 사용되는 키로 참조 무결성에 의해 외래키 값은 NULL이거나 참조 릴레이션의 기본키 값과 동일해야 한다는 규정 제약 조건은 참조 할수 없는 외래키를 가질수 없다는 것과 외래키는 NULL이거나 참조하는 테이블의 기본키와 같은 값이어야한다. 참조되는 테이블의 행을 이를 참조하는 참조키가 존재하는한 삭제될수 없고 기본키도 변경될수 없음을 뜻한다.

이밖에도 데이터베이스의 이론에는 여러가지가 더있지만 학습중 가장 중요해보이는 것들을 간단하게 2차시로 구성하여 적어 봤다. 다음 차시부터는 MYSQL설치부터 시작하여 실습에 관한 내용을 다뤄볼것이다.

학교에서 수강했던 데이터베이스 수업간 배웠던 MYSQL에 대해 포스팅을 하려한다. 

초반엔 과제를 하며 중요하다 생각했던 정의에 대해 2차시정도로 축약하여 설명한후 그 이후부터는 실습에 관련한 내용들을 주로 다뤄볼생각이다.

1. 데이터베이스 정의

특정 조직의 업무를 수행하는데 있어 작동하고 있는 데이터들의 모임을 데이터베이스라고 정의한다. 이러한 데이터베이스의 구성요소는 크게 개체(entity), 속성(attribute), 관계(relationship)로 크게 3가지로 나뉜다.

  첫번째, 개체(entity)의 경우 업무가 다루는 사물(대상)을 가리 키는 것으로 데이터베이스에서 표현하려는 객체로서 서로 구별되는 것을 뜻한다. 대학교를 예로 들면 교수, 학생, 과목이 데이터베이스에서의 개체라고 할 수 있다.

  두번째, 속성(attribute)의 경우 각 사물(대상)이 가지고 있는 상세한 특성으로 즉, 하나의 개체는 하나 이상의 속성으로 구성되어 그 개체의 특성을 설명해주는 지표가 되는 것이다. 예로 들면 교수라는 개체는 교수번호, 교수이름, 전공, 학과로 학생은 학번 이름, 학년, 학과로 과목은 과목번호, 과목이름, 학점이란 속성들로 구성되어 각각의 개체를 구성한다.

  마지막, 관계(relationship)의 경우 업무가 다루는 사물들 사이에 존재하는 연관으로 즉, 각각의 개체 또는 개체 집합들 사이의 관계를 나타내는 것이다. 예로 들면 교수와 학생은 지도라는 관계, 교수와 과목은 강의라는 관계, 학생과 과목은 등록이라는 관계로 이루어 진다 할 수 있다.

  정리하자면, 각각의 속성을 가진 개체들이 관계를 가지고 모여 만들어진 모임을 데이터베이스라고 한다.

2. 데이터베이스의 특징

데이터 베이스의 특징은 크게 6가지로 표현할 수 있다.

  첫번째, 실시간 접근성(Real-Time Accessibility)로 질의에 관해 실시간으로 처리 및 응답이 이루어져야 한다.

  두번째, 계속적인 변화(Continuous Evolution)로 데이터베이스는 만든 이후 정적인 것이 아닌 계속해서 새로운 데이터가 갱신, 삭제, 삽입 등의 동적인 특성을 가짐으로써 항상 최신의 상태를 유지하여야 한다. 물론 동적인 특성을 띔과 동시에 정확성 또한 유지해야 한다.

  세번째, 동시 공용(Concurrent Sharing)으로 데이터베이스는 여러 사용자들이 동시에 사용하는 것이므로 다수의 사용자가 동시에 같은 데이터를 이용할 수 있어야 한다.

  네번째, 내용에 의한 참조(Content Reference)로 데이터 베이스는 위치나 주소가 아닌 체중, 신장과 같은 사용자가 요구하는 데이터의 내용으로 데이터를 찾아낸다.

  다섯째, 지속성(Persistent)로 데이터 베이스는 한번 데이터를 생성하고 나면 일부러 저장매체를 훼손하지 않는 한 소멸하지 않고 지속된다.

  마지막, 상호 관련성(Inter-Related)로 데이터 베이스는 각 개체들이 서로 관계를 맺어 만들어 진다는 상호 관련성을 띈다는 특징이 있다.

데이터 베이스는 어떠한 성질을 가지고 있는 데이터들이 모여 있는 것으로 크게 4가지로 정의할 수 있다.

  첫번째, 통합된 데이터(Integrated Data)로 자료의 중복을 최소로 통제한다는 뜻을 가진다. 중복을 완전히 없애기는 중복이 없을 경우 다른 테이블 사이에 연관을 할 수가 없기에 불필요한 자료의 중복을 최소화한다.

  두번째, 저장된 데이터(Stored Data)로 말그대로 컴퓨터가 접근 가능한 저장매체(테이프, 디스크 등)에 저장된 자료라는 뜻을 가진다.

  세번째, 운영 데이터(Operational Data)로 한 조직의 고유 업무를 수행하기 위해 반드시 필요한 데이터로 단순한 입출력이나 임시 데이터가 아닌 존재목적이 뚜렷한 데이터 라는 뜻을 가진다.

  마지막, 공용 데이터(Shared Data)로 한 조직의 여러 응용 프로그램이 공동으로 소유, 유지, 이용하는 데이터라는 뜻을 가진다.

  정리하자면, 데이터베이스란 한 조직의 여러 응용 시스템들이 공용(shared)하기 위해 통합(integrated), 저장(stored)한 대용량(large)의 운영(operational)데이터의 집합이다.

3. DBMS란?

DBMS 제품을 설명하기전에 간단히 데이터베이스의 종류에 대해 나눠보자면 크게 계층형 데이터베이스, 네트워크형 데이터베이스, 관계형 데이터베이스로 나눌 수 있다.

  계층형 데이터베이스는 데이터의 관계를 트리 구조로 정의하고, 부모,자식 형태를 갖는 구조로써 상위의 레코드가 복수의 하위 레코드를 갖는 구조이다. 하지만 데이터의 중복이 생긴다는 문제점이 있다.

  네트워크형 데이터베이스는 계층형 데이터의 데이터중복 문제를 해결했고, 레코드 간의 다양한 관계를 그물처럼 갖는 구조이다. 하지만 복잡한 구조 때문에 추후에 구조를 변경한다면 많은 어려움이 따른다.

  관계형 데이터베이스는 우리가 흔히 표현하는 행(Column), 열(Record)로 구성된 Table간의 관계를 나타낼 때 사용한다 우리는 이렇게 표현된 데이터를 SQL(Structured Query Language)을 사용하여 데이터 관리 및 접근을 한다.

  이와는 다르게 SQL을 사용하지 않는다는 의미로 NoSQL데이터베이스가 있는데 이번 목차에서는 이러한 SQL데이터베이스인 MYSQL, MS-SQL과 NoSQL데이터베이스인 MongoDB의 특성에 대해 설명해보려 한다.

  첫번째, MYSQL은 PHP, jsp, 자바 웹 프로그래밍에서 사용되는 일반적인 DBMS이며, MYSQL은 공개용 소프트웨어이기 때문에 누구나 무료로 다운로드 받아 사용할 수 있지만, 상업적인 목적으로 MySQL을 사용하려면 반드시 라이센스를 별도로 구매하여야 한다. MySQL은 무료이면서 처리되는 속도 또한 상당히 빠르고 용이하며, 대용량의 데이터를 처리할 수 있는 장점과 보안에도 뛰어난 특성을 지니고 있다.

  두번째, MS-SQL은 C# ,asp.net 웹 프로그래밍에서 사용되는 일반적인 DBMS이며, MS-SQL은 많은 기능들이 마법사로 구성되어 있어 SQL을 몰라도 백업,튜닝,스케쥴,복제등의 관리가 가능해 DB관리툴이 편리하며, 트랜잭션 기반으로 완전한 무결성 구축이 가능하고, 여러 단계의 보안레벨을 지원해 뛰어난 보안성을 자랑하는 특성을 지니고 있다.

  마지막, MONGODB는 모드데이터가 JSON형태로 저장되며, 스키마가 없어 이에 따라 필요할 때마다 필드를 추가하거나 제거하는 것이 매우 쉬워졌음을 의미해 개발과정이 매우 단순해지고 빠르게 개발이 가능하게 되었다. key기반의 get, put 뿐만 아니라 다양한 종류의 쿼리들을 제공한다. 그리고 별도의 스토리지 엔진을 통해 파일을 저장할 수 있는 특징이 있으며, 조인과 트랜잭션이 없는 특성을 지니고 있다.

  정리하자면, 방식에 따라 여러 종류로 나누어 지더라도 결과적으로 DBMS란 응용 프로그램과 데이터의 중재자로서 모든 응용 프로그램들이 데이터베이스를 공유할 수 있도록 관리해 주는 소프트웨어 시스템이라는 것이다.

(나의목표는 일단 MYSQL과 MONGODB를 올해안에 다뤄보는게 목표이다.) 

2020.09월기준, ORACLE, MY-SQL, MS-SQL순으로 세계 DBMS시장을 점유하고 있는 것으로 나타났으며 점유율로 나타낼 경우 ORACLE 약42%, MY-SQL 약19%, MS-SQL 약16%로 나타났다. 국내 DBMS시장의 경우 ORACLE이 60%이상을 점유하고 있는 것으로 나타나 있다. 

*참고문헌 및 사이트

1. DBMS특징 및 구별에 관하여

https://ourcstory.tistory.com/30

https://ykh9300.tistory.com/52

https://siyoon210.tistory.com/130

https://lazyer.tistory.com/27

https://server-talk.tistory.com/29

https://ssmsig.tistory.com/19

https://league-cat.tistory.com/23

2. DBMS 시장 점유율

https://db-engines.com/en/ranking-