MODX Revolutionのシステムテーブルの拡張（だけではありません）

現時点では、MODX Revolutionのニュースポータルを1つリメイクしています。 サイトへのトラフィックは1日あたり最大100,000人になる可能性があるため、ここでは生産性の問題が最も重要な問題の1つです。 現時点では、データベースに75,000を超える記事があり、間違った（および従来のMODX開発アプローチでも）サイトブレーキがほぼ保証されていることを考慮し、訪問の頻度がクエリ実行時間を超えると、サーバーは通常ダウンします。 ここに、これらの問題を解決するために関連する技術の一部を示します。この記事で説明します。

1.長いキャッシュの生成。

確かに多くの人々は、MODXキャッシュを更新すると、すべてのドキュメントを調べ、リソースマップをコンテキストキャッシュに詰め込むことを知っています。 誰かが知らない場合、私はそれについてここに詳しく書いた。 また、バージョン2.2.7（またはその領域）以降のMODXでは、設定（ cache_alias_mapシステム設定）でリソースマップキャッシュを無効にすることができますが、この問題は部分的にしか解決しません-MODXはドキュメントURLをキャッシュしませんが、ID構造には関係ありません。データベースからすべてのドキュメントをソートします。 これにより、第一に、コンテキストキャッシュファイルが大きくなり、第二に、スクリプトが30秒で実行に失敗し、キャッシュファイルが破損する可能性があり、致命的なエラーが発生し、サイトが動作不能になる可能性があります。



ただし、サーバーがすべてのドキュメントをプルし、キャッシュ内のすべてを埋めることができる場合でも、異なる設定を持つ1つのリクエストの比較数値を見てみましょう。 多くの場合、サーバーの設定と異なるサーバーによって同じサイトのメモリ消費量が異なるため、これらの数値は非常に相対的なものになりますが、比較すると、これらの数値から状態の違いがわかります。 メモリ消費量を推定するために、getdataプロセッサーを呼び出して10個の記事を受け取ります。



そのため、 オプション1：リソースマップの完全なキャッシュが有効になります。

コンテキストキャッシュファイルのサイズ：5,792,604バイト。

要求に応じたメモリ消費：28.25 Mb

時間：0.06-0.1秒

オプション2：リソースマップのフルキャッシュは無効です（システム設定cache_alias_map == false）。

コンテキストキャッシュファイルのサイズ：1,684,342バイト。

要求メモリ消費量：15.5 Mb

時間：0.03-0.06秒

オプション3： cacheOptimizerパッチを使用したリソースマップのキャッシュを完全に無効にします。

コンテキストキャッシュファイルのサイズ：54,945バイト。

要求メモリ消費量：4.5 Mb

時間：0.02-0.03秒

そして、それはたった75,000のリソースです。 数十万人では、違いはより顕著になります。



ここには確かに欠点があります。 たとえば、Wayfinderは機能せず、エイリアスマップデータに基づいてメニューが作成されます。 ここでは、メニュー自体を収集する必要があります。 ほとんどの場合、 ここで書いたメニュープロセッサを使用します（セクション2.ウェイファインダーの交換を参照 ）。

2.ドキュメントのTVパラメータによるパフォーマンスの低下。

しかし、これがこのトピックを書く主で最も興味深い理由です。 おそらく、 TVの TVフィールドを使用しないMODX開発者は一人もいないでしょう。 これらは、2つの問題を一度に解決します。1。カスタムフィールドをドキュメントに追加する、2。フィールドのタイプに応じて編集するための異なるインターフェイスを提供する。



しかし、それらには深刻なマイナスがあります-それらはすべて1つのテーブルに格納されます。 これにより、いくつかの問題が一度に追加されます。



1.データベースレベルで値の一意性を制御することはできません。



2. TVフィールドごとに異なるデータ型を使用することはできません。 TVフィールドのすべてのデータは、データタイプmediumtextの単一の列値に含まれています 。 つまり、より多くのデータを使用することはできず、数値は小文字で格納され（並べ替えを伴うクエリの形成に追加の要件が課されます）、異なる列のデータをfeng shuiと比較せず、セカンダリキーとこれにより、もっと多くの不快なことが起こります。



3.複数のテーブルからフェッチするときのパフォーマンスが低下します。 たとえば、1つのドキュメントには複数のTVフィールドがあり、そのうち少なくとも2〜3個のフィールドはほとんど常に入力されています。 リクエストでデータやドキュメント、フィールドをすぐに受け取りたいです。 このリクエストを生成するための2つの主なオプションがあります。



1. TV shekテーブルに参加するだけです。

$q = $modx->newQuery("modResource"); $alias = $q->getAlias(); $q->leftJoin("modTemplateVarResource", "tv", "tv.contentid = {$alias}.id"); $c->select(array( "tv.*", "{$alias}.*", ));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、深刻なマイナスがあります。結果のテーブルでは、C * TVがレコード数を取得します。Cはsite_contentのレコード数、TVは各ドキュメントのsite_tmplvar_contentvaluesテーブルのレコード数です。 つまり、たとえば、ドキュメントのレコードが100個あり、各ドキュメントにテレビレコードが3個ある場合（平均）、合計で100 * 3 = 300個のレコードを取得します。



このため、結果として、ドキュメントごとに複数の結果レコードがあったため、PHPレベルでは、受信したデータを追加処理して一意のデータを生成する必要があります。 これはgetdataプロセッサでも行われます 。 また、負荷が増加し、実行時間が長くなります。



このニュースポータルでは、ドキュメントごとに平均3つのメインエントリがありました。 その結果、最大225,000のテレビ録画。 クエリの最適化を行っても、条件付きの実行には1〜4秒かかり、非常に時間がかかりました。



2.各TVフィールドに個別に参加します。

サンプルリクエスト：

 $q = $modx->newQuery("modResource"); $alias = $q->getAlias(); $q->leftJoin("modTemplateVarResource", "tv1", "tv1.tmplvarid = 1 AND tv1.contentid = {$alias}.id"); $q->leftJoin("modTemplateVarResource", "tv2", "tv2.tmplvarid = 2 AND tv2.contentid = {$alias}.id"); // ......... $c->select(array( "tv1.value as tv1_value", "tv2.value as tv2_value", "{$alias}.*", ));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果のテーブルにはドキュメントレコードと同じ数のレコードがあるため、このようなリクエストはより高速に処理されますが、レコード数が数十万から数十万になり、TV shekの数が10を超えると、負荷は小さくなりません（各TVラックにはさらにテーブルが1つ追加されています）。



この場合の最善のオプションは、TV値をsite_contentシステムテーブル自体に格納することです。つまり、各値はこのテーブルの個別の列に格納されます。



これがピットCRCのトピックに関する次のレッスンであると考えている場合、これは完全に真実ではありません。 従来、利用可能なクラスを独自のもので拡張し、必要な列を追加する（または独自のテーブルを作成する）ことも教えられていました。 しかし、このパスは最適ではありません。 ここでの主な問題は、何らかの方法でクラスを拡張することですが、自分でクラスを変更しないことです。 拡張は、拡張可能な（拡張可能ではない）クラスと、クラスを拡張する拡張クラスのみに関係します。 紛らわしいが、言うのは難しい。 説明します。 基本クラスmodResourceがあります。 modDocument、modWebLink、modSimLinkなどのクラスはそれを拡張します。 それらはすべてmodResourceマップマップから継承します。 modResourceクラスをクラスで拡張すると、クラスに新しい列が追加されますが、クラスは拡張されないため、modDocumentクラスには含まれません。 すべての拡張modResourceクラスに新しい列に関する情報を表示するには、この情報がmodResourceクラス自体に含まれている必要があります。 しかし、システムファイル自体に触れずにこれを行う方法は？..実際、2年以上前にこのことについて部分的に書きました（記事をここに移動しました ）が、今では戦闘モードで実装されています。 これを行います：



1. extensionPackageとしてロードされる新しいコンポーネントを作成します（詳細については、 こちらを参照してください ）。



2. phpMyAdminなどを使用して、site_contentテーブルに新しい列を作成します。



3. CMPGeneratorを使用して、site_contentテーブルのマップを含む個別のパッケージを生成します。 このマップには、新しい列とテーブルの説明があります。



4.メタデータ.mysql.phpファイルのパッケージに、列とインデックスのデータを書き込みます（このようなファイルの例は、ShopModxBoxアセンブリでも確認できます）。

注意深く読んでください。 2つの列と1つのインデックスに関する情報をsite_contentテーブルに追加します。



列が本当に追加されたことを確認しましょう。 コンソールでこのコードを実行してみましょう：

 $o = $modx->newObject('modDocument'); print_r($o->toArray());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この結果が表示されます。

 Array ( [id] => [type] => document [contentType] => text/html [pagetitle] => [longtitle] => //      //       [article_type] => [image] => )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、カスタムフィールドを使用してシステムテーブルを操作できます。 たとえば、次のように書くことができます。

 $resource = $modx->getObject('modResource', $id); $resource->article_type = $article_type; $resource->save();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちの価値は、このドキュメントの表に書かれています。

純粋なMODXで独自の列とインデックスを作成します。

このアプローチでは、テーブルにカスタムフィールドとインデックスがないため、このようなカスタムサイトから純粋なMODXに移行する問題があることは明らかです。 しかし実際には、これはまったく問題ではありません。 実際、テーブルからマップを生成すると、クラスのマップ記述からテーブル、列、およびインデックスを作成できます。 列またはインデックスの作成は非常に簡単です。

 //       $manager = $modx->getManager(); //   $manager->addField($className, $fieldName); //   $manager->addIndex($className, $fieldName);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、名前以外の列とインデックスのデータを指定する必要はありません。 XPDOはこのデータをマップから取得し、説明された列またはインデックスを作成するときに使用します。



コンポーネントを通常のインストールパッケージにアセンブルする場合は、スクリプトを直接登録して、パッケージをインストールするときにカスタム列とインデックスがテーブルにすぐに作成されるようにすることができます。

ドキュメントを編集するときに、TVフィールドでカスタムデータをレンダリングします。

上で述べたように、TVシェックの便利さは、さまざまなコントロール要素（テキストフィールド、ドロップダウンリスト、チェックボックス、ラジオボックスなど）が作成されることです。 さらに、ネイティブフォームエディターでは、特定のTVフィールドに対する権利を区別できるため、支払われていない人はプライベートフィールドを表示/編集できません。 実際、本当に必要な場合は可能ですが、プライベートフィールドは痕跡のない人にとって目障りではありません。 そうしないと、このデータを管理するために独自のインターフェイスを見つけ出す必要があり、これは非常に面倒です。 それでも、このようなデータの編集にはネイティブリソースエディターを使用したいと思います。 ここには理想的なメカニズムはありませんが、あまり適切ではないオプションを作成しました。 その意味は、プラグインレベルでドキュメント編集フォームをレンダリングするときにTVフィールドをそのカスタム値に置き換え、ドキュメントを保存するときにTVチャネルデータをインターセプトし、このデータをカスタムフィールドに保存することです。 残念ながら、ここにあるようにウェッジすることはできません（単にAPIで許可されていないため）。したがって、ドキュメントプロセッサに送信されるデータに影響を与えることはできません。ドキュメントを保存した後、このプレートを自動的にクリーニングします。 3つのイベントで動作するプラグインの例を次に示します（1. TVフィールドの置換とカスタムデータを使用したドキュメント編集フォームのレンダリング、2。データの受信と保存前のドキュメントオブジェクトの変更、3。不要なデータのクリーニング）



このプラグインのおかげで、カスタムデータはドキュメント編集フォームにレンダリングされ、保存時に処理されます。

まとめ

追加フィールドのテーブル内の225以上のエントリのうち、78個のみが残っています。もちろん、すべてのテレビがシステムテーブルに表示されるわけではなく（ただし、検索と並べ替えに使用されるテレビのみ）、一部のデータは確かにテレビフィールドのテーブルにありますが、負荷それにもかかわらず、それは大幅に減少し、リクエストはより簡単になりました。



UPD： TVをレンダリングおよび処理するためのより汎用性の高いプラグイン 。