NoSQL 데이터베이스

메모리 안에서의 처리가 낳은 새로운 과제

• 액세스가 증가하여 시스템에 걸리는 부하가 CPU 및 네트워크까지 영향을 미치면 그때까지 문제가 되지 않았던 점을 고려해야 할 것임

• CPU , 메모리 상에서 처리 완료하는 시간은 마이크로세컨드 수준이고 밀리세컨드 단위의 시간이 걸리는 디스크 I/O와 비교하면 무시할 수 있는 범위라고 할 수 있음 ⇒ 그러나, 디스크 I/O 오버헤드가 상대적으로 0에 가깝게 새로운 병목현상으로 마이크로세컨드 단위의 처리가 표면화 됨

• 탑재 가능한 메모리 사이즈가 증가하면서 모든 데이터를 메모리에 넣는 것을 고려해야 하는 상황이 됨

• 그러나, 기존의 SQL 데이터베이스는 메모리 내에서 처리하는 데 낭비가 크다는 문제가 있음

SQL 데이터베이스의 과제

• 보통 SQL 에서 주로 사용되는 쿼리는 기본 키를 기반으로 한 검색 ⇒ WHERE 절의 조건 부분의 값만 다른 거의 동일한 쿼리가 계속해서 실행되게 됨

• 이 때 반복되는 작업
• 쿼리의 수신
• 구문 해석
• 테이블의 오픈
• 테이블 잠금
• 실행 계획의 작성
• 레코드로의 액세스
• 테이블의 잠금 해제
• 테이블의 클로즈
• 결과 회신

• 기본 키 검색과 같은 간단한 처리의 경우, 이 중 실제로 애플리케이션에 있어 의미 있는 작업은 쿼리 수신, 레코드로의 액세스, 결과 회신 뿐임. 그 이외의 처리는 모두 불필요한 처리라고 말할 수 있음

• MySQL 벤치마크를 이용해서 프로파일링을 해 보면 SQL의 구문 분석, 테이블 열기/닫기 및 그와 관련하여 발생하는 스레드 사이의 과도한 경쟁과 같은 SQL 데이터베이스 특유의 과제가 큼

NoSQL 이란

• 위의 예제에서 SQL 문의 처리 자체의 비용이 의외로 높다는 것을 알 수 있었음

• 이러한 배경에서 기본 키 검색과 같은 단순하기 짝이 없는 액세스 패턴은 SQL 문과 같은 복잡한 언어를 사용하지 않고 프로그래밍 언어의 라이브러리 함수를 사용하여 직접 데이터를 액세스하는 편이 훨씬 고속으로 되는 것이 아닌가 라는 생각이 많아졌고 → NoSQL이 주목을 끔
• 예 : Redis 명령 get key1

• SQL 데이터베이스는 SQL 문을 보낼 필요가 있고, 그 응답으로 열 이름 등과 같은 메타 데이터도 함께 네트워크 전송되기 때문에 아무래도 낭비가 많음

• NoSQL을 사용하면 네트워크 송수신 전송량이 크게 감소하고 구문 분석을 위한 비용도 크게 감소함 → CPU 사용률 크게 낮춤

NoSQL 은 테이블/파일을 연 채로 놔둔다

• RDBMS에 있어 다른 커다란 포인트로는 테이블 열기 및 닫기 비용을 무시할 수 없다는 점임

• 말할 필요도 없지만 테이블의 레코드에 액세스하기 위해서는 해당 테이블을 미리 열어야 함. 테이블을 열어 둔채로 해두면 좋지 않겠냐 라는 생각이 들 수 있지만 그렇게 단순하지 않음(권한 관리 등의 이유로)
• 테이블을 여는 것은 사용자이기 때문에 누가 열었는지를 관리해야 함(권한 관리 등 다양한 목적을 위해)
• 누군가가 테이블을 연 상태에서 테이블을 다른 사용자가 삭제하거나 정의를 변경할 수 없도록 배타 제어해야 함

• 매우 빠른 SQL 문의 경우에는 SQL 문의 수행보다 이러한 테이블 열기 / 닫기 비용이 더 많이 드는 때가 많음

• 테이블 열기/닫기는 배타 제어가 필요하므로 다수의 세션에서 동시에 액세스하면 동시성 성능이 떨어지게 됨

• NoSQL에서는 테이블의 열기/닫기를 매번 처리하지 않고 클라이언트가 접속/해제를 반복해도 테이블을 오픈한 상태로 유지하도록 제어함 → 테이블 열기/닫기 비용이 발생하지 않아 경합을 크게 줄일 수 있고 성능도 향상됨

일반적인 NoSQL의 단점

• 트랜잭션을 지원하지 않는다 (없어도 별로 상관없는 데이터에만 사용할 수 있다)

• 스키마가 없다 (각 열별로 어떤 값이 들어있는지 RDB보다는 알기 어려움)

• 기본 키 이외의 인덱스를 사용할 수 없다

분산 데이터베이스

• NoSQL이 성능 이외에 주목을 받고 있는 중요한 이유 중 하나가 분산 데이터베이스로서의 용도

• NoSQL 제품 중에는 한대로 충분히 트래픽을 처리할 수 없는 경우에 서버를 추가하기만 하면 자동으로 데이터를 다시 분산 배치해서 처리도 분산 해 주는 제품이 있음 → Write Scaling

• 데이터베이스에 읽기 작업이 대량으로 발생하는 경우는 슬레이브를 대량 투입하거나 캐시 서버 늘리는 대응이 고려될 수 있으나 쓰기 작업이 많이 발생하는 경우는 한 대로 처리할 수 없으면 그 쓰기 처리를 분산시키는 방법밖에 없음 (즉, 하나의 서버에서 모든 데이터를 갖는 것을 포기 한다는 의미)