タグ

Databaseに関するguangdaのブックマーク (6)

  • Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ

    先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ

    Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
  • 主キーはインデックスではない - 設計者の発言

    仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス(キー)というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルXがある。ところが、別のテーブルYからテーブルXの特定レコードにアクセ

    主キーはインデックスではない - 設計者の発言
  • Cassandraのデータモデル - terurouメモ

    ざっくりとしたイメージおよび解説。説明が下手なので画像だけ見た方がいいかも。。。 KeySpace ColumnFamilyの集合。RDBMSでいうところのDatabaseに該当する感じ。 ColumnFamily Key-RowのHashMap(HashMap)みたいな感じ。 Key 1つのRowを示すキー文字列。CassandraではKeyによってデータの分散先(保存先ノード)が確定する。 Row Keyに対するColumnもしくはSuperColumnの集合。ColumnとSuperColumnのどちらが入るかはstorage-conf.xmlの設定による。 また、Cassandraの内部では、Row内のColumnはColumnNameによってソートし保存されている。ソート方法についてもstorage-conf.xmlの設定によって確定する。 Column Cassandraで最小

    Cassandraのデータモデル - terurouメモ
  • Cassandraを使った高速ログ検索システムの構築

    ◆ 目的 サーバに届いたメールログをNoSQLであるCassandra(カサンドラ)のデータベースに格納させ、 高速に検索できるようにする。事前にCassandraの予備知識があると理解しやすいだろう。 SQLではないので、テーブルに格納されたデータを柔軟にselectすることはできない。 NoSQLはkey-value形式である。 そのため設計時に何から何を求めるか決めておく必要がある。 今回は次の目的を達成できるようにする。 a) fromアドレスと日時からのメールログの検索 ⇒ fromアドレスと日時をキーにするわけである b) 日時からのメールログの検索 ⇒ 日時をキーにするわけである 追記 ここではcassandra-0.6を使っているのだが、既に0.8までアップデートされているようだ。 しかも大幅にいろいろと変更があるため、具体的な手順は参考にならないかもしれない。 ここではT

  • パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog

    下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で

    パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog
  • dbpatterns.com

    This domain may be for sale!

  • 1