Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ゲーム業界で採用されているMySQL互換フルマネージドサービスのNewSQLデータベース「TiDB Cloud」

ゲーム業界で採用されているMySQL互換フルマネージドサービスのNewSQLデータベース「TiDB Cloud」

MySQLインターフェースのクラウドネイティブなNewSQLデータベース「TiDB(タイ・デー・ビー)」は、今まで苦労してきたデータベース運用を画期的に楽にすることが可能です。それは、機会損失を減らし、今まで出来なかったゲーム企画などにもチャレンジできる製品でもあります。特にクラウドサービスをご利用中の方は、本スライドにてより良さを感じて頂ければと思います。 また、実績としては、日本国内外ですでに多数のゲーム会社様で採用されており、多くのお客様が、フルマネージド型のTiDB Cloudを利用して頂いております。ぜひ、スライドにて今注目のTiDBについてご覧ください。

参考ビデオ:
https://youtu.be/9rp-QzXtlaw

PingCAP-Japan

October 11, 2022
Tweet

More Decks by PingCAP-Japan

Other Decks in Technology

Transcript

  1. ゲーム業界で採用されているMySQL互換フルマネージドサービスのNewSQL
    データベース「TiDB Cloud」

    View full-size slide

  2. こんな方におすすめ

    ・ NewSQLのフルマネージドサービスを探している

    ・ データベースのアプリでの水平分割をやめたい

    ・ 止まらないサービスを運用したい

    ・ 気軽に集計できる画面を作りたい


    View full-size slide

  3. 自己紹介

    PingCAP株式会社

    シニアソリューションアーキテクト水戸
    部 章生(mitobe akio)  

    バックグラウンド

    ● PingCAPの日本法人立ち上げの初期メンバー

    ● 国内ゲーム会社のリードプログラマー

    ● 外資系電子機器ベンダーのサーバ、ストレージ部
    署のプロダクトマネージャー


    View full-size slide

  4. 2015
 2016
 2018
 2019
 2020

    2017
 2022

    2021

    2015-9

    • TiDB available on GitHub

      1ヵ月で2,700+ stars獲得

    2015-4

    • PingCAP 設立

      ※3名のDBAによってスタート

    2016-4

    • TiKV available on GitHub 

      ※ Google Spannerから着想を得た

    2016-8

    • シリーズAの資金調達

    2017-10

    • シリーズBの資金調達(約2.5億円)

    • TiDB 1.0 GA リリース

    2017-12
    • シリコンバレー(US)オフィス開設

    2018-4

    • TiDB 2.0 GA リリース

    2018-8

    • CNCF to Host TiKV in Sandbox

    2018-9

    • InfoWorld 2018 Bossie Award受賞

    • シリーズCの資金調達(約50億円)

    2019-5

    • CNCF to host TiKV in incubato
    r

    2019-6

    • TiDB passed Jepsen test

    2019-7

    • TiDB 3.0 GAリリース

    2019-12

    • Chaos Mesh available on GitHub


    2020-6

    • TiDB 4.0 GAリリース

    2020-7

    • TiDB Cloud betaサービスの開始

    • CNCF to host Chaos Mesh in Sandbox

    2020-8

    • “TiDB, a Raft-based HTAP Database”
    published in VLDB

    2020-11

    ・シリーズDの資金調達(約280億円)

    2021-4

    • 日本法人 設立

    東京オフィス開設



    • TiDB 5.0 GAリリース


    2022-2

    • TiDB Cloud 

    AWS Marketplaceに対応





    2022-4

    • TiDB Cloud 

    GCP Marketplaceに対応





    2022-4

    • TiDB Cloud 6.0 GA 



    PingCAP:創業〜現在まで
    2015年から開発が始まり

    2000社以上導入されているデータベース


    View full-size slide

  5. 2021/4/1

    Online event: 

    Cloud Native Database Meetup #1 

    Sakura Internet様 

    CyberAgent様 

    DMM様

    ・日本法人体制強化 *現在23名+1名 大規模案件常駐 

    営業/SE/テクニカルサポート(保守/技術問い合わせ)/TiDB Cloud R&D(1名) 

    Press Release: 

    さくらのクラウドEnhanced DB
    Offline event: 

    FIT2021

    Online event: 

    Cloud Native Days Tokyo 2021 

    Online event: 

    DB TECH SHOW CASE 

    2022/現在

    PingCAP Japanのご紹介

    Press Release: 

    U-NEXT様TiDB選定の理由
    Online event: 

    Developers Summit 

    Press Release: 

    AWS marketplace対応
    Press Release: 

    平野拓也 氏

    エグゼクティブアドバイザー就任
    本社R&Dが常駐し積極的な日本展開

    日本国内でサポート完了できる体制を提供


    View full-size slide

  6. MySQLコアチーム コアメンバー/InnoDB R&Dヘッド

    SunnyBainsがSoftware Architectとして4月よりPingCAPに入社

    今後のTiDB/TiDB Cloudの更なる品質向上と機能実装の加速にむけて本社開発チームの更なる強化

    本社開発チームの強化
    超強力なメンバーの参加が確定


    View full-size slide

  7. 目次

    1. ゲーム開発現場の課題

    2. PingCAP(TiDB Cloud)のアプローチ

    3. どのようなシナリオで活躍するのか

    4. ゲーム業界事例


    View full-size slide

  8. ゲーム開発現場の課題

    ゲーム開発現場の大きな悩み

    ・ 想定以上のユーザが来た

    ・ DBが減らせない

    ・ どのクエリーが問題なのか分からない

    ・ プライマリーDBがダウンで障害

    ・ 急なコラボイベントで緊急対応
    夜眠たい・・・

    インフラ・アプリ

    プロデューサー

    ・ 想定以上のユーザが来たら機会損失に・・・

    ・ インフラコストを抑えられないのか

    ・ ノーメンテナンスで稼働できないのか

    ゲーム開発に専念させたい

    もっと収益体質にしたい


    View full-size slide

  9. 負荷が上がった際に

    アプリサーバ側はステートレスで簡単に増やせたが

    問題はデータベースサーバ

    簡単には増やせず

    水平・垂直分割に悪戦苦闘の日々

    Jmeterで負荷テストを実施して同時接続2000をクリア問題なしと思っていたら・・・

    ユーザが想定以上にきて、DBが応答を返さなくなりました・・・

    結果、サービス停止し、機会損失へ。

    リリース後・・・

    自分自身の実体験から少し

    ゲーム開発現場の課題


    View full-size slide

  10. 結果:負荷をさばく為、大量のシャーディングが生まれた

    Primary Secondry
    P S
    S
    S
    DAUが増加し・・・

    P S
    S
    S
    P S
    S
    S
    P S
    S
    S
    P S
    S
    S
    P S
    S
    S
    P S
    S
    S
    P S
    S
    S
    P S
    S
    S
    P S
    S
    S
    ゲーム開発現場の課題


    View full-size slide

  11. DBだけでは完結できない為、アプリ側に工数も発生

    ゲーム開発現場の課題

    アプリ側で実施した内容

    ・ 水平、垂直分割のクラス作成

    ・ テーブルをまたぐjoinの改修

    DB側で実施した内容

    ・ DBをユーザ単位で水平分割

    ・ DBをアイテム単位で垂直分割

    大量のシャーディングをしたことにより負荷対策は出来た。


    ただ、別の問題が発生した

    ① DBが分れることによりトランザクションでデータロストが起きる構成に

    ② 負荷や容量増減によるサイジングがしにくい構成に

    ③ 分析がワンクエリで出来なくなる


    View full-size slide

  12. ゲーム開発現場の課題

    シャーディングをした場合、

    ・ 障害ポイントの増加、運用コスト、ランニング費用の増加

    ・ 負荷対策においては、事前に設計が必須

    ・ 想定以上のユーザが来た


    ・ DBが減らせない


    ・ どのクエリーが問題なのか分からない


    ・ プライマリーDBがダウンで障害


    ・ 急なコラボイベントで緊急対応


    ・ DBが落ちるとトランザクションレベルでデータがロスト

    インフラ・アプリ

    プロデューサー

    ・ 想定以上のユーザが来たら機会損失に・・・


    ・ インフラコストを抑えられないのか


    ・ ノーメンテナンスで稼働できないのか

    ×
    ×

    シャーディングでは、悩みが解決できない・・・ 

    負荷対策は出来たが、むしろ、悩みが増えた 

    ×
    ×
    ×
    ×

    View full-size slide

  13. 目次

    1. ゲーム現場の課題

    2. PingCAP(TiDB Cloud)のアプローチ

    3. どのようなシナリオで活躍するのか

    4. ゲーム業界事例


    View full-size slide

  14. そもそもなにが課題でシャーディングが必要なのか

    書き込み性能の向上

    の追及

    PingCAP(TiDB Cloud)のアプローチ

    Primary Secondry Secondry Secondry Secondry
    読み込みデータベースは容易に増やすことが可能

    書き込みは一台のみ = スペックアップの限界が、システム全体の限界となる


    View full-size slide

  15. これまでのDBのアプローチ

    書き込み性能の向上

    PingCAP(TiDB Cloud)のアプローチ

    Primary
    NVMe(PCIeSSD)の登場 

    [ メリット ]

    ・ 書き込み量が1000倍にアップ

    書き込みが、SAS HDD 200 iops ⇒ NVMe SATA 200,000 iopsに

    ・ 読み込み量が4000倍にアップ

    読み込みが、SAS HDD 200 iops ⇒ NVMe SATA 800,000 iopsに


    [ デメリット ]

    ・ RAID構成が組めない為、ディスク障害でサーバダウンになる

    アプローチ1 : DiSKのスケールアップでの向上

    ただし、1000倍に上がってもスペックの上限あり

    ※ クラウドだとここまでは出ない事も多々

    View full-size slide

  16. これまでのDBのアプローチ

    書き込み性能の向上

    PingCAP(TiDB Cloud)のアプローチ

    [ メリット ]

    ・ ハッシュ(ブロックデータ)による細かいデータのシャーディング

    データを自動で分散してくれているので、

    システム全体で大きなストレージとして見る事が可能

    ノード追加で書き込みをスケールアウト


    [ デメリット ]

    ・ MVCCやACIDなどのデータ整合性をアプリ側で実施しないといけない

    アプローチ2 : ブロックデータのシャーディング

    アプリ側でのデータ整合性の管理が非常に大変に

    KVS,NoSQL

    View full-size slide

  17. PingCAP TiDBのアプローチ

    書き込み性能の向上

    PingCAP(TiDB Cloud)のアプローチ

    アプローチ2 : ブロックデータのシャーディング

    アプローチ1 : Diskのスケールアップでの向上

    環境に依存してしまう

    特にクラウドでは、iopsの制限があり十分な書き込み速度が提供できない

    ACIDやMVCCなどの処理をアプリが実装する必要あり

    TiDBの選択
    +
 アプローチ3 : KVS、NoSQLが苦手な

    ACID、MVCCの実現

    = NewSQL


    View full-size slide

  18. TiDB
    クエリの増加 

    ノード追加で対応 

    TiDB
    TiDB
    負荷分散・領域管理 

    3ノードのみ必要 

    SQL解析レイヤー

    ( TiDB Cluster )

    PD Cluster

    TiDB
    TiKV TiKV TiKV
    TiKV
    容量拡張

    ノード追加で対応

    TSO / Data Location

    Metadata

    PD
    PD PD
    データストアレイヤー 

    ( TiKV Cluster )

    PingCAP(TiDB Cloud)のアプローチ

    アプリ側でやっていたMVCC管理をTiDBノードで実装 

    KVSなどで苦労した 整合性を悩まず、しかもMySQLプロトコルで使える 

    Raftを採用したKVSの バックアップを兼ね備えた データ分散

    PingCAPのNewSQLへのアプローチ

    複数Cluster(TiDB,TiKV,PD)で運用

    役割別でCluster化することによりリソース管理の容易さを実現

    TiDBの司令塔


    View full-size slide

  19. PingCAP(TiDB Cloud)のアプローチ

    ・ QPS100万近い値まで可能 ※理論値では、QPS300万達成可能

    ・ 容量は無限大(性能考慮で600TiB程度目安)の拡張性

    複数のデータベースをひとつのTiDBで

    運用できる能力


    View full-size slide

  20. PingCAP(TiDB Cloud)のアプローチ

    SQL解析レイヤーTiDB Clusterの特徴

    MySQLインターフェースに準拠、マルチマスター構成、TiKVへ処理をオフロード

    LB

    TiDB TiDB
    mysql > SELECT table_name,column_name FROM tableA WHERE column_name > [ 検索条件 ];

    全ノードでinsert,updateのSQL対応が可能な為、LBでまとめる事が可能

    SQLをKVのデータへ変換を行いTiKVへ処理、もしくは、検索条件をTiKVに処理
    をオフロードさせる

    TiDB
    クエリの増加 

    ノード追加で対応 

    ノード追加は、ステートレスな役割のため、即座に追加可能


    View full-size slide

  21. PingCAP(TiDB Cloud)のアプローチ

    並列度を高めSQLの処理を高速化

    TiDBがアグリゲーションする事によりデータ量が増えた場合、

    TiKVノードが増える為、並列度を向上させ性能劣化させない事

    が可能

    データ量が増えてもSQLの性能を高速化させる技術

    TiKV TiKV TiKV
    データ量が増えた場合もノードも増えるため、並列度が向上

    TiKV TiKV TiKV
    TiKV
    バッチ処理による書き込みSQLの高速化

    最大256KeyをバッチでまとめてTiKVとのネットワーク

    往復回数を減らし一度で書き込みを実施し高速化

    TiDB
    Batch(1⇒value1, 2⇒value2, 3⇒value3….256⇒value254)をまとめてワンリクエストでTiKVに
    書き込みを実行

    column_name > [検索条件1/3]
 column_name > [検索条件1/3]
 column_name > [検索条件1/3]

    TiDB
    column_name > [検索条件1/4]
 column_name > [検索条件1/4]
 column_name > [検索条件1/4]

    column_name > [検索条件1/4]

    TiDB

    View full-size slide

  22. PingCAP(TiDB Cloud)のアプローチ

    データストアレイヤーTiKV Clusterの特徴

    冗長構成、オンラインでの容量伸縮、ノーメンテナンス運用の実現

    TiKV A
    Region 3

    バックアップ 

    Region 1*

    読み書き可能 

    Region 2

    バックアップ 

    TiKV B
    Region 3

    バックアップ 

    Region 1

    バックアップ 

    Region 2*

    読み書き可能 

    TiKV C
    Region 3*

    読み書き可能 

    Region 1

    バックアップ 

    Region 2

    バックアップ 

    ユーザーテーブル

    データサイズは、デフォルト 96MB 

    ※小さいサイズにする事で柔軟性を確保

    Raftログによるコンセンサスアルゴリズム 

    ひとつの読込/書込ポイントと2つのバックアップ

    ※ 圧縮を行っているので、バックアップありの状態でMySQL一台の容量とほぼ同じになる事も

    96MB
    96MB
    96MB

    View full-size slide

  23. PingCAP(TiDB Cloud)のアプローチ

    冗長構成

    ノードが分かれているので、DCを超えて配置可能

    データベース単体でDRも実現可能

    (クエリーの応答が断ではなく)

    デフォルト 20sの応答遅延のみ ※設定により変更可能

    TiKV
    Region 3 

    バックアップ 

    Region 1* 

    読み書き可能 

    Region 2 

    バックアップ 

    TiKV
    Region 3 

    バックアップ 

    Region 1 

    バックアップ 

    Region 2* 

    読み書き可能 

    TiKV
    Region 3* 

    読み書き可能 

    Region 1 

    バックアップ 

    Region 2 

    バックアップ 

    オンラインでの容量伸縮

    96MBという小さいサイズで管理している為、

    ノード追加した瞬間からデータ移行が開始

    バックアップが読み書きを引き継ぐ機能により様々な問題を解決

    昇格(リーダ) 

    ノーメンテナンス運用を実現

    ファームウェアアップデート時にリーダーを

    別ノードへ移動しローリングアップグレードが可能

    TiKV
    Region 3 

    バックアップ 

    Region 1* 

    読み書き可能 

    Region 2 

    バックアップ 

    TiKV
    Region 3 

    バックアップ 

    Region 1 

    バックアップ 

    Region 2* 

    読み書き可能 

    TiKV
    Region 3* 

    読み書き可能 

    Region 1 

    バックアップ 

    Region 2 

    バックアップ 

    TiKV
    バックアップデータを移動し

    リーダーに昇格

    TiKV
    Region 3 

    バックアップ 

    Region 1* 

    読み書き可能 

    Region 2 

    バックアップ 

    TiKV
    Region 3 

    バックアップ 

    Region 1 

    バックアップ 

    Region 2* 

    読み書き可能 

    TiKV
    Region 3* 

    読み書き可能 

    Region 1 

    バックアップ 

    Region 2 

    バックアップ 

    昇格(リーダ) 

    まず、このノードをアップグレードしリーダを
    移動しながら順に対応

    View full-size slide

  24. PingCAP(TiDB Cloud)のアプローチ

    TiDBの司令塔 PD Clusterの特徴

    データ配置の完全自動化、クエリ情報の収集

    3ノードによる冗長構成 

    PD Cluster

    PD
    PD PD
    スケジューラーによるデータの自動運用

    アクセス先の偏りを調整 

    balance-leader-scheduler 

    データの偏りを調整 

    balance-region-scheduler 

    高負荷なデータを調整 

    hot-region-scheduler 

    アップグレード時にデータを退避 

    evict-leader-scheduler 

    データ量が減ったregionのマージ 

    region merge schedule 

    データ量が増えたregionの分割 

    region split schedule 

    heartbeats

    clusterCache
 coordinator

    balance leader 

    balance region 

    hot region 

    TiKV
    PD
    TiKVからのハートビートによりデータの状態を把握


    View full-size slide

  25. PingCAP(TiDB Cloud)のアプローチ

    Re
    - データアクセスの自動負荷分散

    負荷のかかっているブロックを分割して分散可能 set
    config tikv split.qps-threshold=3000 ※例)
    qps3000で分割(デフォルト)

    ID
 item
 price

    1
 apple
 10

    2
 orange
 9

    Table A
    Table A
    ID
 item
 price

    2
 orange
 9

    3,000QPSを超えたら、

    データ分割を行い

    リバランスを実施し性能担保

    Table A
    ID
 item
 price

    1
 apple
 10

    Region

    (32MB程度のサイズ)
    RegionA
    RegionB
    仮にこのデータに4,000QPSが来たと想定

    ※ ID1に2,000QPS, ID2に2,000QPS想定

    分割したRegionで

    2,000QPSになり閾値以下に!!

    PDスケジューラによる自動シャーディングの技術


    View full-size slide

  26. PingCAP(TiDB Cloud)のアプローチ

    - データアクセスの自動負荷分散

    全ての実行クエリの詳細情報の取得が可能に

    クエリの劣化や異常なクエリの発見に役立つ

    ステートメント一覧

    標準出力項目

    トータル実行時間、平均レイテンシー、実行回数 

    該当のクエリをクリックすると実行計画、各種ステータスの状況確認が可能


    View full-size slide

  27. PingCAP(TiDB Cloud)のアプローチ

    - データアクセスの自動負荷分散

    プロデューサー

    ・ 想定以上のユーザが来たら機会損失に・・・

    → TiDB,TiKVのオンライン拡張で回避


    ・ インフラコストを抑えられないのか

    → TiKVのオンライン縮小が可能


    ・ ノーメンテナンスで稼働できないのか

    → ローリングアップグレード、DDLのオンライン変更対応

    ・ 想定以上のユーザが来た

    → TiDB,TiKVのオンライン拡張で回避


    ・ DBが減らせない

    → TiKVのオンライン縮小が可能


    ・ どのクエリーが問題なのか分からない

    → リアルタイムクエリ分析


    ・ プライマリーDBがダウンで障害

    → ノードダウンでも20秒の応答遅延のみ(※設定で1sにすることも可能)


    ・ 急なコラボイベントで緊急対応

    → TiKVのオンライン拡張が可能


    ・ DBが落ちるとトランザクションレベルでデータがロスト

    → (性能考慮で)600TiBで一つのデータベースで管理可能

    インフラ・アプリ

    TiDBでゲーム業界における今までのすべての問題を解決する事が可能に


    View full-size slide

  28. PingCAP(TiDB Cloud)のアプローチ

    - データアクセスの自動負荷分散

    ・ ランキングをリアルタイムに出したい

    ・ マイページがどんどん重くなってきている

    ・ 運用から解放されたい

    インフラ・アプリ

    ゲーム開発の次の一歩


    View full-size slide

  29. PingCAP(TiDB Cloud)のアプローチ

    - Analytics処理の有無

    AnalyticsとトランザクションをTiDBプラットフォームで利用可能

    コマンド一つで連携、構築可能

    必要なテーブル単位でレプ
    リケート指定可能
    TiFlash
    RowData
    RowData
    RowData
    RowData
    TiKV
    すべてリアルタイムデータ
    利用
    ワンコマンドでクラスターへの同期可能、高速な分析クエリのレスポンスへ

    シナリオ1:APのみ検索

    TiDB

    TiFlash

    シナリオ2:TPのみ検索 

    TiDB

    TiKV

    シナリオ3:TP+AP検索

    TiDB

    TiKV

    TiFlash

    TiFlash Cluster追加で簡単リアルタイム分析が可能

    TiDBがコストベースでクエリを判別し、適切なクラスターを選択


    View full-size slide

  30. PingCAP(TiDB Cloud)のアプローチ

    HTAPで実現できるリアルタイム集計

    米国運輸省からの航空機の離陸と着陸の1987年から現在までの定刻条件の集計処理

    OLTPだけでは苦手だった集計クエリが高速化にランキング集計やマイページの統計情報出力で活躍

    MySQLでは、4~5分かかっていたクエリが1秒未満に


    View full-size slide

  31. PingCAP(TiDB Cloud)のアプローチ

    で解決

    フルマネージドサービスの提供

    (サーバ・クラスター運用、高負荷対応、BigData解析、耐障害性 込み)


    フルマネージドリリース済みプラットフォーム

    Amazon Web Services

    Google Cloud Platform

    Microsoft Azure(2024年予定)

    サーバ・クラスター運用をPingCAPに丸投げ


    View full-size slide

  32. PingCAP(TiDB Cloud)のアプローチ

    の特徴

    マルチプラットフォーム

    ・ ベンダーロックインを回避

    AWS、GCP、Azureで

    フルマネージドサービスを提供


    開発環境の提供

    ・ クラスターを組まずコマンド一つで自身のPC環境で構築可能

    ワンコマンドで構築が可能



    ・ 開発/テスト環境向けミニマム構成の提供

    TiDB Cloud上で、2core 200GB環境の提供

    全てのオンプレミス環境で構築可能 

    パブリッククラウド上のフルマネージド
 自社運用に切り替える事が可能


    View full-size slide

  33. PingCAP(TiDB Cloud)のアプローチ

    データベース管理を弊社スペシャリストがフルマネージドでサポート 

    各リージョン上で弊社が、デプロイした環境のご提供方式 


    アクセス方式は、VPC Peeringもしくは、PrivateLinkで接続後、 

    1つのエンドポイントを利用する方式 

    VPC Peering
    or
    PrivateLink
    mysql -u root -h -P 4000 -p

    VPC Peering
    or
    PrivateLink

    View full-size slide

  34. PingCAP(TiDB Cloud)のアプローチ

    マルチAZで環境配置でデータセンター障害にも対応 


    View full-size slide

  35. PingCAP(TiDB Cloud)のアプローチ

    - データアクセスの自動負荷分散

    ・ ランキングをリアルタイムに出したい

    ⇒ HTAPの導入

    ・ マイページがどんどん重くなってきている

    ⇒ HTAPの導入

    ・ 運用から解放されたい

    ⇒ TiDB Cloudのフルマネージドの活用

    インフラ・アプリ

    データベースの更なる進化で対応


    View full-size slide

  36. 目次

    1. ゲーム現場の課題

    2. PingCAP(TiDB Cloud)のアプローチ

    3. どのようなシナリオで活躍するのか

    4. ゲーム業界事例


    View full-size slide

  37. どのようなシナリオで活躍するのか

    特に要望の多いシナリオ


    ・ オンプレからクラウド化したい

    ・ MySQL互換の製品でマルチマスタ製品が欲しい

    ・ HTAPでクエリの高速化をしたい


    ・ 日本法人のフルサポートが欲しい

    PoCからフルサポートでご好評いただいております。


    View full-size slide

  38. 各フェーズにあったTiDB Cloudの利用

    用途
 開発
 ステージング
 本番環境

    QPS目安
 ~500QPS
 ~1,000QPS 
 20,000QPS~ 
 40,000QPS~ 

    インスタンスタイプ 
 2Core

    ディスクサイズ: 

    200GB ~ 500GB 

    4Core

    ディスクサイズ: 

    200GB ~ 2TB 

    8Core

    ディスクサイズ: 

    500GB ~ 600TB 

    16Core

    ディスクサイズ: 

    500GB ~ 600TB 

    目安コスト
 〜1,000ドル 
 2,000〜3,000ドル 
 5,500ドル
 9,000ドル

    特記事項
 

    ・TiDBの最大スケールが2台 

    ・Tiflash 利用不可 


    ※ 上記機能が必要になった場合
    8coreモデルにスペックアップ 


    ・TiDBの最大スケールが2台 

    ・Tiflash 利用不可 


    ※ 上記機能が必要になった場合
    8coreモデルにスペックアップ 

    
 

    必要なQPSに応じた

    豊富なインスタンスタイプのご提供

    *Enterpriseテクニカルサポートでの概算算出 (※上記は参考価格となります。詳しくは [email protected] までお問い合わせください)


    View full-size slide

  39. 目次

    1. ゲーム現場の課題

    2. PingCAP(TiDB Cloud)のアプローチ

    3. どのようなシナリオで活躍するのか

    4. ゲーム国内事例


    View full-size slide