ISUCON3 本戦参加報告 - まいんだーのはてなブログ
引き続きチーム「50ms or die.」で本戦に参加してきました。 謝辞 はじめに運営の皆様、出題の @fujiwara さん、サーバ提供のデータホテルさまには予選含め、限られた時間でいろいろ絞り出して戦うという、とても得難い機会を頂けたことを感謝申し上げます。 結果 1800なんぼでfailという結果に終わりました。いわゆる「die.」です。 スコアレスでdieしてしまった前回よりはマシだけど、結果に結びつかなかった点は反省して次に繋げたい。 ただ、前回のような絶望感はなく、いかに時間内にやり切るかという挑戦ができたのでとても充実した時間になりました、この点は自身進歩したなと感じてます。 詳細はチームの @__kan さんや @bonnu も書いてくれると思いますが、私も覚えている限り何を思って取り組んだかといったあたりはまとめておきます。 やったことのまとめ プロファイリング @bo
Facebook: MySQL Pool Scannerでの徹底した自動化 - ワザノバ | wazanova.jp
https://www.facebook.com/notes/facebook-engineering/under-the-hood-mysql-pool-scanner-mps/10151750529723920 Facebookがエンジニアブログで、MySQLの運用を自動化している事例を紹介しています。このレベルまでくると、意思をもった大規模なロボット群みたいで、すごいですね。前半はマスタ/スレーブの基本的な自動化の話ですが、後半ではオペレーションの自動化ロジックをどのように自動化して増やすかという手法まで言及してます。 FacebookのMySQL DBクラスタは、２つの大陸にまたがる複数のデータセンタにある数千台のサーバで構成されている。通常、DBアドミンが担当するルーティーンワークは、MySQL Pool Scanner (MPS) で自動化されている。 1) DBノードを詳しく
Go の MySQL ドライバの効率の良い使い方 - methaneのブログ
10/5 に ISUCON 3 の予選に Go 言語で参戦していました。 とりあえずレポートは会社のブログに書いたので、 Go 言語で go-sql-driver/mysql を使って MySQL を使う時に知っておくと良い点をまとめておきます。 ちなみに MySQL ドライバにはもうひとつ MyMySQL というものがあり、 まだ試していませんが、 MyMySQL の方が落とし穴が少なそうな気がします。 sql.Open() が返す DB オブジェクトはコネクションプールをしてくれる なので、自前で DB オブジェクトを使いまわしてコネクションプールを実装しても意味は無いです。 DB.SetMaxIdleConn() で、使い終わってもクローズしないコネクションの数を設定できます。 デフォルトだと使い終わったコネクションを閉じてしまうので、 DB オブジェクト自体をプールしても コネクシ
インデックスの基礎知識
■ インデックスとは データベースの世界で、インデックス(索引)とはテーブルに格納されているデータを 高速に取り出す為の仕組みを意味します。 インデックスを適切に使用することによってSQL文の応答時間が劇的に改善 される可能性があります。 インデックスにはB-Treeインデックスをはじめ、ビットマップインデックス、 関数インデックスなどの種類がありますが、ここでは最も一般的に使われ、かつ ほとんどのDBMSでサポートされているB-Treeインデックスについて解説します。 ※ CREATE INDEX文でオプションを指定しない場合は通常B-Treeインデックスが 作成されます。 ■ B-Treeインデックスのしくみ B-Tree(Balanced Tree)インデックスは次のようなツリー状の構造になっています。 ツリーの先頭はヘッダブロックと呼ばれています。ヘッダブロックでは、キー値の 範囲
オラクルがNoSQLに本気。エンタープライズ向け「Oracle NoSQL Database 11g」公開。オープンソース版も登場
米オラクルはエンタープライズ向けNoSQLデータベース「Oracle NoSQL Database 11g」の公開を発表。評価版の無償ダウンロードを開始しました。オープンソースライセンスに基づくコミュニティ版も準備中（10月26日現在、ライセンス承認待ち）とのことです。 Oracle NoSQL Databaseは、同社のキーバリューストアであるOracle Berkeley DB Java Editionをベースに、分散処理機能、ロードバランス、管理機能、マルチノードバックアップ機能などを追加したもの。大規模なデータを高速に扱うことができ、高い可用性とスケーラビリティを実現すると説明されています。 分散キーバリューストアで単一障害点を排除 NoSQL Databaseの基本的なアーキテクチャは、プライマリキーのハッシュによって指定されたノードにキー／バリューのペアを書き込む分散キーバリュ
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
はじめての MySQL で100万件のデータを管理する時に行ったチューニングまとめ
MySQL の勉強をせずにフレームワーク等で SQL を書かずに Web サイトを構築していました。データ数も2万件程度でしたので、そこまで困ることはありませんでしたが、今回100万弱の商品データを扱う機会ができたので、MySQL のチューニングや発行する SQL について見直す機会がありました。 この記事では MySQL を高速化するのに行った対策など勉強したものを自分用にメモしておきました。 条件式で比較するカラムにインデックスを使用して高速化 商品コードで存在しない商品を見つけて、商品をDBに登録するという処理を行っている場合、4万件超えたころから処理に2秒以上かかるようになってきます。12万件超えた頃には10秒程度かかるようになってしまいましたが、商品コードのフィールドに対してカラムインデックスを貼ることで0.2秒に短縮することができました。 MySQL のリファレンスにも以下のよ
DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
「NewOLTPの時代にNewSQLが求められている」 マイケル・ストーンプレイカー氏
Web時代に生成される大量のデータを、トランザクションを維持しつつ処理できる新しい種類のデータベース「New SQL」が求められていると、データベース研究者の大御所、マイケル・ストーンブレイカー氏が米計算機学会ACM（Association for Computing Machinery）のコラム「New SQL: An Alternative to NoSQL and Old SQL for New OLTP Apps」（New SQL：New OLTPアプリケーションのための、NoSQLやOld SQLに替わるデータベース）で書いています。 New SQL: An Alternative to NoSQL and Old SQL for New OLTP Apps | blog@CACM | Communications of the ACM これまで企業の情報システムの定番は、受発注
データベースの内部動作を知る
SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基本的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの？ Part 1：SQL文はどのように実行されるのか SQL実行までの
データベースのスケーラビリティをどうやって向上させるか
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
Rails3.1の初期化プロセスを細かく追いかけたRailsGuidesの記事を和訳したよ:ミームの死骸を越えてゆけ
This domain may be for sale!
7分半で作るNode.js+MongoDBアプリ - PolyPeaceLight
先日のJJUG SpringのLTをしてきた「7分半で作るNode.js+MongoDBアプリ」の動画を撮り直しました。 本番ではmongoose.Schemaのところをmongoose.modelとしてしまい、まさかのライブデバッグを初めるハメになり、結果として13分となってしまいました。 リベンジとして今日何回かトライしたところ10分を2分半も上回る7分半、スリークォーターの記録を出すことができました。 動画中でやってること 1 環境を証明 nvmとかnodeとかnpmとかがインストールされてないことを証明 env.shは確認するコードが書かれているだけです 2 nvmとmongodbをググる 3 nvmをgitで取得 $ git clone git://github.com/creationix/nvm.git ~/.nvm 4 nvmを環境に読み込む $ . ~/.nvm/nvm.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Devsの常識、DBAは非常識
Don't use MongoDB
【DB概論】データベース設計の目的・まとめ
削除フラグのはなし
Twitterにおける大規模システム構築、3つの原則