Snowflakeのいろんな数値を集めてみた(デフォルト、最大、仕様、推奨値等)

Snowflake

Last updated at 2024-10-27Posted at 2024-06-15

はじめに

Snowflakeで出てくる、様々な設定や仕様にまつわる「数値」をまとめてみました。

主にSnowflakeの認定試験(SnowPro CoreやAdvanced Architect)に向けて学習する過程で登場するものを中心に挙げてみました。

「この数値で何か制限あった気がするけど、何の制限だったっけ？」みたいなモヤモヤ、ありますよね？(自分は何度もありました...)
数値から見た、制限や仕様の逆引きみたいな感じです。

ここでは、1〜10にまつわるものをまとめてみました。

なお、0は特別なのか様々な意味を持ち合わせるので、ここでは省きました。
(設定する項目によって、数値の0という意味、無効という意味、最大という意味、無制限の意味、等)

1

1秒 (仕様)
- サーバーレスのクレジット使用状況
  
  サーバーレス機能の料金は、コンピューティング時間単位で測定されたSnowflake管理のコンピューティングリソースの合計使用状況に基づいて計算されます。コンピューティング時間は秒単位で計算され、端数は最も近い秒に丸められます。
  - つまり、サーバレスコンピューティングは「秒課金」=最低1秒単位での課金である、ということ
  - この課金体系が適用されるSnowflakeのサーバレス機能の例はこちら
1分 (60秒) (仕様)
- マルチクラスターウェアハウスのスケーリングポリシーの設定
  - マルチクラスターウェアハウスで、ウェアハウスを落とすかどうかを判定するチェックの実行間隔が1分間隔
  - これ単体ではあまり意識しなくていいかもしれない
  - 1分毎のチェックが連続で何回成功したか？が重要な観点
- コンピューティングコストについて
  
  クレジットは最低60秒（つまり、1分）で、秒ごとに請求されます。
- ウェアハウス(コンピューティング)コストは、〜60秒以内は同じコストが請求されるという最小単位
- 60秒より後は1秒毎に課金される
  - ウェアハウスのサイズを選ぶ目安にもなったりする
  - XSで長時間稼働させるくらいなら、S以上で60秒以内で処理が完結する方が安くつく等を見極めないといけない
- 資格試験でほぼ確実に問われる仕様
1時間 (60分,3600秒,3600000ミリ秒) (デフォルト)
- タスクがタイムアウトしたか、スケジュールウィンドウを超過した
  
  タスクの1回の実行には、60分のデフォルトの制限があります。この制限は、終了しないタスクに対する保護手段として実装されました。
  ...
  テートメントが記録を返さない場合、タスクには現在、デフォルトの 3600000 ミリ秒（60分）のタイムアウトがあります。
- USER_TASK_TIMEOUT_MS
  
  タスクがタイムアウトするまでの1回の実行の制限時間（ミリ秒単位）を指定します。
  ...
  3600000 （1時間）
- タスクはデフォルト1時間でタイムアウト、これは押さえておいた方がいい仕様
- ついでに、SPCS(Snowpark Container Services)のコンピューティングプールが非アクティブ時に中断されるまでの時間(AUTO_SUSPEND_SECS)も1時間なので、実務向けに覚えておくとよさそう
  - CREATE COMPUTE POOL - オプションのパラメーター
    
    AUTO_SUSPEND_SECS = num
    
    Snowflakeがコンピューティングプールを自動的に中断させるまでの非アクティブの秒数。非アクティブなコンピューティングプールとは、プール内のどのノード上でもサービスやジョブが現在アクティブではないプールのことです。
    デフォルト: 3600秒
1日 (デフォルト)
- タイムトラベル(Time Travel)でよく出てくる日数
- データ保持期間
  
  標準の保持期間は1日（24時間）であり、すべてのSnowflakeアカウントで自動的に有効になります。
- DATA_RETENTION_TIME_IN_DAYS
  
  Snowflakeがオブジェクトに対してTime Travelアクション（SELECT、CLONE、UNDROP）を実行するための履歴データを保持する日数です。
  デフォルト 1
- タイムトラベルはとりあえずデフォルトでは1日分遡れる、ということ
1日 (最大)
- USER_TASK_TIMEOUT_MS
  
  タスクがタイムアウトするまでの1回の実行の制限時間（ミリ秒単位）を指定します。
  ...
  0 - 86400000 （1日）。
- タスクのタイムアウトは最大1日、これも押さえておいた方がいい仕様
1年 (仕様)
- 定期的なキー更新
  
  定期的なキー更新が有効になっている場合、テーブルの廃止された暗号化キーが1年より古い場合、Snowflake は自動的に新しい暗号化キーを作成し、廃止されたキーによって以前に保護されていたすべてのデータを新しいキーを使用して再暗号化します。
- PERIODIC_DATA_REKEYING
  
  このパラメーターは、 Enterprise Edition （またはそれ以上）にのみ適用されます。毎年、新しいキーを使用してテーブルデータの再暗号化を有効/無効にして、データ保護の追加レベルを提供します
  ...
  TRUE ：データが最後に暗号化されてから1年が経過すると、データのキーが再生成されます。キー更新はバックグラウンドで行われるため、ダウンタイムは発生せず、影響を受けるデータ/テーブルは常に利用可能です。
- Snowflakeが管理する暗号化キーの更新周期に関する数値(1年周期で更新)
- Enterprise Edition以上で利用可能
- デフォルトはFALSEなので、定期更新は行われない
- 有効化するにはALTER ACCOUNT SET PERIODIC_DATA_REKEYING = TRUE;を実行
1年 (365日) (保持期間) (仕様)
- 「ACCOUNT_USAGE」「ORGANIZATION_USAGE」の保存期間としてよく出てくる
- 履歴データ保持
  
  特定のアカウント使用状況ビューは、使用状況の履歴メトリックを提供します。これらのビューの保持期間は1年（365日）です。
- 組織の使用状況
  
  AUTOMATIC_CLUSTERING_HISTORY : データは1年間保持されます。
1ステートメント (デフォルト)
- MULTI_STATEMENT_COUNT
  
  マルチステートメント機能を使用するときに実行するステートメントの数。
  ...
  デフォルト 1
- 単一リクエストによる複数のSQLステートメントの送信を実現したい時に意識するパラメータ
- 実務等でなんとなく1リクエストで複数SQLを送信してしまって、これに引っかかる可能性がなくもない
1クレジット(仕様)
- 仮想ウェアハウスのクレジット使用状況
- ウェアハウスのサイズ:XSの消費クレジット
- 以降のサイズは、2倍で増えていくので、XSが1だと覚えておけばS以上は算出できる
- 資格試験向けには必須級で覚えておくべき事項
1MB(制限)
- ログおよびトレースの制限事項
  
  ログおよびトレースイベントペイロードには 1MB の制限があります。ペイロードが 1MB のしきい値を超えている場合、イベントテーブルの記録は不完全となり、列 TIMESTAMP、 RECORD_TYPE、および RESOURCE_ATTRIBUTES の値のみが含まれます。現時点では、しきい値を超えた場合のその他の通知はありません。
- 一部のワークシートをインポートできない
  
  考えられる原因と解決策:
  
  原因
  ワークシートが大きすぎます。 Snowsight の最大ワークシートサイズは 1MB で、 1MB より大きいワークシートはインポートできません。
- クエリテキストサイズの制限
  
  Snowflakeは、Snowflakeクライアントを介して送信されるクエリテキスト（つまり、 SQL ステートメント）のサイズをステートメントごとに1MB に制限することをお勧めします。それ以上のクエリも正常に処理されますが、Snowflakeでは1ステートメントあたり 1MB を超えるクエリはメタデータストアに永続化される前に切り捨てられるため、再実行や再試行はできませんでした。
  - こちらは「1MBに制限することをお勧め」と書かれてあるが、1MBを超えたらよくないことが起こると書いてあるので実質制限扱い

2

2時間 (120分) (仕様)
- Account Usage - データの待機時間
  
  Snowflakeの内部メタデータストアからデータを抽出するプロセスにより、アカウント使用状況ビューには自然な待機時間が発生します。
  ほとんどのビューでは、待機時間は2時間（120分）です。
- 大体のAccount Usageのビューに反映されるまでの時間は、2時間のラグがある
2日 (172800秒) (デフォルト)
- STATEMENT_TIMEOUT_IN_SECONDS
  
  実行中の SQL ステートメント（クエリ、 DDL、 DMLなど）がシステムによってキャンセルされるまでの時間です（秒単位）。
  デフォルト 172800 （つまり、2日）
- 何も設定しなければ、SQLの実行は2日後に強制キャンセルが掛かる
- よく陥りがちなのが、タスクが実行するSQLはデフォルトではこれよりも早くタイムアウトしてしまうこと
  - タスクはこちら(USER_TASK_TIMEOUT_MS)の考慮が必要
- ちなみに、SPCSのジョブについても同じパラメータを参照して同様の制約を受けるので、ついでに意識しておくとよさそう
  - ガイドラインと制約
    
    ジョブのタイムアウト: Snowpark Container Servicesのジョブは同期的に実行されます。ステートメントがタイムアウトすると、ジョブはキャンセルされます。デフォルトのステートメントタイムアウトは2日間。お客様は、ALTER SESSION を使用してパラメーター STATEMENT_TIMEOUT_IN_SECONDS を設定することにより、タイムアウトを変更できます。
    ALTER SESSION SET statement_timeout_in_seconds=<time>
2日 (仕様)
- DATA_SHARING_USAGE ビュー
  - DATA_SHARING_USAGEスキーマのビューの大半は2日間の待機時間となっている
2人 (推奨値)
- ユーザーに対する ACCOUNTADMIN ロール割り当ての制御
  ACCOUNTADMIN のロールをユーザーに割り当てる際には、次の点に注意することを強くお勧めします。
  - このロールは、組織内の選択された/限られた人数にのみ割り当ててください。
  - ACCOUNTADMIN ロールを割り当てられたすべてのユーザーは、ログインに多要素認証（MFA）を使用する必要もあります（詳細については、アクセス制御の構成をご参照ください）。
  - このロールを少なくとも2人のユーザーに割り当てます。
- Snowflake1アカウント内に、ACCOUNTADMINが使用できるユーザーを少なくとも2人作っておくことが推奨されている
- 実用的には「(1)原則使用しないユーザー(例えばログインできない無効なユーザーに割り当てておく」とか「(2)権限昇格によって一時的に特定のユーザーだけがACCOUNTADMINを使えるような仕組みを作っておく」とかで乗り切るのがいいかもしれない
2〜3回 (仕様)
- マルチクラスターウェアハウスのスケーリングポリシーの設定
  - スケーリングポリシー - 標準において、ウェアハウスを落とす条件
    
    2～3つのチェック（1分間隔で実行）に連続して成功した後、クラスターを再起動せずに、最小負荷クラスターの負荷を他のクラスターに再分散できるかどうかが決定されます。

3

3層 (仕様)
- Snowflakeアーキテクチャ
  Snowflakeのユニークなアーキテクチャは、3つの重要なレイヤーで構成されています。
  - データベースストレージ
  - クエリ処理
  - クラウドサービス
- 基礎にして超重要な概念
3〜4列 (推奨値)
- クラスタリングキーを選択するための戦略
  
  単一のクラスタリングキーには、1つ以上の列または式を含めることができます。ほとんどのテーブルでは、Snowflakeはキーごとに最大3または4列（または式）を推奨しています。3〜4を超える列を追加すると、利益よりもコストが増加する傾向があります。
- 闇雲にクラスタリングキーを増やせばいいわけではないということ

4

4時間 (仕様,最大)
- MFA トークンキャッシングを使用して認証中のプロンプトの数を最小限に抑える
  
  MFA トークンのキャッシュは、特に比較的短い時間間隔内に複数の接続が試行される場合に、Snowflake への接続と認証中に確認する必要があるプロンプトの数を減らすのに役立ちます。キャッシュされた MFA トークンは最大4時間有効です。
- ここだけ4時間...これは忘れがちな数値かもしれない
- 試験向けに意識しておいた方がいい数値かもしれない

5

5GB (仕様,最大)
- ステージ、パイプ、ロード履歴の複製 - 考慮事項
  
  内部ステージのディレクトリテーブルに5GBを超えるサイズのファイルがある場合、リフレッシュ操作は失敗します。この制限を回避するには、 5GBより大きなファイルを別のステージに移動します。
- 単一ファイルへのアンロード
  
  Amazon S3、Google Cloud Storage、またはMicrosoft Azureステージの場合、サポートされる最大ファイルサイズは5GBです。
- 1ファイルあたりの上限サイズとしてよく出てくる数値
- 目にする機会も多いと思うので、比較的覚えやすいはず
5分 (仕様)
- ABORT_DETACHED_QUERY
  
  セッションの突然の終了（ネットワークの停止、ブラウザの終了、サービスの中断など）により接続が失われた場合に、進行中のクエリに対してSnowflakeが実行するアクションを指定します。
  ...
  TRUE : 接続が失われると、進行中のクエリは5分後に中止されます。
- デフォルトはFALSE (=進行中のクエリは完了される) のため、あんまり気にしない数値かもしれない
- 実務ではもしかしたら気にするケースがありそう
5回 (デフォルト)
- CREATE PASSWORD POLICY - オプションのパラメーター
  
  PASSWORD_MAX_RETRIES = integer
  ロックアウトされるまでのパスワード入力の最大試行回数を指定します。
  サポートされている範囲は1から10までです。
  デフォルト: 5
- デフォルトでは、パスワードの入力ミスは5回まで
5または10分以下 (推奨値)
- ウェアハウスの停止の自動化
  
  自動中断を有効にする場合は、Snowflakeが1秒あたりの請求を使用するため、低い値（5または10分以下）に設定することをお勧めします。これは、使用されていないときにウェアハウスが稼働しないように（そしてクレジットを消費しないように）します。
- ウェアハウスの自動停止時間を設定する時の推奨値
- ウェアハウスを使っていない時の自動停止の設定なので、クエリ実行時間がこれよりも長くても勝手に停止されることはない
5〜6回 (仕様)
- マルチクラスターウェアハウスのスケーリングポリシーの設定
  - スケーリングポリシー - エコノミーにおいて、ウェアハウスを落とす条件
    
    5から6の連続した成功したチェック（1分間隔で実行）の後。これにより、クラスターを再起動せずに、最小負荷クラスターの負荷を他のクラスターに再分散できるかどうかが決定されます。
  - 「標準」と比べて連続で成功させないといけないチェック回数が多いので、シャットダウン条件が厳しい、緩やかにシャットダウンされるようなイメージ
  - スケーリングポリシー周りは押さえておくべき数値が多い...
5文字以上 (仕様)
- 検索最適化による部分文字列と正規表現クエリの高速化
  
  検索最適化サービスにより、5文字以上の長さの部分文字列を検索する際のパフォーマンスを向上させることができます。
- 検索最適化サービスを利用する際のポイントになってくる
- 「5文字以上」の文字列を検索する際は効いてくる一方で、それより短い文字列を検索しようとすると効果が発揮されない

6

6分 (仕様)
- マルチクラスターウェアハウスのスケーリングポリシーの設定
  - スケーリングポリシー - エコノミーにおいて、新しくウェアハウスが起動する条件
    
    システムが、クラスターを少なくとも6分間ビジー状態に保つのに十分なクエリ負荷があると推定する場合のみ。
  - これは6分間というキーワードは覚えられたとしても、標準 or エコノミーどっちだっけ？で迷うかもしれない
6ヶ月 (仕様,最大)
- Information schemaで閲覧できる期間を指す
- Snowflake Information Schema
- 例えば...
  - DATABASE_STORAGE_USAGE_HISTORY
    このテーブル関数は、指定された日付範囲内の単一のデータベース（またはアカウント内のすべてのデータベース）の1日の平均ストレージ使用量をバイト単位でクエリするために使用できます。結果は次が含まれます。
    - データベースのテーブルとマテリアライズドビューに保存されているすべてのデータ。
    - データベースのFail-safeで維持されるすべての履歴データ。
      注釈
      この関数は、過去6か月以内のストレージ使用量を返します。
  - 6ヶ月の期間分も取得できるデータに関しては資格試験ではあまり問われない感じがしている
  - もっと期間の短いデータに関しては特に問われがちなイメージ
6クレジット (仕様)
- VIRTUAL WAREHOUSES (COMPUTE)
- Snowpark-Optimizedなウェアハウスの最小サイズがMであり、そのクレジットが6である
- 以降は2倍ずつ増える(標準のウェアハウスと同様)
- 同じMサイズでも、標準のウェアハウス(Mサイズ:4クレジット)とは異なる点に注意

7

7日 (604800秒) (最大)
- STATEMENT_TIMEOUT_IN_SECONDS
  
  実行中の SQL ステートメント（クエリ、 DDL、 DMLなど）がシステムによってキャンセルされるまでの時間です（秒単位）。
  0 ～ 604800 （つまり、7日間）
  0 の値は、最大タイムアウト値が適用されることを指定します。
- SQLは最大1週間実行し続けることができる、ということ
- 相当巨大なデータか複雑なクエリか...いずれにしてもウェアハウスの利用料金が気になるところ
7日 (仕様,最大)
- Fail-safeで遡れる最大日数であり、固定値でもある(減らすことも増やすことも不可)
- Fail-safeとは
  
  Fail-safeが提供する、Snowflakeによって履歴データを回復できる可能性のある期間（構成不可能）は7日間です。
- ただしベストエフォート
- 永続テーブルの量産で意図せずストレージコストが掛かるので、お試しテーブルはTAMPORARYとかTRANSIENTで作るようにした方がよい
7日 (仕様,最大)
- Information schemaで閲覧できる期間を指す
- Snowflake Information Schema
- 例えば...
  - LOGIN_HISTORY
    LOGIN_HISTORY ファミリーのテーブル関数を使用して、Snowflakeユーザーによるさまざまなディメンションに沿ったログイン試行をクエリできます。
    - LOGIN_HISTORY は、指定された時間範囲内のログインイベントを返します。
      ...
      注釈
      これらの関数は、過去7日以内のログインアクティビティを返します。
- 他にもQUERY_HISTORY, TASK_HISTORYも該当する
- これらの特性を意識しておくことは、試験でも実務でも結構重要

8

8分 (推奨値)
- エンドポイント: loadHistoryScan
  
  重要
  このエンドポイントは、過剰な呼び出しを避けるためにレート制限されています。レート制限（エラーコード429）を超えないようにするため、 loadHistoryScan よりも insertReport に強く依存することをお勧めします。 loadHistoryScan を呼び出すとき、データロードのセットを含む最も狭い時間範囲を指定します。たとえば、履歴の最後の10分を8分ごとに読むとうまくいきます。
- Snowpipe のloadHistoryScan エンドポイントを呼び出すときに従うべきベストプラクティス
- 重要と書いてある通り、このエンドポイントを使うにあたっては重要な考慮点
- 「重要」とあるだけに、資格試験でも問われそう
8ステートメント(同時実行レベル) (デフォルト)
- MAX_CONCURRENCY_LEVEL
  
  ウェアハウスによって実行される SQL ステートメント（つまり、クエリおよび DML）の並行性レベルを指定します。
  ...
  デフォルト 8
- MAX_CONCURRENCY_LEVEL を下げる方法
  
  デフォルトの最大同時実行レベルは8です。レベルを下げるには、 ALTER WAREHOUSE コマンドを使用してより低い数値を指定します。
- ウェアハウス1台あたり、デフォルトで8クエリ同時に捌けるということ
- SQLがあるタイミングで大量に同時実行されるようなワークロードで効いてくる
- マルチクラスターの最大化モードの話と合わせてとよく出てくる
8MB（8,388,608バイト）(仕様,最大)
- バイナリ型データの最大長
- binary
  
  最大長は8MB （8,388,608バイト）です。VARCHAR とは異なり、 BINARY データ型にはUnicode文字の概念がないため、長さは常にバイト単位で測定されます。

9

特になさそうでした。

10

10 (台,クラスター) (最大)
- マルチクラスターウェアハウスとは
  
  Snowflakeは、マルチクラスターウェアハウスを使用して、静的または動的に追加のクラスターを割り当てて、より多くのコンピューティングリソースを利用できるようにします。マルチクラスターウェアハウスは、次のプロパティを指定することで定義されます。
  クラスターの最大数。1より大きい（最大10）。
  クラスターの最小数。最大値以下（最大10）。
- マルチクラスターウェアハウスの設定で指定できる最大の数が10
10分 (仕様,最大)
- エンドポイント： insertReport
  
  このエンドポイントには次の制限があります。
  10、000の最新のイベントが保持されます。
  イベントは最大10分間保持されます。
- Snowpipe insertReport エンドポイントの仕様上の最大分数
- このエンドポイントを使う上では重要なポイント
10分 (仕様)
- コンシューマーのデータが欠落している、または同期されていない
  
  自動複製リストからのビューが表示されなくなったとコンシューマーから報告されました。
  ...
  オブジェクトが再作成された後、共有に再付与されなかった
  あるいは、オブジェクトが再付与されたが、10分未満しか経過していない。共有に付与されたオブジェクトの変更は10分ごとにチェックされるので、10分未満であれば、更新されたオブジェクトはまだコンシューマーのリージョンに自動複製されていません。
- 複製における仕様として、10分毎の変更チェック〜反映という周期になる
- 複製先に反映されていない時は10分待って再確認が必要
10分 (仕様)
- Snowflake OAuth の概要
  
  アクセストークンは短期間有効で、通常は10分です。アクセストークンの有効期限が切れると、クライアントは更新トークンを送信して新しいアクセストークンを取得できます。
- 比較的短いので利用時は注意
10% (仕様)
- クラウドサービスの使用に対する請求について
  
  クラウドサービスの使用量は、クラウドサービスの日次消費量が仮想ウェアハウスの日次使用量の10%を超えた場合にのみ請求されます。料金は毎日計算されます（UTC タイムゾーン）。これにより、その日のクレジット価格で、毎日10%の調整が正確に適用されます。
- コストに関する数値
- コストを計算するにあたっては重要な考慮点
- Snowflakeアカウント作成直後〜初期構築段階等、ウェアハウスをあまり稼働していない時に請求されがちなコスト
10回 (デフォルト)
- SUSPEND_TASK_AFTER_NUM_FAILURES
  
  タスク実行が連続して失敗した後、スタンドアロンタスクまたはタスクグラフルートタスクが自動的に中断した回数。失敗したタスク実行には、タスク本体の SQL コードがユーザーエラーを生成するかタイムアウトになった実行が含まれます。スキップ、キャンセル、またはシステムエラーが原因で失敗したタスク実行は不確定と見なされ、失敗したタスク実行の数には含まれません。
  ...
  パラメーターのデフォルト値は10に設定されています。これは、10回連続してタスクの実行に失敗すると、タスクが自動的に中断されることを意味します。
- タスクがいつの間にか state : SUSPENDED になっているのは、大体これのせいと思われる(参考)
- 実務向けの考慮点かもしれない
10K (仕様,最大)
- SHOW IMAGE REPOSITORIES - 使用上の注意
  
  コマンドは、コマンドを実行するために使用されるロールのアクセス権によって決定された通り、指定されたオブジェクトタイプに対して最大 10Kの記録を返します。フィルタが適用されていても、10Kの制限を超える記録は返されません。
10TB (仕様,最大)
- データベースが10テラバイトを超えている
  
  エラー
  共有が10TBを超えるデータベースに関連付けられているため、自動複製は使用できません。
  データ製品が10TBを超えるデータベースに関連付けられているため、自動複製は使用できません。
- 複製の制限(上限)として最大10TB/データベースが設定されている
- サポートに連絡すれば上限緩和は可能とのこと

おわりに

こうやって並べてみると、色んな数値がありますね...

こういった数値に関してはとりあえず把握はするものの、どうやって決まるのか？あたりが気になったりしますね。
恒久的にこの数値なのか、改修やバージョンアップで見直されるのか、とかも。
資格試験で問われるような数値に関しては、ほぼ恒久的に決まっているのかなとも思ったりします。

まだまだ色んな数値が存在しますが、10よりも大きな数値に関しても別途まとめたいかなと思います。

以上です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up