こんにちは。Fluentdのメンテナーの福田です。2024年12月14日にリリースした Fluent Package v5.2.0 では、ゼロダウンタイム・リスタートおよびアップデートの機能を追加しました。この機能では、in_udp, in_tcp, in_syslog, の3種のInputプラグインの動作を止めずに、リスタートやアップデートを行うことができます。本記事では、Fluentdのプラグイン開発者向けに、その他のInputプラグインをこの機能に対応させる方法について紹介します。前置き: Fluent Package v5.2.0 のゼロダウンタイム・リスタート/アップデート機能2024年12月14日にリリースした Fluent Package v5.2.0 では、ゼロダウンタイム・リスタートおよびアップデートの機能を追加しました。詳しくは、次の記事をご覧ください。Fluent Package v5.2.0 リリース - ゼロダウンタイム・アップデートInputプラグインをゼロダウンタイム・リスタート機能に対応させる方法Inputプラグインをゼロダウンタイム・リスタート機能に対応させる方法は、マルチワーカーに対応させる方法と基本的に同様です。そのInputプラグインをマルチワーカーに対応させる場合は、それがマルチワーカーで動作して問題ないことを確認した上で、次のようにmulti_workers_ready?をオーバーライドして、trueを返すようにします。def multi_workers_ready? trueend同様にゼロダウンタイム・リスタートに対応させる場合は、ゼロダウンタイム・リスタートで動作して問題ないことを確認（後述）した上で、次のようにzero_downtime_restart_ready?をオーバーライドして、trueを返すようにします。def zero_downtime_restart_ready? trueend例: https://github.com/fluent/fluentd/blob/d7164ddc73f006de345acec8d9beb1846fb6bcb3/lib/fluent/plugin/in_udp.rb#L73-L75ゼロダウンタイム・リスタートで動作可能である条件は次の通りです。他のFluentdインスタン

こんにちは。Fluentdのメンテナーの福田です。2024年12月14日に Fluent Package v5.2.0 をリリースしました。本リリースでは、ゼロダウンタイム・アップデート機能を追加しました。これによって、今後のバージョンではリスタートやアップデートをゼロダウンタイムで実行できるようになります。この記事では、メンテナーの観点から Fluentd の最新パッケージの動向を詳しく解説します。前置き: td-agent のEOLと Fluent PackageFluent Package とは、コミュニティーが提供している Fluentd のパッケージです。それまでコミュニティーが提供していた Fluentd のパッケージとして td-agent がありましたが、td-agent は2023年12月31日限りでサポート終了となりました。Drop schedule announcement about EOL of Treasure Agent (td-agent) 4Fluent Package は td-agent v4 の後継パッケージであり、ある程度の互換性を保っています。多くのケースでは td-agent v4 から簡単にアップデート可能です。また、今回リリースした v5.2.0 は通常版となりますが、並行してLTS版も提供しています。新機能をすぐに使う必要がない、長期に渡って安定して使いたい、という場合はLTS版がおすすめです。現在 td-agent をお使いの方は、ぜひ Fluent Package へのアップデートをご検討ください。詳しくは、次の資料をご覧ください。公式ブログ(英語): Upgrade to fluent-package v5弊社提供資料: Fluent Package LTS（長期サポート版Fluentdパッケージ）ガイド 弊社ブログ: Fluent Package v5.0.2リリース - in_tailプラグインの重大な不具合の修正（前半で Fluent Package についての基本的な情報を紹介しています）Fluent Package v5.2.02024年12月14日に最新の通常版として Fluent Package v5.2.0 をリリースしました。（現時点でのLTS版の最新は v5.0.5 となっています）本バー

こんにちは。Gitはコマンド操作とクライアントアプリ操作を使い分けるのが好きな福田です。突然ですが問題です。このGitのよくあるコマンドラインを見てください。git push origin mainこのmainって、どのmainだと思いますか？...答えは、ローカルリポジトリーのmainです。え、当たり前ですかね...？なんと私は10年以上にわたって、これがoriginのmainのことだと勘違いしながら使い続けてきました。え、結果的に同じことじゃん、って？まあそうなんですが、この勘違いが見事にpush誤爆を生みまして、真相を知った私はまあ大きな衝撃を受けたわけです。この記事では、私の勘違いポイントと、その勘違いが招いたpush誤爆を紹介します。私の勘違いポイントgit push remote branch-AというGitコマンドを考えてみます。私はこのコマンドが、ローカルリポジトリーの今のブランチを、remoteのbranch-Aにpushするというものだと勘違いしたまま、10年以上使っていました。正しくは、ローカルリポジトリーのbranch-Aを、remoteのbranch-Aにpushするです。このコマンドで指定するbranch-Aは、push元のブランチ名を指します。私はこれをpush先だと勘違いしていたわけです。いつも「元」と「先」が同じブランチ名だったので、ずっと気付かなかったわけですね。。さて、push先のブランチ名はどのように決まるのでしょうか？実は冒頭のコマンドは省略形であり、自動的にpush元と同じになります（大抵は1）。そして、省略しない場合は次のような形になります。git push remote branch-A:branch-Bこれがフルの形で、ローカルリポジトリーのbranch-Aを、remoteのbranch-Bにpushするということになります。この最後の:branch-Bの部分が省略可能なわけです。冒頭のコマンドは、次の省略形だったわけです。git push remote branch-A:branch-A勘違いが招いたpush誤爆その時私は、GitHubのとあるリポジトリーに寄せられた、とあるpull requestのレビューをしていました。最後に少し修正が必要になったので、私が代わりに修正をpushしようと思ったのが発端です。こう

先日 fluent-package v5.2.0をリリースしました。v5.2.0の注目に値する機能として、対応しているバージョンのパッケージ間でダウンタイムなしのアップグレードが実現できるという点があります。（つまり、v5.2.0にアップグレードした後、その次のバージョンに改めて更新するときにダウンタイムなしでパッケージを更新できるということです。）この機能を実現するためには、パッケージ更新時のサービスの挙動を制御し、意図しないタイミングで勝手にサービスがリスタートされないようにする必要がありました。本記事では、サービスのリスタートに関連するneedrestartの機能をパッケージ側から抑制する方法について説明します。debパッケージにおけるneedrestartの影響についてneedrestartとは、パッケージの更新時に再起動が必要なサービスを通知してくれるしくみです。apt upgradeなどでパッケージを更新しているときに、最後にどのサービスを再起動するかどうか対話的に確認が求められることがありますが、その機能はneedrestartによって実現されています。1詳細は 第718回needrestartで学ぶパッケージのフック処理によくまとめられているので、そちらを参照するとよいでしょう。fluent-packageでは、ダウンタイムなしのアップグレードを実現するため、サービスの再起動のタイミングを自前で制御しています。そのため、意図しないタイミングでサービスの再起動が実行されうるneedrestartのしくみとは相性が悪いです。ゆえに、fluent-packageの提供するfluentdサービスをneedrestartのチェック対象からはずすようにしています。具体的には、次のようなファイルを/etc/needrestart/conf.d/50-fluent-package.confとして配置しています。2# Configuration for needrestart# Always suppress restarting by needrestart.$nrconf{blacklist_rc} = [ qr(^fluentd\.service$)];このようにすることで、意図しないタイミングでのfluentdサービスの再起動を抑制できます。抑制できている場合

Firefox・Thunderbirdの法人向けサポートサービスをご提供している関係で、「Firefoxのバージョン何々のサポート期限はいつまでなのか？」という趣旨のお問い合わせを頂くことがあります。様々な意味に取れる「サポート期限」という言葉ですが、ここでは「Firefoxの特定のメジャーバージョンについて、セキュリティアップデート（マイナーアップデート）が提供される期間」を指します。このサポート期限は、公式には明確な日付で記載されることがなく、具体的な日付を知るにはいくつかの情報を元に演繹する必要があります。この記事では、オフィシャルに示されている情報からFirefoxのサポート期限を読み取る手順をご紹介します。Firefoxのサポート期限の考え方本稿執筆時点で、Firefoxのサポート期間を示す公式の情報は、Firefox の更新チャンネルの選択 | 法人向け Firefox ヘルプというページに記載されています。このページでは「更新はこれだけの期間提供される」という表現になっていて、「サポート期限はいつまでである」という表現にはなっていないのですが、演繹的に以下のような意味となります。通常リリース版は4週ごとのメジャーアップデートと、その間のマイナーアップデートがある→4週が経過したらそのメジャーバージョンのサポート期限は終了し、それ以後マイナーアップデートは提供されない（次のメジャーバージョンに更新する必要がある）ESRは約52週（1年）ごとのメジャーアップデートと、その間の最低4週ごとのマイナーアップデートがある→約52週（1年）が経過したらそのメジャーバージョンのサポート期限は終了し、それ以後マイナーアップデートは提供されない（次のメジャーバージョンに更新する必要がある）Firefoxのサポート期限の情報ソースと、情報の読み取り方ここから各バージョンの具体的なサポート期限を把握するためには、将来のリリース予定が記されているFirefox Release Calendarを参照する必要があります。こちらのカレンダーで特に重要なのが、Version列、Matching ESR列、Release day列の3つです。カレンダーはQuarter列で四半期ごとにグループ化されていますが、2025年の第2～第3四半期（Q2～Q3）部分を抜き出すと、以下のようになっ

Rubyが好きなのにRubyよりCやC++を書いている時間の方が長い須藤です。Cで書かれたプログラムのデバッグに便利なaddr2lineをデバッグ情報が分離されたファイルに対して使う方法を説明します。addr2line">addr2lineまず、前提知識としてaddr2lineについて説明します。あれ？説明するか、と思ってみたもののあんまり詳しく知らない気がするな。。。まぁ、私が知っている範囲で説明します。addr2lineはGNU Binutilsに含まれているプログラムの1つで、アドレスを元に、それに対応するソースコードの位置を特定する便利プログラムです。といっても、これでピンとくる人はいないでしょう。どの「アドレス」を元にするの？というところがピンとこないと思います。多くの場合、addr2lineに与えるアドレスはglibcのバックトレース用関数で出力したバックトレース内に含まれています。というか、私がaddr2lineを使うときはこのバックトレースで取得できたアドレスしか使っていません。他の人がどうやって使っているのか知りませんが、これが代表的な使い方じゃないかな。たとえば、glibcのバックトレース用関数を使うと次のような情報を得られます。これはGroongaが実際に出力したログから抜粋したものです。/lib/x86_64-linux-gnu/libgroonga.so.0(+0xe68ad) [0x79d5ad2e68ad]この中の+0xe68adの部分がaddr2lineに渡すアドレスになります。これを渡すと「XXX.cの29行目だよ」のように教えてくれます。C言語がスクリプト言語よりデバッグが難しい原因の1つがバックトレースを取得しにくい（クラッシュした箇所を特定しにくい）ことですが、（glibcのバックトレース用関数と）addr2lineを使うことでそれを解消することができます。便利そうでしょ？デバッグ情報では、addr2lineはどうやってアドレスから該当するソースコードの位置を特定しているのでしょうか。あぁ、これも私は雰囲気でしかわかっていないですね。私がこんな感じで動いているんじゃないかな？と思っていることを説明しましょう。（違ったら教えて。）addr2lineはアドレスを元にソースコードの位置を特定していると説明しましたが、実は入力はアドレ

先日、Fluentdのv1.18.0をリリースしました。v1.18.0の変更点についてはFluentd v1.18.0をリリースに関する記事を参照していただくとして、このリリースから、Docker Hubで提供しているコンテナイメージの提供方法を改善し、GitHubでリリース用のタグを打つことで、コンテナイメージをDocker Hubへとデプロイできるようにしました。本記事ではどのようにしてそのしくみを実現したのかについて概要を説明します。従来のコンテナイメージのデプロイ方法これまでは、FluentdはSponsored OSSでありDocker Free Teamとして扱われていました。この状態だと、Automated BuildsとよばれるコンテナイメージをWebインターフェースから簡単にビルドできる仕組みが利用可能でした。しかし、Sponsored OSSであり、Docker Free Teamに所属していても、いつからかAutomated BuildsのWebインタフェースが利用できなくなりました。したがって、これまでのようにWebインタフェースから簡単にコンテナイメージをビルド・デプロイすることができなくなりました。Dockerfileとイメージをデプロイするためのフックの設定（hub.docker.com側でWebインタフェースと連動して実行される）をメンテナンスしていましたが、その仕組みは使えなくなったのです。Automated BuildsのWebインタフェースが利用できることを前提としたフックとなっていたので、これらを置き換える必要がでてきました。そこで、Automated Buildsに依存しない新たなやり方を模索する必要がありました。GitHub Actionsへの移行のポイントFluentdのコンテナイメージとしては次の5つのタイプのイメージを提供していました。(Windowsのコンテナイメージだけは別途手動でメンテナンスしています。)alpine (非推奨。歴史的経緯でまだ提供している)amd64arm64armhfWindowsこのうち、Windowsのコンテナイメージを除いてGitHub Actionsでコンテナイメージをビルド、アップロードするようにしました。具体的な例はdocker-build.ymlです。基本的には次のようなことを

Rubyの開発に参加している須藤です。そろそろRuby 3.4.0がリリースされるので私がメンテナンスしているdefault gem/bundled gemの変更点を簡単に紹介します。対象gem紹介するgemは次の通りです。default gemがRubyに組み込まれているgemで、bundled gemがRubyをインストールするときに普通のgemとしてついでにインストールされるgemです。どちらも新しいバージョンを普通のgemとしてインストールすることで、Ruby本体のバージョンを上げなくても新しいバージョンのgemを使えるようになります。csv: bundled gemfiddle: default gemrexml: bundled gemstringio: default gemstrscan: default gemtest-unit: bundled gemcsvcsv gemはCSVを扱うgemです。csv gemの変更点はこんな感じです。GH-2963つの条件が重なったときにパースに失敗する「ことがある」問題を修正しました。（4つの条件とか言ったほうがいいかもしれないけど、もう1つの条件を説明するのが面倒。。。）GH-301CSV.openがデフォルトでBOMを自動検出するようになりました。ただし！Windowsでは自動検出しません。これはRuby本体のWindowsでのBOMの検出機能がなんか変だからです。気が向いたら直そうかと思っていましたが、普段Windowsを使っていないこともあり全然気が向かなかったのでなにもしていません。だれか直して。なお、CSVにBOMが入る原因のほぼすべてはExcelなはずです。Excelが出力するCSVにはBOMが入っているはずなんです。なので、Windowsでこそこの機能があった方が便利になるはずなのですが、前述の通り無効になっています。Excelで作られたCSVを違う環境で扱うときはこれで便利になるはずです。GH-300CSV.openがStringIOを受け付けるようになりました。普通は文字列かIOを渡すと思うので、StringIOを受け付ける必要性はあまりないと思うのですが、IOを受け付けるならStringIOも受け付けていいよねーということで受け付けるようになりました。GH-313いくつか組み込みで値を変

PostgreSQLにいくつかパッチを投げている須藤です。パッチのレビューの中で、PostgreSQLのリグレッションテストツールpg_regressに今まで知らなかった機能があったことを知ったので紹介します。pg_regress">pg_regresspg_regressはいわゆるエンドツーエンドのテストツールです。PostgreSQLクライアントでサーバーに接続してSQLを実行し、そのときの実行結果があらかじめ用意してある期待値と同じになっているかどうかでテストします。MySQLでいえばmysqltest、Groongaでいえばgrntest相当のツールです。Webアプリケーションのテストではエンドツーエンドのテストは実行時間が長くなりがちでできるだけ書きたくないテストになりやすいですが、データベースのテストの場合はそうでもありません。たしかに、Cで書いた単体テストのほうが実行時間が短くなりやすいですが、CではなくSQLでテストを書けるので、エンドツーエンドのテストの方がメンテナンスしやすいです。また、実際にユーザーが使うときと同じ一連の処理を少ないテストでカバーできることもメンテナンスのしやすさにつながります。Groonga・Mroongaは、昔は単体テストも書いていましたが、今はエンドツーエンドのテストしか書いていません。ということで、PostgreSQLのテストを書くにあたりすごく便利なツールがpg_regressです。pg_regressが苦手なところ">pg_regressが苦手なところ便利といってもなにもかもpg_regressでカバーできるわけではありません。pg_regressはSQLでテストを書くので、SQLで書かないようなことは苦手です。たとえば、SQLを発行する前の接続関連のテストは苦手ですし、レプリケーションのように複数の接続にまたがるようなケースや、PostgreSQL起動時に設定をしなければいけないようなケースも苦手です。環境によって結果が変わるようなケースも苦手だと私は思っていました。pg_regressはPostgreSQLクライアントとしてpsqlを使うので、SQLではできないけどpsqlでできることならできます。たとえば、条件分岐をできます。SQLでもplpgsqlを使えば条件分岐をできますが、psqlの方がもっとがんばれる気

最近、PGroongaの演算子を改良した堀本です。今回、正規表現を用いた検索で使う演算子に新しいデータ型のサポートを追加したので、どうやって追加したかを紹介します。開発の背景今回改良したのは&~演算子（正規表現検索用の演算子）です。今回の改良を行う前は、text型とvarvhar型のカラムに対してのみ正規表現を使った検索をサポートしていました。しかし、PostgreSQLには他にもtext[]型やvarchar[]型のように文字列を格納するデータ型があります。今回は、text[]型のカラムに対して正規表現を用いて後方一致検索を実現したいというケースがあったため、text[]型をサポートしました。開発の手順まず、text[] &~ textの形でクエリーが実行された時に呼び出される関数を定義/実装しその後、&~演算子にtext[]型のサポートを追加します。最後に、アップグレード/ダウングレード時に今回追加した定義を追加/削除するためのSQLを書いて完了です。まとめると、以下のような手順で演算子を改良します。新しい関数の定義新しい関数の実装既存の演算子にデータ型を追加アップグレード/ダウングレードSQLの作成新しい関数の定義最初にtext[] &~ textの形でクエリーが実行された時に呼び出される関数を定義します。関数の実装はまた別途行うので、ここでは定義だけ行います。関数の定義は、CREATE FUNCTIONを使って行います。関数の定義を追加する場所は、 https://github.com/pgroonga/pgroonga/blob/main/data/pgroonga.sql です。関数の名前や引数、戻り値の型等を定義します。関数名は、pgroonga_regexp_text_arrayとし、引数はtext[] &~ textの左辺と、右辺のデータを取ります。また、戻り値はtext[] &~ textの条件にヒットするかどうかを返すのでboolになります。以上から、関数の定義は以下のようになります。CREATE FUNCTION pgroonga_regexp_text_array(targets text[], pattern text)RETURNS boolAS 'MODULE_PATHNAME', 'pgroonga_regexp_text_arra

Groongaの開発をがんばっている阿部です。最近はパトリシアトライのキーをデフラグする機能を実装したのでその機能について紹介します。（わかりやすさを優先するため説明を割愛している部分や厳密には正確ではない説明も含まれますがご了承ください。）前提: パトリシアトライのキーの追加と削除課題があったのでデフラグ機能を実装したわけですが、その課題を理解するため「パトリシアトライのキーの追加と削除」について説明します。key-1、key-2、key-3 という5バイトの文字列がキーとして3つ登録されてある状態を例に使います。（例ではサイズの計算をわかりやすくするためにすべてのキーのサイズを5バイトにしていますが、実際はいろいろなサイズのキーです。）境目がわかりやすいように | で区切り、キーの保存領域を次のように図示して説明します。キーの保存領域を図示:|key-1|key-2|key-3|追加キーを保存するための領域にキーを追加していきます。追加前（計15バイト使用）:|key-1|key-2|key-3|key-4を追加（計20バイト使用）:|key-1|key-2|key-3|key-4|追加する場合は末尾に追加していくだけなのでシンプルです。削除削除の場合は該当の領域からデータだけ削除するイメージです。結果としてすき間のあるデータになります。削除前（計20バイト使用）:|key-1|key-2|key-3|key-4|key-2を削除（計20バイト使用）:|key-1|.....|key-3|key-4|..... の部分は key-2 を削除してできたすき間です。注目すべきは 削除しても使用領域が減らない ことです。削除後に追加また、すき間の部分は再利用されることなく、ずっとすき間のままです。追加前（計20バイト使用）:|key-1|.....|key-3|key-4|key-5を追加（計25バイト使用）:|key-1|.....|key-3|key-4|key-5|..... のすき間は使われることなく、末尾に key-5 が追加されます。課題上述の説明でだいたい課題はおわかりかと思いますが改めて説明します。パトリシアトライの最大総キーサイズは4GiBです。上限の4GiBを超えるとデータの追加ができなくなります。データを削除しても使用領域が減らないため、レコード

PostgreSQL Conference Japan 2024でADBCの話（リンク先にはベンチマークスクリプトや実行結果もあるよ）をした@lidavidmのお手伝いをした須藤です。内容ADBC（Arrow DataBase Connectivity）はODBCのApache Arrowバージョンみたいなやつです。ODBCは接続先のデータベースの詳細を（ほとんど）気にせずに同じAPIでデータベースを使える仕組みです。ADBCも同じように接続先のデータベースの詳細を（ほとんど）気にせずに同じAPIでデータベースを使える仕組みです。違いは何かというと、データをどのように扱うかです。ODBCは行ベースで扱い、ADBCは列ベースで扱います。もう少し言うと、ADBCはApache Arrowを使います。ADBCがなにを目指しているかというと、分析アプリケーションが高速かつ便利にデータベースにアクセスできるようになることです。これを実現するために重要なところがApache Arrowです。Apache Arrowは標準化されているので、すでに各種分析アプリケーションが対応しています。ADBCはデータをApache Arrow形式で扱うので、各種分析アプリケーションはデータベースから取得したデータをそのまま使えます。そのまま使えると便利ですし、変換が不要なので速いです。既存の類似実装よりも効率的な実装になっているので、今後は分析アプリケーション用にデータベースにアクセスしたいときはADBCを使うといいですよ！ADBCは各種データベースごとにドライバーというものを用意してデータベース固有の処理を実装しています。PostgreSQL用のドライバーが用意されているのでPostgreSQLに対してもADBCを使えます。そこのドライバーが効率的な実装になっているのです。たとえば、SELECTの結果をやりとりするところでは、普通にSELECTをしてその結果をパースするのではなく、COPY (SELECT ...) TO STDOUT (FORMAT binary)にしてCOPYのバイナリーフォーマットでやりとりするようにしています。さらに高速にするためにCOPYのフォーマットを拡張可能にすることに取り組んでいたりします。これが実現されるとバイナリーフォーマットではなく、直接Apache A

こんにちは。Fluentdチームの藤田です。2024年11月29日にFluentd v1.18.0をリリースしました。本リリースではゼロ・ダウンタイムによるリスタートを主な機能として追加しました。また、いくつかの機能拡張と不具合の修正が含まれます。本記事ではFluentd v1.18.0の変更内容について紹介します。新機能ゼロ・ダウンタイムによるリスタート機能を追加LnuxおよびmacOS環境下で実行中のFluentdをゼロ・ダウンタイムで更新可能にする機能を追加しました（Windows環境は未対応）。この機能により、設定ファイルの再読み込みやFluentdの再起動をゼロ・ダウンタイムで安全に実行できます。この機能は、FluentdのSupervisorプロセスに対してSIGUSR2シグナルを送信することで利用できます。従来はSupervisorプロセスにSIGUSR2シグナルを発火すると設定ファイルの再読み込みする機能が実行されていましたが、本リリースでゼロ・ダウンタイムによるリスタート機能に置き換わりました（LinuxおよびmacOS環境限定）。従来の設定ファイルの再読み込み機能はいくつかの制限や問題がありました。詳細は#4624を参照ください。なお、従来の機能も引き続き各WorkerプロセスにSIGUSR2シグナルを送信することで利用可能ですが、特別な理由がない限り、ゼロ・ダウンタイムのリスタート機能を推奨します。機能改善設定ファイル: 組み込みRubyコードがHashやArrayの内部でも利用可能に変更設定ファイル内で利用できる組み込みのRubyコードが拡張され、本リリースではHashやArray記法内でも使用できるようになりました。例:key1 ["foo","#{1 + 1}"] # Array記法内で組み込みRubyコードを使用key2 {"foo":"#{1 + 1}"} # Hash記法内で組み込みRubyコードを使用結果:key1 ["foo","2"]key2 {"foo":"2"}既存の設定ファイルに影響はないものと考えておりますが、この変更には互換性がない点にご注意ください。意図せずに動作が変わる場合は、値全体をシングルクォートで囲むことでこの機能を無効化できます。例:key '{"foo":"#{1 + 1}"}'ssl_verify_n

test-unitをメンテナンスしている須藤です。最近@tikkssとtest-unitを改良しているので紹介します。テストを並列実行できるように改良しています。きっかけ@tikkssはRed Data Toolsに参加しているのですが、red-datasetsのテストが遅いのをどうにかするということに取り組んでいました。いくつかのケースはテスト内容を減らすことで高速化しましたが、その方法で高速化できるものは一通り対応しつくしました。これ以上の高速化はtest-unitでテストを並列実行できるようにするしかないのでは！？という気持ちになったので@tikkssと一緒に取り組み始めました。週に1回、お昼の30分で一緒に取り組んでいます。最近は毎週水曜日の12:15-12:45に取り組んでいます。私は東京に住んでいて@tikkssは島根に住んでいるので、Jitsi Meetを使ってオンラインで取り組んでいます。取り組んでいる様子はYouTubeでライブ配信しています。アーカイブもしているので、あとから視聴することもできます。予定次の3種類の並列実行をサポートする予定です。ThreadベースマルチプロセスベースRactorベース現状実はまだ完成していないのですが、一部動くものはできています。Threadを使った並列実行機能は動いていて、マルチプロセスやRactorを使った並列実行機能はまだ動いていません。この間リリースしたtest-unit 3.6.3にThreadを使った並列実行機能は入っているので、興味がある人は--parallelオプションを使ってみてください。なお、普通はThreadを使って並列実行してもテストは速くなりません！RubyでThreadを使って速くなるのはIO待ちが多いときです。RubyのThreadは同時にRubyのコードを実行できないからです。IO待ちになると他のThreadに処理が移るのでIOを待っている間も違う処理をできます。待ち時間を有効活用できるのでIO待ちがある場合は速くなるというわけです。普通はテスト中にIO待ちになることはそんなに多くありません。そのためThreadを使った並列実行機能で速くなることはほぼないんですねぇ。むしろ、オーバーヘッドがある分、微妙に遅くなります。そんなに速度向上を期待できないのにどうして実装したかというと、練

最近、Groongaのindex_column_diffコマンドの誤検知を解消した児玉です。index_column_diffはインデックスの破損を検出するコマンドですが、このコマンドが誤検知を起こすケースがあったので解消しました。この記事では、index_column_diffの詳細と誤検知の原因およびその解消方法を紹介します。ここから先は、Groongaのインデックスの仕組みを理解していることを前提として進めていきます。インデックスの仕組みを知らないよという方は、次の記事を読んだ後に戻ってくると理解しやすいと思います。groongaにデータを登録してからインデックスが更新されるまでの流れgroongaの全文検索処理の流れindex_column_diffについて本題に入る前に、index_column_diffコマンドについて紹介します。簡潔に言うと、index_column_diffは、インデックスの破損をチェックできる便利コマンドです。ここでは、簡単な使い方、仕組みとユースケースを紹介します。使い方使い方はとてもシンプルで、次のように引数を指定して実行するだけです。index_column_diff table_name index_column_nametable_name: チェックするインデックスカラムを含むテーブルの名前を指定します。index_column_name: チェック対象のインデックスカラムの名前を指定します。ただし、利用時には注意点もありますので、詳細はindex_column_diffコマンドのドキュメントをご覧ください。仕組みindex_column_diffコマンドは、次の2つのポスティングリストを比較してインデックスの破損を検出する仕組みになっています。検出対象のインデックスカラムに保持されているポスティングリストindex_column_diffが、インデックス対象のソースカラムから新たに作成したポスティングリストどちらも同一のソースカラムから作成されているポスティングリストなので、両者が一致しない場合は、ポスティングリストの整合性が保たれておらず、インデックスが破損していると判断できます。ユースケース: インデックス破損が疑われる場合Groongaでは基本的にインデックスの破損は起こりません。しかし、インデックスが破損してい