Astro Blog Yuki Shimizu

CouchDB Introduction

CouchDB データモデル

  • 各 DB は独立した document のコレクション
  • 各 document は独自のデータと自己完結型の schema を維持する必要がある
  • document meta data には revision 情報が含まれているため、DB が接続が切断されている間に発生した diff を merge することができる
  • CouchDB は write 処理中に DB field をロックする必要がないように、複数 version の同時実行制御を実装している

couchdb-architecture

https://www.javatpoint.com/couchdb-tutorial より引用

認証

https://docs.couchdb.org/en/stable/intro/security.html#authentication-database

CouchDB にはデフォルトで名前付けされた_usersという特別な認証データベースがあり、すべての登録されたユーザーが JSON ドキュメントとして保存される。

この_usersはシステムデータベースであり、共通のデータベース APIを共有する一方で、いくつかの特別なセキュリティ関連の制約が適用される。

以下は認証データベースが他のデータベースとどのように異なるかのリスト

  • 管理者のみがすべてのドキュメントのリストを参照することができる。
    • GET /_users/_all_docs
  • 管理者のみがChanges Feedsを listen することができる
    • GET /_users/_changes
  • 変更することができない_authという特別な設計書がある
  • 設計ドキュメントを除くすべてのドキュメントは登録済みの CouchDB ユーザーを表し、そのユーザーに属する。
  • デフォルトで_securityはデータベースの設定により、_usersユーザーはドキュメントにアクセスしたり変更したりできなくなる

User Document

https://docs.couchdb.org/en/stable/intro/security.html#users-documents

各 CouchDB ユーザーはドキュメント形式で保存される。これらのドキュメントには認証のために CouchDB が必要とするいくつかの必須フィールドが含まれている。

  • _id
    • document id。特別な prefix を持つユーザーのログイン情報が含まれている
    • org.couchdb.userprefix
      • ユーザーのログイン名の前に特別な prefix がある理由は、ユーザーが属する名前空間を持つため。
      • この prefix は 2 つ以上の_usersデータベースを merge しようとしたときに replication の conflict を防ぐように設計されている
  • derived_key
  • name
    • ユーザー名
    • 不変であり、既存のユーザーの名前を変更することはできない。したい場合は新しくユーザーを作成する必要がある。
  • roles
    • ユーザーの役割のリスト
    • CouchDB には組み込みの role が用意されていないため、必要に応じて独自の role を自由に定義することができる。(_adminのような system role は設定不可)
    • 管理者のみがユーザーに role を割り当てることができ、デフォルトではすべてのユーザーには role がない
  • password
    • プレーンテキストのパスワードを設定可能だが、document が実際に保存される前にハッシュ化されたフィールドに置き換えられる
  • password_sha
    • ソルトでハッシュ化されたパスワード
  • password_scheme
    • パスワードハッシュスキーム。simpleまたはPBKDF2
  • salt
    • ハッシュソルト
  • iterations
    • key を導入するための反復回数
  • type
    • ドキュメントのタイプ。必ずuser value がある