PDOの真の力を開放する - PHPでデータベースを扱う(3)
ちょっと遅れましたが、シリーズの第３回です。前回までに論じた内容をふまえて、簡単な実装を示します。↓前回までの内容はこちら。 DAOの悪夢 - PHPでデータベースを扱う(1) - 泥のように ドメイン駆動設計という救世主 - PHPでデータベースを扱う(2) - 泥のように 題材 「記事にタグを設定できるブログ」みたいなシステムを考えてみます。ブログ記事を示すEntryテーブル、タグを表すTagテーブルの二つを用意しました。MySQL WorkbenchによるER図(鳥足記法)は以下になります。 1つのEntryに対して複数のTagがある、１対多の関係です。同じTagが複数のEntryに関連するため、多対多の関係と見なすこともできそうですが、タグ程度だとあまり意味がないので、これ以上のテーブル分割はやめておきます。 Entryテーブルの主キーがentryIdと冗長な名前をしているのは、自
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
Open Tech Press | MySQLデータのバックアップ方法
2007年5月31日10:53 Tom-Adelstein、Bill-Lubanovic（2007年5月29日（火）） ファイルやディレクトリのバックアップは比較的簡単だが、データベースのバックアップとなると、いくつか特別な工夫を施す必要がある。ここではMySQLを取り上げているが、同じ原理はPostgreSQLやその他のリレーショナルデータベースにもあてはまる。 本稿は、最近O’Reillyから出版された書籍『 Linux System Administration 』の抜粋。 MySQLサーバを休みなく稼働させ続ける必要がないなら、以下に示すような圧縮なしのオフラインバックアップ手法が手っとり早い。 MySQLサーバを停止させる。 # /etc/init.d/mysqld stop MySQLのデータファイルおよびディレクトリをコピーする。例えば、MySQLのデータディレクトリ/var
MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.7.1.6 GRANT ステートメント
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
勝手に図解するmemcached
先日、Brian Akerとミクシィの前坂氏によるmemcachedのセミナーがあった。 実践で使用する上での話や開発最前線の話が聴けたため、セミナーは非常に盛況であった。筆者にとっても非常に勉強になる内容だった。セミナーの資料はBrian Aker氏のサイトから入手できるのでセミナーに参加出来なかったひとはこの資料を読んで自習して頂きたい。 が、いかんせん氏のスライドはパッと見ただけではなんとなく分かりづらいように俺は思う。なぜだろうか？それはきっと図がないからだ・・・と勝手に想像する。オトコたるもの、時には勝手な憶測で突き進むのもアリだ。ちなみにBrianのスライドはほとんど要点の箇条書きになっている。これでは解説がないと、特に新規にmemcachedやMySQLを学習している人たちには分かりづらいだろう。 というわけで氏に代わり、memcachedがどのように既存の仕組みを置き換える
NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ／秒を実現
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか？ それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範（まつのぶよしのり）氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」（英語）をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
hansode.org - このウェブサイトは販売用です！ - hansode リソースおよび情報
このウェブサイトは販売用です！ hansode.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、hansode.orgが全てとなります。あなたがお探しの内容が見つかることを願っています！
HTML5関連のデータベースAPIとWeb Storageの基本
HTML5時代にはWebブラウザでデータベースを扱える 最近のWebの世界で、トレンドになっている技術の1つとして、「HTML5」があります。Webブラウザ上で動作するアプリケーション（Webアプリケーション）が一般化したことがあって、Webブラウザに求められる機能が増えてきました。そこで、その状況に即してHTMLをバージョンアップしようという流れが起こり、HTML5の仕様策定が進められています。 HTML5では、HTMLのタグの仕様だけでなく、周辺のAPI（Application Programming Interface）の仕様も明確化して、Webブラウザによる動作の差異をなくそうという方向になっています。また、Webアプリケーションを作る上で従来不十分だった機能について、各種の新しいAPIも追加されます。 APIの中で、特に不足していた分野の1つとして、「データ管理」が挙げられます。
データベース・クラスタの概要
はじめに これから4回にわたり、PostgreSQLを中心に、データベース・クラスタについて解説します。以下の内容を予定しています。 第1回: データベース・クラスタの概要 第2回: PostgreSQLクラスタの動向 第3回: 主要なPostgreSQLクラスタ（前編） 第4回: 主要なPostgreSQLクラスタ（後編） 1. データベース・クラスタとは データベース構築の基本は、1つのサーバーに1つのデータベースを構築し、運用することです。しかし、いろいろな理由から、1つのデータベースを複数のサーバー（仮想サーバーを含む）にまたがって構築するケースが増えてきました。 本連載では、いろいろな種類のデータベース・クラスタとその用途、主な技術や実装例を解説します。解説の対象となるデータベース・クラスタとは、1つのデータベースを、複数のサーバーや仮想サーバー上に構築するシステムを指します。
Twitter、「拡張性と可用性」を求めてMySQLからCassandraへ乗り換える | OSDN Magazine
人気のマイクロブログサービス「Twitter」を提供する米Twitterが、使用するデータベースをFacebookが開発した「Cassandra」に移行しているという。データ量の増加に自動的に対応できる拡張性や可用性などを評価した結果のようだ。 Twitterのソフトウェア開発者、Ryan Kings氏がMyNoSQLの取材に応じて明らかにした。MyNoSQLはSQLではないデータベースの総称「NoSQL」に関する情報を集めたブログ。 Kings氏によると、TwitterはシェアドMySQLとMemchacheを組み合わせたシステムを利用してきたが、データの増加ペースが急増しており、対応が急務となっていた。人件費をはじめとした運用費用がかさんでおり、共有MySQL設定を自動化するか、他のデータベースへの乗り換えを考慮したという。Cassandra以外のデータベースも検討したが、マシンの追加
Twitterが、Cassandraの本採用を断念。「いまは切り替えの時期ではない」
「いまは新しい技術への大規模な移行をする時期ではないと確信している」。Twitterは、サービスの核となるツイートを保存するデータベースを、MySQLによる大規模分散データベースから、NoSQLデータベースであるCassandraへ移行しようとしていました。しかしCassandraへの移行作業を中止し、引き続きMySQLでの運用を継続すると、Twitter Engineering Blogへのエントリ「Cassandra at Twitter Today」で明らかにしました。 これは戦略の変更だ Twitterは利用者からのツイートを、Scalaによって独自開発したミドルウェア「Gizzard」とMySQL、そしてmemcachedを用いた大規模分散データベースに保存しています。 しかしこうした複雑なシステムによる運用は非常に手間がかかり、人的コストを中心としたコストの増加が非常に大きくな
Oracleの機能を使って表の結合を高速化する（1/4） － ＠IT
本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状で広く使われているOracle9iの機能を基本とするが、Oracle 10gで有効な情報も随時紹介していく。（編集局） 連載目次 前回「表の結合を極めるチューニング・テクニック」では、絞り込み条件がない結合を含むSQL、絞り込み条件のある結合を含むSQLについて実例を基に最適な結合方法を説明しました。 今回は、Oracleの機能である「マテリアライズド・ビュー」「BITMAP JOIN INDEX」「クラスタ」を利用した結合処理に関するチューニング・テクニックについて説明します。 マテリアライズド・ビューを理解する 結合処理な
オラクル マテリアライズドビューメモ(Hishidama's Materialized view for Oracle Memo)
リフレッシュ方法を指定しない場合はforceになる。 後からリフレッシュ方法を変えることも出来る。 SQL> alter materialized view MV_TEST refresh fast; マテリアライズド・ビューが変更されました。 完全リフレッシュ マテビューを計算し直す際に、全データを作り直す。データの変更箇所が少ないなら効率は悪いことになるが、ロジックは一番単純だ。 完全リフレッシュのマテビューを作る際には、「refresh complete」を指定する。個人的には「refresh all」の方が分かり易かったと思うけど…わたしゃ英語圏の人間じゃないからな～ create materialized view MV_TEST refresh complete as select YYMM_GROUP, SHOP_CODE, sum(AMOUNT) SUM_AMOUNT fr
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mikuriya.biz