달력

3

« 2024/3 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
2010. 5. 11. 10:00

maniadb 검색 100% 활용하기 #1 - Artist 매니아디비2010. 5. 11. 10:00


현재 매니아디비의 검색은 아래와 같은 Category로 나뉘어 있습니다.

1. Artist
2. Album
3. Album - Coverart
4. Album - Release
5. Song

하나씩 설명 드리면 다음과 같습니다.

1. Artist

당연한 이야기겠지만, 가수를 검색하는 방법입니다.
가수의 이름을 넣으면 검색이 됩니다. :)

아래는 가수 소찬휘로 검색한 경우입니다.


그런데 왜 검색 결과가 셋이나 될까요?

소찬휘는 알겠는데.. 뒤의 "이브"는 뭘까요?

네.. 바로 소찬휘씨가 기타리스트 "김경희"로 활동했을때, 그룹이 바로 "이브"입니다. 그래서 "이브"가 나오는거죠.

그 밑에 큐브는.. 소찬휘씨의 본명이 "김경희"라 김경희가 활동한 그룹인 "큐브"가 나오게 됩니다.

신기하죠?


비슷한 원리로.. 김태원을 검색하면 김태원은 물론, 그가 활동한 그룹인 부활, DOA Guitar Project, 게임, 디 엔드 등이 검색됩니다.



찾는 가수를 찾는 것은 물론, 그의 다양한 활동까지 알게 되는 즐거움을 누리세요. :)




:
Posted by 알 수 없는 사용자
2006. 12. 31. 23:36

UTF-8 지원 완료 및 검색 약간 개선 매니아디비2006. 12. 31. 23:36

휴우.. 너무 오랫동안 업데이트를 못했습니다.
직장인이 회사 생활하기 힘들었기 때문이라고 핑계를 대봅니다.. :)

이번 수정의 핵심은 외형적인 차이를 거의 가져오지 못하지만,
HTML 표준의 준수와 유니코드(UTF-8)의 지원이었습니다.

아쉽게도 HTML 표준은 아직 덜 따른 상태입니다만,
IE이외에도 FF(파이어폭스) 지원에는 별다른 무리가 없습니다.

그외에 눈에 띌만한 변화는 검색쪽에 있습니다.
그간 ARTIST/ALBUM/SONG의 이름만 가지고 검색을 허용했었습니다만,
몇몇 분들의 요청에 의해 약간 확장했습니다.

1. ALBUM검색
   앨범 이름뿐 아니라, 가수이름까지 넣을 수 있습니다.
   즉, 특정 앨범을 가수로 한정할 수 있게 된거죠..

사용자 삽입 이미지

2. 노래검색
   가사 검색까지 하고 싶었으나 그 부분은 시간이 여의치 못해서 지원하지 못했습니다.
   하지만, 노래 이름에 몇가지 조합을 추가했습니다.
   노래 이름 & 가수/작사/작곡가 조합이 가능합니다.
   즉, 한대수가 부른 행복의 나라를 검색할 수 있습니다.
사용자 삽입 이미지

   사실 노래 이름을 넣지 않아도 되기 때문에, 한대수가 작곡한 모든 곡의 검색도 가능합니다.
   단, 검색 결과는 100건을 한계로 설정했기 때문에 100곡 이상은 나오지 않습니다.
사용자 삽입 이미지


유니코드 적용은 일부 페이지가 아니자 전체 페이지를 해야하므로 업데이트가 늦었습니다만, 이제 유니코드가 적용되었으니 속도 좀 내보겠습니다.
많은 응원부탁드립니다.

감사합니다.
:
Posted by xfactor

사실 튜닝이 필요할 정도의 traffic이 몰리고 있지는 않지만, 여러가지 속도 저하의 요인이 있기에 튜닝작업을 해봤습니다. 개인 서버인지라 비용을 많이 들일 수 없기에, P3 1G 서버 한대를 사업하는 선배한테 삐대어 운용중인지라, 적어도 어느정도는 버텨줘야 한다고 생각했거든요.
게다가 눈에 보이는 것과는 달리 내부의 DB구조와 query는 상당히 복잡합니다. 애초에 설계할때 많은 튜닝 포인트를 두긴 했으나 저희들의 DB에 대한 욕심이 과했는지 상당히 복잡해서 한달정도 작업에 손놓고 있다가 다시 할려고 하면 기억이 잘 안납니다.. --;;;;


1. 메인 페이지에 대한 튜닝
  - web 2.0과 ajax라는 기술에 대한 관심으로 인해 메인에서는 5개의 서브 페이지를 불러오도록 되어 있었습니다만, 삽질임을 깨닫고, 모듈화하여 한방에 다 불러오게 했습니다. 쓰잘데 없이 DB를 5번 open하게 된 셈이었거든요.
아마 계속 뒀다면 ajax 기술 남용 사례가 되지 않았을까... --;;

  - 첫 페이지의 발전사는

1) google style의 검색창 only : 2006년 1월 버젼!
구글처럼 simple하게 만들어보자는 생각에서 검색창만 가져다 붙였지요.
html 소스 조차 구글꺼를 바탕으로 내용만 바꾼거였으니.. 뭐.. 비슷했지요.. 느낌은 훨씬 구렸지만.. --;;
(당시 로고를 제작해주었던 melani양에게 감사의 말을 늦었지만 이제사 전합니다.. ^^)
(원래는 imhelix가 design해주기로 해놓고 배째서 그냥 제가 대충 하고 삽니다. 흑.. 그를 아는 분들은 그눔에게 구박 좀 해주세요.. T_T)

      

2) 핫아티스트, 핫키워드 노출 시작 : 2006년 2월 버젼!
어느날 큐박스를 가봤는데, 심플하면서도 이쁘더라구요.. 그 흉내 함 내봤지요..
아울러 구글 AdSense를 붙여봤답니다.. ^^;;
(얼빵하게도 제 PC의 LCD 모니터와 놋북의 콘트라스트 조정의 실수로 로고 뒤에 색깔이 있는 줄 몰르고 한동안 유지했었답니다.. T_T)

3) 드뎌 태그 클라우드 적용 : 2006년 3월
이올린 첫페이지에 있었던 태그 클라우드.. 괜히 멋있다는 생각이 들어 흉내함 내봤습니다.
스타일을 훔쳐왔으나 잘 안먹더군요.. 역시 스타일은 예나 지금이나.. 글구 자바스크립트도 참 싫어했는데..

4) 트랙백, 코멘트도 노출 시작 : 2006년 4월
  트랙백과 코멘트 역시 메인에 노출시키기 시작했습니다.
  심플하게 가려던 메인이 점점 지저분해짐을 느끼고 있었으나, 위기 의식 따위는 없었던.. ^^;;;


5) 현재의 모습입니다.. : 2006년 8월
메인으로 트랙백을 올렸지요... maniadb는 음악(에서 시작!) 자료를 전문적으로 찾고자 하는 이들에게 도움을 주고자 하여 만들었습니다. (처음 시작은 제 개인 자료 정리하려고 한거지만.. ^^;;) 하지만, 사람들이 찾고 관심을 갖고 또 미디어에서 조명하는 것들이 어떤 것들인지.. 그런 관심도에 따라 음반(혹은 아티스트)을 중심으로 재배치할 수는 없을까.. 그러한 생각에 의해 트랙백이 제일 위로 올라왔습니다. 지금은 트랙백 날려주는 분들이 적어서, 거의 한두개의 트랙백이 있는 음반이 메인으로 올라오지만, 추후 트랙백 양, 질, 그리고 관심사 등에 따라 차별화를 할 수 있도록 할 생각입니다.. 몇몇 관심있어하시는 분들의 글도 링크 달려고 하고 있구요..
(리뷰 링크를 허락해주신 코너뮤직의 송명하님께 다시 한번 감사드립니다.. ^^)
뭐.. 생각은 많은데 시간이 그닥 많지 않아.. 진도가 잘 안나가네요.. 흑..
DB 퍼가서 블로그에 꾸미실 수 있게 Open API도 만들어드려야 하는데.. 우엉..
여튼.. 지금의 모습입니다.. 어제까지의 5개 sub module을 순차적으로 부르는 것은 배제했습니다.
또, 태그 클라우드에 실시간 변하던 것을 1시간 주기로 업데이트하도록 수정했습니다. 뒤에 말씀드리겠지만 성능에 신경좀 썼습니다..



2. 검색 페이지에 대한 튜닝
검색 페이지에는 좌측에 구글 광고와 linkprice 광고가 있었습니다. 과연 이렇게 했을때 수익이 생길까에 대한 궁금증으로 해봤습니다만.. 결론만 말씀드리면.. 형편없었습니다.. --;;
특히 구글 광고는 페이지 로딩 속도만 느려지고 맘에 안들더라구요.. 그래서, 이번에 과감하게 구글 광고를 날려버렸습니다. 대신 링크프라이스 광고는 늘렸는데, 이유는 제가 자주가는 - 혹은 자주 갈거 같은 - 쇼핑몰 배너를 달아두고, 제가 좀 이용할까 해서요.. 맘씨 좋은 분들이 또 이용해주시면 제가 CD 사는데 보탬이 될것 같긴 합니다.. ㅎㅎ

아티스트 검색 후 음반 페이지를 가기 위해 클릭수가 너무 많은게 짜증나서, 검색 결과가 5개 이하의 경우에는 인기 음반 5개를 보여주고, 검색 결과 1개인 경우는 인기 음반 50개까지 보여주도록 해봤습니다.
이게 query 최적화가 잘 안되서 애먹었는데, 우찌우찌해서 어느정도 해결하게 되었습니다. 여기는 index를 잘 써서 해결된거지, 아직까지 cache를 쓰지는 않으므로 추후 더 튜닝의 여지는 있겠지요.



또, 일전에 말씀드렸다시피 검색 결과 노출 순서는 그간 그 검색어에 대해 사용자들이 어디로 이동했느냐를 분석해서 순위 조정을 한다고 말씀드렸었는데요.. 이걸 실시간 DB에서 계산토록 한거를 수정했습니다. 파일로 로깅하고, 1시간 단위로 batch processing하도록 바꿨습니다. 결과적으로 검색은 거의 순식간에 뜹니다.
(검색 처리 시간과 페이지 로딩 시간을 노출해놓고 있으니 참고하세요.. ^^)

검색도 점차적으로 개선할 생각은 있습니다만, 아직 해야할 것들이 많아서 우선순위에서는 제껴두었습니다. 일단은 정보 제공 페이지인 앨범과 아티스트에 초점을 맞추려고 하고 있거든요.. (노래에 대해서는 정말 하고 싶은게 많은데 아마 연내에는 힘들거 같네요.. 제대로 노래 DB 만들겁니다.. 기술적 준비는 거의 다 되었는데, 이제 노가다 처리에 시간이 모질라서.. 흑)



3. 로깅에 대한 튜닝
기존에 DB에 로깅하던 걸 전부 파일에 로깅하고 1시간 Batch Job으로 DB에 반영하도록 수정했습니다.
결국 트래픽 몰렸을때에 대한 대비이자, 한대뿐인 서버 안 죽일려는 나름대로의 배려라고나 할까요..
(아.. 하드도 모질랍니다.. 스캔을 너무 크게 하고 있는지 몰르겠네요.. 새로 스캔하는 것들은 가로 800이상에 맞추려고 하고 있거든요.. )
결국 로그는 파일에 남게 되므로 DB transaction은 매우 줄게 되구요.. 앞서 검색이나 태그 클라우드 등을 보여주는데 리소스를 적게 먹게 됩니다.
그간 남을 위해서 이런 짓 하다가 내꺼에 할려니깐 참... 기분이 묘하더군요..

요거하다가 잼있는것을 발견했는데, 혹시 관심있는 분들은 이용해보세요..
M$의 사이트에서 공짜로 받아 쓸수 있는 Log Parser입니다.
로그 파일을 DB query로 쓸 수 있고, 로그 파일을 DB나 csv, xml 등으로 덤프도 가능하고.. IIS에서만 쓸 수 있는게 아니라 범용적으로 쓸 수 있습니다. input format과 output format을 설정하고, 그걸 바탕으로 마치 DB에서 query하듯이 할 수 있어서 매우 좋았습니다.


최근에 계속 삽질한게 기술적인 부분이어서 오랜만에 올린 글이 거의 기술이야기가 되어버렸네요.
다음에는 얼마나 DB를 알차게 꾸미고, 사이트를 멋지게 할지... 그런 글을 올리겠습니다..
matia군이 좀 올려줘야 하는데, 이눔이 바쁘다고 제가 자꾸 올리게 하네요.. --;;;

그럼.. 오늘은 요기까지...


:
Posted by 알 수 없는 사용자