|+|音楽 |+| |+|

|+|多くの顧客は、これら2つの理由から TiDB を選択します。

|+|最初のものは「スケーラブル」です。

TiDBはミッションクリティカルなワークロードに対して拡張性があります。

|+|TiDBは水平スケーラビリティを提供し、計算レイヤー、ストレージレイヤー、メタデータレイヤーすべてでスケールインとスケールアウトをサポートし、ゼロダウンタイムでスケールイン/アウトが可能です。|+| |+|

これらのレイヤーはお互いに切り離されており、必要に応じて中断することなくスケーリングすることができます。 |+|

|+| TiDBを使用することで、計画停止と非計画停止の両方を排除できます。

以前に言及されたススケールインとスケールアウトに加えて、TiDBはオンラインローリングアップデートおよびオンラインDDLもサポートしています。 |+| |+|

その内部に備えたセルフヒーリング能力は、コンピュート、ストレージ、メタデータの各レイヤーで有効化され、ソフトウェアの障害、ハードウェアの故障、そしてデータセンターの停止に直面しても、ビジネスの継続性を確保しています。 |+| |+|

さらに、|+|追加のセットアップは必要 ありません、ユーザーは TiDB Cloud 上でこれらの利点を利用できます。

|+| 伝統的なRDBMSと同様に、|+| TiDBは強力な一貫性を持つACIDトランザクションサポートを提供します。

|+|TiDBはMySQL 5.7と互換性があります。ほとんどの場合、既存のアプリケーションを変更する必要もなく、TiDBに移行することができます。|+| ただし、英語の原文に存在する場合は、それらの文字列を翻訳結果に再度入れる必要があります。

|+| すでに本番で証明済みですが、数百、あるいは数千のMySQL互換データベースを単一のTiDBクラスタに統合することが可能であることが示されています。 |+|

|+| TiDBを選ぶ第二の理由は、ビルトインのTranslytical、またはHTAP機能です。|+| これは、TiDBがトランザクションと分析的トランザクションの両方を同時に扱うことができることを意味します。

|+|TiDBは、行オンライン処理（OLTP）と分析ワークロードの両方の処理に最適化されているため、行ベースのストレージエンジンと列指向ベースのストレージエンジンの両方に備えています。 |+| |+|

一つの標準的なSQLインターフェースを使用することで、ビジネスアナリストはオンライン操作と冷えたデータを組み合わせた両方から簡単に洞察を得ることができます。 |+|

|+|TiDBはPBスケールで大量のデータを効率的に格納および取得できます。

|+|TiDBは、標準SQLを実装し、JSONデータ型と関数をサポートし、多くのビッグデータの問題を簡素化することができ、ビッグデータエコシステムから特化したツールを取り込む必要がなくなります。 |+| |+|

結果、SQLはドライバーの座席に戻ってきました。

|+|TiDBはNo One Size Fits Allの複雑さをカプセル化し、再投資を減らし、特にクラウドでの再投資を減らす。 |+|

データベースの分野では、多様なアプリケーションに一つの万能な解決策が存在するわけではないことが、長年にわたって広く認められています。したがって、異なる要件に対応するためには、ユニークなデータベースの要件に対応する必要があります。 |+| |+|

高可用性・スケーラビリティが必要な場合もあれば、 |+| 高パフォーマンス・低レイテンシーが求められる場合もあります。

さらに、異なるデータベース技術および構成は、独自の利点と制限を提供します。 |+|

したがって、アプリケーションの特定のニーズを理解し、適切なデータベース技術と構成を選択して、それらの要件に最適に対処することが不可欠です。 |+| |+|

しかしながら、これはしばしば管理の複雑さの|+|かなりの増加につながることがあります。これは、再投資問題があるためにパブリッククラウド|+|環境でさらに増幅する可能性があります。

TiDBの中心には、キーバリューNoSQLデータベースがあります。このデータベースには、状態を持たないSQLレイヤーが組み込まれており、NoSQLとRDBMSの両方の利点を持つようになっています。 |+|

|+|一つのサイズがすべてに合う |+|

ただし、高い操作レベルで|+|は、TiDBが統合されたデータベースとして単一の管理インタフェースを提供するため、|+|ユーザーは両方のアプローチを同時に利用することができます。

極端に低いレイテンシーが必要な場合を除き、ほとんどの場合、TiDBは包括的なソリューションです。 |+|

|+|先に言及したように、TiDBは行ベースおよびカラムベースの両方のストレージエンジンを提供しています。

カラムベースのエンジンは、解析ワークロード用の行ベースのエンジンから必要なデータを自動的に複製することができる。それにより、追加のETLジョブなしにデータをレプリケートすることができる。 |+| |+|

|+|ここにはTiDBのない例のアーキテクチャがあります。

ここに6つのデータベースクライアントインスタンスを配置しました |+| この実践では、もちろん、はるかに多くのものがあるかもしれません。

アーキテクチャは既にクラウド対応しています。

|+|ここでの可用性ゾーンとは、クラウドサービスプロバイダが提供するデータセンターまたはAZを意味します。

|+|そして、私たちはオンライントランザクション処理のためにMySQLを持っています。

ここでのスタンバイデータベースは、高可用性と災害復旧の目的でLeaderデータベースの |+| 完全なレプリカです。

|+| 書き込みのためのLeaderと読み取りのための再レプリカを使用することで、かなりの重いワークロードを処理できます。

|+|そして、読み取りパフォーマンスを向上するために、転送オブジェクトまたはホットスポットオブジェクトのためのキャッシュがあります。

|+|NoSQLデータベースは、水平方向に拡張可能な永続的なストレージであり、そのノードは可用性ゾーンをまたいで高可用性、ディザスタリカバリー、パフォーマンス、スケーラビリティを実現するために使用されます。|+| ただし、入力された英語文に|+|がある場合は、翻訳結果にも含まれます。

データレイヤーのアーキテクチャはある程度複雑です。

|+|MySQLマスターを拡大してみましょう。

ビジネスが成長するにつれ、データは最終的に単一の機械を超えるようになるでしょう。 |+|

増加する書き込みを処理する一つの方法は、シャーディングと呼ばれるものを使用してデータを複数のデータベースに分割することです。 |+|

この場合、AからZの文字で始まるユーザーIDを持つすべての情報を単一のデータベースに格納することを検討します。 |+|

書き込みキャパシティを増やすには、データベースを2つに分割します。 |+|

最初のデータベースを扱っているユーザーと、|+|二番目のユーザーと、いくつかのユーザーが扱っています。

ここでは、ユーザーIDの最初の文字を例として使用していますが、実際には|+|独自の一貫したハッシュを使用して、特定のデータのシャードを決定することがあります。

|+|キャパシティをさらに増やす必要がある場合は、同じことをしてデータセットを再分割します。

|+|追加のシャードは、レポート生成がますます困難になることを意味します。

|+|書き込み操作のみに使用されます。読み取りパフォーマンスのために、ローカル可用性ゾーンのレプリカも必要です。また、ペアリングAZ内のシャードごとにスタンバイデータベースが必要です。高可用性と障害復旧のために。 |+| |+|

開発者や運用チームにとっては全く楽しくないと思われます。

|+|TiDBの使用により、データレイヤーアーキテクチャは簡単であり、さらに複雑さを減らすことができます。 |+|

Like NoSQL, TiDBは分散型であり、水平方向のスケーリングが可能です。

|+|TiDBはシャーディングを自動的に処理し、アプリケーションには透過的であるということを意味しています。

|+|NoSQLとは異なり、TiDBはトランザクションとSQLをネイティブでサポートしており、MySQLと互換性があります。

|+|TiDB内で、レプリケーションは自動的に発生し、シャーディングも自動的に発生し、ロールベースおよびカラムストア変換も自動的に発生します。 |+|

これを日本語に翻訳して、１行で出力します。英語の文章に存在する場合は|+|マークを無視し、翻訳後の文章には元のマークを戻します。

MySQLやNoSQLデータベースの両方を同時に置き換える多目的データベースとしての位置で動作します。

|+|TiDBは汎用性が高く、アプリケーションに集中することができます。

ユーザーは、将来的に痛みが増えることを心配することなく、データを|+|柔軟に取得できます。

しかしながら、TiDBは多目的であるにも関わらず、アプリケーションによって引き起こされるホットスポットのボトルネックを排除することはできないことを言及する必要があります。 |+|

|+| つまり、Redisなどのキャッシュコンポーネントは、アプリケーションのホットスポットケースに対してまだ必要です。

We will discuss how to mitigate hotspots in detail in the TiDB パフォーマンスチューニング course in the database operation learning path and in TiDB specific feature course in the developer learning path. |+| 私たちは、データベース操作学習の道筋における TiDB 及び開発者学習のパスにおける TiDB 特有の機能コースで、ホットスポットの緩和方法について詳しく議論します。 |+|

|+|TiDBは、3000を超えるグローバル採用企業によって利用されており、グローバルなイノベーションLeadersに信頼されています。

|+|以下にいくつかの例を示します。

|+|Catalystは、強力な顧客成功プラットフォームを提供するSaaS（Software-as-a-Service）企業であり、顧客との成功を達成するために企業を支援します。 |+|

|+|Catalystは、データバックエンドとしてPostgreSQLを使用し、その後Elasticsearchを使用したが、うまくいかなかった。

|+|その後、CatalystはTiDBを調査しました。

TiDBの応答時間は、競合他社よりも10〜60倍高速だったことがわかりました。 |+|

Also they are keen that TiDB has perfect support for online DDL.  また、彼らは TiDB に対してオンライン DDL の完璧なサポートがあることを強く望んでいます。

|+|ボルトは、主に車のレンタル、カーシェアリング、フードデリバリーサービスを提供しているエストニアに本拠地を置くグローバルなモビリティ企業です。 |+|

ボルトは1億人以上の顧客がいます。

|+|以前、Boltは主要なデータベースとしてMySQLを使用していました。

データ量が増えると、分割が導入されて、期待に応えられなくなった。 |+|

|+|Boltは、MySQLの代替としてVitessとTiDBを探求しました。

VitessはBoltのアプリケーションに多くの変更を必要とすることがわかりました。 |+|

|+|Boltはついにオープンソースの分散NewSQLデータベースであるTiDBを選みました。

|+|Boltは、TiDBのほぼ無限の水平スケーラビリティに感銘を受けています。

|+|自動的にストレージノードを追加または削除することによって、急激なデータのスパイクや急落が発生しても、数百テラバイトものデータを簡単に処理できます。 |+|

|+|さらに、TiDBには強力な圧縮機能があり、ストレージコストが削減されています。

|+|最後に、簡素化されたアーキテクチャを持ち、トランザクショナルおよび分析ワークロードを同時に処理できます。 |+|

|+|より詳細な情報については、https://www.pingcap.com/customers/をご覧ください。より多くのユースケースについては、そちらをご参照ください。 |+|