ミドルウェアの恐怖と嫌悪

phpが私たちを克服したとき、私たちはJavaScriptの近くにいました。 次のようなことを言ったことを覚えています。私の頭が回転しています。 たぶんあなたはプロジェクトを持っている方が良いでしょう。



突然、私たちの周りにひどいブームがありました...そして、ウェブ全体がLAMPに関するこれらの記事でいっぱいでした...
どんなニーズにも対応できるように書かれているようです。 perl、bash、さらにはCでさえ使用していたタスクを成長させ、吸収しましたが、これらの記事について話す意味はありません。 誰もがすでにそれを知っています。

5番目のIE、少しのNetscape、Opera、およびperlの雑多なcgiモジュールがありました。 必要な技術スタックではなかった。 しかし、もしあなたがナンセンスを集め始めたら、止めるのは難しくなります。 私が心配していたのはPHPを使用している学生だけでした 。 これほど無力で無責任で甘やかされているものはありません。 遅かれ早かれ、このゴミに進むことを知っていました。

最初はそうではなかった

ブラウザ間のJSがコルクの馬のように異なり、XMLHttpRequestはActiveXを介してのみ可能でした。 あまり道はありませんでした。 ダイナミックWebを削減したもの。 IE 6は革命のように見えました。 しかし、クロスプラットフォームが必要な場合は、膨大なミドルウェアをパスしました。 php、ツール、および関連する新しいライブラリに関する多数の記事がその役目を果たしました。

ひどいPHPで、古いアイルランドの小説に酔った国、基本的な運動機能の完全な喪失、視界のぼやけ、木製の舌、恐怖の脳のように振る舞います。 すべてを見ることができるが、何も制御することができない面白い状態。 データがどこにあり、どこにロジックがあり、どこに表現があるかを明確に把握して、タスクにアプローチします。 しかし、その場で、すべてが間違っています。 あなたは邪悪な麺のコードに混乱していて、あなたは思う：何が問題なのか、何が起こっているのか？...

徐々に、ブラウザ間のタイタニックプレートが収束し始めました。 XMLHttpRequestはどこにでも登場し、フロントが明確に分離された動的なWEBの夢が現実になりました。

もちろん、私は流行の犠牲になりました。 手に入れたものすべてを研究した普通のストリートローファー。 Web開発用の単一言語についてのアイデアが空中にありました。 待って、あなたは新しい装いでこれらの変化を見るでしょう、男。
-Node.jsを見てみましょう。
-何？ いや！
「ここで止めることはできません。」 これは太った中間です。
-座って。
どのようなナンセンスがねじれていますか。フロントエンド、ミドルエンド、バックエンドの類似性を見つけるためにJavaScriptでどれだけ書く必要があるのか​​わかりませんか？ これは良い選択肢ではありません。 選択したターゲットには厚すぎます。


しかし、私はそのような考えを残しました。 ドライバーで釘を打つことができることを理解するようになりましたが、時々ハンマーに手を差し伸べると、プロセスが大幅に加速します。

私は全体の状況に対して恐ろしい抗議を感じました。

PostgreSQLなどのDBMSがあり、組み込み関数を使用して信じられないほどデータを操作できます。 ベース内のビジネスロジック！ 実際のバックエンド。 DBMSのビジネスロジックが気に入らず、そこに属していませんか？ このような直接データストリームが好きですか？


喫煙者の「直接的な」流れに関するデータの厄介な動きを把握してみましょう。

最初に遭遇するのは、何らかの理由でデータが途中で絶えず蒸留されることです。 さらに、このデータは最終的なものではなく、後続のリクエストの計算にのみ必要です。 データ処理にはサイクルが使用されます。 手続きサイクル-マルチスレッド用に最適化されていません。

DBMSへの1つのセッションでのクエリの多様性は、速度の終miseという避けられない仮説につながります-データベーステーブルのマルチパス。



これらの要因を排除するには、ロジックをデータに近づける必要があります。 DBMSで！
そして、これは速度を新しい価値にもたらす最も最適な方法です！

アイデアの形成

時間の経過とともに、ブラウザはインターフェイスの完全な動的生成を学習しました。 データとプレゼンテーションの面で明確な分離が達成されました。 主にサーバーからクライアントにデータを送信する本格的な機会がありました。 質問は1つだけでした。中間層で何をするかです。 サーバー側でコレクションのリクエストを単純にルーティングする要素を使用して、トランスポート機能のみにそれを最小化する方法。

これらの素朴な開発者は、古いミドルの拠点の1つを研究することで、安心と理解が得られると信じていました。その結果、IT業界の主要な、古い世界の間違いを理解していなかった厚いレイヤーが生成されました。 誰かまたは何かが致命的な欠陥を持っているかもしれないという信念を失います。
その時までに、nginxは機能し始め、提案された思考を準備するための質問はもうありませんでした。 それはもはや考えではありませんでした。 今では怠programmerなプログラマーコンテストでした。 apacheを介して伝統的な方法でアーキテクチャを何らかの形で説明しようとするというアイデア自体は、ばかげているように見えました。

2010年に、 ngx_postgresモジュールがgithubに到着しました。 設定ファイルでリクエストを指定し、JSON / CSV / WELLで発行します。
構成には、単純なSQLコードで十分でした。 複合体を関数にラップし、構成から呼び出すことができます。

しかし、このモジュールは、http要求の本文をDBMSにロードできませんでした。 サーバーに送信されるデータに重大な制限が課されました。 URLは明らかに、リクエストのフィルタリングにのみ適していました。
出力データのシリアル化は、モジュール自体を使用して実行されました。 それは、私のソファの高さから、RAMの無意味な翻訳のように思えた-PostgreSQLもシリアライズできた。
修正、書き換えるというアイデアがありました。 私はこのモジュールのコードを掘り始めました。

眠れぬ夜を探した後、ngx_postgresは多くの人にとって十分でしょう。 もっと強力なものが必要でした。
マダム、サー、ベイビー、その他何でも ... ... ngx_pgcopyを保持するオプションがあります。

NGX_PGCOPY

実験の実験と分析の分析の後、実用的なすべてをゼロから書き直すというアイデアが生まれました。 ロードを高速化するために、 COPYクエリが選択されました。これは、挿入よりも1桁高速にデータをデータベースに転送し、独自のパーサーを含みます。 残念ながら、このタイプのクエリの記述が不足しているため、このメソッドの特に大規模な呼び出し中にDBMSがどのように実行するかを言うのは困難です。

世界はあらゆる方向に狂っていて、いつでもあなたは絶えずそれに出くわします。 しかし、私たちがしたすべてのことの正確さについて、驚くほど普遍的な感覚がありました。

COPYリクエストと一緒に、CSVで双方向のシリアル化を自動的に受信したため、データ変換の懸念がなくなりました。

URLでCSVのテーブル全体を送受信するプリミティブから始めましょう。
http://some.server/csv/some_table

CSVパーツimport.export.nginx.conf

 pgcopy_server db_pub "host=127.0.0.1 dbname=testdb user=testuser password=123"; location ~/csv/(?<table>[0-9A-Za-z_]+) { pgcopy_query PUT db_pub "COPY $table FROM STDIN WITH DELIMITER as ';' null as '';"; pgcopy_query GET db_pub "COPY $table TO STDOUT WITH DELIMITER ';';"; } 

PostgreSQLは現在、COPY STDINを介してJSONおよびXMLを作成できません。 象のコードスタイルのタブを使用した謙虚な日が来て、私、または誰かのスレッドが時間を見つけて、この機能をCOPYメソッドにねじ込んでくれることを願っています。 さらに、これらの形式の処理はすでにDBMSに存在します。

しかし！ ここでも今でもそれを使用する方法があります！ 次にリクエストで変数$ request_body_fileを使用してpg_read_binary_file関数に渡すことで、nginxをclient_body_in_file_onlyに設定します...
もちろん、次のようにCOPYメソッドでこれをラップする必要があります ngx_postgresのbody_rejectaが完全であるため、モペットでのみ機能します。 私はまだ他のモペットに会っていないし、ngx_pgcopyは追加機能のためにまだ成熟していない。

import.export.nginx.confでjson / xmlがどのように見えるか見てみましょう

 client_body_in_file_only on; client_body_temp_path /var/lib/postgresql/9.6/main/import; location ~/json/(?<table>[0-9A-Za-z_]+) { pgcopy_query PUT db_pub "COPY (SELECT * FROM import_json_to_simple_data('$request_body_file')) TO STDOUT;"; pgcopy_query GET db_pub "COPY (SELECT '['||array_to_string(array_agg(row_to_json(simple_data)), ',')||']' FROM simple_data) TO STDOUT;"; } location ~/xml/(?<table>[0-9A-Za-z_]+) { pgcopy_query PUT db_pub "COPY (SELECT import_xml_to_simple_data('$request_body_file') TO STDOUT;"; pgcopy_query GET db_pub "COPY (SELECT table_to_xml('$table', false, false, '')) TO STDOUT;"; } 

はい、client_body_temp_pathをデータベースディレクトリに設定する必要があり、ユーザーにはALTER SUPERUSERを与える必要があります。 そうでなければ、Postgresは私たちの欲望を地平線を越​​えて送ります。
GETメソッドで提供されるエクスポートは、標準のPostgresパッケージに含まれている組み込み関数を使用します。 これらのアクションの結果をクライアントに通知する場合に備えて、すべてのCOPYがSTDOUTに表示されます。 固定テーブル（simple_data）へのインポートはエクスポートよりも少し大きく見えるため、ユーザー定義のDBMSプロシージャで削除されます。

固定テーブルへのインポート用の1.import.export.sqlの一部

 CREATE OR REPLACE FUNCTION import_json_to_simple_data(filename TEXT) RETURNS void AS $$ BEGIN INSERT INTO simple_data SELECT * FROM json_populate_recordset(null::simple_data, convert_from(pg_read_binary_file(filename), 'UTF-8')::json); END; $$ LANGUAGE plpgsql; CREATE OR REPLACE FUNCTION import_xml_to_simple_data(filename TEXT) RETURNS void AS $$ BEGIN INSERT INTO simple_data SELECT (xpath('//s_id/text()', myTempTable.myXmlColumn))[1]::text::integer AS s_id, (xpath('//data0/text()', myTempTable.myXmlColumn))[1]::text AS data0 FROM unnest(xpath('/*/*', XMLPARSE(DOCUMENT convert_from(pg_read_binary_file(filename), 'UTF-8')))) AS myTempTable(myXmlColumn); END; $$ LANGUAGE plpgsql; 

JSONの柔軟なテーブル選択を使用したインポート機能は、上記と特に違いはありません。 しかし、XMLのこのような柔軟性により、より大きな共有が生成されます。

上記の例では、インポートされたファイルの名前table_nameは、nginxで指定されたターゲット宛先テーブルに影響しません。 table_name / rows / colsドキュメントのxml階層の使用は、組み込みのtable_to_xml関数との対称性のみに起因します。

データセット自体...




ここに移動したので、純粋なCOPYのルーツに戻ります...

わかった これがおそらく唯一の方法です。 すべてを正しく理解したことを確認しましょう。 サーバーとクライアント間で処理せずにデータを送信し、それらをテーブルに入力しますか？



私は恐怖を感じたと思います。
ナンセンス。 ミドルウェアの夢を見つけに来ました。
そして今、私たちは彼女の旋風の中にいるので、あなたは去りたいですか？
あなたは理解する必要があります、私たちは主な神経を見つけました。


はい、それはほとんどそのようなものです！ これはCRUDの拒否です。
もちろん、いくつかの文のあるタイプがカリフォルニアの心の仕事の結果を消し、麻薬中毒者の対話のための短い記事を様式化するので、多くはmanyります。 ただし、すべてが失われるわけではありません。 データ自体とともにデータ修飾子を渡すオプションがあります。 それは今でもおなじみのRESTfulアーキテクチャから離れています。

さらに、時には、そしてより頻繁に、理論的研究が現実の岩石に侵入します。 そのような岩は同じ不幸なマルチパスです。 実際、ユーザードキュメントの多数の位置の変更を許可する場合、これらの変更にはいくつかのタイプのメソッドが含まれる可能性があります。 その結果、1つのドキュメントをデータベースに送信するには、いくつかの個別のhttp要求を作成する必要があります。 また、各HTTPリクエストは、独自のベース変更とテーブルの通過を生成します。 したがって、定性的なブレークスルーには、CRUDメソッドの古典的な理解を放棄する際の根本的な変更が必要です。 進歩には犠牲が必要です。

ここで、より興味深い解決策が見つかると疑っていました。 あなたはちょっと実験して考える必要があります...

エントリーポイント

この質問をする頃には、
彼に答えることができる人はまだ近くにいませんでした。
はい、はい、私は再び始めています...

中間層にデータを送信し、中間層は処理せずにデータベースに送信します。
DBMSはそれらを解析し、ログ/ログとして機能するテーブルに配置します。 すべての入力データの登録。

重要な瞬間、ここにあります！ ロギング/ロギングデータの流れはそのままで！ そして、それはトリガー次第です。 それらでは、ビジネスロジックに基づいて、更新、追加、または他の何かを行います。 データ修飾子のねじ込みはオプションですが、素晴らしいボーナスになる場合があります。

これにより、HTTP GETメソッドとPUTメソッドを使用することで十分になります。 それを適用する方法をシミュレートしてみましょう。 まず、ログとログの違いを判断します。 変更のルートの値と最終値の間の優先順位による重要な違いを強調します。 最初の基準をログに割り当て、2番目の基準をログに割り当てます。

雑誌の最終目標の優先順位にもかかわらず、ルートはまだ必要です。 その結果、このようなテーブルは、結果とジャーナル自体の2つの部分に分割されます。



何を引き出すことができますか？ ログ：車のルート、移動する素材資産など ログ：在庫残高、最後のコメント、およびその他の最近のインスタントデータの状態。

2.jrl.log.sqlのコード：




上記の例では、セルをきれいにする方法がわかりません。 これを行うには、サービス値を固定します。 そして、それらはインポートの方法に大きく依存しています。 場合によっては、絶対に任意のコンテンツを持つ任意のタイプを使用できます。 その他の場合、範囲外の可能性が高い符号を持つターゲット列のタイプのみ。

トリガーは、名前によるテキストのソート順で呼び出されます 。 trg_N_プレフィックスを使用することをお勧めします。 trg_0からtrg_4まで、共通ロジックと着信フィルタリングの整合性のみを提供するサービスを検討してください。 また、5から9を適用した計算に使用します。 トリガーは 9つあれば十分です ！

また、BEFORE INSERTにインストールする必要があることも言う価値があります。 c AFTERの場合、トリガーによる変更の前にNEWサービス変数がテーブルに入れられるためです。 原則として、整合性がある程度重要でない場合、そのようなソリューションは、ログを通過するユーザークエリの優れたアクセラレータになります。 これは、結果のテーブルの値には影響しません。

また、AFTERでは、ユーザーが変更する権利を持っていない場合、エラーを返すことはできません。 ただし、正しいFrondEndは、サーバーによって禁止されている操作を実行しないでください。 したがって、このような動作はハッキングの特徴である可能性が高く、ジャーナルに平和的に記録されます。

プロのフィルタリングとルーティング

標準のnginxツールを使用してURLをルーティングします。 同様に、リクエストをインジェクションからフィルタリングします。 問題を2倍にした後、非対称暗号化の結果に似たコードをmap nginx.confディレクティブにコーディングして、消化可能で安全なSQLクエリを取得します。 将来的には、データをフィルタリングします。

いくつかの困難があります。 これは、 sed s / bad / good / g型を複数置換するためのnginxの通常の構文の不足が原因です。 その結果、我々...

私たちはこのクソテラリウムの厚いところにすぐ入ります。 そして、結局のところ、これらのいまいましい表現を書く心があります！ もう少しすると、彼らは脳を細断します。

最大4つのURL等価フィルター
http://some.server/csv/table_name/*?col1=value&col2=value&col3=value&col4=value
filters.nginx.confのHorrowshow部分

 #  SQL map $args $fst0 { default ""; "~*(?<tmp00>[a-zA-Z0-9_]+=)(?<tmp01>[a-zA-Z0-9_+-.,:]+)(:?&(?<tmp10>[a-zA-Z0-9_]+=)(?<tmp11>[a-zA-Z0-9_+-.,:]+))?(:?&(?<tmp20>[a-zA-Z0-9_]+=)(?<tmp21>[a-zA-Z0-9_+-.,:]+))?(:?&(?<tmp30>[a-zA-Z0-9_]+=)(?<tmp31>[a-zA-Z0-9_+-.,:]+))?(:?&(?<tmp40>[a-zA-Z0-9_]+=)(?<tmp41>[a-zA-Z0-9_+-.,:]+))?" "$tmp00'$tmp01' AND $tmp10'$tmp11' AND $tmp20'$tmp21' AND $tmp30'$tmp31' AND $tmp40'$tmp41'"; } #   map $fst0 $fst1 { default ""; "~(?<tmp0>(:?[a-zA-Z0-9_]+='[a-zA-Z0-9_+-.,:]+'(?: AND )?)+)(:?( AND '')++)?" "$tmp0"; } map $fst1 $fst2 { default ""; "~(?<tmp0>[a-zA-Z0-9_+-=,.'' ]+)(?= AND *$)" "$tmp0"; } #   ,  WHERE map $fst2 $fst3 { default ""; "~(?<tmp>.+)" "WHERE $tmp"; } server { location ~/csv/(?<table>result_[a-z0-9]*)/(?<columns>\*|[a-zA-Z0-9,_]+) { pgcopy_query GET db_pub "COPY (select $columns FROM $table $fst3) TO STDOUT WITH DELIMITER ';';"; } } 

URLでのキリルフィルター処理では、nginxの設定を介して、すべてがスムーズに行われることもありません。base64から別の変数への人間が読めるテキストを使用したネイティブ変換が必要です。 現時点では、そのようなディレクティブはありません。 nginxのソースには、トランスコーディング機能が存在するため、これは非常に奇妙です。
スレッドとして、nginx incチームがこれを解決しなければ、間違いなく思考を集めて、この省略とsedの問題を排除します。

直接関数呼び出しまたはテーブルログのトリガーで動的クエリを内部生成するために、URLにDBMSへの引数を持つ文字列を与えることができます。 しかし、そのようなデータはすでにnginx-access.logに記録されているため、これらの取り組みは冗長です。 また、このようなアクションはベースプランナーの負荷を増大させる可能性があるという事実を考慮すると、それらも有害です。

SM oke all FAQ

-nginxの下のモジュールは長い間正常に書き込まれています。 ファンファーレはどうですか？
既存のアナログのほとんどは、非常に専門的なソリューションです。 この記事では、速度と柔軟性の妥当な妥協案を提示します！

-ディスクを処理します（client_body_in_file_only）-ゆっくり！
RAMドライブとその預言者であるファイルシステムキャッシュがあなたと共に来ますように。

-ユーザーの権利はどうですか？
単純なhttpを使用した承認はpostgresに転送されます。 そこで、組み込みツールを使用して解決しています。 一般的に、完全なバックエンド。

-暗号化はどうですか？
nginx configを介したSslモジュール。 現在の段階では、ngx_pgcopyコードの湿気のために離陸できない場合があります。
サーバーの多様性を備えたnginxとpostgresの接続は、偏執狂的にsshを投げることができます。

-当初、メガネの反射にJSシンボルが含まれているのはなぜですか？ javascriptはどこにありますか？
JSはフロントエンドに行きます。 そして、これは完全に異なる映画です。

-JSが無効になっているクライアントに生命はありますか？
おそらく以前に気付いたように、例では、Postgresはxmlでできます。 つまり HTML出力の準備は問題ありません。 スパゲッティコードの使用とxslスキームの両方。
これはひどいです。 それにもかかわらず、すべてがうまくいきます。 あなたはすべて正しいことをしています。

-写真のサイズを変更し、アーカイブをパックし、GPU上のレプトンのパスを読み取る方法



そして、そう簡単に。

たぶん私はこの男とチャットした方がいいと思った。
FastCGIに行かないでください！
彼らは私たちにこれを期待するだけです。
このボックスに誘ってください
地下に降ります。 あそこ。

ngixclient_body_in_file_only onを言い、コマンドラインにアクセスして、腕いっぱいの$ request_body_fileとplperluを取り込みます。 そしてそのスレッドを以下から適応させます：

 CREATE OR REPLACE FUNCTION foo(filename TEXT) RETURNS TEXT AS $$ return `/bin/echo -n "hello world!"`; $$ LANGUAGE plperlu; 

-CGIのように見えます。 そして、CGIは安全ではありません！

セキュリティは、テクノロジーよりもリテラシーに依存しています。 はい 環境変数をねじ込んだ後、CGIと互換性があります。 さらに、これは、スクリプトの最小限の再構築でCGIからのソフト移行に適用できます。 したがって、この方法はほとんどのPHPソリューションからの避難に適しています。

分散コンピューティング（PostgreSQLクラスタリングのおかげ）のトピックと、非同期へのアプローチを選択する自由についての夢を見ることができます。 しかし、これを行うために、もちろん私はしません。

参照資料

→ ngx_pgcopy
→ PostgreSQL COPYリクエスト
→ slim_middle_samples （ 記事のサンプル +デモアセンブリ）

警告

モジュールはまだ開発中であるため、安定性の問題が発生する可能性があります。 私がまだバックエンドの方向に実装していないキープアライブ接続を考慮すると、この作成は、当分の間、依然として超音速戦闘機に適しています。 読むためのREADMEモジュール。

PS。 実際、CRUDはストアドプロシージャを介して問題なく実装されるか、メソッドごとのログに従って、ログには適用されません。 また、モジュールにDELETEメソッドを追加するのを忘れました。

---

この記事では、1998年の映画「Fear and Loathing in Las Vegas」の映像と引用を使用しました。 これらの資料は、非営利目的および社会の文化的、教育的、科学的発展を刺激する枠組みでのみ使用されます。