http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=001101
１位 応募の理由に疑問を感じた
２位 面接での会話がなり立てない
３位 根拠のない自信過剰
４位 給与・制度・残業ばかり気になる。
５位 前の会社の愚痴、悪口を言う
2007年7月8日日曜日
一テーブルのカラム数について【ＤＢの正規化と非正規化】
引用：http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=26266&forum=26&start=8&12
■ 問題提起
「DBを正規化すると遅くなる」は誤解だそうです。
実体験から感覚的になんとなくそんな気がしていましたが、
実証結果を発表したプロジェクトがあります。
http://itpro.nikkeibp.co.jp/article/NEWS/20051114/224500/
興味を惹かれたので、詳細を見てみました。
http://www.doaplus.com/html/bun03_20051101.html
◎ 反論１
結論ありきの無理やりな実証、というのが素直な感想です。
「非正規化は早いか否か」という問題設定ではなく、早くなるケースもあるということを前提に、どういうケースなら効果を得られるのか・得られないのかというアプローチのほうが良いと思うんですが。
正規化モデルでは性能要件を満たせなくて、非正規化モデルなら満たせる場合だけ非正規化すればよいのです。実際に非正規化する場合は、もちろんプロトタイプとかを用いた実機検証が必要。
そして「非正規化のほうが早い」というだけで非正規化しないことが重要。性能に関する比較を行う場合は、「方式1と方式2を比較」だけではなく、「性能要件と比較」という観点を忘れるべきではありません。
◎ 反論2
私は当該ページを、正規化を推奨するためのプロパガンダと感じました。正規化だけでなく、適切な冗長化がよりよいパフォーマンスを生むと考えている私は、あのページの内容にはまったく同意できません。
世の中の冗長化が「適切な冗長化」だったらいいんですけど。。
概念分析 → 正規化 → ボトルネックを冗長化 （オブジェクト参照の競合排除）
って手順ならいいわけです
もしくは、DB設計に精通した方が分析からいきなりボトルネック箇所を
冗長化した設計にできるのなら正規化と一緒でもいいかもしれません。
現実は違って、概念分析も行わず画面をそのままテーブルにしたような
元から冗長化されまくった構造を見かけることが非常に多いです。
正規化されてないように見えても、実は正規化されている場合もあります。
例えば、商品マスタと販売系のトランザクションテーブルで重複して商品
データを持っているような場合だと、商品マスタは今後扱っていく商品、
販売側は販売時点のデータ、というような別の意味になったりもします。
冗長化を行う前提として、適切な論理設計が必要なのではないですか？
パフォーマンス目的の冗長化はあくまで物理レベルのチューニングであって、
その元となる正規化された構造が必ずあるはずですから。
とはいえ、列方向への非正規化は問題外じゃないかと。
■ 問題提起
「DBを正規化すると遅くなる」は誤解だそうです。
実体験から感覚的になんとなくそんな気がしていましたが、
実証結果を発表したプロジェクトがあります。
http://itpro.nikkeibp.co.jp/article/NEWS/20051114/224500/
興味を惹かれたので、詳細を見てみました。
http://www.doaplus.com/html/bun03_20051101.html
◎ 反論１
結論ありきの無理やりな実証、というのが素直な感想です。
「非正規化は早いか否か」という問題設定ではなく、早くなるケースもあるということを前提に、どういうケースなら効果を得られるのか・得られないのかというアプローチのほうが良いと思うんですが。
正規化モデルでは性能要件を満たせなくて、非正規化モデルなら満たせる場合だけ非正規化すればよいのです。実際に非正規化する場合は、もちろんプロトタイプとかを用いた実機検証が必要。
そして「非正規化のほうが早い」というだけで非正規化しないことが重要。性能に関する比較を行う場合は、「方式1と方式2を比較」だけではなく、「性能要件と比較」という観点を忘れるべきではありません。
◎ 反論2
私は当該ページを、正規化を推奨するためのプロパガンダと感じました。正規化だけでなく、適切な冗長化がよりよいパフォーマンスを生むと考えている私は、あのページの内容にはまったく同意できません。
世の中の冗長化が「適切な冗長化」だったらいいんですけど。。
概念分析 → 正規化 → ボトルネックを冗長化 （オブジェクト参照の競合排除）
って手順ならいいわけです
もしくは、DB設計に精通した方が分析からいきなりボトルネック箇所を
冗長化した設計にできるのなら正規化と一緒でもいいかもしれません。
現実は違って、概念分析も行わず画面をそのままテーブルにしたような
元から冗長化されまくった構造を見かけることが非常に多いです。
正規化されてないように見えても、実は正規化されている場合もあります。
例えば、商品マスタと販売系のトランザクションテーブルで重複して商品
データを持っているような場合だと、商品マスタは今後扱っていく商品、
販売側は販売時点のデータ、というような別の意味になったりもします。
冗長化を行う前提として、適切な論理設計が必要なのではないですか？
パフォーマンス目的の冗長化はあくまで物理レベルのチューニングであって、
その元となる正規化された構造が必ずあるはずですから。
とはいえ、列方向への非正規化は問題外じゃないかと。
「DBを正規化すると遅くなる」は誤解，実証実験の結果が公開に
「DBを正規化すると遅くなる」は誤解，実証実験の結果が公開に
http://itpro.nikkeibp.co.jp/article/NEWS/20051114/224500/
データ・モデリングの普及団体，DOA+コンソーシアムはこのほど，リレーショナル・データベース管理システム（RDBMS）の処理性能に関する実証試験を行い，調査結果を公開した。「データを正規化してデータベースに実装すると，処理性能が低下する」という“誤解”を正すため，実証実験を行ったという。
※ 詳細はこちら
http://www.doaplus.com/html/bun03_20051101.html
データを正規化して実装したときと，非正規化して実装したときの処理性能の違いを調べた結果，「正規化して実装したデータベースの方が処理性能が高い」，「非正規化して実装したデータベースを操作する際，テーブル結合（JOIN）が発生する処理を行うと，処理性能が低くなる」と結論付けた。
実証実験では，自動車の受注業務を想定したWebシステムを構築して，処理性能を測定した。このWebシステムは，データベース上に格納された受注データを基に，製品データや部品データ，部品メーカのデータなどを検索する。
データベース実装の違いを調べるため，Webシステムは，(1)データベース上にデータを正規化して実装したものと，(2)非正規化して実装したものの2パターンを用意した。実証実験は，これら2パターンのシステムのデータベースに，受注データ500万件，受注明細データ5000万件などを格納して実験した。
実証実験の結果，データベース上の単一テーブルを対象に検索した場合，いずれのパターンも2～3ミリ秒で処理を終えた。一方，3つ程度のテーブルにわたりデータを検索した場合，正規化したパターンでは，5000万件のデータを90ミリ秒で検索できた。だが，非正規化したパターンでは，500万件のデータ検索に14秒かかった。
テーブルを1つだけを検索するときには処理速度に差がつかず，複数テーブルにわたって検索すると処理性能に差が出ている。非正規化されたデータベースの場合，複数テーブルで同じ項目を持つことになる。その項目が検索対象になると，その項目を含め，複数のテーブルから値を集計するようなケースでは，テーブルの結合処理が多く発生するためだ。
実証実験の参加者のひとり，ウルシステムズの鳥谷部 聡シニアコンサルタントは，実証実験の結果を受けて，「単一テーブルをアクセスする処理時間がほとんど変わらないのであれば，正規化して実装したほうがデータベースの構造を変更することになっても対処しやすい。複数テーブルにわたって検索処理をするときには，非正規化すると処理性能は極端に落ちる。いずれにしても，非正規化するより，正規化して実装するほうが有利だ」と説明する。
実証実験にはこのほか，NECネクサソリューションズ，住友電気工業，データアーキテクト，PFUの各企業のITエンジニア／コンサルタントが参加した。実験で使用したサーバーは，100万円程度のもの。動作周波数3.6GHzのXeonプロセサを2個，7GBの主記憶，300GBのハードディスクを5個搭載する。サーバーOSにLinux，データベース管理ソフトにPostgreSQL，Webサーバー・ソフトにTomcatを採用した。
http://itpro.nikkeibp.co.jp/article/NEWS/20051114/224500/
データ・モデリングの普及団体，DOA+コンソーシアムはこのほど，リレーショナル・データベース管理システム（RDBMS）の処理性能に関する実証試験を行い，調査結果を公開した。「データを正規化してデータベースに実装すると，処理性能が低下する」という“誤解”を正すため，実証実験を行ったという。
※ 詳細はこちら
http://www.doaplus.com/html/bun03_20051101.html
データを正規化して実装したときと，非正規化して実装したときの処理性能の違いを調べた結果，「正規化して実装したデータベースの方が処理性能が高い」，「非正規化して実装したデータベースを操作する際，テーブル結合（JOIN）が発生する処理を行うと，処理性能が低くなる」と結論付けた。
実証実験では，自動車の受注業務を想定したWebシステムを構築して，処理性能を測定した。このWebシステムは，データベース上に格納された受注データを基に，製品データや部品データ，部品メーカのデータなどを検索する。
データベース実装の違いを調べるため，Webシステムは，(1)データベース上にデータを正規化して実装したものと，(2)非正規化して実装したものの2パターンを用意した。実証実験は，これら2パターンのシステムのデータベースに，受注データ500万件，受注明細データ5000万件などを格納して実験した。
実証実験の結果，データベース上の単一テーブルを対象に検索した場合，いずれのパターンも2～3ミリ秒で処理を終えた。一方，3つ程度のテーブルにわたりデータを検索した場合，正規化したパターンでは，5000万件のデータを90ミリ秒で検索できた。だが，非正規化したパターンでは，500万件のデータ検索に14秒かかった。
テーブルを1つだけを検索するときには処理速度に差がつかず，複数テーブルにわたって検索すると処理性能に差が出ている。非正規化されたデータベースの場合，複数テーブルで同じ項目を持つことになる。その項目が検索対象になると，その項目を含め，複数のテーブルから値を集計するようなケースでは，テーブルの結合処理が多く発生するためだ。
実証実験の参加者のひとり，ウルシステムズの鳥谷部 聡シニアコンサルタントは，実証実験の結果を受けて，「単一テーブルをアクセスする処理時間がほとんど変わらないのであれば，正規化して実装したほうがデータベースの構造を変更することになっても対処しやすい。複数テーブルにわたって検索処理をするときには，非正規化すると処理性能は極端に落ちる。いずれにしても，非正規化するより，正規化して実装するほうが有利だ」と説明する。
実証実験にはこのほか，NECネクサソリューションズ，住友電気工業，データアーキテクト，PFUの各企業のITエンジニア／コンサルタントが参加した。実験で使用したサーバーは，100万円程度のもの。動作周波数3.6GHzのXeonプロセサを2個，7GBの主記憶，300GBのハードディスクを5個搭載する。サーバーOSにLinux，データベース管理ソフトにPostgreSQL，Webサーバー・ソフトにTomcatを採用した。
2007年6月13日水曜日
2007年6月7日木曜日
登録:
投稿 (Atom)
Jang ki hote
