Google Cloud Kubernetes Day（2019/3/26）感想等

　Kubernetes（くーばーねーてす、と会場案内では発音。セッション担当者によってはくーばねてすとか）という言葉を最近よく聞くようになったが、なかなか周囲のインフラ状況と、コンテナ系プラットフォームの導入、利用とが結びつく気配がない。実際最近どうなっているのか、トレンドとしてどういう方向に向かっているのか、どのように移行するのか（富士フィルムのセミナー一番気になった）等確認したく参加。無料。https://cloudplatformonline.com/2019-google-cloud-kubernetes-day-0326.html。

セッションはどれも内容が濃く、実体験に基づく構成、GCPのβ機能の紹介も多い。スライドも話も早く、分からない単語のオンパレードなのに、どのスピーカーも話がうまく、各セッションどれもあっという間だった。午後一杯でとにかく用語概要とGCP万歳を詰め込まれた感。メモは単語をメモるだけで精一杯の部分多し。

全体として、「運用を容易にする」、「デプロイ、リリースを容易にする」といったツールは、これまではオンプレミスを前提にOSSで提供されるものを手元にインストールして設定して自分で連携させて使う、が主流だっただろうが、今後、プラットフォームはクラウドを前提とし、Cloud Nativeなツールがどんどん提供され、各クラウドベンダーがツール類を競いつつ、利用者は金さえ払えばあるいは無料サービスとして容易に使えるようになり、使うのが当たり前になる、という時代にとっくに突入している感がありありと感じられた。以前参加したAWS Essentialsの際も同様な感想を持ち、その際は「へーAWS便利だなー」位だったが、さらに標準化が進み、Kubernetesがデファクトスタンダードになり、どのクラウド使おうがコンテナは当たり前（CloudからCloud Native）で、Kubernetesを必要とするようなインフラは、もう自前で持つよりAWSかGCPのほうが圧倒的に便利で、AmazonやGoogleがどんどん便利なツールを自プラットフォームに入れてサービス競争するから、オンプレインフラ運用を楽に扱える技術が公開されることは今後少なくなるのだろう感が見えているのは、オンプレシステム屋やっている身としては少々不安がある。

（……まぁ、小規模オンプレシステムならそもそもDockerすら必要ないレベルだが。どこかのタイミングでオンプレシステム屋は卒業してクラウドシステム屋にならないと完全に置いてきぼりになるのか、それとも別の道がひっそり提示されているのかはまた別途確認として。）

ベルサーユ渋谷ファーストの広いイベントホールがほぼ満席。席数ベースで参加者１０００名近く（＝３＊約１５＊約２０？）か。　スポンサー企業のブースが６つあったが、あまりブースを推している気配なし。（何をやっているのかブースの外から見て分からないレベルの展示。資料をもらったところだとコンサルとか試験サポートとか。）会場はちゃんと机があったため多少狭かったがノートPCでメモを取っている人多し（スライド公開されないからというのもあるだろう）。キーボード音がうるさいほど。1000人居ると休憩時間のお手洗いは長蛇の列（だから休憩時間が妙に長かったのか……）。水、コーヒーコーナーあり。パンのようなもの配っていたようだが一瞬で無くなっていた様子。終了後に無料懇親会がロビーで開催されていたが、ロビーが人で溢れ、とても懇親できる感じではなかったので、飲まずに退散。

セミナーのTwitterハッシュタグは、「#gc_k8sday」

以下、セミナー中、セミナー休憩時間に書いたメモ等。

 

 

Kubernetes／Containerによる開発の導入難易度とメリット（サイバーエージェント青山真也氏）（@amsy810）

概要

Kubernetesべたぼめ。ただし、オンプレよりGKE（https://cloud.google.com/kubernetes-engine/?hl=ja）とセットで考えないといろいろ辛そうな感じはある。Cloudは普及し始めたがCloud Native（https://www.publickey1.jp/blog/18/ibm_cloudnative_pr.html）の考えを入れるべし。アプリの組み方、セキュリティ面は考慮必要。学習は楽ではないが、利便性に比べて学習コストは低い。（＝学習超大変だがメリットかなり大きい。）

著者Twitter：https://twitter.com/amsy810

メモ

• Kubernetes完全ガイドの著者（https://www.amazon.co.jp/dp/B07HFS7TDT/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1）。
• 2016年頃から採用。オンプレミスで独自のKubernetes　as　a　Service基盤。新規事業多くがKubernetes/Container利用。44%がGKE、GCP。オンプレミス44%。AbemaTVは3年前からGKE。チャレンジングなワークロードにもGKE。Adtech studioでは新規案件90%がGKE。GKEクラスタ運用自動化機能をフル活用。レイテンシ要件にシビアなアドテク領域OK。
• GoogleクラスタマネージャBorg（ぼーぐ）（https://www.slideshare.net/ktateish/google-borg）を元にしたOSSで、長年のGoogleの経験がKubernetesに引き継がれている。今はCloud Native　Computing Foundationsが中立的にホスト、コミュニティによる改良。
• 歴史：Baremetal Era。Bootstrapping、Configuration、Orchestration。Kickstart、Shell Script、Jenkinsあたりが自動化の始まりだが各社秘伝のコードになりがち。クラウドでは、Terraform、Chef、Ansible、Puppet、Salt、Fabric、Capistrano。構造化、共通化された自動化。だが再現性が高くなく時間がかかる。そこからTerraform、Docker、Kubernetes。クラウド非依存の共通化された仕組み。
• CloudではなくCloud Nativeへ。参考になるのが「Cloud Native Trail Map（https://labs.mobingi.com/cloud-native-landscape-trail-map/）」。どういったことをすべきかが載っている。コンテナ、オーケストレーションツール。CI/CD。
• まずDocker。アプリケーションと実行環境のイメージ化。
• Load Balancer、Storageも抽象化。Load Balancer作るManifest、転送先のポートとコンテナ指定だけ。
• 利用者から見るとクラウド固有の知識が不要に。
• 宣言的なAPIとCode。YAML、Manifest。Infrastructure as a Code。
• Control LoopとReconciliation。登録された瞬間３つコンテナが普通。KubernetesでControl Loopがずっと回っているサイクル。現在のコンテナ数、状況と理想状態の比較、差分に対して処理。障害時に自動的にコンテナを他のノードで起動。（セルフヒーリング。）こういうのがいろいろと準備されており運用が楽。
• アプリアップデートの際にLoad Balancerから外してUPしてまた入れて、があるが、こういうところも自動化。Manifest変更のみ。どのイメージを使うかのVersionを書き換え。差分検知してUpdate。
• Serverless on Kubernetes。サーバレス環境。Service Mesh。周辺ツールもGoogleが提供していたりする。Managed Service。
• Kubebuilder／Operator SDKで、Kubernetes自体を拡張して自動化できる。Jenkins等をKubernetesに任せられる。拡張はそれほど難しくない。ループのフレームワーク。
• ただ導入には覚悟が必要。アプリケーションの作り方を変える。モノリスティックではなくマイクロサービスに適している。コンテナの場合非常に頻繁に停止するのでそういう設計を。SIGTERMハンドリング。ネットワークもIPアドレスを意識しない設計を。アプリToアプリ通信でService Discovery経由通信。SourceIP消失。一部知識必要。セキュリティ回りも難しい。runCはKernel共有で影響受けやすい。gVisor等分離性高いContainer Runtime。コンテナ間通信が筒抜けなのでNetwork Policy有効に。
• 学習コストは小さくはない。Cyberagentでのアンケートでは、つらい５０％、導入してよかった１００％。
• 一番つらいのはKubernetesクラスタ管理。GKE使うと解放される。オンプレはしんどい。GKEオンプレもあり。オンプレでGKE使うと楽になるだろう今後は。
• Managed Kubernetesではマネージドの範囲重要。
• Cloud Nativeで組織力強化、開発力向上できる。セキュリティだけには注意のこと。最高なツール。
• 本はGKEベースで書いている。

コンテナ開発プラットフォームにGKEを選択すべき７つの理由（GoogleCloudJapan岩成祐樹氏、田中ｘｘ氏）

概要

　冒頭で、７つと言いつつ５つにしますとの話あり。クラウドを使う理由の44%がセキュリティという話にはびっくり。もう「クラウドはセキュリティが……」と言う時代ではなくなった。ただ、あちこちのセッションで、「セキュリティ注意」発言がある。適切な設定をすれば強固だが、ど素人がマイクロサービスなんてやると穴だらけになりかねないのだろう。（http://www.mpon.me/entry/2017/04/22/020428　によるとすべて外部にネットワーク出ている？？？？）

Stackdriver（https://cloud.google.com/monitoring/?hl=ja）の話は別セッションでも出てきたが、Logging、Monitoring、MicroService連携確認等、Cloud使うなら必須だろう。

メモ

• Security
  • Kubenetesを採用する多くの理由はAgilityだが、Enterpriseで使うならSecurity。Google CloudのSecurityは評価されている。クラウドの長所へ。一昔前と違い、今はSecurityがクラウドを選ぶ理由になっている。徹底的な防御がデフォルトでONになっている。通信、Identity、Hardware Infrastructure、運用とデバイスセキュリティ、ストレージ、サービス面。
  • コンテナのセキュリティは３つのレイヤー。インフラがコンテナ開発に安全か。作成したコンテナがビルド、デプロイして問題ないか、作成したコンテナを実行して問題ないか。
    • Use RBAC and IAM。適切な権限管理。プロジェクトレベルではIAM。NamespaceではRBAC。必要以上にノードをさらさない。信頼された領域のみのアクセスに絞る。Kubernetes Masterも承認されたネットワークからのみ受け付ける。Cloud Armor。Load Balancerレベルでセキュリティ。Backend Config BETA。
    • 作ったアプリやライブラリがセキュアか、セキュアで持って行けるか。CI/CDパイプラインは信頼できないデプロイを止めてはくれない。Software supply chainで制御。意図したところでビルドされているか、テストされているかをメタデータとして持つ。Container Registry脆弱性スキャン。Binary Authorizationは門番代わり。意図したプロセスに乗っ取ったもののみ本番に行けるように。
    • Runtime Security。Container Optimized OS。ChromiumOSベース。セキュアで軽量なOS。アップデートが自動。Runc脆弱性事件でも当OSではアクション必要なし。Runtime security partners in Cloud SCC BETA。ベンダのセキュリティツールを一元化。
• Network
  • GKEは裏で様々なGCPServiceと統合。裏で何がデプロイされるかがユーザエクスペリエンスに影響。Google Cloud Load Balancing。デフォルトで提供されている。グローバルインフラ。Container Native Load Balancing Betaを使うと直接ネイティブにバランシングでレイテンシ改善。
• Hybrid Cloud
  • コードをどこでも実行できる環境を。適材適所を柔軟に。GKE On-Prem BETA。利用には制約あり。GKEとオンプレのクラスタをGoogleCloudで一元管理できる。Stackdriver可観測性をオンプレにも。結果としてオンプレとクラウドでリソースを自由に。同じツールを使ってクラスタの集中管理。環境の差異を最小化。
  • Mercari事例。On-PremからHybrid Cloudへ移行。MonolithをMicroServiceに徐々に。完了したものからGKEへ。API gatewayでルーティング、トラフィック割り当て。On-Premで動かすのが適したものは残しておく。今後Istio Service Mesh。On-PremもGKEへ。
• Observability（可観測性）
  • ロギングとモニタリング。Stackdriver。LoggingとMonitoring機能。Stackdriver Kubernetes Monitoring BETA。Kubernetesワークロード最適化Stackdriverツール。Monitoring、Loggingを１つの管理画面で。CPU使用量、コンテナ状況等。クリックするとLogging画面。一つのUIで。従来のStackdriverからの移行も可。
  • Works With OpenSource。Prometheus。Cloud Native Monitoring Tool。Custom Metrics。PrometheusとStackdriverとのシームレスインテグレーション。GitHub上でコード公開されたOSS。
• Contribution
  • Open Source is free like a puppy。OSSはメンテし続けないとダメ。OSSの活動はUPでは終わらずCommunity活動。Issues、マージ。
  • GKEは、To be Reliable、Scalable、Openへ向かっていく。
    • Regional clusters。マスターを、ゾーンを跨って分散。
    • Regional Persistent Disks。ブロックレベルレプリケーション。
    • Node Auto-Provisioning Beta。Podの水平、垂直スケーリング、Node水平スケーリングに加えて垂直も。4番目のオートスケーリング。
    • Skaffold、Kanico、Knative。Google ContainerTools。GitHubにあり。
      
      
      
      

GKEを用いたレガシーシステムからのリプレイス事例（富士フィルム小林だいすけ氏）

概要

富士フィルムのコンシューマ向けレガシーサービス（１０年運用）をGKEを用いてリニューアルしたときの話。この数年でGCP、コンテナがいかにデファクトスタンダードになったかあたりの歴史話、それがどう自分たちに影響したか、という話もかなり興味深かった。最新技術を選定する場合に「OKかどうか」の判断基準として参考になりそう。

2018/1頃にKubernetesがデファクトスタンダードになり、Kubernetesの開発元であるGoogleのGCPも国内正式サービス開始したので、一気に開発・移行した。ただ、Googleエンジニアが優秀で多分いなければ回らなかったのだろうとスライドの端々で語られているし、社内の協力体制構築、抵抗勢力への説得回数は「∞」、勉強、熱意等、単純に「では移行しちゃおか」では済まない感も満載。１つのプロジェクトで、誰も経験が無く、自分だけでGCP、社外に頼らない、というのはまず失敗するだろう感。（スピーカ自身もこれまで何度も失敗していることを端々でにおわせている。）

メモ

• 富士フィルムでプリントビジネス関連開発担当。FUJIFILM Prints & Gifts（https://pg-ja.fujifilm.com/photo-print）。注文管理システム（OMS）。
• 運用１０年で保守コスト大、機能開発スピード低下。モノ消費からコト消費へユーザの消費動向変化。2018/1～PJ開始。
• Cloud Storage、Stackdriver、SQL、、、、、
• 富士フィルムの分化として、STPDCA。SeeとThinkを重要視。現状分析し、やりたいことが間違っていないかの検証重要。
• レガシーシステムはモノリシックなアプリ（大きい）。負荷状況にリアルタイム追従は困難だった。季節イベント、キャンペーンで負荷増大。年賀状等。負荷量変動への対応を最優先に。2016年ごろからコンテナ調査。Docker、Kubernetes等使ったが運用大変。安定運用難しくハードル高かった。今は期が熟した。（2018/1）　ただコンテナ利用実績なし。急に使って大丈夫か、という声があったがチャレンジングだからやらせてほしいと。「何が標準？」「自分たちで運用できる？」が問題。オーケストレーションツールは使いたい。早目に飛びつくと後悔した例もあり。本番で安定運用、自分たちで理解できる担保ほしい。機能先行ではNG。
• 2014/5、Googleは既にすべてのSoftwareをContainerに載せ、週２０億個コンテナ起動と発表。2014/6にDocker1.0、KubernetesをOSS。2015/6にコンテナ標準団体発足。2015/7にCNCF。Docker SwarmとKubernetes主権争い。2017/7でOCI1.0.標準化。2017/10にdockerがKubernetes統合とサポート発表し、Kubernetesが事実上の標準へ。MicrosoftとAmazonもKubernetesサポート。結果、Kubernetesがコンテナオーケストレーションデファクトスタンダードになり、規格争いによる技術陳腐化懸念後退。主要クラウドベンダがManaged Service開始により安定化。
• 2018/1時点で日本国内でのGAはGoogleのみ。他はβ。正式サービス運用は大きな判断基準。SLAがあるかないか。Kubernetes開発元、４年以上の安定動作運用実績も魅力。Managed Serviceはユーザが対応できない領域も増えるため、安定動作実績はほしい。GKE選定決定。
• 周りの理解。技術的優位性。リスクを背負えるか。総論賛成だが各論が。納期。近道はなし。技術学習と解説資料と説明行脚を繰り返す。延々と。現場レベルでは味方多し。今のがいいとはだれも思っていない。薄々皆気が付いていた部分での連帯感。リスクは解がなかったがBackup Plan準備。技術習得説明。Google Engineerのバックアップ。（実際の運用、サポート者からの話。）
• 技術はゼロから。独学＋ハンズオン＋GoogleEngineerSupportでTry&Error。GKE使いやすさの効果。
• 効率的システム間連携知識が必要。Pub/sub。レガシーシステムルール把握が難しくシステム引きずりが見えづらい。当初プログラム制御でイベント発火。そこから、ファイル配置でCloudFunctionsで配置イベント検知からPub/Sub投げ込みへ。（CloudStorageに置くとイベントがとれる）
• Logging、Alertは最終的にうまくできたがMetrics書き方が迷った。CGPDocumentが手薄。GoogleEngineerにSupport。Yaml書き方の勘所慣れが大変。レガシーシステムの設計思想が合っていない。設計上のキーになる部分の調査が必要だった。
• サービス分離が困難。Max分割したが制御不能。リカバリパターン複雑に。グループ化して分離。MicroService思想は入れたがとにかく小さくするのはダメだった。
• ManagedServiceでカバーできる範囲の見極めが必要。不足する部分は自前。監視面は社内別PJと近いものを。PaaSについてGoogleEngineerSupport受けつつ選定して確認。Prometheus＋自前でリッチな監視を。
• レガシーシステムとの連携は困難。大部分移したが移せないものあり。新しく作ったシステム側で対応。IP制限、連携プロトコルを古いものを使った。一番最初には「すっきり」（全部新しく）を描いていたが困難。乗り換えたい。
• 結果、スケーラビリティ確保はできた。ただ今後の悪化注意。現状、注文が瞬間的に数倍に増加しても処理速度劣化なし。他国展開、横展開しやすい構造へ。保守運用コストも改善。保守コストは1/2．サーバリソース有効活用でランニングコスト3/5へ。導入８か月でサービスダウンタイムなし。安定動作。ログ調査やアラート連携一元管理で改善。今後の分析基盤ベースに。機能改善スピードも向上。約２倍。イベント開催にも柔軟に対応可能な構造へ。
• GKE学習コストは得られるリターンに比べたら小さい。（学習コストは大きいがリターンが大きい。）従来比でインフラ懸念を取り除けた。組み合わせの話や深いところの理解はまだ勉強必要。クラウドベンダのエンジニアの協力が偉大。導入には熱意必要。一人では負けるので仲間を。

コンテナによる開発と運用の進化（GoogleCloudJapan村上大河氏、篠原一徳氏）

概要

MicroServiceは最近はやっているというので本を何冊か読んだが、これまで手掛けたサービスはサービスをそこまで切ってサーバに別々に立てるほど大きくないので「へー」で終わっていたが、大きなシステムだとログインだの検索だのそれだけでも抜き出してサービス化となる。Microserviceどうしの通信のAPIをどう管理するか、バージョニングするかのノウハウがGoogleから公開あり。Istio等を使うとどこから呼ばれているか等も管理できる。

メモ

• 技術サポートの人。MicroServiceの話をする。聴衆でMicroServiceでシステム組んでいる人と言われ手を挙げたのは少なめ。
• いいものを早く届けるために、リリースする規模を少なくするのがPractice。MicroServiceArchitectureの採用。ポイントは人、プロセス、Technologyの３つ。（イテレーションを早くするには。）企業ごとのやり方に最適化を。WaterfallからScrumへの変化への反応。BusinessProcessをどう技術に合わせて変えるか。Change Management。Technologyに対する変化の管理。Googleや提携パートナーからそういう変化のサポートを行うサポートあり。こういうイベントでも発表あり。
• MicroServiceは機能ごとに独立したアプリ、サービスに分割。サービスは単一の目的。サービス間は租結合。軽量なAPIでやりとり。
• Asls to　ToBe。Monolith to Microservice。新規サービスからやる。既存サービスを部分的に置き換える。理想的には開発とビジネスとを１：１の組み合わせをたくさん。ただ複雑にはなるので、今までのアーキテクチャ向けでは監視、管理、保護は困難。イテレーション速度を上げるにはネックになる。
• 4challenges　of　Microservices。１）プロセス内コミュニケーションからプロセス外コミュニケーションへ。RPC＋APIゲートウェイ。２）分散システム導入による複雑化システムの効率管理。サービスメッシュ。３）マイクロサービス協会が引き起こすデータサイロの解決。データレイク。４）アプリケーション以外のコーディングを少なく。自動化（CI/CD）。本質的な部分に集中を。
  • １）REST API、gRPC。サービスを分けることで独立して管理できる一方、利用しているサービスを勝手に変えられる危険性。API仕様を変えるとService全体に影響。ルールを作って防ぎつつイテレーション速度を落とさない。宣言的に管理。APIのVersion管理。REST APIあるいはOpenAPIで使用定義。gRPCやProtocol Buffersでの仕様公開。定義ファイルを利用することで、利用したいAPIのスタブを自動利用、Validation。日々相手のAPIをチェックしつつ開発。Version管理は、GoogleCloudPlatformでバージョン管理ガイドあり。Google内部のAPIバージョニング手法。セマンティックバージョニング。Cloud Endpoint.APIにメジャーバージョン、マイナーバージョン。マイナーバージョンには後方互換性あり。メジャーは下位互換性なし。メジャーバージョンは利用先と互換性担保、連携。自分たちの世界でAPI進化可能。API設計ガイドもGoogleで公開あり。Google内部でのAPI設計スタンダード。一定のルールでMicroServiceを作る。
  • Cloud Endpoints。APIを提供。公開APIに対するアクセスコントロール。API Keys、Stackdriver loggingでAPIコールのログをKeyに紐づけ。VisualizeはBigQuery＋dataポータル。内部向けと外部向けの変更。
  • Stackdriver traceを使い、よりService間呼び出しを効率化。メトリクスはPrometheusで一元化。MicroService、GCPともStackdriver Monitoringで。通信制御はIstio（いすてぃお。https://qiita.com/Ladicle/items/979d59ef0303425752c8）。
  • ２）サービスメッシュ。MicroServiceではシステム複雑化で管理大変。簡略化のための機能提供。アプリに手を入れずサイドカープロキシ。IstioはGoogleとIBM中心開発のサービスメッシュ。トラフィックコントロール、サービスレベルセキュリティ、可観測性を提供。
    • これまでトラフィックはインフラと結びついていた。段階的にローリングUpdate。LoadBalancerから切り離し、、とかをIstioを使うと制御委託。トラフィックスプリッティング。新しいものに10%流して安全にアプリリリース。
    • Istio使うとMicroService間の認証、暗号化、通信許可ポリシー制御。Role Based Access Control。
    • Istioの監視（Service連携監視）機能が入っている。Prometheus、Jaeger。簡易に管理。
    • Istioはもうボタン押せば使える。今後も機能あり。
  • ３）データレイク。MicroService内データストアをどうするか。データがサイロになりかねない。Cloud PubSub。キューイングサービス。分析に必要なデータを送り込み、集める。
• Istioデモ。Python、Java、Ruby、node。GKEクラスタ。Book Info。Cloud Service management。Istio GKE。GoogleがマネージするIstio。β版。オブザーバビリティ向上。SLO管理。Latency　Threshold。80%は30msec以内のレスポンスを維持しているかを月で見たり。Istioのミキサーでサードパーティと連携。アラートの設定をStackdriver経由で。トポロジーグラフ（MicroServiceどうしの連携）は今年前半くらいにサポート予定。現在付け焼刃程度のはある。
• Cloud Service Management Alpha募集中。https://servicemesh.page.link/alpha-service　（←リンクメモったが間違い）
• GCPエキスパートに相談を。全面的にサポートする。

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）あり。

• 著者ブログ：https://blog.engineer-memo.com/
• 著者GitHub（クエリ、ユーティリティ等公開）：https://github.com/MasayukiOzawa

●メモ（スライドなし、デモのみ）

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

• 著者ブログ：https://www.fringeneer-blog.com/

●メモ（スライド公開無し）

• データ集計基盤。大規模データをどれだけスムーズに処理できるかが腕の見せ所となる。
• たどり着いたのは「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版）でほぼ同じ速度なのは講演者もびっくり。