MongoDB와 알송 그리고 음악검색 - MongoDB with ALSong and Music Retrieval System
알송 관련 DB에 MongoDB같은 NoSQL을 접목하면 성능상 잇점이 있을까?
이전에 알송 서버쪽 튜닝 및 신규 서비스 개발하면서는 전혀 생각치 못했던 부분들이지만 그런것들로부터 자유로와진 지금은 한번 생각해볼 만할듯...
가사, 노래 정보...접속로그나 푸시 메시지같이 미친듯이 건수가 많은건 아니지만 가사의 경우는 변태적으로 입력하는 사람들이 꽤 많고 외국노래의 경우(특히 일본노래) 원어-발음-해석의 3중주...이로 인한 한 곡에 해당하는 가사 길이가 상당하니 "종이"에 쓰듯 디자인하는 NoSQL의 특징상 어울릴지도...
그러나 최대한 유지보수 인력을 들이지 않고 자동으로 사용자의 입력을 통해 일정부분 자동화 유지보수가 되게 만든 음원 태그정보의 경우에는 중복을 줄이기 위한 관계때문에 좀 어려울지도 모르겠다는 생각...뭐 역시 이 데이터도 로그같은 것들에 비하면 건수는 새발의 피...
MongoDB에서 like검색은....SQL DB에 비해 과연...애시당초 DBMS에다 직접 like검색하는건 무리가 있는듯...특히 일반 사용자를 대상으로 방대한 데이터가 수집되는 케이스엔 더더욱...
백화점급 물류 관련 시스템이라면 like검색 때려도 데이터 건수나 크기가 큰 문제는 안되겠지만...
그렇다면 내용기반 음악 검색의 경우는 어떨까? Shazam 방식을 이용하여 하둡에 접목시킨 논문을 보긴 했으나 과연 실제 운용시에는 어떻게 될까? Philips 방식의 음악 검색은 약 3초 정도의 연속된 오디오 핑거프린트를 비교하는 방식이기에 핑거프린트 하나하나가 떨어져 저장된 경우에는 연속접근이 어렵기 때문에 실제 데이터 비교시 성능 저하가 나타날듯하기도 하고...그러나 이건 실제 실험과 검증이 필요.
MongoDB, 하둡과 카산드라 공부가 필요한 시점이다. 운이 좋다면 음악검색과 이런 시스템간 연동에 대해 연구할 기회가 생기겠지...
Is there any performance improvement, if NoSQL DBMS system like MongoDB is brought in the database of ALSong?
Lyrics and music tag information... it's not massive data like web log or push message but for the lyrics, there are lots of geeks who put lyrics with unusual contents and some lyrics of music from other countries like Japan have long contents which are three kinds of contents as original lyric, pronunciations, and translations so that it might be good to use NoSQL designed for like paper document.
"like" search in MongoDB... I doubt it's good... it's really bad idea to find something with "like" search in a DBMS especially in a case that collects massive data from a general run of users...
And how about music retrieval system? I've seen a paper about shazam system with hadoop but what about in a real system? I guess there is performance decrease with Philips music retrieval system which compares sequencial fingerprints of three seconds with inquiry fingerprints. If sub-fingerprints are stored separately, it might be a problem to compare with fingerprints. But it needs to be experimented and verified.
When I was in charge of tuning and service development of ALSong, I wouldn't think about at all but it's worth to think for I'm free from these things.
But I think it might be difficult to use NoSQL toward tag information system which I designed to maintain automatically with less human resources and prevent data redundancy through relations between database tables. this data is a drop in the bucket to compare with log data.
But it might not be a problem to use "like" search in some small system for a department store.
It's a time to study MongoDB, Hadoop and Cassandra. If I'm lucky, I can have a chance to research about it...
이전에 알송 서버쪽 튜닝 및 신규 서비스 개발하면서는 전혀 생각치 못했던 부분들이지만 그런것들로부터 자유로와진 지금은 한번 생각해볼 만할듯...
가사, 노래 정보...접속로그나 푸시 메시지같이 미친듯이 건수가 많은건 아니지만 가사의 경우는 변태적으로 입력하는 사람들이 꽤 많고 외국노래의 경우(특히 일본노래) 원어-발음-해석의 3중주...이로 인한 한 곡에 해당하는 가사 길이가 상당하니 "종이"에 쓰듯 디자인하는 NoSQL의 특징상 어울릴지도...
그러나 최대한 유지보수 인력을 들이지 않고 자동으로 사용자의 입력을 통해 일정부분 자동화 유지보수가 되게 만든 음원 태그정보의 경우에는 중복을 줄이기 위한 관계때문에 좀 어려울지도 모르겠다는 생각...뭐 역시 이 데이터도 로그같은 것들에 비하면 건수는 새발의 피...
MongoDB에서 like검색은....SQL DB에 비해 과연...애시당초 DBMS에다 직접 like검색하는건 무리가 있는듯...특히 일반 사용자를 대상으로 방대한 데이터가 수집되는 케이스엔 더더욱...
백화점급 물류 관련 시스템이라면 like검색 때려도 데이터 건수나 크기가 큰 문제는 안되겠지만...
그렇다면 내용기반 음악 검색의 경우는 어떨까? Shazam 방식을 이용하여 하둡에 접목시킨 논문을 보긴 했으나 과연 실제 운용시에는 어떻게 될까? Philips 방식의 음악 검색은 약 3초 정도의 연속된 오디오 핑거프린트를 비교하는 방식이기에 핑거프린트 하나하나가 떨어져 저장된 경우에는 연속접근이 어렵기 때문에 실제 데이터 비교시 성능 저하가 나타날듯하기도 하고...그러나 이건 실제 실험과 검증이 필요.
MongoDB, 하둡과 카산드라 공부가 필요한 시점이다. 운이 좋다면 음악검색과 이런 시스템간 연동에 대해 연구할 기회가 생기겠지...
Is there any performance improvement, if NoSQL DBMS system like MongoDB is brought in the database of ALSong?
Lyrics and music tag information... it's not massive data like web log or push message but for the lyrics, there are lots of geeks who put lyrics with unusual contents and some lyrics of music from other countries like Japan have long contents which are three kinds of contents as original lyric, pronunciations, and translations so that it might be good to use NoSQL designed for like paper document.
"like" search in MongoDB... I doubt it's good... it's really bad idea to find something with "like" search in a DBMS especially in a case that collects massive data from a general run of users...
And how about music retrieval system? I've seen a paper about shazam system with hadoop but what about in a real system? I guess there is performance decrease with Philips music retrieval system which compares sequencial fingerprints of three seconds with inquiry fingerprints. If sub-fingerprints are stored separately, it might be a problem to compare with fingerprints. But it needs to be experimented and verified.
When I was in charge of tuning and service development of ALSong, I wouldn't think about at all but it's worth to think for I'm free from these things.
But I think it might be difficult to use NoSQL toward tag information system which I designed to maintain automatically with less human resources and prevent data redundancy through relations between database tables. this data is a drop in the bucket to compare with log data.
But it might not be a problem to use "like" search in some small system for a department store.
It's a time to study MongoDB, Hadoop and Cassandra. If I'm lucky, I can have a chance to research about it...
댓글
댓글 쓰기