[DB] MongoDB 프로그래밍 1일차

수업을 들은 이후로 이번이 9번째, 10번 수강이라는 목표를 달성하기 위해 들은 수업이기도 하지만 새로운 것을 점점 접하기 어려워 지는 것 같아 가장 생소하면서도 궁금했던 수업을 신청하였습니다.

 

이번 수업에는 교제가 없어서 뭔가 시작부터 조금은 당황스럽습니다. 내일부터는 딱히 펜을 준비할 필요도 없을 것 같습니다.

 

강의실에 늦지 않은 시간에 도착했음에도 불구하고 그동안 2번은 앉았던 것 같은 자리는 다른분께서 먼저 앉으셔서 간단하게 저녁을 때우고 수업을 듣기위해 그 뒷자리에 앉아 준비를 합니다.

 

 

=================================    1    ==============================

(19:08 ~ 19:54)

 

강의자료는 PDF파일로 받았으며 강사님의 자기소개 및 수강생의 각각 자기소개가 있었습니다.

 

우선 자바개발자인 강사님의 확인 및 소개 중간중간 질문도 하셨습니다.

 

NoSQL의 개념부터 차근차근 실습 위주로 수업을 진행한다고 하셨습니다. 자바 기반으로 실습을 진행한다고 하셨으며 자바 개발자가 생각보다 적어서 걱정을 하셨습니다.

 

 

MongoDB를 갖고 Java Script를 할 수도 있다고 하셨습니다.

 

full stack이 요즘의 대세라고 하셨습니다. full stack framework는 하나만 익히면 다 된다고 하셨습니다.

 

NoSQL DB는 스키마가 없어서 스타트업 기업에서 많이 씁니다. 제품화가 쉽고 개발 속도가 빠릅니다.

 

 

NoSQL의 정의

 

전통적인 RDBMS와 차별적화하는 의미로 사용되기도 합니다.

NoSQL은 SQL이나 RDBMS를 배제하지 않습니다.

(Not only SQL)

 

NoSQL은 빠르고 효율적인 처리에 초점을 두었습니다.

 

NoSQL은 row이상이다. key , value쌍으로 저장을 하기도 합니다.

( 그래프, 컬럼- 페밀리, 문서, 테이블로우 등... )

 

스키마가 없고 조인으로부터 자유롭습니다(조인을 지원하지 않음)

 

MongoDB로는 join을 피하는 방법으로 설계를 해야 합니다.

 

컬랙션 설계에 대해서 추후에 실습진행 시 설명을 추가로 해 준다고 하셨습니다.

 

 

NoSQL의 4가지 저장소

 

1) 키 벨류 저장소

2) 컬럼 페밀리 저장소

3) 그레프 저장소

4) 문서저장소

 

site를 하나 알려주신다고 하셨습니다. 만 강의 시작 전 칠판에 주소만 적어주시고 강의자료라고 알려주지 않으셨다며 강의자료에 대해 한번 안내해주셨습니다.

Namoosori-MongoDB(ver2.21).pdf

 

=================================    2    ==============================

(20:08 ~ 20:48)

 

이전 시간에 알려주신다고 하신 site는 nosql-database.org입니다.

 

site소개 후 위의 4가지 저장소에 대한 특징에 대해 설명을 이어 진행하셨습니다.

 

위의 4번의 문서저장소는 저장 단위가 하나의 문서입니다. 즉, web page하나의 화면이 하나의 저장 단위가 되기도 합니다.

 

컬랙션이 관계형 DB의 table이라고 생각을 해도 된다고 설명을 해 주셨습니다.

 

NoSQL의 종류에 따른 검색 추이를 보여주시면서 MongoDB에 대한 관심도가 높아지는 것을 확인할 수 있었습니다.

 

 

NoSQL 비지니스 드라이버

 

1)용량

2)속도

3)다양성

4)민첩성

 

NoSQL은 스키마가 없기 때문에 DB변경에 관계형 DB보다는 유연하게 개발을 할 수 있습니다.

 

1.5배정도 더 빠른 개발이 가능하다고 합니다. 또한 MongoDB와 같은 빨리 개발이 가능한 것으로 개발을 하고 빨리 상품화를 한 후 상품 출시 현황을 보고 관계형 DB로 바꾸는 것도 소개를 해 주었습니다.

 

그렇게 진행하는 이유는 원래 DB가 정교하게 설계 및 관리되어있어야 하지만 출시를 위해 속도를 앞당기는 경우 프로토타입 DB식으로 개발을 하는 것이라고 설명을 해 주셨습니다. 또한 RBD(관계형 DB)를 사용하는 또다른 이유는 트렌젝션 문제입니다.

 

Data가 엄격하게 저장되어야 하고 Transaction이 엄격하게 지켜져야 하는 경우는 RDB를 사용하야만 하며 빠른 반응속도가 필요한 경우에는 NoSQL DB를 혼용해서 사용하는 경우도 있다고 하셨습니다.

 

특히 연구과제의 예를 들어서 비관계형디비(?)를 사용할 수 있다고 하셨습니다.  Main은 관계형 DB라는것이 아직은 깰 수 없는 대세(?)라는 느낌의 이야기를 해 주셨습니다. 완벽하지는 않지만 NoSQL가 성능 뿐 아니라 관계형 DB를 대체할 수 있도록 발전을 하면 대체할 수 있을 것이라고 하셨습니다.

 

구글 검색엔진의 동작 방식을 설명 해 주셨습니다. (강의자료 12페이지 참고)

키 - 벨류 방식으로 저장을 하여 Data의 구조를 단순하게 만들어서 활용합니다.

 

Main DB보다는 보조용 DB로 추천을 하였음.

 

 

 

=================================    3    ==============================

(21:00 ~ 21:48)

 

 

첫날에는 실습 및 환경구축을 할 수 있을지 없을지 확신이 서지 않는다는 말씀으로 마지막 시간의 강의를 시작하셨습니다. 

 

급 프로그래밍 언어에 대한 이야기를 시작하시면서 C언어를 배웠던 옛 시절을 회상하시고 메모리 할당과 해제 부분에서 좌절을 하셨다는 이야기를 해 주셨습니다. Java의 경우에는 메모리 해제를 개발자가 해 줄 필요가 없기 때문에 편했다는 이야기도 하셨습니다. 자바와 자바 스크립트 차이를 설명해주셨습니다. 왜....? 인지는 모르겠지만 도움이 될 것이라 생각하고 듣고 있습니다.

 

자바의 경우에는 한번 배포가 되면 수정 후 재 배포를 해야하지만 자바스크립트의 경우에는 이와 같은 과정이 필요 없다고 하셨습니다.

 

shell에서 java script를 사용할 수도 있다고 하셨습니다. 또한 요즘 자바스크립트가 중요해 지고 있다는 것에 대해 설명을 해 주셨습니다. 그 이유중에 하나로 API의 활용이 증가 한 것과 새로운 환경으로 변하면서 동적으로 화면구성이 이루어 지면서 중요해 졌다고 하시면서 직접 UI관련 개발까지 본인이 한다는 이야기도 해 주셨습니다.

 

여러 이유로 자바스크립트가 갈수록 중요해 질 것이라고 하셨고, 비동기 처리를 해야하는 경우에 함수지향형 언어가 유리하다고 하셨습니다. call back처리가 자바스트립트에서는 편리하다고 하셨습니다.

 

(요즘 트렌드는 여기까지로 갈음한다고 하셨습니다......)

 

관계형DB이전에는 file system!

 

 

유닉스의 파이프를 사용한 명령어의 처리를 응용하여 만들었다고 하셨습니다.

 

레이어페턴이 등장한 이유는 복잡성을 낮추기 위함이라고 하셨습니다.

 

레이어로 나누어서 위에서 아래 방향으로 호출을 합니다.

 

1. UI 레이어

2. 비지니스 로직 레이어

3. 데이터베이스 레이어

 

code안에서 쿼리를 날리는? code를 컨설팅을 한 경험을 이야기 해 주셨습니다. 개발자들이 계속 바뀌면서 style이 없어지고 그러한 것들로 인해 생기는 문제의 예로 소개해주셨습니다. 그러면서 Layer를 만들어 처리하는 것을 강조하셨습니다.

 

NoSQL DB에서 Application을 개발을 하는데 RDBMS의 트렌젝션, 케싱등의 기능을 사용하려면 어플리케이션 단에서 개발자가 구현을 해야합니다.

 

강의자료 22페이지의 모델간의 통합 모델을 도메인 단위로 나누는 이유는 복잡하게 얽혀있으면 따로 분리하기가 쉽지 않다는 것입니다. 즉, 따로 중복을 허용하면서 관리를 하면 일부분의 도메인 모델만을 이식하여 분산처리를 하는 것 또한 가능합니다.

일부분만 변경이 되었으면 그 부분에 해당하는 것만 배포를 하면 된다는 것 또한 장점입니다.

 

 

ACID 트랜잭션은 Lock을 걸고 base 트랜잭션은 lock을 걸지 않습니다.

 

3~4개의 node를 하나의 클리스트링으로 묶습니다. 또한 NoSQL는 메모리를 RDB보다 많이 사용합니다. 또한 클리스터 하나당 2개의 랙으로 나누어 사고(예로 정전.)에 대비해야합니다.

 

분산된 네트워크 상에서 분산처리를 하는데 키값이 중복되면 안됩니다. 키 값을 가지고 충돌방지를 해야 한다고 하셨습니다.

<이 부분은 이해가 잘 되지 않았음 .. 너무 뻔한 이야기 아닌가? 싶었습니다.>

 

트랜잭션을 설명해 주시면서 기본적인 block 개념의 장 단점을 설명해주셨습니다. NoSQL의 경우 lock을 걸지않고 일단 주문을 받습니다.

 

base 트랜잭션은 그동안의 RDB의 트랜잭션과 달리 보상이라는 개념을 갖고 추후에는 결과가 정상적이 될 것이다라는 사고의 트랜잭션입니다.

 

DB샤딩

 

샤딩이란 운영중에 노드를 추가하고 데이터의 일부를 새로운 노드로 옮기는 것을 말합니다. 샤딩을 할 때에도 Data를 나누는 기준을 잘 세워야 합니다. Data를 어떻게 나누느냐에 따라서 성능 차이가 발생할 수 있기 때문입니다.

 

CAP 이론은 시스템이 실패 할 경우에 어떤것을 우선시 할 것인지를 보는 것이라고 생각하시면 됩니다.

 

1) Consistency

2) High Availability

3) Partition Tolerance

 

위의 조건중에 어떤것에 초첨을 두느냐에 관한 이론으로 1)과 2)는 트레이드 오프 관계로 3가지 조건을 모두 최선으로 고려할 수 없습니다.

 

요약으로 레이어드 아키텍쳐를 사용하여야 한다는 것을 강조하셨습니다.

(나머지는 강의자로 페이지 35참고)

 

강의 막바지에는 강사님의 사업 경험으로 main DB를 RBD로 하고 일부만

NoSQL DB를 사용하는 것을 추천 하시면서 하나의 사례를 들어주셨습니다.

 

main으로 MongoDB를 사용하겠다면 한번 더 공부하고 검색하고 고려해보기를 권하셨습니다.