私が推測する最も簡単なアプローチは次のとおりです。
- 2つの新しいテーブルを作成します:
keywords
(id、word)およびkeywords_comments
(keyword_id、comment_id、count)keywords
テキストで見つけた一意のIDとキーワードを保存しますkeywords_comments
そのキーワードを含む各コメント間の接続ごとに1行を格納します。count
で このキーワードがコメントに出現した回数を保存します。 2つの列keyword_id+comment_idは一緒になって、一意の、または直接主キーを形成します。
- データベースからすべてのコメントを取得します
- すべてのコメントを解析し、文字以外(または他の境界)で分割します
- これらのエントリをテーブルに書き込みます
例
次の2つのコメントがあります:
ここで、両方を繰り返し処理し、文字以外で分割します。これにより、各テキストに次の小文字が表示されます。-最初のテキスト:hello、how、are、you-2番目のテキスト:wow、hello、my、name、is、stefan
このテキストの1つを解析するとすぐに、それをデータベースに再度挿入できます。 100.000コメントをRAMにロードしたくないと思います。
したがって、これは次のようになります:
- 最初のテキストを解析して、上記のキーワードを取得します
- 各キーワードをタブケの
keywords
に書き込みます まだない場合 - キーワードからコメントへの参照を設定します(
keywords_comments
)そしてカウントを正しく設定します(この例では、各単語は各テキストで1回だけ出現するため、カウントする必要があります)。 - 2番目のテキストを解析する
- …
マイナーな改善
おそらく100.000のコメントに使用しなければならない非常に簡単な改善は、カウント変数を使用することです。 または、新しいフィールドを追加します has_been_analyzed 各コメントに。次に、データベースからのコメントごとにコメントを読むことができます。
私は通常、データをチャンク単位で読み取るときにカウント変数を使用し、データが開始方向から変更できないことを知っています(つまり、現在の時点まで一貫性が保たれます)。それから私は次のようなことをします:
SELECT * FROM table ORDER BY created ASC LIMIT 0, 100
SELECT * FROM table ORDER BY created ASC LIMIT 100, 100
SELECT * FROM table ORDER BY created ASC LIMIT 200, 100
…
これは、すでに読んだと思われる場所に追加する日付がないことが確実にわかっている場合にのみ機能することを考慮してください。例えば。 DESC
を使用する データが挿入される可能性があるため、機能しません。そうすると、オフセット全体が壊れて、1つの記事を2回読み、新しい記事を読むことはありません。
外部カウント変数の一貫性を維持できない場合は、分析済みの新しいフィールドを追加できます。 コメントを読んだらすぐにtrueに設定します。そうすれば、どのコメントがすでに読まれているか、どのコメントが読まれていないかをいつでも確認できます。 SQLクエリは次のようになります。
SELECT * FROM table WHERE analyzed = 0 LIMIT 100 /* Reading chunks of 100 */
これは、(複数のクライアントまたはスレッドを使用して)ワークロードを並列化しない限り機能します。それ以外の場合は、読み取り+ trueの設定がアトマー(同期)であることを確認する必要があります。