개요
아파치 루신은 open-source, high-performance, scalable DB 엔진이다. elasticsearch, solr등의 오픈소스 프로젝트들이 루신을 엔진으로 사용하고있다.
특징
1. inverted index 데이터구조를 사용한 인덱싱 구조 사용
2. 데이터 저장 구조가 log-structured 이다. 즉, disk의 도큐먼트 정보 혹은 인덱스 정보가 inplace로 수정되지 않는다. 인덱스를 예로 들면, 인덱스는 여러 세그먼트(immutable, append only)로 구성되고 새로운 segment들이 계속적으로 생성되고 과거의 segment들은 merge를 통해 합쳐져서(compaction이라고 함) 전체 segment 갯수가 일정이하로 유지되는 식의 구조이다
위 1번의 특성 때문에 term 기반 검색이 매우 빠르다는 장점이 있다. 모든 필드의 값들이 inverted index를 통해 document id list와 연결되어있고, 텍스트 필드의 경우엔 형태소분석을 통해 단어들이 추출되어 모든 단어들이 마찬가지로 본인이 포함된 도큐먼트의 리스트와 연결되어있다. 따라서 특정 단어로 검색할 경우 포함하는 document를 바로 알 수 있는 구조이다.
2번의 특성은 file system cache를 매우 효율적으로 사용하게 한다. segment 를 inplace 로 수정하는 일 없이 추가만 하는 구조이기때문이다.
도큐먼트를 추가할때마다 segment 가 생성되므로, 가능하면 bulk insert 를 통하는것이 좋다. single document를 매우빠르게 추가하게 된다면 매우 많은 파일들을 대상으로 segment merge를 진행해야 하는데 이 과정이 cost가 더 들어서 좋지 않다고 한다(왜?)
term 검색 뿐만 아니라 특정 field로 aggregation, sort 등의 속도도 높이기 위한 구조가 마련되어 있다. doc_value 라는 필드의 기능으로 가능하다. doc_value 표시된 모든 필드는 column-oritented 방식으로 따로 저장이되기 때문에 해당 필드로 sort, aggregation, fileter등 연산을 할때 빠르게 할 수 있다.
기본 컨셉
루신이 데이터를 insert 할때, 처음엔 in memory buffer에 들어간다(LSM의 멤테이블과 비슷하다. 하지만 readable하지 않다) 버퍼의 데이터가 특정 수치를 넘으면 segment라고 불리는 단위로 flushed 된다. 모든 세그먼트는 자신의 독립적인 인덱스를 갖고 독립적으로 searchable 하다. 가장 중요한 특징은 데이터가 immutable 하다는 것이고 이 때문에 random io write 가 일어나지 않는다. 데이터가 batch 혹은 한개 append 로만 추가되어 매우 높은 throughput을 갖는다. document가 삭제되면 다른 파일에 해당 데이터가 삭제되었다는 기록이 남는다. 세그먼트들은 끊임없이 merge되는데 LSM의 merge와 비슷하다.
데이터가 세그먼트로 flush 되기 전에(메모리에 있으면서) 아직은 검색가능하지 않다. 루신이 near-realtime 이라 불리는 이유이다. 검색에 반영되기 위해선 인덱스의 형태로 데이터들이 조직화 되어야 하는데, 이게 세그먼트로 저장될때 일어나서 바로검색이 안된다.
Terms
inverted index
https://sease.io/2015/07/exploring-solr-internals-lucene.html
루신의 인덱스는 디스크에 기록된다(Filesystem Directory). 최근의 루신의 경우엔 Os의 메모리 매핑을 이용해 ram으로 필요한부분들을 가져온다. 파일시스템 안에서의 인덱슨느 segment의 연속이라고 볼 수 있다. 각각의 세그먼트는 여러 도큐먼트를 통해 만들어진 독립적인 inverted index이다. 세그먼트는 여러 binary file로 구성되어 인덱스의 데이터구조를 이루고 있으며 압축되어 기록되어있다.
term dictionary
sorted skip list 데이터구조로 구성되어있다.
segment
doc values
- 특정 필드를 doc field 지정하여 활성화(default true)
- column oriented 로 따로 저장되고 관리되기 때문에 해당 필드로의 range 검색이나 sort, aggregation을 매우 빠르게 해준다
stored values
- 특정 필드를 store 체크하여 활성화
- store 체크된 필드들은 disk 에 따로 보관되고 관리된다
- search query가 특정 field 만 읽고싶은 경우, store 필드가 대상이면 _source 로 부터 읽는게 아니라 색인된 값을 읽게된다. store체크는 기본적으로 false.
참고
Analysis of Lucene — Basic Concepts(추천)
https://alibaba-cloud.medium.com/analysis-of-lucene-basic-concepts-5ff5d8b90a53
Lucene IndexWriter: An In-Depth Introduction(추천)
The Lucene Inverted Index(추천)
https://sease.io/2015/07/exploring-solr-internals-lucene.html
Exploring Apache Lucene - Part 1: The Index
https://j.blaszyk.me/tech-blog/exploring-apache-lucene-index/
What is in a Lucene index?
https://de.slideshare.net/lucenerevolution/what-is-inaluceneagrandfinal
lucene document
https://lucene.apache.org/core/7_2_1/
'tech > database' 카테고리의 다른 글
[MySQL] InnoDB 스토리지 엔진 아키텍처 (0) | 2024.09.15 |
---|---|
AWS Elasticache vs MemoryDB 비교 (0) | 2024.05.31 |
AWS Elasticache(redis) 내부동작 정리 (0) | 2024.03.31 |
dynamodb 내부구조 (0) | 2023.10.08 |
AWS Kinesis Data Stream 내부구조 (0) | 2023.10.07 |