問題タブ [meteor-publications]

Meteor の世界では多くの開発が行われてきたため、古くて時代遅れのバージョンに対して多くの回答が見つかるため、現在のバージョンで機能する回答を見つけるのが難しくなっています。

特定のコレクションに大量のデータを含むアプリがあります。ロットとは、10,000 ～ 100,000 の間のどこかを意味し、さらに多くの可能性があります。本質的にはログ データであり、結果をページネーションなし (テールなど) のテーブルに表示する必要があります。大規模なコレクションを最適化する方法を研究していると、Meteor の古いバージョンのように見えるこのような問題に遭遇し続けます。

したがって、私が見ているように、私のオプションは次のとおりです。

• 高速レンダリング プラグインを使用して、サブスクリプションの前にページを表示します (少なくとも、これがどのように機能するかについての私の理解です)。
• ある種のプログレッシブ パブリッシュ機能を使用します。この機能では、限られたより関連性の高いデータ ビットを最初にロードし、次にウィンドウ/制限を拡張して残りのデータを徐々にロードします (ただし、これによりサーバーに重い負荷がかかるかどうかはわかりません)。「プログレッシブ パブリッシュ」プラグインがあったようですが、現在は活発に開発されていないようです。
• インデックス作成を介して検索を最適化します (コレクションを作成するときにどのように指定しますか???)
• テンプレートのプロファイリングと最適化をさらに進めます (方法は不明)。
• まだ考えていない他の方法...
• 上記のすべての組み合わせ。

このように大量のデータを公開およびレンダリングするための適切なアプローチは何ですか?

Collection1 - ユーザーの個人情報 Collection2 - ユーザーの公開情報

ユーザーが特定の検索基準をオブジェクトとして設定し、Meteor.call を介してサーバーに送信するという要件があります。

サーバー側

ここで反応性をどのように導入すれば、新しいユーザーがクエリを満たしたときに更新された結果を取得できるでしょうか。

検索可能な大規模なデータセットがあります。ページをレンダリングする前にデータセット全体を送信するのは許容できないほど遅いため、現在は検索を含む部分のみを送信しています。

1 月に 10,000 件のイベントがあり、2 月に 5,000 件のイベントがあるとします。

私が望むのは、これらのレコードを 1 回だけ公開する必要があり、結果のクライアント側コレクションが以前のすべての結果の結合であることです。

pub/sub がすぐにこのように機能するとは思いませんが、この動作に近似できる方法はありますか?

ユーザーが他のユーザーをフォローできるシンプルなアプリに取り組んでいます。ユーザーは投稿にスタ​​ーを付けることができます。また、ユーザーのフィードは、フォローしているユーザーがスターを付けた投稿で構成されます。実際にはかなり単純です。ただし、これはすべて Mongo と Meteor では複雑になります...

私が考えることができるこれをモデル化する基本的に2つの方法があります：

1. ユーザーには、ユーザーがfollowingフォローする userIds の配列であるプロパティがあります。また、投稿には、starrersこの投稿にスタ​​ーを付けた userId の配列であるプロパティがあります。この方法の良い点は、出版物が比較的単純であることです。

   ユーザーが誰をフォローしているかを反応的に聞いているわけではありませんが、今のところそれほど悪くはありません。このアプローチの主な問題は、(1) 1000000 人が投稿にスタ​​ーを付けると、個々のドキュメントが大きくなり、非効率になることです。もう 1 つの問題は、(2) ユーザーが別のユーザーをフォローし始めた時期や、ユーザーが投稿にスタ​​ーを付けた時期などの情報を追跡するのが面倒なことです。

2. これを行うもう 1 つの方法は、さらに 2 つのコレクションを作成することStarsですFollows。ユーザーが投稿にスタ​​ーを付けると、プロパティuserIdとを含むドキュメントが作成されますpostId。ユーザーが別のユーザーをフォローしている場合、プロパティuserIdとを持つドキュメントを作成しますfollowId。Usersこれにより、とのドキュメント サイズが小さくなるという利点が得られますPostsが、特に Mongo は結合を処理しないため、クエリに関しては複雑になります。

さて、私はいくつかの調査を行いましたが、人々は2番目の選択肢が正しい方法であることに同意しているようです. 今私が抱えている問題は、効率的なクエリと公開です。Advanced Publications に関する Discover Meteor の章に基づいて、ユーザーのフォロワーがスターを付けた投稿を並べ替えて限定して公開する出版物を作成しました。

これは機能しますが、規模が非常に限られているようです。特に、すべてのフォロワーがスターを付けたすべての投稿のリストを作成する必要があります。このリストのサイズは急速に大きくなります。次に、$inすべての投稿に対して巨大なクエリを実行します。

もう 1 つの厄介な点は、サブスクライブした後にクライアントでフィードをクエリすることです。

この作業をすべて 2 回行っているようなものです。まず、フィードを公開するためにサーバー上ですべての作業を行います。次に、クライアントでまったく同じロジックを実行して、それらの投稿を取得する必要があります...

ここでの私の質問は、すべての設計の問題です。投稿を凝視しているフォロワーに基づいて、このフィードを効率的に設計するにはどうすればよいですか? どのコレクション/コレクション スキーマを使用すればよいですか? 適切なパブリケーションを作成するにはどうすればよいですか? クライアントでフィードを照会するにはどうすればよいですか?

私は流星を初めて使用し、tmeasday:publish-counts パッケージを使用していくつかのカウントを公開しようとしました。カウントを読み取るだけでは反応性は問題なく動作しますが、Template.helper 関数でカウントを使用すると、カウントが変化しても関数は更新されません。

これが私が持っているものです:

• サーバー上:

  /li>

• クライアント上:

  /li>

• 私のテンプレートには次のものがあります：

  /li>

• 次のサブテンプレートを使用します。

  {{getPublishedCount 'searches'}} は正常に更新されます。「検索」カウンターを取得し、カウンターが変更されるたびに更新します。

ただし、サブテンプレートのカウンタは起動時に正常に実行されますが、依存するカウンタが変更されても更新されません。

私の質問は、どのように、どこで nbSearchesThisWeek ヘルパーを依存カウンター値の変更に反応させるのですか? Deps、Tracking、および ReactiveVars に関するドキュメントを読んだとき、私は非常に混乱しています...ユースケースを機能させるためにこれらのものをどこで使用する必要があるかを本当に理解していませんでした...

ご協力いただきありがとうございます。

フィリップ

次のユースケースがあります。

• フロントエンドとは別のサービスであるバックエンドの MongoDB に users テーブルがあります。DDP.connect() を使用して、このバックエンド サービスに接続します。
• 各ユーザーには一連の「サブジェクト」があります

• users テーブルの各サブジェクトは、名前ではなく ID で参照されます。主題を ID で保持する「subjects」と呼ばれる別のテーブルがあります。

• ユーザーをクライアントに公開したいのですが、公開されたユーザーに最初にサブジェクトを入力したいと考えています。

このブログ投稿に触発されて、次のことを試しました。

これにより、バックエンドで次のエラーが発生します:
Exception from sub users id akuWx5TqsrArFnQBZ Error: Could not find element with id XhQu77F5ChjcMTSPr to change.

ということで、に変更_this.changedしてみました_this.added。エラーは発生しませんが、クライアントの minimongo に変更が反映されていませpopulateんconsole.log(user)。

コレクション全体を返したくない、またはレンダリングしたくない非常に大きなコレクション (100k 以上) があります。テンプレート レベルのサブスクリプションパターンを使用しました。ただし、最新のドキュメントを最初に並べ替えています。新しいドキュメントが追加されると、それらは表示されず、他のドキュメントをページから押し出します。

そうしたいです：

• 最新の 100 ドキュメントを表示
• 必要に応じてさらに表示できるようにする
• ただし、常に最新のレコードを表示する

これを行う方法はありますか？