MySQLは最高のNoSQLシステムです

キーと値のペアの保存など、NoSQLの使用シナリオを見ると、パフォーマンス、使いやすさ、安定性の点でMySQLが望ましいことがわかります。 MySQLは、基本的な操作やエラー解析から複製、さまざまな使用パターンに至るまでのすべてのトピックを網羅した豊富なオンライン資料を備えた堅牢なシステムです。 これにより、MySQLはそのような経験のない若いNoSQLシステムよりも有利になります。



近年、NoSQLシステムが主流になりました。 多くの開発者は、MongoDB、Cassandra、Redis、HadoopなどのNoSQLシステムで、古いSQLシステムを減価させる単一の製品ファミリと見なして、アプリケーションを構築するための最良のオプションを認識しています。



多くの場合、NoSQLデータベースを使用する決定は、宣伝の誇大広告またはリレーショナルデータベースはNoSQLデータベースと同じパフォーマンスを提供できないという誤った信念に基づいています。 データベースの選択に関しては、技術者は運用コストだけでなく、技術の安定性と成熟度に関する考慮事項を見落としがちです。 さまざまなNoSQL（およびSQL）システムの制限と欠陥の詳細については、Aphyr.comで公開されているJepsenプロジェクトシリーズをご覧ください。



この記事では、MySQLを使用してキーと値のペアを保存する方が、ほとんどの特殊なNoSQLシステムよりも優れている理由を説明し、MySQLの使用手順も示します。

Wixサイトの定義

誰かがWixサイトのリンクをクリックすると、ブラウザはサイトアドレスとともにWixサーバーにHTTPリクエストを送信します。 これは、独自のドメイン（domain.comなど）を持つWixプレミアムWebサイトと、Wixサブドメイン（user.wix.com/siteなど）に無料のWebサイトがある場合です。 サーバーは、URLサイトペアのキーと値の検索を実行して、サイトアドレスで要求されたサイトを認識する必要があります。 次の説明では、URLを「ルート」として指定します。



ルートテーブルは、サイトアドレスをサイトオブジェクトに変換するために使用されます。 さまざまなパスを使用してサイトにアクセスできるため、多対1の関係があります。 サイトが見つかると、アプリケーションはそのサイトをダウンロードして操作します。 次に、サイトオブジェクトは複雑な構造を持ち、これには、サイトで使用されるさまざまなサービスである子オブジェクトの2つのリストが含まれます。 以下は施設のモデル例です。 ここでは、正規化された構造を持つ標準SQLデータベースが使用されると仮定します。







従来の正規化モデルでサイトを更新する場合、トランザクションを使用して複数のテーブルを更新し、データの整合性を確保する必要があります（トランザクションはデータベースレベルのロックを使用し、関連するテーブルからの同時書き込みや読み取りを防ぐことに注意してください）。 このようなモデルで作業を続けると、各テーブルのSERIALタイプのキー、外部キー、ルートテーブルのURLフィールドのインデックスにたどり着くでしょう。



ただし、正規化スキームに基づいたデータのモデリングには、多くの複雑な問題が伴います。



•ロックはテーブルへのアクセスを制限するため、大量のデータがあるとパフォーマンスが制限される可能性があります。

•オブジェクトを読み取るには、いくつかのSQLクエリ（この場合は4つ）またはJOINの使用が必要です。これは遅延時間にも影響します。

•SERIAL属性を持つキーにはロックが必要です。これも書き込みパフォーマンスを制限します。



これらの問題は、MySQL（または他のSQLシステム）が提供できる帯域幅とクエリの並列化を制限します。 これらの弱点と、本質的にキーと値のペアであるという事実により、多くの開発者は、安定性、整合性、可用性を犠牲にしても、パフォーマンスと並列化を向上させるNoSQLソリューションを探すことを好みます。



Wixでは、MySQLをキーと値のペアのストレージとして創造的に使用すると、正規化されたデータモデル（上記）を使用したMySQLよりも、ほとんどのNoSQLシステムよりも優れた動作をすることがわかりました。 現在のシステムは、スケーリング、帯域幅、クエリの並列化、遅延時間などのパラメーターを提供し、NoSQLシステムを尊重します。 システムの詳細は次のとおりです。



•3つのデータセンターへのアクティブインストール（active-active-active）。

•約200,000 RPMのスループット。

•ルートテーブルには、約1億件のレコード、10 GBのディスク容量があります。

•サイトテーブルには、約1億のレコード、200 GBのディスク領域があります。

•平均読み取り遅延は1.0〜1.5ミリ秒です（実際には、0.2〜0.3ミリ秒。1つのデータセンターで）。



遅延は約1.0ミリ秒であることに注意してください。 これは、クラウドシステムとオープンソースシステムの両方を含む、キーと値のペアで構築されたほとんどのシステムで印象的な指標と見なされます。 また、MySQL（一般的に信じられている最も単純なSQLシステム）を使用してこれを実現しました。



使用する回路は次のとおりです。

CREATE TABLE `routes` ( `route` varchar(255) NOT NULL, `site_id` varchar(50) NOT NULL, `last_update_date` bigint NOT NULL, PRIMARY KEY (`key`), KEY (`site_id`) ) CREATE TABLE `sites` ( `site_id` varchar(50) NOT NULL, `owner_id` varchar(50) NOT NULL, `schema_version` varchar(10) NOT NULL DEFAULT '1.0', `site_data` text NOT NULL, `last_update_date` bigint NOT NULL, PRIMARY KEY (`site_id`) ) /*ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=16*/;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クエリ条件として使用されていないすべてのフィールドは、blobタイプの単一フィールド（テキストフィールドsite_data）に縮小されました。 サブオブジェクトテーブルと、テーブルオブジェクト自体のフィールドが含まれます。 SERIALタイプのキーは使用せず、ユーザーが作成したGUID変数を含むVARCHAR（50）タイプのフィールドを使用することに注意してください（これについては次のセクションで説明します）。



以下は使用しているクエリです。帯域幅が広く、待ち時間が短いです。

 select * from sites where site_id = ( select site_id from routes where route = ? )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、ルートテーブルへのクエリは最初に一意のインデックスで実行され、クエリは1つの値のみを返す必要があります。 次に、主キーを使用してサイトを参照し、再び1つの値を探します。 ネストされた構文を使用すると、データベースへの1回の呼び出しで両方のSQLクエリを処理できます。



上記の結果には約1ミリ秒かかります。 高いトラフィックと高いリフレッシュレートの条件下での一貫した作業。 トランザクションを使用しない場合でも、半トランザクションの更新。 これは、1つのINSERTコマンドを使用してサイト全体を入力し、ルートにデータを入力するまで、リクエストがそれを検出しないために可能です。 つまり、最初にサイトに関するデータを入力し、次にパスに関するデータを入力すると、sitesテーブルのデータが接続されるまで、境界線の状況であってもデータの整合性に自信があります。



MySQLをNoSQLシステムとして使用するための手順

上記の例で得られた経験（およびWixプラクティスからの他の同様のケース）を使用して、MySQLをNoSQLシステムとして使用するための推奨事項の短いリストを作成しました。



MySQLをNoSQLシステムとして使用する際に覚えておくべき主なことは、データベースレベルのロックと複雑なクエリを回避することです。



•ブロックを伴うトランザクションを使用しないでください。 代わりに、アプリケーションでトランザクションを使用します。

•SERIALタイプのキーを使用しないでください。 このようなキーはブロックを伴い、アクティブ/アクティブビューの構成を複雑にします。

•顧客が作成した一意のキーを使用します。 GUIDを使用しています。



読み上げの構造を最適化する場合、いくつかの追加の推奨事項に注意してください。



•正規化を実行しないでください。

•フィールドがある場合-インデックスを作成する必要があります。 インデックスのフィールドが不要な場合は、BLOB / TEXTタイプの1つのフィールドに保存します（JSONまたはXMLとして）。

•外部キーを使用しないでください。

•リクエストに応じて別のシリーズを読むことができるように構造を設計します。

•ALTER TABLEステートメントを使用しないでください。 これらのコマンドは、ロックと一時的な非アクティブ期間を伴います。 代わりに、ライブ移行データ移行を使用してください。



データをリクエストする場合：



•主キーまたはインデックスでエントリを探します。

•JOINを使用しないでください。

•集約関数を使用しないでください。

•親ベースではなくレプリカで検証機能（BI、データマイニング）を実行します。

アプリケーションを介したライブマイグレーションのデータとトランザクションの転送について詳しく説明する別の記事を書く予定です。

あなたは新しい方法で考えることができます

おそらく、これがこの記事の最も重要な結論です。 MySQLをNoSQLシステムとして使用するのは素晴らしいことです。つまり、設計された方法ではありません。 この記事で示したように、例としては、MySQLを使用して、このために特別に設計されたNoSQLシステムの代わりにキーと値のペアを操作します。 WixでMySQLを選択したのは、キーと値のペア（だけでなく）を操作するためです。使いやすく、管理しやすく、素晴らしいエコシステムだからです。 おまけとして、ほとんどのNoSQLシステムよりも優れたレイテンシ、スループット、および並列化パフォーマンスを提供します。



Wixウェブサイトデザインのチーフアーキテクトデザイナー、

ヨアヴ・アブラハミ



元の記事： Wix Engineers Blog