・データベース的な観点でのソーシャルゲームの特徴 ・データモデル ・ソーシャルゲームに従来型RDBMSを使うべきか、�流行りのNoSQLで行くべきか ・負荷対策 (アーキテクチャ面) ・負荷対策 (ツール面) ・インフラエンジニアのキャリアについて

弊社の一部のサービスでも絶賛活躍中のFusion-io社のioDrive。 Fusion-io ioDriveとFusion-io ioDrive Duoではどちらも、最小容量のモデルはSLC型、そのほかはMLC型を使っているが、Fusion ioDriveの読み込み速度は735〜770MB/s、書き込み速度は510〜750MB/sだ。Fusion ioDrive Duoに至っては、読み込み速度は1.0〜1.5GB/s、書き込み速度は一律1.5GB/sという数値をたたき出す。 @IT Special PR:Fusion-ioのクールな技術を使いこなせ! 今日はデルさん主催の下記セミナーにて、このFusion-ioに関するDELL社の検証結果紹介や、DeNA松信さんによるMySQL環境でのFusion-io検証結果およびDeNAでの利用に関するお話が聞けるとのことだったので、途中からの参加で
実践ハイパフォーマンスMySQL 第2版とLinux-DBシステム構築運用入門を読んで、 MySQL のインデックスについて勉強しなおしている。理解が曖昧だった部分の知識を深められたり、自分の間違いに気づけたりして、とても収穫が多い。 フルテーブルスキャンとフルインデックススキャン Linux-DBシステム構築運用入門 P185 に書いてあるケース。インデックスを利用してても対象レコード数が多いとランダムI/Oが大量に発生して遅くなる。読むべきレコード数が多いのならばフルテーブルスキャンのほうがI/O一回で多くのブロックを読み込めるので速い。 IGNORE INDEX ヒントを与えてパフォーマンスを改善するという例があった。 マルチカラムインデックスと範囲検索 SELECT * FROM users WHERE a = ? AND b >= ? and (c IS NULL OR c >=
NoSQLミドルウェアの特徴をもう少し細かく挙げてみます。分量の都合もあり個別には触れませんが、それぞれのNoSQLミドルウェアで差別化部分に関してはかなり詳細に説明がされていますので、ぜひそちらを参照してみてください。 高速に動作する リレーションモデルではないデータモデル スケールアウト型アーキテクチャ コモディティサーバによって構築される スキーマフリー SPOF(単一故障点)を持たない 自動的に複数台へレプリケーションする イベンチュアルコンシステンシまたは一貫性の選択が可能 SQLのような強力なクエリ言語を持たず、シンプルな問い合わせしかできない Cassandraとは何か NoSQLミドルウェアの筆頭といえばGoogle BigTableやAmazon Dynamoですが、オープンソースの世界でもいろいろなものが出てきています。その中でも最近特に注目を集めているのが、Apach
Cassandra is a hybrid non-relational database in the same class as Google’s BigTable. It is more featureful than a key/value store like Riak, but supports fewer query types than a document store like MongoDB. Cassandra was started by Facebook and later transferred to the open-source community. It is an ideal runtime database for web-scale domains like social networks. This post is both a tutorial
社内で 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
All to often people force themselves into using a database like MySQL with no thought into whether if its the best solution to there problem. Why? Because their other applications use it, so why not the new application? Over the past couple of months I have been doing a ton of work for clients who use their database like most people use memcached . Lookup a row based on a key, update the dat
構造と仕組みをちゃんと理解する。いきなりJDOとかダメって。 http://songofcloud.gluegent.com/2009/11/slim3-datastore1.html 間違い、追加等ありましたらおしえてください。 1.概要 http://www.atmarkit.co.jp/fjava/index/index_bigtable.html 分散KeyValueストア:「巨大なハッシュ=datastore」に「小さなハッシュ=Entity」をたくさん詰め込む get/putの速度:データが無限に増えても遅くならない 全体図 2.スキーマレス Entity = Hashみたいなもの : Valueには全プロパティがシリアライズされて保存される Key / Kind プロパティの型 : int / string / date / list / ... 3.インデックス / クエリ
開発しているシャーディングミドルウェアである Incline と Pacific については YAPC::Asia 2009 を始めいろいろな所で話をする機会をいただいてきたので、今回は、なぜ RDBMS ベースのアプローチを採用したのかという背景を中心に説明させていただきました。概念的な話が多くて分かりにくかったと思います(すみません)が、細かな点についてはパフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)を参照いただければと思います。 また、中で出てきた「実体化ビュー」については、Materialized view - Wikipedia, the free encyclopediaが良くまとまっているかと思います。Incline は一言でいうと、RDBで構成されるshard群の上で read-only かつ eventually co
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近1秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
id:kiskeさんにお誘いいただいて先週金曜日にカカクコムさんの社内勉強会でお話させていただきました。貴重な機会をいただきありがとうございました。 自由に話してOKですよとのことだったので、何にしようかなと少し考えた結果、こんなスライドができあがりました。 MySQLのパフォーマンスの話View more presentations from ikdttr. MySQLも今となってはかなり広く使われていて、パラメータチューニングとかも一通りのことは皆さんご存知だろうと思ったので「チューニングをする際にソースを読んで調べたいと思ったらどうしたらいいか」といったようなテーマに対する答えの一例見たいな感じの内容になりました。 普段使っている/参照しているサーバ変数やステータス変数がどのように実装されていて、それらをソース上で追いかけるにはどうしたらいいか、みたいな感じですね。 勉強会ではgdb
2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。 この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。 確かに、Oracle Real Application Cluster(以下、Oracle RAC)でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。 両者の違いは何かあるのでしょうか? 調べてみることにしました。 インメモリデータベースは1000倍速い 調べてみるとすぐに、両者には明確な性能差があ
magic_multi_connections Magic Multi-Connections magic_multi_connectionsのページ Magic Multi-Connections: A “facility in Rails to talk to more than one database at a time” magic_multi_connections作った人の記事 Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築 magic_multi_connectionsの使い方がのってる Ruby on RailsでMagic Multi-Connectionsを使う magic_multi_connectionsの使い方がのってる 分散DB対応ライブラリ Magic Multi-Connections を試してみる magic_multi_
DBチューニングにおいて、気を配るべきところは数多くありますが、中でも真っ先に見るべきところはディスクI/Oでしょう。なぜかというと、メモリアクセスに比べてHDDの方が圧倒的に遅く、最もパフォーマンス阻害要因になりやすいためです。ディスクI/Oネックの解決方法を探っていくと、「テーブル/インデックス設計やSQL文の見直し」に行き着くこともまた多いです。これらが不適切だと、結果として大量のレコードをアクセスすることになり、ディスクI/Oが多く発生してしまうためです。根本的な原因はディスクI/Oにあります(CPUネックになることもありますが、その例は別の機会に取り上げます)。 ディスクI/Oには大きく分けてシーケンシャルアクセスとランダムアクセスの2種類のアクセスパターンがありますが、RDBMSではインデックスアクセスが主体となるため、ルート→ブランチ→リーフ→実レコードという経路でのランダム
Spider is the first step when accessing a remote database and a storage engine that updates and improves upon the existing architecture of MySQL. Spider supports database transaction. In addition Spider allows an unlimited amount of users to quickly access the MySQL database. Spider supports MySQL partitioning. Spider operates as a "cluster" acting as a single system that supports unlimited parall
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く