Lindorm には、LindormTable エンジン、LindormTSDB エンジン、検索エンジン、、コンピュートエンジン、およびストリーミングエンジンが含まれます。また、HBase、Cassandra、S3、OpenTSDB、Solr、HDFS などの複数のオープン標準インターフェイスと互換性があります。さらに、SQL クエリ、時系列データ処理、テキスト検索および分析をサポートします。
各 Lindorm エンジンのコンピューティングおよびストレージリソースは、お客様のビジネスにおける動的なワークロードに応じて個別に水平スケーリングできます。ワイドテーブルエンジンおよび時系列エンジンは、高い同時実行性と高いスループットを提供します。
エンジンの選択
各エンジンタイプは、特定のユースケースを想定して設計されています。お客様の要件に応じて、1 つまたは複数のエンジンを選択できます。詳細については、以下の表をご参照ください。
エンジンタイプ | 互換性 | シナリオ | 説明 |
ワイドテーブルエンジン (LindormTable) | SQL、HBase API、Cassandra Query Language (CQL)、Amazon S3 API と互換。 | メタデータ、注文、請求書、ユーザーペルソナ、ソーシャル情報、フィード、ログ、軌跡などの管理および分析に適しています。 | 大規模な半構造化および構造化データ向けに設計された分散型ワイドカラムエンジンです。グローバルセカンダリインデックス、多次元検索、動的カラム、TTL、数十万件／秒の高同時実行性操作スループット、数百ペタバイト規模のストレージ容量をサポートします。オープンソース HBase と比較して、スループット性能は 3～7 倍、P99 レイテンシは 1/10 です。ホット・コールドデータ分離をサポートし、圧縮率はオープンソース HBase の 2 倍、全体的なストレージコストはその半分です。また、空間・時空間データ全般に対応した組み込みの GanosBase 時空間サービスを備えており、大規模な履歴軌跡クエリおよび分析ユースケースをサポートします。 |
時系列エンジン (LindormTSDB) | HTTP API を提供し、OpenTSDB API と互換。 | IoT やモニタリングなどのユースケースにおいて、デバイスの測定データや運用データなど、時系列データの保存および処理に適しています。 | 時系列エンジンは、大量の時系列データを処理するための分散ストレージエンジンです。SQL クエリをサポートします。また、時系列データ専用の圧縮アルゴリズムを提供することで、データ圧縮率の向上を実現します。さらに、タイムライン単位で大量の時系列データを多次元でクエリおよび集約できるほか、ダウンサンプリングおよび弾力的なスケーリングもサポートします。 |
検索エンジン | SQL、Apache Solr、Elasticsearch API と互換。 | ログ、テキスト、ドキュメントなど、大量のデータのクエリに適しています。たとえば、ログ、請求書、ユーザーペルソナの検索に検索エンジンを利用できます。 | Lindorm は分散検索エンジンを提供します。この検索エンジンは、ストレージとコンピューティングの分離アーキテクチャを採用しています。ワイドテーブルエンジンおよび時系列エンジンのインデックスをシームレスに格納でき、データ検索を高速化します。全文検索、集約、複雑な多次元クエリなど、多様な機能を提供します。また、1 つの書き込みレプリカと複数の読み取り専用レプリカから構成されるアーキテクチャをサポートし、水平スケーリング、ゾーン間ディザスタリカバリ、TTL などの機能により、大量データの効率的な検索要件を満たします。 |
コンピュートエンジン | Apache Spark API と互換。 | 大量データ生成、対話型分析、機械学習、グラフコンピューティングなどのユースケースに適しています。 | コンピュートエンジンは、クラウドネイティブアーキテクチャに基づく分散コンピューティングサービスを提供します。コミュニティ版のコンピューティングモデルおよびプログラミングインターフェイスをサポートします。また、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 秒あたりのリクエスト数および 1 ノードあたりのリージョン数に応じて、ノード仕様を選択できます。
-
商品タイプ: インスタンス作成時に Lindorm を選択した場合、最小の LindormTable ノード仕様は 4 CPU コア／16 GB メモリです。
各 LindormTable ノードのメモリが 16 GB 未満の場合、一部の LindormTable パフォーマンス最適化機能が正常に動作しない可能性があります。また、LindormTable が 2 ノード以下のみで構成されている場合、一部の書き込み最適化機能が正常に動作しない可能性があります。したがって、LindormTable には、最低でも 3 ノード以上、かつ各ノードが 8 コア／32 GB メモリ以上の仕様を選択してください。各 LindormTable ノードには、16 コア／64 GB メモリの仕様を選択することを推奨します。
以下のような選択を推奨します。
1 ノードあたりの 1 秒あたりのリクエスト数が 1,000 未満、かつ 1 ノードあたりのリージョン数が 500 未満の場合、4 CPU コア／16 GB メモリの仕様を選択します。
1 ノードあたりのリクエスト数が 20,000 未満、かつシャード数が 1,000 未満の場合、8 vCPU／32 GB メモリ以上の仕様のインスタンスを使用できます。
1 ノードあたりの 1 秒あたりのリクエスト数が 20,000 を超え、かつ 1 ノードあたりのリージョン数が 1,000 を超える場合、16 CPU コア／64 GB メモリの仕様を選択します。
重要ノード仕様を選択する際には、1 秒あたりのリクエスト数および 1 ノードあたりのリージョン数だけでなく、他の要因も考慮する必要があります。
上記のルールに厳密に従ってノード仕様を選択した場合、複雑なビジネスでは安定して動作せず、レイテンシが増加する可能性があります。したがって、お客様のビジネスが以下のいずれかの条件に該当する場合は、上記のルールで示された仕様よりも高いノード仕様を選択することを推奨します。
アクセス対象の行に KB 単位、あるいは MB 単位のデータが含まれる場合。
SCAN リクエストで複雑なフィルター条件が指定されている場合。
リクエストキャッシュのヒット率が低く、すべてのリクエストがディスクにアクセスせざるを得ない場合。
インスタンスに複数のテーブルが存在する場合。
オンラインサービスを提供している場合、より多くのデータをキャッシュするために、メモリ容量の大きなノード仕様を選択して、クエリパフォーマンスを向上させることを推奨します。
MapReduce タスクや Spark タスクなどの重負荷のオフラインタスクを実行する必要がある場合、または TPS／QPS が非常に高い場合、より多くの CPU コアを備えたノード仕様を選択することを推奨します。
ノードの CPU 使用率が継続的に 70% 以上である場合、ノード仕様のアップグレードを推奨します。
時系列エンジン (LindormTSDB)
LindormTSDB ノードは、4 CPU コア／8 GB メモリから 32 CPU コア／256 GB メモリまでの仕様をサポートします。ビジネスにおける TPS に応じて、LindormTSDB ノード数およびノード仕様を選択できます。
商品タイプ: インスタンス作成時に Lindorm を選択した場合、最小の LindormTSDB ノード仕様は 4 CPU コア／16 GB メモリです。
以下のような選択を推奨します。
TPS が 190 万未満の場合、4 CPU コア／16 GB メモリのノードを 3 台選択できます。
1 秒あたりのトランザクション数 (TPS) が 390 万未満の場合、8 vCPU／32 GB メモリのノードを 3 台選択できます。
1 秒あたりのトランザクション数 (TPS) が 780 万未満の場合、16 vCPU／64 GB メモリのノードを 3 台選択できます。
1 秒あたりのトランザクション数 (TPS) が 1,100 万未満の場合、32 コア／128 GB メモリのノードを 3 台選択できます。