Tkrzw-RPCの基本機能を実装したので、バージョン0.5.0をリリースした。簡易的な性能測定をして、gRPCのオーバーヘッドについて考えてみる。

前回の記事で、GetやSetなどの、通常のデータベースの個々のレコードを操作するAPIを実装した。CountやRebuildなどの、データベース全体に対する操作も同様に実装できる。しかし、データベース内を横断して個々のレコードを取り出すイテレータは、進捗状態を…

前々回の記事で、gRPCインストールとアプリケーションのビルド方法を確認し、RPCの基本機能を使ってみた。前回の記事で、ログと起動終了という基本的な管理機能を備えたサーバプログラムが出来ている。今回はいよいよAPIの設計と実装に入る。

前回に引き続き、DBサービスの設計について検討していく。サービスと言えば、ログを記録せねばならない。また、起動プロセスと分離してデーモン化する必要がある。gRPCベースのサービスでそれらを行うにはどうすべきか考える。

Tkrzw本体でやりたい事をやり切ったので、データベースサービスでも作ってみよう。既にガチなデータベースサービスは山ほどあるので、レッドオーシャンに敢えて飛び込むのも気が引ける。とはいえ、gRPCを使うとかなり気軽に高性能なサービスを実装できるので…

メモリの使い方を工夫しただけで、ハッシュデータベースのスループットが28%向上し、B+木データベースのメモリ使用量が14%または35%減ったという話。

C言語のmallocやC++言語のnewオペレータが呼ぶメモリアロケータをシステム標準の実装から変更した場合の、各種DBMクラスの動作速度とメモリ使用量を調べてみた。glibc標準のmalloc、jemalloc、tcmalloc、mimallocを比較した。

データベースライブラリTkrzwのバージョンを1.0にした機会に、改めてベンチマークテストをしてみた。最も典型的なデータベースクラスであるファイルハッシュデータベースにて、1億レコードのSetで200万QPS以上、同じく1億レコードのGetで500万QPS以上のスル…

順序付きデータベースの重要なデータ構造であるB+木だが、それを並列に更新する方法についておさらいして、それを保護するミューテクスの種類について考察してみよう。最近実装したアップグレード付き共有ロックを活用して性能向上できるかについても検討す…

標準のstd::shared_mutexを自前のスピンロックに変えるとスループットが改善するという話を以前の記事に書いた。今回はそれを改良して、優先度のポリシーを変えたり、共有ロックを保持したまま排他ロックに格上げするアップグレード機能を実装したりする。

Tkrzwの非同期APIをGoインターフェイスでもサポートした。しかし、性能測定してみた結果、Go自体が備えているゴルーチンが強力すぎるので、ネイティブ側の非同期APIは要らなかったかもという結論に至った話。

C++標準のstd::shared_mutexを自前のスピンロックによる実装に置き換えたところ、スループットが激烈に向上した。その経緯と実装と性能評価について説明する。

TkrzwのJavaインターフェイスがGoインターフェイスの半分の性能しか出ないというのは、さすがに遅すぎるだろうという話があった。JNIのオーバーヘッドが高いからというのを遅い理由として挙げていたが、うまく書けばそれを下げられることが分かったので、や…

PythonとRubyではマルチスレッドを使うと性能がむしろ悪化する。そんな話を以前の記事で書いた。グラフに現れているように、1スレッドだとGoと同じくらいの性能なのに、マルチスレッドにするとスループットが激減してしまうのだ。ところで、ゲームやその他の…

C++に引き続いて、C言語でも非同期APIを整備した。非同期APIはC++のpromise/future機構を使えば簡単にできるのだが、それをCから使うにはそれなりの工夫が必要だった。

並列処理性能を重視したデータベースライブラリTkrzwだが、ついにGo言語をサポートした。並列処理が簡単に書けるGo言語と並列に読み書きできるDBMの親和性は高い。ここでは、各言語の性能比較をした上で、Goでの簡単な使い方について説明する。

TkrzwのGo言語インターフェイスを鋭意製作中であるが、今更ながら、「プログラミング言語Go」を読んだ。20年前に愛読した「プログラミング言語C」や「プログラミング作法」や「UNIXプログラミング環境」のカーニハン先生が著者の一人なので、なんか懐かしい…

非同期APIでは、該当の処理をバックグラウンドで実行するためにスレッドを使う。と同時に、バッチ処理やサーバプログラムなどではフォアグラウンドに相当するスレッドが複数個同時に実行される。となると、性能評価はフォアグラウンドのスレッド数とバックグ…

データベースライブラリの既存の同期的なAPIをラップして、非同期のAPIを作ったという話。C++のstd::futureクラスと独自のスレッドプールを使っている。std::futureのおかげで、スレッドプログラミングの知識が全く無いプログラマでも簡単に非同期処理機能を…

C++11標準以降のasyncとfutureによる非同期処理は非常に使いやすく、とても簡単に非同期処理を実装することができる。それによって、マルチスレッドでは複数の処理を並列実行できた場合には、スループットが向上させられる。一方で、単一の処理をシングルス…

ファイルの読み書きをマルチスレッドで並列に行うための仕組みを、各種プログラミング言語（C++、C、Java、Ruby、Python）で利用できるようにライブラリを整備した。メモリマップI/O、通常I/O、ダイレクトI/Oを同じインターフェイスで利用できる。Tkrzw-0.9.…

C++言語で書かれているデータベースライブラリTkrzwは、当然ながらC++のAPIを提供するが、C言語からは使えない。なので、主要機能をクラスでない関数でラップしたC言語のAPIも提供することにした。C言語のプロジェクトで使えることはもちろん、その他の言語…

データベースファイルを開いたプロセスが突然死した場合、次回にそのファイルを開いた際には自動的に復旧処理が走るようになっている。従来のバージョンでは、復旧に際して、データベース内の全レコードをスキャンして、データベースを再構築するのが専らで…

止められないオンラインサービスでデータベースを運用している場合、バックアップデータをどうやって作るかには頭を悩ませられる。Tkrzwにはバックアップのための手段がいくつかあるが、ファイルシステムのcopy-on-writeスナップショットを簡単に利用する機…

HashDBMの信頼性向上と性能向上を図るためにデータベースフォーマットを変更したのだが、後方互換性を持たせつつフォーマットを変更するのには苦労した。それをどうやって進めたかという話。ユーザにとっては、すげー地味でどうでもいい話ではあるが、開発者…

データベースにエラー検出符号を組み込んだはいいが、実際にどの程度の確率でエラーを検出できるだろうか。単純なチェックサムとAdlerチェックサムとCRCを比較してみた。実際にランダムに文字列を書き換えて、それがきちんと検出できるかどうかの統計を取っ…

各種圧縮アルゴリズムの性能について前回の記事で検討したが、それを実際にデータベースライブラリに組み込んだ。Tkrzw-0.9.30から利用できる。今回は、実際に英和辞書のデータベースを圧縮してみて、どのくらい効果があるのかを確かめてみる。

データベースにレコードを格納する際に可逆圧縮をかけると便利なことがある。 データベースファイルが小さくなり、また入出力のデータ量が減るので早くなることすらある。圧縮アルゴリズムを自分で実装するのは手に余るので、既存の実装を組み込むのが現実的…

TkrzwにはShardDBMというクラスがあり、シャーディングで分割した複数のデータベースファイルをあたかも単一のデータベースであるかのように透過的に扱うことができる。複数マシンに分散しないローカル環境でも、シャーディングを施すと、並列処理性能や再構…

データベースにレコード単位のCRCを内蔵することで、データが破損した際の検出率を高められるようにした。ハッシュ関数の性能測定とそれを組み込んだ際のデータベースの性能測定もして、実用になることを確かめた。これにより、Synchronizeを呼ばない運用で…