Mroongaの開発をしている須藤です。MroongaはMySQL/MariaDB/Percona Serverからいい感じにGroongaを使えるようにするストレージエンジンです。Groongaは全文検索エンジンなので、MySQL/MariaDB/Percona Serverだけで（ゼロETLで！っていうとナウいんでしょ！？）Elasticsearchとかなしにいい感じに高速高機能全文検索機能を実現できます。そんなMroongaは10年くらい前からMariaDBにバンドルされています。MySQL・MariaDB作者のMontyさんがなんかの日本のイベントに来ていたときになんか話して「バンドルするか！」みたいな流れになったような気もするし、それとは別のところでなんやかんやしたような気もして、よく覚えていないのですが、バンドルされています。なんだろう、思い出せないーと思ってインターネットを漁ってみたら、2014年のMyNA会で使った「MariaDBにバンドルされていないMroonga」になんか関連情報がありますね。歴史に興味がある人は眺めてみてね。まぁ、そんなMroongaですが、MariaDBにバンドルされているMroongaの更新が大変で全然更新できていません。でも、それはまずいよねぇということでまた数年ぶりにチャレンジしています。で、今回はMroongaのコピーをMariaDBに入れるんじゃなくて、git submoduleでMroongaを入れようとしています。コピーだと、MariaDBが持っているMroongaの方にだけ最新MariaDBの対応が入って、本家のMroongaでは気づかずに「あれー新しいMariaDBでビルドできなくなってるー」みたいなことになるからです。だいぶ前置きが長くなりましたが、MariaDBにバンドルするMroongaを更新するために、最新のMariaDBでも動くようにする作業をしています。2025年4月のリリース自慢会の後半でもこのあたりのことを説明しているので、テキストだけだとピンとこない方は動画もどうぞ。 最新のMariaDB最新のMariaDBというのはPreviewとかRCとかでリリースされているMariaDBではなくて、MariaDBのリポジトリーのmainブランチのMariaDBのことです。LTS以降に入った変更もありま

本記事を書いている2025年3月、Google PixelでLinuxターミナルが動作するようになり、話題となりました。今回は、従来からあるAndroid向けターミナルエミュレーターアプリであるTermuxに、それまで利用できなかったパッケージを新規で追加する方法について紹介します。LinuxターミナルとTermuxの違いそもそも、Google Pixelで利用できるようになったLinuxターミナルと、Termuxはどのように違うのでしょうか。まだ提供されてから間もないことから、Google Pixel以外での動向については未知数ですが、次のような違いがあります。Google Pixelで利用できるようになったLinuxターミナルはAndroid Virtualization Frameworkを利用した仮想環境で動作するAVFに依存しているため、ハードウェア的にAVFをサポートしていても、Android端末のベンダーによっては無効化されて必ずしも使えない可能性があるTermuxは、Termux向けに移植（クロスコンパイル）されたパッケージを利用できるネイティブなバイナリなので、Androidとの親和性が高い移植されていない機能やパッケージの制約を受ける特性が違うので、Linuxターミナルが提供されることになったからといって、即座にTermuxはもういらないというわけでは現時点ではありません。今後はある程度住み分けしていくことになるのではないでしょうか。Termuxのパッケージを新規に追加する話題となったLinuxターミナルとTermuxの違いをおさえたところで、それでもTermuxにまだないパッケージを移植したい人のために、追加する手順を紹介します。Ubuntu 24.04の環境でdockerを利用できるようにするtermux-packages リポジトリをcloneするTermuxパッケージのレシピを作成するコンテナを利用してパッケージをビルドするビルドしたパッケージをAndroid端末に導入するなお、本記事では、Build Environmentで推奨されているDocker Containerを利用したパッケージのビルド方法に基づいて紹介します。Ubuntu 24.04の環境でdockerを利用できるようにする$ sudo apt install -y doc

Apache Arrow東京ミートアップ2025に参加予定の阿部です。GroongaはApache Arrowフォーマットでのデータロードと検索結果の取得に対応しています。今回は実際にそれを使ってみる企画です。Apache Arrowフォーマットのデータを作るところからやってみます。次の流れで進めていきます。Apache Arrowフォーマットのデータを作るGroongaにApache ArrowフォーマットでデータをロードするGroongaで検索してApache Arrowフォーマットでデータを得るはじめにGroongaでApache Arrowフォーマットを使うには、HTTPインターフェイスを使わないといけない です。なので、本記事ではGroongaに対する操作はHTTPでリクエストする方法を使っています。参考:Apache Arrowフォーマットでデータロードするときの注意などHTTPでリクエストする方法また、もろもろの処理をJavaScriptで実装しました。JavaScriptが好き、以外に選択した理由はないので、他の言語の実装例も見たい方はお問い合わせよりご連絡ください。とりあえず使ってみることが目的の企画なので、各関数で何をやっているかなどの詳細は割愛しています。要所要所に関連する公式ドキュメントへのリンクを記載しましたので、詳細はそちらでご確認ください。1. Apache Arrowフォーマットのデータを作る公式ドキュメント: Apache Arrow in JS にある例を使わせてもらいます。Groonga用にちょっと変えてます。const LENGTH = 2000;// Apache Arrowは列指向なので列ごとにデータを作ります。// （コードからはどのようなデータなのかわかりにくいので、// 後述の"実行結果例"もご確認ください。）const keys = Array.from( { length: LENGTH }, (_, i) => i);const rainAmounts = Float32Array.from( { length: LENGTH }, () => Number((Math.random() * 20).toFixed(1)));const rainDates = Array.from( { length: LEN

Apache Arrowの開発に参加している須藤です。そろそろApache Arrow 20.0.0がフィーチャーフリーズされて、4月の中旬から下旬くらいには20.0.0がリリースされます。そんな20.0.0で予定されている変更の1つであるAPT/Yumリポジトリーに関する変更を紹介します。互換性があるように変更するのでいきなり動かなくなることはないはずですが、長い目で見ると変更に追従しておいて欲しい、といった変更になります。Apache ArrowのAPT/YumリポジトリーApache Arrowが提供しているライブラリーの中にはC++で実装されているライブラリーがあります。C++実装のライブラリーのパッケージは、LinuxではdebやRPMで提供されていることが多いです。aptやdnfで簡単にインストールできるからです。aptやdnfでインストールできると依存関係も含めてインストールしたり、sudo apt upgrade/sudo dnf upgradeでまとめて最新バージョンにしたりできます。Apache Arrowはインメモリーデータ分析ソフトウェアの基盤コンポーネントとして広く使って欲しいので、様々な方法で簡単にインストールできるようにしてあります。今回説明するようにaptやdnfでインストールできるようにしたり、vcpkgやConanのようなC++用のパッケージマネージャーでインストールできるようにしたりといった具合です。どのパッケージマネージャーもだいたい「リポジトリー」のようなパッケージの集合を指す概念があります。基本的に、デフォルトのリポジトリーに登録してある状態にするのが一番簡単にインストールできます。サードパーティーのリポジトリーを登録する必要がないからです。vcpkgやConanではパッケージマネージャーの開発者と協力してデフォルトのリポジトリーを更新しています。しかし、APT/Yumリポジトリーは各ディストリビューションのデフォルトのAPT/Yumリポジトリーでパッケージを更新するのではなく、サードパーティーのAPT/Yumリポジトリーを提供しています。どうしてかというと。。。大変だからです。あとは、リリースタイミングが合わないという理由があります。たとえば、Debianのデフォルトのリポジトリーに入れるにはDebian開発者やDebi

Apache Arrowの開発に参加している須藤です。Apache Arrow東京ミートアップを6年ぶりに開催します！概要Apache Arrow東京ミートアップは7年前と6年前にSpeeeさんに協力してもらって開催していました。Apache Arrow東京ミートアップ2019Apache Arrow東京ミートアップ2018今回、6年ぶりにApache Arrow東京ミートアップ2025を開催します！会場はReazonSpeechやOpenArmなどに取り組んでいるレアゾンHI研究所さんに提供してもらいます。後述の通り、日英が混在するミートアップになる予定なのでReazonSpeechベースの同時通訳システムも提供してもらいます。助かる！そんなに参加者を募れないので、今回はすでにApache Arrowを使っている人限定（Apache Arrowに興味があって使ってみたいんだよねーな人は対象外）で、少し突っ込んだ話をできる機会にできるといいなぁと思っています。こんな感じで使っているんだけど、もっといい使い方ある？とか、こういう機能があると良さそうだから提案したいんだけど、どう思う？とか。今回のミートアップにはApache Arrowの開発者が何人か参加する予定です。最近PMCメンバーになったRokさん、ADBCとかFlight SQLとかを開発しているDavidさん、ビッグエンディアンまわりとかをやっていた石崎さん、なんかいろいろやっている私が参加します。開発者と話をしたいことがある人はぜひ来てね。他にもApache Arrowの利用事例をいくつか紹介します。今のところ、海外さんがPG-Stromでの利用事例を紹介してくれて、あべくんがGroongaでの利用事例を紹介してくれる予定です。他にも利用事例を待っているので、紹介できる人はぜひ。なお、私は英語を聞いたり話したりできません。また、Rokさんは日本語を聞いたり話したりできません。そのため、ReazonSpeechベースの同時通訳システムが活躍するはずです！開催理由実は急遽開催することになったんですが、理由はいくつかあります。最近、Apache Arrowのメーリングリストでヨーロッパでミートアップ開催しちゃう？という話があって、私は「いいなぁ」と思って眺めていました。それとはまったく関係なく、Rokさんから観光

RubyKaigi 2025の3日目の夜にアンドパッドさんが開催するコード懇親会のお手伝いをする須藤です。2025年3月19日の10:00から参加登録できるので、「コードで懇親？楽しそう！」と思うRubyKaigi 2025参加者は登録してね。コード懇親会とはコード懇親会は7年前に私が思いついた懇親会のスタイルです。普通の懇親会とはちょっと違うコンセプトの懇親会です。普通の懇親会は飲食物が用意された状態で各参加者がそれぞれ違う参加者と話をして懇親します。ちょっとしたトークや催し物が用意されることもあります。コード懇親会はその名の通りコードを軸に懇親します。一緒にコードを書いたり、一緒にコードを読んだり、どうしてこんなコードになっているのかみんなで考えたり作者に聞いたり。そんな感じで懇親します。そんなことをして楽しい時間になるの？って思いますよね。楽しい時間になるはず！特にRubyistなら！Rubyは楽しくプログラミングできるように設計されたプログラミング言語です。だったら一緒にRubyでコードを読み書きする時間も楽しい時間になるはずだよね。そういうコンセプトです。とは言っても、やっぱり人によると思います。「一緒にコードを読み書きする」と聞いて「楽しそう！」と感じる人はコード懇親会を楽しめるでしょう。一方、「？」と思う人はそうでもない可能性が高そうです。そんな人は、自分が楽しめそうな他のイベントを選んで参加してください。おそらく https://rubykaigi.org/2025/events/ にイベントリストが公開されるはずなので、そこで自分が楽しめそうなイベントがきっと見つかるはずです。（でも、言葉では理解できなかったけど体験したら理解できた！となる人もいる気はするので体験して自分は楽しめるかどうか確認して欲しいとは思っています。）なお、他のドリンクアップ系イベントと違ってお酒はない予定です。RubyKaigi 2025では毎晩お酒を飲みたい！という人は別のイベントの方が向いています。あるいは、コード懇親会が終わった後に一杯やりに行ってください。21:30に終了予定です。過去のコード懇親会情報言葉での説明だけではイメージがつかない人向けに過去のコード懇親会の様子がわかる情報をおいておきます。参考にしてください。コード懇親会は過去にRubyKaigi 2018

OfficeStringReplacerというMicrosoft Office 製品1のファイル内の文字列を検索・置換するツールを開発した橋田です。Office文書に含まれる文字列の検索、置換処理を素直に実装するとものすごく時間がかかりますが、OfficeStringReplacerでは現実的な時間に収まるように工夫をしています。この記事ではその工夫の詳細について解説します。検索、置換での工夫OfficeStringReplacerでは以下のファイル形式をサポートしています。.xlsx、.docx、.pptx： Office 2007以降の標準のExcel、Word、PowerPointのファイル形式.xlsm、.docm、.pptm： Office 2007以降マクロ機能付きのExcel、Word、PowerPointのファイル形式.xls、.doc、.ppt： Office 2007より前の、旧形式のExcel、Word、PowerPointのファイル形式.accdb、.mdb: Microsoft Accessのファイル形式OfficeStringReplacerはC#で実装しています。Office文書の内容をC#で読み書きする正規の方法としては、Microsoft.Office.Interop.Excel.ApplicationなどのOffice 相互運用オブジェクトにアクセスするC#ライブラリ（以下、Office相互運用ライブラリ）を使う方法があります。ですが、Office相互運用ライブラリでの操作は処理が遅く、ファイル内すべてを検索、置換するような処理では、現実的な時間では実行が完了しません。そのため、現実的な時間で実行を完了させるためには、何らかの工夫をする必要があります。それぞれのファイル形式について、どのような工夫を行ったのか解説します。.xlsx、.docx、.pptx">.xlsx、.docx、.pptxこれらのファイルは、実体としてはOffice Open XML形式のXMLファイルをまとめたZIPファイルです。そのため、ZIPファイルとして展開・圧縮することができます。例えば、エクセルファイルのシートやセルの情報なども、すべて展開後のXMLファイルの中に含まれています。OfficeStringReplacerでは、これらファイルをZIPファ

Groongaの結果セットにRoaring bitmapsを使えないか検討している須藤です。以前、ClickHouseみたいにポスティングリストにRoaring bitmapsを使えないか検証しましたが、既存のPForDeltaの方がよかったのでやめました。しかし、結果セットには使えるかも？とは思っていました。ただ、Groongaの結果セットは「ヒットしたレコードはどれか」というビットで表現できる情報だけではなく、「ヒットしてレコードはどれで、それらのスコアはそれぞれいくつか」という「ヒットしたか」（ビットで表現できる）+「スコア」（64bit浮動小数点数で、ビットでは表現できない）というビットでは表現できない情報が必要です。そのため、使えるかも？とは思いつつ、じゃあどうやって？がわからずにそのままになっていました。この間、なんとなくまたどうにかできないか調べてみたら、Roaring bitmapsのGo実装にはそれを実現する方法が含まれていることを見つけたので紹介します。まだGroongaでは検証していないので、Groongaで使いものになるかどうかはわかりません。Roaring bitmapsRoaring bitmapsは効率よくかつ高速にビットマップを表現する方法です。立っているビットの数に合わせて内部表現を変えることでそれを実現しています。たとえば、2 ** 15番目のビットだけが立っている場合、2 ** 15ビットのビットマップを用意して2 ** 15番目のビットを立てると2 ** 15 / 8バイト（4KiB）必要になりますが、2 ** 15番目という情報だけ持って表現すると2バイトで表現できます。こういう感じのことをいい感じにがんばって効率よくかつ高速にビットマップを表現しています。それでは、ビットしか表現できないRoaring bitmaps（ビットマップなんだから当然）でどうやってビットより大きい情報を表現するとよいのでしょうか。Bit Slice Indexing (BSI)1つのビットマップでは表現できないなら複数のビットマップを組み合わせて表現すればよいのです。その実装がBit Slice Indexingという名前でGo実装に入っています。たとえば、「ヒットしたか」と「64bit浮動小数点数のスコア」を表現するときは、「ヒットしたか」のた

Apache Arrowの開発に参加している須藤です。LLVMは詳しくないし、LLVMのどのコミットで直ったとかも調べていないし、私はレビューとか調査をしていただけで実装していないとかなんですが、最近、数年越しのGandivaの問題が直ったので雰囲気で紹介します。GandivaGandivaはAapche Arrow C++に含まれている実行時式コンパイラーです。ようは実行時に与えられた式（1 + 1とか）をJITコンパイルして、さもビルド時にコンパイルしたような速度で実行できるようにするやつです。もともと、Dremioで使いたくて作ったものをApache Arrowに寄贈したものです。DremioはJavaで実装されているので、Apache Arrow Javaからも使えるようになっています。GandivaとLLVMGandivaはLLVMを使って式をJITコンパイルしています。LLVMには複数のJIT機能があるらしく、当初はMCJITというJITエンジンを使っていました。その後、ORCv2というJIT APIがMCJITを非推奨にしたということで、ORCv2に移行しました。ところで、ORCがなんの略かわかっていません。何度かざっと調べたのですが見つけられませんでした。あと、JITエンジンとJIT APIをどう使い分けているのかもわかっていません。MCJITのドキュメントではJITエンジンで、ORCv2のドキュメントではJIT APIなんです。（「ORC JIT」とかで検索するとORCは「On-Request-Compilation」の略だとわかると@hsbtに教えてもらいました！たしかにLLVMのチュートリアルにそう書いてありました！）ORCv2とLLVM 17しばらくはORCv2で元気に動いていましたが、LLVM 17から特定のケースで動かなくなりました。どういうケースかというと、メインのプロセスがLLVMとリンクしていないケースです。たとえば、JavaからGandivaを使う場合はGandivaを外部ライブラリーとして用意しておいて、実行時に組み込みます。つまり、Java本体（メインのプロセス）はLLVMとはリンクされていなくて、GandivaだけがLLVMとリンクされています。この状態でORCv2を使うとllvm_orc_registerEHFrameSe

Apache Arrowの開発に参加している須藤です。先月、Apache Arrowの公式ブログにHow the Apache Arrow Format Accelerates Query Result TransferというApache Arrowフォーマットを使うとなぜクエリー結果の転送が高速になるのかを説明した記事が投稿されました。すごくよくまとまっている内容で、今後、何度も参照したくなりそうでした。ということで、Apache Arrowの公式ブログに翻訳記事を追加しておきました。昨今の機械翻訳は精度がかなり上がっているので人手の翻訳がなくても読みたい人は読む気はしますが、検索したときに見つかりやすくなるかもなぁと思ってやっておきました。詳細はこの翻訳記事を読んでもらうとして、ここでは簡単に概要を紹介しておきます。概要OLTP（OnLine Transaction Processing）では少数のレコードを変更するだけなのでクエリー結果が大きくなることはほぼありませんが、OLAP（OnLine Analytical Processing）では大量のレコードを扱うのでクエリー結果が大きくなることがよくあります。ここではこのような大きなクエリー結果を扱うことを前提にします。Apache Arrowフォーマットが大きなクエリー結果の転送を高速にするのは次の5つの特徴が関係しています。列指向自己記述的で型安全ゼロコピー可能ストリーム可能汎用的列指向Apache Arrowフォーマットは列指向（カラムナー）です。OLAPはデータ分析処理ですが、データ分析処理用のツールはだいたい列指向でデータを持っています。その方がデータ分析処理が速いからです。転送用のフォーマットが列指向だと、転送用に行と列を転置する必要がなくなります。行と列を転置するのは重い処理なので、これをやらなくて済むと高速になります。（列指向とかは元の記事に図入りで説明があります。）自己記述的で型安全Apache Arrowフォーマットは自己記述的で型安全です。自己記述的というのはデータ内にスキーマなどのメタデータも含まれているということです。メタデータが含まれていない場合は、データからスキーマを推測するか正しく処理するために別途メタデータを取得しなければいけません。そのような処理（特に推測する処理）が必要にな

PGroongaのメンテナンスもしている堀本です。PGroongaは4.0.0からPostgreSQL 17以降を使っている場合に限り、複数のCPUコアを活用してインデックスの構築を並列で実行できます。（PostgreSQL 17より前のバージョンでは動作しないので注意してください。）並列に実行するため、インデックス構築速度の高速化が期待できますが、場合によっては思ったほど高速にならない可能性もあります。今回は、PGroonga 4.0.0を使ってもあまりインデックス構築が高速にならない人向けの記事です。はじめに前述の通り、PGroonga 4.0.0以降ではインデックスの構築を複数のCPUコアを利用して並列に実行できます。どのくらい並列で実行するかは、PostgreSQLがおすすめする並列度を使っていますが、PostgreSQLがおすすめする並列度は控えめなので、あまり高速にならない可能性があります。しかし、PGroongaはPostgreSQLがおすすめしてくる並列度ではなく、全力で並列に実行するように設定を変更できます。PGroonga 4.0.0を使ってもあまりインデックス構築が高速にならない人は、これから紹介する方法を使って高速になるか試してみてください。具体的には、PostgreSQL 17の環境変数にGRN_N_WORKERS_DEFAULTを設定する必要があるので、以降では、この環境変数を設定する方法を紹介します。PostgreSQLに環境変数を設定するということで、PostgerSQL 17に環境変数GRN_N_WORKERS_DEFAULTを設定しましょう。ここで、「え、どうやって？」と思った人はこの先に進んでください。そう思わなかった人は、この先の情報は不要ですので、GRN_N_WORKERS_DEFAULTに-1を設定して高速になるか試してみてください。それでは、UbuntuにインストールされたPGroongaを例に環境変数を設定していきましょう。環境変数は以下のように設定します。/etc/postgresql/17/main/environmentにGRN_N_WORKERS_DEFAULT = -1を追記します。（systemd editを使って環境変数を設定するのではなく、/etc/postgresql/17/main/environm

屋代です。2023年よりセキュアブラウザ製品「Chronos SystemGuard」を担当しています。2025年2月14日に、Chronos SystemGuardの最新版となるv15.0.131.0をリリースしました！ そこでこの機会に、次の2点について簡単にご紹介します。Chronos SystemGuardについてChronos SystemGuardのリリースについてChronos SystemGuardについてChronos SystemGuardとは、先述のとおり、セキュアブラウザ製品です。Windows用アプリケーションとして、現在、Windows 11とWindows 10をサポートしています。Chronos SystemGuardには次の特長があります。ThinAppを使って仮想化することにより、使用時のセキュリティを高めています。仮想化された環境でブラウザを使用することで、万が一悪意あるWebサイトへのアクセスやマルウェア感染などの問題が発生しても、ホストに影響を与えずに済みます。実環境を保護するため、アップロードするファイルやダウンロードしたファイルは専用のファイルマネージャを介して扱います。さらに、サイトの閲覧履歴やファイルのアップロード／ダウンロード操作を、監査ログとして出力する機能も備えています。仮想化前のChronosは、MITライセンスのOSSですが、ThinAppを使って仮想化するためのモジュールはプロプライエタリソフトウェアとなっています。以下当記事ではChronos SystemGuardを「Chronos-SG」と表記します。Chronos-SGはChromiumベースのオープンソースのフレームワーク「CEF（Chromium Embedded Framework）1」を採用しています。Chronos-SGの最新版v15.0.131.0では、CEF131.4.1を使用しています。Chronos-SGのバージョン番号の3桁目を、このCEFのメジャーバージョン番号と揃えています。Chronos-SGの特長についてはChronos SystemGuard製品紹介にも記載があります。あわせてご覧ください。Chronos SystemGuardのリリースについてクリアコードでは、定期的にChronos-SGのリリースを行っています。リ

こんにちは。Fluentdチームの藤田です。今回はfluent-logger-rubyという、Rubyプログラムから手軽にログをFluentdに送信するためのライブラリを取り上げます。Rubyには並列処理を手軽に扱えるparallelというライブラリがあり、マルチプロセスまたはマルチスレッドで処理が行えるようになります。これらを組み合わせて、並列的にfluent-logger-rubyでログを送信したときに問題なくログが送信できるか調べてみました。実装次第では受信データが破損するケースがあるため、注意が必要です。並列処理でfluent-logger-rubyを使う受信したログが壊れるケース以下のようにParallel.eachの外でFluent::Logger::FluentLoggerのオブジェクトを作成すると、期待通りに動作しない可能性があります。require "fluent-logger"require "parallel"HOST = "127.0.0.1"PORT = 24224DATA_LENGTH = 1024 * 1024 * 10logger = Fluent::Logger::FluentLogger.new(nil, host: HOST, port: PORT)Parallel.each(("1".."100"), in_processes: 4) do |str| logger.post('test', { message: str * DATA_LENGTH })endこのコードでは、親プロセスで作成されたFluent::Logger::FluentLoggerオブジェクトを子プロセスでも利用しようとしています。Parallel.eachをin_processesのオプション付きで使用すると、マルチプロセス環境になり、Fluent::Logger::FluentLoggerオブジェクトが保有しているTCPソケットをプロセス間で共有することになります。巨大なデータをTCPソケットで送信する場合、OSのレイヤーでデータが複数に分割して送信されることがあります。1つのソケットに対して複数のプロセスから書き込みを行っていると、データを分割送信している際に混ざることがあり、受信側でデータが壊れる可能性があります。正しくログが転送されるケース以下の

2025年2月14日にFluent PackageのLTS(長期サポート)版の最新バージョンであるv5.0.6をリリースしました。本リリースでは、Windows向けにいくつかの改善を行っています。本記事ではFluent Packageの変更内容について紹介します。Fluent Package v5.0.62025年2月14日にFluent PackageのLTS版の最新バージョンであるv5.0.6をリリースしました。同梱のRubyを3.2.6から3.2.7に更新し、Fluentdのバージョンはv1.16.6からv1.16.7に更新しています。本記事ではFluent Packageの変更内容について紹介します。興味のある方は、以下の公式情報もご覧ください。公式リリースアナウンスFluent Package v5.0.6: https://www.fluentd.org/blog/fluent-package-v5.0.6-has-been-releasedCHANGELOGFluent Package v5.0.6: https://github.com/fluent/fluent-package-builder/releases/tag/v5.0.6Fluentd 1.16.7の修正内容については、公式アナウンスであるFluentd v1.16.7 has been releasedを参考にしてください。改善Fluent Package v5.0.6では、以下の改善をしています。WindowsでFluentdサービスの設定を引き継げるように改善また、Fluent PackageにFluentd v1.16.7を同梱したことにより、次の問題も修正されています。Windowsで--daemonオプションを指定して起動しようとするとNoMethodErrorで失敗するWindowsでサービスの開始と停止を短期間に行うとプロセスが残留したり、停止できなくなるWindowsでFluentdサービスの設定を引き継げるように改善従来のバージョンでは、Fluent PackageのWindows版でアップグレード時にサービスの設定が引き継げないという問題がありました。そのため、Fluent Packageをインストール後に、サービス起動時のオプションをカスタマイズしていた場合には、

Groongaの開発に参加している須藤です。今年も年に一度の肉の日（2月9日のこと）が来ましたね！例年通り、GroongaとMroongaはメジャーバージョンアップしました！今年はついでにPGroongaもメジャーバージョンアップしました！この一年でどのくらいGroonga・Mroonga・PGroongaがよくなったかを紹介します。ちなみに、世間ではメジャーバージョンアップをすると互換性がなくなってアップグレードが大変！というソフトウェアが多いですが、Groonga・Mroongaは非互換なしなのでいつもどおり安心してアップグレードできます！PGroongaは非互換がありますが、普通は関係のない非互換なのでいつもどおり安心してアップグレードできます！そこらへんは後述します。GroongaGroongaは今回のメジャーバージョンアップで15.0.0になりました。前回のメジャーバージョンアップからの目玉機能はここらへんになります。特定ケースの検索パフォーマンス向上JSONのパースの高速化ラテン語系の言語のサポートを強化Unicode 16.0.0対応生成カラムのサポート言語モデルのサポートLGPL-2.1-onlyからLGPL-2.1-or-laterにライセンス変更パトリシアトライへのデフラグのサポートパラレルオフラインインデックス構築のサポートそれぞれ簡単に紹介します。特定ケースの検索パフォーマンス向上Groongaは広く公開しているフリーソフトウェアなので、Groonga開発者たちの知らないところでもたくさん使われています。（使われているはず！）もちろん、そういう使い方をしてまったく問題ないのですが、一部のユーザーはクリアコードが提供するGroongaサポートサービスを利用しています。Groongaサポートサービスは基本的に時間制のサポートサービスになっていて、時間内であればかなりいろんなことに対応しています。高速化もその中の一つです。「高速化したい検索」をこちらで再現するためのデータとクエリーをお客さんから提供してもらって高速化します。クエリーレベルのチューニングをすることもありますが、多くの場合はGroongaの検索処理を改良して抜本的に高速化します。つまり、データ・クエリーはそのままでGroongaをバージョンアップしただけで高速になる、というような高速化