WAS 비교자료들

분류없음 2009/06/03 16:02 율연
누가 물어보길래 자료를 살짝 찾아봤습니다.
저는 뭐 자바엔지니어가 아닌 까닭에 물어물어...

WAS 비교자료들

http://www.theserverside.com/tt/articles/article.tss?l=ServerMatrix
http://en.wikipedia.org/wiki/Comparison_of_application_servers

기타 자료
http://blog.naver.com/galhan/100051750435

비교자료들은 최근것은 별로 없는 것 같네요.
아마도 도메인 별로 특정 제품을 선호하는 경향도 뚜렸한데다가
비교 자료들이 대부분 벤더들의 자사의 제품을 홍보하기 위한 수단이기 때문에 공정하지 못하기 때문이라고도 합니다.

옆자리에 앉아 있는 모 친한 Architect의 말 인용하자면

엔터프라이즈쪽(금융,공공,제조등)은 ibm websphere 또는 bea weblogic
나머지는 jboss

그래서 제로니모 이런건 어떻냐고 물어 봤더니...
Apache의 Geronimo나 java.net의 Glassfish등은
jboss만큼 유저층이 두텁지 않고 보다 academic한 성격이 강합니다.
tomcat과 비슷한건데
JSR의 spec을 일등으로 구현하는데 의미가 있는 프로젝트라고 할까... 요즘은 안봐서 잘 모르겠네요
Reference Implementation이라고 하죠.

라고 하네요.

어차피 전 전문 자바엔지니어도 아니고 해서 뭐 잘모르겠지만
돈 있으면 웹로직 이런걸 도입해서 쓰면 될꺼 같고 아니라면 JBOSS를 쓰면 된다 이런말 같네요.
물론 회사에서 쓰는 경우 회사 인프라에 어떤것이 더 적합하냐에 따라 달라지겠지네요.
트랙백 3, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.euriion.com/rss/response/68

댓글+트랙백 ATOM :: http://www.euriion.com/atom/response/68

누굴까?

분류없음 2009/05/27 12:08 율연
http://www.cs.utah.edu/~hal/index.html

Hal Daumé III 라는 분인데 꽤 유명한 분인가 보다.
본사에 오신다고 한다.
궁금한거 있으면 메일 보내라고 하는데
뭐 아는게 있어야 메일을 보내지..-ㅁ-

bayesian prediction과 self-learning쪽이 전문인가 보다.
얼굴도 잘생겼다. -ㅁ-
불공평하다.


트랙백 4, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.euriion.com/rss/response/67

댓글+트랙백 ATOM :: http://www.euriion.com/atom/response/67

R언어 추천 책

분류없음 2009/05/20 00:10 율연
갑자기 통계에 필이 꽂혀서 밤12시에 고감자군에게 전화해서 추천해달라고 한 책이다.
일단 감자군이 선택한 책을 선택하면 최소한 손해는 안본다.
묻어가기 모드라고나 할까...'ㅡ';;

R활용통계학
R을 이용한 통계 프로그래밍 기초

낼름 주문 했다.
오면 열공 모드로...

받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.euriion.com/rss/response/66

댓글+트랙백 ATOM :: http://www.euriion.com/atom/response/66

Data mining tool

분류없음 2009/05/19 22:34 율연
http://www.kdnuggets.com/polls/2008/data-mining-software-tools-used.htm

SPSS 관련 자료를 찾다가 이런걸 발견했다.

데이터마이닝 소프트웨어 사용 순위 뭐 그런거 인가보다.

RapidMiner나 Weka 정도는 받아서 사용해 보자.

http://twit88.com/blog/2009/03/14/open-source-text-analytics/

여긴 Text Mining에 소프트웨어에 대해 설명해 놓은 것이 있다.

몇개는 생소한데...

여튼.. 참조하자.

그런데 Matlab이 데이터 마이닝 툴이었던가? 뭐 뭐든 가능하긴 하지만...

그리고 오늘 알았는데 SPSS 제품군들은 죄다 PASW 어쩌구리로 이름이 바뀌었다.

왜 그랬는지...
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.euriion.com/rss/response/65

댓글+트랙백 ATOM :: http://www.euriion.com/atom/response/65


Classifier의 training-set 개수가 - 학습용 데이터의 개수가 - feature수에 비해 상대적으로 적을 경우 classifier의 성능이 떨어진다.
바꿔 말하면 feature의 수가 많아질 수록 품질을 확보하기 위해서 필요한 training-set의 개수가 기하급수적으로 늘어나게 되는데
이것을 차원의 저주라고 말한다.
이는 training-set이 충분하지 않을 때는 가능하면 가장 효과적인 feature들을 선택하여 feature의 수를 줄여주는 것이 일반적으로 유리함을 뜻한다.
다른 관점에서 말하면 classifier에서 사용하는 feature의 수가 많거나 classifier가 복잡하게 설계되어 있다면 더 많은 training-set을 마련해야 함을 말하는데 현실적으로 이는 많은 비용문제를 야기시키게 되고 feature의 개수를 줄이는 것은 training-set의 부족함으로 인해 차원의 저주를 피할 수는 있지만 feature의 수가 적음으로 인해서 충분한 판별능력을 가지지 못하여 classifier의 성능 저하를  발생시킬 수도 있다.

적절한 feature를 선택하는 것, 잘 선택하는 것은 대부분 이 계통의 공부가 깊으신 분들이 공통적으로 하는 말씀들이다.
경험상 대부분의 심각한 성능 문제는 feature와 관계되어 있는 경우가 많았다.
복잡한 알고리즘, 멋진 알고리즘 보다는 적절하고 다양한 알고리즘을 선택해서 비교해 보고
복잡한 feature, 대량의 feature보다는 적절한 feature를 선택해야 한다.
쉬우면서도 매우 어려운 문제이고 언제나 잘 안된다.

feature를 선택할 때는 언제나 아주 많은 고민을 해야하고 반복된 시행착오를 많이 해 봐야 한다고 생각한다.

내용 추가.
내가 적어 놓고도 뭔 말인지 잘...
일단 feature를 잘 선택하면 반은 먹고 들어간다는 말이고
선택을 잘 못하면 본전도 못 건진다는 개인적인 경험에서 나온 얘기다.
오해 및 태클은 사양.

트랙백 3, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.euriion.com/rss/response/64

댓글+트랙백 ATOM :: http://www.euriion.com/atom/response/64

hadoop용 bash alias

분류없음 2009/05/13 14:22 율연
귀찮아서..적어 놓고 붙여 쓰기

HADOOP_CMDS="cat cp du dus ls mkdir mv put rm rmr get put chmod"

alias h='hadoop'
alias hdfs='hadoop dfs'
alias hfs='hadoop fs'
for HADOOP_CMD in $HADOOP_CMDS; do
    eval "alias h${HADOOP_CMD}='hadoop dfs -${HADOOP_CMD}'"
done

전체 gateway에 한꺼번에 push해서 사용하자.
트랙백 4, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.euriion.com/rss/response/63

댓글+트랙백 ATOM :: http://www.euriion.com/atom/response/63

hadoop 0.20

어째서? 어째서?
0.18에서 바로 0.20으로 간 것일까?
이계통의 일들이 다 그렇지만 안정성에 치명적인 타격을 입을 것을 알고도 그렇게 했다는 것은 뭔가 중요한 이유가 있는 것이다.
오해의 소지가 있을지 몰라서 하는 말이지만 hadoop의 version이 하나를 건너 뛰었다는 말을 하는 것은 아니다.
내가 사용하는 환경이 0.18에서 0.19를 건너 뛰고 아직 정식 relase도 아닌 0.20으로 바뀌었다는 말이다.

schduler 때문이라고 얼핏 본 것 같다.
그래서 이 버전에서 당장 크게 변한점은 scheduler부분이다.
hod allocate가 사라졌다.
user는 더 이상 job allocation을 할 수 없다.
다시 말하면 안해도 된다 (할 수도 없고..)
새로운 scheduler가 모 보험회사 광고처럼 "알아서 다 해 줄 것이다"

scheduler가 이런 방식으로 바뀐 것은 다음과 같은 문제 때문이다.
일부 user가 hod allcation을 한 후에 deallocate를 하지 않거나 해서 node가 idle상태로 남아 있게 되고 그로 인해 자원이 낭비되면서 다른 user에게 자원을 할당하지 못하는 문제를 해결할 수 있다.
또 hod allocation을 하기 위해서 기다렸던 대기시간을 대폭 단축시켜준다.
아직은 task자체가 unlimit이기 때문에 대용량을 수행해도 최대한의 task를 할당받아서 아주 빠른시간에 수행이 가능하다.
(복잡한 작업이 아니라면 70000개쯤 순식간에...)
또 일부 개념없는 user의 필요이상의 allocation으로 인해 자원이 낭비되는 부분도 해결된다.
왜냐하면 알아서 해 주니까.
이젠 더 이상
"나도 일좀하게 deallocation 해주지 않을래?"
라는 다른 user들의 메신저 메시지는 이제 안 받아도 된다.



트랙백 177, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.euriion.com/rss/response/62

댓글+트랙백 ATOM :: http://www.euriion.com/atom/response/62

text mining...

분류없음 2009/03/25 04:42 율연
두서없는 정리

문자열의 토막난 단위들을 token이라고 부르기로 하고
document에서 추출한 token을 이용해서 뭔가 그럴듯한 데이터를 마이닝하거나 가지고 놀아 보려고 한다면.
그러니까 topic을 만들어 본다거나 tag를 추출한다거나 topic을 clustering 한다거나 하는 경우등이다.
특별한 이유로 구체적으로 예시를 들 수는 없지만.
여튼 경험상 아래와 같은 것들을 고려해야 한다는 것을 알 수 있었으므로 정리해 두고자 한다.

1. 우선 형태소분석기의 상태를 잘 점검해야 한다.
형분기는 종류별로 기본 작동원리가 다를 수 있고 세부 구현에 따라 결과물이 달라질 수 있으므로 어떤 원리로 작동하는지 어느 정도 선까지는 파악하고 있어야 한다.
어떤 기능까지 이용할 수 있는지 파악해 두어야 한다.
이상한 소리 같긴 하지만 그렇다고 해두자. 그리고 직접 만든 경우가 아니고 구현체를 가져다 쓰는 경우에 그렇다는 말이다.
그리고 기능이고 뭐고 아주 단순한 형분기라면 별 상관 없는 얘기가 되겠다.

2. 형분기의 기본상태만으로는 해결이 안되는 문제가 반드시 발생한다.
text data processing이 다 그러하듯이 우선 dictionary 문제가 무조건적으로 발생한다.
(경험상 거의 발생했다는 얘기일뿐. 확대해석 금지)
natural language 종류와 상관없이 거의 다 그렇지 않겠냐는 것이 나의 추측이다.
(한국어라면 복합명사와 기타의 문제로...)
여튼 dictionary는
형분기가 사용하는 dictionary들이든 전처리, 후처리에 사용하는 dictionary든 해당 domain에 적합한지 직감적으로 파악할 수 있어야하고 없다면 만들어 낼 수 있는 source 정도는 확보해 두는 것이 좋다.
물론 그 source는 실비가 소요될 수 있다. (실비 소요하지 않고 얻을 수 있는 것은 없다고 보는 것이 정신건강상 이롭다. 그리고 dictionary는 품질이 보장 되야하는 것이 기본이다.)
dictionary의 source문제 뿐만 아니라 dictionary를 효과적으로 이용하기 위해서는 각종 고속 알고리즘을 섞어써야 하는 경우가 많다. 고속 알고리즘을 선택적으로 섞어써야 하는 이유는 순전히 대용량 처리때문이고 그게 아닌 경우라면 qps나 tps따위에 민감한 time critical한 경우를 고려해야 하는 경우다.
그런 것이 아니라면 저속 알고리즘을 우선 써도 되겠지만 결국 나중에 가서는 못쓰게 된다.
고속 알고리즘을 섞어 쓴다함은 한 두가지의 단순한 자료구조 알고리즘이 아니라 적절한 요소에서의 적절한 고급 알고리즘을 섞어 쓰는 것을 말한다.(당연한 얘기겠지만..쿨럭)
이는 dictionary의 구성 형태에 따라 달라지기도 한다.
즉 one token dictionary인지 phrase dictionary인지 pattern dictionary인지 meta 정보를 포함한 복잡한 dictionary인지에 따라 다소 다르다.
사실 hash table, b-tree, trie, TST, FSA 등등이 뭐가 좋고 안좋고는 중요하지 않다. 단지 어느것이 어느부분에 더 적합한지 원하는 만큼의 충분한 결과가 나오는지가 쬐끔 중요하다.
사실 요즘 하드웨어가 좋아져서 대충 써도 어지간한 것은 성능을 비교하기도 힘들다.
(그래도 많이 하면 성능차가 조금은 나기 때문에 가능하면 좋은게 좋은거라는...)

3. 분산처리를 고려하자.
졸라 빠른 것을 쓰더라도 일을 졸라 많이 해야하는 경우라면 결국 마지막의 time taken을 찍어보면 졸라 느려지는 것이 기본이다.
분산처리를 하기 위해서 적절하게 심플하고 독립성 있는 구조로 구현체를 마련해 두어야 한다.
분산환경과 single machine 환경을 따로 구분해서 작업하기에는 상황이 너무 cloud 환경쪽으로 심하게 가고 있고
또 처리해야 하는 데이터양도 심하게 많아지고 있다.

4. 그외의 수학적 알고리즘
보통의 공학적 알고리즘은 품질보다는 속도와 관련된 성능문제에 많이 관계되어있지만 수학적 알고리즘들은 품질과 큰 관련이 있다. 수학적 알고리즘은 적절한지 아닌지도 구분하기 힘들만큼 사용하는 방식이나 응용에 따라 차이가 많을 수 있다.  여러가지 방법론을 알아보고 빠르게 비교해서 선택할 수 있어야 한다.


트랙백 176, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.euriion.com/rss/response/61

댓글+트랙백 ATOM :: http://www.euriion.com/atom/response/61

음성신호처리

분류없음 2009/03/25 03:02 율연
Spoken Language Processing

http://kangcom.com/sub/view.asp?topid=1&sku=200411240002


교재로 사용하는 책인데 어떻게 생겼는지 구경도 못해봤다.
백과사전식이라고 하므로 한 번 읽고 끝내는 책은 아닐 듯 하다.
사실 음성신호처리를 전공할 생각은 없지만 살짝 관심은 있다.
아마도 전공을 하게 된다면 전화음성인식쯕으로 해볼까 생각중이긴 하다.
그러나
평상시 책을 즐겨 수집하는(??) 나도 선뜻 꺼려지는 책값의 압박과 활용도의 압박이...

좀 더 고민을...
음..나는 책사는데는 고민하지 말자 주의인데...
트랙백 127, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.euriion.com/rss/response/60

댓글+트랙백 ATOM :: http://www.euriion.com/atom/response/60

배움을 이루는 길은 멀고도 험한 일인것 같다.
특히 나의 경우는 이름에 배움을 이루라는 뜻을 내 의사와 상관없이  넣어 두신 이유로
날마다 공부 열심히 해라고 사람들이 말해 주는 경우나 다름없다.
어리지 않은 나이에 뭔가 부족한 것을 채우기 위해 도전한 다는 것은 어려운 일은 아니라고 생각한다.
다만 좀 더 피곤할 뿐이다.

전혀 성격이 다른 과목 3가지를 수강하게 될 것 같다. -ㅅ-
와우..
내가 많이 미쳤거나 많이 부족한 것임에 틀림없다.
여튼
이 번 학기 성적은 죄다 바닥을 기게 될 것 같다.
피곤함으로 부족해서 이젠 두려움이 다가온다.

트랙백 130, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.euriion.com/rss/response/59

댓글+트랙백 ATOM :: http://www.euriion.com/atom/response/59