Kazuho's Weblog: さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた
さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた 先のエントリ「論理削除はなぜ「筋が悪い」か」で書いたとおり、データベースに対して行われた操作を記録し、必要に応じて参照したり取り消したりしたいという要求は至極妥当なものですが、多くのRDBは、そのために簡単に使える仕組みを提供していません。 daifukuは、RDBに対して加えられた変更をトランザクション単位でRDB内にJSONとして記録するためのストアドやトリガを生成するコマンドです。 % daifuku dbname tbl1 tbl2 > setup.sql のように実行すると、指定されたテーブル（ここではtbl1とtbl2）にセットすべきトリガや、更新ログを記録するためのテーブル「daifuku_log」を生成するCREATE TABLEステートメントなど、必要なSQL文をset
漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い（テーブルの行数を保持してる）のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
はてなにおける SSD の実績 - mura日記 (halfrack)
社内で SSD の寿命について話題に上がったので、ちょろっと X25-M G1 の運用実績に関する日記を書いてみよう。 プロダクション環境にある MySQL が動いているホストから、比較的 I/O が激しいものをチョイスして smartctl を叩いた結果がこんな感じ。 # smartctl -d ata -a /dev/sda smartctl version 5.36 [x86_64-redhat-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: INTEL SSDSA2MH080G1GC Serial Number: xxxxxxxxxxxxxx
MySQL を使ったお手軽メッセージキュー実装 - ドワンゴ 研究開発ブログ
はじめに この記事では、MySQL を使って簡単なメッセージキューを手軽に実装する方法を解説します。 メッセージキューとは、メッセージを一時的に溜めておき、順次処理するための仕組みです。迅速なレスポンスが必要な Web アプリケーションにおいて、時間のかかる処理を非同期に行うために、バックグラウンドで順次処理していくような場合に利用できます。 簡単なメッセージキューと言っても、大規模な運用にも耐えられる程度の速度と堅牢性を持ちます。 また、ここで解説している方法で作られたメッセージキューは、弊社ウェブサービスであるニコニコ動画に最近追加されたtwitter連携機能でも利用しています。 メッセージキューを作るにあたって 今回実装するメッセージキューは メッセージの追加(push)を高速に行う事ができる メッセージの取得(pop)はある程度高速に行う事ができる 多くのクライアントから同時に p
(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
仙石浩明の日記: 文字化けしていなくても MySQL 内の文字コードが正しくない場合がある
MySQL 5 からテーブルごとに文字列のエンコーディングを指定できるようになった (「そんなことは知ってるYO!」という人も多いと思うので、 そういう人は「これからが本題」 の部分まで読み飛ばして欲しい)。 例えばテーブルを作るときに、 mysql> CREATE DATABASE test; Query OK, 1 row affected (0.05 sec) mysql> USE test Database changed mysql> CREATE TABLE user ( name VARCHAR(255) ) CHARSET=utf8; Query OK, 0 rows affected (0.05 sec) などと 「CHARSET=utf8」 を指定すれば、 文字列を UTF-8 エンコーディングで格納する。 「CHARSET」 すなわち 「文字集合」 と、 エンコーディ
mysqlで自動更新されるtimestampをあえて更新しない
世間でも言われていますが、mysqlのtimestamp型はいろいろバッドノウハウの固まりではないかと思います。 最近はできるだけdatetime型にするようにしているのですが、すでにtimestamp型依存で動いているコードがある場合、alter tableするのも難しかったりします。 10.3.1. DATETIME、DATE、そして TIMESTAMP タイプや10.3.1.1. TIMESTAMP MySQL 4.1での性質 (いずれもMySQLマニュアル)にも諸々書いてありますが、気になるポイントは以下のあたり。 各テーブルの最初に現れるtimestamp型カラムは、明示的に更新をしていないとUPDATE, REPLACEで現在時刻に自動更新される 各テーブルの二つ目以降のtimestamp型カラムは自動更新されない 扱える期間が1970年～2037年である (datetime型
MySQL :: MySQL 8.0 リファレンスマニュアル :: 10.4 接続文字セットおよび照合順序
複数の文字セットおよび照合順序のシステム変数は、サーバーとのクライアントの通信に関係しています。 これらのいくつかは、これまでのセクションですでに説明されています。 character_set_server および collation_server システム変数は、サーバーの文字セットと照合順序を示します。 セクション10.3.2「サーバー文字セットおよび照合順序」を参照してください。 character_set_database および collation_database システム変数は、デフォルトデータベースの文字セットおよび照合順序を示します。 セクション10.3.3「データベース文字セットおよび照合順序」を参照してください。 その他の文字セットおよび照合順序システム変数は、クライアントとサーバー間の接続のトラフィックの処理に関わっています。 すべてのクライアントには、セッション固
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLでTF-IDFの計算、あと2つのベクトルの内積の計算 (2006-12-19)
http://vivian.reverb.jp/mysql4.1.html