Compared PostgreSQL and NewSQL (YugaByteDB)

徐々に企業への導入もされており、DB界隈では注目を集めているNewSQLをテーマとしてPostgreSQL互換もあるYugaByteDBで性能や可用性、その他課題や制約を整理して比較した内容をまとめました。

Transcript

1. 1 FutureCon 2022 PostgreSQLとNewSQL（YugaByteDB）を 比較してみた 2022/07/18 Mon. Yuta Otsuka
2. • 大塚 雄太 • 現在はPostgreSQLの設計、構築、運用を担当 自己紹介 Copyright ©︎ 2022 by Future Corporation Oracle Database PostgreSQL SQL Server ORACLE MASTER Gold Oracle Database 11g OSS-DB Silver（Goldはこれから受験予定） ― 保有資格 経験 5年（開発、運用） 3年（設計、構築、運用） 1年（設計、開発、運用） スキルセット MySQL ― 1か月（開発）
3. 目次 1. はじめに • PostgreSQLの紹介 • NewSQLの紹介 • YugaByteDBの紹介 2. PostgreSQLとYugaByteDBの比較 • 性能・拡張性 • 可用性 • 運用性 • その他比較 3. まとめ Copyright ©︎ 2022 by Future Corporation
4. はじめに • PostgreSQLの紹介 • NewSQLの紹介 • YugaByteDBの紹介 Copyright ©︎ 2022 by Future Corporation
5. はじめに Copyright ©︎ 2022 by Future Corporation • あるプロジェクトでOracle→PostgreSQLへのマイグレーションに携わる • データベースは年々バージョンアップしており、用途に合わせてプロダクトを選択す る時代になった • RDB、NoSQLに続き、NewSQLという”第3”のデータベースが近年注目を集 めているが、日本国内の導入実績は少ない • RDBとNewSQLを様々な観点で比較し、各々の長所を見極めることで データベースの選択肢を広げるきっかけとしたい
6. ・Bツリー肥大化防止 ・各種の性能改善 ・SEARCH/CYCLE句サポート の紹介 オープンソースのデータベース。近年は年1回の頻度でメジャーバージョンアッ プしてエンタープライズ向け機能追加や性能改善が行われている。 2000 2005 2010 2017 2018 2019 2020 2021 2022 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 ・論理レプリケーション ・宣言パーティショニング ・パフォーマンス改善 ・パーティショニング強化 ・ストプロサポート ・JITコンパイル ・パフォーマンス改善 ・パーティショニング強化 ・拡張統計情報の強化 ・生成列サポート ・Bツリー省スペース化 ・集約関数の性能改善 ・パーティションの性能改善 ・インクリメンタルソート ・VACUUM改善 ・パラレルクエリ改善 ・稼働統計の拡張 ・論理レプリケーション強化 ・MERGE文サポート Copyright ©︎ 2022 by Future Corporation
7. NewSQLの紹介 RDBとNoSQL各々の強みを両立させたデータベースである。 Copyright ©︎ 2022 by Future Corporation トランザクション管理 （ACID） SQLインタフェース スケーラビリティ 概要 RDB(Relational Database) NoSQL(Not Only SQL) New SQL 代表プロダクト 表と表の関係でデータを管理する Key-Valueやグラフなど用途に合わせて管理する Key1 Key2 Val1 Val2 Oracle Database、MySQL SQL Server、PostgreSQL MongoDB、Cassandra、 Amazon DynamoDB、Redis Key1 Val1 表向きはRDBのように表管理できるが、裏側は NoSQLのようにデータが分散管理されている Cloud Spanner、TiDB CockroachDB、YugaByteDB トランザクションによる データの整合性や保全性を保証。 RDBと同等の分散トランザクシ ョン管理が可能。 堅牢なトランザクションはサポー トしていないものが多い。 SQL文によるテーブルの結合や絞 り込みなどCRUD処理が可能。 DBの互換性に合わせたSQLの実 行が可能（TiDB→MySQL互換） SQLに対応していないものが多い。 データの結合や複雑な集計は苦手。 書込ノード追加によるスケールはでき ない(Oracle RACを除く)。 読込ノード追加は可能。 分散データ管理によりサーバ追加 によるスケールアウトで処理能力 増強が可能。 NoSQLと同様にデータの管理方 法が分散型であるため、スケール アウトが可能。
8. の紹介 Copyright ©︎ 2022 by Future Corporation 耐障害性と拡張性に優れた100%オープンソースの分散SQLデータベースであり、オンプレ からマルチリージョンのクラウド環境まで導入できる。 Node#1 PostgreSQL Query Layer PostgreSQL Storage Layer Node#1 Node#2 Node#3 Client PostgreSQL API Tablet3 follower Tablet2 follower Tablet1 Leader Tablet3 follower Tablet2 Leader Tablet1 follower Tablet3 Leader Tablet2 follower Tablet1 follower Table1 YSQL API YSQL API YSQL API YCOL API YCOL API YCOL API DocDB Storage Layer YugaByte Query Layer Client Distrbuted Txn Mgr Distrbuted Txn Mgr Distrbuted Txn Mgr 一貫性を担保す る分散トランザ クション管理 Leaderのみ更新 でき、Tablet単 位でレプリケー ションすること でWhite / Read を負荷分散
9. PostgreSQLとYugaByteDBの比較 • 性能・拡張性 • 可用性 • 運用性 • その他比較 Copyright ©︎ 2022 by Future Corporation
10. PostgreSQLとYugaByteDBの比較 Copyright ©︎ 2022 by Future Corporation 単一ノード、または複数ノードでOLTP（オンライントランザクション処理）と OLAP（オンライン分析処理）のベンチマークを実施する。 システム障害時にサービス停止せず稼働し続ける指標を指す。 HA構成や各データベースの可用性に関する特徴を確認する。 ノード監視や性能分析など運用方法を確認する。 概要 評価軸 データベースの一般的な非機能要件を基に以下の評価軸で比較する。 性能・拡張性 可用性 運用性 PostgreSQLとYugaByteDBの共通点、相違点を確認する。 その他比較
11. 性能・拡張性 Copyright ©︎ 2022 by Future Corporation TPCの提供するベンチマークテストを用いて性能測定を行うとし、内容を以下に示す。 TPCとはDBの性能を計測する様々なベンチマークテストを策定している団体を指す。 出力結果 用途 概要 TPC-B（pgbench） TPC-H 入力 5つのSQLを1トランザクションとして 同時実行数を増やしていく。 銀行の窓口業務をモデルにしている。 窓口 銀行口座 支店 取引履歴 TPS（秒間で処理できるトランザクション数） オンライン処理のように大量アクセス時の 限界性能を測定する。 意思決定支援をモデルにしている。 22種類の複雑な分析SQLを順番に実行する。 SQL単位の処理時間 バッチ処理のように大量データを処理する 際のスループットを測定する。 部品 供給元 地域 国 注文 明細 部品供給 関係 顧客
12. 性能・拡張性 Copyright ©︎ 2022 by Future Corporation PostgreSQL 10、14、YugaByteDB 2.15の3つのバージョンで比較する。 概要 条件 その他の条件は以下の表に従って性能検証を行う。 MWバージョン AWS環境上で同一リージョン、かつ同一インスタンスタイプで構築する （t3.2xlarge：vCPU 8コア、メモリ32GB）。 環境 PostgreSQLの性能に関するパラメータを推奨値に設定する（shared_buffers：RAMの 25%分など）。OSカーネルパラメータも併せて設定する（HugePagesなど）。 パラメータ設定 ネットワーク影響を受けないようにするため、ローカルから負荷掛けを行う。 1ケース実行毎にバッファキャッシュ、ファイルキャッシュのクリアを行って処理時間を安定 させる。 JITコンパイルは使用しない。 備考
13. OLTP限界性能（≒オンライン性能） Copyright ©︎ 2022 by Future Corporation OLTPはPostgreSQLのほうが高い。また、PostgreSQLのメジャーバージョンア ップによる性能向上も確認できた。 最大126%の性能差 PostgreSQL14のほうが10と比較 して平均114%の処理能力向上 YugaByteDBはロック競合エラーが 多発した。悲観ロックをサポートし ていないことが起因していると推 測。3ノードでの検証も同様の結果 であったため、記載は割愛する。 TPS(Transaction Per Second) 同時実行数(スレッド)
14. OLAPスループット（≒バッチ性能） Copyright ©︎ 2022 by Future Corporation OLAPもPostgreSQLのほうが高く、メジャーバージョンアップにより性能向上も 確認できた。 処理時間[分] SQLファイル名 YugaByteDBはデータ登録が12時間経過しても完了しなかったため、 データ件数を1/10スケールで実施しており、処理時間は参考値とする。 20分以上経過しても終了しないSQLは処理を中断した。 PostgreSQL14のほうが10 と比較して平均22%分の処 理時間を削減。 最大72%分の処理時間を削減。
15. 補足：YugaByteDBベンチマーク Copyright ©︎ 2022 by Future Corporation NewSQLはデータを分散管理しているため、分析や集計はRDBより劣る傾向にあり、OLAPの結果は想 定通りであった。 OLTPはシャーディングなどオーバーヘッドが発生するため、単一ノードでの性能差は発生する。 公式では別のベンチマークで複数ノードによる処理能力の増強が確認できるとのこと。 https://blog.yugabyte.com/tpc-c-benchmark-10000-warehouses-on-yugabytedb/
16. Node#2 Node#3 Node#1 Universe YB-TServer YB-TServer YB-TServer Node#2 Node#1 Witness Cluster PostgreSQL PostgreSQL Tablet YSQL Distrbuted Txn Mgr Tablet YSQL Distrbuted Txn Mgr Tablet YSQL Distrbuted Txn Mgr 可用性 Copyright ©︎ 2022 by Future Corporation 各データベースの一般的なHA構成（高可用性）を以下に示す。 Table（Primary） Table（Secondary） Async Streaming Replication 3rd Party Cluster Soft Heart Beat 3rd Party Cluster Soft 3rd Party Cluster Soft YB-Master YB-Master YB-Master Heart Beat Sync
17. 可用性 Copyright ©︎ 2022 by Future Corporation PostgreSQLとYugaByteDBで可用性の比較を行い、以下に示す。 ネイティブ クラスタソフト ダウンタイム データ欠損 クラスタソフトが組み込まれていないため、3rd Party 製のクラスタソフトを導入する必要がある。 クラスタソフトによるが、障害時に数十秒～数分程度 のダウンタイムが発生する。 非同期レプリ&障害時のノード停止&Secondaryの昇格 にかかる時間分だけデータ欠損が発生する。 自動ノード選択機能が導入されており、フェイルオーバー& リカバリを実現できる。 数秒で障害ノードの切り離しと昇格が完了する。 ノード障害中も他ノードで書き込みが可能なため、データ欠 損は極めて少ない。 負荷分散による継続性 Pgpool-IIを用いて参照クエリを分散できるが、 パー スが重いので負荷が高くなる点に留意する。 シャーディング、専用JDBCによる自動ロードバランス、縮 退時のリバランスなど負荷分散機能が豊富で継続性が高い。
18. 運用性 Copyright ©︎ 2022 by Future Corporation ノード監視や性能分析は以下の機能を用いることで運用性を向上させることができる。 PC / Server DB Server Cloud YugaByteDB YugabyteDB Managed PC browzer syscatalog Managed Data Managed Data DB Server PostgreSQL pg_statsinfo 稼働分析データ syscatalog 性能分析レポート pgAdmin
19. 運用性 Copyright ©︎ 2022 by Future Corporation PostgreSQLとYugaByteDBで運用性の比較を行い、下表に示す。 モニタリング SQL実行 監視 メンテナンス実行 性能分析 監査 HWリソースやSQL単位でのモニタリングが可能。 SQLの実行やPL/pgSQLのデバッグ機能、実行計画の グラフィカル表示など開発面での機能が充実。 アラートやログの監視が可能。 VACUUMやANALYZEといったテーブル単位の メンテナンスが可能。 pg_statsinfoによってAWRレポート相当の性能分析や 過去の実行計画の履歴データで分析が可能。 pgAuditという拡張機能を用いて監査は可能。 ログ出力のみのため、GUIでの監査は要作り込み。 pgAdminよりも詳細（スロークエリなど）なモニタリング項 目が充実している。 SQLの実行はできるが、それ以外の機能は確認できなかった。 アラートやログ監視が可能。 テーブル単位以外に、DBのアップデートなど広いレイヤー でのメンテナンスが可能。 パフォーマンスアドバイザー機能によって問題提起や対策を 提案する。レポート機能は確認できなかった。 監査用のダッシュボード上で不正操作などのアラート検知が 可能。
20. その他比較 Copyright ©︎ 2022 by Future Corporation PostgreSQLとYugaByteDBの共通点を以下に示す。 YugaByteDBはPostgreSQL11をサポートしているため、PostgreSQLの知識を活用でき る（postgresql.confの設定値など）。 今後のロードマップではPostgreSQL13のサポートを予定している。 psqlやpg_dumpといったCLIはysqlshやysql_dumpといったコマンドに置き換える必要は あるものの、オプションや引数の指定方法はPostgreSQLと同じである。 DDLやDML、トランザクション管理やPL/pgSQLなどほとんどの文法はサポート済み。 ヒント句（pg_hint_plan）などの拡張機能は予めバンドルしており、他にもサポートされて いる拡張機能は自由に導入、有効化することができる。 詳細 共通点 設計 PostgreSQL互換 拡張機能
21. その他比較 Copyright ©︎ 2022 by Future Corporation PostgreSQLとYugaByteDBの相違点を以下に示す。 継承、主キー削除などサポートがされていない互換性はあるが、大部分は一般的な利用 において問題になりにくいと考える。ただし、悲観ロック管理（FOR UPDATEによる行ロッ ク）と表ロック管理がサポートされていない。悲観ロックは今後サポート予定とのこと。 PostgreSQLは各企業が保守サポートを提供しているが、 YugaByteDBは日本法人との直接サポートのみと思われる。有償サポートはあるが、マ ニュアルも英語のみでやり取りは英語推奨かもしれない（要確認）。 PostgreSQLは3rd party製品の各ベンダーが事前に動作検証を行っており、サポートす るソフトウェアとして明記されているケースが多い。 そのため、他製品を組み合わてサービスの構築がしやすい。 調査した範囲でYugaByteDBはサポートに含まれている製品が見当たらなかった。 詳細 相違点 互換性サポート 製品サポート 3rd party製品との 組み合わせ
22. まとめ Copyright ©︎ 2022 by Future Corporation
23. まとめ Copyright ©︎ 2022 by Future Corporation 各検証結果を基に総評を下表に示す。 性能・拡張性 可用性 運用性 単一ノードでの処理能力が高く、メジャーバージョン アップにより更に性能が向上している。 ネイティブの機能では実現できないので3rd Party製の クラスタソフトに依存する。 pgAdminやpg_statsinfoなど必要な機能を拡張するこ とで運用要件に十分対応できる。 PostgreSQLに比べると単一ノードでの処理能力は低いが、 複数ノードでの処理能力は向上させることができる。 マルチリージョンでの高可用性も実現でき、災害対策等も容易 に実現できる。 YugaByte Manegedをはじめ、運用にかかわるYugaByte製の プロダクトが充実している。
24. まとめ Copyright ©︎ 2022 by Future Corporation PostgreSQLはメジャーバージョンアップにより性能向上と機能追加がされてい る。スケールアウト引き続き行えないため、小～中規模のシステムには導入させ やすい。大規模システムはOracle Database（RAC）や複数プロダクトの組み合 わせが適していると考える。 YugaByteDBは（お財布の都合により）少ないノード数での性能測定のみであった が、楽天モバイルの事例のように約100台、3つのDCで構築された環境であれば 高性能と高可用性の両立ができるものと考える。
25. まとめ Copyright ©︎ 2022 by Future Corporation 現時点でRDBで出来ることすべてがNewSQLで実現できるわけではなく、データ 設計やアプリケーション設計で解消すべき課題はある。 そのため、NewSQLはRDBの上位互換ではなく、各々の長所を多角的に評価して 選択すべきと理解しました。 IoTやAI、また今後発展が予想されるメタバースなど データベースが管理するデータの量は更に増え続けると予想。 そのため、データベース領域の発展も加速することでデータベースエンジニアの 在り方も多様になると考え、選択肢を増やし続けることができる一 生勉強できる領域だと改めて感じた。
26. Thank you for listening. Copyright ©︎ 2022 by Future Corporation