검색은 콘텐츠다

만약 출시되는 아이폰이나 구글폰에 와이파이와 GPS기능이 빠진다면.

생각하기도 싫다.

이런 악몽같은 정책을 펴는 나라는....
그냥 기우이길 바랄뿐...

검색엔진과 클라이언트의 연결을 위한 브로커용 미들웨어를 RESTFul을 이용해보려고 jetty를 가지고 테스트를 해보았다
지금까지는 그냥 socket 서버를 이용하여 간단한 http서버를 구현하여 사용해왔는데
이것 참, 유지보수하기도 귀찮고, 퍼포먼스 나는지도 의문이기도 해서
유지보수가 되는 오픈소스를 이용하는게 편하다는 평소의 신념대로 jetty로 서버구현을 해서 테스트 했다.
물론 상속해서 쓰면 몇자 코딩할 일도 없으니 말이다.

제기랄,
한글 QueryString은 죽어라 안읽힌다.
한두시간 동안 소스까지 봐보면서 뭐가 문제지...  하다가

UTF-8을 기본으로 사용한다는 사실은 알고 있었다만,
브라우저에서 자동 encoding시켜주는 파라미터를 사용했더먼...
이런 젠장... 브라우저에서 생성되는 encoding는 euc-kr이었다...

euc-kr코드를 가지고 죽으라 테스트하였으니....

검색브로커서버를 일단은 http로 구현을 하고 난 후에
시간되면 jdbc를 구현해봐야겠다...
SQL방식이 api공개하기에는 편할 것이니...

얼마전 jaso님이 블로그에다 제목과 같은 푸념을 해 놓았다.
http://www.jaso.co.kr/292

왜 그 글을 쓴지에 대한 내막을 모르면 도대체 왜 저글을 썼을까 할게다.
사실 그날은 나와 검색엔진에 대해서 얘기하다가,
결국 검색엔진 구조가 jaso님이 생각하는 구조와는 운영면에서 틀리다는 것을 빗대서 한 말이다.
HBase류의 시스템에 대한 회의랄까^^

어제 밤(오늘 새벽인가)에 나도
그냥 한숨을 푹푹 쉬었다.

검색 서비스를 다시하기 위해서
그동안 이리저리 틈나는대로 설계도 하고, 테스트도 하고 했건만...

젠장할,
생각한 개념들이 이미 오픈소스로 다 되어 있는게다...

게다가 잘 추적하기도 힘든 코드들로,
완성되지도 않은 채로 말이다...

루씬이 그러하고, 하둡이 그러하듯이,
직접 만들어서 뭘한담...

어차피 조만간 이들이 나보다 더 잘만들텐데...

역시나
이제는 플래폼과 엔진 부분에서의 개개인의 경쟁력은 없어지려나 보다.

이러한 발전과 확산들이 많은 이들이게 희망이 될듯 하지만
실제로, 그 결과를 따져보면
결국은 무한확장 가능한 재력이 있는 업체로의 집중화를 가져오게 되겠지...
나머지 개발자들에게는 그냥 테스팅에 끝나고 말이다...

구글이 그러하듯이 말이다...

내년과 후년은
클라우딩 컴퓨터로 인하여 새로운 집중화의 시대로 접어들 수 있을까?

결국 검색 분야에서 더이상의 벤처는 없다.?

오라클의 LONG타입은 2G정도의 텍스트를 담을수 있다고 하지만
아무생각없이 쓰다가는 낭패를 당한다.

사실 서버자체의 문제는 아니고 이것을 연결하는 클라이언트(ODBC) 상태의 문제인듯 하다.

1. stored procedure를 이용할 경우에는 3만2천 바이트 정도의 크기가 넘어서면 들어가질 않는다.

2. jdbc를 이용할 경우 prepareStatement를 이용하면
setString으로 입력이 가능하다
그러나. 안타깝게도 이것이 긴경우(대체로 2천바이트 이상일듯..)에도 들어가지 않는다.

이경우 StringReader로 wrap한다음 setCharacterStream를 이용해야 한다.
쩝...

http://www.gruter.co.kr/162 에서의 방법을 통한 문자셋 변경은 약간의 문제가 있다.

이렇게 변경된 상태에서 데이터를 처리한후 export해보면
EXP-00008: ORACLE error 6552 encountered
이런 에러를 만나게 될수도 있다

문제의 원인은
단순 캐리터셋 확인 쿼리문(select * from v$nls_parameters where parameter like '%CHARACTER%';)으론 보이지 않지만 실제로는 하나의 타입에(VARCHAR2..) 여러개의 문자셋이 짬뽕(mixup)이 되어 있기 때문이다.

다음의 명령어로 확인해볼수 있다.
select distinct(nls_charset_name(charsetid)) CHARACTERSET,
decode(type#, 1, decode(charsetform, 1, 'VARCHAR2', 2, 'NVARCHAR2','UNKOWN'),
9, decode(charsetform, 1, 'VARCHAR', 2, 'NCHAR VARYING', 'UNKOWN'),
96, decode(charsetform, 1, 'CHAR', 2, 'NCHAR', 'UNKOWN'),
112, decode(charsetform, 1, 'CLOB', 2, 'NCLOB', 'UNKOWN')) TYPES_USED_IN
from sys.col$ where charsetform in (1,2) and type# in (1, 9, 96, 112);

내 시스템의 경우는 다음과 같이 나온다.
CHARACTERSET                             TYPES_USED_IN
---------------------------------------- -------------
AL16UTF16                                NCHAR
AL16UTF16                                NCLOB
AL16UTF16                                NVARCHAR2
KO16KSC5601                              CHAR
KO16KSC5601                              CLOB
KO16KSC5601                              VARCHAR2
US7ASCII                                 VARCHAR2
UTF8                                     CHAR
UTF8                                     VARCHAR2

다음과 같은 방법으로 alter database를 해줘야 완전히 먹히나 보다.
하지만 이미 저장된 문자셋이 깨질수 있기 때문에 주의해야 할듯 하다.

Correcting the problem
======================
This problem was likely caused when the database character set was changed
incorrectly in the past, and some locations where the character set is stored
were updated and others were not.
In order to correct this problem we can simply run a script that correctly
changes the character set in all the locations to the current database character
set:

a) Make sure the parallel_server parameter in INIT.ORA is set to false or it is not set at all.

SQL>show parameter parallel_server

b) Run the next script in SQLPLUS connected "as sysdba"
Please make sure you have a valid backup to fall back on before you run this script!

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ALTER SYSTEM SET AQ_TM_PROCESSES=0;
ALTER DATABASE OPEN;
COL VALUE NEW_VALUE CHARSET
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER='NLS_CHARACTERSET';
COL VALUE NEW_VALUE NCHARSET
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER='NLS_NCHAR_CHARACTERSET';
ALTER DATABASE CHARACTER SET INTERNAL_USE &CHARSET;
ALTER DATABASE NATIONAL CHARACTER SET INTERNAL_USE &NCHARSET;
SHUTDOWN IMMEDIATE;
STARTUP;
-- yes, 2 times startup/shutdown . This is not a typo
SHUTDOWN IMMEDIATE;
STARTUP;

c) Restore the parallel_server parameter in INIT.ORA, if necessary.

This script doesn't change anything for the data that is already stored, but it
re-enforces database character set to be known in all places where it should be
stored.

After running this you can run the query under "Verification of the cause" once
more, and now there should just 2 sets of character sets, 1 for N-types and 1
for normal types. When that is indeed the case the PLS error will be solved.


Further actions
===============
It would be useful to do a healthcheck on this database because it has been
running with this incorrectly converted character set. The following note
describes a "character set health check" for the database:
Note 225938.1 Database Character Set Healthcheck


총 3번의 셧다운이 일어나야 하는데 왜 마지막에 동일한 셧다운이 두번 연속되야 하는지는 잘 모르겠다.^^
다음과 같이 깔끔하게 문자셋이 변경된다.
CHARACTERSET                             TYPES_USED_IN
---------------------------------------- -------------
UTF8                                     CHAR
UTF8                                     CLOB
UTF8                                     NCHAR
UTF8                                     NCLOB
UTF8                                     NVARCHAR2
UTF8                                     VARCHAR2


참조 : http://forums.oracle.com/forums/thread.jspa?messageID=1529012