Local blog for Japanese speaking developers
Cloud Firestore のクエリが遅くなる理由
2019年10月28日月曜日
この記事は Todd Kerpelman(Developer Advocate) による The Firebase Blog の記事 "
Why is my Cloud Firestore query slow?
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Cloud Firestore のパフォーマンスについては、「ベースのデータセットではなく結果セットのサイズに比例して高速化する」、「低速のクエリを作成するのは実質的に不可能だ」など、その素晴らしさを評価する声がよく聞かれます。そしてほとんどの場合、それは事実です。アプリでは莫大な数のレコードが格納されたデータセットに対するクエリを実行し、ユーザーが画面から親指を離すよりも早く結果を取得できます。
とは言え、デベロッパーからは「特定の状況では Cloud Firestore の動作が遅く感じられ、クエリの結果を取得するのに予想よりも時間がかかる」という意見を聞くこともあります。それはなぜでしょうか。今回は、Cloud Firestore の動作が遅くなったように見える場合に考えられる原因と、その対処方法をご紹介します。
理由その 1: データが多すぎる
クエリが遅くなったと感じる場合に第一に考えられる原因としてクエリ自体は非常に高速に実行されているのですが、クエリが完了した後にすべてのデータをデバイスに転送する必要があり、実際にはその処理に時間がかかっているのです。
たとえば、組織内の全営業担当者を対象にしたクエリを実行するとしましょう。このクエリは非常に高速に実行されます。しかし、その結果セットが 2,000 人の従業員のドキュメントで構成されていて、各ドキュメントに 75 KB のデータが含まれていたらどうでしょう。デバイスでは 150 MB のデータをダウンロードする必要があり、それが完了するまで結果は確認できません。
パフォーマンスを改善するには
この問題を解決するには、必要なデータ以外は転送しないようにするとよいでしょう。簡単なのは、クエリに制限を追加する方法です。従業員リストの結果のうち、ユーザーが必要なのは先頭のごく一部だけだと思われる場合は、クエリの最後に limit(25) を追加すれば、最初の方のデータのみダウンロードされ、その他のレコードはユーザーがリクエストした場合に限りダウンロードされるようにすることができます。これについては
こちらの動画
で詳しく説明していますので、ぜひご覧ください。
一方、営業担当者 2,000 人全員のデータをクエリで取得する必要があると考える場合は、別の方法があります。最初のクエリで取得したいデータのみを含むドキュメントをこれらのレコードから分離し、その他の詳細なデータを含むドキュメントは個別のコレクションまたはサブコレクションにまとめるのです。後者のドキュメントは最初の取得時には転送されませんが、ユーザーの必要に応じて後からリクエストできます。
ドキュメントのサイズを小さくすると他にもメリットがあります。たとえば、クエリにリアルタイム リスナーを設定して、ドキュメントが更新されるとそのドキュメントがデバイスに送信されるようにしたい場合です。ドキュメントのサイズを小さくしておけば、リスナーで変更が発生するたびに転送されるデータの量も少なくなります。
理由その 2: オフライン キャッシュが大きすぎる
Cloud Firestore のオフライン キャッシュはとても優れた機能です。オフラインの永続性を有効にすると、ユーザーがトンネル内に入ったときや飛行機に 9 時間乗っている間でも、アプリはオンラインと「同じように機能」します。つまり、オンライン中に読み取ったドキュメントをオフラインでも利用でき、オフライン中に書き込んだデータは、アプリがオンラインに戻るまでローカルでキューに追加されます。さらに、クライアントの SDK ではこのオフライン キャッシュを利用して、大量のデータがダウンロードされないようにすることができるため、ドキュメントの書き込みなどのアクションを高速化できます。ただし Cloud Firestore は「オフライン優先」のデータベースとして設計されているわけではないので、今のところローカルでの大量のデータの処理には向いていません。
Cloud Firestore はクラウド内で、すべてのコレクションの全ドキュメントとそのフィールドをもれなくインデックスに登録しますが、（現時点では）オフライン キャッシュ用にこうしたインデックスを作成することはありません。つまり、オフライン キャッシュ内のドキュメントにクエリを実行する場合、Cloud Firestore ではクエリ対象のコレクションについて、ローカルに保存されているすべてのドキュメントを展開してからクエリと照合する必要があります。
別の言い方をすれば、バックエンドでのクエリは結果セットのサイズに応じて遅くなりますが、ローカルのオフライン キャッシュ内でのクエリは、クエリ対象のコレクションに含まれるデータのサイズに応じて遅くなります。
ところで、ローカルでのクエリが実際にどの程度遅くなるかは、状況によって異なります。ここで話題にしているのはローカル、つまりネットワークに接続していない状態でのオペレーションですが、これはネットワーク呼び出しを行うよりも速い可能性が（しかもかなりの確率で）あります。ただし、1 つのコレクションに含まれる大量のデータを分類しなければならない場合、あるいは単に動作が遅いデバイスを使用している場合、大きなオフライン キャッシュに対するローカル オペレーションは著しく遅くなる可能性もあります。
パフォーマンスを改善するには
最初に、前のセクションで説明したおすすめの方法を試してみてください。つまり、ユーザーが必要とするデータのみを取得できるようクエリに制限を追加し、不要な細かいデータはサブコレクションに移動することを検討します。また、
以前の投稿
の最後に取り上げた「複数のサブコレクションと単独の最上位コレクション」のどちらを使うべきかという観点で考えた場合、このケースでは「複数のサブコレクション」を採用した方がよいでしょう。そうすれば、キャッシュの検索対象が、こうした小さめのコレクションに含まれるデータのみとなるからです。
2 番目の方法は、必要以上のデータをキャッシュに詰め込まないようにすることです。私は、デベロッパーがキャッシュを意図的にこのように使用するケースをいくつか見たことがあります。アプリの最初の起動時に膨大な数のドキュメントにクエリを実行し、その後のすべてのデータベース リクエストにローカル キャッシュを強制的に参照させるというものです。通常、データベース コストを削減したり、以降の呼び出しを高速化したりする目的で用いられますが、実際にはメリットよりデメリットの方が大きい場合がほとんどです。
3 番目の方法は、オフライン キャッシュのサイズを小さくすることです。モバイル デバイスのキャッシュのサイズはデフォルトで 100 MB に設定されていますが、状況によっては（特に、大規模な 1 つのコレクションにほとんどのデータが格納されている場合は）、このサイズではデータが多すぎてデバイスで処理できない可能性があります。このサイズは、Firebase の設定で
cacheSizeBytes
の値を変更することで調整できます。特定のクライアントに対してサイズを調整するとよいでしょう。
4 番目に、
永続性を完全に無効にして
、何か変化があるか確認してみてください。この方法は通常はおすすめしません。前に述べたように、オフライン キャッシュは非常に優れた機能だからです。それでも、クエリが遅くなったように感じて、その理由がわからない場合は、永続性を無効にしてアプリを再実行することでキャッシュが問題の原因かどうかを判断できるでしょう。
理由その 3: ジグザグマージ結合に問題がある
「ジグザグマージ結合」という名前を私が個人的に気に入っていることはさておき、このアルゴリズムは複合インデックスに依存せずに複数のインデックスからの結果を統合できる点で非常に便利です。基本的には、ドキュメント ID 順に並べ替えた 2 つ（またはそれ以上）のインデックス間を行き来して一致を見つける仕組みになっています。
しかし、ジグザグマージ結合にも 1 つ弱点があります。どちらの結果セットもサイズが大きいにもかかわらず両者の共通部分が少ないと、パフォーマンスの問題が発生する場合があるのです。一例として、カウンター サービスも提供している高級レストランを検索するクエリを考えてみましょう。
restaurants.where('price', '==', '$$$$').where('orderAtCounter', '==', 'true')
両方ともかなり大きいグループですが、共通部分はおそらくほとんどありません。この場合、ジグザグマージ結合では、必要な結果を取得するために多くの検索を行う必要があります。
クエリのほとんどが高速に実行されているのに、特定のクエリを複数のフィールドに対して一度に実行している最中に遅くなる場合は、この状況に陥っている可能性があります。
パフォーマンスを改善するには
複数のフィールドにわたるクエリがが遅くなる場合、それらのフィールドに対する
複合インデックス
を作成することでパフォーマンスを改善できます。バックエンドでは、その後のすべてのクエリで、ジグザグマージ結合ではなくこの複合インデックスを使用するようになります。つまり、クエリは結果セットのサイズに比例して高速になるということです。
理由その 4: Realtime Database に慣れてしまっている
Cloud Firestore は、クエリ機能、信頼性、スケーラビリティの点で Firebase Realtime Database を上回ります。ただし北米で利用する場合は、一般に Realtime Database の方が低レイテンシです。通常はそれほど大きな差はなく、チャットアプリなどでは違いに気付くことはおそらくないでしょう。しかし、データベースの超高速応答に依存するアプリ（たとえばリアルタイム描画アプリやマルチプレーヤー型ゲームなど）の場合は、Realtime Database の方が「まさにリアルタイム」だと感じられるかもしれません。
パフォーマンスを改善するには
Realtime Database の低レイテンシが求められるプロジェクトを進めている（かつ、大部分のユーザーが北米にいると予想される）場合、もし Cloud Firestore の特有の機能が必要ないのであれば、そのプロジェクトの該当箇所には Realtime Database を使用するとよいでしょう。ただしその前に、
以前のブログ投稿
や
公式ドキュメント
を確認して、2 つのデータベースそれぞれのメリットとデメリットを十分に理解しておくことをおすすめします。
理由その 5: 物理的な制約がある
ほぼ完ぺきな状況であっても、利用している Cloud Firestore インスタンスがオクラホマでホストされていて、ユーザーがニューデリーにいる場合、「光の速度」の関係で少なくとも 80 ミリ秒のレイテンシが発生します。そして現実的に、どのネットワーク呼び出しでも
242 ミリ秒
前後のラウンドトリップ時間がかかります。そのため、Cloud Firestore がどれほど高速に応答しても、その応答が Cloud Firestore とデバイス間を移動する時間がどうしてもかかってしまうのです。
パフォーマンスを改善するには
まず、
単回のフェッチの代わりにリアルタイム リスナーを使用する
ことをおすすめします。クライアントの SDK 内でリアルタイム リスナーを使用すると、非常に優れた多くのレイテンシ補正機能が提供されるためです。たとえば Cloud Firestore は、ネットワーク呼び出しが戻るのを待っている間、キャッシュされたデータをリスナーに提示するため、ユーザーに結果を表示する時間がより高速になります。また、データベースへの書き込みはすぐにローカル キャッシュに適用されます。つまり、デバイスがサーバーによる確認を待っている間に、これらの変更が即座に反映されることがわかるでしょう。
次に、ユーザーの大半が所在する場所でデータをホストするようにします。最初にデータベース インスタンスを初期化する際に
Cloud Firestore のロケーションを選択
できるので、アプリに最適なロケーションはどこか、コスト面だけでなくパフォーマンス面も含めて十分に検討しましょう。
3 番目の方法としては、量子エンタングルメントに基づいた信頼性の高い安価なグローバル通信ネットワークを実装することが挙げられます。これにより、光の速度の問題を回避できるためです。この対応が済めば、おそらくライセンス料の支払いを終わらせることができ、そもそもどんなアプリを作っていたかも忘れてしまうかもしれません。
最後に
今後、Cloud Firestore のクエリが遅く感じる場面に遭遇したときは、上記の内容に目を通していずれかの状況に当てはまるかどうかを確認してください。なお、アプリのパフォーマンスを確認するには、実際の使用環境でのパフォーマンスを測定するのが一番です。この目的に最適なサービスとして、Firebase Performance Monitoring があります。
Performance Monitoring をアプリに統合して、クエリの実際のパフォーマンスを確認できるようカスタム トレースを 1～2 つ設定してみることをおすすめします。
Reviewed by Sophia Hu - Data Management Specialist, Google Cloud
ラベル
.app
1
.dev
1
#DevFest16
1
#DevFest17
1
#DevFest18
1
#DevFest19
1
#hack4jp
3
A/B Testing
1
A4A
4
Actions on Google
16
Activation Atlas
1
Addy Osmani
1
ADK
2
AdMob
31
Ads
47
Ads API
40
AdWords API
11
Agency
1
AI
10
AIY
3
AIY Vision Kit
2
ALPN
1
AMP
83
AMP Cache
6
AMP for Email
3
AMP SSR
1
AMP Story
2
AMP Toolbox
1
amp-bind
1
AMPHTML Ads
1
Analytics
9
Andorid
12
Android
347
Android Auto
1
Android Design Support Library
1
Android Developer Story
4
Android Developers
4
Android Enterprise
5
Android Go
1
Android Jetpack
3
Android N
18
Android O
13
Android P
7
Android Pay
1
Android Q
13
Android Security Year in Review
1
Android Studio
38
Android Support Library
6
Android Things
15
Android TV
10
Android Vitals
3
Android Wear
29
androidmarket
3
AndroidX
5
Angular
2
Angular 2
2
AngularJS
2
AoG
1
API
25
APIExpert
45
apk
2
APM
1
app
3
App Action
1
app engine
23
App Indexing
7
App Invites
6
App Maker
2
AppCompat
2
Apps Script
11
aprilfool
4
AR
2
Architecture Components
7
ARCore
1
ArtTech
1
Associate Android Developer Certificate
1
Audio
7
Auth Code
1
Authentication
8
AuthSub
2
Autofill
1
AutoML
1
Autotrack
2
award
1
Awareness API
1
Beacons
6
Better Ads Standards
1
BigQuery
9
Billing
1
BLE
4
Blink
1
Blockly
1
blogger
1
BodyPix
1
Brillo
1
Brotli
2
Budou
1
Calendar
3
Canvas
1
Cardboard
4
Career
1
Case Study
1
Certificate
2
chrome
126
Chrome Custom Tab
2
Chrome Dev Summit
2
chrome extension
11
Chrome for Android
2
Chrome for iOS
2
Chrome OS
6
Chrome Tech Talk Night
4
Chromebook
3
Chromecast
7
chromewebstore
7
Chromium
5
CLI
1
ClientLogin
3
Closure Compiler
1
Cloud
21
Cloud Firestore
5
Cloud Functions
9
Cloud IoT Device SDK
1
Cloud Next
8
Cloud OnBoard
3
Cloud PubSub
1
Cloud Storage
1
Cloud Study Jams
3
Cloud Summit
1
Cloud Test Lab
2
Cloudflare
1
CNN
1
Coalition for Better Ads
1
CocoaPods
1
codejam
5
codelab
4
Colaboratory
1
Community
3
compute engine
3
Context
1
Cookie
1
Coral
2
Crash Reporting
2
Crashlytics
2
Dart
2
DataCenter
1
Daydream
4
Deep Learning
4
Demo Party
1
Design Sprint
3
DesignBytes
1
DevArt
3
DevBytes
6
Developer
14
Developer Console
4
Developer Preview
6
Developer Relations
2
DevFest
8
DevFestX
3
DevOps
1
devtools
4
Dialogflow
1
Differential privacy
1
DirectShare
1
DNS-over-HTTPS
1
Domain
1
Doodle
1
DoubleClick
4
Doze モード
1
drive
2
Dynamic Links
3
EarlGrey
1
Easter Egg
1
ECMAScript 2015
1
Eddystone
4
egypt
1
Encryption
1
English
2
ES2015
1
ES2016
1
ES6
2
ES7
1
Event
1
Featured
2
Firebase
117
Firebase Admin SDK
6
Firebase Analytics
10
Firebase Auth
4
Firebase Cloud Messaging
10
Firebase Crashlytics
2
Firebase Database
5
Firebase Libraries
1
Firebase Notifications
1
Firebase Performance
3
Firebase Remote Config
5
Flash
1
Flutter
6
font
3
fraud
1
G Suite
18
game
39
Game Developers Conference 2018
1
Game Developers Conference 2019
1
Gboard
1
GCP
13
GCPUG
1
GDD11JP
56
GDD2010JP
23
GDE
2
GDG
18
GDG Cloud
1
Geo
51
Gingerbread
1
GLIDE
5
Gmail
4
Gmail API
2
Go
1
golang
5
goo.gl
1
Google
6
Google Analytics
3
Google API
1
Google Apps
14
Google Apps Script
4
Google Assistant
10
Google Assistant SDK
2
Google Cast
8
Google Cloud
25
Google Cloud INSIDE Digital
1
Google Cloud INSIDE Games & Apps
6
Google Cloud INSIDE Retail
1
Google Cloud Messaging
11
Google Cloud Platform
11
Google Code-in
1
Google Developer Experts
2
Google Developers Academy
1
Google Developers live
5
Google Developers Summit
2
Google Drive
6
Google Earth
1
Google Fit
2
Google for Mobile
2
Google for Work
1
Google I/O
17
Google Impact Challenge
1
Google Maps
59
Google Maps Platform
10
Google ML Summit
1
Google Pay
2
Google Photo
1
Google Play
110
Google Play Console
9
Google Play Game Services
9
Google Play Instant
1
Google Play Services
23
Google Plus
14
Google Search
7
Google Sheets API
3
Google Sign-In
12
Google Slides API
5
Google Summer of Code
1
Google Tag Manager
1
Google Trust Services
1
Google マップ
4
Google+
2
Googleapps
10
GoogleGames
1
GoogleI/O
28
GoogleLabs
1
GooglePlay
1
GoogleTV
1
Gradle
1
gRPC
2
GTUG
5
GWT
2
hack4jp
2
hackathon
7
Hangouts Chat
2
Hosting
3
HTML5
17
HTML5Rocks
1
HTTP/2
5
HTTPS
12
I/O Extended
4
ID Token
1
Identity
15
Identity Toolkit
1
Ignite
4
IME
11
Indie Games Festival 2018
2
Indie Games Festival 2019
12
Inevitable ja Night
25
Instagram
1
Instant Apps
6
intern
2
Invites
1
IO19
3
iOS
20
IoT
6
IPv6
1
Issue Tracker
2
Japanese Input
1
JavaScript
9
Jetpack
1
K-12
1
Key Transparency
1
Knowledge Graph
1
Kotlin
10
Kubernetes
1
l10n
8
LaunchPad
1
Lighthouse
1
LINE
1
Local AI
1
Lollipop
10
Machine Learning
22
Maker Faire Tokyo
1
Marshmallow
10
Material
1
Material Design
30
MDL
1
MDN
1
metrics
1
MIDI
2
ML Kit
11
Mobile
13
Mobile Bootcamp
4
Mobile Sites certification
1
Mobile Vision
4
mod_pagespeed
1
monetize
3
Mozc
15
Music
1
NativeDriver
2
NativeScript
1
NBU
1
ndk
3
Nearby
5
Next Extended
1
Next Tokyo
3
Nexus
2
Nexus S
1
NFC
1
Node.js
3
Noto CJK
1
NPAPI
2
NPN
1
oauth
11
OpenAI
1
opencensus
1
OpenGL
4
OpenID
3
OpenID Connect
4
OpenSocial
1
opensource
17
Optimization
1
Payment
4
PEM
33
People API
2
Performance
12
Performance budget
1
PersonFinder
1
Physical Web
3
Pi
1
Place Picker
1
Play Billing Library
2
Player Analytics
4
Playtime 2017
1
Policy
4
Polymer
7
privacy
4
Progressive Web Apps
14
project hosting
1
Promise
1
Promo code
1
Protocol Buffers
1
PRPL
1
publicdata
1
Push API
1
Push Notification
3
PWA
3
Python
2
QUIC
1
QWIKLABS
3
RAIL
1
React
1
React Native
2
Realtime Database
9
Recap Live Japan 2019
3
reCaptcha
1
Redux
1
Remote Config
3
Remote Display API
1
Resonance Audio
1
Rewarded Video Ads
2
Runtime Permission
1
Safe Browsing
1
Sample Code
2
Santa Tracker
1
schema.org
1
secur
1
security
52
Service Worker
4
SHA-1
1
sketchup
1
SmartLock for Passwords
4
social
4
Social Good
1
Social Media
1
SPDY
3
speak2tweet
1
Spreadsheet
3
SSR
1
startup
5
Storage
2
story
1
streetview
3
Study Jams
7
Swift
2
SwiftShader
1
Symantec
1
Task
4
Team Drive
1
techtalk
12
TensorFlow
27
TensorFlow Federated
1
TensorFlow Lite
4
TensorFlow Object Detection API
1
TensorFlow Probability
2
TensorFlow.js
1
test
4
Test Lab
6
TFX
1
ToS
1
trace
1
Transliteration
1
Twitter
1
Udacity
20
Unity
3
UX
4
V8
2
VP9
1
VR
11
Vulkan
2
Watch Face
2
wave
2
Wear OS
2
Weave
1
Web
25
Web Animations
1
Web Components
6
Web Manifest
1
Web Packaging
3
WebAssembly
4
WebGL
1
WebMusic
5
WebView
1
Women Techmakers Scholars Program
1
WTM
5
Xcode
1
YouTube
17
YouTube API
1
インタビュー
1
コードサンプル
1
プライバシー
1
機械学習
2
言論の自由
1
節電
3
東日本大震災
9
日本語入力
41
ブログ アーカイブ
2019
11
10
9
8
7
6
5
4
3
2
1
2018
12
11
10
9
8
7
6
5
4
3
2
1
2017
12
11
10
9
8
7
6
5
4
3
2
1
2016
12
11
10
9
8
7
6
5
4
3
2
1
2015
12
11
10
9
8
7
6
5
4
3
2
2014
12
11
10
9
8
7
6
5
4
3
2
1
2013
12
11
10
9
8
7
6
5
4
3
2
1
2012
12
11
10
9
8
7
6
5
4
3
2
1
2011
12
11
10
9
8
7
6
5
4
3
2
1
2010
12
11
Feed
Follow @googledevjp
"プロダクトに関するご意見は
プロダクトフォーラム
にお願いします"
