폭파!!
오~ 독학으로 다 하셨다니 대단하시네요^^
다른건 몰라도 mysql 쪽은 허정수님이 젤 잘하지 않나 싶습니다.
요즘은 mysql 안한다는 소문이 있지만 :)
그리고 빅데이터 (요즘 가장핫한 이슈인 트렌드)라고 한다면.. 굳이 SQL쪽이 아닌 분산처리쪽이나 NoSQL쪽도 염두하시면 좋을듯 합니다.
@이창민님
웁스. 말씀하신대로 저는 요즘 MySQL 잘 안 해요 ㅎㅎ;
그리도 또한 말씀하신 대로 윗 분도 원하시는 것을 꼭 MySQL로 하실 필요는 없어보이고요.
원하시는 건 OLTP인데 다루시는 데이터는 OLAP인 듯 해서.. 그 괴리를 어떻게 줄여야 할지가 포인트일 듯 하네요. relevant score를 어떻게 매지는지 모르겠지만, 요즘 MySQL의 검색에서 hot 한 건 MySQL와 ElasticSearch를 통합하는 것 같습니다.
물론 전 안 해봐서 잘 모르겠고요;;
2번에 query cache 말씀하셨는데 하루 2만건 Insert이면 초당 약 3번씩 query cache가 reset되는 건데 hit도 높지 않고.. query cache는 off 시키는게 좋을 듯 하고요.
나머지는 다른 분들이 ㅎㅎ;
@허정수님
OLTP 뭔지 몰라서 검색해봤는데 transaction data는 아닌거 같구요. (제가 컨셉에 약한게 가령 특정 document에 facebook like를 누른 횟수? 이런게 아니라...) 새로운 main document가 2만건이란 겁니다. (이거도 곧 3~4만 될듯)
좋은 예는 알바사이트에 이력서 개념이 비슷하구요. (text도 있고 그에 딸린 taggin도 많고 종류별 tag (id)로 검색도 하고 등)
https://www.albamon.com/list/gg/mon_gg_list.asp?gubun=2&scd=
근데 오늘의 등록건수 보니 6천건 뿐이군요.
https://www.albamon.com/list/gg/mon_gg_search.asp
검색 필드 수도 이거랑 비슷하긴 한데. (내거가 더 멋지지만!! ㅋㅋㅋ)
근데 알바몬 같은게 OLTP라고 하나요?
오 메일이 없어서 반응이 없는줄 알았건만!!
@mysql제자
아.. OLTP라는 말은 온라인 조회시스템으로 보시면 됩니다. 대신 응답 속도는 빨라야하고요. 그냥 우리가 보통 사용하는 일반적인 웹 서비스로 보시면 되고요.
반대로 OLAP은 많은 양의 데이터를 분석하는 업무라서 느린 속도도 허용됩니다. 예를 들어 쇼핑몰 관리자가 CRM 툴을 이용하여 성별, 지역별, 시간대별 매출을 보는 상황이라고 보시면 됩니다. 이런 경우는 봐야할 데이터가 많기 때문에 오래 걸릴 수 밖에 없죠. 사용자도 일반 사용자가 아니라 관리자들이기 때문에 속도느리다고 웹 사이트를 이탈(퇴사?)하지는 않습니다. 다만, 너무 느리면 회사 의사 결정이 늦어지지 요즘 '핫'한 빅데이터 플랫폼을 고려해야 겠고요.
네 일반적인 웹서비스 (웹사이트?)가 맞습니다.
답변 감사드립니다!