Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ
スキーマ不定のデータをRDBに永続化する方法の比較 — ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
データベースの間違った使い方10項目
一般的なシステムで広く利用されているリレーショナルデータベースですが、システムの進化と共にデータベースの構造も複雑になりがちです。RestMQの作者、Gleicon Moraes氏の公開したスライドがシステムが複雑化していく様子をわかりやすく説明した上で「アンチパターン」を提示していました。 それによるとデータベースのアンチパターンは以下の通り。 動的なテーブルの作成 テーブルをキャッシュとして使う テーブルをキューとして使う テーブルをログとして使う 分散したグローバルなロック ストアドプロシージャ 使われない項目 JOIN地獄 ORMによって繰り返されるクエリ 負荷のコントロール どれも理由があって採用されるデザインですが、確かに後に問題を引き起こした経験もあり耳が痛い感じですね。スライド内ではそれぞれの問題についての解決策としてMongoDBやRestMQなどの利用を進めています。「
Architecture by Accident
This document discusses how architecture emerges even when not initially planned. It begins with an overview of databases, message queues, and caching as common architectural elements that emerge over time. The document then provides examples of how simple applications and data needs can evolve into more complex architectures with multiple servers, databases, caching, and services. It emphasizes t
クラウドに最適化したMySQLのフォーク「Drizzle」が正式版公開
MySQLからフォークし、クラウド用途に最適化して開発された「Drizzle」が3月15日に最初の正式版を公開しました。 MySQLはよく知られたオープンソースのリレーショナルデータベースです。そのMySQLを、トランザクション機能を維持したままクラウドのような大規模分散環境での並列処理とマルチコアCPUに最適化したのが「Drizzle」です。 多くのWebサービスのバックエンドでは、高速なデータベース処理を実現するために多数のMySQLサーバを用いた分散処理をしていますが、Drizzleではそうした用途に特化して設計されています。 NoSQLに対するSQLからの回答 Drizzleは、大規模なWebサービスのバックエンドデータベースとして利用することを想定しているため、Web系サービスのバックエンドとしてはほとんど使われないだろう機能が省かれています。例えば、ACL（アクセス制御リスト）
cassandra調査レポート
個人的な興味からcassandraについてしらべてみました。 間違っている部分など、指摘や質問などあればお知らせいただけるとうれしいです。Read less
データベースサーバを複数台構成とか2010年代には流行らない - blog.nomadscafe.jp
奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。 奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。 ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。 The Art of モバゲー Capacity Planning The Art of Mixi-mobile-appli Capacity Planning 最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖
up and running with cassandra
Cassandra is a hybrid non-relational database in the same class as Google’s BigTable. It is more featureful than a key/value store like Riak, but supports fewer query types than a document store like MongoDB. Cassandra was started by Facebook and later transferred to the open-source community. It is an ideal runtime database for web-scale domains like social networks. This post is both a tutorial
Rackspace Cloud Computing & Hosting | NoSQL Ecosystem
By Jonathan Ellis, Systems Architect Unprecedented data volumes are driving businesses to look at alternatives to the traditional relational database technology that has served us well for over thirty years. Collectively, these alternatives have become known as “NoSQL databases.” The fundamental problem is that relational databases cannot handle many modern workloads. There are three specific pr
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
―CAP定理のジレンマをOracle RACで理解する―(1/2)：クラウドを理解するためのサーバ技術：エンジニアライフ
2009年は、いよいよクラウド時代の幕明けですね。世の中的にも大不況ですから、導入・運用コストを下げることが期待されるクラウドはまさにうってつけではないでしょうか？ しかし、インターネットのあちら側にあるシステムのことは、いまいちピンとこないことが多いですね。最近よく聞く「CAP定理」なんてのもそのひとつだと思います。この定理時代は、前からあったものですが、もっともらしいことを言って煙（いや雲か。）に巻かれている気がしませんか。そんな「CAP定理」をOracleの分散データベースである「Oracle RAC」を例に取り説明してみたいと思います。 1. CAP定理のジレンマ クラウドの特徴のひとつとして、CAP定理が挙げられます。 CAP定理とは、以下の３つを同時には満たせないという定理です。 C：Consistency（データの一貫性） データの更新後、ほかからそのデータを参照した場合、必
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
“MySQLの父”がOpen Database Allianceを設立，独自のコミュニティ版MySQL「MariaDB」を推進
“MySQLの父”がOpen Database Allianceを設立，独自のコミュニティ版MySQL「MariaDB」を推進 MySQL ABの共同創設者Michael Monty Widenius氏らは2009年5月13日（現地時間），グループ「Open Database Alliance」を設立したと発表した。MySQLをベースにWidenius氏が開発したコミュニティ版「MariaDB」のサポートとサービスを行う。 Widenius氏はMySQLを開発した技術者。MySQL ABが米Sun Microsystemsに買収された後，退社して自らのデータベース技術サポート会社「Monty Program AB」を設立していた。OracleがSunを買収した際には，MySQLの将来について懸念を表明していた（関連記事）。MariaDBは，MySQLをベースにWidenius氏が開発してい
http://www.interdb.jp/techinfo/mysql/m-2-10.html
[InterDB] [著者HP] [PREVIOUS][UP][NEXT] ■■■■ [ロック] ■2-10■ ロック ■■■■ MySQLはWRITE(書き込み)ロックとREAD(読み出し)ロックの2種類をサポートしていますが、テーブル型毎に`ロック'の挙動が異なります。 以降、使用頻度の高いMyISAM型とInnoDB型のロックについて説明します(【表.2-8】参照)。 表.2-8 テーブル型毎のロックの挙動 ========================================================================================================================= テーブル型 | ロックレベル | デッドロック状態への対処 | 備考 | ===========+================
A5:SQL Mk-2 - フリーのSQL開発ツール/ER図ツール
A5:SQL Mk-2は複雑化するデータベース開発を支援するために開発されたフリーのSQL開発ツールです。 高機能かつ軽量で、使い方が分かりやすいことを目標に開発されています。 SQLを実行したり、テーブルを編集するほかに、SQLの実行計画を取得したり、ER図を作成したりすることが出来ます。 特徴・機能 OCI接続・直接接続・ADOまたはODBCを介したDBへの接続 Oracle DatabaseはOCI経由の接続・直接接続が出来ます。 PostgreSQLとMySQLは直接接続が出来ます。 Microsoft SQL Serverは、OLE DBプロバイダを直接呼び出した接続ができます。 IBM DB2は、ODBCドライバを直接呼び出した接続ができます。 その他のデータベースは、ADOまたはODBCを利用して接続します。 Oracle, PostgreSQL, MySQLは、A5:SQL
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
インデックスの基礎知識
■ インデックスとは データベースの世界で、インデックス(索引)とはテーブルに格納されているデータを 高速に取り出す為の仕組みを意味します。 インデックスを適切に使用することによってSQL文の応答時間が劇的に改善 される可能性があります。 インデックスにはB-Treeインデックスをはじめ、ビットマップインデックス、 関数インデックスなどの種類がありますが、ここでは最も一般的に使われ、かつ ほとんどのDBMSでサポートされているB-Treeインデックスについて解説します。 ※ CREATE INDEX文でオプションを指定しない場合は通常B-Treeインデックスが 作成されます。 ■ B-Treeインデックスのしくみ B-Tree(Balanced Tree)インデックスは次のようなツリー状の構造になっています。 ツリーの先頭はヘッダブロックと呼ばれています。ヘッダブロックでは、キー値の 範囲
パフォーマンスセラピー / データベース・バッファ・キャッシュのチューニングを学ぶ
データベース・バッファ・キャッシュのチューニングは、ディスクI/Oを低減させることでパフォーマンスダウンを防ぐのが目的です。ディスクへの読込みや書込みは、メモリーに比べるとかなり時間がかかりパフォーマンスが低下する可能性があるので、必要なOracleブロックがメモリー内に存在できるように調整する必要があります。 第10章で復習したような共有プールの調整を行うと、残りの利用可能なメモリーをデータベース・バッファ・キャッシュに割当てることができ、よりディスクI/Oを低減できるのでパフォーマンスチューニングには有効です。 本章では、データベース・バッファ・キャッシュのチューニングについて復習しましょう。 まず、データベース・バッファ・キャッシュの構成について復習します。 (1)データベース・バッファ・キャッシュの役割 SQL実行時にサーバー・プロセスがデータベース・バッファ内に必要なデ
画像もDBに格納して管理する －扱いがめんどうなLOB(ラージオブジェクト)は使わない方法も含め
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Health Insurance High Speed Internet Work from Home Healthy Weight Loss Best Penny Stocks Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
備忘録：JDBCメタデータ - jfluteの日記
