728x90

데이터베이스

    Line 세미나. Redis Pub/Sub을 사용해 대규모 사용자에게 고속으로 설정 정보를 배포한 사례

    개요 - Line Live chat은 Akka로 동작하며 client와 server사이에는 웹소켓으로 동작 - 120대의 채팅 서버와 사이의 커뮤니케이션은 redis pub/sub을 사용 - 채팅의 임시데이터는 레디스에 저장하고 영속 데이터는 정규화해서 배치를 통해 mysql에 저장 - 유저와 시스템을 통해 일부 코멘트를 제어하기도 함 기존 아키텍처 소개 - 방송자가 시청자를 차단하는 경우 차단된 시청자의 코멘트를 해당 방송에서 보여지지 않도록 하는 기능이 있다. - 방송자가 api에 특정 사용자 차단을 요청하면 block 정보를 디비에 저장하고 chat internal api서버에 차단 정보를 전송한다. - 전송 받은 internal 서버는 정보를 mysql에 저장한다. - 웹소켓은 로컬캐시를 뒤지고 ..

    Line 세미나. 대규모 음악 데이터 검색 기능을 위한 Elasticsearch 구성 및 속도 개선 방법 - 2. 클러스터 튜닝

    문제상황 - cms 이외에도 외부에 api server를 열어서 데이터를 저장할 수 있도록 열어줬는데 데이터 부하가 되면서 elasticsearch에 부하가 오고 data node가 100프로 되는 등 문제가 발생된다. - 처음에는 쿼리 튜닝등의 방식으로 문제를 해결하였으나 data node의 cpu가 100프로가 되는등의 문제가 계속 유지되었다. - 데이터 노드를 늘림으로서 검색을 여러 서버로 분산하기 때문에 검색 속도를 늘릴 수 있었다. 하지만 비용이 너무 많이 들었다. - 어느 회사든지 간에 끊임 없는 수평확장은 어렵다. 해결방안 - shard와 replica를 구성하여 부하를 여러 노드로 분산하고 가용성을 늘림 - shard와 replica는 일반적인 규칙이 없다. - 상황에 따라 어떤 shard..

    Line 세미나. 대규모 음악 데이터 검색 기능을 위한 Elasticsearch 구성 및 속도 개선 방법 - 1. 검색 쿼리 개선

    - 발표자 : Taku Tada 시스템 상황 - 유저가 곡을 검색 할 시 meta search api server에 요청이 들어오고 Elasticsearch에 검색을 요청한다. - 8천 500만건의 데이터가 엘라스틱 서치에 들어가 있다. - 지금 발표하는 내용은 음악에 대한 검색과 책 데이터등에서 활용될 수 있다고 생각한다. - 기존에 검색에 사용되던 플드는 오직 Track Name 하나 뿐이었는데 추후 기능 피처로 트랙이름, 부가적인 트랙정보, 앨범이름, 아티스트 이름, 레이블 프로덕트 코드, ISRC와 같응ㄴ 데이터를 조회 조건으로 같이 걸어야했다. 이로인해 기존에 1초 걸리던 검색이 5초 정도의 시간으로 증가하게 되었다. 느렸던 이유 - 기존에는 keyword 타입으로 와일드 카드를 이용해서 조회를..

    Java Lowlevel client bulk api에서 filter_path 사용하기

    https://wedul.site/690 Bulk Index 진행 시 search api 느려지는 현상 해결 방법 리서치 현재 회사에서 하고있는 프로젝트에 경우 Elasticsearch를 사용해서 데이터를 제공하고 있다. 서비스 특성상 초당 받는 데이터 업데이트 요청이 많고 real time engine이 아닌 elasticsearch에 거의 리얼타 wedul.site 이전글에서 작성하였듯이 계속해서 쓰기 작업 시 발생할 수 있는 순단을 줄이기 위해서 여러가지 방법을 찾고 있다. 그중 쓰기 작업이 많이 발생할 때 불필요한 response를 줄이기 위해서 filter_path를 적용해보고자 한다. Filter Path rest api 작업 시 필요한 응답값만 받을 수 있는 기능이다. 하지만 Java Hig..

    Bulk Index 진행 시 search api 느려지는 현상 해결 방법 리서치

    현재 회사에서 하고있는 프로젝트에 경우 Elasticsearch를 사용해서 데이터를 제공하고 있다. 서비스 특성상 초당 받는 데이터 업데이트 요청이 많고 real time engine이 아닌 elasticsearch에 거의 리얼타임 수준의 데이터 변경을 보여줘야한다. 그러다보니 들어오는 요청을 별도의 buffer를 많이 주어 업데이트 할 수 없기 때문에 들어오는 요청을 document id 기준으로 묶어서 bulk 업데이트 될 수있도록 기능을 개발했었다. 회사 블로그에 관련된 내용을 썼었는데 참고 https://techblog.woowahan.com/2718/ 검색을 위한 데이터 다루기 | 우아한형제들 기술블로그 {{item.name}} 안녕하세요. 우아한형제들 검색개발팀 정철입니다. 배달의민족 검색시스..

    Nested field에 대한 대체 필드 flattened type

    일반적으로 하나의 공통 Document내에 서로 다른 속성을 가지고 있어서 별도의 Document인 것 처럼 저장하고 query하기 위해서 우리는 nested obejct 타입을 많이 사용한다. 사용했었던 예로는 가게 - 메뉴, 상품 - 아이템 정도이다. 하지만 nested 필드의 개수만큼 내부적으로 별도의 도큐먼트로 분리되어 저장이 되고 쿼리 시 상위 도큐먼트와 합쳐져서 보여줘야하는 등에 여러 이유로 nested 필드는 많이 느리다. Elasticsearch nested type설명에도 flattened type을 고려해보라고 써있는거 보면 얼마나 좋지 못한지 사용해보지 않아도 가늠해 볼 수 있다. (실사용에서도 퍼포먼스를 극대화 해도 쉽지 않았다.) 그래서 성능이슈를 해결해보고자 찾던 중 7.3 버전..

    Lucene의 segment가 immutable한 이유

    Elasticsearch의 Document의 수정, 삭제 동작이 발생되었을 때 실제 Document를 구성하고 있는 각 shard 내부 Segment는 바로 지워지지 않는다. 대신 해당 세그먼트가 지워졌다고 mark만 하고 수정되었을 경우에는 새로운 세그먼트를 할당한다. 이렇게 동작하는 이유는 Lucene레벨에서 비용을 아끼기 위해서 사용된다고 알고는 있었는데 정확하게 왜 segment가 immutable한지 알지 못해서 정리해 봤다. 1. 동시성 이슈 우선 개인적으로 생각했을 때는 immutable한 데이터의 경우 수정에 의한 고민을 할 필요가 없기 때문에 multi thread 환경에서 특별한 race condition을 고려할 필요가 없어서 이점이 있다고 생각했다. 우연한 기회에 해당 부분에 대해 ..

    Elasticsearch의 Translog 설명

    Lucene을 공부하면서 실제 세그먼트를 조작 하고 인덱싱을 반영 하는 부분을 보면서 Lucene에 commit에 대해서 공부했었다. wedul.site/678 Lucene의 commit과 flush의 차이 Lucene에서 데이터 색인을 위해서 사용하는 IndexWriter의 flush와 commit 두 가지 command의 차이를 정리해보자. 두 개의 operation 이름만 보게되면 동일한 동작을 수행할 것 같지만 실질적으로 다른 동작을 wedul.site 그럼 실제로 Elasticsearch에서 이 Lucene commit에 영향을 받는 부분이 어디인지 알아보게 되면서 translog에 대해 공부해봤다. 우선 translog는 양 자체가 워낙 방대하기 때문에 성능을 위해서는 이 부분에 대한 튜닝이 ..

    Lucene의 commit과 flush의 차이

    Lucene에서 데이터 색인을 위해서 사용하는 IndexWriter의 flush와 commit 두 가지 command의 차이를 정리해보자. 두 개의 operation 이름만 보게되면 동일한 동작을 수행할 것 같지만 실질적으로 다른 동작을 수행한다. 우선 공통적으로 commit과 flush는 둘 다 메모리에 있는 데이터를 디스크에 쓰는 작업을 한다. 하지만 이 부분에 차이점이 있는데 commit은 인덱스를 업데이트하여 디스크에 데이터를 바로 찾을 수 있도록 하는 추가작업을 수행한다. 그래서 만약 lucene IndexWriter에서 flush만 수행하고 commit을 하지 않았다면 해당 인덱스에 대한 변경사항은 검색할 수 없다. 그렇다면 commit을 수행하고 flush를 하지 않는다면 어떻게 될까? 이 ..

    Lucene 기본, 색인, 성능 최적화 정리

    용어 정리 재현율 검색 시스템에서 관련된 문서를 얼마나 빼먹지 않고 찾아두는지 정확도 검색 시스템에서 사용자가 입력한 검색어와 관련없는 문서를 얼마나 정확하세 제거 하는지 fuzzy 레빈슈타인 편집거리를 통해서 입력한 텀과 유사한 텀을 가진 문서를 찾아줌 비교되는 두 단어의 추가, 수정, 삭제에 대한 비용 처리를 하며 비용이 높을수로 서로 다른 term 검색 모델 순수 boolean 모델 지정된 질의에 문서가 해당하는지 아니면 해당하지 않는지를 판단하며 별도의 계산 부분이 없다. 벡터 공간 모델 질의와 문서 모두 고차원(차원은 term을 의미)의 벡터로 표현. 벡터간의 거리를 계산하면 문서와 질의 사이의 연관도나 유사도를 산출 할 수 있다. 확률모델 확률적인 방법을 통해 개별 문서가 질의와 일치하는 확률..

반응형