2021-08-01から1ヶ月間の記事一覧
前回の記事で、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のオーバーヘッドが高いからというのを遅い理由として挙げていたが、うまく書けばそれを下げられることが分かったので、や…