信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
DataMapper、バージョン1.0へ到達
原文(投稿日：2010/07/21)へのリンク DataMapperはRuby向けのオブジェクトリレーショナルマッパーであり、最近マイルストンが1.0へとたどり着いた。このリリースはRailsConf 2010の間にDirkjan Bussink氏のプレゼンテーションで発表された。 DataMapper(DM)はこの2年間、コミュニティプロジェクトによって育てられてきた。DMは高速でスレッドレーフで多機能なORMだ。InfoQは主要な開発者であるDan Kubb氏と話す機会を得た。 DataMapperはバージョン1.0がリリースされたが、これは前バージョンの0.10からの大きなそして重要なバージョンアップだ。氏はこのマイルストンの内実を教えてくれた。 1.0へバージョンアップするかどうか決めるのはちょっと難しかったです。1.0は完璧ですべての課題を解決していてほしいという考えがある一方で
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 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
MySQLの将来が心配なので、（たぶん）日本一のMySQLエキスパート「日本男児」に聞いてみた
オラクルは、サン・マイクロシステムズを買収後、オープンソースとして提供されていたOpenSolarisを事実上終了し、またオープンソースとしてAndroidを提供しているグーグルに対して「Javaと競合する」という理由で訴訟を起こすなど、オープンソースに対して非協力的と見える行動が続いています。 こうなると、同社が保有するオープンソースデータベースのMySQLの今後は大丈夫なのか懸念されます。すでにMySQLのコアな開発者の何人かは同社を去り、MariaDBやDrizzleといったほかのオープンソースデータベースに取り組んでもいます。今後、MySQLの開発が弱体化したり、方向転換してSolarisのようにクローズドになったりすることはないのでしょうか？ そこでMySQLのエキスパートとしてブログ「漢（オトコ）のコンピュータ道」を執筆するブロガー「@nippondanji」であり、かつ日本オ
NoSQLをRDBの代わりに使うと、どういう恐ろしいことが起こるか。PARTAKEの作者が語る
データベースの世界でいま注目されているのがNoSQL。特にキーバリュー型データストアは、グーグルのBigTable、FacebookやTwitterが内部で利用しているCassandraやAmazonクラウドが提供しているSimpleDBなど、すでに実際に使われ始めています。 ではそのNoSQLをリレーショナルデータベースの代わりに使ってシステムを構築するとどうなるのか？ 身をもって体験したことを記したShinya Kawanaka氏によるプレゼンテーション「間違った方向にCassandraを使ってみた」が公開されています。 NoSQLを用いたシステム構築は、リレーショナルデータベースによる構築どう違うのか？ とても分かりやすくまとめられています。ご本人の承諾もいただいたので、その内容を紹介しましょう。 NoSQLを使ったときに起こる恐ろしい事例 プレゼンテーションのテーマは「NoSQLを
Wikipedia が記事の履歴をどのように DB に格納してるか調べてみた - てっく煮ブログ
Wikipedia は過去の編集履歴もサイト上から確認できるようになっているのだが、どのようなデータ構造で情報を保存しているのか気になって調べてみた。MediaWiki を見ればいいWikipedia のソースコードは MediaWiki として公開されているので、これのソースコードを見たり、試しに動かしたりして把握していった。MediaWiki は PHP で開発されている。今回は調査時点での最新バージョン 1.16.0 を利用して調査した。と思ったら MediaWiki に DB 構造が書いてある記事のデータやユーザー情報は全て DB(PostgreSQL or MySQL or SQLite) に保存されるようだ。手っ取り早く SQLite を使ってローカル環境で動かしてみて DB を覗いてみた。DB を眺めつつ、いろいろ調べてたら MediaWiki のサイト上にテーブル構造を示し
地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
ミクシィのNoSQLデータベース「Tokyo Tyrant」をNetVibesが採用した理由
カスタマイズ可能なポータルサービスを提供するフランスの「NetVibes」は、バックエンドデータベースとしてミクシィの平林幹雄氏が開発し、同社内でも利用されているNoSQLデータベースの「Tokyo Tyrant/Tokyo Cabinet」（以下Tokyo Tyrant）を採用しているそうです（追記：平林氏は7月末でミクシィを退職されるとのこと）。 なぜNetVibesはTokyo Tyrantを採用したのか、その理由がmyNoSQLの記事「Netvibes: A Large Scale Tokyo Tyrant Deployment Case Study」で紹介されています。NetVibesは、Hadoop、CouchDB、Tokyo Tyrant、File system、MySQLを評価した上でTokyo Tyrant/Tokyo Cabinetを採用したとのこと。 NetVibes
第1回 memcachedの起動オプションを把握しよう | gihyo.jp
1.4系で新しく追加された主な機能しては バイナリプロトコルの導入 マルチスレッドの標準化 統計の強化 などが上げられます。この1.4系の機能の詳細については前坂徹氏の連載「memcached 1.4の到来」が参考となります。ここではバージョン1.2.5と最新の1.4.5の起動オプションを比較しながら、新しく追加された機能や実際の運用で用いられる起動オプションについて説明します。 1.2系と1.4系の起動オプションの違い まず、memcachedの起動オプションの一覧（ヘルプ）を確認しましょう。memcachedのヘルプを出力するには、「-h」オプションを使います。 $ memcached -h memcached 1.x.x -p <num> TCP port number to listen on (default: 11211) -U <num> UDP port number t
Twitterが、Cassandraの本採用を断念。「いまは切り替えの時期ではない」
「いまは新しい技術への大規模な移行をする時期ではないと確信している」。Twitterは、サービスの核となるツイートを保存するデータベースを、MySQLによる大規模分散データベースから、NoSQLデータベースであるCassandraへ移行しようとしていました。しかしCassandraへの移行作業を中止し、引き続きMySQLでの運用を継続すると、Twitter Engineering Blogへのエントリ「Cassandra at Twitter Today」で明らかにしました。 これは戦略の変更だ Twitterは利用者からのツイートを、Scalaによって独自開発したミドルウェア「Gizzard」とMySQL、そしてmemcachedを用いた大規模分散データベースに保存しています。 しかしこうした複雑なシステムによる運用は非常に手間がかかり、人的コストを中心としたコストの増加が非常に大きくな
インデックスについて - SQLer 生島勘富 のブログ
インデックスが分かってない人が非常に多い。 現実にあった例で、60カラムあるテーブルに、前から3つずつの複合インデックスを20個作るとか、30カラムを1つの複合インデックスにするとか、意味が分かっていない人が非常に多くいます。 ※ 詳しい人へ。ここでは、インデックス = B-Treeインデックスと考えてください。 インデックスとは インデックスとは、そのままズバリ「索引」のことです。 身近な例ではカラオケがあります。いわゆるカラオケ本がインデックス。リモコンで押す番号が主キー、流れる音楽・映像が実レコードと考えてみてください。 カラオケ本は「歌手名順」と「曲名順」の2つは最低限あると思います。 これらは、 歌手名順は、「歌手名・曲名」の組み合わせの複合インデックス。 曲名順は、「曲名・歌手名」の組み合わせの複合インデックス。 と考えることができます。 想像してみてください。小学生でも「アン
NoSQLを上回る性能のVoltDB、そのアーキテクチャとは
データベース研究者の大御所、マイケル・ストーンブレイカー氏が開発し、NoSQLデータベースをも上回る性能を発揮するリレーショナルデータベース「VoltDB」。前回の記事では、その特徴と、NoSQLデータベースのCassandraとのベンチマーク比較を紹介しました。 今回はVoltDBのアーキテクチャについて調べたことをご紹介しようと思います。基本的にはVoltDBのWebサイトやリンク先の内容を基にしています。また、ブログ「独り言v6」のエントリ「VoltDB登場 – RDBMSのようでRDBMSではない新システム」も参考にさせていただきました。 シェアドナッシングな分散インメモリデータベース VoltDBのアーキテクチャは、FAQのページで以下のように説明されています（英語を訳したものを引用しています。以下同じです）。 VoltDBは、シェアドナッシングなサーバ群から構成されるスケーラブ
グーグルのBigQuery、大規模処理の「仕組みは秘密です」
先週行われたグーグルのイベント「Google I/O」で発表された、大規模データをSQLライクな命令によって高速に処理してくれる新サービス「BigQuery」。3日前に公開した記事「グーグルによるMapReduceサービス「BigQuery」が登場。SQLライクな命令で大規模データ操作」で、その概要をお伝えしました。 そのBigQueryについて、Google I/Oのセッションに参加されていたスティルハウス 佐藤一憲氏が「BigQueryってなんぞ？」とエントリをブログに書いています。自由にコピペしていいと許可をいただいたので、あらためてBigQueryとはどんなものなのか、ポイントを紹介しましょう。 大規模なデータを処理できるといえば、思い浮かぶのはMapReduceです。佐藤氏はBigQueryとMapReduceの違いをこう書いています。 MapReduceとはどう違う？ 大規模な
Ruby on Rails セミナー（クックパッド）へ行ってきたメモ - 基本へ帰ろう
what Ruby on Rails セミナー（クックパッド）へ行ってきた。スライドのタイトルは、【５２４万人が利用する食のインフラ「クックパッド」のものづくり】 そこでのメモ。 ※スライドの移動が少し早くてメモが追いつかなかった部分があります。 クックパッド概要 1998年オープン 目的：「毎日の料理を楽しみにする事で、心からの笑顔を増やす」 ４５万品のレシピ（レシピへのアクセスの仕方はロングテール。けっこうばらばらとアクセスされている。） 月間ユーザ５２４万人 Railsの中で世界第８位 月間２.８億View １６時〜１８時がアクセスのピーク 秋からバレンタインに向けてトラフィックが伸びる サーバネットワーク フロントサーバ（Apache2.2）８台 アプリケーションサーバ４４台（？だったかな・・・２２台だったかな・・・？） データベースサーバ４４台 Ruby 1.8.6 Rails2
2009-03-14
@ntamaoki がうちの若手と飲みましょうよ、と言ってきたので、ほいほいそれに乗って日本オラクルの若手エンジニアに会ってきた。実のところ、ERPだAPPSだというのは、よくわからない。わたしはデータベースのエンジニアだったわけで、職種もコンサルとかではなく、サポートのさらに下のバックエンドのサポートだったわけで。 新社屋は素敵だった。二階の受付まで行って、諸般の事情で社内にははいれなくて残念。 まあ、それは、どーでもいい話なのだが、基盤系いいよ〜、RDBMSの開発おもしろいよ〜という話をお腹いっぱい話してきた。 バックエンドサポートの一日つーのは、出社してbugdb見て、自分の担当部分のバグをざっと見て、新しいバグがあれば、拾って、地味に回答を作る。パッチを作る場合もあるし、バグじゃなかったり、バグだったとしても、簡単なワークアラウンドがあったりして、それを回答したりという感じである。
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ SSDがHDDに代わるストレージとして普及しようとしていることを背景に、SSDに特化したまったく新しいアーキテクチャを備えたリレーショナルデータベースを開発しようとしている企業があります。「ReThinkDB」です。 昨年7月に、PublickeyではReThinkDBの概要を記事「SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現」で伝えました。 その記事の中では、ReThinkDBがロックを使わずにトランザクションを実現し、データベース利用中でもスナップショットがとれ、また異常終了しても容易に復帰できる機能を備えている、といったことを紹介しました。 4月に米サンタクララでに行われた「MySQL Conference & Ex
pylori*style wiki - MigrationによるDB管理
Migrationとは Migration とは、Railsで使うデータベースの管理機能で、テーブル作成・カラ ムの追加/変更などの作業を一元管理できます。SQL でスキーマを書くのでは なく、Rails独自の記法(Rubyの文法の範囲内)を使ってDB管理を行います。以 下のようなメリットがあります。 スキーマのバージョン管理ができる rake コマンドでスキーマのバージョンアップ/ロールバックが可能 データベースに依存しない書き方ができるので、他のデータベースに切り替えるのが容易 対応しているデータベース 現在、対応しているデータベースは MySQL, PostgreSQL, SQLite, SQL Server, Oracle です。 今後、対応DBは増えていくと思います。最新情報は、 http://api.rubyonrails.org/classes/ActiveRecord/Mi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OracleのSQLのアンチパターンの問題集1
IDEA * IDEA
mapee.jp