RDB入門　～アプリケーション開発者が陥りやすいDB開発の落とし穴～

RDB入門～アプリケーション開発者が陥りやすいDB開発の落とし穴～ 18-E-6 磯辺信雄アイエニウェア･ソリューションズ株式会社エンジニアリング統括部課長 Developers Summit 2010

アプリケーション開発者が陥りやすいDB開発の落とし穴  導入・開発時等に実際にご相談のあった内容を元にRDBの技術等について解説します。  ケーススタディ1  システムが止まった  ケーススタディ2  プログラムのパフォーマンスが出ない  ケーススタディ3  Viewを使っているのだがパフォーマンスがでない  ケーススタディ4  マルチ（コア）CPUが有効に利用されてないようだ Developers Summit 2010

ケーススタディ１システムが止まった  スタンドアロンで稼働するPOSシステム  数百台規模で展開  １日あたり数台が特定の処理でフリーズ  テスト環境で同じ処理を行っても再現しない  すべての端末で詳細なログを取るように設定  現象が発生した端末からログを回収 Developers Summit 2010

ケーススタディ１システムが止まったその原因は  ある処理がトランザクション分離レベルをRead Committedに設定  このシステムではRead Uncommittedが前提  マルチスレッドプログラムでコネクション・プーリングを使用  後続の読み込み処理にRead Committedに設定されたスレッドが割り当てられた  実行中のトランザクションによってブロック  画面遷移が出来なくなり、Commitに辿りつけず操作不能に… Developers Summit 2010

ケーススタディ１トランザクション分離レベルとは  データベース上でトランザクション処理が複数同時に行われたときに一貫性・正確性を４段階に定義したもの繰り返し不可能分離レベルダーティ・リード幻ロー読み出し Read Uncommitted ありありあり Read Committed なしありあり Repeatable Read なしなしあり Serializable なしなしなし Developers Summit 2010

ケーススタディ１システムが止まったその原因は処理２で更新中のデータをSelectしようとしてブロ Selectだけなのでトラン ReadCommittedで処理ックされたスタートザクションをかけずに処理スタート処理3 処理1 コネクション１ SQL Anywhere データベース処理2 コネクション２コネクションプール Read Uncommittedでトランザクションスタート Developers Summit 2010

ケーススタディ１システムが止まった問題点と解決策  .NETの仕様  プールされているコネクションは直前に使用された時の分離レベルを継承する  解決策  処理開始・終了時に必ず分離レベルの設定を行う  トランザクション分離レベルを十分に理解しましょう！ Developers Summit 2010

ケーススタディ１トランザクション分離レベルとは  RDBMSによって実装の仕方が違う  ANSI/ISO SQL標準  Oracleではこのケースは発生しない  読み取り一貫性  SQL Server、SQL Anywhere等では新しい分離レベルを用意  スナップショット分離レベル（読み取り一貫性の実現）  トランザクション開始時にスナップショットを取るため、ディスクの空き容量に注意  状況に応じて使い分けることを推奨 Developers Summit 2010

ケーススタディ2 プログラムのパフォーマンスがでない  月別の売上件数を表形式に表示する処理のパフォーマンスがでない  切り分けをしてみるとDBに接続している時間が長い・・・SQLが遅いのでは？  実行されたSQLの履歴をログとして収集・分析 Developers Summit 2010

ケーススタディ2 プログラムのパフォーマンスがでない  ログを分析してみると  カラムごとに集計のSQLが実行されていた  SELECT COUNT(*) AS CNT FROM tab01 WHERE nen = ‘2003’ AND tsuki = 1 12月 15 14 11月 12 15 14 12 15 10 3 10月 30 10 3 30 10 3 6 9月 20 3 6 12 15 20 3 6 8月 5 1 30 10 5 1 7月 12 15 14 3 6 10 15 20 6月 30 10 3 1 8 10 16 5月 12 15 14 6 15 14 1 15 14 4月 30 10 3 10 3 6 10 3 3月 20 3 6 20 3 6 3 6 2月 5 1 5 1 １月 15 10 3 1 2002 2003 2004 2005 2006 2007 2008 2009 2010 Developers Summit 2010

ケーススタディ2 プログラムのパフォーマンスがでない  列単位に集計するように修正  SELECT nen,tsuki,COUNT(*) AS CNT FROM tab01 WHERE nen = 2003 group by tsuki,nen order by tsuki,nen 12月 15 14 11月 12 15 14 12 15 10 3 10月 30 10 3 30 10 3 6 9月 20 3 6 12 15 20 3 6 8月 5 1 30 10 5 1 7月 12 15 14 3 6 10 15 20 6月 30 10 3 1 8 10 16 5月 12 15 14 6 15 14 1 15 14 4月 30 10 3 10 3 6 10 3 3月 20 3 6 20 3 6 3 6 2月 5 1 5 1 １月 15 10 3 1 2002 2003 2004 2005 2006 2007 2008 2009 2010 Developers Summit 2010

ケーススタディ2 プログラムのパフォーマンスがでない  全体を一度に集計するように修正  SELECT nen,tsuki,COUNT(*) AS CNT FROM tab01 group by nen,tsuki order by nen,tsuki 12月 15 14 11月 12 15 14 12 15 10 3 10月 30 10 3 30 10 3 6 9月 20 3 6 12 15 20 3 6 8月 5 1 30 10 5 1 7月 12 15 14 3 6 10 15 20 6月 30 10 3 1 8 10 16 5月 12 15 14 6 15 14 1 15 14 4月 30 10 3 10 3 6 10 3 3月 20 3 6 20 3 6 3 6 2月 5 1 5 1 １月 15 10 3 1 2002 2003 2004 2005 2006 2007 2008 2009 2010 Developers Summit 2010

ケーススタディ2 プログラムのパフォーマンスがでない  要求仕様を単純にSQLに置き換えるのは危険  この例では12×9回のSQLが実行されていた  一回あたりの実行時間が短くても回数が増えれば当然パフォーマンスは低下する  修正後は、1回のSQL＋結果セットからのフェッチ  効率のよいSQLを検討する Developers Summit 2010

ケーススタディ3 Viewを使っているのだがパフォーマンスがでない  Viewは非常に便利だが使い方によっては気づかずにパフォーマンスを低下させることがある  単純にテーブルをJOINしているViewはそれほど問題にならない（ベーステーブルへの適切なインデックスは必要）  集合関数・集合演算子は注意が必要  sum,avg,count,max,min等  union,intersect,except等  大量データを集約するようなViewはコストが掛かる Developers Summit 2010

ケーススタディ3 Viewを使っているのだがパフォーマンスがでない  Viewを使ってパフォーマンスがでない簡単な例  以下のようなViewを作成 create view View_sum as select region ,sum(quantity) as qty from orders group by region  以下のようなselect文を実行 select region,qty from View_sum where region = ‘West’  viewが評価された後にwhere条件で抽出されるため、 orderテーブルは全件集約される Developers Summit 2010

ケーススタディ3 Viewを使っているのだがパフォーマンスがでない  Viewを使ってパフォーマンスがでない簡単な例  Viewを使わないと… select region ,sum(quantity) as qty from orders where region = ‘West’ group by region  orderテーブルからwhere条件で抽出されたローだけが集約されるため、Viewを使った場合より高速 Developers Summit 2010

ケーススタディ3 Viewを使っているのだがパフォーマンスがでない  マテリアライズド・ビューという解決方法もある  実データを保持するのでパフォーマンスが良い  集合関数・集合演算子を使用するようなViewと親和性が高い  オプティマイザに自動的に使用を判断させることも可能  SQL文を変更せずにパフォーマンスの向上が見込める  注意点  Refleshの管理が必要  実データを保持するための領域が必要 Developers Summit 2010

ケーススタディ3 Viewを使っているのだがパフォーマンスがでない  マテリアライズド・ビューのデモ  約25万件の売り上げ明細データから特定月の担当者別・日別の売り上げ金額・数量の集計を求める SELECT employees.surname, employees.givenname, CREATE MATERIALIZED VIEW demo AS salesorders.orderdate, SELECT employees.surname, employees.givenname, SUM(products.unitprice * salesorders.orderdate, salesorderitems.quantity) AS TotalSales, SUM(products.unitprice * SUM(salesorderitems.quantity) AS NumberOfSales salesorderitems.quantity) AS TotalSales, FROM (((salesorders JOIN employees ON SUM(salesorderitems.quantity) AS NumberOfSales salesorders.salesrepresentative = FROM (((salesorders JOIN employees ON employees.employeeid) JOIN salesorderitems ON salesorders.salesrepresentative = salesorders.id = salesorderitems.id) JOIN employees.employeeid ) JOIN salesorderitems ON products ON products.id = salesorders.id = salesorderitems.id) JOIN salesorderitems.productid) products ON products.id = WHERE YEAR(orderdate) = 2001 AND MONTH(orderdate) = 7 salesorderitems.productid) GROUP BY employees.surname, GROUP BY employees.surname, employees.givenname, salesorders.orderdate; employees.givenname,salesorders.orderdate; Developers Summit 2010

ケーススタディ4 マルチ（コア）CPUが有効利用されてないようだ  CPUのマルチコア化に伴い、RDBMSもマルチCPU 構成を有効に利用するようなアーキテクチャを実装してきている  クエリ間並列処理  複数接続からのクエリ要求を別々のコアに分散実行  クエリ内並列処理  1つのクエリ内の処理を別々のコアで実行  並列インデックススキャン・並列ソート等 Developers Summit 2010

ケーススタディ4 マルチ（コア）CPUが有効利用されてないようだ  負荷の高いSQLを複数投入してみたが、コアの1つしかCPU使用率が上がらない  ディスクI/Oがボトルネックになっていることが考えられます  キャッシュサイズを増やす  速度の速いディスクを採用する  データベースの配置を複数の物理ディスクに分散する Developers Summit 2010

SQL Anywhere 製品紹介

SQL Anywhere の概要製品基本コンセプト省リソースで管理者不要なデータベースと分散環境の統合、既存システムとの連携ソリューションを提供する包括的なパッケージ製品です省リソースで稼動マルチCPU、64bit(X64）に対応容易なデータ移行ハード投資を抑える Windows XP Windows サーバノートＰＣなどでも軽快に動作。規容易な Vista WMもサポート。初最小限の投資模規模拡張期拡容易なインストール投業務拡大への張 Windows Mobile Linux サーバ資迅速な対応・データベースをファイルコピーの・デ設定要員コスト削減運既存資産のーみで移行可能。使用していたデータをそのまま移行できます。用有効活用タモジュールはCD-ROM1枚で。コ連データ移行が容易既存DBとのデータ同期複雑な設定なしで自動インストースル可能ト携管理の自動化削が減容既存データ既存データベース易活用・連携運用コスト削減エンタープライズクエリ自動学習機能や自動リカバリ機能により、データベースメ既存DB、ORACLEやSQL Server 中堅・中小企業システム IBM DB2などとデータ同期可能。ンテナンスの必要性を極力排除既存データを活用できます。モバイルパッケージ組み込み 22 – Copyright © 2010 iAnywhere Solutions K.K.

SQL Anywhereの概要ビジネス要件の拡張への対応 8U 分散DB環境をデータ同期によりデータ統合データ同期を使い、モバイル Mobile Link システムへと拡張 DBファイルのコピーでバックアップ、復旧や移行可能 Windows Server OS(32bit/64bit），Linux サーバエンジンやWMにも対応 Linux 既存PC等の低スペック（RAM256M)でも稼動 自動チューニング/自動リカバリ BlackBerry テーブル/カラム、通信の暗号化 Windows Mobile 対応 Windows スタンドアロンエンジンモバイル 23 – Copyright © 2010 iAnywhere Solutions K.K.

SQL Anywhereの概要ビジネス要件の拡張への対応基本コンセプトに加え、データ量増大やユーザ数増加などビジネス要件の拡張に伴い、さらに処理効率を向上させる機能を実装パフォーマンス開発・運用  マテリアライズド・ビュー  Visual Studio への統合規  スナップショット・初最小限の投資模  充実した統合管理・分析Tool アイソレーション期拡投業務拡大への  配布インストーラ作成Tool 張  パラレル・クエリ資迅速な対応・・デなど運既存資産のーなど用有効活用タデータ管理コス連データ同期・統合ト携  高可用性オプション削が  容易なデータ同期設定減容  柔軟なデータ暗号化易  Text等その他データソースなど同期用API  メッセージング、Webサービスとのインターフェイス 24 – Copyright © 2010 iAnywhere Solutions K.K. など

その他各種情報 – アイエニウェア・ソリューションズ株式会社ホームページ http://www.ianywhere.jp  製品情報 http://www.ianywhere.jp/prd/index.html  弊社ソリューション情報 http://www.ianywhere.jp/sol/index.html 25 – Copyright © 2010 iAnywhere Solutions K.K.

その他各種情報・アイエニウェア・ソリューションズデベロッパー・コミュニティ http://www.ianywhere.jp/developers/index.html - SQL Anywhere Developer Edition SQL Anywhere の開発者バージョンがダウンロードできます。開発者バージョンは、ユーザ登録のみで、開発用途限定で日数制限無く製品版と同様の機能をご利用いただけます。 - 開発者向けニュースグループ弊社製品をご利用頂く中で、製品に関するご質問についてはニュースグループをご活用ください。弊社エンジニアも時間の許す限り、支援いたしております。 26 – Copyright © 2010 iAnywhere Solutions K.K.

http://www.slideshare.net	28
http://www.mefeedia.com	2
http://s.deeeki.com	1

RDB入門　～アプリケーション開発者が陥りやすいDB開発の落とし穴～

by nisobe58 on Feb 22, 2010

Accessibility

Tags

Upload Details

Usage Rights

3 Embeds 31

Statistics