NotionとSuper.soによるWebサイト構築を支援していくなかで、クライアント様から「数万件のデータを追加していく場合、Notionの表示速度・パフォーマンスは大丈夫そうでしょうか？」とのご指摘をいただきました。
そこでNotion APIを利用してプログラムによって20,000件程度のレコードをサンプルとして追加、他データベースとの紐づけも実施してみて、大量データにおけるNotionのパフォーマンスチェックを行いました。本記事ではテスト結果とNotionのパフォーマンス要因について解説します。
目次:
Notionのパフォーマンスについて+大量投稿でテスト
Notionにおけるデータベースのパフォーマンス低下要因
Notionにおけるデータベースのパフォーマンス要因としては、レコード数、カラム数、リレーション情報などが主としてパフォーマンス低下要因となりうるようでした。特に、下記が懸念事項として挙げられることが多いようです。
- リレーションカラムの数
- 他テーブルと複数のリレーションを作成（他テーブル上の複数レコードとの紐づけ）
- カラムの数、カラム内の情報量
- レコード数
Web上でもリレーション付きのテーブルで数千程度のレコードを入稿した、などの情報はありましたが、さすがに2列以上のリレーションカラム付きで数万件のレコードを入稿してみた、といったような情報を見つけることはできませんでした。
20,000件のレコードをリレーション付きで投稿。DB構成と公開テストページ
そのため、以下のような3つのデータベースを作成し、Notionのパフォーマンステストを実施してみました。
- 元DB（20,000件程度のレコード、他2つのDBとのリレーション設置）
- リレーション先DB_A（20レコード。元DBに紐づけるタグのような扱い）
- リレーション先DB_B（26レコード。元DBに紐づけるタグのような扱い）
参考記事: Notion APIで大量のページをリレーション付きで一括投稿する
参考のため、同構成にてテスト利用したページおよびDBを公開いたします。
Notionパフォーマンステスト（Notionページが開きます）
ただし、上記ページはNotionによってホストされたWebページで公開しておりますため、実際のNotionアプリ上でのパフォーマンスとは大きく異なります。（実際のアプリのほうが遥かに速いです）
テスト結果: 数万レコードをリレーション付きで入稿しても全く問題ない
結論として、利用のためのパフォーマンスとしては全く問題ありませんでした！
各DBの比較としては20,000レコードを入稿した元DBがもっとも動作が軽く、少ないレコード数で元DBへの紐づけを複数実施したリレーション先DBのほうがやや挙動が重い、という結果となりました。
Plusプラン（個人）, Notionダウンロードアプリ, WiFi回線, M2 MacBookといった環境においては、元DBのページを開くまで約1秒、リレーション先DBを開くのに約2〜3秒程かかる、という程度。使用の支障とはなりませんでした。
推察ですが、Notionはタテの読み込み（レコード）とカラム内の内容について一定の表示制限をかけているようです。
レコードについては、一旦は画面上に表示される程度のレコードを取得・表示し、スクロールによって続くレコードを一定量取得するような挙動となっています。
SQLにおけるLIMIT句のようにして随時取得するような挙動となっているようです。
リレーション先DBのほうが遅いという結果になったのは、1つのカラム内に数千程度のリレーション先が設置される結果となったため、
ただし、カラム内の情報も膨大な場合は一定量のみの表示として制限され、詳細はページ内で確認できるように制限されています。（一部表示+詳細ボタン）
Notionパフォーマンスについての補足注意
- Notion自体のパフォーマンスはダウンロードアプリ上のほうが優れており、ブラウザからの動作ではやや重くなります。
- パフォーマンスはご使用のPC、回線速度によっても異なります。
- Notionダウンロードアプリ上で複数タブを開いた場合、パフォーマンスが大きく下がります。ご利用時は単一タブにてご利用ください。
Category: Notion
Tags: SaaS
この記事の気になる箇所を読み返す：
