PostgreSQLのような従来のデータベースは、大規模な環境でのこうした要求に応えるようには設計されていませんでした。小規模なワークロードでは優れたパフォーマンスを発揮しますが、エンタープライズ規模になると、同時実行のボトルネック、レプリケーションの遅延、そしてトランザクションと分析の両方を同一システムで管理することによるオーバーヘッドといった問題に直面することがよくあります。そのため、パフォーマンスとリアルタイム分析を維持しながら、アプリケーションの容易な拡張を可能にする、より優れたデータベース管理システムの必要性が高まっています。

SingleStoreはこれらの問題に対処するために設計されています。分散アーキテクチャと、行ストアと列ストア構造のユニバーサルストレージにより、トランザクションワークロードと分析ワークロードの両方を大規模に処理できます。この記事では、SingleStoreがパフォーマンスを損なうことなく、最も一般的なスケーリング問題にどのように対処するかを検証します。 

PostgreSQLのアーキテクチャ上の強みと限界

ここ数年、PostgreSQLはアプリケーション構築におけるオープンソースデータベースの第一選択肢となっています。その堅牢性とアーキテクチャは多くの開発者に好評です。

1. PostgreSQL は、マルチバージョン同時実行制御 (MVCC) に準拠しており、トランザクション データの読み取りと書き込みが操作をブロックせずに処理できるため、データの正確性と一貫性が保証されます。 
2. ACID プロパティの基本に従い、先行書き込みログ方式はデータの耐久性を確保し、効率的な方法での回復を可能にします。 
3. 主要な手続き型言語をサポートしているため、複雑なビジネス ロジックの開発が可能になります。 
4. PostgreSQL を使用すると、開発者はアプリケーションを簡単に構築し、OLTP 操作を効率的に実行することもできます。 

PostgreSQLはこれらをはじめとする素晴らしい機能を備えているにもかかわらず、特にアプリケーションのスケーラビリティにおいて、いくつかのボトルネックを抱えています。正確性と柔軟性を保証するアーキテクチャ上の決定、MVCCスナップショット、WALロギング、プロセスベースの同時実行性といった要素は、ワークロードが超高同時実行性、リアルタイム分析、シームレスな水平スケールアウトを要求する際には、パフォーマンスを制約し始めます。

PostgreSQLのスケーリングにおける5つの重要な問題点

「PostgreSQLデータベースがパフォーマンス限界に達している5つの兆候」というブログ記事では、PostgreSQLを使用したアプリケーションのスケールアップ時に発生するパフォーマンスのボトルネックについて簡潔に解説しています。では、実際のシナリオを用いて、アプリケーションがPostgreSQLのスイートスポットを超えてスケールアップした場合に何が起こるのかを具体的に見ていきましょう。

1. アクティブユーザーが少数のアプリケーションは正常に動作しますが、ブラックフライデーのセール期間中にアクティブユーザーが急増した際に、PostgreSQLで構築されたアプリケーションがクラッシュしました。その結果、ウェブサイトの読み込み速度が遅くなり、売上が落ち込み、サポートチームの業務が逼迫しました。これは、PostgreSQLのプロセス/接続モデルとロック機構がユーザー数の増加に比例して拡張できないために発生する、同時実行ボトルネックが原因でした。
2. ソーシャルメディアアプリケーションは、中規模ではスムーズに動作していました。しかし、ユーザーが複数のリージョンにまたがって追加された際に、スケーリングの壁にぶつかりました。話題の投稿は、一部のユーザーには即座に表示されましたが、他のユーザーには表示されなくなりました。これは、アプリがアクセスしたリードレプリカによって異なりました。PostgreSQLのレプリカ間のレプリケーション遅延は、グローバルワークロードによって発生しました。 
3. ある税務ソフトウェア会社は、数百万人の同時ユーザーを抱える税務シーズンのピークに対応するため、PostgreSQLを拡張しました。システムはシーズン中は正常に動作していましたが、残りの8ヶ月間は、高価なインフラの95%がアイドル状態でした。ストレージ、レプリカ、バックアップのコストが積み上がり、データベースは弾力的にスケールダウンできませんでした。
4. SaaSアプリケーションは、その上に高負荷の分析ダッシュボードを構築したところ、ひどい障害を起こしました。その結果、ログインが失敗し、分析ボードのデータの一貫性が失われ、頻繁にタイムアウトが発生しました。複雑な分析ワークロードを処理できなかったことが、障害の原因でした。 

要点は次のとおりです。PostgreSQLは小規模なアプリケーションではうまく機能しますが、大規模なワークロードや複雑な操作にスケールアップするとパフォーマンスが低下する可能性があります。アプリケーションにスケーラビリティが求められる場合、PostgreSQLはデータベースの第一選択肢ではありません。

企業の要件は新たなアプローチを要求する

今日のアプリケーションは、もはや夜間のバッチ処理に依存しません。リアルタイムデータを処理し、イベント発生時に運用監視と顧客分析を可能にします。これらのアプリケーションは、速度に加えて、大規模で複雑、かつ予測不可能なワークロードにおいても、低レイテンシのエクスペリエンスを提供する必要があります。

同時に、企業はリソースを無駄にすることはできません。キャパシティを容易に増減調整し、混雑時でもパフォーマンスを維持しながらコストを最適化できる柔軟なシステムが必要です。柔軟性に加え、グローバルビジネスでは、複数の地域にまたがって拡張可能なデータベースが必要です。これらのデータベースは、世界中のユーザーに対して、高速なレプリケーション、強力な一貫性、そして信頼性の高いフェイルオーバーを提供する必要があります。

エンタープライズアプリケーションの開発において、これらの要件が個別に存在することは稀です。通常は、これらが組み合わさって発生します。例えば、グローバルSaaSアプリケーションでは、リアルタイム分析、低レイテンシのインタラクション、コスト効率、そしてマルチリージョンサポートが同時に必要になる場合があります。これらの複合的なニーズを満たすことは、PostgreSQLのような従来のデータベースの限界を示し、新たなアプローチの必要性を浮き彫りにします。

SingleStoreがこれらの課題を解決する方法

SingleStore は、リアルタイムのパフォーマンス、柔軟なスケーラビリティ、ハイブリッド トランザクション、分析処理をサポートする、現代のワークロード向けに構築された分散データベースです。 

SingleStoreはUniversal Storageを基盤として構築されており、インメモリ行ストアとオンディスク列ストアのデータ形式を組み合わせることで、トランザクションと分析の両方のワークロードに最適化された単一のテーブルタイプを提供します。これにより、従来のモノリシックデータベースが抱えるボトルネックを解消します。 

SingleStoreは、スケールアウトを根本から考慮した設計により、エンタープライズ規模の課題に対処します。アグリゲータとリーフノードを備えた分散型シェアードナッシングアーキテクチャを採用しています。データは、ユーザー定義のキーまたはハッシュ戦略に基づいてリーフノード間で自動的にシャーディングされ、各シャード（パーティション）は、異なるノードにプライマリコピーとレプリカコピーを保持します。アグリゲータノードはスマートコーディネーターのように機能します。クエリはマスターアグリゲータによって受信され、マスターアグリゲータはサブクエリを関連するリーフパーティションに並列に展開します。 

そのため、アーキテクチャ上の利点を活かし、水平スケーリングを自動的にサポートします。ワークロードを処理するために、パーティションのバランスを自動的に調整します。 

いくつかのリアルタイムのエンタープライズ例を通して、SingleStore が PostgreSQL よりも効率的であることを理解しましょう。

1. ユニバーサルストレージ
2. ロックフリーの同時実行性
3. 高可用性と自動スケーリング機能
4. MVCC、ストレージ、耐久性

PostgreSQLはWrite Headロギングの概念を採用しており、単一ノードでクラッシュが発生した場合、WALエントリを再度実行する必要がある場合があります。一方、SingleStoreはログを即座に書き込みます。これにより、最新のレプリカセットが生成され、遅延やデータの不整合を回避できます。 

上記の例を通して、SingleStore の分散アーキテクチャとハイブリッドストレージモデルが、PostgreSQL でよく見られるエンタープライズボトルネックを解消する方法をご理解いただけたと思います。スムーズなトラフィックフロー、信頼性の高い高可用性レプリケーション、そして適応型スケーリングを可能にすることで、SingleStore は PostgreSQL が苦戦しがちな領域において、耐久性、拡張性、そして一貫した高いパフォーマンスを実現します。

次のセクションでは、データの整合性を損なうことなく、プロセスを効率的かつシームレスに実行する方法を示しながら、データを SingleStore に移行するための実用的な手法について説明します。

PostgreSQLからSingleStoreへの移行

移行を 4 つのステップに分けてみましょう。 

移行戦略

PostgreSQLからSingleStoreにデータを移行する際の最初のステップは、ダウンタイムの許容範囲とチームのキャパシティに基づいてアプローチを決定することです。これには3つの方法があります。 

1. 一括移行
2. ハイブリッド移行
3. デュアルマイグレーション

次のステップは、PostgreSQLスキーマ、ストアドプロシージャ、そして高負荷な本番環境クエリを評価し、計画することです。これにより、SingleStore上のデータをより適切かつ効率的に管理できるようになります。Postgresに対して使用される最も重要なクエリは保存しておくことをお勧めします。これらのクエリは、SingleStoreのデプロイメントに対する検証に使用できます。 

スキーマ変換

戦略が準備できたら、次のステップはPostgreSQLをSingleStore対応のDDLに変換することです。SingleStoreはMySQLと互換性があるため、BIGSERIALはBIGINT AUTO_INCREMENTに、jsonbはJSONに変換されます。配列はJSONまたは正規化された子テーブルに変換する必要があります。
例えば、次のようになります。

データの移行

戦略とテーブルが決まったら、まずは履歴データを移行します。一般的なパターンとしては、PostgresテーブルをCSVまたはParquetファイルにエクスポートし、クラウドオブジェクトストレージにアップロードします。そこから、SingleStoreパイプラインを使用して、すべてのノード間でデータを並列に一括取り込みできます。 

たとえば、次の例のようにパイプラインを作成して、データをロードするテーブルを作成します。

パイプラインがロードされたら、次のステップは、ユーザーがデータの書き込みを継続している間、PostgresとSingleStoreの同期を維持することです。これは通常、変更データキャプチャ（CDC）によって行われます。そのためには以下の手順に従います。

継続的な移行が行われるため、PostgreSQL と SingleStore 間のデータはリアルタイムで同期されます。 

次のステップは、SingleStore接続文字列を使用してアプリケーションを接続することです。例えば、Javaアプリケーションの場合は、以下のコードをアプリケーションコードに追加します。

詳細については、 「アプリケーション開発ツールへの接続」のドキュメントを参照してください。 

アプリケーションを MongoDB にデプロイしている場合は、SingleStore の Kaiを使用すると、上記のいずれも必要とせずに MongoDB ベースのアプリケーションを SingleStore に接続できる最も効率的な方法になります。 

移行後のチェックリスト

データが SingleStore に移動されたら、留意すべき重要な点がいくつかあります。 

• Postgres 固有のデータ型と機能を SingleStore の同等のものにマッピングすることで、スキーマの互換性を確保します。
• ワークロードのバランスを取り、データの偏りを回避するために、シャード キーとソート キーを慎重に定義します。
• 履歴用の一括ロードと継続的な同期用のパイプライン/CDC を使用して、データ移行戦略を計画します。
• アプリケーションとクエリを更新して、SingleStore の MySQL ワイヤ プロトコルで動作するようにします。
• 移行されたデータを検証し、SingleStore が本番環境で安定するまでロールバック プランを維持します。

結論

今日の世界では、エンタープライズアプリケーションに非効率性は許されません。PostgreSQLは初期段階のアプリケーションとしては間違いなく第一選択肢ですが、ビジネスが成長し、顧客の期待がリアルタイムで常時接続のエクスペリエンスを求めるようになると、ピーク時のダウンタイム、分析の遅延、インフラコストの急上昇など、PostgreSQLの限界がすぐに現れます。

SingleStoreはアプリケーションのボトルネックを解消します。トランザクションと分析を1つのエンジンに統合し、レプリケーションの遅延を排除し、ビジネスに合わせて柔軟に拡張できるため、データベースのパフォーマンス問題への対応ではなく、イノベーションの提供に集中できます。リアルタイムダッシュボードの強化から、世界中の何百万人ものユーザーへの遅延ゼロのサポートまで、SingleStoreは現代の企業が求めるスピード、スケール、信頼性を実現します。SingleStoreの詳細については、SingleStore Heliosの無料トライアルにご登録いただき、その可能性をご確認ください。大手企業がSingleStoreをどのように活用しているかについては、お客様成功事例をご覧ください。また、詳細については公式ドキュメントをご覧ください。