Full text index는 full text serach를 위한 index입니다.


예를 하나 들면, 아래 예시 1)과 같은 내용을 어떠한 게시판에서 검색하려고 한다고 가정합니다.




Full Text Index가 무엇인가요?

그냥 index로 찾는 것과 차이가 뭔가요??

예시 1)




만약 게시판에 'index'가 들어가 있는 본문 + 내용이 많다라고 하면 'index' 글자가 들어있는 레코드를 찾으려면 검색 속도가 현저히 떨어집니다..

 그렇다고 내용 필드에 index(정규인덱스)를 심어놔도 이 검색은 전혀 index를 사용하지 못하는 꼴이 됩니다,

예를 들어, SELECT id FROM board WHERE Content LIKE "%index%"  이런식으로 쿼리를 만들어 사용한다고 하면 모든 행의 문자열을 검색하기 때문에 시간이 오래 걸립니다..

이럴때 사용하는 검색이 Full Text Index입니다. 미리(아님 스케줄로 또는 컴파일할 때,) Content필드의 내용들을 모두 검색해서 검색 불필요 단어(예-영어 : a, the ....)을 뺀 나머지 단어들의 Index를 카타로그로 저장하고 있다가,

Full Text로 질의를 하면, 이때 board테이블의 Contents를 검색하지 않고, 미리 만들어진 카타로그를 통해서 레코드를 찾아 결과를 뿌려주는 방식의 검색입니다.



질의도 보통 검색질의와는 다르게 CONTAINS, FREETEXT등의 질의를 사용합니다.

'LogSystem' 카테고리의 다른 글

Elasticsearch 설치 및 사용법  (0) 2016.07.14
ELK와 스플렁크  (0) 2015.11.14
루씬(Lucene)이란?  (0) 2015.11.14
Full text index란?  (0) 2015.11.14
노드 생성, 동작 원리 및 shard란?  (0) 2015.11.14
Elastic search란?  (0) 2015.11.14

1) 노드의 생성 및 동작 원리


사용자가 하나의 머신에서 Elasicsearch를 시작하게 되면, 하나의 Elasticsearch 노드가 생성되며, 이 노드는 동일한 네트워크 상에서 같은 클러스터명을 같는 클러스터가 존재하는 지를 찾게 됩니다. 만약, 연결(join)될 수 있는 클러스터가 없다면 이 노드는 스스로 클러스터를 생성하게 되고, 만약 클러스터가 존재한다면 해당 클러스터에 연결됩니다.

새로운 클러스터가 생성되었다면, 노드에는 아직 어떠한 인덱스도 존재하지 않는 상태이며, 새로운 인덱스를 생성할 때 인덱스를 몇 개의 shard로 나누어 저장할 것인지를 정의할 수 있습니다. Shard의 개수를 따로 지정하지 않는다면, Elasticsearch의 기본 shard 개수인 5개로 데이터가 나누어져 저장됩니다. 만약, 노드가 기존에 존재하던 클러스터에 연결되고 해당 클러스터에 이미 인덱스가 존재한다면 해당 인덱스 shard들은 추가된 노드에 균일하게 재분산 됩니다.(그림 1)


(그림1)



2) shard란?


Elasticsearch를 비롯한 많은 수의 분산 데이터베이스(분산 검색엔진)에서 shard란 일종의 파티션과 같은 의미이며, 데이터를 저장할 때 나누어진 하나의 조각에 대한 단위입니다. 여기에서 주의할 점은 각각의 shard는 데이터에 대한 복사본이 아니라, 데이터 그 자체라는 점입니다. shard가 노드에 저장되어 있는 상태에서 위 (그림1)과 같이 하나의 노드가 추가 된다면, 기존에 존재하던 shards는 각 노드에 균일하게 재분산 됩니다. 이렇게 가장 먼저 1copy씩 존재하는 데이터 shard를 primary shard라고 합니다.

Elasticsearch는 분산 데이터베이스(분산 검색엔진)이기 때문에, 이렇게 데이터를 나누어 저장하는 방식으로 대용량 데이터에 대한 분산처리를 가능하게 합니다. Primary shard는 각 인덱스 별로 최소 1개 이상 존재해야만 합니다. Shard가 많아지면 그만큼 데이터양의 증가에 대한 Elasticsearch 노드의 확장으로 대응이 가능하다는 장점이 있습니다. 하지만, shard 그 자체도 일종의 비용이라고 할 수 있기 때문에 데이터양의 증가 예측치를 이용하여 적절한 수의 shard를 결정하는 것이 중요합니다.


3) replica란? 

Replica는 한 마디로 정의하자면 또 다른 형태의 shard라고 할 수 있습니다. Elasticsearch에서 replica의 기본값은 1입니다. 이 때, replica의 값이 1이라는 것은 primary shard가 1개라는 것을 의미하지 않고, primary shard와 동일한 복제본이 1개 있다는 것을 의미합니다. 즉, replica의 개수는 primary shard를 제외한 복제본의 개수 입니다. Replica가 필요한 이유는 크게 두 가지인데, 그 중 첫 번째는 ‘검색성능(search performance)‘이고, 두 번째는 ‘장애복구(fail-over)‘입니다.

Replica shard는 동일한 데이터를 갖고 있는 primary shard와 같은 elasticsearch 노드 상에 존재할 수 없습니다.


(그림 2)


그림 2) 와 같이 중복되지 않게 각 노드에 존재하게 됩니다. 이러한 이유는 하나의 노드에 문제가 발생해도 나머지 노드에 모든 데이터 shard들이 존재하기 때문에 정상적인 서비스가 가능하며, 문제가 없는 노드에 있던 replica shard가 자동적으로 primary shard가 됩니다.

즉 n개의 노드에서 문제가 발생했을 때, 최소 n+1개의 노드가 동일한 클러스터 안에 존재해야하며, replica의 최소 갯수는 n개, 최대 갯수는 전체 노드 수 - 1개여야 합니다.

'LogSystem' 카테고리의 다른 글

Elasticsearch 설치 및 사용법  (0) 2016.07.14
ELK와 스플렁크  (0) 2015.11.14
루씬(Lucene)이란?  (0) 2015.11.14
Full text index란?  (0) 2015.11.14
노드 생성, 동작 원리 및 shard란?  (0) 2015.11.14
Elastic search란?  (0) 2015.11.14

1) 소개


Elastic search는 아파치의 Lucene 기반으로 개발한 오픈소스 실시간 분산 검색 엔진(서버)으로 JSON 기반의 비정형 데이터 분산 검색과 분석을 지원합니다. 설치와 서버확장이 매우 편리하다는 장점과 실시간 검색 서비스 지원, 분산 및 병렬 처리 그리고 멀티테넌시 기능을 제공하며, 다양한 기능을 플러그인 형태로 구현하여 적용할 수 있는 것이 큰 특징입니다. 아마존 웹 서비스의 클라우드 서비스와 빅 데이터 처리를 위한 하둡 연동도 지원하고 있습니다. 또한 분산시스템이기 때문에 검색 대상의 용량이 증가했을 때, 대응하기가 수월하다는 장점이 있습니다.

Elastic search는 현재 웹 문서 검색, 소셜 데이터 분석, 쇼핑몰 검색 등 다양한 서비스에서 사용되고 있으며, 앞으로도 중•소규모의 데이터부터 빅 데이터까지 광범위한 검색과 분석 서비스에 활용될 것이라는 전망이 있습니다.




2) 특징


 분산과 확장성, 병렬 처리


Elastic search는 보통 3개 이상으로 구성하고 클러스터로 묶어서 처리하기 때문에 하나의 shard가 깨져도 복제되어 있는 다른 곳에 자동적으로 이동해 보여주기 때문에 SPOF(Single Point Of Failure)를 제거합니다. 또한 데이터의 분산과 병렬 처리가 되므로 실시간 검색 및 분석을 할 수 있고,수평적으로 늘어나도록 설계 되어 있기 때문에 더 많은 용량이 필요하면 노드(Elastic search 서버)를 추가하고 클러스터에 추가 후, 추가적인 하드웨어로 이용할 수 있도록 해주면 됩니다.  (같은 클러스터 내에서 라면 초기설정 그대로도 노드끼리 연결이 되지만, 다른 클러스터에 있다면 설정 필요)


고가용성


Elasticsearch 는 동작중에 죽은 노드를 감지하고 삭제하며 사용자의 데이터가 안전하고 접근가능하도록 유지하기 때문에, 동작 중에 일부 노드에 문제가 생기더라도 문제없이 서비스를 제공합니다.


 멀티 테넌시


클러스터는 여러개의 인덱스들을 저장하고 관리할 수 있으며, 독립된 하나의 쿼리 혹은 그룹 쿼리로 여러 인덱스의 데이터를 검색할 수 있습니다.


 전문 검색(Full text search)


Elastic search는 강력한 full text search를 지원합니다.


 문서 중심(Document oriented)


복잡한 현실세계의 요소들을 구조화된 JSON 문서 형식으로 저장합니다. 모든 필드는 기본적으로 인덱싱되며, 모든 인덱스들은 단일 쿼리로 빠르게 사용할 수 있습니다.


 Schema free


JSON 문서 구조를 통해 데이터를 인덱싱하고 검색가능하게 합니다. (NoSQL과 같은 스키마가 개념이 없음) 그리고 사용자의 데이터가 어떻게 인덱싱 될 것인가에 대한 것은 사용자가 커스터마이징 할 수 있습니다.


 플러그인 형태 구현


검색엔진을 직접 수행하지 않고 필요한 기능에 대한 플러그인을 적용하여 기능을 확장할 수 있습니다. 예를 들어 외부에서 제공하는 형태소 분석기나 REST API를 구현하여 적용할 수 있습니다.

'LogSystem' 카테고리의 다른 글

Elasticsearch 설치 및 사용법  (0) 2016.07.14
ELK와 스플렁크  (0) 2015.11.14
루씬(Lucene)이란?  (0) 2015.11.14
Full text index란?  (0) 2015.11.14
노드 생성, 동작 원리 및 shard란?  (0) 2015.11.14
Elastic search란?  (0) 2015.11.14

robobob.co.kr/56

'아두이노' 카테고리의 다른 글

아두이노로 220V 제어  (0) 2015.11.14

구글에서 공개한 리눅스 컨테이너 관리 시스템.

클러스터가 구성된 coreos-docker의 컨테이너들을 집합 개념으로 관리하며 집합이 죽었을 때의 백업집합을 관리하는 service를 운영


Kubernetes의 구조


POD: 컨테이너들의 집합

-       같은 주소컨테이너 2: A또는 B의 포트를 노출 -> 해당포트로 연결

-       호스트가 다르고포트가 여러 개 필요하다면? Overlay network로 해결!



Overlay network란 물리 네트워크 위에 가상 컴퓨터 네트워크 -기존의 데이터 센터 네트워크 망이 어떻게 구성되어 있던지 Network을 넘어 구성하겠다는 것

vxlan이란 L2 Network 확장성을 의미한다. VLAN 기반 네트워크 보다 더욱 많은 Layer 2 Segment 를 구성한다. VLAN 숫자의 제약을 극복 할 수 있음을 의미한다. Mac Over IP/UDP Header 24bit VAND ID를 새롭게 구성하게 되므로 기존의 VLAN 숫자를 뛰어넘는 구성이 가능해진다. VXLAN Header + UDP + IP 기반으로 전송





Ip netns란 리눅스 시스템에서 네트워크는 단지 하나만 존재하는 글로벌 자원네트워크 네임스페이스를 이용하면격리된 네트워크 환경을 구축할 수 있음


내 생각위의 과정을 봤을 때도커에게 할당 받은 ip들을 리더(?) 격인 1개만 남기고 나머지는 해제이후 포드 하나의 그룹 대표 ip로 지정??


ReplicationController복제를 담당

-       ReplicationController 3으로 지정해 POD 3개를 관리하다가, POD1개가 고장 났을 때, Replication Controller에서 해당 포드를 재 생성해 살려냄.

-       새로 생성해서 죽은 pod를 살리면 ip가 바뀌면서 살아남

-       한 서비스 안에 여러 포드를 관리할 수 있음.







Service & proxy

-       Service를 생성하면 별도의 ip가 할당

로드밸런스로 포드에 균일하게 처리할 수도 있고 트래픽을 강제로 한쪽으로만 몰수도 있음.




장점컨테이너들을 묶어 관리하기 때문에 네트워크, volume, 리소스(cpu, ram)가 공유

Pod가 죽어도 rc에서 관리하기 때문에 백업기능

Service를 생성한 후, pod를 연결하면 자동 로드밸런스 기능뿐만 아니라 강제로 트래픽을 포드에 조절할 수 있음.



단점


'CoreOS' 카테고리의 다른 글

[CoreOS]CoreOS란?  (0) 2017.01.28
[CoreOS] cloud-config 파일 유효성 검사  (0) 2017.01.28
[CoreOS] CoreOS 업데이트  (0) 2017.01.28
[CoreOS] CoreOS 설치  (0) 2015.11.14
Vagrant 사용하지 않고 CoreOS 3대 클러스터링하기 (VirtualBox)  (0) 2015.11.14
Kubernetes  (0) 2015.11.14

+ Random Posts