2019/09/20（金）、Mobile Act OSAKA #11。Cloud Firestoreに空間インデックスを適用して周辺検索を実践した話。登壇者：Wu Qifan（エンジニア, ECインキュベーション開発部）

1. を利用した地理空間検索実践
楽天株式会社
ECインキュベーション開発部
オートエコシステム開発課
仵 启帆 | Keihan
2019/09/20

2. 2
・ 年来日
・ 年阪大院卒、楽天に入社
・今まで携わってきたサービス：
楽天市場 楽天ブックス 楽天デリバリー 楽天ダイニング
楽天車検・カーサービス 他 プロジェクト
・日本 学会認定
上級バーチャルリアリティ技術者
・グーグル認定
開発者・クラウドアーキテクト

3. 3
楽天カーサービスアプリ

4. 4
導入前

5. 5
問題点
• の実装や調整などをバックエンドチームにいちいち依頼しないといけない
• バックエンドチームがウェブに集中していて、ネイティブアプリに詳しくない
• マイクロサービスを配慮した構造になっていなかった
• そもそもウェブとネイティブアプリの仕様が違う

6. 6
導入後
バッチ同期

7. 7
何が良くなったのか
• とにかく新機能がすぐに実装できる
• バックエンド側のリソースを待たなくても、必要な分だけ調整できる
• 自身の機能により：
• （追加実装なしで）ローカルキャシュが勝手に付く
• （追加実装なしで）リアルタイムでデータ変更に反応できる
• サーバのこと意識しなくていい
• の他機能とシームレス連携

8. 8
で地理空間検索？
• 検索中心から特定範囲内の店舗を地図に表示する
• 一部のデータベース製品に地理空間検索の機能が提供されてい
るが、 にはまだない
• というデータ型が用意されてるが、 の
や クエリに対応していない

9. 9
プラン ：全店舗分取得してから距離で絞り込む
• メリット：
• 一番実装しやすい
• デメリット：
• 初回ロードが遅い
• 余計な通信と料金が発生する

10. 10
プラン ：緯度と経度でそれぞれ絞り込んで重複分を取得する
• で並行処理
• プラン よりロード時間が減り、コストが軽減される

11. 11
プラン
の
や
でクエリ
したい
緯度と経度の 次元データのままだとどうにもできない
次元にすればク
エリできる
でもどうやって？
ジオハッシュ

12. 12
ジオハッシュは、 次元地理座標データを次元削減し、 次元データにマッピングするアルゴリズムです
空間充填曲線の数学技法を用いた、空間探索アルゴリズムの一種類である
カーブ アルゴリズム カーブ アルゴリズム

13. 13
エンコードされたもの
アルゴリズム アルゴリズム

14. 14
ライブラリを活用して素早く実装

15. 15
バッチ側
• 位置情報をエンコードして に書き込む
•

16. 16
アプリ側（ ）
該当範囲内のドキュメント（店舗）が取得された
該当範囲内の全ドキュメントが取得完了

17. 17
アプリ側（ ）
該当範囲内のドキュメント（店舗）が取得された
該当範囲内の全ドキュメントが取得完了

18. 18
パーフォマンス改善（旧 プラン ）
0
200
400
600
800
1000
1200
1400
1 2 3 4 5 6 7 8 9 10
Response Time (ms)
ShopAPI(GasStation) Firestore(CarWashShop)
• 平均ロード速度：
を利用した場合の数値です
キャッシュ付くので、一回ロードしてしまえば気にな
らない程度
東京・大阪リージョンを利用したい場合：
• レイテンシが約 になる（ ）
• 基本、東京が大阪より速くなる…
• 値段が若干割高くなる
• マルチリージョンではないので地域冗長が欠如

19. 19
パーフォマンス改善（プラン プラン ）
1 2 3 4 5 6 7 8 9 10 11 12 13 14
検索時間比較
Before After
• 初回ロード速度：
• 平均ロード速度：
• ジオハッシュ導入することで、コスト削減だけで
なく、ロード速度も向上できた

20. 20
まとめ
•
• プロダクト・チーム体制などを配慮して使用するかを決める
• サーバレスと のお陰でフロントエンド開発体験最高だが、コンソールも ツールもイマイチなど、落とし穴が
結構ある
•
• サードパーティライブラリで空間検索を素早い実装実現出来ているが、やはり本家から機能提供してほしい
• ちなみに今日も依存性問題が起こっていた

22. 22