2018年10月8日月曜日

db tech showcase 2018 Tokyo 感想等


概要

　「db tech showcase（https://www.db-tech-showcase.com/）」とは、毎年開催されている、データベースのミニセミナー、データベース関連のソリューション紹介無料イベント。全５会場で約４５分のミニセミナーが中心で、今年は9/19～21の３日間だったがどのセミナーも聞いておきたいほど講師、内容が充実している。（全日程×5名で聴講したいほど。）今回は9/21に出向いてみた。秋葉原UDX　6Fのセミナースペースで開催。
　セミナーによっては公式サイト（https://www.db-tech-showcase.com/）にスライドが公開されている（そうだが、参加したセミナーすべてスライドが無い／まだ無い）。

セミナー内容

　セミナーを受けた感想、気づき、およびセミナー最中にメモった内容を記載しておく。（メモは私的に気になったところ、および機械的にとった部分が多いので、正確性にかけているところが多いため、二次利用される場合等あればセミナー講師のブログ等、その他各種情報をご参照下さい。）


グラフ型データベース入門（株式会社シー・エス・エス　高橋悠氏）

●所感
グラフ型データベースについては以前Neo4j本執筆に携わったことがあるが、最近情報を仕入れていないこと、及びグラフ型データベースの利点について最近はどう話をしているのかを確認してみたかったので聴講。Amazonの高級グラフ型DBが出てきていること、実際の開発ではグラフ型をどう見せるかはやはり公式では難しいこと等確認。
●メモ（スライド公開無し）
  • １：１はKey-Value、１：ｎはRelation、ｎ：ｎはグラフ型、のように考えると一番分かりやすい。
  • 関係型でｎ：ｎを表せなくないが、Entityが増えれば増えるほど作成する関連表が増える。４つのEntityの場合10個。クエリが複雑。
  • グラフ型だとリレーションもデータ、列定義が無くjsonで保持、柔軟性が高い。（プロパティに足りないものがあっても問題ない。）検索が得意。（ネットワークとして持っているため。）
  • 路線検索、パナマ文書の解析。解析結果はWebに掲載されている。アグネスチャンの情報とか確認できたりする。（https://medium.com/@c_z/%E3%83%91%E3%83%8A%E3%83%9E%E6%96%87%E6%9B%B8-%E8%A7%A3%E6%9E%90%E3%81%AE%E6%8A%80%E8%A1%93%E7%9A%84%E5%81%B4%E9%9D%A2-d10201bbe195　の件だろう）
  • Amazon Neptune。信頼性の高いマネージド型グラフデータベースサービス。費用は気軽に使えないレベル。何十億のデータに対してｍｍ秒で結果が帰る。
  • Neo4j。DB Engines人気ランキング２２位、グラフ型で一番人気がある。OSS。
  • 体験談：ビジネスオーナが管理する対象を明確にするためのシステム図。DBの関係性、格納先の把握、改修の影響範囲明確化。CentOSをAWS上に立ててNeo4j。そしてAmazonS3のHTML＋JavaScript＋CSSの画面。静的Webサイトホスティングを使うとWeb画面ができる。Excelで管理していた関係性をグラフ型にすることで影響範囲調査が楽に。ただデータの登録、メンテがエンドユーザが担当するには敷居が高い。画面の描画はJavaScriptコーディング必須（ライブラリは出ているがライブラリによってNeo4jデータに制約があるため先にライブラリを調べておくべし）。管理ツールの導入（有料。）
  • Neo4j　Browserはデフォルトでついてくる管理コンソール。ただユーザに公開するには向かない。Neo4j Bloomが最近出た。公式ツールで、Enterprise Editionがあれば利用できる。D3jsはデータを元にSVG描画JavaScript。無料で有名。グラフ型DB専門ではない。Alchemy.jsはグラフ型データベース用可視化ライブラリ。導入するとすぐ使える。Cytoscape。クライアントアプリでNeo4jとの接続は拡張機能をインストールすると可能。Web公開はできない。これを使うのなら他の使ったほうが良い。Linkurious。ICIJがパナマ文書プロジェクトに用いた。Ogma.jsというJavaScriptライブラリも販売しているが、有料。年間500ユーロくらい？　Keylines。有償。機能が豊富。Zoomcharts。フィルタ等のUIは自作が必要だが表現力が豊か。有償。Developerライセンスは１年無料。５００ユーロくらい？。

MVCCにおけるw-w/w-r/r-wのあり方とcommit orderのあり方の再検討（株式会社ノーチラステクノロジーズ　神林飛志氏）

●所感
　データベースのロック機構、排他制御についてどのように行っているか。新たなデータベースでそのあたりの設計をどう考えているか。こういう話も知っておいたほうが良いかと思い聴講したが、早口でスライド枚数が多く、難易度も桁外れに高かった。「詳しくは論文読め」との発言が各所に。聞きつつ機械的にメモしたものの後から読んでも理解しがたい。
●メモ（スライド公開無し）
  • Logical lease。wtsは最終更新時刻、rtsはリース終了時刻。読める時間。ロックではなくうまく使っている。書き込み有効になるのはリース終了後。書いて良いが有効ではない物理時間と論理時間を分けている。Sundail concurrency control。データセットがValid。リースのextendチャレンジ。ロックとっていない。時間の整合性を見てserialized。分散トランザクションがやりやすい。Suncialではされずcommit orderをdefer。コミットタイムをずらすことでvalid空間に割り当てる。
  • ３つのPhase。Execution、Prepare、Commit。executionは単純にreadwrite。取りに行って取れなかったらアボート。Writeが重なると死ぬ。タプルでreadset、writesetでトランザクション。Readsetのwtsの最大値をセット。時間だけで管理。整合性取れれば連絡しなくてもOKで分散トランザクションに向く。今後のトランザクションでマスタしなきゃいけない一つでロック取るより断然良い。読んで、書いて、タイムスタンプ書いて、writeの最大値を保証し……。リースのrenewで更新処理、もう少し伸ばしたいといってダメならアボート。ダメだったら全部クリア。整合性を取るため。アボートのコストは高く、延長申請の仕組みはギブアップで、……（？）　Commitはupdateしてlock解除。
  • Fault Tolerant。Leaseを書かないとどうなるかというとゼロリセットする。Extendしたものが意味が無くなる。Leaseの情報は必ず書く。リセットをうまくやる仕組み。すべてのタプルをLeaseの時間セットすると負担が大きい。書かないとFTできない。
  • Data caching。リース期間は制御するからキャッシュ要らない。コヒーレントの必要はない。Leaseかかっていれば物理的に整合性取らなくて良い。Always ReleaseかAlways Request。
  • Concurrency Control。0.8で失敗のコストが高い。Hybrid方式。Abortコストの指標になる。論文読んでちょっと考えればよい話。
  • Readonly table。Lease設定が必要ない。Optimize。
  • Transaction Abort。論理的にありえない時間が発生する。
  • MaaT。別のタイムスタンプオーダリング。一番シンプルなのは0から無限大。緩い。それをどんどん小さくしてどういうプロトコルで割り当てるか。狭いとオーバヘッドは減るが失敗する確率が上がる。ロックとは違い時間を制御する。
  • Logical leaseのためのextra　storage。
  • 分散トランザクションの中では良いが、パフォーマンスは悪い。単ノードだと歯が立たない。マルチノードだと性能は悪くは無い。
  • OCC　vs　MVCC。TPC-Cは論外。YCSBは単機能検証。バッチを早くする方法についてはアカデミアは取り組んでいない。
  • Abortのコストは大きい。コストの問題がクローズアップされつつある。どう評価するか。どこからAbort、どこからretry。
  • DBにおけるコメットの位置づけ。ACIDでAtomic、Durableのoperation基準のinstall。プレコミット、グループコミット。コミットしていないデータ消えてよいわけではない。
  • 物理的に厳しいので論理的にできるように。コミットをいじることによって書き込みができなくなる。Lostupdateとは違う。
  • DB開発が２つあるが、考慮が足りていない。とりあえずMVCCのConflictはOCC/CSRに合わせる。Readwriteがconflict。読まれるものは書かなきゃいけない。順番に書くとorderができる。回っちゃまずい、が基本。Writereadの意味付け。Minimumな公準。どのVersionを読むのかまずreadを決める。CommitとVersionと組み合わせ１０通りで２つで２０通り。Write空間の使い方は集合論。位相空間。Orderの基準は位相が変わり、、、。組み合わせが決まるとやっていいことが決まる。ルールをどれだけ決められるか。詳しくはブログに書いてある。Readonlyでも不整合が起きる。Readは立っている空間を決める。そうするとwriteの制約が決まる。
  • 今まではConflict based rule。今後はProtocol based rule。Read Protocol、Write Protocolでルールが決まり、ベタで書く必要が無くなる。分散処理に向いている。無限遅延にも対応できる。定式化にもっとモデル（数学）を持ち込む。

ワンランク上のStatspack活用（株式会社アシスト　地宗幸代氏）

●所感
　Oracleのサポート、トラブルシューティングを行うにはどうしているかについて。何か活用できそうな情報はないかと思い聴講。自分はOracleに関わったことが無いのでStatspackがどれくらい活用されているのか把握していなかったが、これは知らないともったいない機能だろう。
●メモ（スライド公開予定）
  • 4000件以上のトラブル障害対応経験ありな講師。
  • パフォーマンス障害が発生し、障害発生中のパフォーマンス情報が取得できていなかった場合の問題解決率は４２％。デフォルトで出力されるアラート、ログファイルから調査を行うが、何も情報が出ていないケースが多い。Statspackを定期的に取得すると解決率が８０％へ。
  • Statspackは、DBの稼働統計をレポートするツール。稼働情報をsnapshotとして取得、累積。AWRは使用に制限があるが、StatspackはどのEditionでも無償で使える。ほぼAWRと同じものが取得できる。使用したい場合は手動インストールが必要。Spdoc.txtにインストール情報が記載されている。Snapshotなので定期的に取得する必要がある。メモリの中に重いSQL文が入っておりメモリから消えると確認できずレポートに含まれない。取り漏れ発生しないよう細かめに。３ｈほどでも長い。オススメは３０－６０min。execute statspack.snap コマンドで取得。取得したスナップショットを用いてspreport.sqlでレポート出力。
  • CPU、メモリ、使用状況がDB、ホスト全体で取得できる。他、待機イベント、ディスク読み込みの多いsql等。
  • 閾値で、「ディスク読み込みの多い」のその多さ等を設定できる。次のsnapshotから反映されるものと、変更するとレポートが変わるものとがある。表示行数とか変えておかないとデフォルト４行では下が切れることも。
  • 取得レベルを変えると、SQLレポート、セグメント情報等が追加される。
  • 領域の解放には注意。Statspack.purgeを使うと削除できる。肥大化させないように定期的に削除。
  • スナップショットは1種類のため、異なるレポートを別に取得した場合は別に立てる。

Azure上で利用するPaaSデータベース（日本マイクロソフト株式会社　西村栄次氏）

●所感
　クラウドのPaaS動向について確認したかったので聴講。SQLServerコンサルタントも、SQLServerだけではなくNoSQL、オンプレミスかクラウドか、等複合的な視点が必要。RDBっぽい案件でもあまりにも量が多くなるとRDBでは入らないんだよな、と改めて思い出す。こういう話を聞いていると、もうNoSQLが特殊なものではなく（以前システム本部時代に調査したころはまだ特殊案件扱いだったが、）普通に選択肢になる時代にいつの間にか入っているんだなと思わされる。ただ、微妙に見え隠れしている制約がどこにでもあるため、やはり事前調査はかなり必要だろう。
●メモ（スライド公開無し）
  • セッションの目的：Azure上でPaaSの特徴、考慮点、選択の際の考え方を理解してもらう。オンプレミスSQLServerコンサルからクラウドDB提案へ。
  • Relationalデータベースからオブジェクト指向、XMLデータベース、JSON、グラフ、NoSQLへ。（のーしーける、と呼んでいる）
  • クラウドになればなるほどNoSQLが注目されている。
  • CAP定理。Pが起きたときにC、Aどちらを選ぶか。CAがRDB、AP/CPがNoSQL。Base特性、結果整合性。
  • クラウドだからNoSQLが最適というわけではなく、RDBが最適な選択肢にならないわけではない。1つにする必要はない。
  • NoSQLはトランザクション処理に弱い、データ更新後の同期で遅延等弱みがある。拡張性、高パフォーマンス、可用性が比較的安く、データの柔軟性、超大量データを容易に。
  • Twitterは一日12TBで、RDBではパフォーマンスを出せない。可用性はかなり高くつく。データ型を細かく定義。データの管理が高額（データ型変更等が大変）
  • NoSQLは、拡張性にすぐれデータを分散配置しても問題ない、分散配置した各ノードで更新トランザクション大量発生、更新が多少遅れても問題ない（SNSコメント等）、スキーマ自由度が高い、システムに有用。
  • データストア選択を誤ると、データ変換による処理量増加、ストアに対するコスト負担、管理煩雑化、ブロッキングによる処理遅延。
  • 機能要件、セキュリティ、非機能要件、DevOps、管理・コストの軸で考えていく。
  • Azure SQL Database。Max4TB（シングル）。更新一か所、参照Max３つ。リコングレーションを考慮した再接続が必要。スキーマ構造の変更が容易ではない（列追加大変）
  • SQL Datawarehouse。MAX240TB。可用性99.9%。SQLDatabaseほど複雑なクエリ書けない。キー設計、パーティション間違えるとDMS大量発生。MPP処理。１データベースあたりのテーブルは１万。リコンフィグレーションによる切断。
  • Azure Database for MySQL、PostgreSQL。こちらもリコンフィグレーション。SQLDatabaseより時間がかかる。機能が限定的。
  • CosmosDB。マルチマスター可能で分散配置。ストアドプロシージャトリガーを使うことで複数データの整合性を持った更新が可能。パーティションごとに10GB制限。1TBのデータを入れようとすると10GBごとに切れてしまう。キーを間違えるとhotspotできて性能が必要になる。クライアント処理がシングルだと性能が出ない。データモデルによって選択できる言語が決まる。GOだとMongoとか。PHPはGremrinのみとか。
  • CosmosDB（TableAPI）。キーバリューストア。RDBのようなリレーションは無い、
  • CosmosDB（Cassandra）列指向。RDBに近く、集計や範囲検索が得意。RDBのようなリレーションは無い。
  • CosmosDB（Document、Mongo）ドキュメントDB。JSON形式回送構造データ。
  • CosmosDB（Gremlin）グラフデータベース。
  • AzureAnalysisService、RedisCacche、ストレージ（標準、Premium、Data Lake Storage）。
  • WebサイトでAzureデータアーキテクトガイド等公開中。

デモで見る今のSQLServer情報取得方法（フリーランス　小澤真之氏）

●所感
　本日最も期待していたセミナー。SQLServerの実行プランやパフォーマンスチェック系機能についてはまだほとんど使いこなせていないので、そのあたりをどこから手を付けたらよいのか、最新動向が確認したかった。難しかったが期待通り。SQLServerで不足しているインデックス情報を教える機能等は是非アプリ開発時点で定点的に試しておきたい。OSの情報もクエリで取れるので、SQLServerが動いているサーバの状況を知るにはこちらの方が便利そう（ただSQLServerサービス止まっていたらダメだろうが）。最新のOSが持つ情報を知るのにSQLServerから攻めるという考え方も面白かった。GitHubにクエリ公開（https://github.com/MasayukiOzawa/dbts2018-tokyo）あり。

●メモ（スライドなし、デモのみ）
  • 2014以降、実行プランのライブクエリ機能が追加されている。ライブ統計クエリを含む、を有効にしてクエリを実行すると、データの流れを追いながら確認できる。
  • DMVを使うことで、統計情報ヒストグラムが作れる。
  • ビーコンをつけて特定のクエリを識別できる。Where文に、 text like @tag。
  • キャッシュに格納されているかチェックできる（Average Elapsed Time）
  • 複数のCPUコアを使っている場合にいくつ使っているかは、total_dopとして表に出てくる。Total elapsed time,total worker time等も使える。（dop２つだと２つの値が違う。Dop対応ではないDBでも割り算でわかる。Disk性能で伸び悩んでいるとかもわかる。ロックとか。
  • OptimizerStatusUsageとかも使える。最新のSSMS使うとグラフィカルな表示ができる。SSMSはできれば常時最新化するほうが良い。
  • 2016以降、すべてのEdition（Expressでも）でクエリストアが使える。強力。実行したSQL文の実行情報をSQLServerが収集する。DBプロパティで「操作モード」を読み取り、書き込み」にする。サイズも指定できる。デフォルトは１００MBの領域を使うがリミット、クリーンナップを設定できる。いつ実行されたクエリかとかもとれる。クエリストアに関してはインターバル集計が可能、１ｈごとに取得して実行状態を確認、とかできる。互換性レベル、平均実行時間等。
  • クエリストアはGUI機能もある。効率がわるいものだけ取れたり。「後退したクエリ」等。クエリは自動的にハッシュ値がつき、ハッシュ値を使うとピンポイントで検索できる。（右側のプロパティ内に出る。）←後退したクエリ、はデフォルトではなく講師が作ったもの？
  • クエリのIDは連番で降られる。特定のクエリIDで検索し、グラフで見ることもできる。
  • 今のSQLServerはクエリでOSの状態が取れる。OSのVersion、Serviceの情報、Serviceのアカウント、クラスタで動いているか、等。リモートデスクトップでDBにログインしなくても、クエリベースで取れると便利。（セキュリティでリモデできないとき等。）コンテナかどうか、CPUがHyperThredか、ソケットの数とかも出る。
  • パフォーマンスモニタもクエリで取れる。覚えておくと便利。Sys.dm_os_performance_counters。マイクロソフトのブログ（がソースコードにある）を見ると良い。
  • グラハナ（？）でパフォーマンスのSQLを使って可視化とかできる。GitHubに公開されている。OS性能監視ツールを使っているだろうが、そちらの代用程度にはなる。
  • データベースのファイル、どれだけのIOがファイルや待ちに発生しているか、ボトルネックを確認できる。Tempdbを分割するのが一般的なチューニング方法だが、それらが均等に使われているかチェックもできる。（空きサイズによるラウンドロビンなので、効果があるかを確認できる。）
  • バッファキャッシュ。Is in bpool extension。複数のデータベースがあった場合、どのDBがキャッシュを使っているかが分かる。アーカイブのDBがメモリを食っている等。Objtype。Adhocクエリが多いならメモリインパクトを確認。何個Adhocがキャッシュされているか（Cache count）を確認。文字列連携だとAdhocでつらいのでそれを止めるとか。
  • スケジューラ。どのCPUコアが頻繁に使われるか。ヌーマノード単位で確認するとか。ハードウェアの進化に応じて取れるようなものを増やしている。
  • インデックス。日常運用メンテで実施するが、インデックスが使われているかを見える。どのインデックスが使われ、圧縮されているか、インデックスに列が含まれ、どれだけのサイズが使われているか、seekされているか。アクセスされるとlast user scanがnull以外になる。User scansがnullでなければ使われている。夜間の場合はバッチ系とか。Lockも内部で持っておりlock競合で待たされたかを見ることができる。論理的なホットスポットがあるかとか。
  • SQLServerに不足しているインデックス情報が格納される。クエリプランを表示するようにして実行すると、アプリを使って実行後、SQLServerからのアドバイスが見える。開発中のシステムがあれば、一度見て、インデックス不足を確認しておくと、本番運用時のパフォーマンス低下を防げる。（サンプルとしてロック競合。Exec sp_who2ですべてのセッションを確認できる。55番のクエリは51番で処理が進まなくなっているとか。どれがブロッカーか確認できる。
  • デッドロックレポート。拡張イベントのsystem_healthがデフォルトで動いている。覚えておくと便利。デッドロックを取るものがある。デッドロックレポートを生成し、どのクエリとどのクエリが問題あって、、、が見える。30MB程度だが後追い。システムヘルスというキーワード覚えておくと強い。
  • 待ち事象を内部的に持っている。Wait Status。Dm_os_wait_status。ホットスポットになりやすいものの全体像がつかめる。
  • 実行プランが変わっているか、昨日早かったほうのクエリを使うように強制できる、推奨情報だけをためることができる。2017の新機能で自動チューニング。Enterprise以上。

データ集計基盤のいままでとこれから（Fringe　三ツ橋和宏氏）

●所感
　そういえばHadoopだの言っていたのはどうなったんだろう？とちょっと気になったので参加。大量のバッチ処理を行う苦労話、次々にプラットフォーム乗り換える話等かなり興味深かった。クラウドインフラだとバッチ処理のやり方によって金額加算が変わってくるため、どのように課金されるのかを把握した上で再設計しないと、思ったより費用がかかってしまうとか。

●メモ（スライド公開無し）
  • データ集計基盤。大規模データをどれだけスムーズに処理できるかが腕の見せ所となる。
  • たどり着いたのは「Dataflow」。GCPサービス。バッチ処理、ストリーミング処理までデータ処理可能。パイプライン定義してフルマネージドで実行。GoogleソースコードがOSSに寄付、Apache Beamプロジェクトで開発。BeamはBatch-Stream。Cloud Dataflowあり。GCPのBigQuery、DataStore、Pub/Subと連携し、ETLツールとして使われる。GCP主要サービスと連携してシームレスに接続、フルマネージドな実行環境で負荷状況に応じて自動スケール。CPUは上手に使う。無駄が無く使わなくなったら縮退してくれる。
  • パイプラインを実行し、上から順番に流し、最終的にアウトプットを出す。
  • GitHubでコードが公開されていてカスタマイズ可能。Pub/Sub to　BigQuery等。BigQueryに出し入れが多い。データストアバックアップ用途とか。
  • Hadoop(MapReduce)を移植。サーバ台数調整手間削減、処理安定性向上、コスト削減へ。
  • 2010年ごろは単純にDBで処理。オンプレミス。MySQL。データ量増加で処理時間が多く。（データ量１０００万件。）処理が終わらなくなり、再起動、再集計を繰り返すことに。サーバを高価なものにしたがダメ。二倍の価格のサーバで1.2倍。3か月たつともうダメとか。
  • 2011年にHadoop。オンプレミスの分散処理。６台。Hadoopは処理能力が足りなければ増やせばよい。……が、クラスタ１つにつき１処理。待ち行列ができる。自分たちでExcel作って管理する羽目に。土日も手作業。
  • 2012年にAmazon EMR。必要な時にクラウドにクラスタ起動。Elastic Map Reduce。使った分だけ課金。裏でEC2。物理制約からは解放してくれた。ただMapperとReduceに分かれており使い切るのが難しく、個別パラメータの調整が必要。どんどんデータセットが増えると個別パラメータ設定が尋常ではない数になり、調整失敗するとやり直し。ノード数、Mapper/Reduce割合、メモリ容量等。
  • Amazon Redshift、Amazon Kinesis、Dataflow、BiqQuery等登場。BigQuery、RedshiftはSQL処理、他はバッチ、ストリームで処理してHadoopに近いもの。SQLで処理できるタイプが多い。（SQL実行でコード書かなくて良い。）Hadoop MapReduce処理をSQLですると、Hadoop数百行が１５行。BiqQueryは簡単に始められ、料金もリーズナブル。ストレージは0.02ドル／GB（S3より安い）、クエリは$5/TB。ペタバイト級も処理可能。ただ謎技術。ただHadoop処理と同じ処理は処理コスト数倍。ただ、MapReduce処理をSQLに移植する設計がNGだった。（5$が積み重なった。）MapReduceはデータを１行ずつ読んでReduceへと進む基本処理。SQLで再現は困難。（MapReduceのほうがより多くの処理が記述できる。）user_idでグループ化し、user_idごとに個別処理をしていた。
  • 結局、BigQueryでグループ化し、その後MapReduceをDataflowで実行、それ全体をdataflowで制御。役割分担でコスト削減。自動スケールで楽に。
  • 新しい取り組みとして、Unipos（ピアボーナス）でユーザ投稿データから埋もれてしまう有益な情報を取得）を、機械学習モジュールと相性が良いPythonで実装。Dataflowでつなぐ。

2018年データベースの選択（株式会社インサイトテクノロジー　森田俊哉氏）

●所感
　これだけデータベースがあって、「で、結局どれ選べばよいの」「どう違うの」は皆気になるところだろう。こういう比較は定点観測しておきたい。同環境の仮想マシンを準備し、チューニングは各データベースを良く知る人が公開しているものを参考にざっくり行い、公開されているパフォーマンスチェック用クエリ群を使って比較してある。こういったテーブルやSQL文群が公開されているのも面白い（HammerDB）。
　今年の比較だと、機能・パフォーマンス的にOracleとSQLServerはほぼ等価、PostgreSQLが追い付いてきており、MySQLは一段落ちる。ただしパラレルクエリの機能等、各機能を有効に使わないと想定のパフォーマンスが出ないので注意。Oracleはインデックス使わなくても早く（つまり頑張ってインデックス設計してもあまり意味が無かったり）、逆にSQLServerはインデックスがっつり使って同じくらいのパフォーマンス出すのでちゃんとやらなきゃ、という調査が興味深い。前述のインデックスチェック機能を活用しないと。……ただ、そういったことするより並列処理、高パフォーマンスマシンのほうが効果は違ってくるとか。出てあまり間が無い「SQLServer Linux版」がパフォーマンスが高いとは講演者もびっくりとのこと。【SQLServerならWindowsでしょ】という従来のやり方にこだわらなくても良いかもしれない。
　NVMeは、かなりデータ量が多いと違いが出てくるが、まだデータベースアルゴリズムが対応しておらず、ちょっとした案件レベルでの導入は時期早々のようだとのこと。
●メモ（スライド公開無し）
  • 去年も同じセッション。SQLServerはLinuxが出たので今年から追加した（Linux環境使う都合上これまでは比較対象外だったとか）。インサイトのブログに資料あり。ただし苦情がくるのでデータベース名隠している。（https://www.db-tech-showcase.com/blog_db_choice3　　だろう。今年の内容もほぼ同じ感じでSQLServerが追加になっている。）
  • 2012年に当イベントが始まったころのセミナーは、MySQL、Oracle、PostgreSQL、SQLServerの4つだったが、去年34個。今年37個。MAPD、influxdb、HateroDB……。聞いてみたいDBランキングでOracleがトップから４位になり、PostgreSQLが一位へ。
  • ストレージアーキテクチャはPostgreSQLだけ追記型。他は更新型。（MySQL、Oracle、SQLServer）。定期的にバキューム。Auto Vacuum実装であまり意識しなくなった。データ型の定義もちょこちょこ違う。パーティション、パラレル機能は、Enterprise Editionでしか使えないものが多い。最近SQLServerではEEでなくても使えるようになった。SUBPARTITIONINGはSQLServerは使えない。（中の人は必要ないとのこと）。MySQLはParallel Query使えない。
  • レコード件数、データ種類、データ上限下限、ヒストグラム……。
  • インデックスは、MySQLはインデックスは１つしか使わない。仕様として。
  • 機能的にPostgreSQLは追いついてきた（Oracle、SQLServerに。）MySQLは少し少なめ。
  • TPCC、TPCH。ベンチマーク。単純な処理だとあまり差が出ない。TPC（Transaction Processing Performance Council）。HammerDB（OSSデータベース負荷テスト）。SQLServer対応している。データの生成もしてくれる。ベンチマークプログラムとしては便利。TPC-Hは２２個のSQL文順番に投げる。ScaleFactor＝１だと６００万、１０だとその１０倍。サブクエリ、相関サブクエリ等が準備されている。負荷高めの難しいSQL文。
  • VMware立ててメモリ16GB、SSD100GB。パラメータチューニングはPgTune、MySQLTuner。統計情報埋め込み、３回実行して平均処理時間を出す。
  • Oracle、SQLServerは互角。PostgreSQLは１．５倍くらい。MySQLは２倍くらい。ただ不得意なSQL文がはっきりしている。PostgreSQLも。一番早いクエリはSQLServerが数が一番多かった。Oracleは他と比べてインデックス使っていない。（２２中４つ。）SQLServerはがっつり全部使っている。OracleはほぼHash join。SQLServerもHash match、Nested loop join。Oracleだと６００万件くらいだとほとんどインデックスつけなくて良いのでは。Parallel Queryはどれも良く使っている。PostgreSQLは以前はParallelあまり使われていなかったが最近使われるようになった。昔はインデックス使って、、、だったが最近はHashとParallelで対応している。MySQLが遅いのはParallelQuery無いからか。
  • IndexScan→Group byはhash　match、orderbyはParallel、ResultSet。（実行計画を見ると分かる。）細かく処理を分けて扱うデータセットを小さくするほど高速に処理できる。
  • Parallel QueryをOFFにすると、SQLServerはかなりパフォーマンス落ちる。MySQLより遅くなる程度。Oracleで１．５倍ほど。つまりONにしておかないとダメだろう。
  • 最近はクラウド等流行りだし、DBパラメータ書き換えたり実行計画を調べたり、ではなく、スケールアウトして並列処理して高速なデバイス使えばよい、という話。
  • 2007年から比べ、CPUは10倍、メモリは２倍、ストレージは1.2倍程度早くなっている。SSDにすると100倍とか。OracleでもStandard EditionでフルSSDにすると速度1/4になり、Enterprise Edition必要なくなる。NVMeにするとさらにSSDより２－３倍速くなる。
  • VMwareでもNVMeを使えるが、Oracle、SQLServerだとあまり差が無い。他の２つはちょっと差が出ている。（全者はそもそも早くて差が出にくい。）特性として、キューが関係するので、プログラム側がそれを考慮していないとダメ。ただいくつもサーバがあっても劣化しないとか。シーケンシャルのコピーは早いがSQL文はあまり変わらなかったり。クラウドでは効果がある。データを１０倍に増やせば、SSDよりずいぶんと差が出る。
  • MySQLは使いどころを考えるべし。実行計画、ハッシュ、Parallelが無い。ただしOracleと比較して２倍ほどになるわけではない。PostgreSQLは10.1で頭が良くなり、実行計画が良くなった。20%程度早く。
  • Oracleからライセンス価格都合で移行する場合、SQLServerは手堅いが、PostgreSQLもかなり迫っておりアリ。MySQLは使いどころを選べばOK。分析系何千万件には対応困難。クエリをきれいに書けばOKでは。
  • NVMeは大規模処理には効果があるが、まだデータベース的に対応していない。今後に期待。
  • OracleとSQLServer（Linux版）でほぼ同じ速度なのは講演者もびっくり。

0 件のコメント:
ラベル: , , ,
登録: 投稿 (Atom)