작성자: 빅 데이터 모델
이 기사는 2022년 "TDengine 사용, TDengine 작성" 에세이 제출 활동에서 발췌한 것입니다.
업무 때문에 근래 여러 국내 데이터베이스에 노출됐지만 TDengine을 빼놓을 수 없다. 많은 데이터베이스 중에서 TiDB가 눈에 띄고, OceanBase는 명가 출신이고, openGauss는 Huawei가 지원하며, TDengine만이 사람들에게 영웅이 된 듯한 느낌을 줍니다.개발면에서 TiDB는 RocksDB의 성능을 차용하고 openGauss는 PostgreSQL9.2.4.OceanBase조차도 내부 애플리케이션 요구 사항을 기반으로 구축되었으며 TDengine만이 오픈 소스 또는 타사 소프트웨어에 의존하지 않고 자체 개발되었습니다. 또한 범용 데이터베이스가 아니며 주로 산업 네트워크에 서비스를 제공하는 고유한 소셜 애플리케이션 시나리오가 있습니다.
저자는 TDengine에 대한 정의와 이해를 바탕으로 TDengine이 해결할 수 있는 문제, TDengine의 장점과 특징, 다른 데이터베이스와의 차이점을 이 글에서 자세히 설명하여 TDengine 버디에 관심이 있는 사람들에게 도움이 되기를 바란다.
"범용 데이터베이스와 달리 TDengine은 쓸데없는 짐을 버린다"
데이터베이스가 우수한 읽기 및 쓰기를 달성하려면 인덱싱이 핵심 기능이며 일반적으로 데이터베이스 제품에는 포워드 인덱싱 기능이 있습니다. 소위 정방향 인덱스는 문서 레코드의 식별자를 키워드로 사용하는 것이며 키 식별자는 더 이상 전체 디스크를 스캔할 필요가 없습니다. B-tree 인덱스, 해시 인덱스, 비트맵 인덱스에는 차이가 있지만 일반적인 방향은 정방향 인덱스에 속합니다.
정방향 색인 외에 역방향 색인[역방향 색인이라고도 함]이 있는데 역방향 색인은 주로 ElasticSearch와 같은 전체 텍스트 검색에 사용되며 대부분의 데이터베이스는 정방향 색인입니다. TDengine은 정방향 인덱스도 사용합니다.특징은 식별자에 타임스탬프와 차원 지표 데이터를 포함하여 데이터 값에 대한 명확한 설명(특정 시간에 특정 지표 개체의 데이터 값은 무엇인가)을 형성해야 한다는 것입니다.
데이터 조직의 저장 엔진의 관점에서 데이터베이스의 최하위 계층은 B-tree 메커니즘과 LSM 메커니즘으로 나눌 수 있습니다.두 메커니즘은 최고가 아니며 각각 고유한 장점과 단점이 있습니다.
B-tree의 가장 큰 장점은 데이터의 읽기 성능을 지속적으로 높일 수 있다는 점이며, 데이터 레벨이 높아져도 읽기가 커지지 않는다. 그 비밀은 데이터의 궁극적인 영구 저장에 있으며, B-트리는 질서정연하고 규칙적인 데이터 구조로 하드 디스크에 저장됩니다 . 이러한 방식으로 데이터가 점점 더 커짐에 따라 여전히 질서 정연하고 규칙적인 기능을 유지하고 수천 건의 읽기 작업에 직면하여 조건에 따라 실행할 수 있으며 읽기 증폭 동작을 줄이거나 피할 수 있습니다.
B-트리 메커니즘과 달리 LSM 메커니즘은 쓰기 증폭을 줄이고 방지합니다. LSM 메커니즘은 메모리를 최대한 활용하고, 메모리에 공간을 열고, 메모리에 데이터를 먼저 쓰고, B 트리처럼 하나를 쓰는 대신 사용자 성공을 쓰고 직접 반환합니다. 나보다 나이가 많고 나보다 큰 사람은 작고 메모리가 충분한 한 메모리에 직접 채우십시오.메모리가 특정 임계 값에 도달하면 메모리의 데이터가 일괄 적으로 하드 디스크에 기록 되고 한 번에 순차적으로 메모리가 재설정되고 새 메모리를 제공하기 위해 지워집니다 .
전통적인 데이터베이스 MySQL과 Oracle은 B-트리 메커니즘을 사용하고 TiDB와 OceanBae는 최적화된 LSM 메커니즘을 사용하는 반면 TDengine은 B-트리가 메타데이터[주로 타임 스탬프 + 인덱스 데이터]를 저장하는 B-트리 + LSM 메커니즘을 사용합니다. LSM 메커니즘은 특정 데이터를 저장하고, 메타데이터는 정렬된 테이블 구조에 저장되며, 특정 데이터는 추가 방식으로 작성되므로 대량 읽기 및 쓰기 증폭을 피할 수 있습니다.
일반적으로 동시성 제어 성능을 향상시키기 위해 OLTP 제품에는 copy-on-write 또는 MVCC 기능 옵션이 있어야 하며 copy-on-write 및 MVCC는 데이터 일관성을 보장하지만 더 많은 IO 부담을 가져옵니다 . TDengine은 데이터를 수정할 필요가 없으므로 데이터 일관성 문제를 고려할 필요가 없습니다. 일부 쓸모없는 항목은 버려집니다.부담, 열 테이블과 같은 다른 장소를 최적화하는 데 집중할 수 있습니다.
업계의 일반적인 데이터베이스에는 행 기반 테이블, 열 기반 테이블 및 다양한 비즈니스를 위한 완전한 메모리 라이브러리가 있습니다. 특정 데이터 스토리지의 경우 TDengine은 하드 디스크에 전체 열 기반 스토리지를 사용하는 반면 차원 지표는 행-기반 테이블에 저장됩니다. 기반 메모리 . TDengine은 기계의 데이터를 마주하고 있기 때문에 기계는 24시간 작동하여 밀리초 단위로 데이터를 생성합니다.더 많은 데이터를 저장하기 위해 TDengine은 행과 열의 공존 및 용도 분리 방법을 사용합니다.
일반적으로 데이터베이스의 각 행의 문서 기록은 매우 중요하며, 이 행에 기록된 정보는 거래와 무관하고 사용자의 기본 정보일지라도 그 가치 밀도는 매우 높습니다. 하지만 시계열 데이터베이스(Time Series Database)는 다릅니다.1초에 10,000개의 레코드가 생성될 수 있기 때문에 단일 라인 문서 레코드의 값 밀도가 낮고 데이터의 값을 반영하기 위해 데이터를 집계해야 합니다. 일반 데이터를 빠르고 효율적으로 집계하여 값 밀도가 높은 데이터로 변환하는 것도 시계열 데이터베이스를 다른 데이터베이스와 구별하는 중요한 기능입니다.
TDengine은 현재 시장 및 개인 개발자의 요구를 충족시키기 위해 커뮤니티 버전, 엔터프라이즈 버전 및 클라우드 버전 의 세 가지 버전의 제품을 제공합니다.
"시계열 데이터베이스 해체, 여러 주요 제품 기능 분석"
기술적으로 TDengine은 시계열 분야에 초점을 맞춘 분산형 대용량 데이터 분석 플랫폼입니다. 경쟁사는 직접 경쟁사와 간접 경쟁사로 나눌 수 있으며, 간접 경쟁사는 국내 TiDB, OceanBase, GaussDB, 해외 Oracle, MySQL 등 종합적인 기술 측면에서 TDengine에 대한 벤치마킹 대상은 아니지만 타임스탬프가 있는 한 분석 사용되며 시계열과 관계가 있습니다. 여기에서 TDengine이 유용합니다. TDengine과 직접적으로 경쟁하는 경쟁자로는 Druid, OpenTSDB 및 InfluxDB가 있으며 이들은 모두 시계열 분석의 전신입니다.
Druid는 메모리를 최대한 활용하는 데 도움이 되는 Lambda 아키텍처를 채택하고 기록 데이터를 하드 디스크에 저장하고 특정 시간 단위에 따라 데이터를 집계하며 실시간 처리 및 일괄 처리 데이터를 분리하는 분산 시스템입니다. . 실시간 처리는 쓰기가 많고 읽기가 적은 시나리오를 위한 것으로 주로 증분 데이터를 스트리밍 방식으로 처리하고, 일괄 처리는 읽기가 많고 쓰기가 적은 시나리오를 위한 것으로 오프라인 데이터를 주로 이런 방식으로 처리합니다. Druid는 Hadoop에 의존합니다.클러스터에는 무공유 아키텍처가 채택됩니다.각 노드에는 자체 컴퓨팅 및 스토리지 기능이 있습니다.전체 시스템은 Zookeeper를 통해 조정됩니다. 컴퓨팅 성능을 향상시키기 위해 DataSketches의 일부 기본 계산인 HyperLoglog를 포함한 대략적인 컴퓨팅 방법을 사용합니다.
OpenTSDB는 수천억 개의 데이터 포인트 저장을 지원하고 정확한 쿼리를 제공하는 오픈 소스 시계열 데이터베이스입니다 .Java 언어로 작성되었으며 HBase 기반 스토리지를 통해 수평적 확장을 달성합니다.OpenTSDB는 다음을 포함하여 서버 모니터링 및 측정에 널리 사용됩니다. 네트워크 및 서버, 센서, IoT 및 금융 데이터의 실시간 모니터링. OpenTSDB의 설계 아이디어는 HBase의 키를 사용하여 일부 태그 정보를 저장하고 같은 시간의 데이터를 한 행에 저장하여 쿼리 속도를 향상시키는 것입니다. OpenTSDB는 Dimension 태그 등을 사전에 정의하여 HBase에 정교한 데이터 조직화 형태로 배치하여 HBase의 keyRange를 통해 빠른 쿼리를 수행할 수 있지만 차원이 다른 조직화 쿼리에서는 OpenTSDB의 효율성이 떨어집니다.
InfluxDB는 Go 언어로 개발된 매우 인기 있는 시계열 데이터베이스이며 커뮤니티는 매우 활동적이며 기술 기능은 여러 열, 패턴 제거, 통합 데이터 수집, 스토리지 및 시각적 스토리지를 지원하며 높은 압축률 알고리즘을 사용하여 지원합니다. 효율적인 스토리지, TIME SERIES MERGE TREE의 내부 스토리지 엔진을 채택하고 SQL과 유사한 언어를 지원합니다 (버전 2.0은 더 이상 지원하지 않음) .
시계열의 업무적 배경은 데이터 양을 줄이기 위해 일반적으로 OLAP 시나리오에서 사전 집계를 수행하는데 , 사전 집계에 영향을 미치는 주요 요인은 다음과 같이 요약할 수 있습니다.
차원 표시기의 수
차원 메트릭의 카디널리티
치수 표시기의 조합 정도
대략적 및 세분화된 시간 차원 지표
효율적인 pre-aggregation을 이루기 위해 TDengine의 비밀은 슈퍼 테이블이다. 다른 차원 인덱스 쿼리와 관련된 경우 속도가 느려집니다.
TDengine의 TSBS 기반 테스트 보고서는 가까운 시일 내에 발표될 예정이며, 첫 번째 보고서는 InfluxDB와 TimeScaleDB의 상세한 성능 수준 비교 분석을 수행합니다 .관심 있는 파트너는 최근 공식 계정의 내용에 더 많은 관심을 기울일 수 있습니다.
"오늘날 TDengine이 최우선 선택이 되어야 합니다"
TDengine에 대한 나의 지식과 이해는 과거 프로젝트 경험에서 시작되는데, 2018년을 배경으로 업계의 불량부품과 불량부품 예측에 대한 이야기를 들려드리겠습니다.
회사 비즈니스의 급속한 성장과 잘 알려진 그룹의 새로운 공장이 지속적으로 증가함에 따라 모든 종류의 귀중한 데이터를 적절한 가치로 통합, 분석 및 발굴할 수 없습니다. 현재 회사의 발전은 다음 단계의 "싸움"전략에 진입했습니다.신속한 대응과 정확한 예측은 비즈니스 발전의 핵심입니다.빅 데이터는 그 중 중추적 역할을 합니다.과학적인 분석 방법은 다양한 시스템의 데이터를 통합합니다. 공장 제조 지능화 촉진 현대화의 발전은 시급한 과제가 되었습니다.
같은 특수한 문제의 유리 아이디가 공장의 현재 생산 공정에서 나타났습니다.여러 가지 이유로 유리의 품질이 고르지 않으며 비정상적인 품질의 유리가 있을 수도 있습니다. 이러한 비정상적인 유리를 감지하는 과정에서 이상 원인을 탐지하는 것은 불가능하며 이상 원인을 신속하게 찾을 수 없으면 비정상적인 유리가 더 많이 발생하여 생산에 심각한 영향을 미칩니다. 구체적인 응답 수단은 다음과 같습니다.
이상 품질을 가진 유리를 통해 이러한 이상을 생성하는 상관 요인을 찾으십시오. 예: 기계, 재료, 차량, 매개변수 등
이상 유리 감지 및 조기 경보는 이상 품질을 생성하는 요인의 수학적 모델링을 통해 정상 범위를 벗어나는 이상 유리를 예측하고 조기 경보합니다.
分析 glass 的特征值与特征值之间的关联关系，并建立预测模型，提前预测出 glass 的特征值。
分析 glass 相关的电压、电阻、电流、温度、湿度影响。
很明显这是数据挖掘的项目，要分析以上 glass 在生产过程中的环境信息、检测机台资料、量测机台资料、制程参数信息，以及 FDC、OEE 系统的数据，才能找出产生这种问题的原因。第一步是数据收集整合，第二步是数据探索，第三步是模型调校——找出可能性、影响最大的因素的特征因素，第四步是投入生产验证，通过 spark ml 提供预测动力。
当时的技术栈用的是 CDH，首先要通过 Kafka 采集数据，Spark对接 Kafka 进行初步计算去噪并汇总到 Hadoop 里面，以 parquet 的格式保存，如果需要进一步的加工，就通过 impala 进行。这样每天挂起 N 个任务，不停的调度计算。
CDH Hadoop 虽然无法做到实时数据分析，但是也还能做些事，聊胜于无，就继续用着。当时这个坏件故障件预测项目有以下痛点，主要是及时性、有效性、准确性的问题：
难以满足用户需求，某些机器数据的聚合计算需要第二天才能出结果，甚至更多的时间才能出来。
经济成本的费用较高，CPU、磁盘、网络都在一个高段的使用状态，针对越来越多的数据需要投入新机器。
维护成本高，你需要维护 Hadoop 所有的机器，各种 HBase、Spark、Zookeeper、HDFS 之类，不但对工程师要求高，而且工作量巨大。
低质量数据，因为数据流程或者错误的逻辑整合，导致机器传感器聚合后数据模型无法正常使用。
无法做到实时监测，机器数据作为宝贵的自变量因素无法及时传输并进行计算，自然会影响因变量。
笔者经历了这个项目，知道这个坏件故障预测与时间序列有紧密的关系。时至今日，时间序列分析也是重要的数据分析技术，尤其面对季节性、周期性变化数据时，传统的回归拟合技术难以奏效，这时就需要复杂的时间序列模型，以时间为特征作为抓手点。这样即使你不太懂业务的前提下，也可以进行数据挖掘的工作。
那这个项目与 TDengine 有什么关系呢？ 实际上，这个项目并没有用上 TDengine，后来集团搭建了一个 Hadoop集群试点，这次居然用了 HDP，理由很简单，因为 HDP 默认搭载了时序数据库 Druid。
当时技术负责人认为坏件故障预测模型的数据库基座应该是时序数据库，而不是 Hadoop 不停的进行数据采集、数据转换以及各种批计算，通过时序数据库不但可以实时计算，而且输出的数据质量高。至于选择哪个时序数据库，彼时考虑平稳过渡替换以及学习成本综合因素后他们选择了 Druid。
但当时是 2017 年，TDengine 也还没有面世，如果放到今天，TDengine 必定是选型考虑的首选。
要知道，TDengine 的优势相对 Druid 要多了去了，首先 Druid 不是一个经过开源版本 1.00 正式发布的软件，虽然发展多年，直至 HDP 与 CDH 两家公司融合，HDP 搭配的 Druid 也不是 1.00 版；其次 Druid 依赖 Hadoop，动辄就使用大量的资源以及各种复杂的 Hadoop 组件，最后 Druid 只提供 json 的方式，对传统的 DBA 使用十分不友好。
TDengine 有一个我认为很秀的功能，就是它的超级表的跨指标维度建模思想，目前它仅用于自由组合维度指标，拼接不同的时间粒度进行聚合。在我看来，将来应用于时间序列机器学习模型也会是它的一个亮点，在数据建模方面，针对工厂的设施、设备、机床、机房、车间、测台等必须要做高效准确的定义。我们进行项目规划建设时，都会做大量的数据治理工作，但是在具体实施工作上，还是要使用这些传统工具和技术。TDengine 可以有效汇集各种机器数据源，并且能够高质量的提炼，这个是过去的时序数据产品所不具备的。
“是提速，更是赋能”
中国有句话叫做“长江后浪推前浪，一代新人胜旧人”，IT 世界千变万化，如果你和我一样，一直在关注着 TDengine，就会发现，它这几年崛起的非常迅速。去年 TDengine 推出 3.0 版本，新版本升级成为了一款真正的云原生时序数据库，优化了流计算功能，而且还重新设计了计算引擎，优化工程师对 SQL 的使用，另外增加了 taosX，利用自己的数据订阅功能来解决增量备份、异地容灾，更加方便了企业应用。我对 TDengine 未来的期望是，希望它增加库内机器学习函数，增加 ARIMA 模型、MA 模型等时间相关功能，TDengine 的未来是一个智能学习时间序列数据库，对工业 4. 0 来说不仅是提速，更是赋能。
想了解更多TDengine Database的具体细节，欢迎大家在GitHub上查看相关源代码。