메인 DB는 SQL


SQL에서 컬럼과 풀텍스트 조합해서 검색을 쌈빡하게 한다거나 


한글 자연어 검색을 한다거나 하려면 곤란하니까


요즘은 가장 많이 찾는 대안이 엘라스틱 서치잖아?


근데 이것의 단점은 비용이 많이 들어가고 업데이트가 실시간 반영이 느리잖아


업데이트 몇 초 ~ 1분 정도 느린 점은 사용자들이 언제 올릴지 모르는 컨텐츠들에 대하여


단지 목록 열람, 조회를 위한 부분이니 그렇게 민감한 문제는 아니니 넘어가고


비용 문제만 보자


이건 DB엔진 하나 따로 돌리는만큼의 서버 돌아가고 스토리지 잡아먹는데


이럴바엔 그냥 SQL과 호환 잘되게 DB하나 더 열거나 인스턴스 하나 더 열어서 활용하는 게 낫지 않나?


SQL에서 풀텍스트 검색을 영어로 하면 이런 경우는 잘돼


Strawberry로 검색해도 Strawberries가 검색이 잘 되거든


그런데 한글은 딸기들? 산딸기로 검색하면 딸기가 안 나와


그래서 내 목적에 맞게 SQL 검색을 구현하는 거야


테이블 만들어서


... 음 생각해보니까 띄어쓰기, 맞춤법 문제에 산딸기라면 이것을 산, 딸기로 구분을 지어야하는데


이게 산딸, 기로 구분을 지어야할지 판단하는 문제에 봉착되고


여러가지 문제가 많네


그냥 남들이 다 만들어 놓으신 엘라스틱서치 써야겠다


ㅇㅇ