 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||||
|
||||||||||||||||||||
| テスト其の四 〜 データの削除 | ||||||||||||||||||||
|
最後に削除処理をテストしてみます。まずは例のごとく、10万件の社員表を全件deleteした場合です。 |
||||||||||||||||||||
 図3：10万件のデータを全削除した場合の実行速度 |
||||||||||||||||||||
| deleteの場合もupdateと事情は似ています。PostgreSQLの場合は、全レコードに対して削除マークを付けるだけなので、処理は高速で、インデックスの有無はその書き換え対象の大きさへ若干影響するだけという結果でした。インデックスありの場合は、ない場合の6%程上乗せしただけの時間でした。 対してOracleの場合は行を削除するコストは高く、インデックスなしの場合、PostgreSQLに対して3.5倍ほどの実行時間を要した結果でした。ロールバック情報作成などのコストの高さが原因です。また、インデックスの有無が大きく影響しています。こういった行データを管理する複雑さ故のコストの高さはOracleでは避けられません。 ただし、全件deleteの場合ならばtruncateコマンドもありますし、インデックスを一旦削除するという方法もあるでしょう。削除に関してはPostgreSQLではそこまで考えずに実行しても問題なさそうです。
※注：
truncateコマンドはOracle、PostgreSQL共に使用可能です。
|
||||||||||||||||||||
| 条件付きの削除テスト | ||||||||||||||||||||
|
続いてもう少し実用に即したパターンのデータも比較してみます。updateのテスト同様10万件あるデータ中の1万件をランダムに選択し、deleteします。 |
||||||||||||||||||||
delete from 社員表 where 社員番号=[任意の番号];
|
||||||||||||||||||||
|
上記のようなSQL文を1万回繰り返し処理します。社員番号はランダムに生成し、1から10万までの範囲で重複もありえます。 |
||||||||||||||||||||
 図4：10万件のデータから1万件をランダムに削除した場合の実行速度 |
||||||||||||||||||||
| この場合もupdateと同様の結果となりました。インデックスありの場合、実行時間は「Oracle ＞ PostgreSQL」であり、インデックスがない場合は逆に「Oracle ＜ PostgreSQL」となります。 インデックスなしの場合の結果とありの場合の結果が非常に大きな差となって現れるPostgreSQLの結果も同様でした。PostgreSQLのインデックスの有無による処理時間の差は、57倍ほど（参考にOracleは2.3倍ほど）あり、インデックスの効果の程が明らかに見て取れます。 delete文のテスト結果もinsert文の場合と同様、単純なデータの削除速度のみで言えば、PostgreSQLの方が高速であるという結果でした。理由についてはupdateのテスト結果と同じく、そのデータ構造の違いによる操作時のコスト差であると言えます。 |
||||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
-
-
連載
