12월 5주 있었던 일 정리

elsasticsearch 는 정말 대단해.

지난 주에 elsasticsearch를 사용하면서 대단함을 많이 느꼈어. 자동으로 인덱스를 찾아 값을 매핑하는 일부터 kibana에 자연스럽게 시각화하는 모습까지 기술의 발전을 한 눈에 보는 듯 했지.

복잡한 문제를 쉽게 풀어나갈 수 있게 만든 기능과 빠른 속도로 적재하고 검색 가능하다는 확실한 이미지 덕에 elsasticsearch를 자주 활용하지 않을까 생각이 들었어. 어떤 상황에서 사용하기 적합할까 고려했을 떄, elsasticsearch는 네트워크 상태가 나쁘면 CAP 중 어떤 케이스일까라는 고민을 했지.

8.2 버전에서 정확도를 낮춰 집계 계산 가속화하는 기능을 추가하고(C는 적용 X) 클러스터링 관리에 신경 쓴 모습을 보면 AP에 가깝다고 생각 들었지.

그와 관련된 이야기를 찾아봤을 때, CP 냐 AP 냐를 논쟁하고 있었지.

19년 답변에서는 elasticsearch는 linearizable register가 아니니 CAP 이론이 성립하지 안는다고 해. 일반적으로 elasticsearch 작업은 일관성(Consistency)을 유지하고 가용성(Availability)을 희생하게 된다고 해. 그런데 쓰기와 읽기에서 차이가 발생하나 봐. 쓰기는 일관성을 보장하고, 읽기는 가용성을 보장하게 돼.

linearizable register는 위키에서 명령어를 순차적으로 실행해 정보를 기록하는 레지스터라고 해.

결국 모든 시스템은 옛날에 나왔던 이론으로 시스템을 보완하면서 단방향 적인 특징을 가지지 않게 되나봐.

다시 elasticsearch 학습했던 과정을 공유하자면 문서를 읽고 노션에 정리하고 노션에 정리한 내용을 마인드 맵으로 정리했어.

장점들을 파악하기 위해 구조와 특징을 파악하기 시작했지.

elasticsearch는 여러 개의 노드(elasticsearch)로 구성되고 각 노드(elasticsearch)는 샤드 단위로 문서(RDBMS에서는 테이블)를 저장하게 돼.

마지막으로 버전 업데이트 로그를 확인하면서 어떤 목표를 가지고 있는지 파악했어.

지금까지 파악한 elasticsearch 목표는 다음과 같아.

1. 검색 엔진 AI 기능 도입
2. 저장 공간 효율화
3. 지리 데이터 개발 비중 증가

저장 공간을 많이 사용하고 검색과 관련된 많은 기능이 필요하니 elasticsearch 를 적극적으로 차용 할 수 있어보여. 아직 elasticsearch 에 대해 잘 아는 편은 아니지만 컨셉을 이해했으니 적용에는 문제 없어보이지만, 운영 상황에서 발생하는 트러븍에 대응하기 위해서 동작을 어느정도 이해할 필요성을 느꼈어.