[PostgreSQL] 테이블 조작

psql로 접속

sudo su – postgres

psql -U postgres DB이름

이렇게 하면 콘솔이 DB이름이 됨. 이제 여기서 할 일을 하면 되는데..

  • \h를 입력하면 사용할 수 있는 SQL을 보여주고
  • \?를 입력하면 사용할 수 있는 psql 커맨드를 보여준다.
  • 그리고 쿼리를 실행하려면 세미콜론으로 끝내면 된다.

컬럼 타입 변경하기

ALTER TABLE 테이블이름 ALTER COLUMN 컬럼이름 TYPE 원하는타입;

예) Comment 테이블의 comment 컬럼 타입을 text로 변경하기

ALTER TABLE Comment ALTER COLUMN comment TYPE text;

테이블 목록 출력

\dt

테이블 스키마 확인

\d 테이블이름

DB 목록 확인

\l (엘)

[자바 퍼포먼스] 2장 운영체제 퍼포먼스 모니터링, 용어 정의

퍼포먼스 모니터링

Performance monitoring is an act of nonintrusively collecting or observing per- formance data from an operating or running application.

퍼포먼스 프로파일링

Performance profiling in contrast to performance monitoring is an act of col- lecting performance data from an operating or running application that may be intrusive on application responsiveness or throughput.

퍼포먼스 튜닝

Performance tuning, in contrast to performance monitoring and perfor- mance profiling, is an act of changing tune-ables, source code, or configura- tion attribute(s) for the purposes of improving application responsiveness or throughput.

그러니깐.. 모니터링으로 성능 문제를 인지하면, 프로파일링을해서 원인을 찾고, 튜닝으로 해결한다. 용어에 대한 정의를 서로 잘 공유하면 대화하기가 편할텐데.. 모니터링/프로파일링은 좀 햇갈렸었는데 이렇게 구분하면 되겠군.

[vert.x] 컨커런시 모델

https://github.com/purplefox/vert.x/wiki/Concurrency-model

vert.x의 컨커런시 모델은 멀티 리액터 패턴이다. 이 패턴은 Java 1.4에 추가된 NIO로 구현할 수 있다. 그리고 이미 그 기반으로 조금 더 쉽게 코딩할 수 있도록 Netty라는 오픈소스 프로젝트도 있고, vert.x는 netty 위에서 조금 더 최근 기술 동향에 어울리는 프레임워크로 자리잡고자 노력중이다.

최근 기술 동향에 어울리는.. 이라고 함은 vert.x 첫 페이지에서 볼 수 있다.

  • 모든게 non-blocking
  • Polyglot (물론, 그래봤자 JVM에서 돌아가는 언어 들이지만…그래도 폴리글롯은 폴리곳이니깐..ㅋ)
  • True Scalable. (다른 이벤트 기반 프레임워크에 비해 이 점을 장점으로 내세운다. 즉 멀티 리액터 패턴이라는 것이다.)
  • 컨커런시 모델이 깔끔해서 race condition이나 lock 걱정 없이 코딩해도 된단다.
  • 다양한 네트워크 프로토콜 지원: TCP, SSL, HTTP, HTTPS, Websockets.
  • SockJS 지원 (플래시 소켓을 사용하지 않는다고 node.js 진영의 Socket.IO보다 낫다고 주장한다.)
  • Sinatra/Express 스타일(매우 간편한 MVC 스타일)로 코딩할 수 있다.
  • 분산 이벤트 버스 제공

이 중에서 핵심은 단연 컨커런시 모델이라고 할 수 있으니 컨커런시 모델을 살펴보자.

리액터 패턴의 장점은 locking이나 race condition을 신경쓸 필요 없다는 것이다. 쓰레드 하나로 코드를 실행하기 때문이다. 하지만 이런 전통적인 방식의 리액터 패턴은 멀티 코어 서버에서도 최대한 오직 단일 코어만 사용하게 된다는 문제가 있다. 따라서 만약 32 코어 서버를 최대한 활용하려면 인스턴스를 32개 띄워야 된다. 그런데 만약에 그 애플리케이션이 stateless하지 않고, 상태 정보를 관리해야 한다면, 프로세스 간에 메시지를 주고 받아야 하는 등 상태 관리가 까다로워진다.

vert.x는 프로세스당 여러 이벤트 루프를 돌릴 수 있도록 지원하기 때문에 인스턴스 한개를 띄워서 한개의 OS 프로세스로 모든 코어를 활용할 수 있다.

vert.x 인스턴스 한개가 여러 애플리케이션 인스턴스를 동시에 호스팅할 수 있다. 각각의 애플리케이션 인스턴스는 싱글 쓰레드로 동작하고 이벤트 루프 하나씩을 할당 받는다. 애플리케이션 인스턴스의 모든 코드는 오직 해당 이벤트 루프로만 실행한다. 여러 애플리케이션 인스턴스를 배포하는 방법으로 확장을 할 수 있다.

vert.x를 사용하면 컨커런시를 걱정할 필요가 없을 뿐 아니라 전통적인 단일 리액터 모델이 지니고 있는 확장성 문제도 신경쓸필요 없다.

상태 공유와 메시지 전송

stateless한 애플리케이션은, 애플리케이션 인스턴스가 상태 정보를 주고받을 필요가 없다. 하지만 대부분의 애플리케이션이 상태 정보를 가지고 있다.

vert.x는 애플리케이션 인스턴스가 정보를 공유할 수 있는 두가지 방법을 제공한다.

  • 메시지 전송: 한쪽 컨텍스트에서 다른쪽으로 메시지를 전송할 수 있다. 애플리케이션 인스턴스를 액터로 생각한다면, 액터 모델과 비슷하다고 볼 수 있다. 이런 모델은 특히, 데이터 스트림과 관련된 애플리케이션에서 유용하다.
  • 공유 데이터 구조: 공유된 캐시 데이터 같은 경우에는 메시지 전송 방식 보다는 vert.x가 제공하는 데이터 구조를 활용하는 방법이 좋다. immutable 객체만 shared data structure에 넣을 수 있다.

vert.x는 액터만 사용하라거나, 공유 데이터 구조만 사용하라고 강요하지 않는다. 정답은 없기 때문에 애플리케이션에 따라 개발자가 직접 선택할 수 있게 해준다.

[자바 퍼포먼스] 1장 전략, 접근방법, 방법론

  • “애플리케이션에서 기대하는 throughput은 어느 정도인가?”
  • “기대하는 요청-응답 latency는 어느 정도인가?”
  • “얼마나 많은 동접자 또는 동시 작업을 지원해야하는가?”
  • “최대 동접자 또는 동시 작업 중일 때 수용할 수 있는 throughput과 latency는 어느 정도인가?”
  • “가장 최악의 경우 latency는?”
  • “감당할 수 있는 수준의 latency 내에서 GC 주기는?”

이런 질문으로 지표를 정해야 할텐데… 고객이 이런걸 알 수가 있나? 그냥 측정부터 해보는게 좋겠어.

나머지는 그냥 전통적인 (폭포식) 소프트웨어 개발 프로세스에 성능 테스트랑 프로파일을 추가해서 분석, 설계, 코딩에 그 결과를 반영해서 다시 또 개발 프로세스가 돌고 돌고 돌고 하도록 그림을 그린 Wilson & Kesselman의 성능 프로세스라는 그림을 소개하고 있다.

다음으로는 하향식 방법과 상향식 방법을 설명하고 있다. 하향식은 애플리케이션 모니터링부터 시작한다. OS 시스템 모니터링, JVM 모니터링, JEE 서버 모니터링 등을 수행한 뒤 모니터링 정보를 바탕으로 JVM 커맨드 라인 옵션을 튜닝하거나, OS를 튜닝하거나, 애플리케이션을 프로파일링 한다. 프로파일링을 하면 코드가 더 효율적인 구현방식으로 바뀌거나, 비효율적인 라이브러리를 교체하는 등의 작업을 할 수도 있다.

상향식은 아주 밑바닥인 CPU 아키텍처, CPU 갯수등을 분석하는 것부터 시작한다. 아… 이 부분은 너무 로우 레벨이라.. 아흑.. path length니, CPU cache miss니.. @_@ 패스.

나머지도 패스.

 

[자바스크립트] 모듈

http://blog.davidpadbury.com/2011/08/21/javascript-modules/

자바스크립트에는 자바의 import나 C#의 using이라는 개념이 없다. 그래서 자바스크립트를 사용하는 개발자가 직접 그런 개념을 구현하고자 노력 중이다.

모듈 패턴

http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth 이 글에 있는 최종적인 소스 코드가 다음과 비슷하다.

(function(lab49) {

function privateAdder(n1, n2) {
return n1 + n2;
}

lab49.add = function(n1, n2) {
return privateAdder(n1);
};

})(window.lab49 = window.lab49 || {});
view raw gistfile1.js This Gist brought to you by GitHub.

이 코드에는 다음과 같은 개념이 녹아있다.

Isolation

자바스크립트의 함수 스코프를 이용해서 글로벌 스코프 변수를 사용해서 발생할 수 있는 난감한 상황을 피할 수 있다. 함수 내부에 있는 모든것은 시스템의 영향을 받지 않는다.

namespacing

위 코드의 마지막 줄처럼 이미 window에 lab49라는 네임스페이스가 있는지 없는지 여부에 따라서 이미 있다면 기존의 것을 사용하고 없다면 비어있는 객체 리터널을 넣어서 새로 만들도록 할 수 있다. 위와 같은 함수 랩퍼를 여러 자바스크립트 파일이 사용한다고 가정했을 때 유용한 방법이다.

Private State

함수 안에 있는 모든건 외부에서 접근할 수 없기 때문에 코드를 격리시키기 좋긴하지만, 함수 밖에서 그 안에 있는 걸 아무것도 접근할 수 없다면, 별 쓸모없는 함수가 되고 만다. 그래서 lab49처럼 window 객체에 네임스페이스 역할을 할 객체를 붙이고, 거기에 외부로 공개할 것을 붙이는 형태로 코딩할 수 있다. 마치 add 함수처럼. 저렇게 코딩해두면 밖에서는 lab49.add(2, 2)처럼 호출할 수 있다.

CommonJS 모듈

CommonJS는 주로 서버 사이드 자바스크립트 런타임을 만든 사람들로 구성된 그룹으로 모듈 공개와 접근에 대한 표준화를 시도했다.

CommonJS 모듈 스팩

// calculator.js
exports.add = function(n1, n2) {

};

// app.js
var calculator = require('./calculator');

calculator.add(2, 2);
view raw gistfile1.js This Gist brought to you by GitHub.

exports에 공개할 모듈을 추가하고, 모듈을 사용하는 쪽에서는 require를 사용해서 필요한 모듈을 가져다 사용한다.

CommonJS는 서버 사이드 자바스크립트 런타임을 주요 타겟으로 설계되었기 때문에 다음과 같은 이유로 클라이언트 사이드에 적용하기는 어려움이 있다.

  • requrie는 반드시 즉시 리턴해야 한다: 스크립트를 비동기적으로 다운로드하는 스크립트 로더를 사용하기 어렵게 한다.
  • 파일당 모듈: CommonJS 모듈을 만들려면 함수 하나로 감싸야하며 특정한 방법으로 구성해야 하는데, 그러려면 StitchBrowseify같은 노드 모듈을 사용해서 여러 모듈 자바스크립 파일을 하나의 자바스크립 파일로 묶어주는 컴포넌트를 사용하지 않고는 힘들어진다.

AMD(Asynchronous Module Definition)

AMD는 브라우저용 모듈 포맷으로 설계됐다. CommonJS 그룹에서 먼저 제안했지만, Github으로 자리를 옮기고 나서 테스트 스위트로 관리되고 있다.

AMD의 핵심 함수는 define 함수다. 이 함수를 세 개의 매개변수를 가지고 호출하는 코드가 가장 자주 사용하는 방법인데, 첫번째 매개변수로 모듈 이름을 넘기고, 두번째는 이 모듈이 의존하고 있는 모듈 식별자 배열을 넘기고, 마지막으로 모듈 정의를 반환할 팩토리 함수를 넘긴다.

define('calculator', ['adder'], function(adder) {
return {
add: function(n1, n2) {
return adder.add(n1, n2);
}
};
});
view raw gistfile1.js This Gist brought to you by GitHub.

모듈 정의가 define으로 감싸지기 떄문에 얼마든지 한 파일 안에 여러 모듈을 정의할 수 있다. 그리고 모듈 로더가 define 모듈 팩토리 함수를 호출할 때 그 의존성을 파악하여 필요로 하는 모듈을 먼저 비동기적으로 다운로드 할 수 있게 해준다.

자바스크립트가 구리다는 말이냐?

이런 개념 부재가 다른 언어를 사용해온 개발자에게 불편을 주긴하지만, 이런 개념 부재로 인해 자바스크립트 개발자 스스로가 원하는 패턴으로 모듈 구조를 만들어가고 있다.

10년 전에 이런 종류의 기능이 만들어졌다면 어땟을지 상상해보라. 지금처럼 서버 사이드에서 동작하는 자바스크립트 애플리케이션이나, 브라우저에서 비동기적으로 리소스를 로딩하는 기술도 없고 RequireJS 같은 로더처럼 텍스트 템플릿으로 리소스를 추가하는 것과 어울리는 기술은 아니었을 것이다.