시계열 데이터를 관계형 또는 비 저장 형?

시계열 데이터를 관계형 또는 비 저장 형?

---

SNMP를 사용하여 (아마도) 5 분 간격으로 CPU 사용률, 디스크 사용률, 온도 등과 같은 다양한 메트릭에 대한 데이터를 위해 장치를 폴링하는 시스템을 만들고 있습니다. 궁극적 인 목표는 시계열 그래프 형식으로 시스템 사용자에게 시각화를 제공하는 것입니다.

과거에는 RRDTool을 사용하는 것을 살펴 봤지만 캡처 된 데이터를 무기한으로 저장하는 것이 프로젝트에 중요하므로 거부했으며 캡처 된 데이터에 대한 더 높은 수준의 유연한 액세스를 원합니다. 그래서 내 질문은 정말로 :

더 좋은 점은 그래프로 데이터를 쿼리 할 때 성능과 관련하여 관계형 데이터베이스 (예 : MySQL 또는 PostgreSQL) 또는 비 관계형 또는 NoSQL 데이터베이스 (예 : MongoDB 또는 Redis)입니다.

관계형

관계형 데이터베이스가 주어지면 data_instances테이블을 사용합니다.이 테이블에는 모든 필드에 대해 측정되는 모든 메트릭에 대해 캡처 된 모든 데이터 인스턴스가 다음 필드와 함께 저장됩니다.

필드: id fk_to_device fk_to_metric metric_value timestamp

특정 장치에서 특정 메트릭에 대한 그래프를 그리려면 다른 장치를 필터링하는 이 단일 테이블 및이 장치에 대해 분석되는 다른 메트릭을 쿼리해야합니다 .

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

이 테이블의 행 수는 다음과 같습니다.

d * m_d * f * t

여기서 d의 개수 장치 , m_d축적이다 메트릭 수가 , 모든 기기에 기록되지 f는 IS 주파수 데이터 및 폴링되는 t총량 인 시각 시스템이 데이터를 수집하고있다.

1 년 동안 5 분마다 3 개의 장치에 대해 10 개의 메트릭을 기록하는 사용자의 경우 5 백만 건 미만의 레코드를 보유하게됩니다.

인덱스

의 인덱스없이 fk_to_device하고 fk_to_metric이 지속적으로 확대 테이블을 스캔하는 것은 너무 많은 시간이 걸릴 것이다. 따라서 위에서 언급 한 필드를 색인화하고 timestamp(현지화 된 기간으로 그래프를 작성하기위한) 요구 사항입니다.

비 관계형 (NoSQL)

MongoDB는 테이블을 설정하지 않고 프로그래밍 방식으로 만들 수있는 테이블과 달리 컬렉션 개념을 가지고 있습니다. 이를 통해 각 장치의 데이터 스토리지 또는 각 장치에 대해 기록 된 각 메트릭을 분할 할 수있었습니다.

나는 NoSQL에 대한 경험이 없으며 인덱싱과 같은 쿼리 성능 향상 기능을 제공하는지 여부를 알지 못하지만 이전 단락에서는 NoSQL에서 데이터가 저장되는 구조에서 전통적인 관계형 쿼리 작업의 대부분을 제안합니다.

미정

올바른 색인 작성을 가진 관계형 솔루션이 1 년 안에 크롤링으로 줄어 듭니까? 또는 NoSQL 접근 방식의 수집 기반 구조 (저장된 데이터의 정신적 모델과 일치)가 눈에 띄는 이점을 제공합니까?

---

확실히 관계형. 무제한의 유연성과 확장 성.

개념과 적용 모두에 대한 두 가지 수정과 고도 상승.

보정

1. "필요하지 않은 데이터를 필터링"하지 않습니다. 그 것이다 만을 선택 하여 필요한 데이터. 물론 WHERE 절에서 식별 된 열을 지원하는 인덱스가있는 경우 매우 빠르며 쿼리는 테이블 크기에 의존하지 않습니다 (160 억 행 테이블에서 1,000 개의 행을 가져옴). .

2. 당신의 테이블에는 심각한 장애가 있습니다. 설명에 따르면 실제 PK는 (장치, 측정 항목, 날짜 시간)입니다. (TimeStamp라고 부르지 마십시오. 다른 의미가 있지만 사소한 문제입니다.) 행 의 고유성은 다음과 같이 식별됩니다.

      (Device, Metric, DateTime)
   

   • 이 Id열은 아무 것도 수행하지 않으며 완전히 중복됩니다.

     • Id열은 키 (관계형 데이터베이스에 금지 중복 행은, 다른 방법으로 방지해야한다) 결코 없다.

     • 이 Id열에는 추가 색인이 필요합니다. 이는 분명히 속도를 방해하고 INSERT/DELETE사용 된 디스크 공간을 추가합니다.

     • 당신은 그것을 제거 할 수 있습니다. 부디.

높이

1. 장애를 제거 했으므로이를 인식하지 못했을 수 있지만 테이블이 여섯 번째 정규 형식입니다. PK에 하나의 인덱스 만있는 초고속. 이해를 위해 읽고, 이 답변 로부터 여섯 번째 정규 양식은 무엇입니까? 앞으로 향하고 있습니다.

   • (나는 3이 아닌 하나의 인덱스 만 가지고 있습니다. 비 SQL에서는 3 개의 인덱스가 필요할 수 있습니다).

   • 나는 정확히 같은 테이블을 가지고 있습니다 ( Id물론 "키"는 없습니다). 추가 열이 Server있습니다. 여러 고객을 원격으로 지원합니다.

     (Server, Device, Metric, DateTime)

   이 테이블을 사용 하여 정확히 동일한 SQL 코드를 사용하여 데이터를 피벗하거나 (예 : Devices위쪽 및 Metrics아래쪽 또는 피벗) 셀을 전환 할 수 있습니다. 이 표를 사용하여 고객이 서버 성능을 다시 발휘할 수 있도록 다양한 그래프와 차트를 무제한으로 세웁니다.

   • 통계 데이터 모델 모니터 .
     (인라인의 경우 너무 큽니다. 일부 브라우저는 인라인을로드 할 수 없습니다. 링크를 클릭하십시오. 또한 구식 데모 버전이므로 상용 제품 DM을 표시 할 수 없습니다.)

   • It allows me to produce Charts Like This, six keystrokes after receiving a raw monitoring stats file from the customer, using a single SELECT command. Notice the mix-and-match; OS and server on the same chart; a variety of Pivots. Of course, there is no limit to the number of stats matrices, and thus the charts. (Used with the customer's kind permission.)

   • Readers who are unfamiliar with the Standard for Modelling Relational Databases may find the IDEF1X Notation helpful.

One More Thing

Last but not least, SQL is a IEC/ISO/ANSI Standard. The freeware is actually Non-SQL; it is fraudulent to use the term SQL if they do not provide the Standard. They may provide "extras", but they are absent the basics.

---

Found very interesting the above answers. Trying to add a couple more considerations here.

1) Data aging

Time-series management usually need to create aging policies. A typical scenario (e.g. monitoring server CPU) requires to store:

• 1-sec raw samples for a short period (e.g. for 24 hours)

• 5-min detail aggregate samples for a medium period (e.g. 1 week)

• 1-hour detail over that (e.g. up to 1 year)

Although relational models make it possible for sure (my company implemented massive centralized databases for some large customers with tens of thousands of data series) to manage it appropriately, the new breed of data stores add interesting functionalities to be explored like:

• automated data purging (see Redis' EXPIRE command)

• multidimensional aggregations (e.g. map-reduce jobs a-la-Splunk)

2) Real-time collection

Even more importantly some non-relational data stores are inherently distributed and allow for a much more efficient real-time (or near-real time) data collection that could be a problem with RDBMS because of the creation of hotspots (managing indexing while inserting in a single table). This problem in the RDBMS space is typically solved reverting to batch import procedures (we managed it this way in the past) while no-sql technologies have succeeded in massive real-time collection and aggregation (see Splunk for example, mentioned in previous replies).

---

You table has data in single table. So relational vs non relational is not the question. Basically you need to read a lot of sequential data. Now if you have enough RAM to store a years worth data then nothing like using Redis/MongoDB etc.

Mostly NoSQL databases will store your data on same location on disk and in compressed form to avoid multiple disk access.

NoSQL does the same thing as creating the index on device id and metric id, but in its own way. With database even if you do this the index and data may be at different places and there would be a lot of disk IO.

Tools like Splunk are using NoSQL backends to store time series data and then using map reduce to create aggregates (which might be what you want later). So in my opinion to use NoSQL is an option as people have already tried it for similar use cases. But will a million rows bring the database to crawl (maybe not , with decent hardware and proper configurations).

---

Create a file, name it 1_2.data. weired idea? what you get:

• You save up to 50% of space because you don't need to repeat the fk_to_device and fk_to_metric value for every data point.
• You save up even more space because you don't need any indices.
• Save pairs of (timestamp,metric_value) to the file by appending the data so you get a order by timestamp for free. (assuming that your sources don't send out of order data for a device)

=> Queries by timestamp run amazingly fast because you can use binary search to find the right place in the file to read from.

if you like it even more optimized start thinking about splitting your files like that;

• 1_2_january2014.data
• 1_2_february2014.data
• 1_2_march2014.data

or use kdb+ from http://kx.com because they do all this for you:) column-oriented is what may help you.

There is a cloud-based column-oriented solution popping up, so you may want to have a look at: http://timeseries.guru

---

If you are looking at GPL packages, RRDTool is a good one to look at. It is a good tool for storing, extracting and graphing times-series data. Your use-case looks exactly like time-series data.

---

This is a problem we've had to solve at ApiAxle. We wrote up a blog post on how we did it using Redis. It hasn't been out there for very long but it's proving to be effective.

I've also used RRDTool for another project which was excellent.

---

I think that the answer for this kind of question should mainly revolve about the way your Database utilize storage. Some Database servers use RAM and Disk, some use RAM only (optionally Disk for persistency), etc. Most common SQL Database solutions are using memory+disk storage and writes the data in a Row based layout (every inserted raw is written in the same physical location). For timeseries stores, in most cases the workload is something like: Relatively-low interval of massive amount of inserts, while reads are column based (in most cases you want to read a range of data from a specific column, representing a metric)

I have found Columnar Databases (google it, you'll find MonetDB, InfoBright, parAccel, etc) are doing terrific job for time series.

As for your question, which personally I think is somewhat invalid (as all discussions using the fault term NoSQL - IMO): You can use a Database server that can talk SQL on one hand, making your life very easy as everyone knows SQL for many years and this language has been perfected over and over again for data queries; but still utilize RAM, CPU Cache and Disk in a Columnar oriented way, making your solution best fit Time Series

---

5 Millions of rows is nothing for today's torrential data. Expect data to be in the TB or PB in just a few months. At this point RDBMS do not scale to the task and we need the linear scalability of NoSql databases. Performance would be achieved for the columnar partition used to store the data, adding more columns and less rows kind of concept to boost performance. Leverage the Open TSDB work done on top of HBASE or MapR_DB, etc.

---

I face similar requirements regularly, and have recently started using Zabbix to gather and store this type of data. Zabbix has its own graphing capability, but it's easy enough to extract the data out of Zabbix's database and process it however you like. If you haven't already checked Zabbix out, you might find it worth your time to do so.

---

You should look into Time series database. It was created for this purpose.

A time series database (TSDB) is a software system that is optimized for handling time series data, arrays of numbers indexed by time (a datetime or a datetime range).

Popular example of time-series database InfluxDB

참고URL : https://stackoverflow.com/questions/4814167/storing-time-series-data-relational-or-non