読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

AOSA 4 Berkeley DB その1 #read_aosa

読書ノート

Oracle資料

http://www.oracle.com/technetwork/jp/ondemand/db-new/ord-seminar-bdb-v1-20101027-251331-ja.pdf

Berkeley DBの5つの特徴

• 組み込みに適した小型データベース • KVS型のAPIとSQLの2種類のAPIをサポート • オープンソース • 各種プラットフォーム等の対応 • Oracle DatabaseとのSync機能

NoSQLの走り

セカンダリインデックス
  • セカンダリインデックスの内容は、自動的に維持管理される
  • セカンダリインデックスへ直接更新したり挿入したりはしない
  • プライマリへの挿入はセカンダリへの追加になる
  • プライマリデータを削除するとセカンダリも削除される
DBハンドル

DBハンドルを使い、データベースアクセスが可能なので、コードベースでDBを操作できる

概要

  • コンウェイの法則によると、ソフトウェアの設計はそれを作った組織の構造を反映したものとなるらしい

Margoさん ファイルシステムとデータベース管理システムは本質的には一緒で、実装が少し違うだけ Bosticさん ツールベースのアプローチによるソフトウェア開発

  • Berkeley DB
  • さまざまなモジュールの集まりで作られている
  • それぞれがUnixの思想である"ひとつのことをうまくやらせる(do one thing well)"を体現していることもわかる

アーキテクチャへの注目

  • 最初はどんな設計だったのか
  • 最終的にどうなったのか
  • 状況に合わせて変化する設計

はじまり

UnixオペレーティングシステムがAT&Tに独占されていたころに、AT&TのプロプライエタリなソフトウェアをBerkeley SoftwareDistributionから取り除く作業

不自由なソフトウェアは邪悪である

ささやかな目標

  • インメモリのハッシュパッケージであるhsearchやディスク上でのハッシュパッケージであるdbm/ndbmを置き換えること
  • 大きなアイテムを扱えるようにする
  • 他の人のハッシュテーブルに関する研究の流用
  • アプリケーション側からはデータベースハンドルを通じてハッシュテーブルあるいはBtreeを参照でき、データベースハンドルがデータの読み込みや変更をするメソッドを保持

  • B+link→Btree

  • 1.85 Btree

  • 2.0 トランザクション
  • 3.0 作り直し
  • 4.0 レプリケーション
  • 5.0 SQL

設計講座1

複雑なソフトウェアパッケージをテストしたり保守したりしていく上で必須なのが、ソフトウェアをうまくモジュール分割した設計にしておいてモジュール間を
よくできたAPIで連携させることだ。

モジュールを細かくしないといずれ開発が破綻してしまう

複数の実装を共通のインターフェイスで扱えるようになっている。オブジェクト指向の見た目を持っているが、実際のところこのライブラリはCで書かれているのだ

継承じゃなくて、メッセージのほう。オブジェクト指向でやるとコーディング量が減るよってはなし

アーキテクチャの概要

  • 初期の構想と2.0の時点でプロセスマネージャーなるものが削除されている
  • バージョンアップ後でアーキテクチャが複雑化している
  • レプリケーション機能がまったく新しいレイヤーとしてシステムに追加された
  • logモジュールをlogとdbreg(database registration)に分割
  • すべてのモジュール間呼び出しを先頭にアンダースコアをつけた名前空間にまとめた
  • ログ出力サブシステムのAPIがカーソルベースとなった
  • アクセスメソッドの中のfileopモジュールがデータベースの作成・削除・リネームをトランザクション内でできるようにした(その必要はあるのか)

ずいぶんと高機能なデータベース

設計講座2

ソフトウェアの設計というものは、単に問題の全体像を把握してから解決を試みようという流れを強制するための手段のひとつにすぎない
熟練したプログラマーは、その目的を達成するためにさまざまなテクニックを使う
Berkeley DBの場合は、まず最初に完全なUnixマニュアルページを作るところから始めた
  • コードを全く書かずにマニュアルだけを揃えた
  • コードを書いてデバッグが始まってからプログラムのアーキテクチャについて考えるのは難しく、デバッグを始めた時点でのアーキテクチャがリリース時まで引き継がれる
  • アーキテクチャをきちんとしないとコードを書くのは難しい
  • 大規模なアーキテクチャの変更をしようとすると、それまでのデバッグの労力が無駄になってしまうこともよくある だろう

m-takagi/aosa-ja · GitHub