[검색엔진 라이브서치 개발과정 정리]ElasticSearch 와 기존 RDBMS 와의 비교

ES는 기본적으로 No-Sql과 비슷한 구조를 지니고 있다. 따라서 데이터 무결성에 대한 보장이 되지 않는다. 실제로 ES를 활용하는 곳들은 데이터의 성격에 따라서 원본 데이터를 RDBMS에 따로 보관하며 주기적으로 ES의 데이터를 동기화하는 방식을 활용하기도 하는데, 이는 원 데이터에 대한 무결성이 중요한 경우에 그렇다. 그렇다고 해서 ES가 항상 데이터 손실이 일어나는 것은 아니다. 다만 RDBMS의 데이터간 관계를 통해 무결성을 확보하는 구조가 아닐 뿐이다.

 

ES	SQL(RDBMS)	MongoDB(no-sql)
색인(index)	데이터베이스	데이터베이스
샤드(shard)	샤드(shard)	샤드(shard)
매핑/타입(mapping/type)	테이블	컬렉션
문서(document)	row	document
필드(field)	Column	field
객체(JSON)	레코드(튜플)	레코드(BSON)

 

ES의 sql과 관련된 것은 공식홈페이지에 자세하게 나와있다.

 

https://www.elastic.co/kr/blog/an-introduction-to-elasticsearch-sql-with-practical-examples-part-1

An Introduction to Elasticsearch SQL with Practical Examples - Part 1

기본적으로 ES는 빅데이터를 다루기 위해 등장한 것이며, 따라서 스케일 업보다 스케일 아웃이 자유롭다. 대신에 트랜젝션에 대한 보장이 RDBMS에 비해 미비하며, 세부 문서 단위에서의 보안 역시 자유롭지 못하다. 기본적으로 schema-less의 데이터 저장방식을 따르기 때문에 mapping이라는 과정을 통해 schema와 비슷한 형태로 데이터를 분류하지만 훨씬 더 유연하게 작동한다. 이러한 차이를 이해한 상태에서 서비스를 구축하는 것이 중요해 보인다. ES가 검색엔진과 로그 관리 시스템에 가장 많이 쓰이는 이유도 이러한 차이에서 온다고 볼 수 도 있다.