タグ

dbに関するkiririmodeのブックマーク (222)

  • MockRunnerのJDBC Mockを使ってみた - たけぞう瀕死ブログ

    S2UnitDBを使ったユニットテストの支援機能としてExcelファイルからDBにテスト用データを投入したり、ExcelファイルとDBの内容を比較したりすることができます。ただ、実際にやってみるとわかるのですがこのExcelファイルのメンテナンスコストが馬鹿になりません。 そこで、実際にDBにアクセスするのではなく、フレームワークやJDBCドライバのレイヤで発行されたSQLを横取りし、期待通りのSQLが発行されたのかどうかを確認するという方法はどうだろう?と考えました。そういうライブラリを自作しようかとも思ったのですが(実際途中まで作っていたのですが)、世の中同じことを考える人はいるもので、MockRunnerのJDBC Mockという機能を使うとそのものズバリなことができるようです。 http://mockrunner.sourceforge.net/examplesjdbc.html

    MockRunnerのJDBC Mockを使ってみた - たけぞう瀕死ブログ
  • MockRunnerのJDBC Mockの便利機能 - たけぞう瀕死ブログ

    先日紹介したMockRunnerのJDBC Mockですが、実戦投入を前提にチームのメンバーに見てもらっているのですが、いろいろと機能があるようです。たとえば以下のような感じでSQLの期待値の比較方法を制御することができます。 // 大文字・小文字を無視 jdbcTestModule.setCaseSensitive(false); // 期待値のSQLに正規表現を利用可能にする jdbcTestModule.setUseRegularExpressions(true); 正規表現を使えるので、 jdbcTestModule.verifySQLStatementExecuted( "SELECT .* FROM TABLE WHERE ID=\\?"); なんて書いておくとテーブルのカラム追加・削除くらいではテストケースを直す必要がなくなります。便利ですね。欲を言えばSQLの改行や空白の差

    MockRunnerのJDBC Mockの便利機能 - たけぞう瀕死ブログ
  • http://mysql-casual.org/2010/12/mysql-casual-advent-calendar-2010-12-19.html

  • http://mysql-casual.org/2010/12/mysql-casual-advent-calendar-2010-12-20.html

  • 第38回 DBIx::Class:拡張性の高さが売りではありますが | gihyo.jp

    国内では微妙な立ち位置に ずいぶん間が空いてしまいましたが、今回はデータベース話の3回目として、DBICことDBIx::Classについてまとめてみます。DBICは、海外ではMooseやCatalystと並ぶモダンPerl界の三種の神器のひとつとしていまも広く宣伝されていますが、国内では、当初こそClass::DBIからの乗り換えを強力に推進する流れが見られたものの、最近ではあまり名前を聞くこともなくなり、むしろDBICからの脱却が潮流になっているかの印象を受けることさえあります。いったい何がどうなっているのか、例によって歴史を追いかけながら見ていきましょう。 もともとはオブジェクトを永続化するためのもの DBICの立ち位置を理解するには、まずはその先駆けとなったClass::DBIがどういうものであったかを理解しておく必要があります。 連載第36回でも紹介したように、マイケル・シュワーン

    第38回 DBIx::Class:拡張性の高さが売りではありますが | gihyo.jp
  • 索引の使い分けでパフォーマンスを向上できるケース

    連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状で広く使われているOracle9iの機能を基とするが、Oracle 10gで有効な情報も随時紹介していく。(編集局) 連載目次 前回「複合索引(コンポジット索引)が有効なケース」は、コンポジット索引を有効利用するためのチューニング・テクニックを説明しました。Oracleにはいままでに紹介した以外にも、さまざまな状況に応じて使用できる索引が用意されています。今回はそれらの索引の使用場面や特徴について説明します。 ファンクション・ベース索引の使用 Oracle8iから利用できるファンクション・ベース索引では、関数や式の値が事前に

    索引の使い分けでパフォーマンスを向上できるケース
    kiririmode
    kiririmode 2010/12/18
    "ビットマップ索引を使用する場合、更新処理実行時のロック単位がビットマップセグメント単位となる"
  • Test::Fixture::DBI で覚えるデータベーステスト - Articles Advent Calendar 2010 Hacker

    さて、今年も JPerl Advent Calendar の季節がやってきましたね。こんにちわこんにちわ zigorou です。 今回は拙作 Test::Fixture::DBI でデータベースのテストをするお話をしますよ! このモジュールはモバゲーオープンプラットフォームの API 開発時に必要にかられて作り、今では DeNA の社内でも普通に使われて来ているモジュールです。 レポジトリは github です。 はじめに とりあえずはテスト用の table を用意しましょう。 USE test; DROP TABLE IF EXISTS location; CREATE TABLE location ( id int(10) unsigned not null, user_id int(10) unsigned not null, title varchar(255) not null

    Test::Fixture::DBI で覚えるデータベーステスト - Articles Advent Calendar 2010 Hacker
  • 開発メモ: Tokyo TyrantによるHAハッシュDBサーバの構築

    来年のバレンタインデーに、正確には「2009-02-14T08:31:30+09:00」に、UNIX時間が「1234567890」を迎えることを発見してちょっと嬉しいmikioです。さて、今回は高効率ハッシュデータベースサーバTokyo Tyrantを用いてHAハッシュデータベースを構築する手法についてご紹介します。ちょっと難しいし非常に長い内容なのですが、最後までお付き合いくださいませ。 可用性と保全性 HA(High Availability:高可用性)とは、可用性(Availability)が高いことです。それでは説明になっていないので詳しく言い替えますと、システムに障害が起きにくくすることと、たとえ障害が起きたとしてもできるだけ迅速に復旧できるようにすることです。データベース系のシステムはユーザのデータを管理するという中核的役割を担うため、可用性を高めることは最も重要な課題となりま

  • ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering

    こんにちはこんにちは。最近お腹痛いばっかり言ってることで有名なiwanagaです。 DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。 僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。 ソーシャルゲームのためのMySQL入門一覧 ソーシャルゲームのためのMySQL入門 - Technology of DeNA ソーシャルゲームのためのMySQL入門2 - Technology of DeNA 「MySQL

    ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering
  • 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 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で

    NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ/秒を実現
  • PostgreSQLクラスタの動向

    はじめに 今回は、代表的なOSSデータベースである「PostgreSQL」を用いたデータベース・クラスタの、これまでの経緯と現状を解説します。 1. 最初はシングル・マスターのレプリケーション 最初に登場した"PostgreSQLクラスタ"は、「Slony」と呼ぶ、シングル・マスターのレプリケーション・ソフトでした。レプリケーションとは、データベース全体のコピーのことです。これを高可用性(HA)の確保や性能の向上に用いることができます。 Slonyのバージョン1.0がリリースされたのは2004年です。6年も前になります。Slonyは、トリガーの機構を使ってデータベースの変更を検出し、これを複数のスレーブに転送します。これにより、1つのマスターを利用して複数のスレーブにデータベースのコピーを置くことができるようになっています。図1に、その概要を示します。 Slonyの特徴は、原理が単純な点で

  • [ThinkIT] 第5回:高度なインデックスの活用 (1/2)

    ここまでは単一の列に対して作成するインデックスを前提にお話ししてきました。しかし、インデックスは同一テーブルの複数の列に対してまとめて設定することもできます。検索条件に複数列を指定する場合などは、このようなインデックスを使えばさらに効率よく処理を行うことができます。

  • データベース・クラスタの概要

    はじめに これから4回にわたり、PostgreSQLを中心に、データベース・クラスタについて解説します。以下の内容を予定しています。 第1回: データベース・クラスタの概要 第2回: PostgreSQLクラスタの動向 第3回: 主要なPostgreSQLクラスタ(前編) 第4回: 主要なPostgreSQLクラスタ(後編) 1. データベース・クラスタとは データベース構築の基は、1つのサーバーに1つのデータベースを構築し、運用することです。しかし、いろいろな理由から、1つのデータベースを複数のサーバー(仮想サーバーを含む)にまたがって構築するケースが増えてきました。 連載では、いろいろな種類のデータベース・クラスタとその用途、主な技術や実装例を解説します。解説の対象となるデータベース・クラスタとは、1つのデータベースを、複数のサーバーや仮想サーバー上に構築するシステムを指します。

  • 知って得するInnoDBセカンダリインデックス活用術!

    InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が

    知って得するInnoDBセカンダリインデックス活用術!
  • 第3回 DBIx::Classでデータベース操作(3) | gihyo.jp

    Resultクラスの拡張 Resultクラス、ResultSetクラスは自分の好みに合わせて拡張できます。 カラムのinflate/deflate $tweet->created_dateのようなつぶやきの日付を取りたい場合、カラムの値そのままではなくDateTimeオブジェクトを返してくれたらうれしいと思います。その機能を実現するのがカラムのinflate/deflate機能です。inflate(膨らませる)は文字どおりカラムのデータをPerlオブジェクトに変換する機能で、deflate(収縮させる)はPerlオブジェクトをカラムデータへ変換する機能です。 Resultクラス内で __PACKAGE__->inflate_column('column_name', { inflate => sub { # カラムデータからオブジェクトを作って返す }, deflate => sub {

    第3回 DBIx::Classでデータベース操作(3) | gihyo.jp
  • 第3回 DBIx::Classでデータベース操作(2) | gihyo.jp

    Schema::Loaderの利用 第3回(1)でResultクラスには各テーブルがどのようなカラムを持っているかを定義する必要があると書きましたが、「⁠そのようなテーブル情報はデータベースから自動的に取得できるのでは?」と思った方もいるかもしれません。DBIx::Class::Schema::Loaderという別で配布されているモジュールを使用すると、Resultクラスでのテーブル情報の定義を省略できます。 Schema::Loaderを使うべきか 軽いデータベース操作であればSchema::Loaderがお手軽ですが、そうではない場合はResultクラスにテーブル定義をしっかりと書くのがお勧めです。Resultクラスにテーブル定義を書くべき理由は主に2つあります。 ●DBIx::Classからデータベースを作成できる Resultクラスにテーブル定義を書くと、DBIx::Classから

    第3回 DBIx::Classでデータベース操作(2) | gihyo.jp
  • MySQLのインデックスを学ぶ (2) - @kyanny's blog

    Linux-DBシステム構築運用入門をさらに読んでいる。前回は主に Chapter 8 を読んだ内容をメモったが今回は Chapter 9 の内容。 INSERT とインデックス インデックスが多いと INSERT の性能が落ちる、という話題はなんとなく見聞きしていたが、何故性能が落ちるのかについてはわかっていなかった。詳しくは Linux-DBシステム構築運用入門 P210 の図を見てもらうとして*1、ランダム INSERT よりも昇順 INSERT のほうがインデックスのリーフブロックの仕様効率が良い == インデックスのサイズが小さくなる == バッファキャッシュに載りやすくなる == I/O が減る、というのは知らなかったしとても勉強になった。インデックスを更新するために INSERT でもディスクから読み込みが発生する、というのも知らなかった。 クラスタインデックスとランダム I

    MySQLのインデックスを学ぶ (2) - @kyanny's blog
  • IBM Developer

  • ウノウラボ Unoh Labs: PHPで暗号化・復号化あれこれ

    GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠

    ウノウラボ Unoh Labs: PHPで暗号化・復号化あれこれ
  • 第35回 DBI:生のSQLが散らばると言う前に | gihyo.jp

    Perldbm いまでは省みられることも少なくなりましたが、Perlには1989年にリリースされたバージョン3.0以降、dbmと呼ばれるシンプルなデータベースにアクセスする機構が標準で組み込まれています。このdbmは、いわゆるリレーショナルデータベースとは違ってキーと値の組み合わせをディスクに保存できるだけのものですが、ハッシュ(当時はまだ連想配列と呼んでいました)と結びつけることでタブ区切りファイルなどを読んでいくより高速に検索ができたため、ユーザ環境に永続的なデータを保存する手段のひとつとして重宝されていました。Perl 3/4の時代にはdbmopenというコマンドが使われていましたが、この機構はPerl 5になって一新され、いまではより汎用的なtieというコマンドを使うことになっています。この仲間としては古くからあるBerkeley DBやGDBMなどのほか、最近では平林幹雄氏のT

    第35回 DBI:生のSQLが散らばると言う前に | gihyo.jp