PerlとOracleDatabaseでの性能試験（データ増幅） - Articles Advent Calendar 2011 Test
はじめに はじめまして！ dukkiedukkie と申します。 知人にこちらを教えて頂きまして登録させていただきましたが、予備知識なく&&不慣れでご迷惑おかけすると思いますが、よろしくお願いいたします！！ IT業界を16年ほどさまよっており現在はPerlで色々書いてます。が、ゴリゴリのプログラマというわけでもなく 前職は某ポータルサイトにて広告システム全般のシステム基盤設計とシステム運用、前々職は某金融システムにてDBA（Oracle中心）、その前は某ブログシステムのDBA（Oracle中心）、さらにその前は、某IT情報配信サイトのエンジニアとして、働いてきた90年代CGIプログラミングを原点とする”オッサンPerler”です。 ですが、どんどん新しいことを学びたいので、なかよくしてくださいね!! データベースの性能試験とPerl さて、ほとんど準備もしておりませんため（次回はがんばりま
データの偏りを考慮したデータ増幅：【続】PerlとOracleDatabaseでの性能試験 - Articles Advent Calendar 2011 Test
単純な増幅ではテストで見抜けない性能ボトルネック こんにちは。dukkiedukkieです。クリスマスが近づいてきてますね。 さて、先日[/articles/advent-calendar/2011/test/6]を書かせていただきましたが、今日はその話の続きで。 エンティティのカーディナリティを考慮しつつデータ増幅を行ったとしても、先日のやり方では、全ての増幅データのデータ量が均一になってしまいます。ですが、現実のデータストア運用現場で発生する問題には、 「WHERE条件句で絞込みを行なっているのだけど、この条件指定に対してマッチする行数が多すぎて、結果の返却スピードが遅い」 「実行計画的には変わらないのだけど、当該IDのみconsistent gets量がメガバイト単位になってしまって、どうしてもクエリがスローダウンしてしまう」 「AWRとかRDBMSの統計情報を見ると、バッファイン、
独り言v6 » RDBMSにおける5つの並列可能性 – L.star的デザイン(2)
前回、と言ってもずいぶん前になるが 超並列RDBMSは成立するか – L.star的デザイン（１） にてある程度の考察をしているRDBMSのデザイン。kumoFSどうだろうとか寄り道しつつ、自分なりの次のステージまで煮詰めることができたので、それについてメモとして書き留めたい。 まず目標として掲げるのは、 標準的なストレージしか持たないサーバ群を使う。 単純CRUDクエリのスケールアウト。読み書き両方 JOIN構文のサポート。特に１TB程度の複数テーブルをINNER JOINして集計できる 1つのクエリ内部を複数サーバに分割させることによる性能向上。スケールアウトというわけではないが。 というところである。かなり無茶な要求と思うが、ここまでサポートできるとデザイン上で納得できれば悪くなかろう。現実に実装する場合には、随所で発生するボトルネックとの戦いになるだろうし。前回は「ストレージノード
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
