Merge pull request #28 from mainmethod0126/elasticsearch-solo-system-…

…to-db-and-general-system-change-db-selection-process

엘라스틱서치 캐시 관련 포스팅 작성중

pages/elasticsearch/elasticsearch-solo-system-to-db-and-general-system-change-db-selection-process.mdx

@@ -0,0 +1,45 @@
+# elasticsearch 단독 체제에서 RDB 를 병행하는 체제로 전환하기 (1부, 2024-04-17 기준 미완성, 현재 작성중)
+
+현재 사용하던 서비스가 로그 조회 기능을 메인으로 시작되어 elasticsearch 단독 체제로 사용중에 있었으나
+
+몇가지 이슈사항들이 발생하여 RDB 를 병행하는 방식으로 체제 전환을 고려하게 되었다.
+
+## elasticsearch 단독 체제의 문제점
+
+### 태생이 다름
+
+`elasticsearch`는 `검색 엔진`으로 태어났다 주 목적이 `검색` 이다
+`rdb`는 `저장소`로 태어났다 주 목적이 `저장` 이다
+
+위와 같은 이유로 각자의 메인 역할이 있다
+물론 둘다 `저장`과 `검색` 이 가능하나 메인 기능이 아닌 어떻게 보면 `부가기능`이므로 `한계가 명확하다`
+
+### 1. 높은 메모리 점유율
+
+elasticsearch 는 메모리를 많이쓴다
+
+그 이유는 주 목적이 `검색` 이기 때문인데,
+
+`검색`의 중요 요소는 `정확성`과 `속도` 이기 때문이다
+
+구글에서 키워드를 입력하고 검색 버튼을 눌렀을 때 검색 결과를 보기 까지 10초 이상이 걸린다고 생각하면
+
+많은 스트레스가 예상된다.
+
+그렇기 때문에 `elasticsearch` 는 검색 성능을 극대화하기 위하여 작업 처리속도가 느린 `보조기억장치(하드디스크)` 에서 데이터를 바로 검색하기 보다는
+
+메모리 캐싱을 적극적으로 활용하여 `높은 검색 성능`을 발휘환다.
+
+대표적으로 캐싱되는 데이터들은 아래와 같다
+
+#### 필드 데이터 캐시
+
+#### 쿼리 캐시
+
+#### 샤드 요청 캐시
+
+#### 도큐먼트 캐시
+
+### 2. ACID 미지원
+
+### 3. Deep Paging 불가(가능하지만 권장하지 않음)

pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx

@@ -0,0 +1,103 @@
+import { Callout } from "nextra/components";
+
+# elasticsearch 에서 사용하는 캐시들을 알아보자 (2024-04-17 기준 미완성, 현재 작성중)
+
+공홈에서 설명하는 캐시 : https://www.elastic.co/kr/blog/elasticsearch-caching-deep-dive-boosting-query-speed-one-cache-at-a-time
+
+## 페이지 캐시
+
+리눅스 토발즈가 1995년에 리눅스 운영체제의 파일 시스템 관리를 개선하기 위해 가상 파일 시스템(VFS)과 실제 파일 시스템(FS) 사이에 캐시 계층을 도입하면서 이를 `페이지 캐시` 라고 부르게되었다
+
+간단하게 `리눅스의 파일 시스템 캐시 방식` 이라고 보면 된다
+
+파일 시스템 캐시의 정의는
+
+**파일 I/O 가 발생하면 캐시 레이어에 파일 핸들별로 파일 데이터를 캐싱해놓고 동일한 파일에 대한 I/O 발생 시 디스크가 아닌 메모리상의 캐시 데이터를 읽고쓰도록하여 파일 I/O 속도를 빠르게 하기 위한 목적이다.**
+
+<Callout type="info" emoji="❕">
+쓰기의 경우 캐시 메모리상의 데이터를 변경하고 해당 캐시의 데이터가
+변경되었음을 알리는 **dirty(변경됨) 플래그를 ON**한다 그러면 운영체제의
+`쓰기용 워커 스레드(flusher thread)` 가 주기적으로 **dirty 플래그가 ON**
+되어있는 캐시들을 찾아서 디스크에 쓰게 된다
+
+이렇게 뒤늦게 디스크에 쓰이는 것을 [쓰기 지연(writeback)](https://scslab-intern.gitbooks.io/linux-kernel-hacking/content/chapter16.html) 이라고 한다
+
+</Callout>
+
+흔히 알고있는 가상 메모리를 페이지 단위로 관리하는 **페이징 매커니즘과 다른 용어다**
+
+<Callout type="warning" emoji="❔">
+"아니 그럼 그냥 파일 시스템 캐시라고 하지 왜 페이지 캐시라고 부르는거야?"
+
+필자는 처음에 위와 같은 의문이 들었다.
+
+찾아보니 그냥 `페이지 단위` 로 캐싱하는 방식이라 `페이지 캐시` 라고 부르게된 것 같다.
+
+</Callout>
+
+### 엘라스틱서치 세그먼트 불변성과 페이지 캐시의 관계
+
+엘라스틱서치에서는 저장되는 데이터들을 [세그먼트](https://mainmethod0126.github.io/elasticsearch/Basic-Concepts-of-Elasticsearch#%EC%84%B8%EA%B7%B8%EB%A8%BC%ED%8A%B8%EB%9E%80)라는 `파일`로 관리한다.
+
+이 **세그먼트의 아주 중요한 특성**이 있는데 바로 [불변하다](https://mainmethod0126.github.io/elasticsearch/Basic-Concepts-of-Elasticsearch#%EC%84%B8%EA%B7%B8%EB%A8%BC%ED%8A%B8%EB%8A%94-%EB%B6%88%EB%B3%80immutable%ED%95%98%EB%8B%A4)는 것이다
+
+이말은 즉슨, **한번 페이지 캐시된 세그먼트 파일의 경우 세그먼트 파일이 삭제되어서 영원히 안쓰게 되는 경우를 제외하고는 dirty(변경됨) 체크될 일이 없다**
+
+**페이지 캐시의 데이터 변경으로 인하여 디스크 I/O가 발생할 일이 극히 드물다는 뜻이다.**
+
+그렇기 때문에 **거의 대부분의 경우 캐시에서 데이터를 불러오기 때문에 속도가 상당히 빠르다**
+
+위와 같은 이유로, **엘라스틱서치의 세그먼트 불변성은 페이지 캐시와 아주 찰떡이다**
+
+<Callout type="warning" emoji="❔">
+"세그먼트 병합은 삭제가 아니니까 dirty 체크 되는거 아니니?"
+
+사실상 병합도 삭제다.
+
+A, B의 데이터가 하나로 압축되어 AB 라는 새로운 세그먼트 파일이 생성되고 A, B 단일 세그먼트 파일들은 삭제된다
+그러니 세그먼트 파일은 `생성`, `삭제` 두 케이스만 존재하는거라고 봐야한다.
+
+</Callout>
+
+### 유의 사항 1 : 최대 메모리의 반은 남겨놔야한다
+
+운영체제가 관리하기 때문에 커널 메모리 영역을 사용하게된다
+
+그렇기 때문에 elasticsearch 실행 시 [최대 메모리의 반은 남겨놓고 나머지 반에서 heap을 할당하는 것으로 권장](https://www.elastic.co/guide/en/elasticsearch/reference/7.11/tune-for-search-speed.html#_give_memory_to_the_filesystem_cache_2)한다.
+
+**나머지 반은 페이지 캐시를 위한 커널 메모리 영역**으로 남겨놔야하기 때문이다.
+
+만약 이를 무시하고 대부분의 메모리를 elasticsearch heap으로 할당하게되면 페이지 캐시 성능이 저하될 것이다
+
+### 유의 사항 2 : 엘라스틱서치의 높은 리소스 점유율
+
+엘라스틱서치에 굉장히 많은 요청이 들어오는 환경이라면, 페이지가 캐시가 할당될 수 있는 공간을 엘라스틱서치의 세그먼트 파일 캐시가 대부분 차지하게된다.
+
+그렇게되면 엘라스틱서치보다는 I/O가 적은 타 프로세스들에서는 페이지 캐시를 활용할 수 없게될 가능성이 존재하여 타 프로세스의 성능 저하가 발생할 수 있다.
+
+이는 리눅스에서 가장 오랫동안 참조되지 않은 페이지를 교체하는 방법인 [LRU](https://ko.wikipedia.org/wiki/Least_Recently_Used) 알고리즘을 사용하기 때문이다
+
+---
+
+## 샤드 레벨 요청 캐시
+
+**집계로만 구성된 검색 결과를 캐싱함**
+
+## 쿼리 캐시
+
+---
+
+opster 에서 설명하는 캐시 : https://opster.com/guides/elasticsearch/glossary/elasticsearch-cache/
+
+## 노드 요청 캐시
+
+노드 요청 캐시는 필터 컨텍스트에 사용된 쿼리 결과를 유지한다
+결과는 가장 최근에 사용된 항목을 기준으로 제거된다
+
+## 샤드 데이터 캐시
+
+샤드 데이터 캐시는 크기
+
+## 필드 데이터 캐시
+
+---