생각하는 대로 살자.

http://www.tutorialspoint.com/mongodb/index.htm

MongoDB - Overview

MongoDB는 cross-platform의 document oriented DB이다. 높은 수준의 성능과 가용성, 쉬운 확장성을 제공하며 Collection과 Document의 개념 내에서 동작한다.

(참고 : Document-Oriented DB가 뭥미? http://lambdaexp.tistory.com/38, ORM(Objected Relational Mapping)을 왜 쓸까? http://www.tutorialspoint.com/mongodb/mongodb_overview.htm)

Database

 Database는 collection을 위한 물리적 그릇이라고 볼 수 있다. 각각의 database는, 각각의 파일 시스템을 갖춘 파일들의 셋을 가지고 있다. 하나의 MongoDB 서버는 일반적으로 여러 개의 데이터베이스를 가진다.

Collection

 Collection은 MongoDB document의 집합체이다. RDBMS table과 같으며 collection은 하나의 데이터베이스 내에 존재한다. Collection은 꼭 일정한 틀을 갖출 필요가 없으며 한 collection내의 document들은 서로 다른 filed를 가질 수도 있다. 일반적으로 하나의 collection내의 모든 document들은 비슷하거나 연관이 있는 목적으로 만들어져 있다.

Document

 document는 key-value pair의 집합이다. document는 dynamic schema를 가지고 있다. Dynamic schema가 뜻하는 것은 같은 Collection 내의 document들이 꼭 같은 field들 혹은 구조를 가질 필요가 없다는 것과, 하나의 collection의 document들의 공통된 field가 서로 다른 data 타입의 값을 가지고 있을 수 있다는 것이다.

아래는 RDBMS 용어와 MongoDB와의 관계를 보여주는 표이다.

 아래의 예제는 한 블로그 사이트의 document 구조를 나타내고 있다. 간단하게 콤마로 key-value pair를 구분하였다.

 _id: ObjectId(7df78ad8902c)
   title: 'MongoDB Overview', 
   description: 'MongoDB is no sql database',
   by: 'tutorials point',
   url: 'http://www.tutorialspoint.com',
   tags: ['mongodb', 'database', 'NoSQL'],
   likes: 100, 
   comments: [	
      {
         user:'user1',
         message: 'My first comment',
         dateCreated: new Date(2011,1,20,2,15),
         like: 0 
      },
      {
         user:'user2',
         message: 'My second comments',
         dateCreated: new Date(2011,1,25,7,45),
         like: 5
      }
   ]
}

_id 는 12 바이트의 16진수의 수이다. 이는 각각의 document의 유일성을 결정한다. _id 값은 직접 값 설정을 해 줄 수 있다. 만약 설정을 하지 않았다면 MongoDB 자체에서 매 document마다 생성을 해준다. 이 때 이 12 바이트는 현재 timestamp의 첫 4 바이트와 machine id 3 바이트, mongodb server의 pid의 2 바이트로 이루어 져 있으며 나머지 3 바이트는 단순한 증가값으로 채워진다.

asp.net

.NET 프레임워크를 기반으로 한 웹 애플리케이션 개발 모델, 프레임워크, 관련 기술을 총칭해서 부르는 것.

=>

1. ASP.NET은 .NET 프레임워크를 기반으로 한다. 따라서 .NET에서 제공하는 클래스 라이브러리를 사용할 수 있으며, 프로그래밍 언어로는 .NET이 제공하는 모든 언어를 사용할 수 있고, .NET 프레임워크 기반의 애플리케이션에 적용되는 모든 요소들이 ASP.NET에서 적용이 된다. 즉, .NET에 대해서 잘 알지 못하면서 ASP.NET을 잘 안다는 것은 불가능 하다.

2. ASP.NET은 웹 애플리케이션을 만들기 위한 것이다. 따라서 일반적인 웹 애플리케이션의 특성을 그대로 가지며, 웹 애플리케이션이 수행 가능한 범위 내에서만 능력을 발휘할 수 있다.

3. ASP.NET은 '엔터프라이즈 수준'의 애플리케이션을 맞추는데 가장 큰 초점을 맞추고 있다. 따라서 간단한 애플리케이션들을 만드는 데는 최적의 개발 모델이 아닐 수 있다는 점을 염두에 두어야 한다. 또한 엔터프라이즈 애플리케이션을 개발 할 때 고려해야 할 사항들에 대해서도 알 필요가 있다.

웹의 동작 방식

1) Request & Response의 구조를 취한다.

2) 기본적으로 전송 시에 HTTP 프로토콜을 사용한다.

3) Request를 보내고, Response를 처리하는 웹 클라이언트가 있어야 한다.

4) Request를 처리하고, Response를 보내는 웹 서버가 있어야 한다.

5) 기본적으로 Request에는 Get 방식과 Post 방식이 존재한다.

6) 기본적으로 Response의 최종 형태는 정적 HTML 이다.

빨간색 : ASP.NET에 해당하는 부분

ex)  대용량 바이너리 데이터를 전송하기 위해 HTTP 업로드 컴포넌트가 나옴(1) 

HTTP 이어받기 기능 등장(1)

주고 받는 프로토콜의 전송 수준에서의 보안을 위해 SSL이 등장(1)

최대한 많은 요청을 가장 빨리 처리하기 위해 웹 서버 기술이 발전(2)     

요청에 따라 동적으로 응답을 생성해 내기 위해 웹 서버 애플리케이션 기술(CGI, ISAPI, ASP, ASP.NET, PHP 등)이 나옴(3) 

정적 컨텐츠인 HTML에 동적인 측면과 상호작용성(interactivity), 재사용성을 부여하기 위해 DHTML, JavaScript, CSS, ActiveX, 애플릿 등이 나오게 됨(4) 

효율적으로 요청을 처리하고, 응답 속도를 보다 빠르게 하고, 응답 결과를 렌더링 해서 보여주기 위해 브라우저 기술이 발전(5)

 초기의 웹 서버는 HTML, 그림 파일과 같은 정적 컨텐츠에 대한 요청을 받아서 이를 그대로 전달할 뿐이었다. 즉 초기의 웹은 '통신'보다는 FTP나 Gopher와 같은 '전송'을 한다는 의미가 강했다. 웹이 진화 되면서 정적 컨텐츠가 아닌 동적 컨텐츠를 전달할 방법이 없을까 궁리하게 되었고, 동적 요청을 위한 매개 변수를 어떻게 전달할 것 인가와 이를 받아서 어떻게 처리해야 하는 가라는 문제가 대두 되게 된다.

 매개 변수의 전달은 Get, Post 방식이 존재한다. Get방식은 URL 뒤에 ?이후에 키=값 쌍으로 이루어진 Query String을 붙여서 매개변수를 전달하는 방법이고, 이에 비해 Post 방식은 태그를 사용하며, 키=값 쌍을 HTTP 헤더 내에 집어 넣어서 전달하는 방법이다.

 정적 컨텐츠에 대한 요청과 동적 컨텐츠에 대한 요청을 구분하기 위해 편의상 동적 컨텐츠 만의 확장자를 사용하게 된다. 즉, .html이나 .htm 대신에 .cgi .asp .php .jsp .aspx 등을 사용하게 된 것이다. 이렇게 동적 컨텐츠로 구분되는 확장자로 요청이 들어올 경우, 웹 서버는 이를 가로채서 동적 컨텐츠 처리 모듈에 던져주게 된다.

 동적 컨텐츠를 처리하는 모듈, 즉 웹 애플리케이션은 최초에는 CGI 형태가 사용되었지만, 시간이 흐름에 따라 ISAPI 방식과 Script 기반 방식 등으로 진화 되어 나갔다. 현재 우리가 사용하고 있는 대부분의 방식은 Sxript 기반 방식으로 보면 된다. ASP.NET 역시 여기에 속한다고 보면 된다.

 ASP는 기본적으로 IIS 웹 서버 상에서 사용될 목적으로 만들어졌다. ASP가 처음 등장한 건 훨씬 이전이긴 하지만, 널리 사용된 것은 NT4.0의 옵션팩에 탑재된 IIS4.0이므로 이를 기준으로 하면 다음과 같다.

 IIS 4.0 시절, ASP가 구동되는 기본 아키텍처는 아래와 같은 In-Process 모델이다.

*ASP.NET의 아키텍처와 개선 사항

ASP.NET 설치 시에 aspnet_isapi.dll이라는 ISAPI 처리기가 등록된다. 이 것은 .aspx와 같이 ASP.NET 관련 확장자를 가로채서 실제로 처리하는 작업자 프로세스(Worker Process)인 aspnet_wp.exe 에게 전달한다. aspnet_wp.exe는 내부에 요청의 전후에 개입하기 위한 HttpModule과 개별 요청을 처리하기 위한 HttpHandler로 구성된다. HttpModule이나 HttpHandler는 기본으로 제공되는 것 이 외에 사용자가 정의해서 확장하는 것이 가능하다.

 ASP.NEt은 별도의 전용 프로세스인 aspnet_wp.exe에서 구동되므로 자신이 죽더라도 inetinfo.exe에는 영향을 미치지 않는다. 따라서 이전 dllhost.exe에서 구동될 때처럼 안정성 측면에서는 확보가 된 셈이다. aspnet_isapi.dll은 실행 중인 aspnet_wp.exe가 없을 때는 바로 이 프로세스를 다시 실행하며, 구성 정보에 따라서 aspnet_wp.exe의 동작을 제어할 수도 있다. machine.config의 <processModel> 내용을 보면 이를 제어하기 위한 내용들이 존재한다. timeout을 지정해서 일정 시간 동안 요청이 없으면 종료 시켜버릴 수도 있고, 일정 시간 이상 데드락이 걸렸을 때는 재시작하는 기능도 존재한다. 다양한 구성 정보에 다라서 동작 특성을 제어하는 것 역시 가능해 졌음을 의미한다.

 위 그림의 우측에 보면 aspnet_state.exe라는 프로세스가 있다. ASP.NET 역시 기본적으로는 세션을 In Process 모드로 관리하지만, 설정에 따라서 그림과 같이 세션을 별도의 프로세스(aspnet_state.exe)에서 관리할 수 있다. 다라서 aspnet_wp.exe가 죽는다고 하더라도 세션 정보 자체는 여전히 살아있게 된다.