すぐにHighLoadとBigDataを実現する10の方法

イリヤ・コスモデミャンスキー（ ハイドロバイオント ）

リポジトリでの作業には一般的なエラーがあり、これらのエラーは意図的にそれらを発明したものではありませんが、リモートデータベースサポートで多くの作業を行っているため、単にそれらを収集します。 多くの場合、お客様からも同じです。 そして、収集したものに対して一種の評価を行います。 今日はこれらのことについてお話します。



Ilya Kosmodemyansky：すべてのストレージに共通することがいくつかありますが、私たちは主にPostgreSQLで作業しているため、PostgreSQLに固有のいくつかの事柄について自然に言及します。 また、PostgreSQLは伝統的にWeb上で多く使用されてきました。



エピグラフとして、次のものを引用できます。







エレクトロニクスの場合と同様に、2種類の問題があります。余分な接触がある場所、または必要な場所に接触がない場所です。 データベースは同じ話です。 人々がデータベースに保存しないもの：写真から完全に驚くべきものまで、おそらくそこに保存すべきではありません。 あるいは、逆に、保存すべきものをデータベースに保存しないかもしれません。 あるものには1つのキャッシュが使用され、別の目的には別のキャッシュが使用され、3番目のキャッシュにはNoSQLストレージなどが使用されるためです。 そして、おそらくデータベースのどこかにいる方が良いでしょう。 そしてもっと価値があります。



これらのことを実際に簡単に見てみましょう。 これらの問題は、これらの問題の深刻度の順にそれほど多くは順序付けされていませんが、ここでそれを把握します。





免責事項として：いくつかのトローリングがあります。 たぶん私はどこかへ進まないでしょう。 あなたがそれについて退屈な話をするとき：「男はそのようにそれをしない！」、そして、もちろん、誰もが言う：「うん」と彼らはそれをする。 感情が現れると、人は次のように見えます。 どんな愚か者がそのように書いていますか？」 gitを開き、そこに-ta dam！ 昨日これを書いたのは誰ですか？ その後、よりよく記憶されます。



まず、最初の問題の1つを参照してください。







そして最初のものは、非常にまれな機会にしか観察しないためです。 おそらく、この問題がOracleとDB2で発生することはほとんどありません。スケーリングされた各ノードには莫大な費用がかかるためです。 ただし、これは空想の逃避を制限しますが、Webで特に使用されるわけではありません。 そして、オープンソースで、無料のもので-ただ行く方法です！ さらに、PostgreSQLでは絶対に必要ではありません。MySQLではさらに特徴的で、特にNoSQLでは特に必要です。



人々はスケーリングが好きです。なぜならスケーリングは良いからです。彼らはそれについて本に書いています。 「良い」という理由だけで。 なぜ良いのか-説明できる人はほとんどいません。ここにはいくつかの異なる問題があります。



特に特徴的なのは、過去10年間で、すべてがスケールアウトされるべきであり、決してスケールアップされるべきではないということを常に聞いていることです。 スケールアップがひどいので！



それ以来、発明されて以来、コンピューターはやや強力になりました。 タスクも成長しましたが、タスクは強力なコンピューターほどには成長しませんでした。



客観的な理由でビッグデータを扱う人がいます。彼らはハドロンコライダーから何かを引き出す物理学者です。 これらは、星が研究する物理学者です。 彼らは遺伝子を研究する生物学者です。 これらはコンピューターゲームを作成し、ゲームスクリプトの開発が不十分な人（宇宙の原子よりも多くの要素を持つことが多い）であり、これが機能するはずだと考えています。



大量のデータが本当に必要で、1台のマシンに収まらない客観的なタスクは、ごくわずかです。 たぶん、ある種の証券取引所とそのようなもの。



したがって、原則として、特に最初からスケーリングするのはあまり良くない可能性があります。 実際のところ、典型的なケースは、それがどのように発生するかをより近く、より理解できるようにすることです。







多くの人が私たちのウェブサイトを使用することにしました。 通常、共同創業者の1人とマーケティングを行うと、どれだけの負荷がかかるかを計画するときに、通常のプログラマーは一度に100に分割できます。 しかし、もしそうなら、あなたはそれについて何かをする準備ができているはずです。 当然のことながら、人々はすぐにスケーリングについて考え、そして私は、いわゆる時期尚早のスケーリングについてさえ考えます。



典型的な物語。 サイトに100万人のアクティブユーザーがいるので、このユーザーの作成日までにそれらを共有します。 そして、なぜユーザーが作成された日付までに？ それは私たちにとってとても必要だと思われたからです。 実際、このようなケースはさまざまな場合がありますが、これはその1つです。



その結果、しばらくすると、多くの問題が発生します。 ユーザーは完全に独立しているわけではないため、たとえば、リレーショナルデータベースのある種のありふれたタスクを収集するために、友人と同じマシン上にある場合は、特別なサービスなどが必要です。 実際、チャットやその他の相互対話では、必然的にユーザーが別のマシンに住んでいることが判明し、「到着」しました。 ロジック全体ですぐに複雑になり、サポートがすぐに複雑になります。



かなり前に、あるプロジェクトで、PostgreSQLを搭載した10台のマシンを配置した場合（多くの点でまだ高速ではありません）、これらのマシンは計画された負荷やコストに耐える能力を備えている必要があると思いました。 比較して、見た。 Oracleエンタープライズライセンスを購入し、大きなキャビネットを備えたディスクアレイに配置するだけで、お金を払ってばかげて安くなりました。 そのような場合があります。 データベースがより良く機能し始めたので、今ではこの主題については簡単です。 すべて-Oracle、MySQL、PostgreSQLの両方が過去10年間にわたって非常に大きな進歩を遂げました。



しかし、さらに大きな問題が発生します。 突然、全体を見ることができた100台のマシンのうち、アクティブになっているマシンはわずかです。 新たに登録されたユーザーは、私たちのサイトでの生活パターンに起因して、不均一に活動しています。 つまり、長い間登録していくつかのマシンに落ち着いたユーザーは、それに応じて何もせず、車のコストもかかります。



もう1つ問題があります。マシンが立っている場合、キャッシュはウォームアップされません。 データベースは、ディスクからではなくキャッシュからデータを返すと、より高速に動作します。 したがって、「あるユーザーに関するデータを取得する」というリクエストが1時間に1回届くと、完璧なタイミングからはほど遠い場合、ウォームアップされないため、これを行うためにリクエストが数倍遅くなることがわかります。キャッシュ、すべてがうまく機能しません。



100台の車を配達し、インフラストラクチャに適切な変更を加え、作動不能なシステムを受け取ったため、すぐにやり直す必要があるという問題があります。



そして、一般的に、このケースははるかに広いです。 最初に彼らは破片に一つの鍵を見ました、そして彼らは実際には完全に異なる何かをする必要があることに気づきました。 それぞれ、やり直し始めました。 Webが動いているターゲットであり、実際、設計よりも速く条件が変化するため、もう一度別の方法で必要であることがわかりました。



したがって、私の典型的なアドバイスは、最初に通常のリレーショナルベースで1台のマシンのリソースまで拡大し、そのペースでどこに到達するかを確認することです。 次に、この車のアップグレードにかかる費用と、よりファッショナブルなハードウェアでより良く、より速く生きることができる金額をそれぞれ計算します。 そして、これを計算した後、その後のみスケーリングについて決定します。



そして、このアプローチは実際には複数のプロジェクトを節約しました。なぜなら、早​​すぎるスケーリングは多くのチームリソースと多くのお金を必要とし、結局はより高価で悪くなるだけだからです。







2番目のポイントは、ランキングでも十分高い。 これらは「ゼロからのビッグデータ」のケースです。 企業は「常時データ」を持ちたいと考えています。 典型的なストーリー-いくつかの統計を考慮し、収集しますが、ユーザーアクティビティ、タイムインベントリ、一般的には知りません。 実際、そこには新しいデータがあるので、そこからの集計のみが必要です。それは、先日、先週、最後の1時間です。 それ以外はすべて事前に計算された単位です。 そして、これらのユニットを年に1回再集計する必要があります。 他のケースでは、それらはまったく数えられないことがわかりましたが、数テラバイトを保持しているため、単にそこに横たわっていました。 これは、不良バッグデータの典型的な例です。



このタスクをビジネスに説明するのはプログラマーのタスクです。ビジネスがデータを失い、分析を計算しないという恐怖は完全に明白だからです。 データはお金で、すべてがシンプルです。 しかし、同時に、4テラバイトを保持する代わりに、さまざまな興味深いことを行うことができます。 データを正しくアーカイブでき、生データをアーカイブマシンのどこかに保存することもできるため、必要に応じて、それらに基づいて集計を再計算できます。これは、突然新しい集計が必要になった場合に、統計などに使用します。 しかし、その結果、到着したばかりのホットデータは4テラバイトではなく100ギガバイトを占有し、これを扱うのがはるかに簡単になります。



さらに、多くのデータベース、たとえば同じPostgreSQLには、これを可能にする多くの自動ツールがあります。 たとえば、PL /プロキシを使用すると、アーカイブされたデータをリモートマシンに転送し、必要に応じてそこからデータをプルして、サンプルを返すことができます。



これを行うには多くの方法がありますが、この状況では、これまたはそのアーカイブとホットデータへのパーティション化が非常に役立ちます。 数千倍のサイズのデータ​​ベースを運用するためには、このデータの大部分が本物である場合、90％は必要ありません-常に苦痛であり、その必要はありません。







彼らは普遍的なアプローチを使用するのが好きです。 Entity-Attribute-Valueは、一般に、DBAにとって災難です。 プログラマーは設計に非常に興味があるからです。 すべてが普遍的であるため、何か新しいものを追加する必要がある場合、テーブルの構造を変更する必要はありませんが、新しいタイプの属性を追加し、新しい属性を登録し、そこに新しい値を入れることができます。



良い、便利、素晴らしいですが、結果として、それはすべて巨大な3つまたは4つの（タイプがある場合）テーブルに成長します。 そして、あなたのデータはすべてそこにあり、あなたは常にそれらに参加しています。 同時に、実際には、これらのJOINを何らかの形で最適化することは非常に困難です。なぜなら、そのような状況では、ある種の「テキスト」にデータが含まれている可能性が高いからです。 たとえば、それらを異なるタイプに配置することは難しく、そのようなデータのインデックス作成効率は、別々のリレーショナルテーブルに保持する場合よりも桁違いに小さくなるためです。



さらに、それが何の属性なのかを把握するためにどれだけのドキュメントを保持する必要があるか想像できますか。 それでも、特に合理的な説明があれば、リレーショナルスキーマ自体がある程度文書化されます。 EAVでは、適切なドキュメントがなければ、まったく状況がまったくなく、そのように理解することはできません。



その結果、EAVを構成するものは一般に「コア」と呼ばれます。 完全に動作しなくなるような状態になると、誇らしげな名前「core」に名前が変更されます。 そして、これはすべて異なるアイデアで重み付けされ始めます。実際には、非正規化されたデータが保存されるため、少なくとも何らかの種類の迅速なアクセスが可能になります。



その結果、設計の初期の簡素化から何も残っていません。 これはゆっくりと、ひどく機能し、このスキームの変更は、多くの場合、異なる人々や物事の部門によっても書かれた、完全に独立したばらばらの束に投げ込まれなければなりません。その結果、そこに述べた目標を効果的に達成できません。







ORMでも同じです。 私は長いホリバーに行きたくありません。ORMを持っているのは良いことでも悪いことでもありますが、DBAとして私はORMが嫌いです。 原則として、ORMで何かをすばやくプロトタイプしたいという願望を理解していますが、実際には、奇妙な現象が始まります。 ORMはデータベースの速度を大幅に低下させることを理解しており、プレーンSQLで一部のクエリをやり直し始めています。 さらに良いことに、適切なクエリを作成するようにORMをトレーニングしてみてください。 これは、一般的にひどいことです。 ORMによって生成されたリクエストに勇気を持って奮闘し、それを正しく書く方法を知っている人を見たことがあります。 彼はすでにリクエストをしていて、それを正しく書いた。 そして彼は、ORMが同じタイプのリクエストを生成し、それが正常に動作するようにORMをトレーニングしようとしました。 これの無意味さが完全に明らかになります。



さらに、原則として、たとえば、トピックに関する別のレポートを読むことができます。「ORMがアクセスしたSQLクエリログで推測しましょう」。 これ（上のスライド）は何ですか？ 一般に、多くのORMはこれによって罪を犯します。 しかし、このINが非常に大きなサイズになる可能性があることを付け加えると、ほとんどの場合、Djangoはこれと同じになります。 Ruby on Railsでは、それらは短くなります。



実際のところ、ORMは多くの方法で推測できますが、このことは一般的に非常に悪いことです。 なんで？ このリストは何でも構いませんから。 オプティマイザは、それをどう処理するかをまったく知りません。 これが何らかの種類のJOINに置き換えられた場合、どこにいても動作する可能性が最も高くなります。 何らかの形で最適化できます。 非常に汚いハッキングがなければ、このINで何もできません。 そしてORMで！ ある程度、すべての要求はそのように行われます。



つまり、はい、お気に入りのORMのプロトタイプを作成してください。ただし、いずれにせよ、遅かれ早かれ、いずれにせよ、不快で悪くなることを理解する必要があります。 そしてパフォーマンスの面では、主なものは悪いです。







ビッグデータに関する純粋なpostgresのことを次に示します。 PostgreSQLにはそのような自動バキューム機能があります。 PostgreSQLは、挿入すると挿入し、更新すると挿入+削除します。 同時に、削除も削除ではなく、単にスコープからタプルを削除するだけです。



そして、非常に断片化されたテーブルを取得します。 タブレットの実際の実際の値は100,000である可能性があり、数百万個の関連性のないタプルが含まれているという理由だけで、ある種の地獄ギガバイトの重さがあります。 彼らはただ運転し、データベースを典型的なビッグデータの例に変えます。



当然、そこに何も設定されていない場合、すべてがうまく機能しない場合、それを悪用する人々の最初の反応は次のとおりです。「自動バキュームをオフにしましょう！ 実行時間が最も長いプロセスであるため、すべてに干渉します。インデックスを追加することはできません。autovacuumがテーブルを通過する場合、DDLを実行する必要はありません。 オフにしましょう！」



それは非常に不十分に終わり、それに応じて、あなたはそれについてたくさん話すことができます。



autovacuumの対処方法と対処方法に関する推奨事項のリファレンスを次に示します。 主なことは、結果が絶対に怪しいので、何らかの方法でそれをオフにする必要がないことです。 本当に必要のない時系列データを使用するよりも、「すぐに使える」ビッグデータを取得し、データベースのスペースを占有します。







「参加するのは悪です！」 私はこれが私の頭のどこから来たのかを観察しています。 たとえば、長い間他のバージョン3でMySQLを使用していた人々は、多くの場合、JOINは悪であるという考えを持っています。



ここで何が言えますか？ JOINは良いです。 なぜリレーショナルモデルがこれほど成功しているのですか？ 関係モデルは、未知のもののように、そのような後方のものであると聞いたことがありますか？ スキーマレスのNoSQLが登場してみんなを倒すという意見を誰もが聞いたことがあると思います。 発生しません。



なんで？ データは1つの方法で便利に保存されます-ディスク上のブロックの形で、別の方法で、できればより高いレベルで取得するのが便利だからです。 したがって、異なるテーブルなどから高レベルの方法でデータを取得する場合、最適化を行うにはリレーショナルモデルが非常に便利です。 そして、リレーショナルモデルを使用する場合、それを最大限に活用する必要があります。



JOINの代わりに何ができますか？ とても簡単です。 私たちは、お気に入りのプログラミング言語、アプリケーションサーバー、バックエンド-どこでも-2枚または3枚のプレートからデータを取り込みます。 実際、それらはすでにアプリケーションに存在し、スペースを占有するなどしています。これらのプレートは簡単に大きくなる可能性があります。 つまり、実際には最後に10行を取得する必要があり、巨大なシートを引き出します。



そして、手作業でJOINを行います。そのような「手作業による日没」です。 最初にサイクルを歩き始め、それが遅いことに気づき、そこである種のハッシュアルゴリズムを発明し始めます。



実際、「フルサイズのライブモデルの蒸気エンジン」などのデータベースを発明し始めています。 それでも、オプティマイザーはJOINアルゴリズム（ネストされたループ、ハッシュ、マージ、またはその他のパラメーター）を選択するためにパラメーターの束に関する情報を収集するため、やや悪いでしょう。 プログラミング言語では、すべて自分で書き直します。 そして、これはなぜですか？



しかし、誰もこれを見たことがない人はいますか？ まっすぐに？ 他の誰もが少なくとも一度はどこかでこれに会った。 , -.



, . SQL – . , , JOIN , , .







– . Slony? PostgreSQL , , , , Slony, . , . trigger based , .



, , , ( , ), - .



PostgreSQL , , : Shipping Log' Hot Standby', Slony, Londiste PgQ, , . , , , Shipping' Log'. , , - , - .



, , - . , . – . , . , , - - , , , -. - . , , , -, .



, - , - , , .



, , , SQL. , - , , - , , SQL. , , , , .



- – . , – , , , , . – . , SQL statement', , , 8- , , redo . , , slave . , . . , .







, , .



, EXPLAIN. , , . , , . , , , , production 100 . , , , , , , , - . .

, Highload++ Junior 2016 . — 2016 YouTube.

, – , workload . , , , . - , , , , , . , , - , .



, , - production DBA. – . , , , , , «, », , - . これは間違っています。



, - , , , - . , PostgreSQL pg_stat_statements, , – : , ; .



, , « ». , . production, , .







Java-. pretending to be smart. , – - , - .



Java. Java , , Java' , , , . . , , , . , , – . , . : 10 . , 10 . 10 .



? , , . ́ . , .



– . . : , . – . なに なんで？



DBA , ? ( - , – PostgreSQL , , BEGIN, EXPLAIN ANALYZE ROLLBACK, ) . , . – .



, , , . . . , , , Python' , .



, , , , , , , , / .







, , . , .



, - , , . – , . -. , - - ? . - , - .. , ? . 明らかに。



EXPLAIN - , , ETL, - - , , – - ?



, . , : , - , - ; . , , - . , .



count(*), , - , . .



. , , . , . PostgreSQL , , , - , , , .



– . , 261 526 , , , 15 . , ?



count(*) – . count(*) – Seq Scan ( PostgreSQL), . count(*) . 20 ? , .



? ?



. . SQL- -, ! . , , - . . , , , , , . .



: «Know your data!» , .



- ( - Oracle , , Orace , SQL- ..; , – !) : « , SQL-?». : « , , ».



, , , , , , , , . , PostgreSQL , , .



. . ありがとう .



: , autovacuum . append-only, ?



: . .



, .



-, , . . , append , , .



-, pg_catalog, . . autovacuum, . - pg_class , . , .



. , - , , , autovacuum . , , , 90% autovacuum, autovacuum performance , , . .



: . , ?



: , , , , , , . : , , , , . .



: , . . ? , - , , - . - , , «», , - , - . , .



PL/Proxy , , , ? - ?



: . -, – - , , , , . « ».



, . – , , .



concurrency , – , – . , , .



, , , PL/Proxy. , , , , , . この技術は何ですか？ , , , PL/Proxy, , PL/pgSQL, . , , . , Microsoft. .



, , VIEW UNION' , , , , PL/Proxy. , , , WHERE, , . – PL/Proxy , , , UNION . , .



: , , - - ? ? ?



: , , , , , , .



, , . , – . . . , - , . : SSD , , , - .



, «» – , , , , .



, PostgreSQL - , – , , 30 , - , – , , . . .



, , , - workload. , , UTP-, master. - , , , , , , , .



, . , . – , , UTP, , , . .



: , . PL/Proxy foreign data wrapper? ?



: foreign data wrapper, . PL/Proxy , , autocommit, , RPC, . foreign data wrapper – , -, , -, , , .



Foreign data wrapper PostgreSQL . , , – , .



, foreign data wrapper , foreign data wrapper , .



: PL/Proxy , ?



: , , , , .



: : , - shared storage - OCFS2, OCFS2 read-only .



: . , - table space - , latency, .



: ?



: , table space ? , read-only. - table space, page, , .



: Oracle - ?



: . Oracle RAC, .



: - ORM? ORM, ? production ? ?



: , , . -. , ORM , -, ORM, , – . .



, ORM , SQL – , Java , , . « ». , , , .



: , ORM, ; , ORM, . , - ORM . , 90% , ORM, .



, – , ORM , – , , . . – , SQL , , , - .



ORM . - , , . , , , – , .



– . -, , . . - .

» hydrobiont

» ik@postgresql-consulting.com

— HighLoad++ Junior .



, , HighLoad++ Junior HighLoad++ .



? — 5 6 ? .



( :) — , , highload-. — .



, Project1917 (http://project1917.ru/), Nginx+MySQL+Laravel+AngularJS . , highload — , ( ) .



: HTTP- , , HTTP- , , MySQL .



, , ! !