[데이터넷] 모든 사물이 네트워크로 연결되고, 인공지능 기술로 인해 자동으로 판단하고 동작하는 이른바 스마트 세상은 더 이상 꿈이 아닌 현실이 됐다. 이는 사물인터넷(IoT)의 확산을 야기했으며, 각종 센서에서 수많은 데이터들이 쏟아짐에 따라 기존 방식으로 처리하는 것은 사실상 불가능해졌다. 스마트 시대 경쟁력 제고를 위해 IoT 데이터를 처리하는 방안에 대해 알아본다. <편집자>

스마트 시대가 우리 삶에 매우 빠른 속도로 다가오고 있다. 현재 대한민국에서 가장 많이 회자되고 있는 분야인 ‘스마트팩토리’는 공장이 자율적으로 상호 소통하면서 문제를 진단하고 해결함으로써 더 높은 수준의 제품 생산 및 품질을 보장하는 것을 의미한다. 스마트팩토리의 주요 특징은 크게 세 가지로, ‘지능화’, ‘연결화’, ‘가상화’라 이야기할 수 있다.

연결화는 생산 장비 등을 네트워크를 통하여 연결함으로써 데이터의 빠른 전달을 가능하게 하는 것이며, 가상화는 실제 공장을 데이터 형태로 추상화하는 것을 의미한다. 이 두 가지가 완료된 시점에서 지능화가 가능하다.

지능화는 공장이 디지털 데이터 및 정보를 기반으로 스스로 판단하며, AI 및 생산계획에 따른 자율제어 기능을 의미한다. 지능화를 위한 모든 연산과 판단, 추론 등이 IoT 데이터를 중심으로 이뤄지며, 결과적으로 생산 지능화를 위한 데이터의 저장 및 추출이 매우 중요해진다. 즉, 스마트팩토리를 달성하려면 공장에서 발생되는 IoT 데이터가 그 중심에 있다는 것을 알 수 있다. 이를 어떻게 효율적으로 활용하느냐가 중요한 목표가 된다.

늘어나는 IoT 데이터

IoT 시대에 기하급수적으로 데이터가 발생하는 원인을 살펴보자. 첫 번째는 연결된 단말 장비 개수의 증가이다. 5G를 비롯한 통신망의 확충으로 인해 상상할 수 없을 정도로 많은 장비가 네트워크에 연결되고 있다. IoT 애널리틱스(IoT-Analytics) 자료에 의하면 2025년까지 215억개의 IoT 장치가 네트워크에 연결될 것으로 전망된다.

두 번째는 연결된 장비가 갖는 센서의 개수도 늘어난다는 것이다. 특정 시점의 데이터양은 연결된 ‘장비 개수 × 장비당 센서 수’이므로, 장비가 갖는 센서의 수를 알아보는 것으로 전체 센서의 수를 계산할 수 있다.

세 번째 원인은 데이터 보존 기간의 연장이다. 스마트팩토리를 구축하는 경우, 시계열 데이터를 더 오랫동안 보관하고, 데이터를 더 짧은 샘플링 주기(Sampling Rate)로 읽어 들여야 한다는 요구사항이 빗발치고 있다. 샘플링 주기는 장비나 센서의 반응속도(Latency)와 직결된다. 기업이 필요로 하는 다양한 데이터 분석을 위해 데이터의 장기간 보관이 필수적이라는 인식이 널리 퍼지고 있다.

반도체 공정을 예로 들어보자. 반도체 공정은 수많은 생산 장비를 이용해 24시간 내내 끊임없이 생산이 진행된다. 생산 과정에서 이용되는 장비에도 수많은 센서가 존재하지만, 생산 장비에서 센서 데이터를 외부로 출력해주는 표준 방식이 존재한다.

그 데이터를 모아 분석하면 다양한 방법으로 생산 효율을 올릴 수 있지만, 너무나 많은 데이터가 발생하기 때문에 이를 모두 수집해 저장하는 것은 매우 어려운 과제다. 반도체 장비당 센서의 수는 200~700개에 달하며, 하나의 생산라인에는 장비가 1000여대까지 설치돼 있기 때문이다. 초당 1건의 센서 데이터를 저장한다고 가정하고 장비당 센서의 수를 평균 500개로 잡았을 때, 장비 개수를 1000대로 설정하면 1초에 생성되는 센서 데이터의 수는 50만 건이 된다. 한 달이면 약 1조 건의 데이터를 처리해야하는 셈이다.

그런데 센서당 1초에 한 건씩 입력되는 데이터로는 생산 데이터 분석 및 추적에 부족함이 많다. 그래서 이를 0.1초에 한 번씩 데이터를 모은다고 가정해보자. 데이터 해상도를 높이면서 품질에는 더 큰 고도의 추적이 진행된다. 그러나 이로 인해 초당 생성되는 센서 데이터의 수는 10배로 증가하게 된다. 반도체 생산 시 하나의 웨이퍼가 생산 공정을 거쳐 패키징 되기 위해서는 최대 90일이 소요된다. 생산 과정을 추적하기 위해 칩과 관련된 모든 과거 기록을 유지해야 어느 장비의 어떤 센서가 오류를 감지했는지 확인할 수 있는데, 이를 위해서 최소한 90일간의 데이터를 저장 및 유지해야 한다는 결론이 난다.

이를 데이터양으로 환산해 보면 초당 500만 건이 발생하는 데이터를 저장, 분석해야 한다는 의미다. 90일간 저장할 경우, 약 38조 건의 데이터를 저장해야 한다.

좀 더 상식적으로 생각해 보면 문제의 원인이 되는 특정 시점의 일부 IoT 데이터만 저장하고, 정상 패턴의 IoT 데이터는 버리는 것이 서버 등의 자원 및 에너지를 아끼는 방법이라 여겨진다. 그러나 실제 스마트팩토리 관련 산업에서는 데이터를 일부만 저장하지 않고 전체를 저장하려고 시도하고 있으며, 대부분의 제조 기업은 자신들의 데이터를 버리려고 하지 않는다.

모든 데이터 저장·보관 필요

특정 생산 단위에서 문제가 발생한 것을 발견했다면, 어느 공정에서 품질 문제가 발생한 것인지 추적해 원인을 분석하는 것을 FDC(Fault Detection & Classification)라고 한다. 이를 수행하기 위해서는 생산 과정에서 발생한 센서 데이터를 보존하고 있어야 한다. 생산 도중에 문제를 발견했을 때, 오류가 발생한 제품들을 제거하고 비용을 절약하는 것도 FDC의 주요 목표다.

이를 위해서는 장치에서 생성되는 센서 데이터의 패턴이 문제를 발생시키는 패턴인지를 판단해야 한다. 데이터 패턴을 풍부하게 유지하고 분석해야 오류를 일으키는 데이터 패턴과 정상 상태 패턴을 정확하게 판단할 수 있다. 이는 ‘오류 데이터만 모으면 된다’거나 ‘특정 경계 값만 넘으면 오류로 처리하도록 하면 문제가 없을 것’이라는 생각이 틀렸을 뿐만 아니라, 왜 FDC라는 응용 영역에서 정상/비정상과 관계없이 데이터를 오랜 기간에 걸쳐 대량으로 저장하고 보관해야만 하는지에 대한 중요한 근거가 된다.

비즈니스가 고도화됨에 따라 지속적인 공정 변경 및 생산 라인 추가가 발생하면, 새로운 인공지능 예측 모델을 다시 생성해야 한다. 이 때 과거에 저장된 모든 데이터가 그 빛을 발할 수 있다. 이미 도래한 기계학습 시대에는 오히려 더 많은 데이터가 필요하다는 역설이 IoT 데이터의 폭증을 이끄는 것으로 여겨진다.

스마트 산업이라 불리는 곳에서 발생하는 대규모 데이터는 대부분 센서 데이터 형태다. 앞으로도 이러한 센서 데이터는 더 많이 발생할 것이 분명하며, 이러한 데이터에 대한 저장과 처리가 모든 곳에서 요구될 것이다. 분명히 지난 세대와는 다른 새로운 데이터 처리에 대한 시장의 요구가 높아지고 있는데, 현재 이런 데이터에 대한 대응을 어떻게 하고 있는지 살펴보자.

IoT 데이터 전쟁 시작

IoT 시장에서 데이터 전쟁이 시작됐다. 누가 가장 빨리, 그리고 효율적으로 폭증하는 데이터를 처리하느냐가 앞으로 벌어질 전쟁에서의 승패를 가늠하는 중요한 잣대가 된다. 전통적인 트랜잭션 기반의 데이터베이스인 RDB(Relational Database)은 공기와 같이 우리 삶에 직결돼 있다. IT 관련 담당자가 학교나 기업에서 사용하고 배우는 거의 모든 데이터베이스가 바로 이 종류다. 대표적으로 오라클(Oracle), MySQL, 마리아DB(Maria DB), 포스트그레SQL(PostgreSQL), MS-SQL, 사이베이스(Sybase), DB2 등이 있으며, 이 외에도 기술하지 않은 수십여 종의 유사한 제품들이 존재한다.

RDBMS의 편의성과 익숙함에도 불구하고 21세기 IoT 데이터를 처리하기에는 너무 많은 제약사항이 있다. 그 이유는 RDBMS가 트랜잭션 기능을 통해 데이터를 처리하기 때문이다. 트랜잭션은 은행의 송금이나 비행기 예약과 같은 복잡하고 어려우면서 연속된 비즈니스 업무를 하나의 온전한 업무 단위로 처리하기 위해 고안된 기술 요구사항이다.

지난 30년간 지속적으로 데이터 처리의 신뢰도가 중요한 비즈니스 영역에서 RDB가 사용돼 왔다. 그러나 데이터의 처리비용과 관계없이 이론적으로 완벽하게 보장되는 방향으로 기술 개발이 이뤄졌기 때문에 현재의 하드웨어 성능으로 초당 수만 혹은 수십만 건을 처리하는 것은 불가능하다. 트랜잭션을 지원하는 RDBMS는 성능을 위해 아주 큰 비용을 지불하고 있다.

첫 번째는 연산복구 비용이다. 수행 중인 트랜잭션은 완벽하게 끝나거나, 혹은 수행되기 이전의 상태로 완벽하게 복원돼야하기 때문에 RDBMS는 모든 트랜잭션의 변경 연산에 대해 로그(Log)라는 2차 저장매체에 기록을 수행한다. 검색 성능을 높이기 위해 다양한 인덱스를 생성하면 할수록 입력 성능은 떨어지는 상충(Trade-off)이 발생한다. 이러한 로깅 비용이 데이터베이스의 성능을 저하시키는 가장 중요한 이유다.

두 번째는 잠금(Locking) 비용이다. 데이터베이스에서 하나의 트랜잭션은 다수의 테이블에 접근하고, 그 트랜잭션이 동시에 여러 건 수행돼야 한다. 이러한 환경에서 높은 동시성을 제공하고, 잠금으로 인한 교착상태(Deadlock)를 방지하기 위해 매번 모든 데이터 접근에 대해 잠금을 수행하게 되는데 이 비용이 매우 크다.

세 번째는 비효율성이다. 일반화된 데이터 저장 구조 및 인덱스 구조의 복잡성 때문에 RDBMS는 느릴 수밖에 없는 한계를 스스로 인식하고, 이를 극복하기 위해 노력해왔다. 그 결과 데이터베이스는 매우 복잡한 구조로 진화하며 전체적인 코드의 복잡성이 더 커졌다. 이 복잡성은 단순한 연산에 대해서도 복잡한 내부 로직을 수행할 수밖에 없는 구조적인 한계를 가진다.

이러한 이유로 IoT 데이터의 입력 성능이 최대인 경우라도 초당 수천 건으로 제한될 수밖에 없다. 더 큰 문제는 저장된 대규모의 데이터에 대해 수억 건 정도의 질의를 수행하면 마치 함흥차사처럼 답이 없어 개발자를 괴롭힌다는 점이다.

이 같은 IoT 데이터 전쟁에 뛰어든 것은 RDBMS만이 아니다. 일반 텍스트 파일 기반 제품, 스플렁크(Splunk), 엘라스틱(Elastic) 등 검색 엔진 기반 솔루션, 하둡(Hadoop) 기반 솔루션, 그리고 NoSQL(Not Only SQL) 기반 제품 등이 있다.

텍스트 기반 솔루션, 데이터 접근 어려워

일반 텍스트 파일(Plain Text File)은 기존 데이터베이스로 해결이 어려운 경우 가장 빈번하게 찾는 방법이다. 가장 쉽고 강력하지만 뒤처리가 복잡하다. 쉽게 말하면, 쏟아져 나오는 센서 데이터를 그대로 일반 텍스트 파일에 저장하는 방식이다. 그러나 이렇게 저장할 경우 다음과 같은 문제점이 발생한다.

첫째, 데이터 접근이 어렵다. 일단 압축된 상태이기 때문에 압축을 해제해야 하고, 이를 위해서는 콘솔이나 임의의 솔루션을 통해서 접근하고, 복사해야 한다. 사용자의 특정 요구를 위해 정규화되지 않은 관리비용이 크게 발생한다.

둘째, 데이터 검색 시 성능이 느리다. 이것이 더 큰 문제다. 접근하기 위한 대상 파일을 이미 알고 있는 경우에는 그나마 쉽지만, 특정 패턴을 찾는다고 가정할 경우 업무량과 비용의 측면에서는 재앙 수준이다. 모든 압축된 텍스트 파일을 순차적으로 일일이 확인하면서 특정 데이터나 패턴을 찾아야 하는데, 그 데이터의 크기가 수 테라바이트(TB)에 달한다면 어떻게 해야 할까.

최근 몇 년 동안 각광을 받았고, 비즈니스 영역에서는 대세로 자리 잡은 기법이 스플렁크나 엘라스틱 등 검색 엔진 기반 솔루션이다. 이들이 각광을 받는 이유는 우선 특정 산업계의 시계열 데이터가 일반 텍스트 파일로 존재한다는 것이다. 검색 엔진은 텍스트 파일을 읽고 인덱싱하는데 최적화돼 있다.

대규모의 데이터 크기에도 적절한 성능을 보장한다. 대규모 로그성 빅데이터를 보유하는 많은 기업들이 이를 채택하고 되고, 그중에서도 검색과 부분 분석이 필요한 보안 영역에서 특히 더 많은 고객을 확보하게 됐다.

또한 직관적이고 쉬운 사용자 인터페이스(UI)도 강점이다. 사용자는 몇 가지 조작만으로 이전에 볼 수 없었던 자신의 빅데이터 분석 결과를 화려한 그래픽으로 볼 수 있다.

검색 엔진 기반 솔루션, 실시간 처리 어려워

그러나 검색 엔진 기반 솔루션들은 IoT를 위한 센서 데이터 처리에는 적합하지 않다. 그 이유로는 첫째, 모든 처리 가능한 데이터가 일반 텍스트 형태로 구성돼야 한다는 점이다. 모든 데이터를 무조건 일반 텍스트로 변환하면서 발생하는 저장 공간의 낭비와 변환 비용이 매우 크다.

둘째, 실시간 처리에 대한 어려움이다. 검색 엔진 기술의 핵심 중 하나인 역인덱스(Inverted Index) 생성은 특정 문서에 포함된 임의의 키워드 기반으로 검색할 수 있지만, 인덱스를 생성하는 데 상당히 많은 시스템 비용을 지불해야 한다. 그래서 이런 기술은 실시간 처리보다는 포털사이트와 같이 하루에 한 번 전체적인 인덱스를 구축하는 곳에서 주로 사용된다.

셋째, 대규모의 시계열 센서 데이터 특성을 지원할 수 없는 구조적인 한계와 느린 성능이다. 시계열 센서 데이터는 시간 값에 대해 높은 카디널리티(Cardinality)를 가지며, 각각의 센서가 대량의 데이터를 생산한다.

카디널리티가 높다는 것은 센서의 종류와 시간 값이 매우 다양해 중복되는 데이터가 적다는 의미다. 이런 특성의 데이터 분석 기능을 지원하는 것은 검색엔진의 원래 목적에 비추어볼 때 불가능에 가깝다. 센서의 종류가 고작 수십 종류거나 데이터의 총량이 수백만 건이면 처리가 가능하나, 수억, 수십억, 수백억 건의 센서데이터를 굳이 비효율적인 검색엔진에 넣을 이유가 없다.

동시 사용자 처리 약해

하둡은 구글의 내부 데이터 처리 엔진인 빅테이블과 동일한 자바 기반의 오픈소스 버전이다. 구글과 같은 인터넷 검색 엔진 서비스를 하며, 수집된 웹 문서를 위한 역인덱스가 필요하다. 문제는 수집된 웹 문서의 크기가 수백 TB가 넘어간다는 것과 이 문서를 모두 읽어서 역인덱스를 구성해야 한다는 것이다. 이를 위해 하둡이 개발됐고 ‘빅데이터 솔루션’이라는 별명을 갖게 되며 온갖 대량 데이터를 수집할 수 있는 것으로 포장됐다. 이에 수년간 각 기업 데이터 담당자들은 너나할 것 없이 하둡을 도입했다. 그러나 하둡의 기본 특성을 이해하지 못하면 바느질할 곳에 망치와 못을 사용하는 꼴이 될 수 있다.

첫째, 하둡은 최소 4대 이상의 클러스터로 구성해야 한다. 서버가 4대 필요하다는 이야기가 될 수도 있다. 하둡 특성인 하드웨어 병렬 구성이 선행돼야 한다는 의미다.

둘째, 처리할 모든 데이터를 하둡 파일 시스템(HDFS)에 저장하도록 돼 있으며, 파일의 부분 변경이 불가능하다. 따라서 정교한 데이터 처리를 위한 세밀한 파일 조작이 어렵다.

셋째, 데이터 분석을 위해 기본적으로 맵리듀스(Map Reduce)를 수행하게 되며, 이는 클러스터 준비 시간에만 몇 초 이상의 시간이 걸린다. 센서 데이터처럼 초당 수만, 수십만 건의 데이터가 생성될 때 이 과정이 과연 수행될 수 있을지가 의문이다.

넷째, 동시 사용자 처리가 거의 불가능하다. 기본적으로 하둡은 단일 사용자를 기준으로 모든 데이터를 검색하는 구조다. 다수의 사용자가 동시에 맵리듀스를 수행하는 것은 시스템에 재난 수준의 부하를 생성시킬 수 있다.

다섯째, 생각 외로 높은 비용이 든다. 많은 기업들이 라이선스가 무료라고 도입했다가 유지보수나 기술지원에 들어가는 높은 비용에 놀라는 경우가 많다. 최소 10개 이상의 오픈소스를 설치해야 할뿐만 아니라, 장애가 발생했을 때 그 원인과 대처 방법을 빠른 시간 내 찾기가 쉽지 않다. 대기업이 아닌 일반 기업에서 이러한 오픈소스를 다 알 수 있도록 담당 인력을 배치하거나 학습시킬 수 있는 비용과 시간을 마련하기는 어렵다.

실시간 데이터 추출에 불리

SQL이 지원되지 않는 새로운 DBMS인 NoSQL도 있다. NoSQL은 새로운 데이터 처리 트렌드로 매우 성공적인 IT 이력을 갖고 있다. 그중에서 가장 유명한 제품이 카산드라(Cassandra)와 레디스(Redis)다. NoSQL은 세상의 모든 데이터가 유일한 키(Unique Key)를 갖고 있으며, 이 유일 키를 기반으로 나머지 데이터가 연결돼 있다고 보는 솔루션이다. NoSQL이 가장 역할을 잘 해내는 영역으로는 객체 인증 혹은 데이터 캐시 서비스를 들 수 있다.

NoSQL의 장점은 바로 확장성과 고가용성이다. 확정성 관점에서 모든 데이터에는 반드시 유일 키가 존재하기 때문에 자신이 속할 서버를 쉽게 지정할 수 있고, 이 서버의 개수를 무제한으로 늘림으로써 사용자 요청의 증가에 대한 유연한 대처가 가능하다.

고가용성 관점에서도 자신의 데이터를 두 개 이상의 서버에 복제해 둠으로써 만일 하나의 서버에 장애가 발생하더라도 나머지 서버가 대신할 수 있어, 장애에도 큰 어려움 없이 서비스 수행이 가능하다. 그러나 NoSQL은 센서 데이터 처리를 위해서 몇 가지 약점이 존재한다.

첫째는 집계 함수(Aggregation)를 사용하기 힘들다. 통계를 얻기 위해 다수의 유일 키를 조합하는 건 사실상 불가능한 경우가 많다.

둘째는 시계열 데이터 저장이 구조적으로 용이하지 않다. 센서의 태그 번호를 기준으로 서버에 저장하는 것은 좋은 전략이지만, 구조적으로 시계열 데이터 처리는 쉽지 않다.

셋째, 시계열 데이터의 추출이 매우 느리다. 센서 데이터를 저장할 경우 해당 칼럼에 시간 및 값이 쌍으로 연결된 수백만 개의 연속된 데이터가 있을 때, 시간 범위로 추출하기 위해 선형적 탐색을 해야 하는 문제가 발생한다. 설상가상으로 입력되는 특정 태그의 시간이 역전된다면 추출한 이후 다시 정렬해야 하는 상황이 발생하며, 최악의 경우 아무것도 할 수 없는 지경에 이르게 된다.

최근 가장 독특하면서 대중적인 인기를 갖고 있는 몽고DB(MongoDB)는 오픈소스이다. 그렇기 때문에 많은 사용자가 무료로 사용할 수 있을 뿐만 아니라 빠른 성능으로 인해 전 세계적으로 인기가 높다. 그리고 스스로를 문서DBMS(Document DBMS)라 칭할 정도로 문서와 같은 비정형 데이터 처리에 특화돼 있으며, SQL이 아닌 JSON(JavaScript Object Notation) 형태로 동작하기 때문에 특정한 종류의 데이터베이스라 이야기하기 힘들다. NoSQL로 구분하기도 하지만, 좀 더 정확히 하자면 전통적인 데이터베이스와 NoSQL의 중간 정도라 할 수 있다.

빅데이터 일반 문서 처리 혹은 일반 데이터 저장소 등 산업군을 가리지 않고 사용되고 있어 만능으로 보이기도 한다. 그러나 센서 데이터 처리 관점에서 보면 이 제품의 한계는 명확하다. 많은 기능과 데이터 형태를 지원하지만 실제로 대량의 시계열 데이터의 입력 성능과 추출 성능이 매우 느리기 때문에 IoT 센서 데이터 처리 영역에 적합하다고 할 수 없다.

확장성 부족 문제 직면

전통적인 제조 산업 분야에 흔히 통용되는 솔루션이 있다. 바로 RTDB(RealTime Database) 혹은 RT 히스토리안(Historian)DB 이다. 제품의 종류와 무관하게 센서 데이터를 저장하는 제품이자 솔루션이다. 오에스아이소프트(OSISoft)의 파이시스템(PI System)이나 데이터파크(dataPARC) 등 수만 개 이상 서로 다른 종류의 센서 데이터를 고속으로 저장하고, 이를 실시간으로 시각화해 주는 제품으로 오랫동안 사용돼 왔다.

그러나 IoT 환경이 제조 산업에 적용되면서 기존 솔루션으로는 폭발적으로 증가하는 데이터를 처리하기 힘든 지점에 이르렀다. RT 히스토리안DB가 센서 데이터 처리에 다소 버거운 이유는 다음과 같은 몇 가지 이유를 들 수 있다.

첫째, 확장성이 제공되지 않는다. RT 히스토리안DB는 단일 서버로 최고의 성능을 낼 수 있고 이중화까지 지원이 가능하다. 그러나 데이터양이 급격하게 증가하는 상황에선 이중화가 아닌 다중화가 필요하고, 무엇보다 서버를 추가해 처리 성능을 높이는 것이 중요한데 이에 대한 대처 방안이 당초 설계 시 고려되지 않았다.

둘째는 IT와 OT(Operation Technology)의 융합이 시작됐다는 점이다. 앞서 OT 영역에서 RDBMS는 이 영역에의 적용이 고려되지 않았다. RT 히스토리안DB의 구성요소 내 RDBMS가 포함돼 있으며, 기존 OT에서의 IT 기술 자체가 RDBMS 기반이다.

스마트팩토리 전용 솔루션 제품은 센서 데이터의 빠른 처리를 위해 단일 데이터베이스 형태 기반으로 개발되는 경우가 늘어나고 있다. 개발과 사용이 간편하고 확장성을 보장할 수 있는 소프트웨어를 토대로 IT 영역에서 OT 영역으로의 확장이 이뤄지고 있으나 RT 히스토리안DB는 단일 패키지가 아니라 큰 솔루션으로 제공되고 있어 미래의 개발과 스마트팩토리 시장에서의 수요가 감소할 수밖에 없다.

그렇다면 IoT 데이터 전쟁에서 승리하기 위한 솔루션은 어떤 특징을 보유하고 있어야 할까? 데이터 입력과 저장 속도도 빨라야 하고, 고속으로 데이터를 추출해야 하며, 고속의 시계열 질의를 지원해야 한다. 물론 실시간 통계 기능과 SQL 지원은 기본이어야 한다. 다음호에서 센서 데이터 처리를 위해 필요한 조건과 적합한 구성에 대해 알아보겠다.