« PostgreSQL事例紹介セミナー2008 | メイン | 今週末は、、、 »

2008年11月28日

PostgreSQL 事例紹介セミナー2008

カテゴリ：PostgreSQL

　というわけで、行ってきました『PostgreSQL 事例紹介セミナー2008』。おっきいモノから身近なモノまで色々あって、大変参考になりました。

　というわけで、いつものメモです。
　あ、でも、今回はメモって言うか資料の中から重要な部分の抜粋に近いかも。
　いつも通り、あまり深く考えないでね。

　っていうか、坂井さん、これだよこれ。（坂井さんってだれ？）ポータルの記事頑張ってね。

-----

【大規模導入事例（証券取引所クラス）のご紹介】
サンマイクロシステムズ(株)　システム技術統括本部　中村 完氏

・SunDWアプライアンス
・でかいなぁ
・S1010、DB論理容量100TBって、どんな単位や

・シェアードナッシングアーキテクチャ
・単一DBのデータレコードを複数サーバに分散配置
・各サーバが平行してDB処理を行う、ディスクi/OやCPUに対するワークロードを分散、スケーラビリティを確保
・複数のセグメントホストを組み合わせ単一データベースをとして稼働

・SunDWでのデータ分散
・八種アルゴリズム、セグメントインスタンスに対してバランスの取れた処理とデータは一
・スキーマセットを重複のないように小分けにする

・SunDWでのクエリ実行
・マスタインスタンスがクエリ処理に対して実行プランを作成
・送られたプランに従って、各セグメントが各々管理するデータを処理、結果表示

・SunDWでの高可用性
・ミラーセグメント
・プライマリセグメントにアクセスできない、セグメントホストに障害が発生した場合、別ホストにミラーセグメントにスイッチオーバー

・Sun Fire X4500
・2つのDual-Core AMD Opteron
・4Uで48TB、SATA HDDを48本、凄まじく密集HDDだ
・48本のディスクを6つのコントローラで制御
・4つのGBEthernet port

・東京工業大学のTSUBAMEスーパーコンピューターで利用

・ZFS、Zettabyte File System
・ext3よりも圧倒的に高速
・バックアップ機能、スナップショット作成（瞬時に終了、取得時にはデータ容量ゼロ、変更分だけデータ容量が追加）、スナップショットは複数回取得可能

・デモ、マスター1台、セグメント2台
・コマンド実行はマスターインスタンスには全く負荷が掛からない、全てセグメント側で処理
・んー、キレーに2倍になるなぁ

・まとめ
・高パフォーマンス、高いコストパフォーマンス、高い拡張性、高い可用性、容易性、オープン性、低消費電力（120w/TB）

・ハードの単価っておいくらなんだろ
・ただ、商用のモノって考えれば、このスケールの容易性は重要かも

【携帯CGMサイトにおけるPostgreSQL可能性対策について】
(株)ビジュアルワークス　取締役 社長室 室長　落水 恒一郎氏

・ビジュアルワークス
・モバイルコミュニティ＆モバイルメディア事業
・フォレストページ（forest page）、モバイルサイトの無料作成サービス
・携帯小説、同盟？、検定、専門学校情報

・フォレストページ、プロフ、日記とか、SNS的なコミュニティとか
・月間25億pv、7～8割が携帯、200万人、利用者の7～8割が女子中高生、女性比率95%
・1日6時間から8時間、平均月額パケット代60～80万円、コア層
・バナー広告以外に、クロスメディアマーケ、PCや雑誌などと
・公募型プロモーション、コカコーラの友情学園（TVCM）
・Disnyの無料公式モバイルサイト（アライアンス）

・システム構成
・Webサーバが数十台、DBサーバ数台、データセンター数ラック
・データベースの特徴、テーブル数が多い（2000テーブル）、一つのテーブルが大きい
・アクセスに関する特徴、参照：更新＝８：２、小さくシンプルなクエリ、24時間365日アクセス、ピーク時間23時～1時（700万pv/h）、逆は4～6時（100万pv）
・データに関する特徴、データ量が多い、200GB
・4年前に初めて、ここまででかくなるとは思っていなかった

・課題
・性能劣化
・ユーザ数増大、アクセス数の増加、ユーザ向けの新機能の追加、コンテンツ増大
・PostgreSQLのバージョンアップ（8.1→8.3）で改善（若干）
・が
・高可用性のニーズ対応を、、、
・Slony-Iの導入、Pgpool-IIとの組み合わせでダウンタイム軽減、検索機能のスレーブ参照によるレスポンスの改善

・導入
・Webサーバにpgpool、DBサーバはマスタをSlony-Iでスレーブを作成、更新はマスタ、参照はスレーブ
・Slony-Iの導入で、SRAOSS Incにコンサルティング依頼
・導入の時に気になったポイント、同期して本運用に入るまでに要する時間、レプリケーション実施による性能劣化、ピークタイムにおける同期遅延

・導入の状況
・データの同期時間、テーブルのセット10分、テーブル追加5.5時間、シーケンスのセット1時間、初期データの同期（コピー）3時間、初期データのコピー中の更新3時間
・エラーがあって、ギリギリ36時間

・導入後
・そもそも非同期の状況が発生
・Slony-Iの利用にあたっては、Primary keyが必須
・ALTERテーブルが大変
・障害時の復旧について

・導入前に気になったポイント
・レプリケーション実施による性能劣化
・ピークタイムにおける同期遅延、数秒程度

・今後の課題
・Slony-Iを利用した上での運営ノウハウ
・更新を含めたさらなる負荷分散
・DB分割を行い、それぞれにSlony-Iを利用
・Slony-Iの動きとかよくわからん

・広告配信システムもPostgreSQLを使ってる
・ADサーバ

・AmebloよりもPVがある
・それって、すごいな
・かなりシンプルな構成なのに、ここまでレスポンスが出せるってのはすごい

・PostgreSQLを選んだ理由
・ビジネスとしてどこまで成長するかわからなかったので、商用DBを使うことは考えずPostgreSQLの存在を知ったので
・アプリケーションは？
・PHP
・OSはRHEL

【医療分野における診断画像データベースを支えるPostgreSQL】
(株)日立メディコ
メディカルIT事業部　システム本部　開発部　画像グループ　鈴木 雅登 氏

・日立メディコ
・医用画像診断装置の開発・製造・販売・サービス
・2300名
・日立の中央研究所で創られたモノで医療機器関係の製造販売をしている

・画像診断装置＝モダリティ
・CTスキャナ装置、MRI装置、X線診断装置、PET/CT装置、超音波診断装置、光トポグラフィ装置、マンモグラフィーとか
・こういった装置を作っている訳じゃなくて、こういった装置につなげる機器類を作っている

・PACS、Picture Archiving Communication System
・種々の医用画像をデジタル化してDICOM規格を用いて大容量の記憶媒体に保管し、医師が診断するのに『必要な画像』を『必要なとき』に『必要な場所』で迅速に取得し、表示するシステム

・DICOM、Digital Imaging and COmmunication in Medicine
・医療画像診断装置、医用画像プリンタ、医用画像システム、医療情報システムがらみの画像データや関連する診療データを通信、保存する方法を定めた国際標準規格

・病院にPACSを導入すると
・フィルム運搬業務の軽減
・これまではかなり負担が大きく多くの時間が消費されていた
・保管庫の削減

・日立メディコのPACS製品
・DICOM画像サーバ　WeVIEW、DICOM画像を受信し、画像データの保存・管理を行う、RHL ES 3.0、PostgreSQL 8.1.6
・画像診断ワークステーション　NV-1000（医事品クラスII）、DICOM画像を高精細モニタ上で表示、画像ビューワ、Microsoft Windows XP PostgreSQL8.1.6
・2007年度グッドデザイン賞受賞、医者に負担をかけない画面のデザインなど
・デモ、マウスでやりたい操作が直感的にできる

・OSI参照モデルとDICOM規格
・OSI参照モデルに準じるように通信プロ所るを定める
・OSI参照モデルの上位層（5,6,7）のプロトコルを定義

・画像保存処理
・画像情報を『保存（転送）』する機能を定めている
・画像を保存要求（転送）する側：Service Class User（SCU）
・画像を保存（受信）する側：Service Class Privider（SCP）
・モダリティが50台つながってる病院も
・患者情報テーブル→検査情報→撮影情報→画像情報
・ロック多用

・画像検索・取得
・画像情報を『問い合わせし転送要求』する機能を定めている
・画像を検索する側：SCU
・検索に対して応答する側：SCP

・画像発生量の推移と保存容量
・1000床規模の大規模病院、8年くらいで50年くらい増えてる
・現在は80TBクラス
・1日12万枚/日、消費ディスク容量70GB/日＝16TB/年

・Enhanced DICOM
・従来のCT/MRのDICOMはヘッダ情報が画像毎に存在
・Enhanced DICOMによるデータ構造とプロトコルの見直し
・Functional GroupによるMultiFrame構造の定義
・トランザクションの低減
・が、国内では全く普及していない、、、現在はDICOMが使われ続けている

・画像発生ピーク時間の処理性能
・午前中に検査が発生、システム負荷が掛かる

・SLB（Server Load Balancer）によるアクセスの分散・冗長化
・各サーバへのアクセスはSLBを介し、サーバ負荷や稼働状況を監視することで冗長化

・データベース冗長化
・更新系はDB同期モジュールを使用し、各サーバのデータを更新
・参照系は各サーバ毎で可能なので、負荷軽減

・課題と解決方法
・冗長化構成の関係上、データ更新時にテーブルロック。レコード数が多い（3億レコード）テーブルではVacuum処理が短時間で完了しない
・解決策、ロック制御専用テーブルを作成し、スレッド間の排他処理はロック専用テーブルを介して行うように、エーブルロック相当の排他処理とVacuumの両立

・まとめ
・PostgreSQLの使い方に1部工夫は必要だけど、医療画像システム用途にも利用できるデータベースマネジメントシステムとして、多くの医療施設で導入実績を重ねている

・画像自体もPostgreSQLに入ってる？
・画像自体は、ファイルとして置かれている


【PostgreSQLを使ったチラシ・口コミサイトの構築・運営事例】
オールクリエイター(株)　代表取締役　橋本 俊秀 氏

・電子チラシ＆口コミサイト「とっとくねっト」
・会員2万人、3年くらい
・日本初の携帯3社対応電子チラシサイト

・OSは好みでLinux、Perl5、Pgの使い方が載ってたから、、、PostgreSQLで作り始める
・その後言語をPerlからPHP、OSをRedHatからVine、でもDBはPostgreSQLのまま

・活用したテクニックと功罪
・シリアル型の活用、タイムスタンプの内部取得、プログラムの生産性は向上、が、pgpoolを使おうとしたときの障害に、、、pgpoolあきらめる
・標準SQL＆シンプルSQLの組み合わせ、ソースは見やすいけどレスポンスの遅さが発生、joinを活用、別の開発メンバーがPostgreSQL独自の文法などを導入、explain analyzeして事前にコストを調査
・カーソル関数とVIEW、データ件数が増えるとオーバーヘッドが大きい、カーソルは避ける、VIEWも同様今は使っていない
・JOINを使う、対象が4000件を越えるとコストが掛かるので、絞り込んでからJOINするように
・テーブル定義時の厳密なカスケード指定、cascade deleteは指定せずにクリーンアッププログラムを実行
・システムカタログ、PostgreSQL8にVersionUPで障害、、、システムカタログは使わないように
・バックアップとリストア、7→8でバイナリバックアップで失敗、全て8系列に
・PGクラスタ、サーバの不具合（使い方の問題？）、、、PGクラスタを使わずに、サーバのハードバージョンアップ

・これから導入する方へのアドバイス
・業務的なテーブル設計はほどほどに、単なる機械的な一意キーとしておき、業務キーは別項目で非キーとして持つ方が、Web系はラク
・テーブル連携もほどほど
・explaine analyzeをしなされ、ぼろいマシンで、、、

【自治体ビジネスに向けたPostgreSQLでの試み】
(株)BSNアイネット　白柏 雅資 氏

・新潟、市町村の委託業務から始まる

・OSSによる統合DBを介した基幹システムと業務システム連携の実証
・汎用機が拡張性を阻害、汎用連携データベースを運用
・総務省の動向（地域情報プラットホーム）

・なんだかよくわかんない

・PostgreSQL/pgpool-HA選定理由
・PostgreSQL
・可用性確保の選択肢が豊富
・企業買収などによる影響を受けにくい
・日本国内で実績や情報が多い
・新潟においてもコミュニティが存在、協力を得やすい
・pgpool-HA
・構成が単純でコストが掛からない
・データの保全性が高い
・Heartbeat連携用機能が提供されている
・日本初の技術でサポートを受けやすい
・pgpool-IIにしなかった理由
・負荷分散が必要ない
・パラレルクエリが必要ない

・共通基盤コードのフルオープンソース化の検証
・共通基盤と業務ユニットの連携の検証
・Webサービス連携の性能評価の検証

・トキめき新潟大会競技運営支援システム
・参加団体提供サービス、情報公開サービス、主催団体提供サービス、競技開催地提供サービス
・Webを使って、全ての情報の登録・結果登録・リザルト更新などを出来るように
・従来はAccessでクローズドな感じ
・ネットワーク対応、オープンソースの活用、Rubyによる開発、新たな技術による設計

【住友電気工業株式会社におけるオープンソースソフトウェアの積極的な導入】
住友電気工業(株)　情報システム部　中塚 康介 氏

・住友電工、でかい
・ワイヤーハーネス、光ファイバケーブル、、、でかい
・情報システム部門、情報システム部55名（システム企画、情報技術）、子会社で住友電工情報システム(株)360名（設計・開発・運用・保守）
・Linuxは1999年から、2006年からはLinux+Xen
・PostgreSQLは2005年から標準、それまではOracle・DB2とかInformix、その前はADBS？とか
・PostgreSQL以外のデータベース利用は承認が必要、、、、それもすごいな、つまり、でかい！
・現在開発が継続しているプロジェクトでも50以上が採用
・再帰SQL開発にリソース提供をしたそうです

・Xen
・ハードウェアの保守切れ対策
・サーバ数の増大
・障害発生時に異なるサーバでもシステムを動かすぜ
・2007年にXenによる仮想化を導入決定、I/O性能の問題は構成の標準化や運用でカバー
・システム構成の標準化、導入、運用の実施工数、問い合わせ工数を削減、運用やバックアップなどを統一的に実施

・導入時の評価、新人が評価を担当（1人で8件以上）、社内セミナーで説明、利用技術を全社で統一、技術素養を持ったシステム開発者の育成
・評価内容、パフォーマンス評価・安定性評価・障害対策、障害発生時の復帰方法・導入、運用、障害対応の作業手順が容易か、、、システム構築の標準を策定することで、導入のトラブルを防止、標準の範囲で性能、運用を保証

・正規化されたDBは高速に動作、indexを適切に利用することで正規化されたDBは非正規化されたDBよりも高速に動作
・非正規化されたDBはJOINすると非常に遅い、、

・運用標準策定

・システム構築事例、社内ポータルサイトver2、新申請システム
・社内ポータルサイトver2
・機能強化が目的、機能改善、スケジュール共有の機能強化、絞り込み機能、通知設定機能強化、その他の改善
・利用ユーザ数7400、データベースアクセス、COMMIT 9700/day、SELECT 6,000,000/day、データ送料5.4GB
・DBサーバ、Xeon 3GHz 4core * 2、メモリ12GB
・本番時のパフォーマンス悪化、PostgreSQLの問題かと思い、バージョンアップ、再チューニング、でも抜本解決に至らず
・原因はSQL、書き直し、1200msから30msへ改善
・設定変更での性能改善も大きいが、SQLの改善が問題解決につながった
・マルチコアなら8.2という事が共有されていなかった、、、

・新申請システム
・旧システムの問題点、登録ユーザ数の増加、発行申請文書数が2倍に、、、パフォーマンス定価
・データベースの選定、旧システムは商用、PostgreSQLなら改修コストは1/4
・移行テスト、全連携システムに対しテストの徹底を依頼、重要なシステムについてはテストケースも提示
・新申請システム規模、ユーザ26900、利用ユーザ2600/day、データベースアクセス　COMMIT 158,000/day、SELECT 8,000,000/day、データ総量32GB
・サーバ、旧Xeon2.4Ghz8core　メモリ4GB、新Xeon3Ghz4core*2、メモリ12GB
・本番時、パフォーマンス悪化
・Xenの問題ではない
・応急対応でアプリケーションサーバとデータベースサーバのハードを分離

・その他の問題
・EXPLAIN ANALYZEしなはれ
・バージョンのチェック
・仮想化など複合的な理由が多い
・インデックスアドバイザに期待

・リカバリ
・実際に壊して戻してみるセミナーをやってみる、ファイルを壊す、ディスクが溢れる等
・やってみると疑問点が多々
・仮想化しているので、サーバ自体を落とすというのもアリかもしれない

・ディスク溢れ
・不適切なSQLで巨大なpgsql_tmpが出来ていた

・今後のPostgreSQLの利用
・経理システムでのPostgreSQLの利用を検討
・使って安心できる仕組みが必要、pgpool-II、全社会議室システムをプロトタイプとして評価
・障害が発生しても確実に復旧できるか、レプリケーション、マニュアルに記載されていない挙動もチェック
・どこまでチューニング可能、「勘と経験と度胸」によるチューニングから脱したい



投稿者 ymkx : 2008年11月28日 20:17 |