複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
SQLを使うなら理解しておきたいアルゴリズム？(というか、select文の書き方) - where・order by・join・group by - 何かしらの言語による記述を解析する日記
SQLのselect文の書き方の覚書です。 なお、本文中の動作確認は「mysql Ver 5.0.67」で行いました。 2009/10/05 13:30 追記 予想外に多くのアクセスとブクマをいただき、正直驚いております。 本文はsqlの内部処理には一切触れておりません。ごく普通のsqlの書き方にのみ触れています。 釣りのつもりはありませんが、釣られたと感じた方にはごめんなさい。 目次 説明に使用するデータ構造？(というかテーブル) 抽出(where句) ソート(order by句) ソートの例(昇順) ソートの例(降順) 結合(join句) 集計(group by句) 関連記事 説明に使用するデータ構造(というかテーブル) select文の使い方を説明するために、以下のようなテーブルを使います。 create table countries ( name nvarchar(30), cu
クックパッドとHadoop - クックパッド開発者ブログ
はじめまして。今年の5月に入社した勝間@さがすチームです。 入社してからは、なかなか大変なことも多いですが、最近はお酒好きが集まって月曜から飲み合う 「勝間会」なるものも発足して、仕事面でも仕事以外の面でも密度の高い毎日を過ごしています！ さて、僕は「さがす」チーム所属ということで、普段はレシピを「さがす」ユーザの満足度を上げるために、 クックパッドの検索まわりについて、いろいろな開発を行っています。 一方で、ユーザの「さがす欲求」について深く知るために、大規模なデータ解析を行い、欲求の分析を行う機会も増えてきました。 ところが、クックパッドのログは膨大な数があるので、一口のデータ解析と言っても通常のバッチ処理だと間に合わないため、 分散処理環境の必要性が高まってきました。 そこで、まずは手軽に試せる分散処理の王道ということで、最近ではHadoopを使ったデータ解析環境を整備しています。
データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基本原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 Oracle、SQLServer、MySQLと色々なDBのチューニングをしてきましたが、
Kazuho@Cybozu Labs: Perl のテスト用に MySQL 環境を自動で構築するモジュール Test::mysqld を書いた
ORM やウェブアプリケーション関連のライブラリなどのテストケースを書くにあたっては、 RDBMS へのアクセスが必要になります。しかし、SQLite のようなスタンドアローンのデータベースと比較すると、サーバ型データベースである MySQL に接続してテストを書くのは、既存の MySQL の権限設定やデータベース名を気にする必要があったりと、いろいろ不便です。そこで、MySQL のインスタンスをテンポラリディレクトリに自動生成し、テストが終わったら削除してくれる Perl モジュール Test::mysqld を書きました。こんな感じで使います。 use DBI; use Test::mysqld; use Test::More; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '' }, # TCP接続を
オレオレ検索窓を設置しよう - mixi engineer blog
まだピクミン2をクリアしてないのでケジメ的に新作ゲームを買えないmikioです。今回は、Tokyo Cabinetを使って激烈簡単に特定サイトの専用の検索機能を設置する方法について説明します。クローリングから検索までを10分くらいの作業で可能にします。 特定サイトの検索エンジン Web全体の検索機能を作るのは、途方もない技術力と設備を持っているGoogleやMicrosoftなどのビッグプレーヤでないと難しいのが現実です。でも、自分が気に入っているいくつかのサイトを対象とした検索エンジンを作るのであれば個人だってできます。また、インターネットから手が届かないイントラネットのコンテンツの検索機能は自分達で手がけないと構築できません。 ということで、企業用の検索システムが数多く売られていますし、LuceneやGroongaやHyper Estraierなどのオープンソース製品も世に多数存在しま
GT Nitro: カーレーシング・ドラッグレーシングゲーム - Google Play のアプリ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
もう1つの、DBのかたち、分散Key-Valueストアとは
もう1つの、DBのかたち、分散Key-Valueストアとは：分散Key-Valueストアの本命「Bigtable」（1）（1/3 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 クラウド時代のデータベース「分散Key-Valueストア」 グーグルがインターネットの世界をここまで席けんできた最大の理由は何でしょうか。実は、それは同社の優れた検索技術ではありません。グーグルが成し遂げた最も大きなブレークスルーの1つは、同社が生み出した巨大な分散データストア、「Bigtable」にあります。 Bigtableは、Google検索をはじめ、YouTubeやGoogle Map、Google Earth、Google Analytics、Goog
mysqlでいちいちshow databasesとか打つのがめんどい→readlineのマクロで解決 - （ひ）メモ
MySQLでいちいちshow tables;とか打つのがだるい。\tみたいなalias設定できないのかなぁ http://twitter.com/weboo/status/1658300902 おぉ、readlineのマクロを使えばいいのかー http://twitter.com/weboo/status/1658314333 なるほ！ってことでちょっと設定してみました。 # ~/.inputrc $if mysql "\C-xd": "show databases;" "\C-xt": "show tables;" "\C-xu": "select user,host,password from mysql.user order by user,host;" "\C-xb": "select user,host,db from mysql.db order by user,host;"
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
PerlとRubyで省メモリなハッシュを使おう - mixi engineer blog
サボっていた早朝ジョギング＠駒沢公園を再開して2週間たち、やっと抜かれる数より抜く数の方が増えてきたmikioです。今回は、PerlやRubyのハッシュの代用としてTokyo Cabinetを使うことでメモリ使用量を激減させられることを説明します。 抽象データベースAPI Tokyo Cabinetには抽象データベースという機構があり、先日、そのPerlとRubyのバインディングをリリースしました。それを使うと、各種言語のハッシュとほぼ同じような共通したインターフェイスで、以下のデータ構造を利用することができます。 オンメモリハッシュ：各種言語に標準のハッシュと同じく、メモリ上でkey/valueの関係を表現する。 オンメモリツリー：メモリ上の二分探索木としてkey/valueの関係を表現する。 ファイルハッシュ：いわゆるDBMとして、ファイル上でkey/valueの関係を表現する。 ファ
B木 - naoyaのはてなダイアリー
昨年から続いているアルゴリズムイントロダクション輪講も、早いもので次は18章です。18章のテーマはB木(B Tree, Bツリー) です。B木はマルチウェイ平衡木(多分木による平衡木)で、データベースやファイルシステムなどでも良く使われる重要なデータ構造です。B木は一つの木の頂点にぶら下がる枝の本数の下限と上限を設けた上、常に平衡木であることを制約としたデータ構造になります。 輪講の予習がてら、B木を Python で実装してみました。ソースコードを最後に掲載します。以下は B木に関する考察です。 B木がなぜ重要なのか B木が重要なのは、B木(の変種であるB+木*1など)が二次記憶装置上で効率良く操作できるように設計されたデータ構造だからです。データベースを利用するウェブアプリケーションなど、二次記憶(ハードディスク)上の大量のデータを扱うソフトウェアを運用した経験がある方なら、いかにディ
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
MapReduce on Tyrant - mixi engineer blog
先日、隅田川の屋形船で花見と洒落込んだのですが、その日はまだ一分咲きも行ってなくて悲しい思いをしたmikioです。今回はTokyo Tyrant（TT）に格納したデータを対象としてMapReduceのモデルに基づく計算をする方法について述べます。 MapReduceとは Googleが使っているという分散処理の計算モデルおよびその実装のことだそうですが、詳しいことはググってください。Googleによる出自の論文やApacheプロジェクトによるHadoopなどのオープンソース実装にあたるのもよいでしょう（私は両者とも詳しく見ていませんが）。 今回の趣旨は、CouchDBがMapReduceと称してJavaScriptで実現しているデータ集計方法をTTとTCとLuaでやってみようじゃないかということです。簡単に言えば、以下の処理を実装します。 ユーザから計算開始が指示されると、TTは、DB内の
データベースの基礎を理解しよう！ プログラミング未経験から始めるPHP入門
はじめに 本連載では、PHPまたはプログラミング初心者の方を対象に、PHPを用いたWebアプリケーションの作成方法を説明していきます。今回は、データベースとSQLに関して、「おすすめレストラン一覧を閲覧できるWebサイトを制作する場合」を例にして、説明をしていきます。 対象読者 プログラミングが初めてでこれから学習する予定の方 プログラミングの経験はあるがPHPを初めて学習する方 この記事の内容 はじめに 対象読者 動作確認環境 データベースとは何か･･･データベースはどんな役割？ データベース操作の基礎･･･データベース言語「SQL」とは SQL基礎：テーブルの作成･･･CREATE文を使ってみましょう SQL基礎：レコード追加･･･INSERT文を使ってみましょう SQL基礎：レコード検索･･･SELECT文を使ってみましょう SQL基礎：レコード更新･･･UPDATE文を使ってみまし
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
「キー・バリュー型データストア」開発者が大集合した夜
「発表者が自分よりも若い人ばかりだ」。外見が20代にしか見えない東京工業大学の首藤一幸准教授（1973年生）の驚くさまが、少し面白かった。2009年2月20日の夜、多くのWeb企業が注目する「キー・バリュー型データストア」を開発する若手技術者が、東京・六本木のグリー本社に一堂に会した。 キー・バリュー型データストア（またはキー・バリュー型データベース）は、大量のユーザーとデータを抱え、データベースのパフォーマンス問題とコスト高に頭を悩ませるWeb企業が注目する技術である。記者は同日に開催された「Key-Value Store 勉強会」に参加させてもらった。午後7時から11時まで、キー・バリュー型データストアを開発・研究する若手技術者が立て続けに登場し、1人15分の持ち時間で成果を発表し、議論を重ねるという集まりだ。 呼びかけ人であるプリファードインフラストラクチャー（PFI）最高技術責任者
blog.katsuma.tv
greeさんで開催されたKey Value Store勉強会に行ってきました。 時間にして4時間超え、内容も国内のKey-Value Storeなソフトウェアの最前線の話ばかりで相当なボリューム。以下、メモってたのを残しておきたいと思います。（誤字、脱字、内容に誤りを含むものなどありましたらお伝えください）また、発表者の方やプロダクトについて、ざっくり調べてURL見つけられたものについてはリンク張っています。 森さん / 末永さん groonga Sennaの後継エンジン 融通が効かないのがSennaのデメリット スコア算出式のカスタマイズなど Sennaの転置索引 索引の構成部品を自由に組み合わせて使える APIもいろいろ QL DB Low Level memcached互換のkey-value store バイナリのみ対応 計測 クライアント memstorm-0.6.8 mem
大規模データ処理のための行列の低ランク近似 -- SVD から用例ベースの行列分解まで -- - 武蔵野日記
id:naoya さんのLatent Semantic Indexing の記事に触発されて、ここ1週間ほどちょくちょく見ている行列の近似計算手法について書いてみる。ここでやりたいのは単語-文書行列(どの単語がどの文書に出てきたかの共起行列)や購入者-アイテム行列(どの人がどの本を買ったかとか、推薦エンジンで使う行列)、ページ-リンク行列(どのページからどのページにリンクが出ているか、もしくはリンクをもらっているか。PageRank などページのランキングの計算に使う)、といったような行列を計算するとき、大規模行列だと計算量・記憶スペースともに膨大なので、事前にある程度計算しておけるのであれば、できるだけ小さくしておきたい(そして可能ならば精度も上げたい)、という手法である。 行列の圧縮には元の行列を A (m行n列)とすると A = USV^T というように3つに分解することが多いが、も
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
