Time-series data is increasingly at the heart of modern applications - think IoT, stock trading, clickstreams, social media, and more. With the move from batch to real time systems, the efficient capture and analysis of time-series data can enable organizations to better detect and respond to events ahead of their competitors, or to improve operational efficiency to reduce cost and risk. Working with time series data is often different from regular application data, and there are best practices you should observe. This blog series seeks to provide these best practices as you build out your time series application on MongoDB:
IoT, 주식 거래, clickstreams(사용자가 인터넷에서 보내는 시간 동안 방문한 웹사이트를 기록한 것), SNS등의 현대의 application의 중심에는 시계열(time-series) data가 점차 자리잡고 있다. batch에서 실시간 시스템으로의 이동을 통해, 시계열 data의 효율적인 저장과 분석을 통해, 기업은 그들의 경쟁사보다 앞서서 event를 감지하고 대응하거나 운영 효율성을 개선하여 비용이나 위험을 줄일 수 있다. 시계열 data를 사용하는 것은 흔히 일반 application과 다르고, 모범 사례를 준수해야 한다. 이 게시물 시리즈는 MongoDB에 시계열 application을 구축할 경우, 다음과 같은 모범 사례를 제공하고자 한다.
- Introduce the concept of time-series data, and describe some of the challenges associated with this type of data
시계열 data의 개념을 소개하고, 이런 유형의 data와 관련된 당면 과제를 설명한다. - How to query, analyze and present time-series data
시계열 data를 query, analyze, 표시하는 방법 - Provide discovery questions that will help you gather technical requirements needed for successfully delivering a time-series application.
시계열 application을 성공적으로 구축하는데 필요한 기술적인 요구사항을 수집하는데 도움이 되는 의문점을 제공한다.
What is time-series data?
While not all data is time-series in nature, a growing percentage of it can be classified as time-series – fueled by technologies that allow us to exploit streams of data in real time rather than in batches. In every industry and in every company there exists the need to query, analyze and report on time-series data. Consider a stock day trader constantly looking at feeds of stock prices over time and running algorithms to analyze trends in identify opportunities. They are looking at data over a time interval, e.g. hourly or daily ranges. A connected car company might obtain telemetry such as engine performance and energy consumption to improve component design, and monitor wear rates so they can schedule vehicle servicing before problems occur. They are also looking at data over a time interval.
모든 data가 본질적으로 시계열인 것은 아니지만, 점점 많은 data가 시계열로 분류될 수 있다. 즉, batch가 아닌 실시간으로 data stream을 이용할 수 있게 하는 기술에 힘입어 가속화되었다. 모든 회사와 기업에서, 시계열 data에 대한 query, analyze, report가 필요하다. 기회를 찾기 위해, 시간에 따른 주식 가격 자료를 끊임없이 검토하고, 동향을 분석하기 위해 algorithms을 실행하는 주식 거래자를 생각해 보자. 그들은 일정한 시간별(시간별, 일별 등)로 data를 검토한다. 자동차 관련 회사는 부품 설계 개선을 위해 엔진 성능과 에너지 소비같은자료를 얻을 수 있으며, 문제가 발생하기 전에 차량 서비스를 예약할 수 있도록 마모율을 모니터할 수 있다.
Why is time-series data challenging?
Time-series data can include data that is captured at constant time intervals – like a device measurement per second – or at irregular time intervals like those generated from alerts and auditing event use cases. Time-series data is also often tagged with attributes like the device type and location of the event, and each device may provide a variable amount of additional metadata. Data model flexibility to meet diverse and rapidly changing data ingestion and storage requirements make it difficult for traditional relational (tabular) database systems with a rigid schema to effectively handle time-series data. Also, there is the issue of scalability. With a high frequency of readings generated by multiple sensors or events, time series applications can generate vast streams of data that need to be ingested and analyzed. So platforms that allow data to be scaled out and distributed across many nodes are much more suited to this type of use case than scale-up, monolithic tabular databases.
시계열 data에는 일정한 시간 간격(초당 장치 측정) 또는 경고나 감시 event 사례에서 생성된 불규칙한 시간 간격으로 얻은 data를 포함할 수 있다. 시계열 data는 흔히 장치의 유형, event의 위치 같은 속성을 가질 수 있고, 각 장치는 가변적인 추가 metadata를 가질 수도 있다. 다양하고 빠르게 변화하는 data 수집과 저장소 요구사항을 충족하는 data model의 유연성 때문에, 엄격한 schema를 사용하는 전통적인(테이블 형태의) database system은 시계열 data를 효율적으로 처리하기가 어렵다. 또한, 확장성 문제도 있다. 복수의 sensor나 event에 의해 생성되는 data를 읽는 경우가 많다면, 시계열 application은 수집과 분석이 필요한 방대한 data stream을 생성할 수 있다. 따라서, data를 여러 node에 걸쳐 확장하고 분산할 수 있는 platform이, scale-up된 단일 테이블 형태의 database보다, 이러한 유형의 사례에 훨씬 더 적합하다.
Time series data can come from different sources, with each generating different attributes that need to be stored and analyze. Each stage of the data lifecycle places different demands on a database – from ingestion through to consumption and archival.
시계열 data는 다양한 source를 가질 수 있고, 각각이 저장, 분석되어야 하는 다양한 속성을 생성할 수 있다. data lifecycle의 각 단계는 수집에서 사용, 보관까지 database에 대해 다양한 요구사항을 가진다.
- During data ingestion, the database is primarily performing write intensive operations, comprising mainly inserts with occasional updates. Consumers of data may want to be alerted in real time when an anomaly is detected in the data stream during ingestion, such as a value exceeding a certain threshold.
data 수집 중에는, database는 주로 write 집약적인 작업(가끔 updates를, 주로 inserts로 구성된)을 수행한다. data 사용자는 수집 중에 data stream에 이상 징후(예: 특정 임계값을 초과하는 값)가 발견되면, 실시간으로 경고를 받고자 할 수도 있다. - As more data is ingested consumers may want to query it for specific insights, and to uncover trends. At this stage of the data lifecycle, the workload is read, rather than write heavy, but the database will still need to maintain high write rates as data is concurrently ingested and then queried.
사용자는 data가 더 많이 수집됩에 따라, 어떤 통찰력과 트렌드를 알기 위해 query를 할 수도 있다. data lifecycle의 이 단계에서, 많은 write 작업보다는 read 작업이 수행되지만, data가 동시에 수집되고 query되므로, database는 여전히 높은 write 속도를 유지해야 한다. - Consumers may want to query historical data and perform predictive analytics leveraging machine learning algorithms to anticipate future behavior or identify trends. This will impose additional read load on the database.
사용자는 과거 data를 query하고, machine learning algorithms을 활용하여, 미래 행동을 예측하거나 트렌드를 파악하기 위해 예측 분석을 수행하려 할 수도 있다. 이것은 database에 추가적인 read 부하를 줄 것이다. - In the end, depending on the application’s requirements, the data captured may have a shelf life and needs to be archived or deleted after a certain period of time.
마지막으로, application의 요구 사항에 따라, 수집된 data는 보관 기간이 있을 수 있어, 일정 기간 후에 archive되거나 삭제되어야 한다.
As you can see working with time-series data is not just simply storing the data, but requires a wide range of data platform capabilities including handling simultaneous read and write demands, advanced querying capabilities, and archival to name a few.
시계열 data로 작업을 통해 알 수 있는 것은 단순히 data를 저장하는 것이 아니라, 동시 read/write 처리, 고급 query 기능 및 archive와 같은 광범위한 data platform 기능이 요구된다는 점이다.
Who is using MongoDB for time-series data?
MongoDB provides all the capabilities needed to meet the demands of a highly performing time-series applications. One company that took advantage of MongoDB’s time series capabilities is Quantitative Investment Manager Man AHL.
MongoDB는 매우 성능이 뛰어난 시계열 application의 요구 사항을 만족시키는 데 필요한 모든 기능을 제공한다. MongoDB의 시계열 기능을 활용한 회사는 Quantitative Investment Manager Man AHL이다.
Man AHL’s Arctic application leverages MongoDB to store high frequency financial services market data (about 250M ticks per second). The hedge fund manager’s quantitative researchers (“quants”) use Arctic and MongoDB to research, construct and deploy new trading models in order to understand how markets behave. With MongoDB, Man AHL realized a 40x cost saving when compared to an existing proprietary database. In addition to cost savings, they were able to increase processing performance by 25x over the previous solution. Man AHL open sourced their Arctic project on GitHub.
Man AHL의 Arctic application은 MongoDB를 활용하여, 매우 빈번하게 발생하는 금융 서비스 시장의 data(초당 약 250M ticks)를 저장하였다. hedge fund manager의 연구원(금융시장분석가)은 시장이 행동하는 방식을 이해하기 위하여, Arctic과 MongoDB를 사용하여 새로운 거래 모델을 연구, 구성, 배치하였다. MongoDB를 통해, Man AHL은 기존의 독점 database에 비하여 40배의 비용 절감 효과를 실현하였다. 비용 절감 외에도, 기존의 솔루션 대비 처리 성능을 25배 향상할 수 있었다. Man AHL은 GitHub에 Arctic project를 open하였다.
Bosch Group is a multinational engineering conglomerate with nearly 300,000 employees and is the world’s largest automotive components manufacturer. IoT is a strategic initiative at Bosch, and so the company selected MongoDB as the data platform layer in its IoT suite. The suite powers IoT applications both within the Bosch group and in many of its customers in industrial internet applications, such as automotive, manufacturing, smart city, precision agriculture, and more. If you want to learn more about the key challenges presented by managing diverse, rapidly changing and high volume time series data sets generated by IoT platforms, download the Bosch and MongoDB whitepaper.
Bosch Group은 약 30만명의 직원을 가진 다국적 엔지니어링 대기업으로, 세계 최대의 자동차 부품 제조업체이다. IoT는 Bosch의 전략적 결정으로, MongoDB를 IoT 제픔군에서 data platform으로 선택했다. Bosch 그룹과 자동차 제조, smart city, 정밀 농업 등의 산업용 internet application의 많은 사용자들에게 IoT application을 제공한다. IoT platform에서 생성되는 다양하고 빠르게 변화하는 대용량 시계열 data에 대해 더 많이 알고 싶다면, Bosch와 MongoDB 백서를 내려받자.
Siemens is a global company focusing on the areas of electrification, automation and digitalization. Siemens developed “Monet,” a platform backed by MongoDB that provides advanced energy management services. Monet uses MongoDB for real time raw data storage, querying and analytics.
siemens는 전기, 자동화, 디지털 분야에 주력하는 글로벌 기업이다. siemens는 고급 에너지 관리 서비스를 제공하는 MongoDB 기반의 “Monet” platform을 개발하였다. 실시간 원시 data 저장, query, 분석을 위해, Monet은 MongoDB를 사용한다.
Focus on application requirements
When working with time-series data it is imperative that you invest enough time to understand how data is going to be created, queried, and expired. With this information you can optimize your schema design and deployment architecture to best meet the application’s requirements.
시계열 data로 작업할 경우에는, data의 생성, query, 만료 방법을 이해하는데 충분한 시간을 투자해야 한다. 이 정보를 사용하여 application의 요구사항을 가장 잘 충족할 수 있도록 schema design과 배포 구조를 최적화할 수 있다.
You should not agree to performance metrics or SLAs without capturing the application’s requirements.
application의 요구사항을 파악하지 않고 성능 metric이나 SLA에 동의해서는 안된다.
As you begin your time-series project with MongoDB you should get answers to the following questions:
MongoDB로 시계열 project를 시작할 경우, 다음과 같은 질문에 대한 답을 얻어야 한다.
Write workload
- What will the ingestion rate be? How many inserts and updates per second?
수집 속도는 얼마인가? 초당 insert, update 수는 얼마나 되나? As the rate of inserts increases, your design may benefit from horizontal scaling via MongoDB auto-sharding, allowing you to partition and scale your data across many nodes - How many simultaneous client connections will there be?
동시 client 연결 수는? While a single MongoDB node can handle many simultaneous connections from tens of thousands of IoT devices, you need to consider scaling those out with sharding to meet the expected client load. - Do you need to store all raw data points or can data be pre-aggregated? If pre-aggregated, what summary level of granularity or interval is acceptable to store? Per minute? Every 15 minutes?
모든 원시 데이터를 저장해야 하거나 data가 사전 집계될 수 있는가? 사전집계된 경우, 어떤 간격으로 저장될 수 있는가? 분별로? 15분마다? MongoDB can store all your raw data if you application requirements justify this. However, keep in mind that reducing the data size via pre-aggregation will yield lower dataset and index storage and an increase in query performance. - What is the size of data stored in each event?
각 event에서 저장되는 data 크기는 얼마인가? MongoDB has an individual document size limit of 16 MB. If your application requires storing larger data within a single document, such as binary files you may want to leverage MongoDB GridFS. Ideally when storing high volume time-series data it is a best practice to keep the document size small around 1 disk block size.
insert 속도가 증가함에 따라, MongoDB auto-sharding를 통한 수평 확장으로 많은 node에 data를 분할하고 확장할 수 있어, 설계에 유리할 수 있다.
단일 MongoDB node는 수만개의 IoT device로 부터 동시에 발생하는 많은 연결을 처리할 수 있지만, 예상되는 client 부하를 고려하여, sharding으로 이를 scale out을 고려해야 한다.
MongoDB는 application의 모든 원시 data를 저장해야 한다면 할 수 있다.그러나, 사전 집계를 통해 data 크기를 줄이면, data 집합과 index 저장소가 줄어들고 query 성능이 향상된다.
MongoDB는 개별 document의 크기가 16MB로 제한되어 있다. application이 단일 document에 binary file처럼 더 큰 data를 저장해야 한다면, MongoDB GridFS를 활용할 수 있다. 이상적으로 대량의 시계열 data를 저장하는 경우, 1개의 disk block 크기 정도로 document 크기를 작게 유지하는 것이 최선이다.
Read workload:
- How many read queries per second?
초당 read query의 수는? A higher read query load may benefit from additional indexes or horizontal scaling via MongoDB auto-sharding. - Will clients be geographically dispersed or located in the same region?
clients가 지리적으로 분산되어 있거나 동일 지역에 위치하는가? You can reduce network read latency by deploying read-only secondary replicas that are geographically closer to the consumers of the data. - What are the common data access patterns you need to support? For example, will you retrieve data by a single value such as time, or do you need more complex queries where you look for data by a combination of attributes, such as event class, by region, by time?
지원해야 하는 일반적인 data access pattern은 무엇인가? 예를 들어, 시간 같은 단일 값으로 data를 검색하는가? 또는 시간이나 지역별로 event class 같은 속성의 조합으로 data를 찾는 더 복잡한 query가 필요한가? Query performance is optimal when proper indexes are created. Knowing how data is queried and defining the proper indexes is critical to database performance. Also, being able to modify indexing strategies in real time, without disruption to the system, is an important attribute of a time-series platform. - What analytical libraries or tools will your consumers use?
사용자가 사용할 분석 라이브러리나 tool은? If your data consumers are using tools like Hadoop or Spark, MongoDB has a MongoDB Spark Connector that integrates with these technologies. MongoDB also has drivers for Python, R, Matlab and other platforms used for analytics and data science. - Does your organization use BI visualization tools to create reports or analyze the data?
BI 시각화 tool을 사용하여 보고서를 작성하거나 data를 분석하는가? MongoDB integrates with most of the major BI reporting tools including Tableau, QlikView, Microstrategy, TIBCO, and others via the MongoDB BI Connector. MongoDB also has a native BI reporting tool called MongoDB Charts, which provides the fastest way to visualize your data in MongoDB without needing any third-party products.
As with write volumes, reads can be scaled with auto-sharding. You can also distribute read load across secondary replicas in your replica set.
많은 read query 부하는 추가 indexes나 MongoDB auto-sharding을 통한 수평 확장을 통해 해소할 수 있다.
write와 마찬가지로, read는 auto-sharding으로 확장될 수 있다. replica set의 secondary replicas로 read 부하를 분산할 수도 있다.
data 사용자에게 지리적으로 더 가까운 read 전용 secondary replicas 를 사용하여, 네트워크 read 대기시간을 줄일 수 있다.
query 성능은 적절한 index가 생성될 경우에 최적이다. data를 query하는 방법을 알고 적절한 index를 정의하는 것은 database 성능에 있어 중요하다. 또한, 시스템 중단 없이, index 전략을 변경할 수 있다는 것은 시계열 platform의 중요한 속성이다.
사용자가 Hadoop 이나 Spark 같은 tool을 사용하고 있다면, MongoDB는 이런 기술을 토합할 수 있는 MongoDB Spark Connector 를 가지고 있다. MongoDB는 Python, R, Matlab 그리고 분석 및 데이터 과학에 사용되는 기타 platform용 driver도 가지고 있다.
MongoDB는 MongoDB BI Connector를 통하여 Tableau, QlikView, Microstrategy, TIBCO 등의 주요 BI 보고서 tool의 대부분과 통합된다. MongoDB는 MongoDB Charts 라는 native BI 보고서 tool도 가지고 있는데, 이것은 다른 3'rd party 제품없이, MongoDB에서 data를 시각화하는 가장 빠른 방법을 제공한다.
Data retention and archival:
- What is the data retention policy? Can data be deleted or archived? If so, at what age?
data 보존 정책은? data를 삭제하거나 archive하는가? 기간은? - If archived, for how long and how accessible should the archive be? Does archive data need to be live or can it be restored from a backup?
archive한다면, 기간은 얼머나 되며, 어떻게 접근 가능한가? archive data가 실시간이어야 하는가? backup에서 복구될 수 있는가? There are various strategies to remove and archive data in MongoDB. Some of these strategies include using TTL indexes, Queryable Backups, zoned sharding (allowing you to create a tiered storage pattern), or simply creating an architecture where you just drop the collection of data when no longer needed.
MongoDB에는 삭제와 archive를 위한 다양한 정책이 있다. 이들 정책에는 TTL indexes, Queryable Backups, zoned sharding (계층화된 저장 pattern을 생성할 수 있음) 또는 더 이상 필요 없는 경우 collection을 ㅅ단순히 제거하는 아키텍처의 생성등을 포함한다.
Security:
- What users and roles need to be defined, and what is the least privileged permission needed for each of these entities?
어떤 사용자와 역활을 정의해야 하는가? 그리고, 이들 각각에 대해 필요한 최소한의 권한은? - What are the encryption requirements? Do you need to support both in-flight (network) and at-rest (storage) encryption of time series data?
암호화 요구 사항은? 시계열 data의 network, storage 암호화를 지원해야 하는가? - Do all activities against the data need to be captured in an audit log?
data에 대한 모든 activities를 audit log에 저장해야 하는가? - Does the application need to conform with GDPR, HIPAA, PCI, or any other regulatory framework?
application이 GDPR, HIPAA, PCI 또는 기타 규제 framework을 준수해야 하는가? The regulatory framework may require enabling encryption, auditing, and other security measures. MongoDB supports the security configurations necessary for these compliances, including encryption at rest and in flight, auditing, and granular role-based access control controls.
규제 framework은 암호화, audit 그리고 기타 보안 조치가 필요하다. MongoDB는 network, storage 암호화, audit, 세분화된 역활 기반 access control을 포함하여, 이러한 compliance에 필요한 security configurations을 지원한다.
While not an exhaustive list of all possible things to consider, it will help get you thinking about the application requirements and their impact on the design of the MongoDB schema and database configuration. In the next blog post, "Part 2: Schema design for time-series data in MongoDB” we will explore a variety of ways to architect a schema for different sets of requirements, and their corresponding effects on the application’s performance and scale. In part 3, "Time Series Data and MongoDB: Part 3 – Querying, Analyzing, and Presenting Time-Series Data", we will show how to query, analyze and present time-series data.
고려해야 할 모든 사항에 대한 전체 목록은 아니지만, application 요구 사항과 그것이 MongoDB schema와 database 구성에 미치는 영향에 대해 생각해 보는데, 도움이 될 것이다. 다음 게시물인 "Part 2: Schema design for time-series data in MongoDB”에서, 다양한 요구 사항에 대한 schema를 설계하는 다양한 방법과 그 요구 사항들이 application의 성능과 규모에 미치는 영향을 알아보자. part 3인, "Time Series Data and MongoDB: Part 3 – Querying, Analyzing, and Presenting Time-Series Data"에서, 시계열 data를 query, analyze, 표시하는 방법을 설명한다.