Q: Manticore Search で文字列の範囲比較（>, =, <=）が誤った結果を返すのはなぜですか？

これは既知のバグです（v29.18.5 で修正済み）: セカンダリインデックスが使用されると、文字列属性に対する範囲比較が誤ってハッシュ等値チェックに変換されるため、`s > 'a'` は `s = 'a'` のように動作し（`>=`/` 'a' /*+ NO_SecondaryIndex(s) */`。なお、このヒントはフィルターが1つだけの `COUNT(*)` クエリでは無視されます。2) JSON エンドポイント（および COUNT クエリ）では、範囲フィルターを式として書き換えます: `{"table":"t","expressions":{"in_range":"IF(s > 's050000', 1, 0)"},"query":{"equals":{"in_range":1}},"options":{"cutoff":0}}` — `cutoff: 0` は必須です。指定しないと `hits.total` は下限値を返します。

Question 1

Manticore Search 25.9.1でSELECT @@performance_schemaが空またはNULLを返すのはなぜですか？

Accepted Answer

バージョン25.9.1におけるリグレッションにより、`SELECT @@performance_schema`が1ではなく空の結果を返すようになりました。これにより、DBeaverとの統合やその他のクエリが破損しました。この問題はコミットd1fcc38で修正され、その後のリリースに含まれています。解決するには、この修正を含む最新のManticore Searchバージョンにアップグレードしてください。一時的な回避策として、アプリケーションがこれに依存している場合は値をハードコードすることもできますが、恒久的なアップデートをお勧めします。

Question 2

Manticore Search のセキュリティ脆弱性を非公開で報告する方法は？

Accepted Answer

セキュリティの脆弱性は、contact@manticoresearch.com にメールを送信して非公開で報告できます。または、Manticore Search リポジトリで GitHub の Private Vulnerability Reporting 機能（現在有効化されています）を使用することもできます。

Question 3

columnar_attrsをsql_attr_multi (MVA)と組み合わせて使用した場合にCSphIndex_VLN::Build_AddToDocstoreで発生するManticore indexerのSIGSEGVクラッシュを修正する方法

Accepted Answer

これは Manticore 25.0.0 の既知のバグです: インデックスで `columnar_attrs = *` (または MVA 属性を明示的に列挙した場合) と `sql_attr_multi` を併用すると、indexer が最初のドキュメントで SIGSEGV によりクラッシュします。修正方法と回避策は以下の通りです:

1. **Manticore をアップグレード** してバージョン 25.13.5 以降にします。このバージョンでクラッシュは修正されています (PR #4586):
   ```bash
   sudo apt update && sudo apt install manticore manticore-columnar-lib
   ```
   その後、インデックスを再構築します: `sudo -u manticore indexer --config /etc/manticoresearch/manticore.conf --all --rotate`

2. **影響を受けるバージョンでの回避策**: MVA 属性をカラムナストレージから除外します。`columnar_attrs = *` の代わりに、`[index]` セクションで MVA 以外の属性のみを明示的に列挙するか、そのインデックスから `columnar_attrs` を完全に削除してください。

Question 4

Manticore Searchのバージョン29.2.0以降、フィルタリングされたKNNクエリが約7倍遅くなったのはなぜですか？

Accepted Answer

これは Manticore Search 29.2.0 でコミット `f0506e35d` によって導入されたパフォーマンスのリグレッションです。KNN クエリに選択性の高い属性フィルタが含まれており、プランナーが brute-force/fullscan による実行を選択した場合、内部の `knn_dist` フィルタがプリフィルタステージでスキャンされたすべての行に対して評価されます。これは、後で文字列/属性フィルタによって破棄される行に対しても行われます。このため、`fullscan` の時間が一致した行数ではなく、テーブル全体のサイズに比例して増加します。この問題はコミット [`868eb4c0ba5ae2992f2b174895727fdacd1a5846`](https://github.com/manticoresoftware/manticoresearch/commit/868eb4c0ba5ae2992f2b174895727fdacd1a5846) で修正されています。その修正を含む Manticore Search のリリースにアップグレードしてください。一時的な回避策として、29.1.1 にダウングレードしてください（例：`manticoresearch/manticore:dev-29.1.1-786b8d5`）。`SHOW PROFILE` でリグレッションを確認できます。影響を受けるバージョンでは、累積の `fullscan` 時間が大幅に増加していることがわかります。

Question 5

Manticore Search で文字列の範囲比較（>, <, >=, <=）が誤った結果を返すのはなぜですか？

Accepted Answer

これは既知のバグです（v29.18.5 で修正済み）: セカンダリインデックスが使用されると、文字列属性に対する範囲比較が誤ってハッシュ等値チェックに変換されるため、`s > 'a'` は `s = 'a'` のように動作し（`>=`/`<=` は「等しくない」比較になります）。この問題は SQL 演算子と JSON の `range` フィルターの両方に影響し、通常は `FLUSH RAMCHUNK` によってセカンダリインデックス付きのディスクチャンクが作成された後に発生します。**修正方法:** Manticore Search 29.18.5 以降にアップグレードしてください（dev パッケージリポジトリにパッチ適用済みのビルドがあります）。**影響を受けるバージョンでの回避策:** 1) オプティマイザヒントを使用してクエリごとにセカンダリインデックスを無効にします: `SELECT * FROM t WHERE s > 'a' /*+ NO_SecondaryIndex(s) */`。なお、このヒントはフィルターが1つだけの `COUNT(*)` クエリでは無視されます。2) JSON エンドポイント（および COUNT クエリ）では、範囲フィルターを式として書き換えます: `{"table":"t","expressions":{"in_range":"IF(s > 's050000', 1, 0)"},"query":{"equals":{"in_range":1}},"options":{"cutoff":0}}` — `cutoff: 0` は必須です。指定しないと `hits.total` は下限値を返します。

Manticore Search

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト