本を読む Shibuya.pm TT #12で話を聴いた
11月30日に、Perlプログラマの集まるイベント「Shibuya.pm Technical Talk #12」に参加して、発表を聴いてきました。 中心となったのは「NoSQL vs. NoKVS ライトニングディスカッション」。実際に高速（分散）KVSやRDBMSを開発したり使ったりしている豪華メンバーが壇上に並んで、発表や議論を繰り広げました。 そのほかの発表も含めて、実開発者による濃い話が面白く語られていました。全体的に、アプリの実行速度にこだわった話が多かったのが印象的です。あと、予定の9時ぴったりに終わったのにもびっくり。 1週間たっちゃいましたが、以下、自分の復習として、メモをまとめておきます。 Tatsumaki" I/O bound HTTP clients in web frameworks（miyagawa） Shibuya.pmといえばこの人、miyagawaさんのセ
1年目の人にわかってほしいこと - 極北データモデリング
今年採用した新卒者は、ウチぐらいの規模の会社ではめったに取れないレベルの猛者たちだ。 一人はTOEICのスコアが930台で、一人は年間の読書量が2000冊(200の間違いじゃない。2000なのだ)で、もう一人は特定されるのでここには書けないある大会の優勝者だ。 こういう人を集めたら何かすごいことが起きるかというと、集めただけでは別に何も起きない。 彼らにはどこかで目を覚ましてもらわなくてはならない。「目を覚ます」というのは、例えば この会社で要求される技術はたいして難しいものではない。勉強すれば1日で理解できる程度のことが大半 先輩は昔から何でも知っていたような顔をしているが、実はここ1,2年で覚えた技術で仕事をしている だから、先輩が10年目でようやくできるようになった技を、1年目の自分があっさりものにできてもおかしくない といったことに気付くことだ。 本当は大して難しくないのに...
hbstudy#5に参加してきた - cloned.log
第5回: PostgreSQL安定運用のコツ2009、DBサーバーのパフォーマンスチューニング PostgreSQLは使ったことも運用したこともほとんどないので端から端までわからないかなと思っていたのだけど、みんながよく言うVACUUM処理の原理的な必要性が理解できたし、統計系コマンドが充実していることを知ることができたのでとても良かった。スライドが判りやすくまとまっている。前提知識として頭に入れておけば、いつか本格的にPostgreSQLを使わなければならなくなったときにとても役に立ちそう。 MySQLは一番業務で利用しているRDB。SIerの頃はOracleだったけれども、今となってはMySQLの利用経験の方が多くなっている。 まだ最後の章が読み切れていないのだけど、Linux-DB システム構築/運用入門 (DB Magazine SELECTION)がとても良本なので（読み終わった
PostgreSQL安定運用のコツ2009 @hbstudy#5
2009年11月14日のインフラエンジニア勉強会（hbstudy）で使用したスライドです。 hbstudy#5 http://tinyurl.com/hbstudy5 ・パフォーマンスと初期設定 ・データベースの監視 ・性能劣化とメンテナンス を含んでいます。Read less
シングルマスタ／マルチスレーブ構成に興味がない理由 - kazuhoのメモ置き場
システム全体で必要な書き込みパフォーマンスが、RDBMSノード１基の IOPS の W% の場合、シングルマスタ+スレーブn台構成のシステム全体のパフォーマンスは、 書き込みパフォーマンス: W 読み込みパフォーマンス: R=(1-w)*(n+1) になる。この n=R/(1-w)-1 って w が増加するとスレーブ増設のメリットが加速度的に失われていく点がイヤ。 例えば、システム全体で要求される書き込みパフォーマンスが W=0.3 で、読み込みパフォーマンスが 3 ならば、シングルマスタ／マルチスレーブ構成で必要なノード数は5台。マルチマスタ構成を採った場合でも理想値は4台なので、そう遜色があるわけではない。 しかし、仮に必要なパフォーマンスが２倍 (W=0.6, R=6) になると、必要ノード数はマルチマスタ構成での8台に対し、シングルマスタ／マルチスレーブ構成では16台と、一気にコス
Salesforceのデータベース - snippets from shinichitomita’s journal
すごい良い記事。 知られざる「マルチテナントアーキテクチャ」（2）～スケーラビリティのカギは組織ID － Publickey 知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey 頼まなくてもこういう記事を書いてくれる人が増えている（頼まれてないっすよね？）のは、SFDCにとって、デベロッパーマーケティングとして成功だと思う。大事にしてくださいね。 スキーマについて 上記記事では、データベースの物理スキーマについて、公開情報をもとに分析されています。 掟破りのスキーマ セールスフォースのアプリケーションで扱われるすべての数字や文字のデータは、Dataテーブルに保存される。このことがセールスフォースのデータベーススキーマの核心です。 Dataテーブルはどんなデータでも受け入れられるよう、次のようなスキーマになっています。恐らく、データベースに詳し
DB設計時のサイズ見積もり - よねのはてな
ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ
Re URLを扱うテーブルを作るときにどうすべきか - kazuhoのメモ置き場
数日前、 pathtraqの事例を詳しく知りたい URLを扱うテーブルを作るときにどうすべきか - 金利0無利息キャッシング – キャッシングできます - subtech に対し、 pathtraq は前方一致検索が必要だから算術系圧縮して varbinary(767) だけど、順序の維持が不要ならハッシュのが速いはず はてなブックマーク - kazuhookuのブックマーク / 2009年3月11日 と書いた件について。 ハッシュ値を使えるべきケースでは使うべきってのは、まあ間違いではないけれども、常にそうかというと微妙だなと思わないわけでもないわけであり。mala さんに対しては今更言うまでもないような気がするけど、なんか自分の頭の中がもやもやしてるので、まとめてみる。 気になる点としては、まず、disk I/O の回数。RSS リーダーのようなケースでは、「あるフィードの、特定時点以
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
もしもデータベースサーバがクラッシュしたら
人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ！！人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから
Percona MySQL と OurDelta | Carpe Diem
データベースサーバを新規に増設するために、最新の MySQL を調査していたところ、現時点での公式な 5.0 系の最新版はなぜかバイナリが公開されていない 5.0.75 ということが分かりましたが、同時に Percona Inc. という会社が独自にパッチをあててビルドしている Percona MySQL というものがあることを知りましたので、実際に試しつつベンチマークをとってみました。 Percona は、MySQL Performance Blog を書いていることで有名です。 まず、Percona MySQL とは、Percona Lab によると次のような説明があります。 Percona builds binaries that contain recent versions of the MySQL database server, plus additional popular
オラクルが「10倍速い」DB専用機、「10年に一度の変革」と遠藤社長
日本オラクルは2009年1月20日、データベース専用システム「Oracle Exadata」を発表した。日本オラクルの遠藤隆雄代表執行役社長最高経営責任者は「10年に一度のテクノロジーの変革」と意気込む（写真1）。大量のデータを扱うデータウエアハウスやバッチ処理を高速化したいユーザーに向けて売り込む。オラクルにとっては初のハードウエア製品となる。会見にはハードを提供する日本ヒューレット・パッカード（日本HP）の小出伸一代表取締役社長執行役員が同席。「ExadataはIT業界にとって重要な位置付けにあるものだ。日本オラクルと技術検証に取り組むほか、パートナーに情報を提供するなど支援をしていく」（小出社長）と述べた。 Oracle ExadataはDB本体の「Oracle Database 11g」に、同DB専用のストレージサーバーを組み合わせることで高速化を図っている。米Oracleの責任者
どうも世間では、思ったよりDBエンジニアが不足している様だ: 不倒城
ちょっと技術的な話。oracle分かる人にしか分からないかも。 最近取引先のシステムを見る機会が何度かあったのだが、昨日すんごいとこ見た。 DBが重くて業務にならないというから、ちょっと中を覗かせてもらったらもうエラいこっちゃ。 ・業務ロジックの殆どをファンクション・プロシージャで構成している。なのに、キャッシュヒット率が妙に低い。 ・調べてみようと思ったら一回もstatspackが取得されていない。(担当者には、「statspack?syslogならとってあるんですが…」と言われた) ・各テーブルのindexがどういう訳か全列に貼られている。ちなみにindexは全テーブル例外なくその一個だけ(プライマリキーを除けばだが)。 ・と思ったら、PKが文字列だったりするテーブルがあちらこちらにある。 ・試しにファンクションを一つ二つ見てみたら、なんか普通にクロス結合されまくっていてちょっとくらっ
結合方式とインデックスの関係 - 極北データモデリング
ネスト化ループ結合/マージ結合/ハッシュ結合は、それぞれインデックスをどのように使うのか、を整理する。 マスタのｘｘコードとトランザクションの同名の列を等結合にするSQLについて、 インデックスが片側(マスタ側のみ) インデックスが両側 インデックスなし の3条件で、各結合方式の実行速度を計測してみる。 テスト内容 PostgreSQL8.3.5で以下のSQLを実行する。 explain analyze select * from tellers t -- 1000件のマスタ inner join history h on h.tid=t.tid -- 1000万件のトランザクション結合方式は以下の手順で制御する。 ふつうに実行すると、プランナはハッシュ結合を選択する。 set enable_hashjoin to off を実行すると、プランナはマージ結合を選択する。 さらに set e
select * は禁じ手で、必ず列名を列挙すべしとされている理由 - 極北データモデリング
select * from ... と書いてはダメ、たとえ全列取得する場合でも select a, b, c, d from ... と書くのが常識、という話をずいぶん前に聞いたことがあって、意味がわからないので人力検索に投げてみた。 いただいた回答を整理しておく。 テーブル内の一部の列を参照したい場合 例えばクライアント側では1列しか見ないのにワイルドカードで全列取得することには、パフォーマンス上の問題がある。 select * from ... でも select a from ... でもディスクI/Oのコストは基本的に変わらないが*1、それ以外のところに問題がある。 ネットワークの問題。DBサーバからクライアントに転送するデータが無駄に大きくなる メモリの問題。DBMSのデータキャッシュやOSのファイルキャッシュが無駄遣いされる テーブルの全ての列を参照したい場合 全列取得したい場
RDBMSの終わりとかについて - 技術日記＠kiwanami
本人が大まじめなので少し補足説明。 まず、 id:nowokay はコメントで書かれているような、Javaしか書けないとかSQLが書けないとかDBの知識がどうのというような、脊髄反射でDISられるようなレベルではない。寝坊についてはDISられても仕方がない。 自分が理解している、きしだ理論は以下のよう。 前提： JPAは永続化実装に依存しない永続化APIである SQL(RDBMS) < JPA+JPQL 実現したい機能が満たせる前提で、永続化実装に依存しないという意味で。もちろんこの時点でアプリケーション側はJPA(Java)に依存。 話題のターゲットは、参照が多く、REST的なURLにマップできるくらいの複雑さを持つWebアプリ RDBでしか実績が豊富にないような複雑な業務アプリはRDBのままでかまわない。 である時に、JPAでRDBに依存しないような考え方でプログラムを作っておけば、（
「RDBMSの時代の終わりが見えてきた」についてそろそろ一言言っておくか - ひがやすを技術ブログ
2008-12-12 いくつか誤解を生みそうな表現があるので、それをまずは指摘しましょう。 プログラムモデルとしては、すでにRDBMSからの脱却の準備は始まっています。ORマッピングがそれです。 これが、意図的かはわからないけど、ミスリードを生んでいます。「RDBMSの時代の終わりが見えてきた」というタイトルで、こういう書き方をすると、「ORマッピングによって、すでにRDBMSからの脱却の準備は始まっている」という風に読めるでしょう。これが、ミスリード。 JPAが大切だと思っているのは、永続パラダイムの転換に、コーディングを変えることなく対応できるからです。もちろんJPA+RDBMSのシステムをJPA+非RDBMSに切り替えれるという話ではなく、プログラマのコードの書き方の対応の話です。 これをもう少し、噛み砕くと、JPAのJPQL(SQLもどき)を使えば、SQLとしては統一されていない複
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Selfkleptomaniac — PostgreSQL8.1以降の透過的なパーティショニング
リレーショナル・データベースの世界
Martin Fowler氏はデータストレージについての凍結した考えがほぐれてきたと考えている
