ワイドテーブルエンジン、時系列エンジン、検索エンジン、コンピューティングエンジン、ストリーミングエンジンなど、さまざまなエンジンが組み込まれている Lindorm は、Apache HBase、Apache Cassandra、Amazon Simple Storage Service (Amazon S3)、OpenTSDB、Apache Solr、Hadoop 分散ファイルシステム (HDFS) など、複数のオープンソースソフトウェアおよびサービスの標準 API とも互換性があります。このように、Lindorm は、SQL クエリ、時系列データ処理、テキストベースのデータクエリと分析など、マルチモーダルデータの機能を提供できます。
各 Lindorm エンジンのコンピューティングリソースとストレージリソースは、ビジネスの動的なワークロードに適応するように個別にスケーリングできます。ワイドテーブルエンジンと時系列エンジンは、高い同時実行性と高いスループットを提供します。
エンジンの選択
ビジネス要件に基づいて、1 つ以上のエンジンを選択できます。次の表に、Lindorm でサポートされているエンジンを示します。
エンジン | 互換性 | シナリオ | 説明 |
ワイドテーブルエンジン (LindormTable) | SQL、HBase API、Cassandra Query Language (CQL)、および Amazon S3 API と互換性があります。 | メタデータ、注文、請求書、ユーザーペルソナ、ソーシャル情報、フィード、ログ、軌跡の管理と分析に適しています。 | ワイドテーブルエンジンは、大量の半構造化データと構造化データの分散ストレージに使用されます。グローバルセカンダリインデックス、多次元検索、動的カラム、および Time-To-Live (TTL) 機能をサポートしています。ワイドテーブルエンジンは、数千万の同時リクエストを処理し、ペタバイトのデータを格納できます。また、コールド・ホットデータ分離機能も提供します。オープンソースの Apache HBase のパフォーマンスと比較して、読み取り/書き込みパフォーマンスは 2 ～ 6 倍向上し、パーセンタイル 99% (P99) のレイテンシは 90% 削減され、圧縮率は 100% 削減され、ストレージコストは 50% 削減されます。ワイドテーブルエンジンは、空間データまたは時空間データに適用可能な組み込みの Lindorm GanosBase サービスを提供します。 Lindorm GanosBase サービスを使用して、大量の履歴軌跡データをクエリおよび分析できます。 |
時系列エンジン (LindormTSDB) | HTTP API を提供し、OpenTSDB API と互換性があります。 | IoT や監視などのシナリオで、デバイスの測定データや運用データなどの時系列データを格納および処理するのに適しています。 | 時系列エンジンは、大量の時系列データを処理するために使用される分散ストレージエンジンです。 SQL クエリをサポートしています。時系列エンジンは、時系列データ専用の圧縮アルゴリズムを提供します。これにより、データ圧縮率が向上します。時系列エンジンを使用すると、複数のディメンションを使用して、タイムラインごとに大量の時系列データをクエリおよび集約できます。エンジンは、ダウンサンプリングと弾性スケーリングもサポートしています。 |
検索エンジン (LindormSearch) | SQL、Apache Solr、および Elasticsearch API と互換性があります。 | ログ、テキスト、ドキュメントなど、大量のデータをクエリするのに適しています。たとえば、検索エンジンを使用して、ログ、請求書、ユーザーペルソナを検索できます。 | Lindorm は、分散検索エンジンを提供します。検索エンジンは、ストレージがコンピューティングから分離されているアーキテクチャを使用します。検索エンジンは、ワイドテーブルエンジンと時系列エンジンのインデックスを格納してデータ取得を高速化するためにシームレスに使用できます。検索エンジンは、全文検索、集約、複雑な多次元クエリなど、さまざまな機能を提供します。また、1 つの書き込みレプリカと複数の読み取り専用レプリカで構成されるアーキテクチャをサポートし、水平スケーリング、ゾーン間のディザスタリカバリ、TTL などの機能を提供して、大量のデータの効率的な取得の要件を満たします。 |
コンピューティングエンジン (LDPS) | Apache Spark API と互換性があります。 | 大量のデータの生成、インタラクティブな分析、計算学習、グラフコンピューティングなどのシナリオに適しています。 | コンピューティングエンジンは、クラウドネイティブアーキテクチャに基づく分散コンピューティングサービスを提供します。 Community Edition のコンピューティングモデルとプログラミングインターフェイスをサポートしています。また、Lindorm ストレージエンジンの機能も統合し、基盤となるデータストレージ機能とインデックス機能を使用して、分散ジョブを効率的に完了します。 |
ストリーミングエンジン | SQL および Apache Kafka API と互換性があります。 | IoT データ処理、アプリケーションログ処理、物流エージング分析、旅行データ処理、リアルタイム軌跡処理などのシナリオに適しています。 | Lindorm ストリーミングエンジンは、ストリーミングデータを格納および処理するために使用されます。軽量のコンピューティング機能を提供します。ストリームコンピューティングエンジンを使用してストリーミングデータを Lindorm に格納して、ストリーミングデータの処理とアプリケーションの要件を満たすことができます。ワイドテーブルで提供される Lindorm GanosBase サービスを Lindorm ストリーミングエンジンと組み合わせて使用して、電子ジオフェンシングや地域統計収集などのリアルタイム軌跡分析機能を実装できます。 |
ノードの数と仕様の選択
Lindorm は、エンジンノードの水平スケールアウトをサポートしています。ノードを追加して、高レイテンシ、不安定なパフォーマンス、各ノードの過剰なワークロードなどの問題を解決できます。ただし、大量のリクエストが送信されて単一ノードのホットデータにアクセスする場合、ホットデータによって発生する問題を回避するために、ノードの仕様をスペックアップすることしかできません。仕様が高いノードは、ホットデータにアクセスするために送信されたリクエストを処理する能力が高くなります。 また、仕様が高いノードは、ビジネスにより安定したパフォーマンスを提供し、ホットデータにアクセスするために送信された大量のリクエストとリクエストによって生成されたトラフィックによって引き起こされる過剰なワークロードやメモリ不足 (OOM) の問題を回避できます。
したがって、ビジネスの要件に基づいてインスタンス内のノードの仕様を選択することをお勧めします。 Lindorm コンソールで、Lindorm インスタンス内のノードの仕様をスペックアップできます。詳細については、「インスタンスのエンジン仕様の変更」をご参照ください。ノード仕様の選択方法がわからない場合、またはノード仕様のスペックアップ時にサポートが必要な場合は、Lindorm のテクニカルサポート (DingTalk ID: s0s3eg3) にお問い合わせください。
ワイドテーブルエンジン (LindormTable)
LindormTable ノードは、4 CPU コアと 8 GB のメモリから 32 CPU コアと 256 GB のメモリまでの仕様をサポートしています。 Lindorm インスタンス内の LindormTable ノードの数を増やすことができます。ビジネスの 1 秒あたりのリクエスト数と単一ノードのリージョン数に基づいて、ノード仕様を選択できます。
Lindorm インスタンスの作成時に [プロダクトタイプ] に Lindorm を選択した場合、LindormTable ノードの最小仕様は 4 CPU コアと 16 GB のメモリです。
各 LindormTable ノードのメモリが 16 GB 未満の場合、LindormTable の一部のパフォーマンス最適化機能が正しく動作しない場合があります。 LindormTable に 2 つ以下のノードしか含まれていない場合、LindormTable の一部の書き込み最適化機能が正しく動作しない場合があります。したがって、LindormTable には、それぞれ少なくとも 8 コアと 32 GB のメモリを搭載した 3 つ以上のノードを選択してください。各 LindormTable ノードに 16 コアと 64 GB のメモリを含む仕様を選択することをお勧めします。
次のルールに基づいて LindormTable ノードの仕様を選択することをお勧めします。
単一ノードにアクセスするために送信される 1 秒あたりのリクエスト数が 1,000 未満で、単一ノードのリージョン数が 500 未満の場合は、4 CPU コアと 16 GB のメモリを搭載した仕様を選択してください。
単一ノードにアクセスするために送信される 1 秒あたりのリクエスト数が 1,000 を超えて 20,000 未満で、単一ノードのリージョン数が 500 を超えて 1,000 未満の場合は、8 CPU コアと 32 GB のメモリを搭載した仕様を選択してください。
単一ノードにアクセスするために送信される 1 秒あたりのリクエスト数が 20,000 を超え、単一ノードのリージョン数が 1,000 を超える場合は、16 CPU コアと 64 GB のメモリを搭載した仕様を選択してください。
重要ノード仕様を選択する際には、1 秒あたりのリクエスト数と単一ノードのリージョン数以外の要素も考慮する必要があります。
上記のルールに基づいて複雑なビジネスのノード仕様を正確に選択した場合、ビジネスが安定して実行されない可能性があり、レイテンシが増加する可能性があります。したがって、ビジネスが次のいずれかの条件を満たす場合は、上記のルールで説明されている仕様よりも高いノード仕様を選択することをお勧めします。
アクセスされる可能性のある行には、KB または MB 単位のデータが含まれています。
SCAN リクエストで複雑なフィルター条件が指定されています。
リクエストによってアクセスされるほとんどのデータはメモリにキャッシュされておらず、ディスクに保存されています。
Lindorm インスタンスには多数のテーブルが含まれています。
ビジネスがオンラインサービスを提供する場合は、大きなメモリを搭載したノード仕様を選択して、より多くのデータをキャッシュし、クエリのパフォーマンスを向上させてください。
MapReduce タスクや Spark タスクなどの負荷の高いタスクをオフラインで実行する必要がある場合、またはビジネスの TPS と QPS が非常に高い場合は、CPU コア数の多いノード仕様を選択することをお勧めします。
ノードの CPU 使用率が 70% 以上のままである場合は、ノード仕様をスペックアップすることをお勧めします。
時系列エンジン (LindormTSDB)
LindormTSDB ノードは、4 CPU コアと 8 GB のメモリから 32 CPU コアと 256 GB のメモリまでの仕様をサポートしています。ビジネスの TPS に基づいて、LindormTSDB ノードの数と仕様を選択できます。ビジネスの TPS に基づいて、LindormTSDB ノードの数と仕様を選択できます。
Lindorm インスタンスの作成時に [プロダクトタイプ] に Lindorm を選択した場合、LindormTSDB ノードの最小仕様は 4 CPU コアと 16 GB のメモリです。
次のルールに基づいて LindormTSDB ノードの数と仕様を選択することをお勧めします。
TPS が 1,900,000 未満の場合は、それぞれ 4 CPU コアと 16 GB のメモリを搭載した 3 つのノードを選択できます。
TPS が 1,900,000 を超えて 3,900,000 未満の場合は、それぞれ 8 CPU コアと 32 GB のメモリを搭載した 3 つのノードを選択できます。
TPS が 3,900,000 を超えて 7,800,000 未満の場合は、それぞれ 16 CPU コアと 64 GB のメモリを搭載した 3 つのノードを選択できます。
TPS が 7,800,000 を超えて 11,000,000 未満の場合は、それぞれ 32 CPU コアと 128 GB のメモリを搭載した 3 つのノードを選択できます。
ビジネスのデータ処理パフォーマンスを最大化する場合、上記のルールに基づいて LindormTSDB ノードの数と仕様を選択できます。 LindormTSDB ノードの数と仕様を選択する際には、ビジネスモデルタイプ、バッチのデータサイズ、同時リクエスト数など、他の要素も考慮する必要があります。詳細については、「書き込みテストの結果」および「クエリテストの結果」をご参照ください。