著者: ビッグ データ モデル
この記事は、2022 年の「TDengine を使用して TDengine を作成する」エッセイ提出活動からのものです。
仕事柄、ここ数年国内のいろいろなデータベースに触れてきましたが、忘れられないのがTDengineです。数あるデータベースの中でもTiDBが際立っており、OceanBaseは名家の出身で、openGaussはファーウェイの支援を受けており、TDengineだけがヒーロー気分を味わえる. OceanBase でさえ内部アプリケーション要件に基づいて構築されましたが、TDengine だけはオープン ソースやサードパーティ ソフトウェアに依存せずに自己開発されました。さらに、これは汎用データベースではなく、主に産業用ネットワークにサービスを提供する独自のソーシャル アプリケーション シナリオを備えています。
この記事では、TDengine の定義と理解に基づいて、TDengine で解決できる問題、その利点と注目点、および他のデータベースとの相違点について詳しく説明し、TDengine バディに興味を持っている人の助けになることを願っています。
「汎用データベースと違い、TDengineは無駄な荷物を捨てる」
データベースが優れた読み取りと書き込みを実現したい場合、コア機能はインデックス作成です. 一般に、データベース製品には前方インデックス作成機能があります. いわゆるフォワード インデックスは、ドキュメント レコード内の識別子をキーワードとして使用するものであり、キー識別子はディスク全体をスキャンする必要がなくなりました。B ツリー インデックス、ハッシュ インデックス、およびビットマップ インデックスには違いがありますが、一般的な方向は順方向インデックスに属します。
フォワード インデックスに加えて、リバース インデックス (逆インデックスとも呼ばれます) もあります. リバース インデックスは、主に ElasticSearch などの全文検索に使用され、ほとんどのデータベースはフォワード インデックスです. TDengine also uses a forward index. その特別な機能は、データ値 (特定の時間における特定のインジケーター オブジェクトのデータ値) の明確な説明を形成するために、識別子にタイムスタンプとディメンション インジケーター データを含める必要があることです。
データ編成のストレージ エンジンの観点から、データベースの最下層は B ツリー メカニズムと LSM メカニズムに分けることができます.2 つのメカニズムは最適ではなく、それぞれに長所と短所があります:
B-tree の最大の利点は、データの読み取り性能を継続的に向上させることができることであり、データのレベルが上がっても読み取りが拡大することはありません。その秘密は、データの究極の永続的なストレージにあります。Bツリーは、整然とした規則的なデータ構造でハードディスクに保存されます。このようにして、データがますます大きくなっても、整然とした規則的な機能を維持し、何千もの読み取り操作に直面しても、条件に応じて実行し、読み取り増幅の動作を軽減または回避できます。
B ツリー メカニズムとは対照的に、LSM メカニズムは書き込み増幅を減らして回避します。LSM の仕組みはメモリをフル活用してメモリに空間を開け、まずメモリにデータを書き込んで書き込んで直接ユーザーの成功を返す、B 木のようなものを書くのではなく、私よりも年上で、私よりも大きな人小さな、十分なメモリがある限り、メモリに直接書き込むだけで、メモリが特定のしきい値に達すると、メモリ内のデータがバッチでハードディスクに書き込まれ、一度に順番に、メモリはリセットされ、新しいものを提供するためにクリアされます。
従来のデータベース MySQL と Oracle は B-tree メカニズムを使用し、TiDB と OceanBae は最適化された LSM メカニズムを使用しますが、TDengine は B-tree + LSM メカニズムを使用し、B-tree はメタデータ [主にタイムスタンプ + インデックス データ] を格納します。 LSM メカニズムは特定のデータを格納し、メタデータは順序付けられたテーブル構造に格納され、特定のデータは追加された方法で書き込まれるため、大量の読み取りと書き込みの増幅が回避されます。
一般的に言えば、同時実行制御のパフォーマンスを向上させるために、OLTP 製品にはコピー オン ライトまたは MVCC 機能オプションが必要です. コピー オン ライトとMVCC はデータの一貫性を保証しますが、より多くの IO 負担をもたらします. TDengine はデータを変更する必要がないため、データの一貫性の問題を考慮する必要はありません. データは、順序付けられて追加された形式で書き込まれます. 読み取りと書き込みのみであるため、ロック保護の必要はなく、役に立たないアイテムは捨てられますが、その分、カラムナ テーブルなどの他の場所の最適化に専念できます。
業界の一般的なデータベースには、行ベースのテーブル、列ベースのテーブル、さらにはさまざまなビジネス向けの完全なメモリ ライブラリがあります.特定のデータ ストレージについては、TDengine はハードディスク上の完全な列ベースのストレージを使用しますが、ディメンション インジケーターは行ベースのテーブルに格納されます。ベースメモリ。TDengine はマシンのデータに直面しているため、マシンは 24 時間稼働してミリ秒ごとにデータを生成します. TDengine は、より多くのデータを格納するために、行と列の共存と目的の分離の方法を使用します.
一般に、データベースの各行の文書レコードは非常に重要であり、この行に記録されている情報がトランザクションとは関係なく、ユーザーの基本的な情報にすぎないとしても、その値の密度は非常に高くなります。しかし、時系列データベース (Time Series Database) は異なります. 単一行のドキュメント レコードの値密度は低く、1 秒間に 10,000 レコードを生成でき、データの値を反映するにはデータを集計する必要があります。通常のデータを迅速かつ効果的に集約して、価値密度の高いデータに変換します。これは、時系列データベースを他のデータベースと区別する重要な機能でもあります。
TDengine は現在、市場と個々の開発者のニーズを満たすために、コミュニティ バージョン、エンタープライズ バージョン、およびクラウド バージョンの 3 つのバージョンの製品を提供しています。
「時系列データベースの解体、いくつかの主要な製品機能の分析」
技術的には、TDengine は時系列分野に焦点を当てた分散型大量データ分析プラットフォームです。その競合相手は、直接的な競合相手と間接的な競合相手に分けることができ、間接的な競合相手には、国内の TiDB、OceanBase、GaussDB と海外の Oracle、MySQL などがあります。ここで TDengine が役に立ちます。TDengine と直接競合する競合他社には、Druid、OpenTSDB、および InfluxDB があり、これらはすべて時系列分析の前身です。
Druid は、メモリを最大限に活用するのに役立つ Lambda アーキテクチャを採用し、履歴データをハードディスクに保存し、特定の時間粒度に従ってデータを集約し、リアルタイム処理とバッチ処理データを分離する分散システムです。 . リアルタイム処理は、書き込みが多く読み取りが少ないシナリオ用であり、主にストリーミング方式で増分データを処理します. バッチ処理は読み取りが多く書き込みが少ないシナリオ用であり、主にこの方法でオフライン データを処理します. Druid は Hadoop に依存しています。クラスタにはシェア ナッシング アーキテクチャが採用されています。各ノードには独自のコンピューティング機能とストレージ機能があります。システム全体は Zookeeper によって調整されます。計算パフォーマンスを向上させるために、HyperLoglog、DataSketches のいくつかの基本計算を含む近似計算方法を使用します。
OpenTSDB は、数千億のデータ ポイントの格納をサポートし、正確なクエリを提供するオープン ソースの時系列データベースです. Java 言語で記述され、HBase ベースのストレージを通じて水平拡張を実現します. OpenTSDB は、サーバーの監視と測定に広く使用されています。サーバー、センサー、IoT、および財務データのネットワークおよびリアルタイム監視。OpenTSDB の設計思想は、HBase のキーを使用していくつかのタグ情報を保存し、同じ時間のデータを 1 つの行に保存して、クエリの速度を向上させることです。OpenTSDBは次元タグなどを事前に定義し、洗練されたデータ編成形式でHBaseに配置します. HBaseのkeyRangeを介して迅速なクエリを実行できます. ただし、OpenTSDBの効率は、任意の次元の編成クエリで低下します.
InfluxDB は、Go 言語で開発された非常に人気のある時系列データベースです。コミュニティは非常に活発であり、技術的な機能は、任意の数の列、デパターン化、統合されたデータ コレクション、ストレージ、ビジュアル ストレージをサポートし、高圧縮率アルゴリズムを使用してサポートします。効率的なストレージ、TIME SERIES MERGE TREE の内部ストレージ エンジンを採用し、SQL に類似した言語をサポートします(バージョン 2.0 ではサポートされなくなりました)。
時系列のビジネス バックグラウンドについては、OLAP シナリオで事前集計を実行して、データ量を削減するのが一般的です。事前集計に影響する主な要因は、次のように要約できます。
次元指標の数
ディメンション メトリックのカーディナリティ
次元指標の結合度
粗粒度および細粒度の時間ディメンション メトリック
効率的な事前集計を実現するために、TDengine の秘密はスーパー テーブルです. Druid は事前に事前計算を定義します. InfluxDB には独自の連続クエリ メソッドもあり、HBase を使用する場合にのみスプライシングされます. したがって、HBase異なるディメンションのインデックス クエリが含まれる場合は遅くなります。
近い将来、TDengine の TSBS ベースのテスト レポートがリリースされる予定です.最初のレポートでは、InfluxDB と TimeScaleDB の詳細なパフォーマンス レベルの比較分析が行われます. 関心のあるパートナーは、最近の公式アカウントの内容にさらに注意を払うことができます.
「今日、TDengine は第一の選択肢でなければなりません」
私のTDengineの知識と理解は、過去のプロジェクト経験から始まります.2018年を背景に、業界における不良部品と不良部品の予測についての話をします.
会社のビジネスが急速に成長し、有名なグループの新しい工場が増え続けているため、あらゆる種類の貴重なデータを適切に統合、分析、発掘して、その価値を十分に引き出すことはできません。現在、会社の発展は次の「闘争」戦略に入った.迅速な対応と正確な予測が事業発展の鍵である.ビッグデータはその中で重要な役割を果たしている.科学的分析方法を使用して、さまざまなシステムからのデータを統合する.近代化の進展は緊急の課題となっています。
同じ特殊な問題のガラスIDが現在の工場の生産工程で発生しており、様々な理由でガラスの品質にばらつきがあり、品質に異常のあるガラスが存在する場合もあります。これらの異常ガラスの検出過程では、異常の原因を特定することは不可能であり、異常の原因を迅速に突き止めることができなければ、さらに異常なガラスが発生し、生産に深刻な影響を与えることになります。応答の具体的な手段には次のものがあります。
異常な品質のガラスを通して、この異常を生み出す相関要因を見つけます。例：機械、材料、車両、パラメータなど
異常なガラスの検出と早期警告は、異常な品質を生み出す要因の数学的モデリングを通じて、正常な範囲から逸脱する異常なガラスを予測し、早期に警告します。
分析 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上查看相关源代码。