근원e - No place to go~

갤럭시 S2 Quadrant 밴치 마크 결과 (ICS 4.0.3)

Sphinx 검색엔진 기본 설정

Sphinx 검색엔진 기본 설정 (서버 기본 구성값 )

# sphinx 검색엔진 기본 설정 구성
# 데이터 소스 설정
source sourcename # 데이터 소스 명
{
	# 데이터 베이스 설정
	type = mysql	# 데이터 베이스 타입
	sql_host = localhost	# 호스트
	sql_user = mysqluser	# 사용자
	sql_pass = mysqlpass	# 비밀번호
	sql_db = mysqldatabase	# 데이터베이스 이름
	sql_port = 3306	# 포트 

	# 데이터 수집질의 전 수행할 질의 
	sql_query_pre = SET CHARACTER_SET_RESULTS=utf8
	sql_query_pre = SET NAMES utf8

	# 데이터 수집용 질의 
	sql_query = SELECT * FROM data

	# 데이터 확인질의 (기본키는 $id로 넘겨줌)
	sql_query_info = SELECT * FROM data WHERE id=$id

	# 데이터 수집 질의 이후 수행할 질의 
	sql_query_post = UPDATE data SET status = 'ok'

}

# 데이터 인덱스 설정
index indexname 
{
	source = sourcename	#데이터 소스명 (상단 설정 이름)
	path = /data/		# 데이터 저장소 
	docinfo = extern	# 데이터 저장 모드 (기본 extern, inline, none)
	charset_type = utf-8	# 데이터 캐릭터 셋
	# 케릭터셋 테이블
	charset_table = 0..9, A..Z->a..z, _, a..z, U+AC00..U+D7A3, U+1100..U+1159, U+1161..U+11A2, U+11A8..U+11F9
	min_word_len = 2	#최소 단어 단위 
	ngram_len = 2		# N-gram Indexing 단위 (기본 0)
	ngram_chars = U+AC00..U+D7A3 # N-gram Indexing 을 사용할 캐릭터셋 범위 
}

# 인덱서 설정
indexer
{
	mem_limit = 128M	# 메모리 제한
}

# 검색데몬 설정
searchd
{
	listen		  = /tmp/searchd.sock	# unix domain socket 경로
	listen		  = 9312		# TCP 포트 
	listen		  = localhost:9306:mysql41	# MySQL 프로토콜 (SphinxQL)
	log = /log/log.log	# 데몬 로그 
	query_log = /log/query.log # 질의 로그 
	read_timeout = 5 # timeout
	max_children = 30 # 최대 자식 프로세스
	pid_file = /var/run/pid.pid # pid 경로
	max_matches = 1000 # 최대 매칭 수 
}

PHP MySQL Native Driver (mysqlnd)

PHP 5.3 부터 지원하기 시작한 MySQL Native Driver 는 MySQL 에서 지원하는 MySQL API를 이용하지 않고, PHP만을 위해 새로 쓰여진 C언어 기반의 API입니다. MySQL 의 듀얼라이선스 정책과 기타 메모리 반환시, 데이터 복사시 불필요한 낭비를 줄이고 좀더 PHP에 최적화된 성능을 제공하기 위해서 작성된 것입니다.

기존 MySQL Client API 와 동일한 동작을 하게끔 새로 작성된 API로 큰 성능향상에 기대하는 것은 무리지만 아주 약간은 빨라지고 가벼워 졌다는것에 중점을 두면 좋겠습니다.

또한 MySQL 클라이언트가 구지 필요없고 DB접속만 가능한 웹 서버일 경우 MySQL 클라이언트를 설치 하지 않고 PHP를 컴파일하는 것에는 매우 환영할 점입니다. ^^

MySQL , MySQL Improved, MySQL PDO (PHP Data Objects) 의 client api를 기존 MySQL Client API를 사용하지 않는것입니다. (libmysqlclient.so 등)

컴파일 환결설정에는 클라이언트만 존재하는 서버에서 더이상 MySQL Client 설치가 필요치 않고 PHP 소스만 가지고 설치를 할 수 있습니다.

--with-mysql=mysqlnd  (MySQL API)
--with-mysqli=mysqlnd (MySQL Improved Extension)
--with-pdo-mysql=mysqlnd (MySQL Functions:PDO_MYSQL)
--enable-mysqlnd

경로 설정등은 기존의 MySQL Client API (libmysqlclient)를 더 이상 사용하지 않기 때문에 필요치 않습니다.

32Bit PHP 에서 42억 이상의 수 계산 및 합산 (with MySQL, without bc, gmp)

오랜만에 PHP 팁을 쓰네요 ~ 사실 PHP팁이라기 보다는 MySQL 질의 사용 방법에 대한 것을 적어 봅니다. 32bit 로 컴파일된 PHP의 경우 최대 정수 값이 int(2147483647) 입니다. 64bit 환경에서 컴파일된 PHP는 int(9223372036854775807) 의 값을 다룰 수 있습니다. 하지만 32bit환경에서 최대 정수값 이상의 계산을 하려 할때는 bc, gmp등의 수치 계산 확장 모듈이 필요 합니다.

사용하고 있는 모든 환경에서 수치 계산 확장 모듈이 모두 사용가능 한것은 아니기에 MySQL 의 힘을 빌려 계산을 할 수 있습니다. MySQL 내부적 수치 연산은 BIGINT 는 unsigned 일떄 18446744073709551615 까지 가능합니다. 엄청 큰 수를 다룰 수 있어 종종 사용을 합니다.

합 , 누적 , 평균등의 계산을 MySQL 내부 변수와 함께 질의로 표현을 할 수 있습니다.

SET @total = 0; -- 전체 합을 구할 변수 

SELECT 
	tRst.trade_date, -- 거래일
	tRst.s_amount,	-- 합계
	@total := @total + tRst.s_amount AS acc_amount -- 누적합
FROM
(
	SELECT 
		trade_date, -- 거래일
		sum(amount) as s_amount -- 거래 금액
	FROM
		trade
	GROUP BY 
		trade_date
) AS tRst
GROUP BY tRst.trade_date
UNION
SELECT @total; -- 총계

이상으로 bc, gmp를 사용할 수 없는 32bit 컴파일된 PHP환경에서 MySQL의 도움으로 큰 수에 대한 합산 및 계산을 할 수 있습니다.

예제.sql

Apache 2.4.1 릴리즈

드디어 Apache httpd 2.4.1 이 릴리즈 되었네요 ~ 정말 반가운 일이고 많은 변화가 있습니다. 가장 큰 변화중에 하나가 Apache 실행시에 MPM 타입을 선택을 할수 있는 형태로 변한것입니다. 그리고 그중에 가장큰 Event MPM이 추가 된것이죠 그동안 Apache httpd 에서는 prefork, thread 형태의 MPM을 지원했었고 2.2 대에서 실험적으로 Event MPM을 지원했는데 이번에는 정식으로 Event MPM을 지원합니다. 물론 컴파일을 다시 하지 않아도 모듈형태로 실행시 원하는 형태의 MPM을 선택하여 실행시킬수 있는 형태로 바뀌었습니다.

소스의 변화점은 apr, apr-util 이 소스에 포함되어 있지 않은 형태로 배포가 됩니다. 컴파일할때는 좀더 귀찮겠지만 , 자주 바뀌지 않는 apr, apr-util 을 매번 한번에 컴파일 하지 않아도 되는 점이 있습니다. (물론 그전에도 따로 사용해도 괜찮았었죠, 소스에서 포함되지 않았다 라는 것이죠)

기능상의 변화는 비동기 통신에 더좋은 반응을 할수 있는 형태로 바뀌었다는 것인데 이것은 Event MPM을 지원한다는 말 같습니다.

그외 사용상 더 새로운점이 있으면 포스팅을 수정,추가 해보도록 하죠~ ^^

컴파일 방법

선행작업
Apache Portable Runtime Project (http://apr.apache.org) 에 방문하여 apr, apr-util 을 다운로드 받아 설치합니다.
apr, apr-util을 apache httpd 2.4.1 의 srclib 디렉터리내에 apr, apr-util로 압축을 해제 하신다음에 사용하셔도 괜찮습니다.(이전 버전들 처럼 사용)
그외 따로 컴파일 하시려면 apr 과 apr-util을 따로 설치해주시고 Apache httpd 2.4.1 컴파일 설정시에 --with-apr=[apr:prefix] --with-apr-util=[apr-util:prefix] 를 옵션으로 넣어 컴파일 하셔야 합니다.

컴파일
이전버전과 동일하게 사용하셔도 됩니다. 다만 여러가지 MPM을 테스트 하시려면 --enable-mpms-shared=all 옵션으로 모든 MPM을 활성화하여 동적 모듈로 만들어 놓을 수 있습니다. 설정만 바꾸면 괜찮겠죠

컴파일 환경 설정 (configure)
1. apr, apr-util을 Apache httpd 2.4.1 의 srclib 에 포함 시켰을때 --with-included-apr 옵션을 추가 시켜 같이 컴파일을 할 수 있도록 설정해주시면 됩니다.

2. apr, apr-util을 별도로 설치하여 사용중이실때 --with-apr, --with-apr-util 옵션 으로 경로를 설정해주시면 됩니다.

그외 사항은 원하시는 옵션으로 컴파일 하시면 동일하게 동작합니다. ^^ 너무 쉽지 않나요? 일단 오늘 사용해봤기 때문에 좀더 상황을 봐서 포스팅을 해봐야 겠네요 ^^

authz_core:error AH01630: client denied by server configuration
mod_authz_core 에서 제한을 한 경우 위와 같은 메시지가 error log에 기록됩니다. Directory 부분에 해당 Directory 접근 제한을 해제 하셔야 합니다.

Require all granted 모든 접근에 대해 제한을 두지 않습니다.
Require all denied 모든 접근에 대해 제한합니다.
Require env env-var 해당 환경 변수만 허용합니다.
Require method http-method 해당하는 HTTP 메소드(GET/POST등)만 허용합니다.
Require expr expression 표현식이 참일때만 허용합니다.
Require user userid 사용자 아이디에 해당할때만 허용합니다
Require group group-name 해당하는 그룹만 허용합니다.
Require valid-user 허가된 사용자만 허용합니다.

(auth 모듈을 사용하지 않는 다면 해당하지 않습니다.)

Node.js

웹 개발자에게 아주 친숙한 Javascript 문법으로 되어 있으며 Node.js 는 Google Chrome 에서 사용하는 V8 Javascript Engine을 사용하여 아주 뛰어난 성능을 보입니다. (최종 결과물 실행결과가 , 매우 최적화 되어서 빠르다거나, 메모리 사용량이 매우 작다는 뜻은 아닙니다. ^^)

해당 기능만 수행하는 전용 프로그램과는 틀리게 좀 무겁기는 하지만 간단하게 작성하며 유지보수가 쉬운 서버사이드 스크립트 언어로서는 최적의 방법으로 작업을 마무리 할수 있게 도와줍니다.

아래 스크립트는 /tmp/testfile 을 감지하여 파일에 대한 이벤트를 검출하는 것입니다. 변경이 이루어 졌는가 또는 , 이름이 변경되는가를 감지 할 수 있는 스크립트 입니다.

// 파일 경로 
var filepath = '/tmp/testfile';

// Filesystem 모듈 로드 
var fs = require('fs');

// fs watch 메소드를 사용하여 /tmp/testfile 을 감시한다.
fs.watch(filepath, function (event, filename) {
	console.log('event is: ' + event);

	if (filename) {
		console.log('filename provided: ' + filename);
	} else {
		console.log('filename not provided');
	}
});

좀더 공부를 해봐야 하지만, 아직까지 힘들게 작업했던 모든것이 한번에 해결되는듯한 느낌으로 다가오네요 ^^

설치 방법은 간단합니다.

Node.js ( http://www.nodejs.org/ )

http://www.nodejs.org/#download 에 방문을 하셔서 Windows , Macintosh, sourcecode  를 이용하여 손쉽게 설치가 가능합니다.

아직 한글화된 문서는 많이 찾아보기 힘들지만, 대부분 손쉽게 접근할 수 있도록 잘 정돈되어 있습니다.
전체적인 평가로는 너무나 재미있는 녀석이네요 ^^

Halo 액생 해외주문

Mouse Without Borders

Mouse Without Borders 는 KVM 소프트웨어 (하드웨어 KVM 스위치와는 다르게 모니터는 각각의 컴퓨터에 연결된 모니터를 이용합니다.) 입니다. 소프트웨어적으로 여러 컴퓨터를 제어할수 있습니다. Microsoft 에서 정식으로 제공하는 프로그램이 아닌 시험적인 프로그램으로 제품에 대한 지원이 지속적으로 이루어지지 않을 수도 있으며 , 여러가지 오류를 포함 할 수도 있습니다.

이와 비슷한 소프트웨어로는 오픈 소스 프로젝트인 Synergy , Input Director 가 있습니다. Synergy 의 경우에는 여러 OS를 지원하지만 설정 방법이나, 키매핑 등의 문제(한/영전환키)가 있습니다. Mouse Without Borders는 시험적인 소프트위어로서 아직까지 (현재까지)는 아무런 비용없이 사용 할 수 있습니다. Windows를 사용하는 환경이라면 아무런 문제없이 사용가능 합니다.

최대 4대의 장치를 사용할 수 있고, 각 장치에 연결된 여러 입력장지로 다른 장치를 동시에 제어 할 수 있습니다. 또한 서버 클라이언트 구조가 아닌각각의 장치가 서버와 클라이언트를 담당하고 있어 한대의 장치가 연결이 끊겨도 다른 장치는 동시에 사용가능 합니다. 클립보드 공유, 파일 드래그앤 드롭등을 지원하고 여러 편의 성이 지원됩니다. 또한 동일 네트웍 내의 장치를 하나의 키를 통해 연결을 합니다. Windows 로그인 화면에서 입력장치를 사용할 수 있습니다.

http://getsatisfaction.com/mouse_without_borders 에서 다운로드 받을수 있습니다.

Windows 에서 설치시에 관리 권한이 요구 될수 있습니다.

설치 후 키셋팅 및 장치 이름을 설정하면 자동으로 네트웍상의 다른 장치를 찾아 연결을 진행합니다.

TCP 포트는 15100, 15101 포트를 사용하며
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MouseWithoutBorders 에 TcpPort 의 이름으로 REG_DWORD 값으로 TCP포트를 변경 할 수 있습니다.
cmd
reg add HKLM\SOFTWARE\Microsoft\MouseWithoutBorders /v TcpPort /t REG_DWORD /d [포트번호]

요구 사항
Microsoft .NET Framework 2.0 SP2

설치 화면 (라이선스 동의)

Accept and Install 을 눌러 다음으로 진행합니다.

갤럭시 S SHW-M110(SKT/KT) VG14 순정 펌웨어

JQuery 정규식으로 selector 사용방법

$(
	/* selector구문 */
).filter(function(){
	return this.id.match(
			/* 매칭될 정규식 */
		);
}).each(function(){
	// 해당하는 부분만 사용함
});

갤럭시 S2 SHW-M250(SKT/KT) EG14 순정 펌웨어

갤럭시 S2 SHW-M250(SKT/KT) EE31 순정 펌웨어

HTML 5 Cache manifest (HTML 5 Application Cache)

HTML 5 를 이용한 웹 애플리케이션을 개발할때 실시간으로 표현시 느린 부분 이나 즉시 수행해야 할 부분을 미리 읽어 들이거나, 다음 접속때, 오프라인된 내용을 이용할때 미리 저장된 데이터를 사용할 수 있도록 하는 방법입니다. 예를 들어 특정 버튼 클릭시 음성 파일을 재생한다고 했을때 캐시 되지 않고 실시간으로 표현하기 위해서는 이벤트가 발생한 후 음성 파일을 다운로드 후 재생을 하게 됩니다. 이때 발생하는 문제점 중에 하나가 버튼을 클릭 한 후 바로 재생을 못하고 다른 동작이 일어 났을때 재생이 될 수 있다는 점이죠. 이런 것을 최소한 방지 하기 위해 미리 읽어 들일 파일을 브라우저에게 알려주는 것입니다.

W3C HTML Application Cache

<DOCTYPE html>

캐시 파일의 MIME 타입은 text/cache-manifest 입니다.

CACHE MANIFEST
#해당 캐시 파일에 대한 설명 , 버전, 갱신일 등.

# 해당 웹 페이지에서 캐시할 내용입니다.
CACHE:
#캐시할 파일 
./cache.jpg
http://example.com/cache.png

# 네트웍 장애(또는 비슷한 현상 : 연결실패등)시 사용할 내용입니다.
FALLBACK:
#대상 파일	#대체할 오프라인 파일
./cache.jpg ./cache_offline.jpg

# 오프라인시 사용 불가능 한 파일 입니다. (온라인에서만 접근 가능한 파일)
NETWORK:
./networkimg.jpg

위 처럼 사용합니다.
HTML 5 Application cache 는 이벤트를 발생시킵니다.

interface ApplicationCache {

	// 상수 : 업데이트 상태
	const unsigned short UNCACHED = 0;	// 캐시가 안되었음 (캐싱전)
	const unsigned short IDLE = 1;	// 유휴상태 
	const unsigned short CHECKING = 2;	// 캐시 채크중
	const unsigned short DOWNLOADING = 3;	// 다운로드중
	const unsigned short UPDATEREADY = 4;	// 업데이트 준비
	const unsigned short OBSOLETE = 5;	// 캐시 크룹이 사용할 수 없는 상태임
	
	// 상태 값
	readonly attribute unsigned short status;
	
	// 업데이트
	void update();	// 업데이트를 다운로드 하도록함
	void swapCache();	// 캐시된 내용 중 최근 변경된 값을 확인합니다. 
	
	// 이벤트 핸들러 
	attribute Function onchecking;	// 캐시를 체크하고 있음
	attribute Function onerror;	// 오류발생
	attribute Function onnoupdate;	// 업데이트가 안되었다. 
	attribute Function ondownloading;	// 다운로드 중
	attribute Function onprogress;	// 다운로드 비율
	attribute Function onupdateready;	// 업데이트 준비 됨
	attribute Function oncached;	// 캐시 완료
	attribute Function onobsolete;	// 캐시 사용 할 수 없음
};
ApplicationCache implements EventTarget;

// cache 객체 
var cache = window.ApplicationCache;	// window 에서 가져옴

가족 나들이 - 오산 물향기 수목원

5월 8일 오산 물향기 수목원 가족 나들이 ~ 봄꽃이 다 진 후 ~ 가족끼리 여행을 다녀 왔습니다.

수진e 온실앞에서 한컷~

엄마와 함께~

아빠랑.... (얼굴 표정이 -_-)

이쁜짓~

대현이는 잠자느라고 사진을 못찍었네요

MySQL 데이터 타입

정수형
MySQL 의 정수형 타입은 TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 등이 있습니다. 순서대로 1Byte, 2Byte, 3Byte, 4Byte, 8Byte 를 사용합니다. 정수형 데이터를 이용해 연산을 할경우 내부적으로는 BIGINT로 출력이 됩니다. 실제로 연산 결과를 테이블로 저장을 하거나 임시 테이블 생성된 것을 확인해 보면 필드 타입이 BIGINT로 되어 있습니다. 테이블 생성시 INT(10) 과 같이 괄호 안의 숫자의 크기는 MySQL에서의 출력 제한일 뿐 실제 내부 데이터는 4Byte를 차지하게 되어 있습니다. 또한 UNSIGNED 를 사용하여 보다 큰 값을 활용할 수 있습니다. 예를 들어 많이 저장하는 형태인 IP주소는 32Bit의 부호 없는 주소 입니다. 이 것을 MySQL 에 저장을 할때 CHAR(15) 와 같이 저장하는 것 보다는 INET_ATON 함 수를 이용하여 4Byte 의 정수로 저장을 할 수 있습니다. 고정된 길이 형태의 정수형 데이터를 이용하는것이 테이블 이용 측면이나, 공간활용 측면에서 매우 좋습니다. 수십개의 ROW를 다룰때는 상관없지만 매우크게 늘어날 데이터의 경우 꼭 생각을 해보는 것이 좋습니다.

실수형
실수형 데이터 타입은 FLOAT, DOUBLE, DECIMAL 이 있습니다. 이 데이터 형식은 매우크거나 소수점이 포함된 실수를 표현하는 데이터 형입니다. 데이터의 크기는 FLOAT 는 4Byte, DOUBLE 는 8Byte를 이용합니다. DECIMAL은 정한만큼의 크기를 이용해 저장이 가능합니다. 하지만 정확도 면에서는 DECIMAL이 정확합니다. 실수형 데이터에 대한 매우 정밀한 연산을 요하지 않는 이상 DECIMAL보다는 FLOAT, DOUBLE을 사용하는게 바람직합니다.
* UNSIGNED 연산 오류 발생시

문자열
문자열에는 많은 형태의 데이터 형이 있습니다. CHAR, VARCHAR, TEXT, BLOB, BINARY 등이 있습니다. (물론 SMALLTEXT, TINYTEXT 등의 타입도 존재합니다. 하지만 이런것 들은 다루지 않도록 하겠습니다.)
CHAR
고정 형태 문자열입니다. CHAR(20)으로 설정된 필드의 경우 20개의 문자를 저장할 수 있는 공간이 됩니다. 1개의 문자를 저장해도 실제 저장된 영역은 "1Byte + \0 ...." 형태로 20Byte를 사용하게 됩니다. (MySQL에서 문자열 저장시 한개의 필드내 값은 마지막 \0(널문자)가 나오는 곳을 확인합니다.)

VARCHAR
가변 길이의 문자열입니다. 최대 저장할 수 있는 길이를 VARCHAR(200)등 과 같이 지정 할 수 있습니다. 많은 양의 데이터를 저장 할 때는 불필요한 공간을 차지 하지 않기 때문에 저장공간 활용면에서는 많은 효율이 있습니다. 테이블 생성시 ROW_FORMAR=FIXED 를 지정을 하면 CHAR과 동일하게 취급합니다.

BLOB,TEXT
매우큰 형태의 데이터를 저장하는 데이터 타입입니다. 보통 게시판에서의 게시물등이 이에 해당합니다. 이러한 형태의 데이터 타입은 별도의 테이블로 빼 놓는것이 좋습니다.

ENUM
ENUM은 정해진 문자열과 (최대 64개) 수(bit)로 매칭시켜놓은 형태입니다. 예를 들어 Apple = 1, Banana = 2, Melon = 3 등과 같이 ENUM에 정해진 값들은 내부적으로 숫자로 취급됩니다. 데이터의 속성 , 카테고리 등의 상태 값을 지정하는 데이터로 사용시에 매우 좋은 형태의 자료입니다. 예를 들어 CHAR(10)형태의 데이터 타입에 INDEX를 생성하, 똑같은 데이터에 ENUM형태에 INDEX를 사용하는 것과는 하늘과 땅차이 입니다. 8개의 타입이 필드에 지정된다고 했을때 데이터 길이는 ENUM은 1Byte, CHAR형은 10Byte를 차지하게 되고 INDEX또한 매우 근 형태를 나타나게 됩니다.

SET
SET은 여러개의 값을 지정할 필요가 있을때 사용합니다. 예를 들어 읽기,쓰기,실행 3개의 권한을 데이터 베이스에 표현을 해봅시다. 특정 필드에 "철수"의 권한은 "읽기,쓰기,실행" 이렇게 표현을 할 경우 데이터를 읽어온 후에 또다시 처리를 하게 됩니다. 하지만 SET의 경우에는 읽기 = 1, 쓰기 = 2, 실행 = 3 으로 할당(비트)을 합니다. 각각 값은 1개의 비트로 표현을 하고 3개의 값은 3개의 비트로 처리 됩니다. 예를 들어 "000" 비트의 경우 모든 값을 가지지 않는 형태이고 "001"은 읽기, "010" 은 쓰기, "100" 은 실행 으로 저장하는 형태입니다.(저장 크기는 최소 1Byte 최대 8Byte) 이 처럼 권한 등 여러가지 상태값을 저장할때 SET은 매우 좋은 성능을 나타 냅니다.

MySQL 데이터 타입과 설계 방법
MySQL 데이터형의 괄호안 숫자 의미

MySQL Optimization Hint

DELAYED 처리 지연
SELECT 가 매우 바쁜 테이블이고 , INSERT , REPLACE의 경우에는 늦게 처리가 되어도 문제가 없을 경우 사용할 경우 해당 구문은 테이블 작업이 없을때 작업을 하도록 큐에 기록됩니다. LAST_INSERT_ID를 사용할 수 없습니다. 구문의 큐에 적재되었을때는 해당 구문을 바이너리 로그에 남기지 않으며 실제로 구문이 수행이 되엇을때 로그에 남기게 됩니다. 서버가 갑작스레 중단이되거나 시스템이 사용불가 상태에 놓였을때는 해당 구문이 수행되지 않으며 또한 복구 할 수 없습니다. 그리고 파티셔닝된 테이블에서는 사용할 수 없습니다. DELAYED구문은 MySQL 의 시스템 설정 값인 server_delyed_insert_limit 구문 이상으로 많을 경우 지연되지 않고 바로 수행될 수 있습니다. 사용가능한 테이블 엔진은 MyISAM, MEMORY, ARCHIVE, BLACKHOLE 에서 사용가능 합니다.

HIGH_PRIORITY , LOW_PRIORITY
테이블 접근 우선 순위를 다루는 힌트 입니다. HIGH_PRIORITY 는 테이블 락을 기다리는 큐 앞에 우선적으로 힌트가 주어진 질의를 앞에 놓습니다. LOW_PRIORITY 는 다른 테이블 락을 위해 기다리는 구문들 중에 가장 마지막에 위치 시켜 늦게 실행 시키는 것입니다. HIGH_PRIORITY 를 사용가능한 테이블 엔진은 MyISAM, MEMORY, MERGE 에서 사용가능합니다.

SQL_SMALL_RESULT, SQL_BIG_RESULT
GROUP BY, DISTINCT 구문을 수행할 때 임시 테이블 과 정렬중 어떤것을 사용할지 알려주는 것입니다. SQL_SMALL_RESULT 결과가 적으므로 정렬을 위해 인덱스가 포함된 임시테이블을 사용하고 SQL_BIG_RESULT 는 결과를 정렬전에 임시테이블을 만들고 임시테이블에서 정렬을 수행합니다.

SQL_BUFFER_RESULT
질의 실행을 위해 테이블 락을 빨리 해제 하도록 임시테이블을 사용합니다.

STRAIGHT_JOIN
MySQL 이 최적화 실행을 하기 위해 분석되는 시간이 극도로 클때 사용합니다. PROFILING 을 수행했을때 Statistics 상태 값이 매우 클때 이 구문을 사용하여 최적화를 수행하지 않고 나열된 순서대로 테이블을 이용합니다. 이런 질의를 수행할때 이 구문을 수행하는 것 보다는 쿼리 옵티마이저가 최적 화를 수행 할 수 있도록 구문을 재작성 하는것이 좋습니다. (FROM 이후 JOIN 구문에서 테이블간 JOIN 유형을 쓰지 않거나, 나열했을 경우 STRAIGTH_JOIN 으로 수행 됩니다.) MySQL 서버 설정 값 중 optimizer_search_depth 는 쿼리 옵티마이저가 얼마나 실행계획을 철저히 분석할지 결정합니다. Statistics 에서 오래 수행이 된다면 이 값을 줄여주세요 , (최적화된 쿼리를 작성하는것이 더욱 중요합니다.) optimizer_prune_level 는 옵티마이저에게 조사된 행 수를 바탕으로 특정 실행 계획을 무시하도록 합니다. (특별한일이 없을 경우 수정하지 않는게 좋습니다.)

USING INDEX, FORCE INDEX, IGNORE INDEX
EXPLAIN 결과를 봤을때 질의와 관계 없는 인덱스를 사용하고 있으면 USING INDEX, FORCE INDEX를 이용하여 강제적으로 사용할 인덱스를 지정 할 수 있습니다. 또 FOR ORDER BY FOR GROUP BY를 이용하여 정렬/그룹 수행에 필요한 인덱스를 지정 할 수 있습니다.
IGNORE INDEX는 사용되는 인덱스중 무시할 인덱스를 지정합니다. 이 구문으로 지정된 인덱스는 사용하지 않고 무시됩니다.
예

SELECT * FROM table USE INDEX (index_1) IGNORE INDEX FOR ORDER BY (index_2) ORDER BY field_1;

MySQL 의 효율적인 테이블 설계 방법

1. 저장될 형식에 맞추어서 데이터를 정규화 합니다.

어떠한 데이터라도 정규화가 가능한 범위까지 최대한 정규화를 합니다. 예를 들어 학생정보를 입력하는 테이블의 경우 학생의 기본 정보와 학과, 전공, 수강과목등을 하나의 테이블에 몽땅 넣는것 보다는 학과 전공 강의과목을 분류해 다른 테이블로 분류를 하여 학생 테이블에는 관련된 항목에 대한 키를 가질 수 있도록 합니다. 또한, 모든 정보를 가지고 있지 않은 별도의 정보는 별도의 테이블에 따로 저장을 하여 불필요한 공간이 모든 학생 정보에 들어가지 않도록 합니다. 정규화에 대한 자세한 정의는 천천히 다뤄보도록 하겠습니다.

2. 작은 형태의 데이터를 큰 데이터 형으로 저장하지 않도록 합니다.
학생들의 과목 점수를 저장하는 성정 테이블을 예를 들어보도록 하겠습니다. 학생 과목과 함께 학생 성적이 0점에서 최대 100점까지 기록이 된다고 할때 저장되는 필드의 데이터형을 INT, MEDIUMINT , SMALLINT 등으로 지정하지 않고 가장 작은 형태인 TINYINT로 지정합니다. INT의 경우에는 4Byte의 공간을 차지하게 되지만. TINYINT의 경우에는 1Byte의 저장공간을 자치하게 됩니다. 많은 양의 데이터가 쌓이게 된다면 한개의 필드 형에 따른 연산 속도가 많은 차이를 불러오게 됩니다.

3. NULL 의 최소화
MySQL은 조회시 필드의 값이 NULL인지를 판단하는 동작을 하게되어있습니다. 필드에 NULL값을 최소화 하여 쿼리 수행 속도를 높일수 있습니다.

4. ENUM, SET 을 활용
데이터 중 형태, 속성등을 나타내는 값을 저장하기 위해 CHAR,VARCHAR를 사용하는것 보다는 ENUM을 사용하는것이 효율적입니다. 표현상으로는 문자열이지만 내부적으로는 bit 단위로 처리가 됩니다. 도한 2개 이상의 속성을 구분값으로 처리하는것 보다는 SET 형식으로 처리하는것이 훨씬 효율적이고 공간과 쿼리 수행속도에 도움이 됩니다.

5. 테이블 Row format 을 고려합니다.
테이블의 Row format 은 테이블 내에 가변 컬럼들의 유무에 따라 결정이 됩니다. 그 형태에 따라 테이블 연산 수행 속도와 , 저장공간에 많은 차이를 불러옵니다. 예를 들어 특정 프로그램에 대한 수행 로그를 기록하는 테이블을 예를 들어 봅시다. 프로그램 연산시 사용하는 중요한 테이블이 아닌 연산 결과에 따른 로그들을 기록하는 테이블의 경우 수 많은 데이터가 쌓이게 됩니다. 또한, 많은 연산 보다는 필요에 의해 가끔 조회를 하게 됩니다. 이런 테이블의 경우에는 가변형 데이터 타입인 VARCHAR등을 사용하여 테이블의 구조를 잡는것이 좋습니다. 가변형 테이블을 사용함으로서 많은 공간 절약 효과를 나타낼 수 있습니다.

이것 과 반대로 회원 주문내역 테이블을 생각해 봅시다. 많은 회원들이 조회를 하는 주문내역 테이블에서는 가변 형태의 저장 포멧 보다는 고정형태의 필드를 사용하는것이 연산 속도 및 테이블 최적화, 복구에 더 좋습니다. 고정적인 형태의 저장 형태로 인해 필드 데이터의 종료 위치를 계산할 필요도 없으며 데이터 타입 선언 형태만큼 데이터를 불러오게 됩니다. 물론 10개의 문자를 저장할 수 있는 CHAR형태의 필드일 경우에 1개의 문자만 저장해도 실질적 공간은 10byte를 차지하게 됩니다. 테이블 설계시 이 2개의 Row format 에 대해서는 특 실을 잘 따져 보는게 좋습니다. SHOW TABLE STATUS 구문으로 테이블 형태를 알아 볼 수 있습니다.

6. 큰 데이터 형은 별도의 테이블로 분리 합니다.
큰 데이터형식 BLOB, BINARY BLOB, TEXT 등은 별도의 테이블로 저장하는것이 좋습니다. 게시판을 예를 들어 보겠습니다. 여러 목록을 불러올 시에 해당 목록의 번호, 제목, 작성자 등만을 목록으로 표시합니다. 하지만 내용도 같은 테이블에 있다고 하면 해당 내용의 길이 및 데이터 저장 끝부분을 검사 하고 ,또한 ROW의 종료 위치 마저 재 각각임으로 테이블 연산시 많은 시간이 걸리게 됩니다. 이처럼 가늠하기 힘든 크기의 데이터를 가진 컬럼 데이터 타입은 별도의 테이블로 저장을 하여 테이블의 효율성을 높일 수 있습니다.

7. OPTIMIZE TABLE을 주기적으로 수행합니다.
큰 데이터 형을 가지는 테이블에 대한 INSERT / UPDATE 가 많을 경우 그만큼 테이블에 대한 단편화가 심해지게 되어 있습니다. 데이터가 저장되어 있을때 해당 ROW에 대한 업데이트가 진행되었을때 더욱 작은 형태로 데이터를 수정하게 되면 빈공간이 중간에 남게 됩니다. 또, 더 큰 형태로 업데이트를 하게 될 경우 해당 ROW에 대한 데이터를 다른 위치에 저장을 하게 되고 그 위치는 빈공간으로 남게 되어 있습니다. 물론 다른 작은 데이터가 오게 되면 그 공간으로 들어가겠죠 (Windows 의 디스크 조각모음을 생각하시면 됩니다.) 큰 데이터가 자주 업데이트 되거나, 삽입 삭제가 이루어 진다면 가변 길이 저장형태에 따른 테이블 데이터의 단편화게 오게 됩니다. 이와 같은 현상을 최소화 하기 위해 테이블에 대한 OPTIMIZE TABLE을 수행하여 줍니다.

MySQL TO_SECONDS()

-- 입력된 시간까지의 초
SELECT TO_SECONDS('2011-04-21 00:00:00');
-- +--------------------------+
-- | TO_SECONDS('2011-04-21 00:00:00') |
-- +--------------------------+
-- |              63470563200 |
-- +--------------------------+
-- 1 row in set (0.00 sec)
-- 특정 일자 로 부터 흘러간 시간
SELECT TO_SECONDS('2011-01-01 00:00:00') - TO_SECONDS('2008-01-01 00:00:00');
-- +-----------------------------------------------------+
-- | TO_SECONDS('2011-01-01') - TO_SECONDS('2008-01-01') |
-- +-----------------------------------------------------+
-- |                                            94694400 |
-- +-----------------------------------------------------+
-- 1 row in set (0.00 sec)

MySQL Foreign key 체크 끄기

-- 외래키 검사 비활성
SET FOREIGN_KEY_CHECKS = 0;

-- 데이터 입력 부분
SOURCE [덤프 파일]

-- 외래키 검사 활성
SET FOREIGN_KEY_CHECKS = 1;

Apache 2.2 Server MPM event (mpm event)

 Development of this MPM is not complete. Do not use this
 MPM unless you are a programmer willing to help fix it.

 If you are looking for a stable server, you should not use
 the 'event' MPM until it is moved out of experimental.
============================================================

약간 무섭기도 하나.. 상관없이 쭉~ 진행을 합니다. 컴파일 방법인 기존 아파치와 동일합니다. 하지만 다중 I/O 처리를 prefork , thread 등으로 처리하는것이 아닌 I/O event 를 이용하여 빠른 응답을 할 수 있도록 처리를 한다는것입니다.

컴파일을 쭉 진행한 후에 상태를 확인해 보도록 하겠습니다.
$ ./httpd -V
Server version: Apache/2.2.17 (Unix)
Server built:   Apr 15 2011 11:57:42
Server's Module Magic Number: 20051115:25
Server loaded:  APR 1.4.2, APR-Util 1.3.10
Compiled using: APR 1.4.2, APR-Util 1.3.10
Architecture:   64-bit
Server MPM:     Event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)

Server MPM 이 이벤트로 동작하는 것을 확인 할 수 있습니다. ab로 테스트를 해봤을때 대기 시간이 10~20%가량 줄어들었습니다. (기존 ab테스트 내용이 없는 관계로 차후 비교 하여 포스트에 추가하도록 하겠습니다.)

당분간 event 기반으로 사용을 해봐야 할 것같습니다. ^^

nginx 1.0.0, php 5.3.6 (php-fpm)

PHP 5.2.x PHP.net 지원 중단

date_default_timezone_set("Aisa/Seoul") ;

MySQL Query Profiling

MySQL 에서 쿼리의 처리 상태별 소요 시간등을 알아 볼 수 있는 방법은 EXPLAIN 으로 쿼리 JOIN 이나 유효하게 사용되는 키등을 볼 수 있습니다. 또하나의 방법이 profiling 입니다. MySQL 에 질의를 한후 쿼리 파싱 시간, 테이블 Locking , Send data 등의 상태를 시간별로 알아 볼 수 있습니다.또한 질의별 CPU사용 시간등을 상세히 볼 수 있습니다. EXPLAIN 등과 같이 사용하여 좀더 효율 적이고 , 최적화된 질의를 구현 할 수 있습니다. (MySQL 5.1 대에서 사용 가능합니다.)

MySQL profiling 에서 상세히 알아 볼 수 있는 값은 아래와 같습니다.
Block IO : 데이터 블럭 연산 횟수를 나타냅니다. (Disk 에서 블럭 단위로 얼마큼의 데이터 사용했는지 알 수 있겠죠
Context Switches : 문맥 교환 횟수를 화면에 출력 합니다.
IPC : 프로세스간 메세지를 주고받은 수를 화면에 출력합니다
MEMORY : 프로파일링 된 질의를 처리 할때 사용된 메모리를 출력합니다
PAGE FAULT : MySQL 질의 처리시 필요한 메모리 확보를 위해 메모리 할당 시도 입니다.
SOURCE : 질의를 처리 할떄 이용된 함수 , 또는 처리에 필요한 함수 를 구현한 소스파일의 이름입니다.
SWAPS : 스왑된 횟수를 나태냅니다. (메모리 스왑과는 차이가 있습니다.)

쿼리 진행 상황별로 상태 값을 표시해줍니다. 상태에 따라서 아래 사항들이 안나올 수도 있습니다.
initialization : 쿼리를 실행하기 위해 초기화  진행
Opening Tables : 테이블 열기
System Lock : 시스템 락
Table Lock : 테이블 락
checking permissions : 권한 체크
optimizing : 쿼리 죄적화
statistics : 통계 기록
preparing : 실행 준비
create tmp table : 임시 테이블 생성
executing : 실행
copying to tmp table : 임시테이블에 데이터 복사
sending data : 데이터 전송
sorting result : 데이터 정렬
removing tmp table : 사용된 임시 테이블 삭제
init :초기화
end : 종료
query end : 쿼리 종료
freeing items : 사용된 자원 반환
closing table : 테이블 닫기
logging slow query : Slow query 기록

위에 열거한 쿼리 상태 값들의 유무가 쿼리의 성능을 나타내는 척도는 아님을 말씀 드립니다. 단, 위 상태 값들을 실행 시간 및 점유율등을 파악해서 쿼리를 최적화 할 수 있는 것입니다. 그리고 쿼리 진행에 있어서 어떤 단계가 가장 많은 자원을 소비하는지 알아볼 수 있는 용도로 이용 할 수 있는 것입니다.

MySQL Query Profiling 을 사용하기 위해서는 profiling 옵션을 켜주어야 사용 가능합니다. 현재 세션에서 켜는 방법은 SET PROFILING = 1 을 사용하여 켤 수 있습니다. 이 옵션은 현재 연결된 MySQL 세션에서만 적용이 됩니다. 실제 서비스 되는 쿼리를 직접 수행 상태를 파악해 볼때 매우 유용합니다.

쿼리 프로파일링을 수행하면 실제 수행보다 쿼리 수행상태, 수행시간등의 기록등으로 쿼리 진행 상태가 늦어질수 있기때문에 쿼리 최적화를 위해 분석용도로 사용하시면 됩니다.

SET PROFILING = 1옵션을 수행 한 이후 에는 해당 세션에서 일어난 쿼리들의 분석 상태들이 기록이 됩니다. 분석이 진행된 쿼리들의 목록을 조회 하려면 SHOW PROFILES 로 분석이된 쿼리들을 볼 수 있습니다.
mysql > SHOW PROFILES;
+----------+------------+--------------------------------------------------+
| Query_ID | Duration   | Query                                            |
+----------+------------+--------------------------------------------------+
|        1 | 0.00059400 | insert into tTable values (default, '안녕하세요')|
+----------+------------+--------------------------------------------------+
1 rows in set (0.00 sec)

프로파일링의 최대 기록수는 SET PROFILING_HISTORY_SIZE=[NN] 으로 설정 할 수 있습니다. 결과는 Query ID 와 수행 시간 , 그리고 수행된 Query 를 보여주도록 되어 있습니다.
mysql> show profile cpu for query 1;
+------------------------------+----------+----------+------------+
| Status                       | Duration | CPU_user | CPU_system |
+------------------------------+----------+----------+------------+
| starting                     | 0.000101 | 0.000000 |   0.000000 |
| checking permissions         | 0.000023 | 0.000000 |   0.000000 |
| Opening tables               | 0.000046 | 0.000000 |   0.000000 |
| System lock                  | 0.000020 | 0.000000 |   0.000000 |
| init                         | 0.000021 | 0.000000 |   0.000000 |
| update                       | 0.000141 | 0.000000 |   0.000000 |
| Waiting for query cache lock | 0.000011 | 0.000000 |   0.000000 |
| update                       | 0.000011 | 0.000000 |   0.000000 |
| end                          | 0.000010 | 0.000000 |   0.000000 |
| query end                    | 0.000014 | 0.000000 |   0.000000 |
| closing tables               | 0.000117 | 0.000000 |   0.000000 |
| freeing items                | 0.000056 | 0.000000 |   0.000000 |
| logging slow query           | 0.000010 | 0.000000 |   0.000000 |
| cleaning up                  | 0.000013 | 0.000000 |   0.000000 |
+------------------------------+----------+----------+------------+
14 rows in set (0.00 sec)

SHOW PROFILE [ALL|BLOCK IO|CONTEXT SWITCHES|IPC|MEMORY|PAGE FAULT|SOURCE|SWAPS] [Query for [Query ID]] 형식으로 호출 할 수 있습니다. Query profiling 의 수행 상태는 information_schema 의 profiling 테이블에서도 해당 기록을 조회 할 수 있습니다. 일반적인 SELECT 구문으로 조회 할 수 있습니다.

쿼리 프로파일링으로 여러 가지 형태의 분석을 할 수 있으며 , 쿼리 처리 시에 가장 대기가 긴 항목을 알아 볼 수 있습니다.

대현이 50일 사진 촬영~

2월 10일 태어난 대현이가 드디어 50일이 되었습니다.
스듀디오 가서 50일 기념 촬영을 하고 왔습니다 .
오랜만에 가족 나드리를 하고 왔네요 ^^

MySQL SELECT 연산 오류 (BIGINT UNSIGNED value is out of range) 해결

SELECT 절 이후 산술 연산자의 리턴 값은 데이터 형에 따라 종속되지 않고 큰 값을 해결하기 위해 BIGINT 형으로 출력이 됩니다. 하지만. 데이터 타입의 부호 (SIGNED/UNSIGNED) 의 경우에는 종속이 됩니다. 예를 들어 SMALLINT 형의 필드와 INT 형의 연산의 경우 리턴형은 BIGINT 형입니다. 하지만 부호의 경우에는 필드 형에 종속 적입니다. 따라서 형이 틀리거나 음수 연산이 동반이 될 경우에는 아래와 같은 연산 오류가 일어나게 되어 있습니다.

ERROR 1690 (22003) BIGINT UNSIGNED value is out of range

위 같은 오류는 데이터 형이 정해지지 않거나 UNSIGNED 형인 필드에서 연산시 음수를 동반한 연산이 이루어 질 경우 BIGINT UNSIGNED 범위에 벗어난다는 소리 입니다. 해결 방법은 연산 대상에 CAST, CONVERT 로 형을 변환을 해줍니다. 예를 들어 보겠습니다.

mysql> desc test;
+-----------------+-----------------------+------+-----+
| Field           | Type                  | Null | Key |
+-----------------+-----------------------+------+-----+
| nSeq            | int(10) unsigned      | NO   | PRI |
| nAmount         | mediumint(8) unsigned | NO   |     |
+-----------------+-----------------------+------+-----+

위와 같은 테이블이 존재 한다고 했을때 첫번째 ROW 의 값은 아래와 같이 들어 있습니다.
mysql> SELECT * FROM test;
+------+----------+
| nSeq | nAmount  |
+------+----------+
|    1 |     1000 |
+------+----------+
1 row in set (0.00 sec)

위 결과를 아래 처럼 질의를 했을 경우 연산 오류가 발생합니다. 범위를 벗어 났다는 것이죠 unsigned 형의 데이터에 음수를 넣을 수 없다는 것입니다.
mysql> SELECT (nAmount * 1) FROM test;
ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(nAmount * 1)'

MySQL 의 산술 연산시에 테이블 데이터 타입의 부호에 따라 리턴 형의 부호가 결정됨으로 음수 연산이 필요할 경우 아래와 같이 해결 해주면 됩니다.
mysql> -- SELECT CAST(nAmount * 1 AS SIGNED) FROM test;
mysql> SELECT CONVERT(nAmount * 1, SIGNED) FROM test;
+-------------------------------+
| CONVERT(nAmount, SIGNED) * -1 |
+-------------------------------+
|                         -1000 |
+-------------------------------+
1 row in set (0.00 sec)

중요한 것은 MySQL 의 수치형 데이터 타입의 결과 타입은 BIGINT 형이며 부호 (SIGNED/UNSIGNED)는 해당 필드의 부호를 따라갑니다.

Windows 7 Update Backup 삭제

%WINDIR%\SoftwareDistribution\Download

MySQL 5.5.x 설치 [cmake]

득남했습니다.

둘째 대현이

첫째 수진이

상호 검색 후 무료 통화 방법

Windows 7 서비스 팩 1 설치 후 백업 제거

Windows 7 서비스팩 1을 설치 하면 서비스팩 설치 이전 상태로 돌아가기 위한 시스템 파일 과 변경전의 레지스트리 등을 시스템 파일을 백업해두고 있습니다. 또한 서비스팩 의 설치 프로그램 등으로 약 1~1.5GB 정도의 용량을 차지하게 됩니다.

노트북이나 SSD를 사용하는 시스템에서 불가피 하게 늘어난 용량으로 사용을 할 수 없게 됩니다. 물론 설치 시에 서비스팩과 통합이 된 설치 본으로 설치를 했을 경우에는 문제가 없으나 추가로 설치 했을 경우에는 용량이 부담이 됩니다.

이 처럼 서비스팩 1 설치 후 백업으로 인해 용량이 부족할 경우 제거를 할 수 있습니다.

Windows 에 포함되어 있는 관리 도구중 "배포 이미지 서비스 및 관리 도구" 가 있습니다. 관리자 권한으로 실행 하는 도구 입니다.
* 주의 서비스팩 1 정식 버전이 아닌 경우 절대 제거 하지 마세요. 이 작업 후에는 서비스팩 설치 이전 상태로 돌릴 수 없습니다.

관리자 권한으로 명령 프롬포트 실행