TECH BLOG
技術ブログ

ARTICLE

  • 2020-06-19 Swarm64 DA

    Swarm64 DA 4.1.0ユーザーガイド

Swarm64 DAユーザーガイドの取り扱いについて

このユーザーガイドは開発元のSwarm64 AS社の許諾の元、翻訳版を公開しています。
そのため本文書の書面による許可なしの使用、複製、改変、再配布を固く禁じます。
ユーザガイドの内容に関するお問い合わせは株式会社インサイトにお問い合わせください。

株式会社インサイトお問い合わせフォーム

翻訳元文書:『Swarm64 DA 4.1.0 user guide for AWS R5d
※翻訳元文書の更新・新規作成に伴い随時更新予定

目次

Swarm64 DAの概要
初めてのAWS使用
Swarm64 DAインスタンスの起動
 ・インスタンスの推奨事項
 ・永続的なストレージ
 ・Swarm64 DAインスタンスに接続する
 ・Swarm64 DAの起動と停止
 ・Swarm64 DAのPostgreSQLパラメータ設定
 ・カーネルのアップグレード
Swarm64 DAの評価
Netdataによる監視
高性能レプリケーションクラスター
 ・レプリケーションクラスターのセットアップ
 ・レプリケーションクラスタークエリ
 ・レプリケーションクラスターにおけるデータの整合性
 ・事前定義された制限内でのレプリケーションクラスタのスケーリング
 ・事前定義した制限を超えてレプリケーションスラスタをスケールアップする
データベースへのアクセス
Swarm64 DAのデータベースアーキテクチャコンポーネント
 ・範囲インデックス(range index)
 ・テーブルで範囲インデックスを選択する
 ・主キー、一意キー、および外部キーについて
 ・NativeテーブルとSwarm64 DA外部テーブルの選択
 ・データの高速取り込みのためのチューニング
メモリと並列処理
データ定義(DDL)
 ・範囲インデックスのカラム
 ・テーブルの削除
 ・テーブルの変更
 ・テーブルANALYZEと統計情報の更新
 ・範囲インデックス
 ・ヒント
 ・Swarm64 DA外部テーブルのVACUUM
データクエリ言語(DQL)
 ・テーブルのロック
 ・DELETEおよびUPDATEステートメント
バックアップについて
ワークロード管理
 ・ワークロードマネージャーの検査
JOINノード
Shuffleノード
クエリの書き換え

Swarm64 DAの概要

Swarm64 DAという用語は、Swarm64 Data Acceleratorの短縮形です。

初めてのAWS使用

AWSを初めて使用する場合や、使用後しばらく経過している場合は、次のウォークスルーで、Swarm64 DAでのAWSインスタンスの使用を開始できます。
AWSでのインスタンスの起動に関する決定的な情報については、「AWSの使用開始」を参照してください。

  1. Amazonマーケットプレイスから、Swarm64を検索します。

  2. 右上にある[申請]を選択します。

  3. 右上で、[構成]を選択します。

  4. ドロップダウンメニューの[フルフィルメントオプション]と[ソフトウェアバージョン]で、デフォルトを使用します。

  5. (オプション)ドロップダウンメニューの[リージョン]で、AWSリージョンを変更します。

  6. [続行して起動]を選択します。

  7. ドロップダウンメニューの[アクションの選択]で、[EC2から起動]を選択します。
    注意:そのように起動されたインスタンスにアタッチされたEBS(Amazon Elastic Block Store)のサイズを変更することはできないため、[ウェブサイトから起動]オプションは避けてください。
    デフォルトでは、Swarm64 DAは200GBのEBSスペースで起動しますが、データセットには小さすぎる可能性があります。

  8. 「起動」を選択します。

  9. 最適化されたメモリでフィルタリングし、R5dインスタンスタイプの1つを選択します。
    Swarm64は、r5d.4xlargeからr5d.24xlargeまでのすべてのR5dインスタンスタイプをサポートします。
    どれを選択すればよいかわからない場合は、r5d.16xlargeを選択してください。

  10. 右下で、[インスタンス詳細の構成]を選択します。インスタンスの詳細が表示されます。

  11. デフォルトの構成値を使用して、[ストレージの追加]を選択します。
    ・ストレージの表示に関する詳細。
    -デフォルトでは、一部のボリュームはすでにインスタンスに接続されています。
    -ルートボリュームは、オペレーティングシステムがインストールされている/dev/nvme0n1p1にマウントされます。
    -エフェメラルディスクは、EBSへのアクセスをキャッシュするインスタンスローカルSSDであり、NVMe(不揮発性メモリエクスプレス)デバイスとしてマウントされます
    -ディスクはハードウェアに直接接続されているため、ディスクの場所は変更できません。
    -EBSボリュームタイプは、nvmeディスクとしてもマウントされます。ただし、正確なデバイス名は時々変更されます。

  12. (オプション)デフォルトのEBSスペースの量を変更します。Swarm64 DA起動スクリプトは、EBSのデフォルトの場所によって異なります。そのため、マウントポイントのデフォルトの場所は変更してはいけません。

  13. .右下で、[タグを追加]を選択し、1つまたは複数のタグを追加します。
    たとえば、キーとしてNameを使用し、値としてmy-instance-nameを使用して、インスタンスに名前を付けることができます。

  14. [セキュリティグループの構成]を選択し、新しいセキュリティグループを作成するか、既存のセキュリティグループを選択します。 
    セキュリティグループは、インスタンスを起動するAWS VPC(仮想プライベートクラウド)へのアクセスが許可されるIPアドレスを定義します。

  15. [確認して起動]を選択します。
    AMIディスプレイの詳細。

  16. 必要に応じて最終調整を行い、[起動]を選択します。
    既存の鍵ペアを選択するか、新しい鍵ペアを作成するウィンドウが表示されます。

  17. 秘密鍵と公開鍵のペアを設定します。
    公開鍵はインスタンスに直接コピーされるため、秘密鍵を持つものだけが、SSHを使用してインスタンスにアクセスできます。

  18. 「…を持っていることを認めます」を選択し、「インスタンスの起動」を選択します。
    起動ステータスページが表示されます。

  19. [説明]タブの画面下部で、[パブリックDNS(IPv4)]リンクを見つけてコピーします。

  20. [インスタンスの表示]を選択します

  21. 端末で、次のコマンドを入力します。

    ssh -i your-private-key ubuntu@public-ip

    接続を確立するのに数分かかる場合があります。「接続を続行してもよろしいですか(はい/いいえ)?」と表示されたら、「はい」と入力してEnterを押します。
    Swarm64 DAバナーが表示されます。 Swarm64 DAが現在起動中であるというメッセージが表示された場合は、少し待ちます。起動が完了すると、システム全体の通知が届きます。通知は次のようなものです。


    Swarm64 DA is currently starting up. You will be notified once startup is complete.


  22. (オプション)Swarm64 DAが現在起動しているというメッセージを受け取った場合、起動が完了したというシステム全体の通知を待つか、Swarm64サービスのステータスを監視することができます。
    起動の完了を待つ間にSwarm64 DAサービスのログ出力を表示するには、次のコマンドを実行します。

    journalctl -fu swarm64da 
  23. psqlクライアントを使用してSwarm64 DAサービスに接続します。

    psql -U postgres -h localhost 

    これで、SQLクエリを実行できます。

Swarm64 DAインスタンスの起動

Swarm64 DAは、Ubuntu 16.04に基づくAMIとして提供されます。 Swarm64 DA AMIの各インスタンスが自動的に構成され、使用できるようになります。

インスタンスの推奨事項

Swarm64 DAは、さまざまなタイプのAWSインスタンスで実行できます:r5d.4xlargeuntilr5d.24xlarge
データセットのサイズがTPC-H 1000と同等かそれよりも大きい場合(1TB以上のデータなど)、r5d.16xlarge以上のインスタンスを使用します。
TPC-H 300などのデータセットが小さい場合は、r5d.8xlargeインスタンスのような小さいインスタンスを使用できます。

永続的なストレージ

サポートされるAWSインスタンスには、一時ストレージが含まれます。データを永続化するために、Swarm64 DAインスタンスにはElastic Block Storage(EBS)ボリュームが付属しています。
デフォルトでは、このEBSボリュームの容量は200GBです。
データセットが大きい場合は、インスタンスを起動するときに大きいサイズを指定する必要があります。
注意:
 AWSマーケットプレイスのWebインターフェイスではEBSボリュームのサイズを指定できなため、EC2ポータルを使用してインスタンスを起動する必要があります。
AWSマーケットプレイスでは、EC2ポータルでの立ち上げプロセスを継続することができます。
EBSは低速のストレージであるため、Swarm64 DAインスタンスには、インスタンス上の一時ディスクを使用して高速I/Oを提供するように事前構成されたbcacheが付属しています。
デフォルトのEBSボリュームは/dev/sdbデバイスに接続する必要があります。使用可能な一時ディスクの数は、インスタンスのタイプによって異なります。
Swarm64 DAは、利用可能なすべてのNVMeデバイスを使用し、複数のデバイスがある場合はRAID0アレイを作成します。これにより、単一の論理デバイスをキャッシュに利用できます。
Swarm64 DAインスタンスのデータは、/data/postgresqlにあります。

Swarm64 DAインスタンスに接続する

端末で、次のコマンドを入力します。

 ssh -i your-private-key ubuntu@public-ip

接続を確立するのに数分かかる場合があります。
「接続を続行してもよろしいですか(はい/いいえ)?」と表示されたら、「はい」と入力してEnter押します。
Swarm64 DAバナーが表示されます。 Swarm64 DAが現在起動中であるというメッセージが表示された場合は、さらに数回待ちます
しばらくすると、起動が完了すると、端末にメッセージが表示されます。メッセージは次のようになります。


Swarm64 DA is currently starting up. You will be notified after startup
completes.


関連タスク
データベースへのアクセス

Swarm64 DAの起動と停止

Ubuntuの他のサービスと同じように、Swarm64 DAを制御できます。

  1. サービスのステータスを確認します。

    sudo service swarm64da status
  2. サービスを停止します。

    sudo service swarm64da stop 
  3. サービスを開始します

    sudo service swarm64da start

    注意:
    Swarm64 DAサービスを(再)起動した場合、データベースを再初期化してFPGAを再プログラムするために時間がかかります。初期化が完了すると、システム全体の通知が届きます。

Swarm64 DAのPostgreSQLパラメータ設定

Swarm64 DAには、インスタンスタイプに応じて、データベース用に最適化された構成が付属しています。
設定ファイルはetc/postgresql/11/mainディレクトリにあります。現在のサーバー構成は、postgresql.confファイルにあります。同じディレクトリにあるpg_hba.confファイルでクライアント認証権限を設定できます。ログファイルの名前は/var/log/postgresql/postgresql-11-main.logです。

カーネルのアップグレード

Swarm64 DAデータベースシステムが動作しなくなる可能性があるため、Linuxカーネルのアップグレードは避けてください。

Swarm64 DA評価

Swarm64 DAベンチマークツールキットで提供される一連のベンチマークを使用して、Swarm64 DAを評価できます。ツールキットは、推奨されるスキーマに基づいてデータベースをセットアップし、ベンチマーク用にテスト中のシステムを準備します。
Swarm64は、さまざまなベンチマークをロードして実行する簡単な方法を提供します。ホームディレクトリから、インストーラースクリプトを実行します。

./install_s64da_benchmark_toolkit.sh

インストール手順の完了後に表示される指示に従います。手順を確認するには、インスタンスの/home/ubuntuディレクトリにあるREADME.mdファイルを参照してください。
データが取り込まれた後、VACUUMおよびANALYZEが実行される前に、swarm64da.cluster関数はディスク上のデータを再編成して、範囲インデックスの有用性を高めます。
S64 DAベンチマークツールキットを使用せずにSwarm64 DAを評価するには、swarm64da.clusterを手動で実行します。詳細については、データのクラスタリングを参照してください。

Netdataによる監視

Netdataを使用して、アプリケーションとシステムのパフォーマンスと状態を監視できます。

高性能レプリケーションクラスター

Swarm64 DAを使用したレプリケーションクラスターは、a) Swarm64 DAを実行している複数のデータノードにそれぞれデータの完全なコピーが含まれ、
b) PostgreSQLのレプリケーションミドルウェアであるPgpool-IIを実行している単一のフロントエンドで構成されます。
pgpool-II 4.1.0のドキュメントを参照してください。
Swarm64 DAは、クラスターとしてデプロイされている場合、同時接続数によって読み取りパフォーマンスを拡張できます。
データベースユーザーは、PostgreSQLクライアントまたは任意のPostgreSQL互換コネクタを使用してフロントエンドノードに接続できます。
複数の接続が異なるデータノードに分散されており、各接続のリソースが増えるため、クエリの応答時間が改善されます。

レプリケーションクラスターのセットアップ

次の手順では、クラスターに2つのデータノードがあることを前提としています。

  1. AWS MarketplaceまたはEC2で必要な数のSwarm64 DAのインスタンスを起動して、各データノードを作成します。
    重要:
     各インスタンスのインスタンスタイプとEBSストレージ容量が同じであることを確認してください。
     各Swarm64 DAインスタンスはそれ自体を自動的に構成し、それぞれが使用できるデータベースシステムをセットアップします。

  2. Ubuntu 18.04 HVM(ハードウェア仮想マシン)をフロントエンドとしてr5d.4xlargeインスタンスを起動し、それにsshでログインします。

  3. (オプション)データノードとフロントエンド間のSSHを構成します。 レプリケーションクラスターのSSH構成を参照してください。

  4. (オプション)データノードとフロントエンド間のSSLを構成します。 データノードのSSL構成を参照してください。

  5. フロントエンドでPgpool-IIをインストールして構成します。これにより、すべてのデータノードを単一のデータベースシステムとして統合して表示することで、レプリケーションを管理できます。

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys BA9EF27F
sudo curl https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sudo apt-add-repository "deb http://apt.postgresql.org/pub/repos/apt/ $(lsb_release -c -s)-pgdg main"
sudo apt-get update
sudo apt-get install -y postgresql-client-11 pgpool2

Pgpool-IIには、pgpool.confpcp.confの2つの設定ファイルがあります。ファイル/etc/pgpool2/pgpool.confは、Pgpool-IIの動作を記述しています。
/etc/pgpool2/pcp.confファイルは、Pgpool-II管理ツールであるPCPツールのセキュリティ認証情報を定義します。

b)pgpool.confファイルで以下のオプションを変更します。
listen_addresses = '*' : 任意のIPアドレスから接続を受け入れます。
replication_mode = on :Pgpool-IIレプリケーションモードを有効にする。
failover_if_affected_tuples_mismatch=on : 古いデータを持つデータノードを特定し、データノードごとに返される行数が異なる場合にフェイルオーバーを有効にするのに役立ちます。
load_balance_mode = on : さまざまなデータノードへの接続のロードバランシングを有効にします。使用可能なリソースが多いほど、各クエリは高速になります。
black_function_list = 'currval, lastval, nextval,setval, pg_reload_conf,add_column_to,drop_column_from,change_optimized_columns_to' : クエリにブラックリストの関数が含まれている場合は、負荷分散を無効にします。
allow_sql_comments = on : クエリにコメントが含まれている場合でも、クエリの負荷分散を有効にします。
health_check_period = 60 : ヘルスチェッカーを有効にして、データノードが利用できない場合にPgpool-IIがより迅速に検出できるようにします。
health_check_user = ‘postgres':ヘルスチェッカーが使用するユーザー名を設定します。
ssl = on:(オプション)データでSSLを有効にした場合はノードを有効にします。4を参照してください。
c)pgpool.confファイルを編集して、バックエンドで始まるすべての行を削除します。
これらは、バックエンドを定義するサンプル行です。
d)次の行をpgpool.confファイルに追加します。

  backend_hostname0 = 'NODE0_IP'
  backend_port0 = 5432
  backend_weight0 = 1
  backend_data_directory0 = '/data/postgresql'
  backend_flag0 = 'ALLOW_TO_FAILOVER'
  backend_hostname1 = 'NODE1_IP'
  backend_port1 = 5432
  backend_weight1 = 1
  backend_data_directory1 = '/data/postgresql'
  backend_flag1 = ‘ALLOW_TO_FAILOVER’

ホスト名NODE0_IPおよびNODE1_IPは、起動したデータノードのプライベートIPアドレスです。
e)PCPの認証を構成します。
 「PCPの認証構成」を参照してください。

f)rootとして、Pgpool-IIを再起動して新しい設定を使用します。

sudo service pgpool2 restart

その後、Pgpool-IIはポート5432で接続を受け入れる準備が整います。
g)show pool_nodesコマンドを使用して、使用可能なノードとその状態を確認します。

psql -U postgres -h localhost -c “show pool_nodes”

次の情報が表示されます。
node_id | hostname | port | status
————+————————+———+———
0 | 172.31.46.143 | 5432 | up
1 | 172.31.6.115 | 5432 | down
ノードのステータスがダウンの場合、Pgpool-IIが複製に使用できるように、ノードを手動で接続する必要があります。
h)(オプション)停止しているノードを接続するには、次のコマンドを使用します。

 pcp_attach_node -h 127.0.0.1 -U pgpool -p 9898  -n 1 -w

ノードが接続された後、show pool_nodesコマンドは、両方のデータノードが接続を受け入れることができることを表示します
i)データ型がSERIALであるテーブルとの互換性のために、Pgpool-II補助テーブルを作成します。

psql -U postgres -h localhost -f /usr/share/pgpool2/insert_lock.sql \template1
PCPの認証構成
  1. rootとして、PCPのパスワードのハッシュを生成し、pg_md5を使用してpcp.confファイル内のユーザー名に関連付けます。

    sudo echo "pgpool:$( pg_md5 password )" | 
    sudo tee /etc/pgpool2/pcp.conf
  2. (オプション)資格情報をホームディレクトリの.pcppassファイルに追加して、各PCPコマンドのパスワードを手動で入力しないようにします。

    echo "127.0.0.1:9898:pgpool:password" > "$HOME/.pcppass"
    chmod 600 “$HOME/.pcppas
    データノードのSSL構成

    クラスター内のすべてのデータ転送を暗号化するには、SSLを使用するようにデータノードとフロントエンドの両方を設定します。
    データノードでは、PostgreSQLは独自の秘密鍵と証明書を必要とします。 (認証ではなく)暗号化の目的でのみ、自己署名証明書を必要とします。

  3. server.pemおよびserver.crtという名前のファイルに、サーバーの秘密鍵と証明書をそれぞれ作成します。

    openssl req \
      -nodes \
       -x509 \
       -newkey rsa:1024 \
       -keyout server.pem \
       -out server.crt \
       -subj "/CN=ip-1-2-3-4.us-west-1.compute.internal"

    重要:
    ファイルの名前は、server.pemおよびserver.crtにする必要があります。

  4. 両方のファイルをPostgreSQLデータディレクトリにコピーします。データディレクトリはpostgresユーザーが所有しているため、次のコマンドをrootとして実行します。

    sudo cp server.pem server.crt /data/postgresql
  5. 両方のファイルに正しいアクセス許可があることを確認します。
     秘密鍵ファイルは読み取り可能でなければなりませんが、PostgreSQLのプロセスによって書き込み可能であってはなりません。証明書ファイルには同じアクセス権限を使用できます。
    これを行うには、rootユーザーを所有者として設定し、postgresグループをファイルのグループとして設定し、所有者によるファイルの読み取りと書き込みを許可し、
    グループのみが読み取り、他のユーザーは読み取れないようにします。(8進表記では0640):

    sudo chown root:postgres /data/postgresql/server.pem
    sudo chown root:postgres /data/postgresql/server.crt
    sudo chmod 0640 /data/postgresql/server.pem
    sudo chmod 0640 /data/postgresql/server.crt
  6. PostgreSQL構成ファイルでSSLを有効にします。

    ssl = on
  7. (オプション)PostgreSQLのホストベースの認証構成で非ローカル接続にSSLを適用します。データノードへのすべての接続がSSL暗号化されていることを確認する場合は、SSL暗号化を適用できます。
    つまり、SSLを使用できないクライアントによる接続の試行はすべて拒否されます。そのためには、/data/postgresql/pg_hba.confhost all all all trust行をhostssl all all all trustに変更します。

レプリケーションクラスターのSSH構成

クラスタのあるノードから別のノードへのアクセスを容易にするには、フロントエンドとデータノードにSSHキーを設定する必要があります。

  1. ssh-keygenコマンドを使用して公開鍵と秘密鍵を作成します。これにより、暗号化されていないホスト鍵が作成されます。

    ssh-keygen -t rsa -C "cluster-host-key" -f pk_cluster -N ""

    その後、秘密鍵ファイルの名前がsshコマンドに渡されます。公開鍵は、末尾が.pubである同じファイル名を使用します。

  2. プライベートキーファイルのファイルアクセス権が正しいことを確認するには、プライベートキーファイルをその所有者のみが読み取りおよび書き込みできるようにする(8進表記で600):

    chmod 600 pk_cluster 
  3. 秘密鍵ファイルと公開鍵ファイルをデータノードとフロントエンドの両方にコピーします。

    scp pk_cluster pk_cluster.pub ubuntu@IP_ADDRESS:.ssh 

    .sshディレクトリは、ユーザーのホームディレクトリにすでに存在している必要があります。

  4. データノードとフロントエンドでSSH接続を許可します。

    ssh ubuntu@IP_ADDRESS \
    'cat .ssh/pk_cluster.pub >> .ssh/authorized_keys' 

    SSHでそれぞれの秘密鍵との接続を許可するには、公開鍵をファイル.ssh/authorized_keysに追加する必要があります。

レプリケーションクラスタークエリ

単一ノードのSwarm64 DAまたはPostgreSQLのインストールと同じように、フロントエンドを介してレプリケーションクラスターに接続してクエリを発行できます。
フロントエンドへの各接続には、特定のデータノードが割り当てられます。接続は、データノード間で負荷分散されます。
SELECTクエリは、割り当てられたデータノードでのみ実行されます。データの一貫性を維持するために、INSERT、UPDATE、DELETE、およびCREATEなどの書き込みクエリが複製され、
すべてのデータノードで実行されます。 レプリケーションクラスターのデータの整合性を参照してください。例外の詳細については、Pgpool-IIのドキュメントを参照してください。
書き込みクエリはすべてのノードで実行されるため、クラスター内の取り込み速度は単一ノードのSwarm64 DAを使用する場合よりも遅く、速度はクラスター内のデータノードの数に反比例します。
データノードが使用できなくなり、Pgpool-IIがそれを検出すると、障害のあるデータノードに接続されていた場合、接続はドロップされます。
他のデータノードに接続している場合、接続が一時的に中断される可能性があります。

レプリケーションクラスタにおけるデータの整合性

レプリケーションクラスタの各データノードには、データの完全な最新コピーが含まれている必要があります。このようにして、クエリの出力は、クエリが実行されたデータノードから独立しています。
起動時に、すべてのデータノードが同じデータを持つことを保証する必要があります。起動中にデータノードのEBSボリュームが作成された場合、データベースはすべてのデータノードで空白の状態になります。
以前のSwarm64 DAデプロイメントのデータを再利用する場合は、EBSスナップショットが必要であり、データノードごとに新しいEBSボリュームをインスタンス化して、
すべてのデータノードの状態を同じにする必要があります。
クラスターのサイズがわからない場合は、必要になる可能性のあるデータノードの最大数(または事前定義された制限)を決定します。次に、この数のノードを起動し、データを取り込みます。
取り込みフェーズの後、事前定義された制限内でワークロードのサイズに応じてクラスターをスケーリングできます。
詳細については、事前定義された制限内でのレプリケーションクラスターのスケールアップを参照してください。
INSERT、UPDATE、DELETE、CREATEなどのデータベースを変更するクラスタークエリの使用中にデータの整合性を保つために、すべてのノードに発行されます。
Pgpool-IIはこれらのレプリケーションを透過的に実行します。すべての変更操作がすべてのデータノードに適用されるため、データの状態は同じになります。
データノードの変更が失敗すると、クエリ全体がすべてのノードで中止されます。
フロントエンドをバイパスすることになるため、データノードに直接接続することは避けてください。単一のデータノードでデータが変更された後、ノード間でデータを再同期するメカニズムはありません。
クエリレプリケーション機能は、フロントエンドを介して発行されるクエリでのみ機能します。
いずれかの時点でデータノードが使用できなくなった(Pgpool-IIでダウンステータスになっている)場合は、データノードが使用できなくなった後にデータノードに発行された書き込み操作がないことが確実でない限り、
クラスターに再接続しないでください。クラスター内のデータノードの数を増やすには、事前定義された制限内でのレプリケーションクラスターのスケールアップを参照してください。

事前定義した制限内でのレプリケーションクラスタのスケーリング

「レプリケーションクラスターにおけるデータの整合性」で説明されているように、事前定義した制限内で簡単にレプリケーションクラスターをスケーリングできます。
これを行うには、書き込み操作が実行されていないことを確認する必要があります。一部のノードは使用できません。
(そのようなノードはPgpool-IIによってダウンとして示されています)

レプリケーションクラスターのスケールダウン

現在のワークロードに対してクラスターが大きすぎる場合は、データノードの数を減らします。
AWSを使用して、目的のデータノードを停止または終了します。 
Pgpool-IIに応答しなくなったデータノードには、ダウンステータスのマークが付けられます。 Pgpool-IIは、そのノードへの接続を送信しなくなりますが、show pool_nodesコマンドで引き続き表示されます。

事前定義した制限内でレプリケーションクラスタをスケールアップする

クラスターが予想されるワークロードに対して十分な大きさでなく、事前定義したクラスターサイズに達していない場合は、データノードの数を増やします。

  1. クラスターの既存の(停止した)データノードを起動します。
    利用可能なクラスターに空いているデータノードがある場合は、AWSツールを使用してそれらを起動します。他のデータノードは、
    INSERT、UPDATE、DELETE、CREATEなど、データベースを変更するクエリを実行してはなりません。そうしないと、クラスターは不整合な状態になります。
    データノードがデータベースを変更するクエリを実行した可能性のあるクラスターをスケーリングするには、「定義済みの制限を超えてレプリケーションクラスターをスケールアップする」を参照してください。
    クラスターデータの一貫性の詳細については、「レプリケーションクラスターのデータの一貫性」を参照してください。

  2. 新しいデータノードをPgpool-IIに接続します。
    新しいノードの識別子は、show pool_nodesコマンドで確認できます。識別子を使用して新しいデータノードを添付します。 5.hを参照してください。

事前定義した制限を超えてレプリケーションクラスタをスケーリングする

レプリケーションクラスタは、事前定義された制限を超えてスケーリングできます。これには時間がかかり、スケールアップが行われている間はクラスターを使用できなくなります。

事前定義された制限を超えてレプリケーションクラスタをスケールアップする

クラスターが予想されるワークロードに対して十分な大きさでなく、事前定義されたクラスターサイズに達している場合は、データノードの数を増やします。

  1. クラスターを停止して、データが変更されていないことを確認します。
    a)フロントエンドにログインし、Pgpool-IIを停止します。

    sudo service pgpool2 stop

    b)各データノードにログインし、Swarm64 DAを停止します。

    sudo service swarm64da stop
  2. 新しいデータノードを起動します。
    Swarm64 DAの新しいデータノードが既存のデータとまったく同じ特性を持っていることを確認してくださいインスタンスタイプとEBSボリュームのサイズを含む、クラスター内のノード。

  3. 新しいデータノードとクラスター内の既存のデータノードの1つとの間にSSHキーを設定します。
    レプリケーションクラスターのSSHの構成を参照してください。

  4. データを新しいデータノードにコピーします。
    クラスターの既存のデータノードの1つにログインし、データを新しいデータノードにコピーします。新しいデータノードのプライベートIPが必要になります。

    *sudo rsync -avzrh -progress -e "ssh -i id_rsa" /data/postgresql \
    ubuntu@new-node-ip:/data/postgresql --rsync-path="sudo rsync"*
  5. pgpool.confファイルを編集して、データノードをPgpool-II構成に追加します。
    5.dを参照してください

  6. クラスターを再度起動します。
    a)各データノードにログインし、Swarm64 DAを起動します。

    sudo service swarm64da start

    b)フロントエンドにログインし、Pgpool-IIを起動します。

    sudo service pgpool2 start
  7. 新しいデータノードをPgpool-IIに接続します。
    新しいノードの識別子は、show pool_nodesコマンドで確認できます。識別子を使用して新しいデータノードを添付。 5.hを参照してください。

データベースへのアクセス

  1. AWSインスタンスからデータベースに接続します。
    psql -U postgres -h localhost
  2. (オプション)スーパーユーザー以外のユーザーがデータベースに接続できるようにします。
    GRANT USAGE ON FOREIGN SERVER swarm64da_server TO user; 
    GRANT USAGE ON SCHEMA swarm64da TO user;
  3. PostgreSQLクライアントからSwarm64 DAプラグインをロードします。
    CREATE EXTENSION swarm64da;
  4. 拡張機能が正しく読み込まれていることを確認し、そのバージョン番号を調べます。
    SELECT * FROM swarm64da.get_version();

Swarm64 DAのデータベースアーキテクチャコンポーネント

Swarm64 DAは次のコンポーネントで構成されています。
Swarm64 DAのデータベースアーキテクチャコンポーネント表1:Swarm64 DAのデータベースアーキテクチャコンポーネント
Swarm64 DAは拡張機能としてPostgreSQLにプラグインし、テーブルデータとインデックスのストレージインターフェイスとして外部データラッパー(FDW)を使用します。
Swarm64 DAは、PostgreSQLのネイティブテーブル形式によるデータベースのすべての機能、または外部テーブルとして作成されたSwarm64 DAテーブルによる大規模なサブセットをサポートします。

範囲インデックス(range index)

Swarm64 DAは、範囲インデックスと呼ばれる独自のメカニズムを使用して、より高速な処理のためにメタデータを配置します。
範囲インデックスを使用すると、Swarm64 DAはこれらの列のいずれかで頻繁に使用される値または値の範囲を任意の順序で効率的に処理できます。
これらの範囲の読み取りは、特にクラウド環境やスケーラブルなエンタープライズストレージなど、低レイテンシのローカルストレージが利用できないか望ましくない場合に、I/Oスループット用に最適化されます。
次の図に示すように、範囲インデックスを使用すると、Swarm64 DAはクエリに関連するデータのみにアクセスできます。
as

左側には、マルチパートキー(ws_order_numberおよびws_sold_date_sk)があります。このアクセスで、インデックスの検索と、ストレージから分散したデータブロックの数をフェッチしてクエリ処理を完了します。
各ブロックには多くの行が含まれています。この効果はリード増幅と呼ばれます。これらのブロックがフェッチされると、クエリに関連しない多くの行が、比較的少数の関連行とともに取得されます。
このメカニズムでは、各範囲インデックスの列範囲に沿ってデータが配置されます。範囲インデックスに沿って1つまたは複数の範囲を問い合わせする場合、各範囲の交点のデータのみが取得されるため、
ストレージデバイスからのI/O転送がはるかに少なくなり、読み取り時間が大幅に少なくなります。
次に、ほとんどのデータレイアウトがアクセラレータカードを使用してフィルタリングされ、さらにデータベースで処理されます。
範囲インデックスを最大限に活用するには、データを特定の方法でディスクに保存する必要があります。
これは、特定の順序でデータを取り込む(および更新を回避する)か、Swarm64 DAが提供するクラスター関数を呼び出すことによって確認できます。
範囲インデックスは最小限のストレージ領域を必要としますが、マルチパートキーなどのNativeインデックスの場合はそうではありません。

テーブルで範囲インデックスを選択する

頻繁なデータポイントまたはデータ範囲を問い合わせするのが一般的である場合は、範囲インデックスを使用します。次の特性の範囲インデックスを検討してください。
 •時間または日付の範囲データが格納されているカラム
 •価格帯または特定の価格帯データが格納されているカラム
 • 量(の範囲)を表すデータが格納されているカラム
 •ファクトテーブルの主要なビジネスメトリック
 •追跡またはセンサーデータ
 •x/yまたは経度/緯度などの空間情報データが格納されているカラム
Nativeデータベースのマルチパートキー(複合キーまたはマルチパートインデックスとも呼ばれます)とは異なり、範囲インデックスは任意の順序で、互いに独立して問い合わせできます。
それらが定義される順序は重要ではありません。問い合わせされる範囲インデックスが多いほど、クエリの実行が速くなります。この動作は、ネイティブのマルチパートキーとは異なります。
マルチパートキーは、決められた順序で使用した場合に最高のパフォーマンスを発揮し、それまでに指定したキーパートをスキップすると、パフォーマンスが大幅に低下します。
範囲インデックスは、範囲インデックスの範囲に沿った前述の近似データレイアウトの恩恵を受けます。
テーブルごとに最大3つの範囲インデックスを設定できます。範囲インデックスの設定は必須ではありませんが、テーブルごとに2つまたは3つを使用するのが理想的です。
一般的に主キーと外部キーで使用される「ID」などの列ではなく、範囲で問い合わせされる列には範囲インデックス付き列を使用します。そうすることで、3つの範囲インデックススロットの1つを適切に選択できます。

主キー、一意キー、および外部キーについて

一意性や1対多の関係など、データの固有の特性により、データベースはクエリをより効果的に計画および実行できます。
他の分析データベースソリューションと同様に、Swarm64 DA外部テーブルでは、一意性(または一意である必要がある主キー)や1対1または1対多の関係を示す外部キーなど、
データの固有のプロパティを示すヒントを定義できます。
注意:これらのプロパティは実行時に適用されません。データの起点で暗黙的に強制される固有のプロパティである場合は、正しいヒントを設定することをお勧めします。
例えばNativeテーブルにおいてキー制約などが指定されているデータのトランザクションシステムなど。
これらのヒントの正確性を保証する3番目のシステム(トランザクションデータベースやビジネスロジックなど)がない場合は、これらを選択しないでください。
主キー、一意キー、および外部キーヒントを作成および変更する方法の詳細については、主キー、一意キー、および外部キーヒントを参照してください。

NativeテーブルとSwarm64 DA外部テーブルの選択

Nativeテーブルと外部テーブルは、次のユースケースで自由に組み合わせることができます。
 •銀行取引
 •Webまたはモバイルアプリケーション
 •リアルタイム追跡
 •ほぼリアルタイムの分析
 •データウェアハウジング
 •ストリーミングと時系列
 次の場合は、Swarm64 DA外部テーブルのネイティブテーブルを選択してください。Swarm64 DA外部テーブルで以下の処理を実行した場合、Nativeテーブルと同等かそれよりも遅くなる可能性があります。
(方法としてはレプリケーション機能を使用してSwarm64 DA外部テーブルとNativeテーブルを同期させるなどがある。)
 •数行または数百行の小さなトランザクションでテーブルを操作する。
 •一度に1つの値またはテーブルのごく一部を削除・更新する必要がある。
 •トランザクションスキームとしてREAD COMMITTEDが必要な場合。
 •ワークロードには、インデックス付きの列から単一の値を取得することが含まれることがよくあります。
次の場合は、Swarm64 DA外部テーブルを選択してください。
 •テーブルが非常に大きい、または時間の経過とともに非常に大きくなることが意図されている。
 •範囲(時間範囲など)を問い合わせしている。
 •データウェアハウスのファクトテーブルなど。
 •データが高速で移動している場合(データベースへのストリーミングなど)。
 •イベントを記録するとき。
 •大規模でほとんど静的なテーブルの場合。

データの高速取り込みのためのチューニング

Swarm64 DAは、ほぼリアルタイムのストリーミングユースケースで、1秒あたり最大2,000万行を実証しました。
これらの取り込み速度を実現するために、PostgreSQLおよびデータアクセラレータと対話するツールのベストプラクティスが必要です。
•データベースにデータを迅速かつ一貫して提供します。
 マルチスレッドメカニズムを使用して、データベースにデータを提供します。
 データベース接続との対話中の待ち時間を隠し、処理のオーバーヘッドを低く保つことができるます。
 Goなどの協調型マルチスレッドに基づくソリューションが最も効果的であることがわかりました。具体的なツールの推奨事項とサンプルコードについては、Swarm64にお問い合わせください。
•テーブルごとに複数のデータベース接続を同時に使用します。
 データを提供するマルチスレッドメカニズムに加えて、テーブルごとに複数の並列接続を介してデータベースにデータを提供する必要があります。
•COPY FROMを使用して解析のオーバーヘッドを制限し、単一ステートメントのINSERTトランザクションを回避します。
 データベースにテキスト文字列として提供される個々のSQL INSERTステートメントにデータが挿入された場合、これらのステートメントの解析とトランザクションコンテキストの作成にはかなりのリソースが必要です。
代わりに、COPY FROMコマンドを使用してください。 10万行のバッチを個別のCSVファイルとして提供します。これらのCSVファイルは、たとえば、リアルタイムで作成でき、メモリ内のファイルシステムに一時的に常駐できます。
•複数のテーブルを同時に使用します。
 Swarm64 DAはマルチテーブルインサートで適切にスケーリングできるため、複数のテーブルに並行して取り込むと、パフォーマンスがさらに向上します。

メモリと並列処理(パフォーマンス)

並列処理(つまり、タスクでの作業が許可されているワーカーの数)とそれぞれに割り当てられたwork_memの量との間でトレードオフの調整を行う必要があります。
work_memは、並列ワーカーごととクエリ実行ノードごとに割り当てられ、max_worker_processes制限に達するまで、すべての接続でワーカープロセスを生成できます。
経験的に、同時に実行されるヘビーウェイトクエリの数が少ない場合(たとえば、一度に2〜5個)、クエリノードごとのwork_memが4〜8個の並列ワーカーで十分機能するため、合計メモリの約1/16で実行可能です。
大規模なデータセットでの分析ワークロードが重い場合は、max_parallel_workers_per_gatherを16に増やすことが望ましい場合があります。
この場合、使用可能なRAMの1/32以下をwork_memとして使用し、max_worker_processesを32未満に制限する必要があります。
さらに、クエリの実行中に実際にデプロイされた並列ワーカーの数をオーバーライドし、代わりにswarm64da.maximize_parallel_workers_per_query = trueを設定することにより、
常に収集ごとの最大ワーカー数を有効にします。
これにより、一度に1つのクエリを実行するときにリソースの使用量を最大化できます。effective_cache_sizeの値は、キャッシュできるデータの量を反映する必要があります。
これは、PostgreSQLクエリの計画中に利用可能なOSディスクキャッシュの量の見積もりとして機能します。
Swarm64 DAテーブルの場合、effective_cache_sizeの値を大きくすると、ディスクから読み取られるデータの再利用も増加します。

データ定義(DDL)

注意:
二重引用符の使用を制限します。
PostgreSQLの使用方法に関する標準的な慣行に従って、Swarm64は二重引用符(“)を避けることを強くお勧めします。これはスペースまたは特定の大文字で表または列の名前を作成するためです。
通常、二重引用符を使用するとユーザークエリまたは特定のAPIとの幅広い互換性の問題が生じます。詳細については、ブログの投稿「Don’t use double quotes in PostgreSQL(二重引用符を使用しないでください)」を参照してください。
二重引用符、大文字と小文字が区別されるテーブル名などに関連する警告が詳しく説明されています。二重引用符はサポートされていますが、使用しないことを強く推奨します。

テーブル範囲のインデックス付き列の作成

範囲インデックスのカラム

テーブルが作成された後は、範囲のインデックス付きの列を変更できなくなります。最大4つの範囲のインデックス付き列を推奨します。次のリストは、インデックス付けできる列タイプを示しています。
特に、可変長の列タイプおよび8バイトを超える固定長の列タイプは、現時点ではインデックス付けできません。範囲インデックス付きの列はnullが入る場合でも問題ありません。

ストレージと統計

Column type & Notes
BOOLEAN ※サポートされているが選択性が低いため推奨しない
SMALLINT, INT / INTEGER, BIGINT, SMALLSERIAL, SERIAL, BIGSERIAL
DATE
TIME
TIMESTAMP / TIMESTAMPZ
ENUM  ※等価比較のみがサポートされている
NUMERIC or DCHAECIMAL ※最大13桁にすることができる。
CHAR, VARCHAR, TEXT ※平等と不平等の評価のみを加速します。ステータスコード、テキストベースの識別子、およびテキストベースの列挙に最適です。

カスタムタイプは、固定長が8バイト以下であり、標準の整数比較演算を使用して比較できる限り、インデックス付き列としてサポートされます。
2つの範囲のインデックス付き列を持つテーブルの作成は、次のように行われます。

CREATE FOREIGN TABLE my_table (
    col0 INT,
    col1 TIMESTAMP NOT NULL,
    col2 VARCHAR(30))
SERVER swarm64da_server
OPTIONS (range_index 'col0, col1’);

SQLキーワードを列名として使用する場合は、二重引用符を使用してください。

CREATE FOREIGN TABLE my_table (
    year DATE,
    name INT NOT NULL,
    col2 VARCHAR(30))
SERVER swarm64da_server
OPTIONS (range_index '"year", “name”');

SQLキーワードの詳細については、SQL Key WordsSQLキーワードを参照してください。

分割テーブルの作成

パフォーマンスのために、特に並列クエリ実行では、テーブルを分割することを推奨します。Nativeテーブル(以下の例ではmy_table)は、複数のSwarm64 DAパーティションに割り当てられています。

CREATE TABLE my_table (
    col0 INT,
    col1 TIMESTAMP NOT NULL,
    col2 VARCHAR(30))
PARTITION BY HASH (col0);
CREATE FOREIGN TABLE my_partition_0
PARTITION OF my_table
FOR VALUES WITH (MODULUS 2, REMAINDER 0)
SERVER swarm64da_server options(
    range_index 'col1');
CREATE FOREIGN TABLE my_partition_1
PARTITION OF my_table
FOR VALUES WITH (MODULUS 2, REMAINDER 1)
SERVER swarm64da_server
OPTIONS(range_index ‘col1');

注意:
JOIN、集計、GROUP BYなどに頻繁に使用されるディメンションに沿ってパーティション分割することを推奨します。
これらは、JOINに使用する両方のテーブルが同じパーティション構成に従ってそれぞれのJOINキーによってパーティション分割されている場合に最も効率的に実行されます。
パーティションを選択した場合、パーティションキーとして使用される列にインデックス付きの列を追加で割り当てることは推奨しません。
上記の例のcol0はパーティションキーとして使用されるため、範囲インデックスから除外されます。
詳細については、「テーブルのパーティション分割」を参照してください。

テーブル範囲のインデックス付きの列とヒントを同時に作成する

表示されたすべてのテーブルオプションは、テーブルの作成時に同時に指定できます。次のリストは、複雑なテーブルを作成する例を示しています。

CREATE FOREIGN TABLE orders (
    o_orderkey bigint NOT NULL, o_custkey int NOT NULL,
    o_orderstatus character(1) NOT NULL,
    o_totalprice numeric(13,2) NOT NULL,
    o_orderdate date NOT NULL,
    o_orderpriority character(15) NOT NULL,
    o_clerk character(15) NOT NULL,
    o_shippriority int NOT NULL,
    o_comment character varying(79) NOT NULL
)
SERVER swarm64da_server
OPTIONS(
    range_index 'o_orderdate',
    primary_key_hint 'PRIMARY KEY (o_orderkey)',
    foreign_keys_hint 'FOREIGN KEY (o_custkey)
    REFERENCES customer(c_custkey)',
    unique_keys_hint ‘UNIQUE(o_custkey)');
データのクラスタリング

範囲インデックスを最大限に活用し、I/O転送を最小限に抑えるために、Swarm64 DAには、PostgreSQL CLUSTERコマンドと同様に、ディスク上のデータを物理的に再配置する機能が用意されています。
Swarm64 DA外部テーブルweb_salesを2つの範囲インデックスでクラスター化するには、クラスター関数

SELECT swarm64da.cluster( 'web_sales'、‘ws_order_number、ws_sold_date_sk');

を実行します。最初のパラメーターはクラスター化するテーブルを指定します。 2番目のパラメーターはそのテーブルに属する列のコンマ区切りのリストです。これらのすべての列には範囲インデックスが存在する必要があります。
次のPostgreSQLの列タイプはクラスタリングをサポートしています:
SMALLINT、INTEGER、BIGINT、MONEY、TIME、DATE、BOOLEAN、NUMERIC、SERIAL、BIGSERIAL、SMALLSERIAL、 TIMESTAMP、TIMESTAMPTZ
さらに、最大サイズ8バイトのINTEGERに変換可能なカスタムタイプがサポートされています。文字型の列は範囲インデックスを持つことができますが、それらをクラスター化することはできません。
テーブルの範囲インデックスのサブセット(最小:1)でのみクラスター化することが可能です。クラスター機能の実行中にテーブルを問い合わせできます。ただし、同時更新と削除はできません。
オプションのタイムアウト(秒単位)を3番目のパラメーターとして指定できます。これは主に、重いクエリのワークロードが制約された後にデータベースサーバーの全リソースを利用できることを保証するためのものです。
デフォルトのタイムアウトは9000秒です。

SELECT swarm64da.cluster('web_sales'、 'ws_order_number'、3600);

タイムアウトのために関数が早く停止した場合、テーブルの一部がクラスター化されないままになることに注意してください。これにより、I/Oの削減によるパフォーマンスの潜在的なメリットが制限されます。

swarm64da.cluster_max_budget(integer)

この構成パラメーターは、クラスター機能が使用できるメモリ量(メガバイト単位)を制御します。通常、値が大きいほど、テーブル全体でクラスタリングの結果が細かくなりますが、同時クエリで使用できるメモリの量は減少します。
デフォルトの予算は100メガバイトです。実行中、クラスター関数は元のテーブルの約2倍のディスク容量を消費する可能性があります。
後でそのスペースを再利用できるようにするには、テーブルをクラスタ−化した後、VACUUM web_salesのようにVACUUMを呼び出します。
クラスター関数は、特に大きなテーブルの場合、実行に時間がかかります。取り込み中にテーブルがすでに範囲インデックスで並べ替えられている場合、クラスター関数を実行してもメリットがない場合があります。
クラスタリングが完了する前にユーザーによってクラスタリングが中断されると、テーブル全体が元のクラスター化されていない状態になります。

テーブルの削除

 DROP FOREIGN TABLE my_table;

テーブルの変更

列の追加と削除

列の追加と削除は、次に概説するそれぞれのSQL関数を使用することで簡単に実現できます。
注意:
次の関数の実行中、データの安全性を確保し、SQL関数内でロールバックできるように、それぞれのテーブルの完全なコピーが作成されます。その結果、次のSQL関数に注意してください。
•少なくともテーブルが現在使用しているのと同じ容量のストレージが必要です。
•関数自体がすでにトランザクションを使用してトランザクションを実行しているため、トランザクションの外部でのみ実行する必要があります。常にデータの安全性を確認してください。
注意:
これらの関数では、テーブル名や列名などの識別子は大文字と小文字が区別されます。たとえば、列の名前がcol1で、列Col1を削除する関数が実行されると、関数は異常終了し、エラーメッセージが表示されます。

列を追加する

列を追加します。

  SELECT swarm64da.add_column_to(
    'table name’,
 'column name',
 'column type [NOT NULL DEFAULT value]’);

例:

 SELECT swarm64da.add_column_to(
    'orders',
    'o_firstname',
    'CHAR(20) NOT NULL DEFAULT '' '' ');
 -- verbose version with named arguments:
 SELECT swarm64da.add_column_to(
    table_name := 'orders',
    column_name := 'firstname',
    column_type := 'CHAR(20) NOT NULL DEFAULT '' '' ‘);

文字列内の単一引用符( ’)文字をエスケープするためのルールを守ってください。
標準のPostgreSQLエスケープルールに従って、単一引用符で区切られた文字列内で使用される単一引用符は、2つの単一引用符で置き換える必要があります。
例:
CHAR(20)NOT NULL DEFAULT ''は 'CHAR(20)NOT NULL DEFAULT' '' ''になります
注意:
テーブルが別のテーブルの列タイプとして使用されている場合、または継承階層の親テーブルである場合、テーブルに列を追加することはできません。

列を削除する

列を削除します。

SELECT swarm64da.drop_column_from(
    'table name',
    'column name’);

例:

 SELECT swarm64da.drop_column_from(
    'lineitem',
    'l_comment');
 -- verbose version with named arguments:
 SELECT swarm64da.drop_column_from(
    table_name := 'lineitem',
    column_name := 'l_comment');

削除された列は、範囲インデックス付き列のリストや一意の外部キーヒントなど、テーブルオプションからも削除されます。これらのリストのいずれかが空になると、オプションは完全に削除されます。
列名がテーブルオプションのいずれかの部分文字列と一致する場合、列の削除は機能しません。
テーブルから列を削除する前に、列に応じて、ビューなどのオブジェクトがないことを確認してください。
注意:
テーブルが別のテーブルの列タイプとして使用されている場合、またはそれが継承階層の親テーブルである場合、テーブルから列を削除できません。

テーブルのANALYZEと統計の更新

クエリオプティマイザーは、最新の統計に基づいて、可能な限り最良のクエリプランを見つけます。テーブル統計はANALYZE my_tableで更新できます。ANALYZEを実行するだけです。
すべてのNAtiveテーブルの統計を更新しますが、Swarm64 DA外部テーブルの統計は更新しません。外部テーブルの統計を更新するには、ANALYZEコマンドでテーブルを明示的にリストする必要があります。

範囲インデックス

テーブルの範囲インデックスは、次のSQL関数で変更できます。この関数の実行中、データの安全性を確保し、SQL関数内でロールバックできるように、それぞれのテーブルの完全なコピーが作成されます。
その結果、このSQL関数は次のことに注意が必要です。
•少なくともテーブルが現在使用しているのと同じ容量のストレージが必要です。
•関数自体がすでにトランザクションを使用してデータを確認しているため、常に安全にトランザクションの外部で実行する必要があります。
注意:
この関数では、テーブル名や列名などの識別子は大文字と小文字が区別されます。たとえば、列の名前がcol1で、関数を実行して列Col1を範囲インデックスとして設定すると、関数は異常終了し、エラーメッセージが表示されます。

 SELECT swarm64da.change_range_index_to(
    'table_name',
    ‘range_index');

例:

 SELECT swarm64da.change_range_index_to(
    'lineitem',
    'l_partkey');
 -- verbose version with named arguments
 SELECT swarm64da.change_range_index_to(
    table_name := 'lineitem',
    range_index := ‘l_partkey');

Swarm64 DAは、次のインデックス付き列タイプをサポートしています(Swarm64のOLAP最適化INDEX):
•Swarm64 DAは、OLAP用に設計された独自の範囲インデックスを使用します。
•INT、BIGINT、DATE、TIMESTAMP、TIMESTAMPTZ、BOOLEAN
•SMALLINT、SERIAL、TIME、BIGSERIAL、SMALLSERIAL、ENUM、整数互換のカスタムタイプ
•CHAR、VARCHAR、TEXT。 >、<、およびLIKEには追加の加速がないことに注意してください。
•NUMERICまたはDECIMALは最大13桁です。

ヒント

定義されていない場合は、ヒントを追加できます。

ALTER FOREIGN TABLE table OPTIONS(
    ADD unique_keys_hint 'UNIQUE(c1)');
ALTER FOREIGN TABLE table OPTIONS(
    ADD primary_key_hint 'PRIMARY KEY(c1)');
ALTER FOREIGN TABLE table OPTIONS(
    ADD foreign_keys_hint '
    FOREIGN KEY (base1_id)
    REFERENCES base1(id)’);

ヒントがすでに定義されている場合、ヒントを設定およびリセットできます。 SETを使用する場合は、すべてのヒント部分をリストする必要があります。省略されたヒントは削除され、コマンドの実行後には表示されなくなります。

 ALTER FOREIGN TABLE table OPTIONS(
    SET unique_keys_hint 'UNIQUE(c1)');
 ALTER FOREIGN TABLE table OPTIONS(
  SET primary_key_hint 'PRIMARY KEY(c1)');
 ALTER FOREIGN TABLE table OPTIONS(
    SET foreign_keys_hint '
    FOREIGN KEY (base1_id)
    REFERENCES base1(id)’);

ヒントが以前に定義されていた場合、それを削除できます。

ALTER FOREIGN TABLE table OPTIONS(DROP unique_keys_hint);
ALTER FOREIGN TABLE table OPTIONS(DROP primary_key_hint);
ALTER FOREIGN TABLE table OPTIONS(DROP foreign_keys_hint);

PostgreSQLで外部テーブルを使用する方法の詳細についてはPostgreSQLのドキュメントを参照してください。

CREATE FOREIGN TABLE に関しては https://www.postgresql.jp/document/12/html/sql-createforeigntable.html
を参照。
ALTER FOREIGN TABLEに関してはhttps://www.postgresql.jp/document/12/html/sql-alterforeigntable.html
を参照。
DROP FOREIGN TABLEに関しては
https://www.postgresql.jp/document/12/html/sql-dropforeigntable.htmlForeign Dataを参照。

主キー、一意キー、および外部キーのヒント

主キー、一意キー、および外部キーヒントは、ネイティブPostgreSQLテーブルと同じ目的を持っていますが、それらはヒントであり、強制されないという違いがあります。
主キーのヒントには、一意性も含まれます。重複を含む列に一意または主キーのヒントを誤って追加すると、誤ったクエリ結果が発生する可能性があることに注意してください。
次の例を参照してください。

 CREATE FOREIGN TABLE t0(
     col0 INT NOT NULL,
     col1 TEXT)
 SERVER swarm64da_server;
 CREATE FOREIGN TABLE t1(
     col0 INT NOT NULL,
     col1 TEXT)
 SERVER swarm64da_server;
 ALTER FOREIGN TABLE t1
 OPTIONS(ADD unique_keys_hint 'UNIQUE(col0)');
 SELECT * FROM t0
 INNER JOIN t1 ON t0.col0 = t1.col0;

テーブルt1には重複があります。 t1をt0と結合すると、一意のキーヒントがt1.col0に追加されるとすぐに誤った結果が生成されます。

user=# SELECT * FROM t0
INNER JOIN t1 ON t0.col0 = t1.col0;
 col0 | col1 | col0 | col1
------+------+------+------
0| A | 0| a 
1| B | 1| b 
1| B | 1| c
1| B | 1| d 
4| E | 4| e
(5 rows) 
user=# ALTER FOREIGN TABLE t1
OPTIONS(ADD unique_keys_hint 'UNIQUE(col0)');
ALTER FOREIGN TABLE
user=# SELECT * FROM t0
INNER JOIN t1 ON t0.col0 = t1.col0;
col0 | col1 | col0 | col1 
------+------+------+------ 
0|A | 0|a
 1|B | 1|b
4|E | 4|e 
(3 rows)

CREATE TABLE my_table LIKE my_foreign_table INCLUDING INDEXESはありません。外部テーブルからのヒントを一意性制約、またはネイティブテーブルの主キーまたは外部キーに変換します。
テーブルの継承と組み合わせて使用すると、主キー、一意キー、または外部キーは継承されません。これはPostgreSQLのNativeテーブルとSwarm64 DA外部テーブルの両方から継承する場合も同様です。
これらは手動で追加されています。複合インデックスの一部としてサポートされる列数に関するPostgreSQLの制限が適用されます。(INDEX_MAX_KEYS、デフォルトでは32)
構文は、PostgreSQLの主な一意の外部キー制約の構文と一致します。 Swarm64 DA構文は、
MATCH FULL、MATCH PARTIAL、MATCH SIMPLE、ON DELETE、ON UPDATE、DEFERRABLE、NOT DEFERRABLE、INITIALLY DEFERRED、INITIALLY IMMEDIATE
をサポートしていません。

主キーヒントの作成

テーブルごとに定義できる主キーヒントは1つだけです。単一または複数の列が含まれる場合があります。

 CREATE FOREIGN TABLE t00(
    c0 INT,
    c1 INT)
SERVER swarm64da_server
OPTIONS(
    primary_key_hint 'PRIMARY KEY(c1)');
CREATE FOREIGN TABLE t02(
    c0 INT,
    c1 INT,
    c2 INT)
SERVER swarm64da_server
OPTIONS(
    primary_key_hint 'PRIMARY KEY(c1, c2)’);
一意キーのヒントを作成する

テーブルごとに、任意の数の一意のキーヒントを定義できます。

CREATE FOREIGN TABLE t00(
    c0 INT,
    c1 INT)
SERVER swarm64da_server
OPTIONS(
    unique_keys_hint 'UNIQUE(c1)');
CREATE FOREIGN TABLE t01(
    c0 INT,
c1 INT,
    c2 INT)
SERVER swarm64da_server
OPTIONS(
    unique_keys_hint 'UNIQUE(c1), UNIQUE(c2)');
CREATE FOREIGN TABLE t02(
    c0 INT,
c1 INT,
    c2 INT)
SERVER swarm64da_server
OPTIONS(
    unique_keys_hint 'UNIQUE(c1, c2)');
CREATE FOREIGN TABLE t03(
   c0 INT,
 c1 INT,
   c2 INT,
   c3 INT)
SERVER swarm64da_server
OPTIONS(
    unique_keys_hint 'UNIQUE(c1), UNIQUE(c2, c3)’);

結合の依存関係に関する知識は、クエリプランニングにとって重要です。これは、ベーステーブルの各行について、結合されたテーブルに少なくとも1つの行があることをクエリプランナーに通知するためです。
この情報により、プランナーは結合によって生成される行数のより正確な見積もりを作成できるため、処理中のデータにより適したクエリプランを見つけるのに役立ちます。

外部キーヒントの作成

外部キーヒントは、テーブル間で強制されない外部キー関係であり、クエリの計画中に評価され、Swarm64 DA外部テーブルをベーステーブルとして使用する結合のパフォーマンスが向上します。
参照されるのは、PostgreSQLのNativeテーブルまたはSwarm64 DA外部テーブルのいずれかのテーブルです。列リストでは、コンマを区切り文字として使用して、任意の数の列を指定できます。
DROP(FOREIGN)TABLEコマンドでCASCADEキーワードが指定されていない場合、外部キーヒントにより、参照されているNativeのPostgreSQLまたはSwarm64 DA外部テーブルを削除できません。

CREATE FOREIGN TABLE base1(
    id INT,
    payload INT)
SERVER swarm64da_server;
CREATE FOREIGN TABLE base2(
    id INT,
    payload INT)
SERVER swarm64da_server;
CREATE FOREIGN TABLE test_table(
    base1_id INT,
    base2_id INT,
    payload INT)
SERVER swarm64da_server
OPTIONS(
    foreign_keys_hint '
FOREIGN KEY (base1_id)
REFERENCES base1(id),
FOREIGN KEY (base2_id)
REFERENCES base2(id)’);

制限事項
次の制限が適用されます。
•PostgreSQLの外部キー制約仕様とは異なり、列リストは省略できず、Swarm64 DAによって推察されません。
•外部キーヒントで参照される列は、参照する列と同じデータ型である必要があります。
•強制されない関係の性質上、CASCADEやRESTRICTなどのキーワードはサポートされていません。

ヒントの検査

PostgreSQLクライアントでテーブルを記述することにより、主キーおよび外部キーのヒントを検査できます。

user=# \d t00
                     Foreign table "public.t00"
Column |  Type   | Collation | Nullable | Default | FDW options
-------+---------+-----------+----------+---------+-------------
c0     | integer |           |          |         |
c1     | integer |           |          |         |
Server: swarm64da_server
FDW options: (
    range_index 'c0',
    unique_keys_hint 'UNIQUE (c1)’)
user=# \d t01
                     Foreign table "public.t01"
Column |  Type   | Collation | Nullable | Default | FDW options
-------+---------+-----------+----------+---------+-------------
c0     | integer |           |          |         |
c1     | integer |           |          |         |
Server: swarm64da_server
FDW options: (
    range_index 'c0',
    primary_key_hint 'PRIMARY KEY (C1)’)

Swarm64 DA外部テーブルのVACUUM

デフォルトでは、クエリがデータを挿入または更新するたびに、ディスク使用量が増加します。削除の場合にも発生する可能性があります。
ただし、一部の行を削除するトランザクションが完了すると、それらの行に使用されているディスク領域は使用できなくなります。
NativeのPostgreSQLテーブルなどの場合、Swarm64 DA外部テーブルをバキュームすることが可能です。
その操作の後、新しいディスク割り当てはディスク使用量を増やす前に、まず空のスペースを再利用しようとします。
このコマンドはNativeテーブルとまったく同じように機能します。ただし、パーティション分割されたテーブルをバキュームしても、Swarm64 DAパーティションはバキュームされないことに注意してください。
それぞれのコマンドを呼び出す必要があります。
Swarm64 DA外部テーブルのバキュームは、自動バキュームデーモンと互換性があります。
VACUUM FULLはサポートされていません。

データクエリ言語(DQL)

Swarm64は、NativeテーブルのPostgreSQL機能の完全なセットと、Swarm64 DA外部テーブルの大きなサブセットをサポートします。可能なSQLクエリの完全なリストについては、SQL言語を参照してください。
注意:
一般に、データを問い合わせるアプリケーションでは、SQLクエリ文字列を変更する必要はありません。
ただし、留意すべきいくつかの制限があります。このような制限が問題の問い合わせに影響している場合は、データベースのNativeテーブル形式を使用してください。
Swarm64 DAは異なるテーブルフォーマット間で自由に結合できるため、これが推奨されるソリューションです。
Swarm64 DA外部テーブルは、(ほぼリアルタイムの)データウェアハウジング、時系列データ、データボールト、ストリーミング、データログ、またはETL(Extract-Transform-Load)出力結果を対象としています。
個々のレコードを頻繁に更新する必要がある場合は、トランザクションワークロード(OLTP)である可能性が高いため、この特定のケースではNativeテーブルを使用することをお勧めします。
ハイブリッドトランザクション分析処理の場合、トランザクションのNativeテーブルを分析用のSwarm64 DA外部テーブルと組み合わせることが推奨されます。

テーブルのロック

Swarm64 DA外部テーブルは、Nativeテーブルと同じ構文で、明示的に呼び出されたときにこの機能をサポートします。それ以外の場合、外部テーブルではロックはサポートされません。
NativeのPostgreSQL親テーブルをロックしても、そのロックはSwarm64 DA子テーブルに伝播されないため、これはテーブル継承のコンテキストで特に重要です。
行レベルのロックはサポートされていません。

DELETEおよびUPDATEステートメント

Swarm64 DA外部テーブルのPostgreSQL DELETEおよびUPDATEステートメントは、いくつかの制限付きでサポートされています。
•テーブルのDELETEおよびUPDATEステートメントは順次実行されるため、同じテーブルで同時に実行されるDELETEまたはUPDATEステートメントは、
以前にトリガーされたDELETEまたはUPDATEステートメントが完了するまで待機します。
•同じテーブルのクエリごとのDELETEまたはUPDATEステートメントの数は1つに制限されます。同じテーブルに対する2つのDELETEステートメントの例:

 WITH CTE AS (DELETE FROM table1 t1
     WHERE a < 50 RETURNING t1.a)
 DELETE FROM table1 d
 USING CTE
     WHERE d.a < 60;

•パーティション間の行の再配置を意味するUPDATEステートメントはサポートされておらず、エラーが発生します。

バックアップについて

PostgreSQLユーティリティpg_dumpを使用して、データベースのバックアップを作成できます。 Swarm64 DAには、外部テーブルの内容をダンプできるように変更されたバージョンのpg_dumpが付属しています。
次のオプションを使用して外部データをダンプします。

 pg_dump --include-foreign-data=foreignserver

foreignserverパターンに一致する外部サーバーを使用して、外部テーブルのデータをダンプします。複数の--include-foreign-dataオプションを記述することで、複数の外部サーバーを選択できます。
また、foreignserverパラメーターは、PSQLの\dコマンドで使用されるのと同じルールに従ってパターンとして解釈されるため、
パターンにワイルドカード文字を書き込むことで、複数の外部サーバーを選択することもできます。
重要:
変更されたpg_restoreは現在、クロステーブル制約を考慮していません。したがって、たとえばFOREIGN KEY制約に依存している場合は、データベーススキーマを個別に復元する必要があります。
注意:
ワイルドカードを使用する場合、シェルがワイルドカードを展開しないように、必要に応じてパターンを引用符で囲むように注意してください。唯一の例外は、空のパターンが許可されないことです。
Swarm64 DAで定義されているデフォルトの外部サーバーはswarm64da_serverであるため、Swarm64 DA外部テーブルのデータを含むデータベースをダンプする場合は、次のコマンドを使用します。

 pg_dump —include-foreign-data=swarm64da_server

--include-foreign-dataを指定すると、pg_dumpは外部テーブルも書き込み可能かどうかをチェックしません。
したがって、Swarm64 DA以外の外部サーバーのデータをダンプする場合、外部テーブルダンプの結果をクリーンなデータベースに正常に復元できる保証はありません。
注意:
オプション--include-foreign-data--jobsオプションと互換性がありません。両方が指定されている場合、pg_dumpはエラーになります。
注意:
pg_dumpコマンドはSwarm64 DAメタデータ情報を無視します。詳細については、PostgreSQLのpg_dumpのドキュメントをご覧ください。

ワークロード管理

Swarm64 DAは、リソース管理システム、ワークロードマネージャーを提供し、クエリで使用可能なCPUとメモリの合計、および同時クエリの最大数を制限および制御します。
ワークロードマネージャーは、システムを枯渇させ、パフォーマンスの予測可能性を高める貪欲なクエリを回避します。
SELECT、UPDATE、INSERT、DELETEコマンドのみがワークロードマネージャーによって管理されます。 ANALYZEやVACUUMなどの他のすべてのコマンドは無視されます。
この機能はデフォルトで無効になっています。これを有効にするには、パラメーターswarm64da.enable_workload_managerをスーパーユーザーとしてonに設定します。

    swarm64da.workload_manager_max_concurrent_queries(integer)

システムで同時に実行できるクエリの最大数を設定します。この制限を超える新しいクエリはキャンセルされるか、実行中のクエリの1つが終了するまでブロックされます。
待機時間は、構成されたステートメントのタイムアウトに対してカウントされます。
カーソルやPL/pgSQL関数によって発行されたクエリなど、同じ接続によって発行されたすべてのクエリは、同じクエリと見なされ、同じリソースを共有します。
クエリは常に等しいクエリがすべてのリソースを使用できない場合でも、リソースの合計量のシェア、たとえば、システムが6 CPUと12 GBのメモリで構成されており、
同時クエリの最大数が2の場合、各クエリは常に3 CPUと6 GBのメモリを取得します。
デフォルト値はmax_worker_processes/2と同じです。このパラメーターをpostgresql.confファイルに設定します。

swarm64da.workload_manager_cpu_budget (integer)

ワークロードマネージャが分散できるCPUの総数を設定します。クエリごとに割り当てられるCPUの数は、クエリが使用できる並列ワーカーの数に影響し、
実行および計画中にmax_parallel_workersおよびmax_parallel_workers_per_gatherを上書きします。クエリには常に少なくとも1つ必要です。
値-1は、CPUに制約がなく、クエリが管理されていないかのように大量のCPUを使用することを示します。デフォルト値は
max_worker_processesです。このパラメーターをpostgresql.confファイルに設定します。

swarm64da.workload_manager_memory_budget (integer)

ワークロードマネージャーが分散できるメモリの総量をKBで設定します。割り当てられたメモリは、クエリが使用するwork_memの値を計算するためにのみ使用され、クエリプランの操作に依存します。
クエリは少なくとも64 KBのwork_mem値を取得します。クエリに複雑なプランがある場合、必要なメモリの総量は、ワークロードマネージャが割り当てたメモリ量よりも多くなります。
そのような場合、クエリは割り当てられた量より多くのメモリを使用します。値が-1の場合、メモリは制限されておらず、クエリは管理されていない場合と同じくらい多くのメモリを使用します。
デフォルト値は1 GBです。このパラメーターをpostgresql.confファイルに設定します。

swarm64da.workload_manager_adaptation_rate (floating point)

ワークロードマネージャーは、さまざまなワークロードに適応できるため、割り当てられたリソースの量をクエリごとに最大化します。
たとえば、通常4つのクエリがシステムで実行されている場合、各クエリはリソースの1/4を受け取りますが、
後で単一のクエリを実行すると、すべてのリソースを使用できます。ワークロードマネージャーは、時間の経過とともに同時クエリの最大数を変更します。
これは、swarm64da.workload_manager_max_concurrent_queriesの値を超えることはありません。
ワークロードマネージャーは、新しいクエリごとに、実行中およびキューに入れられたクエリの数に基づいて新しい最大値を計算します。
この値の変化速度は、この適応率パラメーターによって制御されます。この適応率パラメーターは、0から1まで変化します。
1に近い値は、現在の状態により多くの重みを与え、以前に計算された最大同時クエリ制限よりも少なくなります。
値0は、適応動作を無効にし、実際の最大値を変更しなくなります。デフォルト値は0.5です。このパラメーターをpostgresql.confファイルに設定します。

swarm64da.workload_manager_bypass_cost (integer)

クエリがワークロードマネージャをバイパスする閾値を設定します。合計計画コストがこのパラメーター以上のクエリは、ワークロードマネージャーによって管理されます。この値より低いものは無視されます。
デフォルト値は10,000です。このパラメーターを設定できるのはスーパーユーザーだけです。

swarm64da.workload_manager_priority (enum)

ユーザー、ロール、またはデータベースのクエリに優先度レベルを割り当てます。優先レベルは、MIN、LOW、MEDIUM、HIGH、MAXです。高い優先度の値で発行されたクエリは、低い値のクエリの前にスケジュールされます。
デフォルト値はMEDIUMです。このパラメーターを設定できるのはスーパーユーザーだけです。

ワークロードマネージャの検査

関数swarm64da.get_workload_stats()は、空きリソースの量、現在の同時クエリの最大数、キューで待機しているクエリの数、および現在実行中のクエリを表示します。
割り当てられたリソースとそれらを所有する接続のプロセスIDを表示するには、関数swarm64da.get_allocated_resources()を使用します。

JOINノード

Swarm64 DAは、パフォーマンス最適化とメモリ最適化された内部結合、左結合、準結合、および反結合の実装を提供します。
これらはそれぞれ、クエリプランでハッシュ結合、ハッシュ左結合、ハッシュ準結合、および結合ノードの下の2つのシャッフルを伴うハッシュ反結合として表示されます。
結合は、シャッフルもサポートされ、有効になっている場合にのみサポートされます。さらに、PostgreSQLのwork_memパラメータが許可するよりも多くのメモリを消費すると予測される場合、結合はオフになります。
メモリ使用量の予測が不正確であることが判明し、結合が許容量より多くのメモリを使用する場合、クエリはエラーを生成します。
明示的に結合を有効または無効にするには、swarm64da.enable_join(bool)データベース設定を使用します。
関連する概念
「Shuffleノード」

Shuffleノード

Swarm64 DAクエリプランナーは、ワーカー間で行を再分散するカスタムシャッフルノードを発行して、クエリの並列処理を改善できます。
ノードがクエリプランにカスタムスキャン(Swarm64 DAハッシュシャッフル)として表示されます。シャッフルノードは、結合または集計の下のプランに表示できます。
シャッフルは、parallel_leader_participation(boolean)パラメーターが無効になっている(SET parallel_leader_participation = FALSE)場合にのみサポートされます。
シャッフルを明示的に有効または無効にするには、swarm64da.enable_shuffle(bool)データベース設定を使用します。

クエリの書き換え

Swarm64 DAのクエリ書き換えサブシステムは、クエリをより優れたバリアントに書き換えることにより、特定のクエリのパフォーマンスを向上させます。
書き換えられたクエリは、意味的には元のクエリと同等です。これは、クエリが満たす必要のある強力な条件によって実施されます。
クエリの書き換えは、いくつかの独立した最適化を介して実行されます。これらの最適化の1つ以上を単一のクエリに適用でき、各最適化を個別に有効または無効にできます。

swarm64da.enable_unnesting (bool)

単一の集計サブクエリの非相関を有効にします。
次のクエリは同等です。

 SELECT s.name FROM students s, exams e WHERE s.id = e.student_id AND e.grade = (SELECT MIN(e2.grade) FROM exams e2 WHERE s.id = e2.student_id)
 ```

 ```
SELECT s.name, FROM students s,exams e, (SELECT e2.student_id as id, MIN(e2.grade) AS best FROM exams e2 GROUP BY e2.student_id) 
m WHERE s.id=e.student_id AND m.id=s.id AND e.grade=m.best

等価結合は、相関s.id = e2.student_idを持つ元のサブクエリよりも速く実行されます。デフォルト値はonです。

swarm64da.enable_not_in_to_not_exists (bool)

NOT INからNOT EXISTSへの変換を有効にします。
次のクエリは、idとサブクエリの出力がそれぞれNULL値を出力しない場合、同等です。

SELECT student FROM class WHERE id NOT IN (SELECT student_id FROM exams)
SELECT student FROM class WHERE NOT EXISTS (SELECT 1 FROM exams WHERE student_id = id)

NOT EXISTSを使用したクエリは、NOT INを使用したクエリよりも高速に実行されます。デフォルト値はonです。

注意
このユーザーガイドは開発元のSwarm64 AS社の許諾の元、翻訳版を公開しています。
そのため本文書の無料かつ、書面による許可なしの使用、複製、改変、再配布を固く禁じます。

CATEGORY

ARCHIVE

データベースの
パフォーマンス・チューニングのご相談は
株式会社インサイトまで
お気軽にお問い合わせください。

CONTACT