PHP開発者向けのPHP + Java、またはインメモリクラスター

イントロ

PHP + Java。 ここから写真を撮ります。



「毎日コードを書く」という記事のこの解説で、私はプロジェクトをすぐに見せて、毎日1時間（週末を除く）を割り当てたと言いました。 最近、私の仕事はインメモリデータグリッド（IMDG）をデータウェアハウスとして使用する分散Javaアプリケーションの作成に関連しており、私のプロジェクトはこれに関連しています。



IMDGの詳細については、以前の記事（ 1、2 ）をご覧ください。 しかし、要するに、これはキーによるオブジェクトのクラスター分散ストレージであり、すべてのデータをメモリに保持するため、データへの高速アクセスが実現されます。 クラスターから抽出せずにデータを保存するだけでなく、処理することもできます。

また、各具体的なIMDGにデータ処理用の独自のインターフェイスがある場合、データアクセスインターフェイスは通常ハッシュテーブルと同一です。

この記事について

ほとんどのIMDGはJavaで記述され、Java、C ++、C＃のAPIをサポートしていますが、Webプログラミング言語（Python、Ruby、PHP）のAPIはサポートされておらず、クライアントを記述するためのプロトコルは非常に制限されています。 私がIMDGの大衆への浸透の主な障害であると考えるのはこの事実です-最も一般的な言語のサポートの欠如。



IMDGメーカーはまだWeb言語のサポートを提供していないため、Webプログラマーは、Javaサーバー開発者ほど簡単にアプリケーションをスケーリングすることができません。 したがって、IMDG JBoss Infinispan（Red Hatが所有するJBoss会社はJava開発者のサークルでは非常によく知られています）として、私は同様のことを自分で行ってオープンソースに入れることにしました。 私のプロジェクトはSproot Gridと呼ばれ、これまでのところPHPでのみ利用可能ですが、コミュニティが興味を持っている場合は、RubyとPythonも統合します。



この記事では、インメモリデータグリッドと、Sprootグリッドの構成、実行、使用方法について再度説明します。

IMDGが必要な理由

負荷の高い多くのプロジェクトのボトルネックは、データウェアハウス、特にリレーショナルデータベースです。 従来のデータベースの欠点を克服するために、主に2つのアプローチが使用されます。



1）キャッシュ

プラス ：

• 高速データアクセス

短所 ：

• 実際のクラスタソリューションは非常にまれであり、ほとんどの場合、ユーザーはサーバー間でのデータの分散を処理する必要があり、データにアクセスするときは、このデータがあるサーバーを特定します。 このようなシステムでは、すべてのクラスターノードの占有率を均一にすることは困難です。
• データの関連性とアクセス速度の間の妥協が必要です。 キャッシュ内のデータが古くなる可能性があり、キャッシュから古いデータを削除してから新しいデータをキャッシュすると、追加の遅延とシステム負荷が発生します
• 通常、データはアプリケーションで使用されるドメインオブジェクトの形式ではなく、BLOBまたは文字列の形式でキャッシュされます。 キャッシュから取得したデータを使用する場合、最初に必要なオブジェクトを構築する必要があります

2）NoSQLソリューション

プラス ：

• 優れた水平スケーラビリティ

短所 ：

• ディスクを使用する場合、それほど速くない結果
• 特定のリレーショナルデータベースでの作業に焦点を当てた社内ソフトウェアの動作を保証することはほとんど不可能です

IMDGは、両方のアプローチの利点を組み合わせたものであると同時に、上記のソリューションに対していくつかの利点があります。

1. 優れた水平スケーラビリティ
2. 高速アクセス
3. 真のクラスタリング（任意のノードにデータを置くことができ、クラスターの任意のノードにデータを要求することもできます）、ノード間のデータの自動バランシング
4. クラスターはオブジェクトのすべてのフィールドを認識しているため、キーだけでなくフィールド値でもオブジェクトを検索できます
5. フィールドまたはそれらの組み合わせによってインデックスを作成することが可能です
6. リードスルーおよびライトビハインド（またはライトスルー）メカニズムを使用する場合、データはデータベースと同期され、他のアプリケーション（または他のアプリケーションモジュール）が従来のデータベース（MySQLまたはMongo-関係ありません）を使用し続けることができます
7. 前の段落の作業スキームを使用すると、キャッシュ内のデータを更新する問題がなくなります。 それらは常にデータベースと同じです

これら2つの興味深いメカニズムを詳しく見てみましょう：リードスルーとライトビハインド（ライトスルー）

リードスルー

リードスルーは、リクエスト中にデータベースからデータをプルできるメカニズムです。

たとえば、キャッシュからキー ' key 'を使用してオブジェクトを取得し、クラスターにそのようなキーを持つオブジェクトがない場合、このオブジェクトはデータベース（またはその他の永続ストレージ）から自動的に読み取られ、キャッシュに入れられますリクエストへの応答として返されます。

データベースにそのようなオブジェクトがない場合、nullがユーザーに返されます。

当然、必要なSQLクエリと、クエリ結果のオブジェクトへのマッピングは、ユーザーの肩にかかっています。

ライトビハインド（ライトスルー）

書き込み速度を最適化するために、データベースではなく、直接キャッシュに書き込むことができます。 一見奇妙に聞こえますが、実際にはデータベースの負荷を軽減し、アプリケーションの速度を向上させます。

次のようになります。

1. ユーザーはcache.put（key、value）を呼び出します。オブジェクト ' value 'はキー ' key 'によってキャッシュに保存されます
2. このイベントのハンドラーはクラスターでトリガーされ、sql-requestはデータベースにデータを書き込むためにコンパイルされ、その実行
3. 管理がユーザーに返されます

この相互作用スキームはライトスルーと呼ばれます 。 クラスター内の更新と同時にデータベースと更新を同期できます。 ご覧のとおり、このアプローチはデータの書き込みプロセスを高速化しませんが、キャッシュとデータベース間のデータの一貫性を保証します。 また、このタイプのレコードでは、データはキャッシュに送られます。つまり、それらへの読み取りアクセスはデータベース要求よりも高くなります。



データベースへの同時書き込みが重大な条件ではない場合、より一般的な後書きメカニズムを使用して、データベース（他のサービス）への保留中の書き込みを整理できます。 このようなもの：

1. ユーザーはcache.put（key、value）を呼び出します。オブジェクト ' value 'はキー ' key 'によってキャッシュに保存されます
2. 管理がユーザーに返されます
3. しばらくすると（ユーザー設定可能）、キャッシュ書き込みイベントハンドラーが起動します
4. ハンドラーは、前のハンドラー以降に変更されたオブジェクトのパック全体を収集します
5. パックは記録のためにデータベースに送信されます

後書きを使用する場合、ユーザーは更新がデータベースに到達するまで待機せず、データをキャッシュに入れるだけなので、書き込み操作は大幅に加速されます。同じオブジェクトのすべての更新は、データベースへの書き込み中に1つの結果更新にマージされますデータベースサーバーの読み込みにもプラスの影響を与えるパック

したがって、3秒ごと（2分または50ミリ秒）にすべてのデータ更新がデータベースに非同期的に送信されるようにIMDGを構成できます。

これはSprootグリッドにありますか？

最初のバージョンでは、上記で説明したすべてをすぐに実装しないことにしました。 時間がかかりますが、ユーザーからすぐにフィードバックを得たいと思います。

したがって、Sproot Grid 1.0.0で利用可能なもの：

1. クラスターノード間でデータ量のバランスをとる水平スケーラビリティと公平なクラスタリング
2. 組み込みのPHPタイプとドメインオブジェクトの両方を保存する機能
3. フィールドごとにインデックスを作成し、このインデックスで検索する機能

はじめに

まず、ここから配布パッケージをダウンロードし、解凍する必要があります。

必要なソフトウェアをインストールする

JBoss InfinispanはJavaアプリケーションであるため、JavaとPHPの間の対話方法を選択する必要がありました。 Apache Thriftはそのようなリンクとして選択されました（プロトコルは、Cassandraのノード間のシリアル化とトランスポート用に開発されました）。したがって、Sproot Gridがシステムで動作するには、以下をインストールする必要があります。

• Java
• Thrift-本番環境でのインストールは不要です。インストールは開発マシンでのみ必要です（詳細については、 コードの生成を参照してください）。 本番環境にデプロイする場合、Thriftライブラリの.phpファイルとjavaライブラリを.jar形式でコピーするだけです
• PHP（まだインストールされていない場合）

インストール手順はプロジェクトwikiにあります

構成

構成ファイルは$ deploymentFolder / sproot-grid / config / definition.xmlにある必要があります。ここで、deploymentFolderはディストリビューションを解凍したディレクトリへのパスです



プロジェクトwikiで構成について詳しく読むことができます。



設定からわかるように、オブジェクトのタイプごとにキャッシュの名前を書き込むことができます（または、そのようなオブジェクトを別のキャッシュに保存したくない場合は登録できません）。 キャッシュはクラスター全体に分散されたハッシュテーブルであり、クラスター内にはできるだけ多くのキャッシュが存在する可能性があります。 1つのキャッシュに保存できるのは、同じタイプのオブジェクトのみです。

すべてのキャッシュについては、<caches />セクションで説明する必要があります。

この構成には、クラスター構造とその中に保存されるキャッシュのリストを説明するための個別のセクションがあります。



<datatypes /> -クラスターに保存されるタイプの説明。 組み込みのPHPタイプとカスタムタイプの両方を使用できます。 ご覧のとおり、オブジェクトの種類ごとにキャッシュの名前を書き込むことができます（または、そのようなオブジェクトを別のキャッシュに保存したくない場合は登録できません）



<cluster /> -クラスター構造の説明と、そこに保存されるキャッシュのリスト。

<caches />はキャッシュについて説明します。 キャッシュ名は一意である必要があります。backup-countパラメーターは、データを失うことなく失うことができるクラスター内のノード数を決定します。 バックアップカウントが重要になるほど、クラスターの信頼性は高まりますが、消費するメモリが増えます。 エビクション（キャッシュからのオブジェクトの自動削除）を構成することもできます。これについては、Wikiページで詳しく説明します。

<multicast />は、クラスターの構築に使用されるマルチキャストアドレスを定義します。 ご存知のように、マルチキャストではクラスDネットワークのみが利用可能です（224.0.0.0-239.255.255.255）

<nodes />は、クラスターノードの数と種類を示します。 現在、ノードには2種類しかありません： ストレージのみ -データストレージと内部サービスリクエストのみを処理します-データを保存するだけでなく、外部リクエストも処理するため、このタイプのノードでは、PHPクライアントからのリクエストを受信するポートを指定する必要があります。

アプリケーションと統合するためのコード生成

効率的な操作のために、クラスターはアプリケーション（ドメインモデル）に固有のコードを生成し、そのJava部分をコンパイルする必要があります。 必要なすべてのコードを生成してコンパイルするには、次のことを行う必要があります。

  1) cd $deploymentFolder/sproot-grid/scripts 2) build.sh(or build.cmd)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

$ deploymentFolderは、ディストリビューションを解凍したディレクトリです

コード生成は、ドメインモデルの説明が変更された場合にのみ行う必要があります。 モデルが安定している場合は、この操作を1回だけ実行する必要があります。その後、生成されたphpソースをコードリポジトリに保存し、Javaパーツをライブラリにコンパイルします。 つまり アプリケーションをデプロイする前に何も生成する必要はありません。これは開発段階で1回だけ行われます。

コード生成が完了したら、$ deploymentFolder / sproot-grid / php / orgからアプリケーションのルートに.phpファイルを含むフォルダーをコピーします

打ち上げ

  1) cd $deploymentFolder/sproot-grid/scripts 2) run.sh(run.cmd) nodeId memorySize
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

nodeIdは、構成ファイル内のセクションのid属性の値です。

memorySize-ノードに割り当てるメモリの量（MBまたはGB単位）



例：

 run.sh 1 256m
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または

 run.cmd 2 2g
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーション内で使用する

コード生成のステップでは、アプリケーションと統合するために必要なすべてのものを手に入れました。 このコードをアプリケーションにコピーするだけです。このため、$ deploymentFolder / sproot-grid / phpフォルダーからアプリケーションのルートにすべてをコピーします

それだけです！ これで、アプリケーションからクラスターを使用できます。



APIの説明はここにありますが、要するに、APIは次のようになっています。

• get（$ cacheName、$ key）
• getAll（$ cacheName、配列$キー）
• cacheSize（$ cacheName）
• cacheKeySet（$ cacheName）
• containsKey（$ cacheName、$ key）
• 検索（$ cacheName、$ fieldName、$ searchWord）
• 削除（$ cacheName、$キー）
• removeAll（$ cacheName、配列$キー）
• put（$ cacheName、$ key、$ domainObject）
• putAll（$ cacheName、配列$ domainObjects）
• clearCache（$ cacheName）

おわりに

Sproot GridはMITライセンスの下で公開されています。

ソースコード

Wiki

配布