高速SSDの落とし穴。データベースで利用するときはご注意を！
今年はSSDの台頭がめざましい。価格の低下、大容量化、そして高速化、さらには低電力化まで期待できるというからもうHDDの出番はなくなるんじゃないだろうかというぐらいの勢いである。しかしそんなSSDもデータベースで利用する時には気をつけてもらいたい。 MySQL Performance Blogでインテル製SSDを使って検証した結果がレポートされている。 インテル製SSDはめっぽう早い。彼らのテストでは一秒間に5250回もの書き込みが出来たそうだ。しかしそれはライトバックキャッシュが有効になっているときの話であって、ライトバックキャッシュを無効にすると書き込みは秒間1200回まで低下したらしい。（それでも高速だが。） で、このインテル製SSDのライトバックキャッシュはくせ者で、バッテリー等で保護されていない。つまり、ライトバックキャッシュにダーティな（まだディスクへの書き出しが完了していない
FriendFeedはどのようにスキーマレスなデータをMySQLに格納しているか - モジログ
FriendFeedのBret Taylorが、スキーマレスなデータ（スキーマ（型）に制約されないデータ）をMySQLに格納する方法を紹介している。実際にFriendFeedで使っている方法で、最新のものらしい。 Bret Taylor's blog - How FriendFeed uses MySQL to store schema-less data http://bret.appspot.com/entry/how-friendfeed-uses-mysql MySQLを通常のRDB的な方法でなくストレージ的に使い、JOINを使わないでスケールさせるというもの。CouchDBなどにも近い、最近有力になりつつあるアプローチだ。これを、実績もあり普及しているMySQLを使って実現し、言語はPythonで実装している。 メインのテーブルは次のようなもの。 CREATE TABLE ent
「キー・バリュー型データストア」開発者が大集合した夜
「発表者が自分よりも若い人ばかりだ」。外見が20代にしか見えない東京工業大学の首藤一幸准教授（1973年生）の驚くさまが、少し面白かった。2009年2月20日の夜、多くのWeb企業が注目する「キー・バリュー型データストア」を開発する若手技術者が、東京・六本木のグリー本社に一堂に会した。 キー・バリュー型データストア（またはキー・バリュー型データベース）は、大量のユーザーとデータを抱え、データベースのパフォーマンス問題とコスト高に頭を悩ませるWeb企業が注目する技術である。記者は同日に開催された「Key-Value Store 勉強会」に参加させてもらった。午後7時から11時まで、キー・バリュー型データストアを開発・研究する若手技術者が立て続けに登場し、1人15分の持ち時間で成果を発表し、議論を重ねるという集まりだ。 呼びかけ人であるプリファードインフラストラクチャー（PFI）最高技術責任者
表領域に空きがあるのにORA-01536が出てINSERT出来ないとき
OracleRDBMSを利用している人向けのお話。 このORA-01536はかなりメジャーなノウハウらしいのでいまさら言及するのもあれだけど、表領域はまだ空きがあるのに！とあわわわ、ってならないためにまとめておきますね。引っかかる情報は多いほうがいいし。 原因tablespace quota がどうの、って書いてあるとおりで、INSERTなどを発行しようとしているユーザーの、その表領域に対するquota(クオータ)が不足しています。クオータは領域の使用量に対する制限で、"ユーザー：表領域"ごとに設定できます。設定されているクオータは SELECT * from user_ts_quotas; -- とか SELECT * from dba_ts_quotas; で確認できます。 対策1. UNLIMITED TABLESPACEシステム権限の付与まず、クオータ(制限)がまったく存在しないよ
どうも世間では、思ったよりDBエンジニアが不足している様だ: 不倒城
ちょっと技術的な話。oracle分かる人にしか分からないかも。 最近取引先のシステムを見る機会が何度かあったのだが、昨日すんごいとこ見た。 DBが重くて業務にならないというから、ちょっと中を覗かせてもらったらもうエラいこっちゃ。 ・業務ロジックの殆どをファンクション・プロシージャで構成している。なのに、キャッシュヒット率が妙に低い。 ・調べてみようと思ったら一回もstatspackが取得されていない。(担当者には、「statspack?syslogならとってあるんですが…」と言われた) ・各テーブルのindexがどういう訳か全列に貼られている。ちなみにindexは全テーブル例外なくその一個だけ(プライマリキーを除けばだが)。 ・と思ったら、PKが文字列だったりするテーブルがあちらこちらにある。 ・試しにファンクションを一つ二つ見てみたら、なんか普通にクロス結合されまくっていてちょっとくらっ
クラスタリングファクタによってSQLのパフォーマンスが変わる話 - 極北データモデリング
昨日の実験では、両側にインデックスがある場合、マージ結合とネスト化ループ結合の速さがハッシュ結合と同等かそれ以上になってしまった。 少量のマスタと大量のトランザクションの結合は、ハッシュ結合が圧勝してしかるべきなので何だこりゃと思ったのだが、これはテストデータが都合よく整列しているせいだとわかったので、結合カラムの値を更新して測定し直してみた。 データを作り直す 昨日の時点では、トランザクションデータの作り方に問題があって、結合カラム(tid)が同じ値のレコードが一箇所に固まっていた。 こんな感じ: bench=# select * from history limit 10; tid | bid | aid | delta | mtime | filler -----+-----+--------+-------+----------------------------+--------
InnoDBのファイルサイズ管理
最近、InnoDBのデータ領域（テーブルスペース）が成長してしまって元に戻すことが出来ない場合の対処についてよく質問されるので、今日はテーブルスペースが成長することへの対策について説明しよう。（ここのところMySQLネタが続いているが、Planet MySQL日本語版を意識しているわけではないのであしからず！！＜＜ホントかよ？！＞俺） InnoDBのテーブルスペースが成長してしまうのは、ズバリ自動拡張しているからである。テーブルスペースに対して何もオプションを指定しないと、デフォルトでは次のような設定と同じテーブルスペースが作成される。 [mysqld] innodb_data_file_path=ibdata1:10M:autoextend サイズは10MBしかないが、自動拡張するのである。自動拡張してしまうと何が問題なのかというと、データが増えた場合にファイルシステムの空き領域を使い切
JDBC経由によるVARCHARへのINSERTの文字数制限 Kaname's hackday
Java.sql.PreparedStatementインターフェースを使用してOracleデータベースにデータを登録する際、setString()メソッドを使用してバインドできる文字列のサイズには制限があるようです。 Oracleデータベースとしてのバインドサイズの上限はVARCHAR2、NVARCHAR2の最大サイズ（4000バイト）と同じなのですが、Oracle JDBCドライバでPreparedStatementインターフェースのsetString()メソッドを使用した場合、使用しているキャラクタ・セットによってより厳しいサイズ制限が課せられるようです。 「Oracle9i JDBC開発者ガイドおよびリファレンス2(9.2)」の中の「ThinドライバによるSQL CHAR データ・サイズ制限」というトピックで解説されている内容を見ると、データベース・キャラクタセットがJA16SJIS
ソフトウェア開発の効率化を支援する SI Object Browser シリーズ
div.hs-menu-wrapper > ul > li" data-pacnav-mobile-width="820"> SIOB OBER OBPM
マスタメンテナンスで未来のデータを入力したいんですけど - 極北データモデリング
マスタメンテの扱いは毎回困るところ。 どうもマスタデータには「最新」系のものと「無時間」系のものがあるらしい。 いつのトランザクションデータと結合しても問題ないのが「無時間」のマスタで、問題を起こすことがあるのが「最新」のマスタ。 元号マスタなんてのは無時間。 商品マスタとか部門マスタなんかが「最新」のマスタ。属性が今時点の値になっているので、古ーいトランザシクョンデータと結合すると「商品名が(過去の事実と)違う」「部門の所属セグメントが違う」みたいなことになる。 そういう属性はトランザクションデータ側にコピーしておけばとりあえず問題ないんだけど*1、ほんとに困るのは未来のデータを前もって入力したいとき。 例えば4/1から新入社員が1000人入ってくる会社で、3月中に新人の情報をちまちま入力していると、3月中の社員数が狂ってしまう。正しくは4/1の明け方に1000人分入力しなくてはならない
My wonderful living» ブログアーカイブ » 重複レコードを取得する
データを集計する上でDISTINCTを利用し、重複レコードを除外する事があるが、逆に重複レコードのみ取得したいという機会はあまりない。 しかし、データの整合性を確認するために、重複レコードのみ取得したいと思ったのだが、DISTINCTの逆がないためどうやって抽出しようか非常に迷った。 どうやら以下の方法で取得できるようだ。 ■サンプルSQL
Java+PostgreSQLでBLOBを扱う その1 - MOYO Laboratory
例外が起きなくてもディスクスワップが多発しているようだし、ひょっとしてファイルの全バイナリから巨大な SQL でも組み立てているのだろうか? 今回はそこらへんをちょっと突っ込んで調べてみようと思う。 何とも不安に駆られながら PostgreSQL 7.4 のソースを取得し、同封されている JDBC ドライバのソースから setBinaryStream を検索してみる。JDBC 3 を使っているのだが、実際に使われているのは JDBC 1 の実装らしい (JDBC 3 はソースこそあれ中は未実装)。 public void setBinaryStream(int parameterIndex, InputStream x, int length) throws SQLException { if (connection.haveMinimumCompatibleVersion("7.2"))
電話番号の帰属先は何処
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45666 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA
HAVING句の力
＠IT：Databaseフォーラム全記事インデックス オラクルパーティショニング
リレーショナル・データベースの世界
ISAM - Database Management Systems - higepon blog
https://labs.cybozu.co.jp/blog/kazuho/archives/2008/11/_ssd.php
[ヅラド] Java の PreparedStatement で MySQL の LIKE を扱う方法