커뮤니티 사이트를 오래 운영하거나, 사용자가 많은 곳을 운영하시는 분들은 무언가를 검색하시다 '계속검색' 이라는 것을 보셨을겁니다.

 

저희는 한 게시판에 게시글이 60만개 가까이 있는데요, 이런 경우에는 겨우 3개월 전 게시글이 기억나서 검색해보면 '계속검색'을 진짜 계속 눌러야합니다.

더군다나 계속검색 기능이란걸 모르는 유저들도 많더라구요.

 

물론 웹서버의 안정적 운영을 위해서 디비전을 나눠 검색하게 한 것도 알지만, 편의성을 위해서 성능을 좀 포기할 의향이 있습니다.

혹시 이 공동의뢰에 관심 있으신 분들이라면 다 그 생각이실거에요.

 

엘라스틱서치란 것이 존재하는 것은 알지만..

이미 구축하시고 운영하시는 분께 여쭤보니, 엘라스틱서치를 위한 별도의 서버도 필요하다고 하시기에 좀 부담스럽더라구요.

 

그래서 혹시나 웹 서버의 성능을 조금 포기하더라도(물론 그렇다고 검색되는 한 디비전 당 게시글 수만 늘리는 정도는..) 게시판 내에서 글 전체 검색이 가능하게 할 기능을 개발 의뢰 같이 하실 분들이 계실지 궁금합니다.  

  • ?

    https://xe1.xpressengine.com/qna/19958341

    적용해보고 서버 자원이남는지 테스트해보셨나요?

    60만개면 단독서버에서 동시에 10명정도 검색해도 큰 무리는 없을실텐데 쿼드코어 8스레드 이상이라면요

     

    저도 유저들이 몰라서 그냥 전체검색 으로 바꿔두었는데 아직까지 이상은 없네요 

  • profile

    위의 댓글처럼 코어에서 $use_division을 수정하셔도 되고, 코어 수정이 부담될 경우 리스트를 가져올 때 애드온 등을 통해 해당 변수값을 바꿔치기하는 방법이 있을 것 같네요.

  • profile
    쫒겨난적은 없고.. 경고먹은적은 있네요..

    회원글 한번에 3000개씩 등록되게 하니까요.

    근데 검색도 한번에 수십명이 접속해서 SQL 에 부화주면.. 음 비슷하지 않을까 싶어요.
  • profile
    성능이 좋고 나쁘고의 문제가 아니라, 서버가 터지는 게 문제입니다.

    엘라스틱이나 스핑크스 같은 별도의 DB에 의존하지 않고 해결하려면 MySQL 5.7 이상 + fulltext index + ngram parser의 조합 정도가 그나마 가능성 있는 검색 솔루션이 될 것 같습니다.

    제대로 된 fulltext index 없이 단순히 테이블 스캔 제한을 해제하는 방식으로 구현한다면 아무리 고성능 서버를 사용하더라도 동접 수십 명이면 뻗게 만들 수 있어요. 앞으로 서버 점검, 튜닝 의뢰시 유쥬얼 서스펙트가 될 것 같으니 기대해 보겠습니다.^^
  • profile profile
    음 그렇군요ㅠㅠ.. 결국 현실적인 대안은 엘라스틱서치겠네요..