原著者: Zhao Yuying、InfoQ 編集長
現在、ある有名な国内スポーツ ブランドは、世界中で 12 の靴とアパレルのスポーツ ブランドを運営し、全国に約 10,000 のオフライン ストアを持ち、ナイキ、アディダス、プーマ、コンバースなどのブランドの店舗のほとんどは同社によって運営されています。これらのビジネスは、同社のテクノロジー企業 Yunsheng Haihong によって全面的にサポートされています。過去 10 年間、Yunhai 小売システムは、オムニチャネルおよびフルカテゴリーのスポーツ シューズと衣料品をサポートする小売サービス プラットフォームであり、8,000 を超えるオフライン ストアの小売をサポートしています。
小売分野のこのようなベテラン企業は、どのようにして MySQL からネイティブ分散データベースに段階的に移行したのでしょうか? 全体的な構造変更のアイデアは何ですか? 実践を経て、コストの観点からOracleと国産の分散データベースをどう評価するか... 最近、InfoQはYunsheng HaihongのチーフアーキテクトであるHong Liang氏にインタビューする機会に恵まれ、上記の問題について一つ一つ議論した。
背景の紹介
Yunsheng Haihong のデータベース アーキテクチャ設計を紹介する前に、その全体的なビジネス背景を理解しましょう。Yunsheng Haihong の中核事業は、グループ内で使用される在庫、端末小売、財務サポート システムの 3 つのモジュールを含む小売システムです。
2013 年以来、Yunsheng Haihong はデータベース アーキテクチャ全体の構築を開始し、ビジネスの継続的な発展により複数回の反復を経てきました。2016 年以前、雲盛海虹は基本的にまだ伝統的な小売時代にありました。内部情報システムは主要地域によって構築され、独自のデータベース構造を維持し、ビジネス データを毎日本社にアップロードしていました。データベースは集中化された単一データベースを採用しています。この手法の利点は、構造がシンプルであることですが、ビジネスが発展するにつれて、地域の集計データをタイムリーに確認する方法がない、また、地域の集計データを確認することができないなどの欠点がますます明らかになります。全国の地域にわたるリアルタイムの在庫。
これらの問題を解決するために、Yunsheng Haihong は 2016 年に新しいアーキテクチャである Yunhai Retail System を立ち上げ、デジタル小売時代におけるアーキテクチャの進化への道を切り開きました。
MySQLからOracle、そして完全なTiDBまで
これまでに、雲海小売システムは主に 3 段階の進化を経験しました。
フェーズ 1: マイクロサービスの適用、データ共有の実現、最初のオペレーションの改善、デジタル ビジネスの開発のサポート
現段階では、Yunsheng Haihong はマイクロサービス + MySQL サブデータベースとサブテーブルの方法を使用しています。プロジェクトの開始時に、チームはデータの垂直セグメンテーション モードが短期間で比較的安定しており、MySQL クラスター開発の難易度がチームにとって比較的理解しやすいと考え、MySQL を選択しました。
ビジネスの急速な発展に伴い、多くの問題がチームの当初の予想を超えていました。MySQL クラスターは複雑なレポート分析をサポートしていませんでした。チームは、この部分の需要を共有するために Oracle を導入しようとし、Otter を通じてデータをリアルタイムで同期しました双方のデータの整合性を確保します。TOBビジネスにおいては内部レポートが非常に重要であり、データの精度が非常に高く、ホットデータとコールドデータが頻繁に変化するため、Oracleの導入によりリアルタイムレポートの問題が解決されました。
それ以来、雲海小売システムは5年間にわたりビジネスの急速な発展をサポートし、国内のさまざまな地域および主要地域での大量のデータの保管の実現、リアルタイムのデータ共有の実現、および目標の達成など、多くの小さな目標を達成しました。ビジネスの見える化の目標。しかし、ビジネスの拡大と要件の難しさの増加に伴い、いくつかの新たな課題が徐々に浮上してきました。まず、全体のアーキテクチャはサブデータベース、サブテーブルともにMyCATをベースとしていますが、日々のメンテナンスにおいて、テーブルの追加やテーブルの調整など新たな業務が発生すると、メンテナンスレベルによって人件費が増加し、構成を手動で調整する必要があるため、その構成が呼び出されます。
第二に、当時すでに 110 以上の Otter 同期チャネルがあり、使用するにはあまり理想的ではありませんでした。たとえば、ソース側にはテーブルを追加するがターゲット側にはテーブルを追加しない、または単にフィールドを調整するだけでも、同期の中断が発生する可能性があり、維持するために多大な労力が必要になります。最も重要なことは、Oracle も大量のデータを拡張できないことや、集計ライブラリの分析時間が短いことなど、いくつかのボトルネックに直面していることです。
フェーズ 2: データの爆発的な増加による集約ライブラリ分析の適時性の低下の問題を解決する
2020 年以前、Oracle の単一ポイントのパフォーマンスは水平方向に拡張できなくなり、チームは代替案を積極的に探し始めました。この時点でチームは TiDB と連絡を取り始め、当時 InfoQ が開催した ArchSummit カンファレンスで PingCAP の共同創設者兼 CTO である Huang Dongxu 氏から詳細な説明を聞きました。 , TiDBはOracleの問題点を解決できてとても便利であることが分かりました。社内の小規模トライアルが顕著な成果を上げた後、Yunsheng Haihong は最終的にTiDBクラスターの導入を早急に推進することを決定しました。
TiDB を実稼働環境にデプロイする際のストレス テスト計画を決定します (ストレス テストの実装には Percona のオープン ソース ツール Percona-playback を使用します)。
「2020年に疫病が発生し、当社のビジネスに多大な影響を及ぼしました。当社はオンライン ビジネスに注力し始めました。技術面で最も直接的なプレッシャーとなったのは、在庫管理モジュールの変更でした。もともと、ニーズを受けてTaobao、Jingdong、Vipshop、Douyinなどのプラットフォームとの接続は、最終的に実装までに3か月、場合によっては半年かかりますが、すでに早い段階でTiDBに切り替えているため、技術スタックレベルでの準備は十分に行っており、最終的には 2 週間しかかかりませんでした。単一プラットフォームの在庫管理モジュールの調整は短期間で完了しました」と、Hong Liang 氏は述べています。
2020年TiDB導入後のアーキテクチャ図
社内エンジニアに関する限り、TiDB の導入も非常に順調に進んでいます。まず、Yunsheng Haihong の主なビジネスは MySQL をベースに構築されており、TiDB は MySQL プロトコルと完全な互換性があり、MySQL から TiDB への移行は比較的スムーズです。次に、TiDB は日常の運用保守、容量拡張、容量削減が非常に便利ですが、これまで DBA は、月次または四半期ごとに早朝に十数個のインスタンスのデータ移行を完了する必要がありました。データ移行のリスクは非常に高く、問題が発生した場合の影響は非常に深刻です。TiDB 導入後は、MySQL の日常検査などの時間のかかる作業はもちろん、基本的に移行作業を行う必要がありません。アーカイブとバックアップ。最後に、MySQL サブデータベースとサブテーブルによってもたらされる制限により、チームは変更に迅速に対応できません。会社の組織構造を調整するたびに、ビジネスに一定の影響が生じます。チームは、この影響を迅速に吸収する必要があります。 TiDB の導入により、テクノロジー スタック全体がより効率的かつ柔軟になります。
フェーズ 3: 分散データベースの完全な導入に向けて移行し、最初はクラウドベースのアーキテクチャを検討します
現在、Yunsheng Haihong は社内で MySQL から TiDB への移行を完了しており、初期バージョン 4.0 から現在のオンライン バージョン 5.4.2 まで、TiDB をアップグレードするたびに、より実用的な機能が提供されます。次に、Yunsheng Haihong は Oracle から TiDB への移行を試み、徐々にデータベース クラスターを収集し、運用と保守の負担をさらに軽減する予定です。Yunsheng Haihong 内では、Oracle はコア ビジネスや書き込み業務をあまり引き受けず、基本的に AP 指向のデータとビジネスを移行するため、この部分は比較的簡単です。チームはデータ精度の調整を含むフロントエンドのデータ移行に重点を置きます。 。
インタビューの中で、Hong Liang 氏は、現在の社内 TiDB クラスターは 100 マシンに達し、フロントエンドとバックエンドのビジネス負荷にそれぞれ耐えるために 2 つの TiDB クラスターが展開されていると述べました。ステートメント分析の負荷は Oracle によって引き受けられます。その時点で、Yunsheng Haihong のすべてのビジネスは TiDB クラスター上で実行され、Oracle クラスターは段階的にシャットダウンされます。
さらに、アーキテクチャ全体が徐々にクラウドベースになっていきます。現在、Yunshenghaihong の一部のアプリケーションはプライベート クラウドに変換されており、将来的には、開発、テスト、トレーニング、本番などの一部の環境がパブリック クラウドに変換されることが試みられます。
データベース設計の中核問題に関するディスカッション
小売業界では、Yunshenghaihong はテクノロジーに多額の投資を行っている企業の 1 つと見なすことができますが、その事業範囲と規模を考慮すると、技術的なアーキテクチャを構築するのは困難であり、データベースの選択とアーキテクチャの進化において考慮すべき要素は数多くあります。 。その過程で、チームはいくつかの経験も調査しました。
小売業界がOracleを完全に放棄することは可能でしょうか?
小売分野においては、特に極めて高い精度が要求される財務データなど、ある程度の歴史のある企業であれば初期にOracleデータベースを導入していたはずですが、当時は国内に代替できるデータベースがあまりありませんでした。現在、国内のデータベースはますます成熟し、選択肢が増え、多くの企業が他のデータベースへの移行を試み始めています。
Yunsheng Haihong 氏の経験から判断すると、小売業界には将来的に Oracle を放棄するあらゆる機会があり、非常に要求の厳しい財務諸表データの処理さえも国内のデータベースで処理できるでしょう。
モデルの選択に関しては、企業はビジネスの特性に応じて事前に耐圧テストを実施する必要があり、移行前に関連する計画を立てる必要もありますが、Yunshenghaihong は MySQL から TiDB へ、Oracle から TiDB への十分な記録を作成しています。
コストの観点から見ると、分散データベースにはそれだけの価値がありますか?
一口にコストといっても、ソフトウェアのライセンス料、ソフトウェアのサービス料、ハードウェアの調達料、日常の保守料など多岐にわたりますが、企業の内部事情によっても異なります。
Yunsheng Haihong 氏の経験から判断すると、ソフトウェア ライセンス料に関しては、TiDB が Oracle より明らかに有利です。ソフトウェア サービス料に関しては、TiDB 自身のエコロジーとコミュニティ構築 (ドキュメントを含む) は比較的完全ですが、国内のサービスが不足しているため、データベースの成熟度が高いと、成熟したサービスエコシステムの構築に人的資源を投入できないため、選定状況に応じて判断する必要がある; ハードウェア調達コストの点では、Yunsheng Haihong は使用前と使用後の差がほとんどない; 日常のメンテナンスの点では、 TiDB は敷居が低く、メンテナンスが簡単なので人件費を大幅に節約できます。
MySQL クラスターの管理と比較すると、データのバックアップ、ハードウェアの障害対応、マスター/スレーブノードの管理などが比較的面倒ですが、TiDB は基本的に軽量な保守を実現でき、その後のクラウド化によりさらに運用保守コストが削減される可能性があります。
完全にクラウド化しますか?
前述したように、Yunsheng Haihong は実際には将来的に徐々に曇る予定であり、そのチームはこれについて多くの考慮事項を持っています。
インタビューの中で、Hong Liang 氏は、単一のデータベースではなくクラスター全体の観点から見ると、コンピュータ ルームの管理、ネットワーク セキュリティ、高可用性、災害復旧の点で、クラウド化はローカル導入よりも多くの利点があると述べました。現在では、TiDB と Alibaba Cloud も連携しており、特に独自のテクノロジー スタックが MySQL に基づいている企業にとって、クラウド化は比較的容易です。
インテリジェントな運用と保守の価値は、初期段階で検討する価値がありますか?
過去 2 年間、展開、運用、運用、メンテナンスのプロセス全体をよりインテリジェントにするために、多くのデータベースに AI 機能が積極的に統合されてきました。Yunsheng Haihong にとって、企業内での AI 実装の需要は比較的緊急性が低いです。
「インテリジェントな運用保守や AI 機能の導入は、基盤となるインフラが整備されているかどうかにかかっています。ストレージと計算が分離されているか、運用保守機能が向上していなければ、AI は空中の城のようなものです。 」