背景
新しい風と今年のインターネット業界のリフトは、常に背の高い上の新しい用語のすべての種類を聞いて。ビッグデータ、人工知能、ネットワーキング、機械学習、ビジネスインテリジェンス、諜報警告ああ、というように。
以前のシステムでは、データの可視化、情報管理、およびプロセス制御のため。今、ビジネスだけでなく、持って管理し、制御するには、このシンプルで満足します。データの可視化解析、大規模なデータマイニング、統計的予測、モデリングとシミュレーション、インテリジェントな制御は、さまざまなサービスの追求となっています。
私たちは本当の問題を解決するためにインターネットを使用する前に、「涙のようにすべてが時間の中に消え、時間は、死にかけています」。今、私たちが現実に、時系列データ接続に満足されている、あなたはその動きを予測するため、将来の動向を把握することができ、その規則性を明らかにすることができます歴史の彼らの見解を転送することができます。
だから、我々はデータベースの分類の新しいタイプを作成し、（そのようなログ、ユーザの行動など）時間に関連する大量のデータの格納を開始し、構造的特性およびこれらのデータ、継続的な改善と最適化の一般的な使用シナリオをまとめた - 時系列データベース（時系列データベース）。
時系列モデル
主に（すなわち、の時系列、時間変化のために）タイムスタンプ付きデータを処理するための時系列データベースを参照し、時間タグ付きデータは、時系列データと呼ぶことにします。
次のように各時点の構造は以下の通りであります：
タイムスタンプ：時刻データポイントは、データが発生した時間を表します。
メトリック：インデックス名、現在の識別データは、いくつかのシステムにも名前を呼ばれます。
値：数値データの値は、例えば、CPU使用率、トラフィックおよびその他の値などの、典型的にdouble型は、いくつかのシステムのデータポイント値を持つことができ、値は時系列の複数のピースです。一部のシステムでは、別のキーに発現し、より多くの価値を持つことができます
タグ：提携プロパティ。
実現
例えば、私は、センサの時系列データのシリーズを記録したいです。データは以下のように構成されています。
-
識別子：DEVICE_ID、タイムスタンプ
-
メタデータ：location_idの、dev_type、firmware_version、CUSTOMER_ID
-
機器インデックス：cpu_1m_avg、FREE_MEM、used_mem、net_rssi、net_loss、バッテリー
- センサ指標：温度、湿度、圧力、CO、NO2、PM10
あなたは次のような構造にテーブルを構築し、従来のRDBMSストレージを使用する場合：
テーブル
だから、簡単な時系列データベースのアップです。しかし、これは、データモデルのニーズを満たすためだけです。我々はまた、性能、効率的なストレージ、高可用性、分散性と使いやすさの面でより多く行う必要があります。
あなた自身が時系列データベースを達成するために聞かせている場合は、考えると考えることができ、あなたが設計し、あなたが検討するもののパフォーマンスを最適化する方法を、高可用性を行う方法、使用に簡単な操作を行う方法について説明します。
タイムスケール
このデータベースは、実際には、従来の時間ベースのリレーショナルデータベースPostgreSQLの変換配列データベースです。postgresqlの学生が知って学び、PostgreSQLは、データベース・システムでは特に強いスケーラブルな、強力な、オープンソースです。
timescale.incはタイムスケール、基盤となるストレージアーキテクチャ上のタイミング互換性のあるSQLデータベースのPostgreSQLを開発しましたので。PostgreSQLサービスの延長として。次のようにその特徴は以下のとおりです。
基本：
すべてのSQLのためのPostgreSQLのネイティブサポートは、（セカンダリインデックス、非時間集計、サブクエリ、JOINを、窓関数を含む）完全なSQLインタフェースが含まれています
データベースに直接適用することができるツールを使用してPostgreSQLのクライアントまたはクライアント、変更する必要はありません。
時間指向の機能、API関数と最適化された対応します。
信頼性の高いデータストレージ。
拡張：
（単一ノード）を増幅するための拡張、透明な時間/空間仕切り
（一括提出、インデックスメモリ、トランザクションのサポート、データのバックアップサポートを含む）の高いデータ書き込み速度
大量のデータへの迅速なアクセスを確保するために単一のノード上の適切なブロックサイズ（二次元データパーティション）。
ブロックとサーバとの間の並列動作の間
短所：
TimescaleDBが列預金技術を使用していないので、それは時系列データを圧縮する効果を約4倍の最大の圧縮率で、非常に良いではありませんしました
高いパフォーマンス要件は、スタンドアロンのサーバーを持つことになりますので、完全に、（開発関連の機能の下で）分散展開をサポートしていないもの
実際には、このデータベースにさらに見に行くことができます。我々は、すべてのRDBMSに精通している、これは、私たちは、RDBMSのより深い理解を理解するために、その実装メカニズム、ストレージメカニズムを理解することができます。時系列の専門処理の中で、私たちは、時系列データの特性を学び、時系列モデルのRDBMSを最適化する方法を学ぶことができます。
その後、我々はまた、特性の綿密な外観のために記事を書いて、このデータベースを達成することができます。
Influxdb
Influxdbは特に、IOTおよび監視に非常に一般的であり、業界の多くの人気のあるAの時系列データベースです。その使用は、外出先言語開発、顕著な特徴は、パフォーマンスです。
特長：
効率的な時系列データの書き込み性能。カスタムTSMエンジン、高速なデータの書き込みや、効率的なデータ圧縮。
依存追加のストレージありません。
シンプルで高性能なHTTPクエリと書き込みAPI。
グラファイト、collectd、及びopenTSDB：のようなデータ摂取の異なるプロトコルをサポートするための多くのプラグイン
SQLに似たクエリ言語、クエリおよび集計操作を簡素化します。
インデックスタグは、高速で効率的なクエリの時系列をサポートしています。
期限切れのデータ保持ポリシーの効果的な除去。
より効率的に頻繁にクエリを作る重合における連続自動クエリデータ、。
Influxdbは、クローズドソースバージョンに配布されて。これが弱点であるので、分散したクラスタでは、独自の実装を必要とします。
OpenTSDB
スケーラブルな時系列データベース。オープンOpenTSDB公式サイト、あなたが見る最初の事は、この文です。これは、その重要な特徴としてスケーラブルます。OpenTSDBは、HBaseの特性を活用するのHadoopとHBaseの、上で実行されます。それが増加またはサービスノードを減少させることによって容易に拡張容量をできるように、別々の時系列悪魔（TSD）することで、サービスを提供しています。
TSDBアーキテクチャ
Opentsdb HBaseのは、時系列データベース（新しいバージョンもカサンドラをサポートしています）に基づいています。
高可用性を実現するためにベースの分散保存特性データのHBaseの列、高性能書き込み特性。HBaseの、不十分な大きな収納スペース、圧縮によって制限されます。全体のHBase、ZooKeeperの依存
タグセットフリーモードデータ構造（sys.cpu.user 1436333416 23ホスト= WEB01ユーザー= 10001）
非友好的なシンプルな構造、多値クエリ
HTTP-DSLのお問い合わせ
TSDBのrowKeyデザインと設計のためのHBaseのテーブル上のOpenTSDBは、機能の私達の深い研究の価値があります。興味がある学生が学ぶことを学ぶにいくつかの詳細な情報を見つけることができます。
ドルイド
ドルイドは、リアルタイムのオンライン解析システム（LOAP）です。そのアーキテクチャのコンバインリアルタイムのオンラインデータ分析は、異なる使用シナリオを満たすために、フルテキスト検索システムや時系列システム、そのデータのストレージ要件を備えています。
簡単に圧縮データに、サポート効率的なスキャンおよび重合：ストレージを使用して列。
スケーラブルな分散システム：ドルイド自体はスケーラブルで、フォールトトレラント分散型クラスタアーキテクチャを達成するために。導入が容易。
超並列能力：ドルイド各クラスタノードが同時にコンサルティングサービスを提供することができます。
リアルタイムおよびバッチデータの摂取：などカフカなどによるリアルタイムデータのドルイド摂取。バッチデータは、摂取したHadoopのデータとして導入することができます。
自己修復、自己均衡、簡単な操作とメンテナンス：高可用性と耐障害性を実現するドルイド独自のアーキテクチャ。異なるサービスノードは、要求に応じてノードに応じて加算または減算することができます。
データを確実にするフォールトトレラントなアーキテクチャが失われることはありません：ドルイドは、データの複数のコピーを維持することができます。さらにHDFSは、データが失われないことを確実にするために、深さストレージとして使用することができます。
インデックス：ドルイドは逆の文字列とビットマップ索引をコーディング達成するために、効率的なフィルタとGROUPBYをサポートしています。
時間ベースのパーティショニング：ドルイド、元のデータ・ストレージ・パーティションドルイド範囲ベースのクエリは、より時間効率的になりますので、実行する時間に基づきます。
自動予備重合：摂取のデータ予備重合処理中のデータのドルイドサポート。
ドルイドアーキテクチャは非常に複雑。サービス、クエリ、データの多様に分けるシステム全体によって、その機能は、マスターシステムの異なる機能は、独立した外部記憶装置の展開及び統一照会サービスを提供します。これは、クラスタサービスを分散して低レベルのデータ・ストレージ・サービスを提供します。
ドルイドアーキテクチャ
アーキテクチャ設計上のドルイドは、学習の価値があります。あなたは時系列ストレージだけでなく、に興味がある場合は、分散型クラスタアーキテクチャもドルイドのアーキテクチャを見て、興味を持って。さらにドルイド柱状ストレージセグメント（ドルイドデータ記憶構造）設計で実現ハイライト、であるが、逆索引を達成します。
Elasticsearch
Elasticsearchは、テキスト、数字、地理空間、構造化および非構造化データを含むすべてのタイプのデータに適用分散型のオープンソースの検索・分析エンジン、です。Elasticsearchは、最初2010年に（今弾性として知られている）Elasticsearch NVによって公開され、ApacheのLuceneのベースに開発されました。そのシンプルなRESTスタイルのAPIをElasticsearch、分散性、スピードと拡張性が知られています。
ELKスタックにElasticsearchが知られています。多くの企業は、ベースELKログ分析システムとリアルタイムの検索システムを設定します。私たちは、ELKに基づいてメトリックの監視システムの開発を始める前に。これは、店舗の時系列データベースにElasticsearchの使用を考えました。したがって、完全にビジネスのニーズを満たすため、時系列データモデル、収穫良い結果を格納することが、より適切なものに、マッピングのElasticserachを最適化。後半Elasticsearch新しいバージョンで発見されたとしてもメトリックAPM部品やアセンブリ、及びそのフルテキスト検索、時系列の記憶容量のプロモーションの多くを公開し始めました。そして、私たちは本当に一致を考えていました。
タイミング最適化Elasticsearchは記事を参照することができます：「elasticsearch-として-時系列データ・ストア」
あなたは、メトリックのコンポーネントのElasticsearchを見て行くことができます：弾性メトリック
Beringei
Beringei Facebookは2017年、最新のオープンソースの高性能データ・ストレージ・メモリ・タイミング・エンジンです。高速の読み取りと書き込み、および高圧縮率や他の特性を有します。
2015 Facebookは紙発行の「ゴリラ：A高速、スケーラブル、インメモリー時系列データベース」を、Beringeiはこのアイデアの時系列データベースの実装に基づいています。
圧縮は、XOR値を用いて符号化、データのデルタのデルタアルゴリズムストレージを使用Beringei。それは、大量のデータを使用できるように、非常に少ないメモリの下に格納することができます。
適した時系列データベースを選択する方法
データ・モデル
時系列データモデル、二つの一般的であり、非スキーマは、タグモデルを複数有する、名前、タイムスタンプ、値型があります。前者は、複雑なビジネスモデルのためのより適切な多値モデルに適しています。後者は、一次元データモデルのために適しています。
クエリ言語
現在では、ほとんどのTSDBサポートHTTPベースのSQLのようなクエリ。
確実
主に高可用性システムの安定性の可用性、ならびに保存されたデータの可用性に関する。良いシステムは、エレガントかつ高可用性アーキテクチャを持っている必要があります。シンプルで安定しました。
演奏
パフォーマンスは、我々が考慮しなければならない要因です。我々は、データモデルのニーズに加えて、複数のデータ記憶セグメントを考え始めるときには、大きな理由は、パフォーマンス上の共通データベース・システムは、当社のニーズを満たしていないです。配列ライブラリーは、一度書き、多くの小さなシーンを読ん傾向にある時間のほとんどは、ユーザーが自分たちのニーズのバランスを取る必要があります。ここでは、参照を行うことができ、各ライブラリの性能比較があるでしょう。
生態系
私はいつも私たちはエコロジーを真剣に検討しなければならないのオープンソースコンポーネントで選択することを考えました。良い生態系は、人々がより多く使用し、未知のピットが少なくなります。使用中のほかの出会いの問題、リゾートコミュニティでは、多くの場合、いくつかのよりよい解決策を得ることができます。また、良好な生態系、およびシステムのその周囲の境界は非常に私たちは複数の他のドッキング・システムでプログラムを成熟している可能おり、成熟になります。
運営管理
操作しやすい簡単操作・保守、。
当社及びサポート
会社の背後にある支援システムがより重要です。大きな経験を持つことになり、可用性と継続的なメンテナンスアップデートを確実にするために投影し、強力な企業や組織、背後にあります。
性能比較
タイムスケールInfluxDB OpenTSDBドルイドElasticsearch Beringei
ライト（単一ノード）15K /秒470K /秒32K /秒25K /秒30K /秒の10メートル/秒
ライト（5ノード）100K /秒120K /秒128K /秒
概要
あなたは自分自身には、以下の適切なメモリ要件を選択することができます。
小さいながらも優れた、高性能、少量のデータ（億）：InfluxDB
タイムスケール：シンプルで、データの量（千万）は、関節の問い合わせ、リレーショナルデータベースインフラストラクチャがあります
大量のデータ、分散クラスタリングの要件に基づいて、ビッグデータサービス：opentsdb、KairosDB
分散クラスタリングリアルタイムのオンライン分析OLAP要件、およびよく資源不足：ドルイド
究極のパフォーマンス、ホットとコールドデータの大きな違いの追求：Beringei
elsaticsearch：ローディング、分散コンピューティング重合の両方を取得します
あなたの両方の需要とインデックスの時系列の場合。だから、ドルイドとElasticsearchは最良の選択です。その性能は悪くないが、検索された特性は、時系列を満足しつつ、高度に利用可能であり、耐性アーキテクチャフォールト。
遂に
その後、我々は、このようなようにInfluxdb、OpenTSDB、ドルイド、Elasticsearchとして、1または2 TSDBを理解することができます。これに基づき、メモリストレージの異なる行と列について学ぶことができ、LSMの原則の実現、数値データの圧縮、読みとmmapの書き込み性能の知識などを強化します。