Tablestore

プロダクト紹介

Table Storeとは

Alibaba Cloud Table Store は、高速でかつ拡張性を備え、リアルタイムでアクセスできる NoSQL データストーレジサービスです。Alibaba Cloud の Apsara 分散システム上に構築されています。

  • データをパーティション化およびロードバランシングによりシームレスにスケーリングできるインスタンスおよびテーブルに編成します。
  • データを基盤となるハードウェア・プラットフォームで発生する障害やエラーなどからアプリケーションを保護し、迅速なリカバリ機能と高可用性のサービスを提供しています。
  • ソリッドステートディスク(SSD)を使用して複数のバックアップを持つデータを管理し、迅速なデータアクセスと高データ信頼性を実現します。

Table Storeを使用する場合、データベースのソフトウェアとハードウェアのクラスタサイズ変更、アップグレード、メンテナンスなどの複雑の問題を処理せずに、格納した分のみ利用料が発生します。

利点

Table Store は完全に管理された NoSQL データベースサービスであり、シームレスなスケーラビリティを備えた高速かつ予測可能なパフォーマンスを提供します。 Table Store を使用すると、分散データベースの運用とスケーリングに伴う管理上の負担を軽減できるため、ハードウェアのプロビジョニング、セットアップと設定、レプリケーション、ソフトウェアのパッチ適用、またはクラスタスケーリングについて心配する必要はありません。 さらに、 Table Store には以下の利点があります。

  • スケーラビリティ
    • 予約済み読み書きスループットの動的調整
      テーブルを作成するときに、ビジネス要件とデータアクセス条件に基づいてアプリケーションのために予約済み読み書きスループットを設定できます。 Table Store は、テーブルの予約済み読み書きスループットに基づいてリソースのスケジュールと予約を行い、リソースの使用コストを最小限に抑えます。 アプリケーションに基づいて、テーブルの予約済み読み書きスループットを動的に調整できます。
    • 無制限の容量
      Talbe Store テーブルに格納されるデータ量は無制限です。 テーブルサイズが大きくなると、Table Store はサイズ変更されたテーブルへの即時記憶領域割り当てのためにパーティショニングを調整します。
  • データの信頼性
    Table Store は、異なるラックの異なるサーバーにまたがって複数のデータコピーを保存します。 障害が発生した場合、データをコピーしたバックアップサーバはすぐにサービスを復元するため、データの損失はゼロです。
  • 高可用性
    自動障害検出とデータ移行により、Table Store はハードウェア障害とネットワーク関連障害の両方からアプリケーションを保護し、高可用性を実現します。
  • 管理のしやすさ
    Table Store が、パーティショニングの管理、ソフトウェアのアップグレード、ハードウェアのアップグレード、構成の更新およびクラスタのサイズ変更などの複雑なタスクを自動的に管理するため、ビジネスの成長に集中できます。
  • 安全なアクセスプラットフォーム
    Table Store は各アプリケーション要求に対して ID 認証を実行し、不正なデータアクセスを防ぎ、データアクセスのセキュリティを確保します。
  • 高い一貫性
    Table Store は、データの書き込みの一貫性を保証し、データの 3 つのコピーがディスクに書き込まれることおよびデータが最終的にすべての格納場所にわたって一貫してしていることを保証します。 書き込み操作に対して成功した結果が返されると、アプリケーションは最新のデータを読み取ることができます。
  • 柔軟なデータモデル
    Table Store テーブルは固定フォーマットを必要としません。 各行の列の数および名前は同じでも行が異なる列の値の型は、変更できます。 Table Store は、Integer 型、Boolean 型、Double 型、String 型、Binary 型など、複数のデータ型をサポートしています。
  • マルチテナントメカニズム
    Table Store は共有ストレージメカニズムを使用します。これにより、異なるユーザーの複数のインスタンスが同じクラスタリソースを共有できます。 Table Store はパーティショニングを最小単位として使用します。これにより、パーティショニングレベルでの負荷分散メカニズムがサポートされ、さまざまなインスタンス間の影響を分離できます。
  • 従量課金
    Table Store は、予約して使用した実際のリソースに応じて料金を請求します。
  • 統合モニタリング
    Table Store コンソールは、1 秒あたりの要求数や平均応答待ち時間など、リアルタイムのモニタリング情報を提供します。

ケーススタディ

このドキュメントでは、Table Store に関するさまざまな典型的なケーススタディを提供し、Table Store についてのより深い理解を得るのに役立ちます。

ビッグデータの保存と分析

Table Store は、低コスト、低レイテンシ、そして高並行性ストレージと大量のデータへのオンラインアクセスを提供します。 さらに、Table Store は、増分データトンネルとフルデータトンネルを提供し、MaxCompute などのビッグデータ分析プラットフォームでの SQL の直接読み取りおよび書き込みも行います。 リアルタイムのデータストリームの計算を容易にするために、効率的な増分ストリーミング読み取りインターフェイスが提供されています。

ビッグデータの保存と分析

ソーシャルフィードストリームの保存

Table Store は、インスタントメッセージング (IM) チャット、コメント、スレッドなど、人々の間のやり取りによって生み出される大量のソーシャル情報を保存できます。 Table Store に保存されているエラスティックリソースは、従量課金方式で請求されます。 非常に競争力のあるコストで、待ち時間を短くする必要があるときにトラフィックの変動が大きく同時実行性が高いアプリケーションのニーズを Table Store は満たすことができます。 Table Store は画像とビデオを OSS に保存し、CDN アクセラレーションを使用して、最適なユーザーエクスペリエンスを提供します。

ソーシャルフィードストリームの保存

財務リスク管理

低レイテンシ、高並行性性、柔軟なリソースに対する従量課金などの Table Store の利点が組み合わされて、財務リスク管理システムが最適化され、トランザクションリスクを厳密に制限できます。 柔軟なデータ構造が、市場ニーズの変化に応じたビジネスモデルの迅速な反復を可能にします。

財務リスク管理

IoV データストレージ

1 つのテーブルに、別々のデータベースとテーブルにデータを分散させることなくペタバイト単位のデータを保存できるため、ビジネスロジックが簡素化されます。 スキーマフリーのデータモデルにより、さまざまな車載機器のモニタリングデータに簡単にアクセスできます。 Table Store は、複数のビッグデータ分析プラットフォームおよびリアルタイムコンピューティングサービスとシームレスに統合して、リアルタイムのオンラインクエリおよびビジネスレポート分析を容易にすることができます。

IoVデータストレージ

IoT 時系列データストレージ

ペタバイト単位のデータを格納し、毎秒数千のクエリ (QPS) を処理できる単一のテーブルで、Table Store は IoT デバイスとモニタリングシステムの時系列データを簡単に保存できます。 ビッグデータ分析 SQL 直接読み取り機能と効率的な増分ストリーミング読み取りインターフェースは、オフラインデータ分析とリアルタイムストリーミングコンピューティングの簡単な方法を提供します。

IoT時系列データストレージ

E-commerce への推奨

Table Store を使用すると、大量の過去の取引注文を処理するときに、データ量とアクセスパフォーマンスに簡単に対処できます。 MaxCompute と組み合わせることで、 Table Store は正確なマーケティング、柔軟なリソースの保存、および従量課金を可能にします。 Table Store を使用すると、多数の顧客がオンラインアクセスするピーク時間を簡単に管理できます。

E-commerceへの推奨

FAQ

Table Store の概要

Table Storeは従来のRDBMSとどう違うのですか?

Table Store は、行と列を使用する 2D、NoSQL データストレージテーブルシステムです。Table Store は、テーブルの作成時に厳密なスキーマを必要とせずに動的に追加または削除できる属性列があります。
Table Store は、従来の RDBMS の豊富な機能(ビュー、索引、トランザクション、および無数の SQL 文など)をサポートしていませんが、スケーラビリティが向上し、使いやすい機能を提供し、非常に大量のデータ)に加えて、各テーブルの 100,000 QPS での同時クエリをサポートしています。
また、Table Store では、簡単なプログラミングのための統一された HTTP RESTful API が提供されています。Table Store リソースの実際の使用量(ストレージと読み取り/書き込みのスループット)に応じて支払いを行います。

テーブル作成時の注意点

テーブルの作成に属性列が必要ですか?

いいえ。Table Store は、半構造化テーブルをサポートしています。表の作成時には、主キー列(列 1〜4)のみが必要です。
表の属性列の数は、Table Store 限定されません。データの各行は、異なる量と種類の属性列を持つことができます。アプリケーションがデータを書き込んでいるときは、Table Store にすべてのデータ列(主キー列と属性列)の名前と値を指定するアプリケーションが必要です。

テーブル作成時のプライマリキーの最初の列にあるパーティションキーは何ですか?

表のデータ・サイズが設定値に達すると、Table Store はパーティション・キー列の値の範囲に基づいて表をパーティション化し、ロード・バランシングを実現します。
表の作成時には、表にはデフォルトで 1 つの区画があり、すべての表データはこの区画に入っています。表に複数の区画がある場合、各区画に保管されるデータは、すべて区画キー列の特定の値の範囲内のデータです。パーティションキー列の値のすべての範囲は、主キー列のデータ型 Integer または String に基づく列値の自然順序によってセグメント化されます。
データ問合せのパフォーマンスに加えて、データの区分化も予約済みの読取り/書込みスループットの使用に影響します。 表に複数の区画がある場合、表の予約済みの読み取り/書き込みスループットは各区画に比例します。

適切なパーティションキーを設定するには?

パーティションキーの選択は、大量のデータが存在する場合にテーブルのクエリパフォーマンスに影響するため、テーブル作成時に重要です。アプリケーションのパーティションキーを設定するときは、次の基本原則を守ってください。

  • ユーザーの性別(男性/女性)など、固定値または小さな値の範囲の属性は使用しないでください。
  • 自然順序でソートした後、明示的なクエリホットスポットを持つ属性を避ける。たとえば、TimeStamp を最新のデータを照会するためのパーティションキーとして使用します。
  • UserID などの自然順序でソートした後、散在したクエリホットスポットでアトリビュートを使用します。
質問ホットスポットを予測できない場合、何ができますか?

パーティションキーを書き込む前に、アプリケーションの機能に従ってデータをハッシュすることをお勧めします。たとえば、データ行を書き込むときは、単純なハッシュアルゴリズムを使用して UserID のハッシュ値を生成し、ハッシュ値と UserID をスプライスし、パーティションキー値として Table Store テーブルに保存します。この軽量な操作は、クエリのホットスポットの問題を効果的に解決できます。パーティションキー値はスプライスされたハッシュ値と実際の値の結果であるため、アプリケーションはパーティションキーを使用して範囲(getRange)を読み取ることができません。

アカウントのテーブル数の制限はいくらですか?制限を増やすことはできますか?

各 Table Store ユーザーは最大10個のインスタンスを作成でき、各インスタンスは 1 つのアカウントで最大 64 個のテーブルを持つことができます。
次のシナリオでは、テーブル数の制限を増やすことができます。

  • 膨大なデータ量と高いクエリパフォーマンス要件
    Table Store、データベースのシャーディングとテーブルの分割によって大量のデータアクセスリクエストに対処する従来の SQL データベース(たとえば、MySQL)とは異なり、分散型設計を採用し、膨大なデータボリュームとアクセス待ち時間のボトルネックを解消します。
    巨大なデータ量に起因する妥協したクエリのパフォーマンスを気にすることなく、構造化されたデータまたは半構造化されたデータをスパーステーブルに保存できます。
  • アプリケーションの急速な成長
    データとアクセス量の増加に加えて、Table Store を使用して、顧客(サードパーティのパートナーやベンダーなど)にサービスを提供することができます。ベンダーにサービスを提供し、Table Store に基づくソリューションを提供する場合は、ベンダーごとに Table Store テーブルのセットを展開する必要があります。この場合、テーブルの数はすぐに上限に達します。テーブルの数量の上限を絶えず増やすと、操作やメンテナンスのコストが制御不能になり、グローバルデータ分析の複雑さが増します。
    Table Store を新しい方法で使用し、同じ型の大規模な構造化/半構造化データを大きなテーブルに保存することをお勧めします。
  • Table Store 考慮事項
    テーブルの数は、テーブル Table Store 分散アーキテクチャのリソース属性です。Table Store クラスタの固定スケールを仮定すると、テーブルの数は最大値を有することが理解できます。Table Store のスケーラビリティは、テーブルの数量の限界に効果的に対処できますが、リソースの制御性のために、Table Store は 1 つのアカウントのテーブルの最大数に制限を設定します。

Table Store で有効なデータ型

Table Store は、Integer、String、Boolean、および Double のデータ型をサポートしています。

  • 整数は、23、-908、および +87 などの 64 ビット符号付き整数を示します。Integer 型の値は、-9,223,372,036,854,775,808 から+ 9,223,372,036,854,775,807 までです。
  • 文字列は、’Test’、’Open Table Service’、’ Table Store User Guide’など、入力時に一重引用符( ‘)で囲まれた UTF-8 文字列を示します。文字列の長さは 0 KB から 512 KB の範囲です。長さは 1,024 バイトを超えないようにすることをお勧めします。
  • Boolean はブール型データを示し、TRUE または FALSE のいずれかに設定できます。
  • Double は、IEEE 754 標準の 64 ビット形式の浮動小数点数を示します(例:1.23、-34.0、+102.23、1.0e-10、 2.006E+3)。

※Double 型は、表またはビューの主キー列には適用されません。
※Double および Boolean 型は、データ・パーティション・キー、つまり主キーの最初の列には適用されません。

テーブルとインスタンスの命名規則

テーブル名の規則
  • 各名前の長さは 1〜255 バイトです。
  • 各名前には、大文字と小文字、数字、アンダースコア(_)を使用できます。
  • 各名前は、文字またはアンダースコアで始まる必要があります。
インスタンス名の規則
  • 各インスタンス名は、リージョン内で一意でなければなりません(異なるリージョン間のインスタンスには同じ名前を使用できます)。
  • 各名前の長さは 3〜16 バイトです。
  • 各名前には、大文字と小文字、数字、ハイフン( - )を使用できます。
  • それぞれの名前は文字で始まる必要があります。
  • 名前はハイフンで終わることはできません。

PK_パーティション

プライマリキー

主キーは、テーブル内のレコードの行を一意に識別します。表を作成するときは、主キーを生成する列を指定する必要があります。これらの指定された列は、主キー列と呼ばれます。主キー列を null に設定することはできません。主キー列の値の組み合わせは、行を一意に識別できる必要があります。主キー列の型は一度作成すると変更できません。

データパーティションとパーティションキー

格納されたデータの負荷を均衡させるために、Table Store はテーブルを自動的にデータパーティションに分割します。 データは、データパーティションキーと呼ばれる主キーの最初の列でパーティション化されます。
同じデータパーティションキーを持つ行は、同じデータパーティションに属している必要があります。これにより、 Table Store は、同じデータパーティションキーを持つデータに対して一貫した変更を行うことができます。
次の図は、電子メールシステムの電子メールテーブルの一部を示しています。表の主キーおよびパーティション・キーに関する情報は、次のとおりです。

  • UserID、ReceiveTime、および FromAddr の各列には、電子メールユーザーの ID、受信時刻、および送信者がそれぞれ示されます。これらの列は主キー列であり、電子メールを一意に識別することができます。UserID 列はデータパーティションキーです。
  • ToAddr、MailSize、Subject、および Read 列は、受信者、電子メールのサイズ、電子メールの件名、および電子メールが読み取られているかどうかを示します。これらの列は、電子メールに関する情報を格納する共通の列です。

次の図では、Table Store、UserID U0001 と U0002 を持つユーザーに関する情報が同じデータパーティションに格納され、ユーザー ID U0003 と U0004 のユーザーに関する情報が別のデータパーティションに格納されます。

データパーティションとパーティションキー

表、行、列、値における Table Store とワークブックの比較

Table Store テーブルを使用すると、Table Store テーブルのデータをクエリ、挿入、変更、および削除できるため、テーブル内の構造化データを管理できます。Table Store テーブルのデータは、行、列、および値によって構成されます。

表、行、列、値におけるTable Storeとワークブックの比較

上の図は、基本的な Table Store 概念を示しています。

  • :表は、ページの下部に表示されるラベルとして参照されます。異なるラベルは、異なる表に対応しています。
  • :各行には、値と列をマッピングするタプルが含まれています。
  • :同じ列のデータには、同じカテゴリ属性(データ型)があります。
  • :使用可能な値のタイプは、String、Integer、Boolean、Double、または Binary です。Table Store 使用すると、一部の列に値を持たせることができません。列に値がない場合、列はストレージスペースを使用しません。

※列が主キー列の場合、値型は String、Integer、または Binary のみです。

ユーザー認証

Table Store は、対称署名を使用して、リクエストが所有者によって送信され、応答が Table Store によって返されることを確認します。
アカウント登録でアカウント登録後、 Access Key ID と Access Key Secret を取得することができます。 AccessKeyID はユーザーの ID を表し、AccessKeySecret は要求と応答の署名と検証に使用されます。 AccessKeySecret は秘密にする必要があります。
Table Store にリクエストを送信するときは、リクエストにプレーンテキスト、アクセスキー ID、および要求の平文で情報に署名するために AccessKeySecret が使用されたときに生成される認証コードが含まれている必要があります。
要求を受け取った後、Table Store は、AccessKeyID に対応する AccessKeySecret を見つけ、平文の情報に署名する。計算された検証コードが提供された検証コードと同じである場合、要求は有効とみなされます。
Table Store からの応答を確認するには、同じ計算を実行する必要があります。計算された検証コードが提供された検証コードと同じである場合、応答は有効です。

Access Key ID と Access Key Secret の取得方法

  1. コンソール にログオンする。
  2. 最上部のメニューから[ AccessKeys ]を選択します。
  3. セキュリティに関するヒントが表示されたら、 [ AccessKey の管理を続ける ] をクリックします。

Access Key ID と Access Key Secret が表示されます。

AccessKey 権限管理

現在、 Table Store は、 AccessID と AccessKey に基づいた認証のみをサポートしています。認証後、 Table Store 内のリソースには何の制約もなくアクセスできます。
1つのアカウントには、 AccessID と AccessKey のペアが異なる場合がありますが、アカウントに表示されるTable Store のリソースは、アクセスに使用される AccessID と AccessKey に関係なく同じです。
サブアカウントを使用する場合は、 Alibaba Cloud アカウントで Table Store にアクセスするための権限がサブアカウントに付与されていることを確認してください。サブアカウントは、権限が許可されているリソースにのみアクセスできます。

ストレージのデータボリュームにクエリ速度は影響されるか

単一行のクエリと範囲クエリの場合、クエリの速度はデータボリュームとは無関係です。
NoSQL データベースとして、 Table Store は、単一行のクエリと範囲クエリの速度に影響を与えずに、データボリュームをクラスタスケールと共に線形に拡張することができます。データ量が 1 億レベルまたは 10 億レベルに達しても、クエリ速度は変わりません。
高性能インスタンス( SSD で構成される )では、 1 行をクエリする速度はミリ秒レベルです。 1 つの行のデータ量が少ない場合、クエリ速度は一般に 10 ミリ秒以内です。

計測と課金

予約済み読み書きスループット

予約された読取り/書込みスループットは、表の属性です。システムは、テーブルの予約済みの読み取り/書き込みスループット設定に基づいて、バックグラウンドでリソースを予約します。これにより、このテーブルのスループットが確実に確保されます。
CreateTable を使用してテーブルを作成するときは、予約済みの読み取り/書き込みスループットを指定する必要があります。テーブルが作成されたら、UpdateTable を使用して、テーブルの予約済みの読み取り/書き込みスループット設定を更新できます。
テーブルストアでは、各テーブルの予約済み読み取りスループットと書き込みスループットが 0 より大きく 5,000 未満である必要があります。テーブルに予約済みの読み取りスループットまたは書き込みスループットが 5,000 を超えることが必要な場合は、チケットを起票する必要があります。
予約読み出し/書き込みスループットの測定単位は容量単位(CU)です。アプリケーションが API を介してテーブルストアの読み込み/書き込み操作を実行すると、対応する量の読み書き CU が消費されます。
テーブルストアは、インスタンス内のすべてのテーブルに対する予約済みの読み取り/書き込みスループットの合計に基づいて時間料金を請求します。ユーザーの予約済みの読取り/書込みスループット構成は動的に変更できるため、テーブル・ストアは、予約された読取り/書込みスループットに関する統計を設定された時間間隔で生成し、この値に単価を掛けて実際の手数料を得る。予約済みの読取り/書込みスループット単価は、Alibaba Cloud によって更新される場合があります。

データストレージ

Table Store は、インスタンスデータの総量に基づいて、時間当たりの料金を請求します。ユーザーのデータサイズは動的に変更できるため、Table Store は設定された時間間隔でテーブルデータサイズを計算し、時間平均データサイズを計算します。料金は、平均データサイズに単価を掛けて計算されます。単価は Alibaba Cloud によって更新される場合があります。最新の請求詳細については、Alibaba Cloud の公式ウェブサイトを参照してください。
インスタンスの合計データ量は、インスタンス内の各表のデータの合計です。表のデータ量は、表内のすべての行のデータの合計です。次の例では、表のデータ量の計算方法を説明します。
次の表では、ID はプライマリキー列で、その他の列はすべて属性列です。

データストレージ
  • 行 id = 1 の場合、データ量は次のとおりです。len(‘id’)+len(‘name’)+len(‘length’)+len(‘comments’) + 8 バイト + 10 バイト + 8 バイト + 32 バイト = 78 バイト
  • 行 id = 2 の場合、データ量は次のとおりです。len(‘id’)+len(‘name’)+len(‘length’)+len(‘comments’) + 8 バイト + 20 バイト + 8 バイト + 999 バイト = 1,055 バイト
  • 行 id = 3 の場合、データ量は次のとおりです。len(‘id’)+len(‘name’)+len(‘length’)+ 8 バイト +4 3 バイト + 8 バイト = 71 バイト

テーブルのデータ量は 78 Byte + 1055 Byte + 71 Byte = 1204 Byte です。測定された時間内に表のデータ量が変化しない場合、ユーザーに 1,204 バイトの請求が行われます。Table Store は、個々のテーブルのデータ量を制限したり、未使用のサービスを課金したりすることがないため、隠されたコストはありません。

API/SDK

Java SDK エラー:SocketTimeoutException

症状

アプリケーション要求中に SDK が SocketTimeoutException を投げます。

原因

Receive time (SDK がデータを受け取る時刻)と Send time (SDK がデータを送信する時刻)の差が SocketTimeout の値より大きい場合、SDK は SocketTimeoutException を投げます。この期間に、アプリケーションは要求(ネットワーク送信を含む)を送信し、サーバは要求を処理し、アプリケーションは応答(ネットワーク送信を含む)を受信します。OTSClient の作成時に SocketTimeout の値を設定できます。SocketTimeout のデフォルト値は 15 秒です。

解決

問題によっては、SocketTimeoutException が次のように解決されることがあります。

  • ネットワークが切断されています。 ping または curl コマンドを実行してネットワーク接続を確認します。特に、すべての要求に対して SocketTimeoutException が投げられた場合は特にそうです。
    1. ping aaaa.cn-hangzhou.ots.aliyuncs.com
    2. curl aaaa.cn-hangzhou.ots.aliyuncs.com
    • ネットワークが接続され、 curl コマンドが実行されると、次のような結果が返されます。
      1. <?xml version="1.0" encoding="UTF-8"?>
      2. <Error><Code>OTSUnsupportOperation</Code><Message>Unsupported operation: ''.</Message><RequestID>00054ec5-822c-8964-adaf-990a07a4d0c9</RequestID><HostID>MTAuMTUzLjE3NS4xNzM=</HostID></Error>
    • ネットワークが切断されている場合は、非 ECS 環境でイントラネットエンドポイントが使用されているかどうかを確認します。
  • サーバーの処理時間が、SDK が SocketTimeout に指定した時間を超えています。
    通常、テーブルストアサーバーは 15 秒以内に要求を処理します。処理時間がサーバーのタイムアウト時間(通常は 10 秒)を超えた場合、サーバーは OTSTimeout をクライアントに返します。
    SocketTimeoutException は、SocketTimeout に小さい値が設定された場合に投げられます。(2 秒など)。
  • ネットワークの伝送速度が遅い。
    サーバの処理時間に影響を与えなくても、ネットワーク伝送速度が遅いために遅延が発生すると SocketTimeoutException が投げられることがあります。この場合、トラフィック量が多いか、帯域幅が不足しているか、ネットワーク再送率が高いかどうかを確認してください。
  • ガベージコレクション (GC) ( フル GC を含む ) は、Java で頻繁に発生します。
    プログラムのロードが高く、GC が頻繁に発生すると、SocketTimeoutException が投げられることがあります。完全な GC が発生すると、アプリケーションは要求の送信や応答の受信に失敗します。その結果、SocketTimeout の SDK で指定された時間が終了し、SocketTimeoutException が投げられます。
    この場合、GC の原因を分析して解決してください。

Java SDK ログライブラリ

Table Store Java SDK で使用されるログライブラリはどれですか?

Table Store Java SDNK は SLF4J に依存し、 log4j2 はデフォルトのログ実装ライブラリとして使用されます。

ログライブラリをどのように置き換えるのですか?

Java SDK の依存関係から log4j2 を削除してください。削除されると、SLF4J は、アプリケーション内で SLF4J API を実装できる別の依存ログ・ライブラリを自動的に検出します。

  1. <dependency>
  2. <groupId>com.aliyun.openservices</groupId>
  3. <artifactId>ots-public</artifactId>
  4. <version>2.2.4</version>
  5. <exclusions>
  6. <exclusions>
  7. <groupId>org.apache.logging.log4j</groupId>
  8. <artifactId>log4j-api</artifactId>
  9. </exclusion>
  10. <exclusion>
  11. <groupId>org.apache.logging.log4j</groupId>
  12. <artifactId>log4j-core</artifactId>
  13. </exclusion>
  14. <exclusion>
  15. <groupId>org.apache.logging.log4j</groupId>
  16. <artifactId>log4j-slf4j-impl</artifactId>
  17. </exclusion>
  18. </exclusions>
  19. </dependency>

プライマリキーエラー

症状

原因:[ErrorCode]:OTSInvalidPK, [Message]:Validate PK type fail. Input: VT_STRING, Meta: VT_BLOB., [RequestId]:00055f43-3d31-012b-62c3-980a3eefe39e, [TraceId]:02822839-3b5b-af35-409a-cf68841239fa, [HttpStatus:]400

原因

プライマリキーの種類は、テーブルの作成中は binary に設定され、データの書き込み中はプライマリキーの種類は string に設定されます。

解決

データの書き込み中にプライマリキーの種類をテーブルの作成時と同様に設定します。

Java SDK エラー: java.lang.IllegalStateException

Java SDK を使用すると、次の例外が発生します。
java.lang.IllegalStateException: Request cannot be executed; I/O reactor status: STOPPED
原因

shutDownが OTSClient に対して呼び出され、OTSClient のすべての I / O リアクターが無効になります。このエラーは、OTSClient を再度読み書きする場合に返されます。

解決策

OTSClient が shutdown 状態にあるかどうかを確認してください。

Java SDK エラー: Invalid date format

症状

Java 8 環境で、Table Store Java SDK を使用すると、次の例外が投げられます。

[Error Code]:OTSParameterInvalid, [Message]:Invalid date format: Wed, 18 May 2016 08:32:51 +00:00.
原因

Classpath の Joda-Time は SDK に依存しており、Java 8 のバージョン要件を満たしていません。

解決

ots-public 2.2.4 への更新。SDK が Joda-Time に依存している場合は、Joda-Time バージョンを 2.9 に更新します。

Java SDK を使用する場合、Protobuf または HttpClient と競合する

症状

Table Store Java SDK は、Protobuf 2.4.1 と HttpAsyncClient 4.0.2 に依存しています。これは、アプリケーションに固有の同じライブラリと頻繁に競合します。

解決

Table Store SDK が提供する特別なバージョンを使用できます。

  1. <dependency>
  2. <groupId>com.aliyun.openservices</groupId>
  3. <artifactId>ots-public</artifactId>
  4. <version>2.2.5</version>
  5. <classifier>jar-with-dependencies</classifier>
  6. <exclusions>
  7. <exclusion>
  8. <groupId>com.google.protobuf</groupId>
  9. <artifactId>protobuf-java</artifactId>
  10. </exclusion>
  11. </exclusions>
  12. </dependency>

または

  1. <dependency>
  2. <groupId>com.aliyun.openservices</groupId>
  3. <artifactId>tablestore</artifactId>
  4. <version>4.2.3</version>
  5. <classifier>jar-with-dependencies</classifier>
  6. <exclusions>
  7. <exclusion>
  8. <groupId>com.google.protobuf</groupId>
  9. <artifactId>protobuf-java</artifactId>
  10. </exclusion>
  11. </exclusions>
  12. </dependency>

※classifierは、jar-with-dependencies を使用して HttpClient と Protobuf をパッケージ化し、HttpClient および Protobuf の依存関係を削除するようにパッケージの名前を変更するために使用されます。

例外 OTSUnsupportOperation の発生

症状

syncClient.createTable が(ときリクエスト )と呼ばれ、次のエラーが返されます。

Caused by: [ErrorCode]:OTSUnsupportOperation, [Message]:Unsupported operation: 'CreateTable'.
原因

バージョン 4.0.0 以降の SDK を使用して、以前のバージョンのテーブルにアクセスします。

解決

以前の SDK バージョン(推奨バージョン:2.xx)を使用してください。

  1. <dependency>
  2. <groupId>com.aliyun.openservices</groupId>
  3. <artifactId>ots-public</artifactId>
  4. <version>2.2.5</version>
  5. </dependency>

BatchWriteRow 実行時、"Table StoreParameterInvalid" を返す。

症状

BatchWriteRow を使用して一度に 100 データレコードをコミットすると、次のエラーが返されます。

ErrorCode: OTSParameterInvalid, ErrorMessage: The input parameter is invalid.,
原因

バッチ操作では重複した行が検出されます。

解決

他のコードを変更することなく、1 回のデータレコードをコミットします。

Table Store を使用すると、エラー 500 が時々返される

症状

Table Store を使用する場合、報告される一般的な 4xx および 5xx エラーには次のものがあります。

HTTP ステータス エラーコード エラーメッセージ
503 OTSPartitionUnavailable パーティションは使用できません。
503 OTSServerUnavailable サーバーは使用できません。
503 OTSServerBusy サーバーがビジー状態です。
503 OTSタイムアウト 操作のタイムアウト

Table Store は排他的に配布される NoSQL サービスであるため、サーバーはデータ・ボリューム内のデータ量とアクセス条件に基づいて自動的に負荷を分散し、データ・サイズのシームレスなスケーリングを可能にし、通常は単一ホスト・サービス
Table Store は、第 1 の主キーのシーケンスに基づいてデータを異なるデータパーティションに分割し、データパーティションは読み書きサービスのために異なるサービスノードにスケジューリングされます。
データパーティションのデータやアクセス・ボリュームが大きすぎると、 Table Store 最初にこの状態を検出し、二つのデータパーティションにデータパーティションを分割して、下のサービスノードへの 2 つのデータパーティションをスケジュールするための動的負荷分散機能を使用していますより軽い荷重。次の図では、P1 は Table Store によって P1’ と P5 に次のように分割されています。

Table Storeを使用すると、エラー500が時々返される

前述の例に示すように、 Table Store は、テーブルデータサイズの自動スケーリングを可能にし、手動の介入は必要ありません。ただし、データテーブルが作成されると、1 つのデータパーティションしか存在せず、読み書きの並行性が制限されます。その結果、自動ロードバランシングでもレイテンシが存在します。リクエスト機能のチケットを開いて、事前にデータテーブルを複数のデータパーティションに分割することができます。
Table Store は共有ストレージを使用し、データパーティションは論理単位です。ロード・バランシング中、データ・テーブル・メタデータはデータの移行なしに変更されます。メタデータが変更されると、データの一貫性を保つために、関連するデータパーティションが短期間無効になることがあります。 この期間は通常、数百ミリ秒と短く、データ・パーティションの負荷が大きい場合には数秒間続くことがあります。この期間中、データ・パーティションの読み取りまたは書き込みが行われると、500 エラーが報告されることがあります。この問題を解決するためにもう一度試すことができます。公式 SDK は、デフォルトでいくつかの再試行ポリシーを提供します。クライアントの初期化時に再試行ポリシーを指定できます。
Table Store は、標準的な RESTful API を提供します。制御不能なネットワーク環境のため、すべての読み取り/書き込み操作の再試行ポリシーを追加して、ネットワークエラーをある程度まで許容することをお勧めします。

※BatchWriteRow または BatchGetRow を使用して、複数の表または表の複数のデータ・パーティション間でバッチでデータの書き込みまたは読み取りを行うため、データ・パーティションが分割される可能性があるため、書き込みまたは読み取り操作は非アトミックです。操作はアトムから行のみです。200 個のメッセージが返されたとしても、失敗した行の応答で getFailedRows()をチェックする必要があります。

1つのプライマリキーで複数行データを得る方法

GetRange で特殊なサンプルコードのために複数行を検索できます。

ページングクエリを活用する方法

制約

従来のリレーショナルデータベースでサポートされていたページングクエリとは異なり、 NoSQL データモデルと API のページ機能には次の制約があります。

  • 範囲全体の行数を取得できません。つまり、合計ページ数を計算することはできません。
  • オフセット・フィルターをクライアント上で実行し、サーバーがスキャンして読み取ったデータが固定されているため、ページ・ジャンプにオフセットを設定することはお勧めしません。オフセット値が大きすぎると、クエリに時間がかかることがあります。
  • シーケンシャルページングのみがサポートされています。
サンプルコード

以下は、ページングされた読み込み API を実装するためのサンプルコードです。この API には、オフセットフィルタが含まれ、指定された数のページのデータが読み込まれます。

  1. /**
  2. * Query data in the specified range, return data on pages of specified numbers, and skip some rows according to the offset value.
  3. */
  4. privatestaticPair<List<Row>,RowPrimaryKey> readByPage(OTSClient client,String tableName,
  5. RowPrimaryKey startKey,RowPrimaryKey endKey,int offset,int pageSize){
  6. Preconditions.checkArgument(offset >=0,"Offset should not be negative.");
  7. Preconditions.checkArgument(pageSize >0,"Page size should be greater than 0.");
  8. List<Row> rows =newArrayList<Row>(pageSize);
  9. int limit = pageSize;
  10. int skip = offset;
  11. RowPrimaryKey nextStart = startKey;
  12. // If too much data needs to be queried, not all the data is returned through one request. You must perform stream query to obtain the data.
  13. while(limit >0&& nextStart !=null){
  14. // Construct a query parameter of GetRange.
  15. // NOTE: Set the startPrimaryKey to the last point that has been read, so that the steam query continues from the point that has not been read yet in the previous operation.
  16. RangeRowQueryCriteria criteria =newRangeRowQueryCriteria(tableName);
  17. criteria.setInclusiveStartPrimaryKey(nextStart);
  18. criteria.setExclusiveEndPrimaryKey(endKey);
  19. // Correctly set the limit. The number of data rows expected to be read is at most a complete page of data and data that needs to be filtered (offset).
  20. criteria.setLimit(skip + limit);
  21. GetRangeRequest request =newGetRangeRequest();
  22. request.setRangeRowQueryCriteria(criteria);
  23. GetRangeResult response = client.getRange(request);
  24. for(Row row : response.getRows()){
  25. if(skip >0){
  26. skip--;// Data before offset must be filtered out. The policy is reading the data first and then filtering the data on the client.
  27. }else{
  28. rows.add(row);
  29. limit--;
  30. }
  31. }
  32. // Set the start point for the next query.
  33. nextStart = response.getNextStartPrimaryKey();
  34. }
  35. returnnewPair<List<Row>,RowPrimaryKey>(rows, nextStart);
  36. }

以下は、上記の API を使用して、指定された範囲内のすべてのデータをページ単位で読み取る例です。

  1. private static void readByPage(OTSClient client, String tableName) {
  2. int pageSize = 8;
  3. int offset = 33;
  4. RowPrimaryKey startKey = new RowPrimaryKey();
  5. startKey.addPrimaryKeyColumn(COLUMN_GID_NAME, PrimaryKeyValue.INF_MIN);
  6. startKey.addPrimaryKeyColumn(COLUMN_UID_NAME, PrimaryKeyValue.INF_MIN);
  7. RowPrimaryKey endKey = new RowPrimaryKey();
  8. endKey.addPrimaryKeyColumn(COLUMN_GID_NAME, PrimaryKeyValue.INF_MAX);
  9. endKey.addPrimaryKeyColumn(COLUMN_UID_NAME, PrimaryKeyValue.INF_MAX);
  10. // Start reading data of the row with offset = 33 in the range on the first page.
  11. Pair<List<Row>, RowPrimaryKey> result = readByPage(client, tableName, startKey, endKey, offset, pageSize);
  12. for (Row row : result.getKey()) {
  13. System.out.println(row.getColumns());
  14. }
  15. System.out.println("Total rows count: " + result.getKey().size());
  16. // Read data on the following pages in sequence until all the data in the range is read.
  17. startKey = result.getValue();
  18. while (startKey != null) {
  19. System.out.println("============= start read next page ==============");
  20. result = readByPage(client, tableName, startKey, endKey, 0, pageSize);
  21. for (Row row : result.getKey()) {
  22. System.out.println(row.getColumns());
  23. }
  24. startKey = result.getValue();
  25. System.out.println("Total rows count: " + result.getKey().size());
  26. }
  27. }

特定の列に値を追加する方法

列の値を 1 ずつ増やすには、次の手順を実行します。

  1. row = getRow(primary_key, 'col') // Read the column value.
  2. old_value = row['col'] // Record the old value of this column.
  3. row['col'] = old_value + 1 // Calculate the new value.
  4. updateRow(row, condition: row['col'] == old_value) // Write the new value to the column. You must set the condition check to make sure that this column retains the old value when writing the new value; that is, the column is not modified by others simultaneously.

Python SDK ListTable のサンプルコード

ListTable サンプルコード
  1. # -- coding: utf8 --
  2. import time
  3. import logging
  4. import unittest
  5. from ots2 import *
  6. ENDPOINT = "https://xxx.cn-hangzhou.ots.aliyuncs.com";
  7. ACCESSID = "xxx";
  8. ACCESSKEY = "xxx";
  9. INSTANCENAME = "xxx";
  10. ots_client = OTSClient(ENDPOINT, ACCESSID, ACCESSKEY, INSTANCENAME)
  11. list_response = ots_client.list_table()
  12. print u'instance table:'
  13. for table_name in list_response:
  14. print table_name

Python SDK のドキュメントには、インポートプロンプトに関する情報は含まれていません。インポートが追加されていない場合、次のプロンプトが表示されます。

  1. Traceback (most recent call last):
  2. File "listtable.py", line 6, in
  3. ots_client = OTSClient(ENDPOINT, ACCESSID, ACCESSKEY, INSTANCENAME)
  4. NameError: name 'OTSClient' is not defined

この問題を解決するには、次のようにインポートの実行を追加する必要があります。

Python SDK ListTableのサンプルコード