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

## はじめに

こちらの記事 [Snowflakeのいろんな数値を集めてみた(デフォルト、最大、仕様、推奨値等)](https://qiita.com/fkdfkdfkd/items/2b7a5107c56246627c3d) の続編になります、

前回は、1〜10をピックアップしてみました。
今回は、11以降の数値にまつわるものをまとめてみました。

前回同様に資格試験で出てきそうなものとか、存在するものから気になったものとかを抜粋して列挙していきますので、数値の粒度も荒くなります。
(早速、11に該当しそうなものがなかった...)

## 12

- 12時間 (43200秒) (デフォルト)
    - [LOCK_TIMEOUT](https://docs.snowflake.com/ja/sql-reference/parameters#lock-timeout)

        > リソースをロックしようとして、タイムアウトしてステートメントを中止するまでの待機秒数です。
        > デフォルト 43200 （つまり、`12時間`）

## 14

- 14日 (仕様,最大)
    - Information schemaで閲覧できる期間を指す
    - [Snowflake Information Schema](https://docs.snowflake.com/ja/sql-reference/info-schema)
    - 例えば...
        - [COPY_HISTORY](https://docs.snowflake.com/ja/sql-reference/functions/copy_history)

            > このテーブル関数を使用して、さまざまなディメンションに沿って過去14日間のSnowflakeデータのロード履歴をクエリできます。
            > ...
            > このビューは、`14日`を上限としたコピー履歴を返します。この制限を回避するには、 COPY_HISTORY ビュー （Account Usage）を使用します。
    - 他にも、[LOAD_HISTORY](https://docs.snowflake.com/ja/sql-reference/info-schema/load_history)、[WAREHOUSE_LOAD_HISTORY](https://docs.snowflake.com/ja/sql-reference/functions/warehouse_load_history)とかも
    - Information schemaで見ることができる範囲が14日以内であるものが一番多いのもポイント
    - 「2週間」とし表現を改めて、「2」に含めても良かったかも

- 14日 (デフォルト)
    - [MAX_DATA_EXTENSION_TIME_IN_DAYS](https://docs.snowflake.com/ja/sql-reference/parameters#max-data-extension-time-in-days)

        > Snowflakeがテーブルのデータ保持期間を延長して、テーブル上のストリームが古くなるのを防ぐことができる最大日数。
        > ...
        > デフォルト `14`

    - [データ保持期間と陳腐化](https://docs.snowflake.com/ja/user-guide/streams-intro#data-retention-period-and-staleness)

        > テーブルのデータ保持期間が`14日`未満 であり、ストリームが消費されていない場合、Snowflakeはこの期間を一時的に延長して、古くならないようにします。アカウントの Snowflake Edition に関係なく、期間はストリームのオフセットまで、デフォルトで最大14日まで延長されます。

    - こちらもつまり2週間ということ
    - ストリームを消費せずに放置するとこれに引っかかるので注意
    - 特に検証環境とかでは、ストリームの残骸が残っていて次に動かそうとした時にこの条件に引っかかってしまい、古いストリームのせいで動かなくなっている可能性がありそう

- 14桁 (仕様,最大)
    - [Geospatial Data Supports 14 Digits](https://community.snowflake.com/s/article/Geospatial-data-supports-14-digits-after-decimal-point-for-coordinate-values)

        > Currently, Snowflake supports a maximum of `14 digits` after the decimal point for Geospatial data and it rounds the number off to `14 digits` if a user submits a coordinate value greater than `14 digits` after the decimal point.

        - Snowflakeでは地理空間データの小数点以下最大14桁をサポートしているとのことで、地理空間データを扱う場合は気にしておいた方がいいかも

## 15

- 15分 (デフォルト)
    - [CREATE PASSWORD POLICY - オプションのパラメーター](https://docs.snowflake.com/ja/sql-reference/sql/create-password-policy#optional-parameters)

        > PASSWORD_LOCKOUT_TIME_MINS = integer
        >
        > 指定されたパスワード再試行回数（つまり、 PASSWORD_MAX_RETRIES）に達した後、ユーザーアカウントがロックされる分数を指定します。
        > サポートされている範囲は1から999までです。
        > デフォルト: `15`

    - デフォルトでは、パスワードを間違えまくってロックされた後、15分待つと再試行できるようになる

## 16

- 16 MB（16777216バイト） (仕様,最大)
    - VARIANT型データの最大サイズ
        - [VARIANT の特徴](https://docs.snowflake.com/ja/sql-reference/data-types-semistructured#characteristics-of-a-variant)

            > VARIANT の最大サイズは`16MB`です。しかし実際には、内部的なオーバーヘッドのために最大サイズは小さくなるのが普通です。最大サイズは保存されるオブジェクトにも依存します。

    - ロード中とかでサイズを超えてしまうと以下のようなエラーが出るとのこと
        - [Max LOB size exceeded](https://community.snowflake.com/s/article/Max-LOB-size-exceeded)

            > Max LOB size (16777216) exceeded, actual size of parsed column is 17894470.

    - また、VARCHARも同様
        - [VARCHAR](https://docs.snowflake.com/ja/sql-reference/data-types-text#varchar)

            > VARCHAR の最大長は 文字数 で指定されますが、 VARCHAR には、最大 バイト数 （16,777,216（`16 MB`））の制限もあります。VARCHAR 列に保存できるUnicode文字の最大数を以下に示します。

- 16MB (デフォルト)
    - アンロード時の出力ファイルのサイズ
    - [COPY INTO <場所> - オプションのパラメーター](https://docs.snowflake.com/ja/sql-reference/sql/copy-into-location#optional-parameters)

        > MAX_FILE_SIZE
        > スレッドごとに並列に生成される各ファイルの上限サイズ（バイト単位）を指定する数値（> 0）。実際のファイルサイズとアンロードされるファイルの数は、並列処理に使用可能なデータの合計量とノードの数によって決定されることに注意してください。
        > ...
        > デフォルト 16777216 （`16 MB`）

    - COPY INTO <場所> を使う際、並列操作を利用するために出力するファイルを分割する仕様になっている
    - このサイズを大きく設定すると1ファイルに集約されることになるので、アンロードに掛かる時間も遅くなる
    - アンロード処理に対してパフォーマンスを求められる場合に注意する

## 20

- 20秒 (仕様)
    - [マルチクラスターウェアハウスのスケーリングポリシーの設定](https://docs.snowflake.com/ja/user-guide/warehouses-multicluster#setting-the-scaling-policy-for-a-multi-cluster-warehouse)

        > 標準（デフォルト）
        > クエリの処理待ち、または システムが現在実行中のクラスターで実行できるクエリよりも1つ多いクエリが検出されると、最初のクラスターがただちに始まります。
        > 連続する各クラスターは、前のクラスターが始まってから`20秒`の間、開始を待機します。
        > たとえば、ウェアハウスが最大クラスター数10個で構成されている場合、クラスター10個すべてを開始するのに必要な時間は、丸々200秒以上かかる場合があります。

    - マルチクラスターウェアハウス 標準 (デフォルト)モードにおける、次のクラスターが起動するまでの待機時間
    - 最初のクラスターは、クエリがキューに入れられるか、現在実行中のクラスターで実行できるクエリより1つ多いクエリがあることをシステムが検出するとすぐに開始される
    - 以降のクラスターが必要になる場合は、開始を20秒待機してから起動する仕様

## 24

- 24時間 (仕様)
    - [保存済みのクエリ結果の使用](https://docs.snowflake.com/ja/user-guide/querying-persisted-results)

        > クエリが実行されると、結果は一定期間保持（つまり、キャッシュ）されます。期間が終了すると、結果はシステムからパージされます。
        > Snowflakeは永続的なクエリ結果を使用して、何も変更されていない場合（「取得の最適化」）に結果が再生成されるのを防ぎます。さらに、永続的なクエリ結果を使用して結果を後処理できます（例：既に計算された結果の上に新しいクエリを重ねる）。
        > すべてのサイズの永続的なクエリ結果の場合、キャッシュは`24時間`後に期限切れになります。

    - 結果キャッシュが(利用されなければ)削除されるまでの猶予時間
    - これも24h = 1日なので、「1」に含めても良かったかも
    - 24h以内にキャッシュが利用されると、その時点から24hのカウントがリセットされる
    - ただし永久に24hがリセットされるわけではない (MAX31日間保持)
    - RESULT_SCANは、このキャッシュの有効期限内であれば利用できる
        - [RESULT_SCAN](https://docs.snowflake.com/ja/sql-reference/functions/result_scan)

            > 結果がテーブルであるかのように、以前のコマンドの結果セット（クエリを実行した`24時間`以内）を返します。
            > ...
            > `24時間`が経過していない限り、コマンド/クエリは現在のセッションまたは過去のセッションを含む他のセッションから取得できます。
            > ...
            > Snowflakeは、すべてのクエリ結果を`24時間`保存します。この関数は、この期間内に実行されたクエリの結果のみを返します。

- 24時間 (待機時間) (仕様)
    - 主に「ORGANIZATION_USAGE」の待機時間としてよく出てくる
    - [組織の使用状況](https://docs.snowflake.com/ja/sql-reference/organization-usage)
    - 例えば...
        - [ACCOUNTSビュー - 使用上の注意](https://docs.snowflake.com/ja/sql-reference/organization-usage/accounts#usage-notes)

            > 使用上の注意
            > ビューの遅延は最大`24時間`です。

    - 一方で[Account Usage](https://docs.snowflake.com/ja/sql-reference/account-usage#account-usage-views)は大体2〜3時間の待機時間になっている
- 24個(過去24個分) (最大)
    - [CREATE PASSWORD POLICY - オプションのパラメーター](https://docs.snowflake.com/ja/sql-reference/sql/create-password-policy#optional-parameters)

        > PASSWORD_HISTORY = integer
        >
        > Snowflakeが保存する最新のパスワードの数を指定します。保存されたこれらのパスワードは、ユーザーがパスワードの値を更新するときに繰り返して使用することはできません。
        > 現在のパスワードの値は履歴にカウントされません。
        > ...
        > デフォルト: 0
        > 最大: `24`

    - いわゆるパスワードの再利用禁止の設定
    - 最大で過去24個分のパスワードを保持しておき、再利用禁止にできるということ
    - [AWSとかでも](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)最大履歴は24になっている

## 25

- 25クレジット/TB (仕様)
    - [UNDERSTANDING SNOWFLAKE PRICING](https://www.snowflake.com/pricing/pricing-guide/)

        > $25 per Terabyte per month for customer deployed in AWS – Asia Pacific (Tokyo)
        > $25 per Terabyte per month for customer deployed in Azure – Japan East (Tokyo)

    - AWSおよびAzureの東京リージョンでのストレージコスト
    - 多分日本ではよく使われると思うのでピックアップした

## 30

-  30日 (仕様)
    - [暗号化キーのローテーション](https://docs.snowflake.com/ja/user-guide/security-encryption-manage#encryption-key-rotation)

        > Snowflakeが管理するキーすべては、`30日`以上経過するとSnowflakeによって自動的にローテーションされます。アクティブなキーは廃止され、新しいキーが作成されます。廃止されたキーが不要になったとSnowflakeが判断すると、キーは自動的に破棄されます。

    - Snowflakeのオブジェクトキーは、30日ごとに自動的にローテーションされる

## 31

- 31日 (仕様,最大)
    - [保存済みのクエリ結果の使用 - 取得の最適化](https://docs.snowflake.com/ja/user-guide/querying-persisted-results#retrieval-optimization)

        > クエリの永続化された結果が再利用されるたびに、Snowflakeはクエリの最初の実行日時から最大`31日`まで、結果の24時間の保持期間をリセットします。`31日`後、結果は消去され、次回クエリが送信されると、新しい結果が生成されて保持されます。

    - 結果キャッシュの最大保存期間
    - キャッシュが使用されなければ24時間で削除されるが、使用するとカウントがリセットされてまた24時間延命される
    - なんだかんだ使用され続けた結果、31日までは延長される

## 32

- 32文字 (仕様,最大)
    - [CREATE EXTERNAL TABLE - パーティション分割パラメーター](https://docs.snowflake.com/ja/sql-reference/sql/create-external-table#partitioning-parameters)

        > これらのパラメーターを使用して、外部テーブルをパーティション分割します。
        > `<part_col_name> <col_type> AS <part_expr>`
        > ...
        > 注釈
        > ユーザー指定のパーティション列名の最大長は`32文字`です。

    - そんなに長い名前にしないかもしれないが、社内で決めた命名規則とかに従っていると超えちゃうかも

- 32MB (仕様,最大)
    - [Streamlitアプリのデータ制限](https://docs.snowflake.com/ja/developer-guide/streamlit/limitations#data-limits-on-streamlit-apps)

        > Streamlit in Snowflake と Snowflake Native App で実行中のStreamlitアプリは、1回のクエリから取得できるデータ量に`32MB`の制限があります。`32MB`を超えるクエリは以下のエラーをスローします。
        >
        > MessageSizeError: Data Size exceeds message limit
        > この制限を回避するには、`32MB`より小さい単位でデータを取得するようにStreamlitアプリを設計します。

    - Streamlitが使えるようになって(Snowflake in Streamlit/SiS)、データアプリのGUI化をバリバリやろうとしている中で、忘れた頃にこの制限に引っかかりそうかも

## 36

- 36時間 (仕様)
    - [Sparkコネクターの概要 - データ転送](https://docs.snowflake.com/ja/user-guide/spark-connector-overview#data-transfer)

        > Tip
        > 次のいずれかに該当する場合は、外部データ転送を使用します。
        >
        > - バージョン2.1.x以下のSparkコネクターを使用している場合（内部転送をサポートしていません）。
        > - 転送に`36時間`以上かかる可能性がある場合（内部転送では、`36時間`後に期限が切れる一時的な認証情報が使用されます）。
        > 
        > それ以外の場合は、内部データ転送の使用を お勧めします。

    - Sparkコネクターの転送モード 外部転送 or 内部転送 を選択する際の1つの判断基準

## 37

- 37桁 (仕様,最大)
    - [数値データ型 - 固定小数点数のデータ型](https://docs.snowflake.com/ja/sql-reference/data-types-numeric)

        > 最大スケール（小数点の右側の桁数）は`37`です。有効桁数が38未満ですが、最下位桁が小数点以下37桁を超える数値（例：0.0000000000000000000000000000000000000012（1.2e-39）は、一部の精度の桁を失うことなく表現できません。

    - 数値の小数点の右側の表現は最大37桁になっている

## 38

- 38桁 (仕様,最大)
    - [数値データ型 - 固定小数点数のデータ型](https://docs.snowflake.com/ja/sql-reference/data-types-numeric)

        > NUMBER
        > オプションの精度とスケールを使用した、最大`38`桁の数字です。

    - 数値は38桁までの表現が限度ということ

## 50

- 50MB (仕様,最大)
    - ウェブインタフェース(Snowsight)経由でのデータロード時のファイルの上限サイズだった数値
    - いまでは250MBまでアップロード可能となっている
        - [ウェブインターフェイスを使用したデータのロード](https://docs.snowflake.com/ja/user-guide/data-load-web-ui)

            > ウェブインターフェイスを使用して、最大サイズ 250MB のファイルからデータをロードできます。

        - [拡大された最大ファイルサイズ —-- 一般公開](https://docs.snowflake.com/ja/release-notes/2024/ui/2024-02-14#larger-maximum-file-size-general-availability)

            > 2024年2月15日 --- Snowsightリリースノート
            > ...
            > Snowflakeは、以下のユースケースで最大ファイルサイズを`50MBから250 MBに拡大`しました。
            > - Snowsightを使用したデータのロード。
            > - 名前付き内部ステージにファイルをアップロードする.


    - これはシンプルにありがたい
    - 嬉しい変更であっても、資格試験で問われやすい数値だと仕様変更の度に回答が変わってきたりもする
    - この手のアップロード制限は、実務上引っかかりやすいポイントなので緩和される分にはWelcome

## 60

大体は[`1`にまつわる数値](https://qiita.com/fkdfkdfkd/items/2b7a5107c56246627c3d#1)として以前記載してまとめていたため、ここでは書いてなかったもの(60のキーワードで引っかかるもの)を書いておきます。

ドキュメント上、単位の表記は複数記載しておいて欲しいなぁと思いつつも、内部的に設定可能な単位とかに依存して秒表記なのか分表記なのかが変わったりするのかなぁ...という想像はしました。(あるいは筆者の感覚とか？)


- 60秒 (1分) (仕様)
    - [Python UDF CREATE FUNCTION commands fail with 'Loading function timed out after 60 seconds'](https://community.snowflake.com/s/article/Python-UDF-creation-fails-with-load-timeout-error)

        > Example Error:
        > Loading function timed out after `60 seconds` in function <Function Name> with handler <Handler>
        > ...
        > The default timeout value for loading the Python UDF is `60 seconds`.


    - Python UDF をロードするためのデフォルトのタイムアウト値は 60秒とのこと
    - 忘れた頃にこれに引っかかる可能性はありそう
    - 解決方法としては...
        - コードを確認して再設計
        - 60秒内にコードがロードおよびコンパイルされるようにする

    - [キーペア認証: トラブルシューティング - JWT_TOKEN_INVALID_ISSUE_TIME](https://docs.snowflake.com/ja/user-guide/key-pair-auth-troubleshooting#jwt-token-invalid-issue-time)

        > JWT トークンが発行時刻から`60秒`以上経ってからSnowflakeによって受信されました。
        > ...
        > JWT トークンがトークンの発行時刻から`60秒`以上経過してからSnowflakeによって処理される原因となっている過剰なネットワーク遅延があるかどうかを確認します。

    - 忘れた頃に、あるいは環境を変えた時に急に出るかもしれない
        - IPが変わったとか、VPNまわりとか...等
    - こちらの投稿も要確認
        - [Key Based Authentication Failed with "JWT token is invalid" Error](https://community.snowflake.com/s/article/Key-Based-Authentication-Failed-with-JWT-token-is-invalid-Error)

## 64

- 64日 (仕様)
    - [データのロード - メタデータのロード](https://docs.snowflake.com/ja/user-guide/data-load-considerations-load#load-metadata)

        > Snowflakeは、データがロードされる各テーブルの詳細なメタデータを保持します。
        > ...
        > このロードメタデータは`64日`後に期限切れになります。ステージングされたデータファイルの LAST_MODIFIED の日付が`64日`以下の場合、 COPY コマンドは特定のテーブルのロードステータスを判断し、再ロード（およびデータの重複）を防ぐことができます。LAST_MODIFIED の日付は、ファイルが最初にステージングされたときまたは最後に変更されたときのどちらか遅い方のタイムスタンプです。

    - 同じファイルを再ロードする時の考慮点になる
    - 同じページに記載の[回避策](https://docs.snowflake.com/ja/user-guide/data-load-considerations-load#workarounds)は必読

        > ステージングされたファイルの LAST_MODIFIED の日付が64日を超えます。
        > ...
        > ファイルのロードが成功した場合のロードメタデータの有効期限が切れます。
        > ...
        > 同じテーブルにファイルを再ロードしようとします。
        > COPY コマンドはファイルが既にロードされているかどうかを判断できないため、ファイルはスキップされます。
        > ファイルをロードするには、 LOAD_UNCERTAIN_FILES コピーオプション（または FORCE コピーオプション）が必要です。


## 72

- 72時間 (仕様)
    - [Amazon SNS トピックのサブスクリプションが削除された後に、Snowpipeによるファイルの読み込みが停止する](https://docs.snowflake.com/ja/user-guide/data-load-snowpipe-ts#snowpipe-stops-loading-files-after-amazon-sns-topic-subscription-is-deleted)

        > - SNS トピックサブスクリプションが削除されてから`72時間`待ちます。
        > - `72時間`後、Amazon SNS は削除されたサブスクリプションをクリアします。
        > - トピックを参照するパイプを再作成します（CREATE OR REPLACE PIPE を使用）。パイプ定義で同じ SNS トピックを参照します。
        > - SNS トピックサブスクリプションの削除前に機能していたすべてのパイプが、S3からのイベントメッセージの受信を再開するはずです。
        > `72時間`の遅延を回避するために、別の名前で SNS トピックを作成できます。

    - 72時間待つ、というのは忘れそうだが、トラブルシューティングを問われる時にポイントになってくる要素
    - 実務的には別名で作った方が早いのでそっちになりそうな気がする

## 90

- 90日 (最大)
    - [MAX_DATA_EXTENSION_TIME_IN_DAYS](https://docs.snowflake.com/ja/sql-reference/parameters#max-data-extension-time-in-days)

        > Snowflakeがテーブルのデータ保持期間を延長して、テーブル上のストリームが古くなるのを防ぐことができる最大日数。
        > ...
        > 0 から 90 （つまり、`90日`）--- 0 の値は、データ保持期間の自動延長を無効にします。

    - [Time Travelの理解と使用 - データ保持期間](https://docs.snowflake.com/ja/user-guide/data-time-travel#data-retention-period)

        > 永続データベース、スキーマ、およびテーブルの場合、保持期間は0から90日までの任意の値に設定できます

    - [DATA_RETENTION_TIME_IN_DAYS](https://docs.snowflake.com/ja/sql-reference/parameters#data-retention-time-in-days)

        > Snowflakeがオブジェクトに対してTime Travelアクション（SELECT、CLONE、UNDROP）を実行するための履歴データを保持する日数です。
        > ...
        > 0 または 1 （ Standard Edition の場合）
        > 0 ～ `90` （ Enterprise Edition以上 の場合）

    - 保持期間に関連して出てくる数値で、非常に重要

- 90日 (仕様)
    - [組織を使い始める - 組織の名前の変更](https://docs.snowflake.com/ja/user-guide/organizations-gs#changing-the-name-of-your-organization)

        > Snowflake サポートに連絡する際、ユーザーが元の アカウント URL を使用して組織内のアカウントに一時的にアクセスできるかどうかを決定する必要があります。元のアカウント URL を保持する場合、`90日`後に自動的にドロップされるため、その時点でユーザーは新しいアカウント URL を使用してアカウントにアクセスする必要があります。`90日`の期限の前にアカウント URL をドロップする場合は、 組織 URL の削除 をご参照ください。

    - [アカウント URLs の管理](https://docs.snowflake.com/ja/user-guide/organizations-manage-accounts-urls#label-drop-org-access-url)

        > 組織の変更
        > Snowflakeサポートがアカウントの組織を変更する場合、元のアカウント URL を保存または削除できます。保存された場合、元の URL は「旧組織 URL」と呼ばれます。この URL は`90日`間アカウントにアクセスするために使用でき、その後削除されます。
        > 
        > 元の URL が保存されており、`90日`が経過する前に削除する場合は、 組織 URL の削除 をご参照ください。

    - 実務では非常に重要なポイント
    - 組織名変更は業務都合で発生し得るため、変更前の旧URLの有効期間は意識しておかないと、突如Snowflakeに接続できない！となってビックリすることになる
- 90日 (デフォルト)
    - [CREATE PASSWORD POLICY - オプションのパラメーター](https://docs.snowflake.com/ja/sql-reference/sql/create-password-policy#optional-parameters)

        > PASSWORD_MAX_AGE_DAYS = integer
        > 
        > パスワードの変更が必要になるまでの最大日数を指定します。
        >
        > デフォルト: `90`。これは、`90日`ごとにパスワードを変更する必要があることを意味します。

    - 一般的によく言われている推奨日数がデフォルトになっている

## 100

- 100アカウント (仕様,デフォルト)
    - [アカウントの作成](https://docs.snowflake.com/ja/user-guide/organizations-manage-accounts-create)

        > 新しいアカウントの作成またはアクセスに問題がある場合は、次を検討します。
        > デフォルトでは、組織内のオンデマンドの最大アカウント数は25件です。組織が容量契約を結んでいる場合、デフォルトの最大アカウント数は`100件`です。これらの制限を引き上げるには、 Snowflakeサポート にご連絡ください。

    - 比較的大きな組織だとアカウント数が100は達する可能性がありそう
    - サポートに問い合わせることでこの制限は突破できる

- 100行 (デフォルト)
    - テーブル関数を実行した時、デフォルトで返却される行数としてよく出てくる
    - 例 : [TASK_HISTORY](https://docs.snowflake.com/ja/sql-reference/functions/task_history)

        > RESULT_LIMIT => integer
        > 関数によって返される行の最大数を指定する数です。
        > ...
        > デフォルト: 100。
    - [COPY_HISTORY](https://docs.snowflake.com/ja/sql-reference/functions/copy_history)とかはまた違った仕様になっている

- 100人 (仕様,最大)
    - [Okta error Requested number of membership exceeded the max limit 100](https://community.snowflake.com/s/article/Okta-error-Requested-number-of-membership-exceeded-the-max-limit-100)

        > Pushing a group from OKTA with over `100` users to Snowflake will error with the message: "Errors reported by remote server: Requested number of membership exceeded the max limit `100`"

- 100テーブル (仕様,最大)
    - [Unable to create a stream on a view due to limit of max number of base tables - more than the limit of 100](https://community.snowflake.com/s/article/Unable-to-create-a-stream-on-a-view-due-to-hitting-the-max-number-of-base-tables)

        > This error is due to hitting the maximum number of base tables allowed for a stream.
        > The limit of `100` base tables is intended for controlled memory management and to avoid memory issues in the cloud services layer due to the high number of tables.

    - ["SQL compilation error: Dynamic Table has too many inputs, limit is 100, saw xxx." when creating a Dynamic Table containing more than 100 inputs](https://community.snowflake.com/s/article/This-KB-article-provides-a-solution-to-the-error-when-using-more-than-100-input-tables-in-a-single-Dynamic-Table-statement)

        > This error occurs when there are more than `100` tables included in a single Dynamic Table's DDL since there is currently a limit of a total of `100` tables/inputs, out of which there can be a maximum of 10 Dynamic tables while others can be standard tables.

    - [動的テーブルの既知の制限](https://docs.snowflake.com/ja/user-guide/dynamic-tables-limitations)

        > 動的テーブルの定義:
        > - 100個を超えるテーブルをクエリすることはできません。

    - そんな無茶な設定はしないのでは...と思いがちだが、コードでリソースを管理していて、パラメータ注入で機械的に処理を実行していると知らない間に超えてしまうかもしれない
    
- 100個,100タスク (仕様,最大)
    - [タスクの紹介 - タスクグラフ](https://docs.snowflake.com/ja/user-guide/tasks-intro#task-graphs)

        > 新しいタスクを作成するとき（CREATE TASK ... AFTER を使用）またはそれ以降（ALTER TASK ... ADD AFTER を使用）に先行タスクを指定できます。タスクグラフは、合計で最大1000タスク（ルートタスクを含む）に制限されます。単一のタスクには、最大`100個`の先行タスクと`100`個の子タスクを含めることができます。

    - タスクの実行制限で、先行タスクや子タスクの最大値
    - システムが徐々に肥大化した時等、忘れた頃に引っかかる可能性がありそう

- 100〜250MB, 100GB未満 (推奨値)
    - [データファイルの準備 - 一般的なファイルサイズの推奨事項](https://docs.snowflake.com/ja/user-guide/data-load-considerations-prepare#general-file-sizing-recommendations)

        > 並行して実行されるロード操作の数は、ロードされるデータファイルの数を超えることはできません。ロードの並列操作の数を最適化するには、 圧縮された データファイルのサイズをおよそ`100から250MB`（またはそれ以上）にすることをお勧めします。
        > ...
        > 注釈
        > 非常に大きなファイル（例: `100GB` 以上）をロードすることはお勧めしません。

    - ロード時の留意点として重要
    - 水平スケールを生かしてロードすることが推奨されている
    - 小さすぎる or 大きすぎるファイル1つで何度も検証しているとコンピューティングリソースのクレジットも気になりそう

--- 

100まできた!

以降は粒度がさらに荒くなりますが、ご了承ください...

## 128

- 128 (制限)
    - [ログおよびトレースの概要 - ログメッセージとトレースイベントを比較する](https://docs.snowflake.com/ja/developer-guide/logging-tracing/logging-tracing-overview#compare-log-messages-and-trace-events) 

        > トレースイベント
        > 数量制限
        > スパンあたりのトレースイベント数の上限は`128`です。スパン属性の数にも制限があります。

    - トレースイベント使う時は気にしておかないと...ログは思いの外大量に吐かれそうなので、知らないうちに上限突破していてちゃんと記録されてない、みたいなことが起こりそう
- 128bit (デフォルト)
    - [データロード機能の概要 - ステージングされたファイルの暗号化](https://docs.snowflake.com/ja/user-guide/intro-summary-loading#encryption-of-staged-files)

        > 暗号化されていないファイル
        > 
        > データのロードおよびアンロード操作のために内部ステージに格納されているすべてのファイルは、サーバー側で AES-256の強力な暗号化を使用して自動的に暗号化されます。デフォルトでは、Snowflakeは`128ビット`のキー（オプションで256ビットのキーを構成可能）による追加のクライアント側の暗号化を提供します。

    - [CLIENT_ENCRYPTION_KEY_SIZE](https://docs.snowflake.com/ja/sql-reference/parameters#client-encryption-key-size)

        > SNOWFLAKE_FULL 暗号化タイプを使用する際は、Snowflakeが内部ステージ（データのロード/アンロード用）に保存されているファイルを暗号化/復号化するために使用する AES 暗号化キーサイズをビット単位で指定します。
        > 
        > 値 `128` または 256
        > デフォルト `128`

    - ファイルの暗号化方式で指定できるbit数(128か256)

## 130

- 130個 (仕様)
    - [Snowflake Native App の更新とアップグレード - バージョンおよびパッチについて](https://docs.snowflake.com/ja/developer-guide/native-apps/versioning#about-versions-and-patches)

        > 注釈
        > 1つのバージョンは最大130個のパッチを含むことができます。

    - Native Applicationのpatchの上限数
    - デプロイを自動化していると、開発・検証中に自然と超えてきそうな値
    - 超えるならバージョン自体をあげるか、破棄して再度0から始めるか、あたりか
    - なぜ130なのか

## 250

- 250MB (仕様,最大)
    - [ウェブインターフェイスを使用したデータのロード](https://docs.snowflake.com/ja/user-guide/data-load-web-ui#prerequisites-for-loading-data)

        > ウェブインターフェイスを使用して、最大サイズ`250MB`のファイルからデータをロードできます。より大きなファイルまたは多数のファイルをロードするには、Snowflakeクライアント SnowSQL を使用します。

    - csvとかをアップロードする時は、圧縮しておく方がより多くのデータをアップロードできる

## 256

- 256bit (オプション)
    - [CLIENT_ENCRYPTION_KEY_SIZE](https://docs.snowflake.com/ja/sql-reference/parameters#client-encryption-key-size)

        > SNOWFLAKE_FULL 暗号化タイプを使用する際は、Snowflakeが内部ステージ（データのロード/アンロード用）に保存されているファイルを暗号化/復号化するために使用する AES 暗号化キーサイズをビット単位で指定します。
        > 
        > 値 128 または `256`

    - ファイルの暗号化方式で指定できるbit数(128か256)
    - 特に指定しなければデフォルトの128bitになる
    - 256bitを使用する場合は以下の注釈がある

        > 注釈
        >
        > - JDBC ドライバーを使用しており、このパラメーターを256（強力な暗号化用）に設定する場合、追加の JCE ポリシーファイルをデータのロード/アンロード元の各クライアントマシンにインストールする必要があります。必要なファイルのインストールの詳細については、 JDBC ドライバーのJava要件 をご参照ください。
        > - Pythonコネクタ（または SnowSQL）を使用しており、このパラメーターを256（強力な暗号化用）に設定する場合、追加のインストールまたは構成タスクは必要ありません。
- 256バイト,256文字 (仕様,最大)
    - [SET - 使用上の注意](https://docs.snowflake.com/ja/sql-reference/sql/set#usage-notes)

        > 文字列変数またはバイナリ変数のサイズは256バイトに制限されています。
        > SQL 変数の識別子（つまり、名前）は256文字に制限されています。

    - 長い文字列をセッションパラメータに設定しようとして引っかかる可能性がある
    - [CREATE PASSWORD POLICY - オプションのパラメーター](https://docs.snowflake.com/ja/sql-reference/sql/create-password-policy#optional-parameters)

        > PASSWORD_MIN_LENGTH = integer
        > パスワードに含める必要がある最小文字数を指定します。
        > サポートされている範囲は8から`256`までです。
        > デフォルト: 8
        > ...
        > PASSWORD_MAX_LENGTH = integer
        > ...
        > サポートされている範囲は8から256までです。
        > デフォルト: `256`
        > ...

    - パスワードの文字数も256文字がMAX

- 256MB, 256-512MB (推奨値)

    - [外部テーブルの概要 - 一般的なファイルサイズの推奨事項](https://docs.snowflake.com/ja/user-guide/tables-external-intro#general-file-sizing-recommendations)

        > |形式|推奨サイズの範囲|
        > |-|-|
        > |Parquetファイル|   `256` - `512` MB|
        > |Parquet列グループ| 16 - `256` MB|
        > |サポートされている他のすべてのファイル形式 | 16 - `256` MB|

    - 外部テーブルをスキャンする時のParquetファイルのサイズの推奨値として出てくる
    - 他も〜256MBが推奨値になっている

## 429

- 429 (エラーコード,仕様)
    - リクエスト制限に引っかかった時に出るエラーコード
    - 特にSnowpipeのエンドポイント(loadHistoryScan)に関して資格試験で問われがちなので覚えとくと有利
    - [Snowpipe REST API - エンドポイント: loadHistoryScan](https://docs.snowflake.com/ja/user-guide/data-load-snowpipe-rest-apis#endpoint-loadhistoryscan)

        > このエンドポイントは、過剰な呼び出しを避けるためにレート制限されています。レート制限（エラーコード`429`）を超えないようにするため、 loadHistoryScan よりも insertReport に強く依存することをお勧めします。 loadHistoryScan を呼び出すとき、データロードのセットを含む最も狭い時間範囲を指定します。たとえば、履歴の最後の10分を8分ごとに読むとうまくいきます。毎分過去24時間の履歴を読み取ろうとすると、レート制限に達したことを示す`429`エラーが発生します。レート制限は、各履歴記録を数回読み取ることができるように設計されています。

## 500

- 500同時リクエスト/アカウント (仕様)
    - [SnowflakeとのOkta SCIM 統合 - 制限事項](https://docs.snowflake.com/ja/user-guide/scim-okta#limitations)

        > Snowflakeは、SCIMエンドポイント（例えば、 /Users エンドポイント、 /Groups エンドポイント）ごとに、アカウントにつき最大`500`の同時リクエストをサポートします。

## 512

- 512クレジット (最大)
    - [ウェアハウスサイズ](https://docs.snowflake.com/ja/user-guide/warehouses-overview#warehouse-size)
    - 2024/7時点での最大サイズである6XLのクレジット/時
    - 今後、1024クレジット/時 のウェアハウス(7XL?)が登場するのかは未知

## 786

- 786クレジット (最大)
    - [Snowpark用に最適化されたウェアハウスの請求](https://docs.snowflake.com/ja/user-guide/warehouses-snowpark-optimized#billing-for-snowpark-optimized-warehouses)
    - 2024/7時点でのSnowpark用のウェアハウスの最大サイズである6XLのクレジット/時
    - 標準ウェアハウスの6XLのクレジット+256
    - 高い...

## 999

- 999日 (最大)
    - [CREATE PASSWORD POLICY - オプションのパラメーター](https://docs.snowflake.com/ja/sql-reference/sql/create-password-policy#optional-parameters)

        > PASSWORD_MIN_AGE_DAYS = integer
        >
        > 最近変更したパスワードが再度変更できるようになるまでの日数を指定します。
        > サポートされている範囲は0から`999`までです。
        > ...
        > PASSWORD_MAX_AGE_DAYS = integer
        > パスワードの変更が必要になるまでの最大日数を指定します。
        > サポートされている範囲は0から`999`までです。

    - パスワード変更までの猶予期間として設定できる最大日数
    - 0を指定すると無期限となるが、指定できる最大値として999に何らかの意味があるのかは不明
    - 非常にインパクトのある数値なので、一見で覚えられそう(ただし、あまり活用する場面はなさそう)

## 1000

- 1000個, 1000タスク (仕様,最大)
    - [タスクの紹介 - タスクグラフ](https://docs.snowflake.com/ja/user-guide/tasks-intro#task-graphs)

        > 新しいタスクを作成するとき（CREATE TASK ... AFTER を使用）またはそれ以降（ALTER TASK ... ADD AFTER を使用）に先行タスクを指定できます。タスクグラフは、合計で最大`1000タスク`（ルートタスクを含む）に制限されます。

    - 同時並行で実行できるタスクは1000タスクが上限ということ

- 1000ファイル (仕様,最大)
    - [COPY INTO <テーブル> - オプションのパラメーター](https://docs.snowflake.com/ja/sql-reference/sql/copy-into-table#optional-parameters)

        > ロードする1つ以上のファイル名のリスト（コンマで区切る）を指定します。ファイルは、コマンドで指定されたSnowflake内部の場所または外部の場所のいずれかに既にステージングされている必要があります。指定されたいずれのファイルも見つからない場合は、 COPY ステートメントで別の ON_ERROR オプションが明示的に設定されていない限り、デフォルトの動作 ON_ERROR = ABORT_STATEMENT はロード操作を中止します。
        > 指定できるファイル名の最大数は`1000`です。

    - 複数ファイルを指定すると並行ロードできるのでおすすめされる一方で、パラメータ背指定できるファイル名は最大1000個まで
    - これもプログラム経由で機械的にファイル名を注入していると、いつの間にか1000に達している可能性がありそうなので要注意

## 1024

- 1024バイト (仕様,最大)
    - [Snowpipe REST API - エンドポイント： insertFiles](https://docs.snowflake.com/ja/user-guide/data-load-snowpipe-rest-apis#endpoint-insertfiles)

        > 注釈
        > ...
        > - 指定された各ファイルパスは、 UTF-8としてシリアル化される場合、<= `1024`バイトの長さである必要があります。

    - Snowpipeのエンドポイント insertFilesの2つの制限のうちの一つ

## 2000

- 2000文字 (仕様, 最大)
    - [QUERY_TAG](https://docs.snowflake.com/ja/sql-reference/parameters#query-tag)

        > データ型 文字列（最大2000文字）
        > 説明
        > セッション内で実行されるクエリおよびその他の SQL ステートメントのタグ付けに使用できるオプションの文字列です。

    - QUERY_HISTORYに表示されるクエリタグの文字数が2000文字まで
    - タグとしてはかなり余裕がある文字数ではなかろうか

## 2048

- 2048bit (最小,仕様)
    - [Kafkaコネクタのインストールと構成 - キーペア認証の使用およびキーローテーション](https://docs.snowflake.com/ja/user-guide/kafka-connector-install#using-key-pair-authentication-key-rotation)

        > Kafkaコネクタは、基本認証（つまり、ユーザー名とパスワード）ではなく、キーペア認証に依存しています。この認証方法には、`2048`ビット（最小）の RSA キーペアが必要です。 OpenSSLを使用して公開キーと秘密キーのペアを生成します。公開キーは、構成ファイルで定義されたSnowflakeユーザーに割り当てられます。

    - Kafka関係の話題は実務で多分使うケースがないイメージがありつつ、資格試験ではよく問われるイメージがある
    - Kafkaコネクタの認証にはキーペアを用い、その鍵長は2048bit〜を用いる

## 5000

- 5000個 (最大)
    - [Snowpipe REST API - エンドポイント： insertFiles](https://docs.snowflake.com/ja/user-guide/data-load-snowpipe-rest-apis#endpoint-insertfiles)

        > 注釈
        > - 投稿には最大`5000個`のファイルを含めることができます。

    - Snowpipeのエンドポイント insertFilesの2つの制限のうちの一つ

## 10000

- 10000行 (仕様)
    - [ワークシートの結果の調査](https://docs.snowflake.com/ja/user-guide/ui-snowsight-query#exploring-the-worksheet-results)

        > ワークシートで1つまたはすべてのクエリを実行すると、クエリ結果が表示されます。
        > クエリ結果は、最大10,000行のテーブルとして表示されます。クエリが10,000行を超える行を返す場合は、 Download results オプションを使用してすべての結果を表示します。

        SQLワークシートの使用上の注意点でもある。
        Snowsight(Web UI)で全部のクエリ結果を見るには限界があるということ。
        クエリ条件を駆使して表示数を絞るか、手元で全件データを見たいならダウンロードもしくはアンロードして手元で確認する必要がある

    - ...が、これは少し前までの使用っぽく、[英語のマニュアル](https://docs.snowflake.com/en/user-guide/ui-snowsight-query#exploring-the-worksheet-results)によると、現在はこの制限が取っ払われているように見える

        > Available to most accounts. Accounts in U.S. government regions, accounts using Virtual Private Snowflake (VPS), and accounts that use Private Connectivity to access Snowflake continue to see query results limited to 10,000 rows.

        一部のアカウントでは10,000行と書いてあり、それ以外は...無制限？
        試してみた。

        ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/617410/aaff72ea-aaac-e17e-e7b5-24ee4d92cac2.png)

        すごい。600万行の結果がSnowsight上で見えるようになっている。

- 10000件 (10K) (仕様,最大)
    - [Snowpipe REST API - エンドポイント: loadHistoryScan](https://docs.snowflake.com/ja/user-guide/data-load-snowpipe-rest-apis#endpoint-loadhistoryscan)

        > 内容がテーブルに追加されたインジェスト済みファイルに関するレポートをフェッチします。大きなファイルの場合、レポートはファイルの一部のみの場合があります。このエンドポイントは、2つの時点間の履歴を表示するという点で insertReport と異なります。最大`10,000個`のアイテムが返されますが、複数の呼び出しをパブリッシュして、目的の時間範囲をカバーできます。


    - insertReport Snowpipeエンドポイントから取得できるのは最新の10,000件のイベント
    - それ以上取得したい場合はCOPY_HISTORYテーブル関数を使う
    - [TASK_HISTORY](https://docs.snowflake.com/ja/sql-reference/functions/task_history)等で、テーブル関数の結果に指定できる最大行数

        > RESULT_LIMIT => integer
        > 
        > 関数によって返される行の最大数を指定する数です。
        > 一致する行の数がこの制限よりも大きい場合、指定された制限まで、最新のタイムスタンプを持つタスク実行が返されます。
        > 範囲： 1 ～ `10000`

    - [SHOW TASKS - 使用上の注意](https://docs.snowflake.com/ja/sql-reference/sql/show-tasks#usage-notes)

        > LIMIT rows の値は `10000` を超えることはできません。 LIMIT rows が省略され、結果セットが`10K`行より大きい場合、コマンドはエラーになります。

    - SHOW系コマンドの表示件数もこの10000が上限の模様
    - 10000を超えるデータがあるとしてその結果を表示するには、 Snowflake Information Schemaで対応するビューをクエリして情報を得る

## おわりに

10以降の数値をまとめてみました。

何か制限あったっけ？みたいな時に、頭の片隅で引っかかるきっかけになればいいなぁという感じで書きました。

引き続きこれは...と思った数値があればひっそり更新したなと思います。

以上です。