１００万件レベルのデータを対象とした、サジェスト（＝オートコンプリート）システムの作成方針について

Question

やりたいこと

・WEBブラウザ上でサジェスト（＝オートコンプリート）の仕組みを作りたい
・元データは１００万レコード程度のデータサイズ
・同時利用者は１００人程度
・デバイスはPC,SP両方対象

思い立つ実装方法

二パターンあると思っています。

１）HTTPで全件ファイル（CSVやJSON）をDL→JSでロード→JSで入力に対する候補絞り込み処理を実施
○ロードが終わり、キャッシュを使うようになれば早そう
○通信が1回しか発生しないので、オーバーヘッドが少ない？
×読み込むまでの処理が重そう

２）入力値をAPIサーバーに投げる→APIサーバーが絞り込み候補を返却→HTMLで結果をそのまま表示
○必ず最新のデータが取得できる（はず）
×キャッシュが利用できない？
×API送信中に入力変更されたら、また通信が発生するので通信重複が酷そう（JS側のライブラリ選定が重要？）

２）はDBに都度アクセスするのではなく、
サーバーサイドに変数としてロードして保持しておくことを想定しています。

質問（相談）事項

皆さんであれば、どちらの方法取りますでしょうか
※前提として、具体的な実装方法を知りたいわけではなく
他の方であればどう実装するのかを知りたいと考えています。

ネットを見ても、数十件レベルの例しかなく、
また、JSの変数に定数としてセットされているものがほとんどで、
上記の懸念点を払拭できるようなものはありませんでした。

Comments

[退会済みユーザー]

聞くより試したほうが早い

Answer 1

実際に試して調整する以外にないと思います。しかし 100 万件全てダウンロードするのはさすがに重いと思うので、ある程度小分けにする方向で考えた方がいいんじゃないでしょうか。

私なら、そのユーザーの履歴に加え全ユーザーの履歴を鑑みて重み付けをし、頻出の語を上位から適当な数ダウンロードさせ、数文字入力されるまではそれを使います。入力がある程度溜まったら候補が絞られるので、改めてダウンロードさせます。

具体的には、そのページにアクセスした時点で50 件ダウンロード、二文字以上入力があり、入力が 500 ミリ秒間以上途絶えるたびに条件に合うものを上位から 50 件ダウンロードするところから始め、実際に試しながら数を調整します。

50 件ずつダウンロードしなくても、前回ダウンロードした時点のキーワードをサーバーで見れば、ダウンロード済みのデータが判別できるので、足りないところだけ送ればパフォーマンスが良くなるかもしれません。

Comments

[gologius]

最も具体的なアンサーだったため、ベストアンサーにさせてもらいました。

入力が途切れたタイミングで通信させるのはよいアイデアかもしれません。
実装してみます。

Answer 2

どちらの方法取りますでしょうか

考えられる全ての方法を実装し、実務に耐えられものを選定します。
いわゆる、ベンチマークテストです。

---

SPのケースにおける、端末性能が具体的に示されていませんので、なんとも言い難いのですが
PCとは異なり「バッテリー切れ」というリスクが存在します。

100人程度で利用なら、業務用途思われます。100万件のデータ内容がどのようなものかは不明ですが、全員が100万件のデータを必要とするのでしょうか。

業務用であれば尚の事、古くから開発手法にある「業務分析・システム分析」に相当する「現場での利用状況の調査や想定」がしっかり行うことが必要に感じました。

各人が携行する端末がバッテリー切れで、ビジネスがストップ（機会損失の発生）する。最悪の事態ですよね。
実装後、利用状況（実務）に適しているかどうかは「試さないと分からない」と思います。

---

「どちら」じゃない別の実装方法/運用方法を思いつきましたので示しておきます。

1. 利用者に必要なデータに絞って、毎朝DL確認する。
2. DLがあれば内容を indexDB を書き換える形で永続化する。
3. indexedDBから変数に与えてサジェストに利用する

---

コメントを受けて追記

WebStorage, indexedDB 共に、保存上限があります。
（サイズは仕様では定められていませんので、例外を発生させて実装を確認するしかない状況です。)

• https://developer.mozilla.org/ja/docs/Web/API/Storage/setItem
• https://developer.mozilla.org/en-US/docs/Web/API/IDBObjectStore/add

日本語１文字はUTF8で約3byteという事も考える必要がありますので、
2020年現在のブラウザでは、100万件全てを端末で扱うのは無理なんじゃないかなとも思います。

Comments

[gologius]

試してみないと分からない、というのはごもっともな話だと思います。
ただ、実際にリリースしてから運用上困ったことがあるような実装経験者がいればと思い、
質問させて頂いた次第です。

WEBStorageは調べていましたが、IndexedDBなるものもあるのですね（調査不足ですねすいません）
案の一つとして追加します

Answer 3

これ面白いですけど、もう少し要件を整理してみてはいかがですか？
100万レコードあるのであれば、最初のキーを押したときの候補はかなりの数になると思います。

辞書順でのサジェストは UX 的に意味ないので、業務要件に従って「大量のサジェストの絞り込み」を検討する必要があると思います。

で、要件を整理していると、多分ですけど、AkitoshiManabe さんの「別の実装方法」や Zuishin さんの「私の方法」が候補に上がってくるかと。

回答として書きましたが、回答になってないですね＾＾；
解決時には、要件の背景と検討方針を教えていただけると嬉しいです。

Comments

[gologius]

仰るように最初の一文字だけであれば相当数の候補数になるため、
３～５文字程度入力した段階で、候補を表示しようとしていました

サジェストの実際の中身は商品コードです。
聞き間違い、入力間違いが多く実装しようとしていた次第です。

[退会済みユーザー]

このコメントは質問に書いておいたほうが良かったですね＾＾；
＊商品のコード体系や、分類に関しても言及があればより良かったかと。

多分全然違う発想の回答がついていたと思います。