# Elasticsearchの機能と実践的な使い方 🔎 「検索→変換→集計」を1本のパイプで書ける。SQLライクで学習コストが低い新世代のクエリ言語、それがES|QLです。 🏷️ タイトル: ES|QL(パイプ型クエリ言語) 🔗 URL: 📘 概要 ES|QLはElasticsearchのデータを問い合わせ・集計・可視化・アラート化まで一気通貫で扱える新しいクエリ言語です。Unixのパイプのように `|` でコマンドを連結し、データを段階的に絞り込み・変換・集約していきます。JSONの集計DSLを書かずに、アドホック分析を素早く進められます。 ⚙️ 機能の説明 クエリは必ずソースコマンドから始まり、処理コマンドをパイプで連結する構造です。 ・`FROM` でインデックス/データストリームを指定(時系列向けの `TS` もある) ・`WHERE` で行を絞り込み ・`STATS ... BY` で集計とグルーピング ・`EVAL` で派生列を生成、`SORT` で並べ替え、`LIMIT` で件数制限 ・`KEEP`/`DROP`/`RENAME` で出力列を制御 ・`DISSECT`/`GROK` で非構造テキストをパース ・`LOOKUP JOIN` でマスタデータと結合、`ENRICH` でポリシー付与 コマンドや関数名は大文字小文字を区別しません(`FROM` も `from` も同じ)。 🛠️ 実践的な使い方 障害調査では、検索から集計までを次のように1本で書けます。 `FROM logs-* | WHERE status >= 500 | STATS count = COUNT(*) BY BUCKET(@timestamp, 5m) | SORT count DESC` Kibanaのエディタはオートコンプリート、インライン補完、Prettifyボタンによる自動整形を備え、実行後はフッターに処理ドキュメント数などの統計が出ます。同じES|QLがDiscover・ダッシュボードのパネル・アラートルール・Elastic Securityで共通に使えるのが大きな利点です。クエリ履歴やお気に入り(スター)機能で定番クエリの再利用も可能です。 💡 ユースケース ・SREのアドホックなログ分析(エラー率のサービス別・時間バケット別集計) ・ダッシュボードのES|QL可視化パネル ・セキュリティの検知ルールやアラート条件の記述 ・`LOOKUP JOIN` でサービス名→チーム名のようなマスタ結合を行う運用分析 ⚠️ 注意点 ・フィルタなしで多数のインデックスを横断するとレスポンスが肥大化するため、`KEEP`/`DROP` で列を絞ること。 ・Kibana内では `SET time_zone` ではなく `dateFormat:tz` 設定でタイムゾーンを扱う。 ・自然言語からのクエリ生成はEnterpriseライセンスとコネクタ設定が必要です。 ・マッピングされていないフィールド参照は既定で失敗するため注意が必要です。 #Elasticsearch# #ESQL#

# Neo4jの機能と実践的な使い方 ♻️ 「なければ作る、あれば更新する」——イベントストリームを何度流しても重複ノードを生まない冪等な書き込みは、`MERGE` 一文で実現できます。 🏷️ タイトル: CREATE / MERGE / SET / DELETE 🔗 URL: 📘 概要 `MERGE` は、パターンが存在すればマッチして束縛し、なければ作成して束縛する upsert クラウズです。`MATCH` と `CREATE` を一体化し、過去にデータが在ったかどうかで条件分岐できます。日次バッチやストリーム取り込みの冪等化に不可欠です。 ⚙️ 機能の説明 ・全体一致か全体作成か: `MERGE` はパターン全体に対して「すべてマッチ」か「すべて作成」のどちらかで、既存パターンを部分的に再利用しません。部分的に扱いたい場合は `MERGE` を複数に分解します。 ・`ON CREATE SET` / `ON MATCH SET`: 作成時だけ・マッチ時だけ実行されるプロパティ設定です。作成時刻の刻印やアクセス回数のインクリメントに使えます。両方を同時に書けます。 ・リレーションシップの `MERGE`: 少なくとも片方のノードが束縛済みである必要があります。無向 `-[r:KNOWS]-` は双方向で探してから左→右で作成します。 ・制約との連動: 一意制約があると `MERGE` は競合検知を行い、重複生成を防ぎます。性能上もラベル/プロパティへのインデックス作成が強く推奨されます(無いと毎回フルスキャン)。 🛠️ 実践的な使い方 イベントストリームの冪等な upsert 例です。 ```cypher MERGE (u:User {id: row.userId}) MERGE (p:Page {url: row.url}) MERGE (u)-[v:VIEWED]->(p) ON CREATE SET v.count = 1 ON MATCH SET v.count = v.count + 1 ``` 派生ノードを重複なく作る定番パターンです。 ```cypher MATCH (person:Person) MERGE (loc:Location {name: person.bornIn}) MERGE (person)-[r:BORN_IN]->(loc) ON CREATE SET r.createdAt = timestamp() ``` 💡 ユースケース ・クリックストリーム/IoTイベントの取り込みで、同一ユーザー・ページを一意化しながらカウントを積み上げる。 ・複数パイプラインからマスタを書き込んでもエンティティが二重化しない取り込み基盤。 ⚠️ 注意点 ・`MERGE` のキーには一意制約を併用するのが鉄則です。制約が無いと並行実行で一瞬の重複が生じ得ます(制約は最終的整合のみ保証)。 ・`MERGE` のプロパティに `null` は使えません。条件付き設定は後段の `SET` で行います。 ・同一 `MERGE` 内で作成中ノードの値を相互参照できません。先に `MATCH` するか `SET` に分けます。 ・`DELETE` はリレーションシップ付きノードに失敗します。`DETACH DELETE` を使います。 #Neo4j# #Cypher#

# Elasticsearchの機能と実践的な使い方 🌊 もう` 🏷️ タイトル: Data stream(追記型時系列データの論理ストリーム) 🔗 URL: 📘 概要 データストリームは、追記型(append-only)の時系列データ格納に最適化された複数インデックスを、1つの名前で扱う抽象レイヤーです。ログ・イベント・メトリクスのように次々と流れ込むデータに向いており、利用者は隠された「バックインデックス」群を意識せず、単一のリソース名へ読み書きできます。 ⚙️ 機能の説明 ・データストリームの実体は、自動生成される複数の隠しバックインデックスです。命名は`.ds-<データストリーム名>-<>-<世代>`で、世代は`000001`から始まる6桁ゼロ詰めの整数です(例: `.ds-logs-myapp-prod-2026.06.10-000001`)。 ・書き込みは常に最新の「ライトインデックス」1つだけが受け付けます。古いバックインデックスへは直接書き込めません。 ・検索は自動的にすべてのバックインデックスへルーティングされ、データセット全体を横断して問い合わせられます。 ・各ドキュメントには`date`または`date_nanos`型の`@timestamp`フィールドが必須です。テンプレートに無ければ既定の`date`マッピングが自動適用されます。 ・利用には`data_stream`定義を含むインデックステンプレートが必須で、マッピング・設定・ライフサイクルポリシーをここで定義します。1つのテンプレートを複数のデータストリームで共有できます。 ・年齢やサイズの閾値に達すると「ロールオーバー」が走り、新しいバックインデックスが作られてライトインデックスが切り替わります。これはILMやデータストリームライフサイクルで自動化されます。 🛠️ 実践的な使い方 まず`data_stream`を含むインデックステンプレートを用意します。 `PUT _index_template/logs-myapp-template` `{ "index_patterns": ["logs-myapp-*"], "data_stream": {}, "template": { "mappings": { "properties": { "@timestamp": { "type": "date" } } } } }` あとはアプリから常に同じ名前へ書くだけです。 `POST logs-myapp-prod/_doc` `{ "@timestamp": "2026-06-10T09:00:00Z", "level": "INFO", "message": "started" }` 💡 ユースケース アプリケーションログを`logs-myapp-prod`というデータストリームへ書き込み、バックインデックスのロールオーバーは自動管理に任せる構成が定番です。アプリ側は日付別インデックス(` ⚠️ 注意点 ・バックインデックス名は内部実装の詳細です。restoreやshrinkで変わることがあるため、名前から日付などのロジックを組まないでください。 ・頻繁に同じIDで上書き更新(last-write-wins)したい用途には不向きで、その場合は通常のインデックスやエイリアスを使います。 ・更新・削除は`update by query`・`delete by query`など専用APIを使い、ライトインデックス以外への直接書き込みはできません。 ・データストリームが使用中のインデックステンプレートは削除できません。 #Elasticsearch# #データストリーム#