バイナリ（ファイル）ストレージ、悲観的な終わりの怖い話

ダニエル・ポドルスキー（Git in Sky）

私のレポートは「バイナリ、ファイルストレージでもあります」と呼ばれていますが、実際、私たちは恐ろしい話を扱っています。 問題は（これが私のレポートの論文です）、今では良いだけでなく、少なくとも許容できるファイルストレージシステムが存在するということです。



ファイルとは何ですか？ ファイルは名前の付いたデータです。 重要なのは何ですか？ ファイルがデータベース内の行ではないのはなぜですか？



ファイルが大きすぎて1つのピースとして処理できません。 なんで？ HighLoad会議があるため、サービスがあります。同時に10万の接続を保持するサービスがあります。 接続ごとにサイズが1 MBのファイルを指定する場合、これはそれほど重要ではありませんが、これらのファイルのバッファーには約100 GBのメモリが必要です。







余裕がない。 とにかく。 したがって、これらのデータを、チャンクと呼ばれる小さな断片に分割する必要があります。 かなり頻繁に、時にはブロックで。 そして、ファイル全体ではなくブロックを処理します。 したがって、さらに別のレベルのアドレス指定があり、少し後に、これがバイナリリポジトリの品質に大きな影響を与える理由が明らかになります。





それにも関わらず、世界には良いバイナリストレージがないという事実にもかかわらず、ファイル交換は現代の大量データ交換の基礎です。 つまり インターネットを介して送信されるものはすべて、ファイルの形式で作成されます。htmlページから始まり、ストリーミングビデオで終わります。反対側には、ストリーミングビデオとこちら側のファイルがあります。 多くの場合、この面では-いいえ、しかしそれにもかかわらず、それはまだファイルです。



なぜそう なぜ大量ファイル共有をファイル共有に基づいているのですか？ 10年前はチャンネルが遅かったため、10年前はJSONインターフェースを買う余裕がなく、常にサーバーをリクエストできず、待ち時間が長すぎたため、ユーザーに表示するために必要なすべてのデータが必要でした。アップロードしてから、ユーザーにこのデータを操作する機会を提供します。







ファイルストレージ。 実際、「リポジトリ」という用語は「リポジトリ」と呼ばれるべきであるため、非常に残念です。



20〜30年前までは、これらは本当にリポジトリでした。データを処理し、テープに入れて、このテープをアーカイブしました。 これがリポジトリです。 今日、誰もそれを必要としません。 現在、4億5千万個のファイルがある場合、それらはすべてホットアベイラビリティである必要があります。 20テラバイトのデータがある場合、これは、これらの20テラバイトのうちのいずれか1バイトがいずれかのユーザーによって近い将来に必要とされることを意味します。 企業環境で作業している場合を除き、企業環境で作業している場合、HighLoadという言葉が企業環境に適用されることはほとんどありません。



ビジネス要件では、書かれていても「ファイルを保存する」と書かれることはありません...バックアップシステムと呼ばれるもの-いいえ、これはバックアップシステムではなく、災害復旧システムです。ファイルを保存する必要はありません。



ファイルを保存する必要があるのはなぜですか？ 彼らが与えられなければならず、彼らが与えられるために、彼らはあなたと一緒でなければなりません。 そして、私はこれが常にそうであるとは限らない、すなわち言わなければならない。 たとえば、多くのプロジェクトはhtmlページを保存しませんが、その場で生成します。多数のページを保存することは問題であり、多数のhtmlページを生成することは問題ではないため、拡張性の高いタスクです。







ファイルシステムは古く、ジャーナリングされています。 古いファイルシステムとは何ですか？ 私たちは彼女にデータを書きました、彼女は多かれ少なかれこのデータを適切な場所のディスクにすぐに送りました。



ジャーナリングファイルシステムとは何ですか？ これは、2つの段階でデータをディスクに書き込むファイルシステムです。まず、「ログ」と呼ばれるディスクの特別な領域にデータを書き込み、次に空き時間があるとき、またはログがいっぱいになったときに、このログからファイルシステム上にある必要があります。 これは、開始を加速するために考案されました。 私たちは常に一貫したファイルシステムを持っていることを知っているので、たとえばサーバーの緊急再起動が失敗した場合、ファイルシステムをチェックする必要はありませんが、小さなログのみをチェックする必要があります。 それは重要です。



ファイルシステムはフラットで階層的でした。

• フラットはFAT12です。 あなたはおそらく彼女に会ったことがないでしょう。 それぞれディレクトリはなく、すべてのファイルはルートディレクトリにあり、FATテーブルのオフセットによってすぐに利用できました。
  
  
  
  
• 階層的。 実際、ファイルシステムでディレクトリを整理することは、フラットなシステムではそれほど難しくありません。 たとえば、現在問題を解決しているプロジェクトでは、それを行いました。 ただし、最新のファイルシステムはすべて、NTFSで始まり、ある種のZFSで終わる階層ファイルシステムです。 それらはすべてディレクトリをファイルとして保存します。これらのディレクトリには、これらのディレクトリの内容のリストがそれぞれ保存されます。10レベルのネストのファイルを取得するには、10個のファイルを順番に開く必要があり、11番目のファイルはあなたのものです。 SATAドライブには100 IOPSがあり、1秒間に100回の操作を実行できます。10回は既に使用しています。 ネストの第10レベルのファイル。これらのディレクトリがすべてキャッシュにない場合、システムが他に何もしなくても、0.1秒未満で開くことはできません。

FATを除くすべての最新のファイルシステムは、アクセス制御と高度な属性をサポートしています。 奇妙なことに、FATはまだ使用されており、アクセス制御も高度な属性もサポートしていません。 なぜここに書いたのですか？ それは私にとって非常に重要な瞬間だからです。 1996年に、ファイルシステムに関連する恐ろしい物語が始まりました。そのとき、従来のUNIXでアクセス制御がどのように機能するかを注意深く研究しました。 権利の仮面を覚えていますか？ 所有者、所有者グループ、その他全員。 タスクがありました。ファイルの読み取りと書き込みができるグループ、ファイルの読み取りができるグループを作成する必要があり、他の人はこのファイルで何もできません。 そして、私は、従来のUNIXの権利のマスクがそのようなパターンをサポートしていないことに気付きました。







もう少し理論。 POSIXは実際の標準であり、現在使用しているすべてのオペレーティングシステムでサポートされています。 実際には、これはファイルシステムがサポートする必要がある呼び出しのリストにすぎません。 これらすべてにおいて私たちにとって重要なことは何ですか？ 開く 実際には、POSIXでのファイルの操作はファイル名ではなく、ファイルハンドラーによって行われます。ファイルハンドラーはファイル名からファイルシステムに要求できます。 その後、すべての操作にこのハンドラーを使用する必要があります。 読み取り、書き込み、シークなどの操作は単純な場合があり、分散ファイルシステム標準POSIXを作成することはできません。



なんで？ シークはランダムなファイル位置へのランダムな移動、つまり 現実には、私たちは何を読んでいるのか分からず、どこに書いているのかも分からない。 私たちが何をしているのかを理解するために、オープン操作から返されたハンドラーと、ファイル内の現在の位置が必要です。これが2番目のアドレス指定です。 POSIXファイルシステムは、「開いてファイルを最初から最後まで読み込もう」などの連続したものだけでなく、ランダムな2番目のアドレス指定をサポートしているという事実、または例えば「開いてファイルを書き込もうと、すべての新しい記録可能なブロックがファイルの最後に追加されます」 POSIXがこれがそうでないことを要求するという事実は、（これについては後で詳しく）良い分散POSIXファイルシステムを作成することを許可しません。



POSIXファイルシステムには他に何が存在します。 実際、すべてのPOSIXが同じアトミック操作のセットをサポートしているわけではありませんが、いずれにしても、一定数の操作はアトミックでなければなりません。 アトミック操作は、一度に発生するか発生しない操作です。 データベース内のトランザクションを思い出させますが、実際はただ思い出させます。 たとえば、この会議で集まったため、ディレクトリの作成はアトミックな操作です。







理論に関する最後のこと。 ファイルシステムの機能には実際には必要ないが、時には役立つさまざまなもの。

• オンライン圧縮とは、ブロックを記録するときに圧縮することです。 たとえば、NTFSでサポートされています。
  
  
  
  
• 暗号化 NTFSでもサポートされており、ext4では圧縮も暗号化もサポートされていません。両方をサポートするブロックデバイスを使用して構成されています。 実際、ファイルシステムが正常に機能するには、どちらも必要ありません。
  
  
  
  
• 重複排除。 今日のファイルシステムにとって非常に重要なポイント。 たとえば、4億5千万個のファイルがあるが、2億個のチャンクしかないプロジェクトがあります。これは、ファイルの約半分が同じであり、異なる呼び出し方をしていることを意味しています。
  
  
  
  
• スナップショット。 なぜこれが重要なのですか？ 5 TBのファイルシステムを使用しているため、そのように一貫したコピーを作成することはできません。 すべてのプロセスを停止し、ファイルシステムからの読み取りを開始しない限り。 私の推定によると、安価なSATAドライブから5テラバイトが約6時間読み取られます。まあ、1時間あたり5テラバイトです。 5時間サービスを停止できますか？ いいえ、そうですね。 したがって、ファイルシステムの一貫したコピーが必要な場合は、スナップショットが必要です。
  
  
  
  これまで、スナップショットはLVMのブロックデバイスレベルでサポートされており、うんざりしています。 見て、LVMスナップショットを作成すると、線形読み取りがランダムになります。これは、スナップショットを読み取り、基本ブロックデバイスで読み取る必要があるためです。 書き込みではさらに悪化します。ベーシックボリュームで読み取る必要があり、スナップショットに書き込む必要があり、スナップショットから再度読み取る必要があります。 実際には、LVMのスナップショットは役に立ちません。
  
  
  
  ZFSには適切なスナップショットがあり、それらの多くが存在する可能性があります。たとえば、ファイルシステムのコピーを作成してからスナップショットを転送できる場合は、ネットワーク経由で転送できます。 一般に、スナップショットはファイルストレージ機能には必要ありませんが、非常に便利であり、やがて必須であることがわかりました。

この理論全体の中で、最新のものですが、おそらく最も重要なものです。



読み取りキャッシュ。 NT4インストーラーをMS DOSから起動したとき、スマートドライブ（これはMS DOSの読み取りキャッシュ）を実行せずにNT4をインストールするのに6時間かかり、スマートドライブを実行すると40分かかりました。 なんで？ ディレクトリの内容をメモリにキャッシュしないと、毎回これらの非常に10のステップを実行する必要があるためです。



レコードキャッシング。 実際、最近まで、これは非常に悪い音であると信じられていました。デバイスで書き込みキャッシュを有効にできるのは、バッテリー制御のトレードコントローラーがある場合だけです。 なんで？ このバッテリーを使用すると、サーバーに到達しなかったデータをメモリに保存できるため、ランダムにオフになります。 サーバーの電源を入れると、このデータをディスクに追加できます。



オペレーティングシステムがこのようなものをサポートできないことは明らかであり、コントローラーレベルで実行する必要があります。 今日、SSDドライブと呼ばれる非常に安価なRAMを使用できるため、この動きの関連性は急激に低下しました。 今日、SSDへの書き込み書き込みは、ローカルファイルシステムのパフォーマンスを向上させる最も簡単で効果的な方法の1つです。



それはすべて、お使いのコンピューターにローカルなファイルシステムについてでした。







高負荷はネットワークです。 これは、訪問者がネットワークを介して訪問するという意味でのネットワークであり、これは水平スケーリングが必要であることを意味します。 したがって、ネットワークファイルアクセスプロトコルは、ステートレス-NFS、WebDAV、および他の多くのプロトコルの2つのグループに分けられます。



ステートレス-これは、結果が前の操作の結果に依存しないという意味で、後続の各操作が独立していることを意味します。 これはPOSIX標準ファイルシステムには当てはまりません。 読み取りおよび書き込みの結果は検索結果に依存し、彼は次に、オープンの結果に依存します。 ただし、たとえば、POSIXファイルシステムの上にステートレスNFS転送プロトコルが存在し、これが彼の主な問題です。 なぜNFSがそんなにクソなのですか？ ステートフルの上にステートレスだからです。



ステートフル。 今日、ステートフルプロトコルはネットワーク通信でますます使用されています。 これは非常に悪いです。 予測できない遅延があるため、インターネットのステートフルプロトコルはあまり適していませんが、それでも、多くの場合、JSON javascriptインターフェースは以前のサーバーとの通信がどのように終了したかを記憶し、次のJSONを注文します。前の操作の終了方法に基づきます。 ステートフルプロトコルを備えたネットワークファイルシステムのうち、CIFSはsambaとも呼ばれます。



両面の雌犬の耐障害性。 実際、従来のファイルシステムはデータの整合性に依存しているため、作成者は「ストレージ」という言葉に魅了されていました。 データで最も重要なことは、データを保存して保護することだと考えていました。 今日、これはそうではないことがわかっています。 RootConfのデータセンターのデータ保護に関与している人物の報告を聞いたところ、ハードディスクアレイだけでなく、ソフトウェアディスクアレイも拒否することをしっかりと伝えました。 各ディスクを個別に使用し、これらのディスク上のデータの場所、このデータの複製を監視するシステムを使用します。 なんで？ たとえば、5つの4 TBディスクのディスクアレイがある場合、20 TBが含まれるためです。 たとえば、ディスクの1つが飛び出すなどの偶発的な障害が発生した場合、復元する必要があります。実際には、16 TBをすべて読み取る必要があります。 1時間あたり1テラバイトあたり16テラバイトが読み取られます。 つまり ドライブが1つしか飛び出しませんでしたが、アレイを再度起動するには16時間必要です。これは今日の状況では受け入れられません。



今日、バイナリストレージのフォールトトレランスは、まず中断のない読み取りであり、奇妙なことに書き込みです。 つまり あなたの店は最初のくしゃみのためにカボチャになってはいけません、それは内部に隠されたデータを保存するだけで占められています。 データが失われた場合、神は彼らを祝福し、失われます。主なことはショーが続くことです。



ネットワークバイナリについて他に何を言うことが重要ですか？ 同じCAP定理、つまり 次の3つのうち2つを選択します。

1. または、データは常に一貫性があり、常に利用可能ですが、同じサーバー上にあります。
2. または、データは常に一貫性があり、複数のサーバーに分散されますが、そのデータへのアクセスはときどき制限されます。
3. または、データは常に利用可能であり、サーバー間で分散されますが、あるサーバーと別のサーバーから読み取ったデータは、まったく保証されません。

CAP定理は単なる定理であり、誰も証明していませんが、実際には事実です。 失敗します。 試行は常に行われています。たとえば、OCFS2（Oracle Cluster Filesystemバージョン2）は、CAPの定理の無効性を証明する試みです。



これはすべてファイルシステムに関するものです。 バイナリストレージについて、問題は何ですか？ それを理解しましょう。



TBのデータと数百万のファイルを保存する必要があるすべてのシステム管理者が思い浮かぶ最も簡単な方法は、単純に大規模なストレージシステム（データストレージシステム）を購入することです。







大規模なストレージシステムがオプションではないのはなぜですか？ 大規模なストレージシステムとそれと通信する1つのサーバーがある場合、またはデータを断片に分割でき、1つのサーバーが各断片でファイルと通信する場合、問題はありません。



水平スケーリングを使用している場合、これらのファイルを提供するサーバーを絶えず追加するか、神が禁じているのでそれらを最初に処理し、その後にのみ提供すると、大規模なストレージシステムにある種のファイルシステムを配置できないという事実に遭遇します。



初めてDRBDの手に落ちたとき、私は思いました：素晴らしい、私は2つのサーバーを持ち、それらの間にDRBDに基づいたレプリケーションがあり、一方から他方を読み取るサーバーがあります。 すべてのサーバーが読み取りをキャッシュすることがすぐに明らかになりました-これは、ブロックデバイスで何かを静かに変更しても、それ自体はこれを変更せず、無効にするキャッシュを知らないコンピューターがそれを知らないことを意味しますそれらが実際に既にある場所からデータをまったく読み続けます。



この問題を克服するために、キャッシュの無効化を提供するさまざまなファイルシステムがあります。 実際、共有ストレージにマウントしたすべてのコンピューターでこれを実行しています。



また、このOCFS2には、競合録音中のブレーキという問題があります。 アトミック操作について話したことを思い出してください-これらはアトミックな操作であり、1つの部分で発生します。 分散ファイルシステムの場合、すべてのデータが1つの大きなストレージシステム上にある場合でも、リーダーとライターを募集するアトミックな操作では、それらすべてが合意に達する必要があります。



ネットワークにおけるコンセンサスは、ネットワークの遅延です。 OCFS2の作成は本当に苦痛です。 実際、Oracleはそれほどばかではなく、優れたファイルシステムを作成し、まったく別のタスクのために作成しました。 彼らは、複数のOracleサーバー間で同じデータベースファイルを共有するために作成しました。 Oracleデータベースファイルには、このOCFS2で完全に機能するような動作パターンがあります。 ファイルストレージには適さないことが判明しました。2008年に試してみました。 OCFS2を使用した場合でも、時間の監視、つまり 同じホスト上で実行するすべての仮想マシンでは時間がわずかに異なるため、OCFS2は正常に動作しません。つまり、 ある時点で、この一貫性サーバーの時間が戻ったり、その場所に落ちたりすることが必然的に起こります。 そして、なぜそんなにゆっくりと、私はすでに説明しました。



また、大規模で大規模なストレージシステムであっても、自分で使用するのは非常に困難です。 たとえば、ヘスナーでは大容量ストレージは提供されません。 大規模なストレージシステムが非常に信頼性が高く、非常に優れており、非常に高性能であるという考えは、必要なリソースの正しい計算と単純に関連しているという疑いがあります。 大規模なストレージシステムを購入することはできません。ストアで販売されているわけではありません。 認定ベンダーに行き、彼と話をしなければなりません。 彼はうなずき、「それはあなたに費用がかかります。」と言います。 そして、それはあなたのために50-10万台のシャーシ、つまり また、ディスクでいっぱいにする必要がありますが、正しくカウントされます。 このストレージは5〜10％でロードされ、負荷が増加したことが判明した場合は、別のストレージを配置するようにアドバイスされます。 これは人生についてです。



いいでしょう 大規模なストレージシステムは選択肢ではありませんが、後に血液で発見しました。







クラスターファイルシステムを使用します。 いくつか試してみました：CEPH / Lustre / LeoFS。



まず、なぜそんなに遅いのですか？ 理由は理解できます-クラスター全体での同期操作のため。 リバランスとはどういう意味ですか？ HDFSには、すでに存在するデータの自動リバランスはありません。 なぜ彼女はそこにいないのですか？ なぜなら、CEFでリバランスが発生した時点で、私たちはそれを扱う機会を失うからです。 リバランスは確立された手順であり、ディスク交換の帯域幅の約100％を消費します。 つまり 飽和ディスク-100％。 時々リバランス、それはそれがかかるすべてのくしゃみのために、それは10時間続きます、すなわち。 CEFで作業する人々が最初に行うことは、リバランスの強度を強化することを学ぶことです。



いずれにせよ、多くのファイルと多くのデータがあるプロジェクトで現在使用しているまさにそのクラスターで、リバランスを緩めなければなりませんでした。そこで、実際には100％の飽和ドライブがあります。 このような負荷では、ディスクは非常に速く故障します。



なぜリバランスするのですか？ くしゃみごとに起こるのはなぜですか？ これまでのところ、これらの「理由」はすべて未回答のままです。



そして、同じ問題は、クラスター全体を同期的に処理する必要があるアトミック操作です。 クラスタに2台のマシンがある限り、クラスタに40台のマシンがある場合はすべて問題ありません。これらの40台すべてのマシンが見つかります... 40 ^2-送信する必要のあるネットワークパケットの数があります。 リバランスおよび一貫性プロトコルはこれに対処しようとしますが、これまでのところあまり成功していません。 これまでのところ、この意味で、マルチノードを備えた単一障害点のあるシステムは少し先導されていますが、それほど強力でもありません。







すべてのファイルをデータベースに入れることができないのはなぜですか？ 私の観点からすると、これはまさにすべきことです。データベースにファイルがある場合、そのようなことを処理するための優れたツールの大きなパッケージがあるからです。 データベースは10億行、ペタバイト単位で作業できます。数十億行、数十ペタバイト単位のデータベースで作業できます。 あなたが欲しい、Oracle、あなたが欲しい-いくつかのDB2、あなたが望む-いくつかのNoSQLを取る。 なんで？ ファイルはファイルだからです。 ファイルをアトミックエンティティとして扱うことは不可能であるため、分散ファイルシステムは適切に存在せず、分散データベースは正常に存在します。







そして、あらゆる種類のACFS、Lustreなどのクロスは、ファイルをバックアップする必要があるということです。 20 TBのバックアップをどのように想像しますか？ 1時間あたりTBを思い出させてください。 そして最も重要なこと-単一のファイルシステムがなく、スナップショットを撮ることができない場合、そのような量の一貫性を確保する場所、頻度、方法。 私が個人的にこの状況を見る唯一の方法は、新しいファイルを書き込むとき、バージョン管理機能を備えたファイルシステムであり、古いファイルはどこにも消えず、ファイルシステムの状態を見に行く時間を示すことでそれに到達できます。 何らかのガベージコレクションも必要です。



Microsoftは90年代にそのようなファイルシステムを提供すると約束していましたが、それは実現しました。 はい、Windows用の分散ファイルシステムがあり、Longhorn用にそれを発表しましたが、Longhornもこのファイルシステムも発生しませんでした。



バックアップが重要な理由 バックアップは耐障害性ではありません-オペレーターのエラーに対する保護です。 私自身、たまたまrsyncコマンドでソースと宛先を混同して、16の仮想マシンを実行しているサーバーを取得しました（魔法の話です！）が、それらを削除したため、イメージのあるファイルはありません。 仮想マシン自体からDDコマンドを使用してそれらを削除する必要がありました。 その後、何も起こりませんでした。 しかし、それでも、バイナリリポジトリのバージョン管理を保証する義務があり、通常はバージョン管理をサポートするファイルシステムはありません。ただし、ZFSはクラスタ化されておらず、したがって、私たちに適していないため、世の中にはありません。



どうする？ 開始するには、独自のタスクを勉強します。

• 保存する必要がありますか？ すべてのファイルをストレージシステムの1つに配置し、1台のヘビーデューティサーバーで処理できる場合。 これで、2 TBのメモリと数百のコアを持つサーバーを使用できます。 これに十分な予算があり、ファイルストレージが必要な場合は、そうしてください。 これにより、ビジネス全体のコストが安くなります。
  
  
  
  
• POSIX 誤って読んだり誤って書いたりする必要がない場合、これは大きなプラスになります。たとえば、前述のHDFS、CFSまたはLustreなどの既存のセットに対処できます。 Lustreは、コンピューティングクラスターにとって優れたファイルシステムですが、特定のクラスターにとってはあまり役に立ちません。
  
  
  
  
• 大きなファイル-必要ですか？ すべてのファイルを小さいと見なすことができる場合（小さい-これは状況であり、ファイルプロパティではないことを思い出してください）、ファイルを単一のデータとして扱う余裕がある場合、問題はありません-データベースに入れます-すべてがありますいいね ここで言及したプロジェクトで、名前を付けないで、なぜ成功したのですか？ ファイルの95％はそれぞれ64 KB未満であるため、これは常にデータベース内の1行であり、この状況ではすべてが正常に機能します。
  
  
  
  
• バージョン管理-必要ですか？ 実際、バージョン管理は必要ないが、バックアップが不要な場合があります。これらは、すべてのデータがロボットによって生成される場合です。 実際、ファイルストレージはキャッシュです。 オペレーターのエラーの余地はなく、失うものは何もありません。
  
  
  
  
• ストレージの大きさはどれくらいですか？ 単一のファイルシステムの機能がニーズを満たすのに十分であれば、非常に優れています。
  
  
  
  
• ファイルを削除しますか？ 奇妙なことに、これは重要です。 VKontakteが何も削除しないようなバイクがあります（実際、これはバイクではありません）。 そこに写真や音楽をアップロードするとすぐに、それは常にそこにあり、この情報へのリンクは削除されます。復旧はありません。 VKontakteでファイルが占有している場所の再利用はありません。 彼らは私がそのような報告を聞いたと言っています。 なんで？ 場所を再利用しようとするとすぐに、一貫性に重大な問題が発生するためです。 OCFS2がOracleデータベースに適合したのはなぜですか？ データベースに新しいデータを書き込むと、ファイルの最後に追加されるだけなので、場所は再利用されません。 場所を再利用したい場合は、CDを実行します。これが現代のOracleに当てはまるかどうかはわかりませんが、2001年にはそうでした。 コンパクトを実行します-これはオフライン操作であり、処理するファイルを排他的に所有するという事実により一貫性を保証します。 ディスク容量を再利用しますか？ 同じVKontakteが新しいディスクを突くのは普通のことで、そういうことだと思います。
  
  
  
  
• 負荷プロファイルはどうなりますか？ 読む、書く。 多くの分散ファイルシステムでは、書き込みパフォーマンスが非常に低下します。なぜですか？ アトミック操作のため、クラスター全体の同期操作のため、一貫性を確保するため。 NoSQLデータベースには、同期クラスター操作が1つしかありません。 通常、レコードバージョンを非難します。 データはないかもしれませんが、後で来るかもしれませんが、特定のレコードのバージョン、すべてのノード、誰もが同じことを考えるべきです。 そして、これはすべてのNoSLQには当てはまりません。たとえば、Cassandraはこれを気にしません。Cassandraはクラスター全体で同期操作を行いません。 読んでいるだけなら、クラスター化されたファイルシステムをいくつか試してみてください。 これらは、人々がやって来て、「なぜこれをすべてやったのか、ただLustreを使ってください」と言うときの成功物語です。 はい、あなたの状況では、Lustreは機能しましたが、私たちのものは機能しませんでした。
  
  

要件の一部の組み合わせ、一部のタスクでは、ソリューションは直接存在しますが、一部の組み合わせでは存在せず、実際には存在しません。 検索しても見つからなかった場合は、そこにないことを意味します。



結局何をすべきか？ 開始する場所は次のとおりです。

• これらの20万ユーロを2か月間当局に懇願し、それにもかかわらず彼らが与えられたとき、うまくやることができます。 ちょうど20万を請うのではなく、最初にベンダーに行って、あなたが請う必要がある金額を彼と計算し、それからさらに1.5倍を請います。
  
  
  
  
• まだすべてのファイルをデータベースに追加します-私はこのようにしました。 4億5千万個のファイルをデータベースに入れましたが、POSIXを必要とせず、ファイルの95％が小さいため、このトリックは成功しました。
  
  
  
  
• ファイルシステムを書くことができます。 最終的には、さまざまなアルゴリズムが存在します。ここでは、NoSQLデータベースの上に作成したアルゴリズムを使用します。他のアルゴリズムを使用できます。 Postgresql RDBMSの上に最初のバージョンを作成しましたが、ここでは、すぐにではなく、2年後にもいくつかの問題がありました。 実際、それほど難しくはありません。POSIXファイルシステムを作成することもそれほど難しくありません。FUSEを使用すれば、呼び出しはそれほど多くなく、すべて実装できます。 しかし、実際には、適切に機能するファイルシステムを作成することは困難です。
  
  

このレポートは、負荷の高いシステムHighLoad ++ Juniorの開発者のトレーニング会議で行われた最高のプレゼンテーションの1つです。 現在、2016年のカンファレンスである大人の兄弟を積極的に準備しています。今年は11月7日と8日にSkolkovoでHighLoad ++が開催されます。



今年は、データウェアハウジングに関する多くの興味深いトピックがありますが、ここで最も物議を醸す、猛烈なレポートがあります。

• 自転車はすでに発明されています。産業用ストレージは何ができますか？/アントンズバンコフ;
• Blu-rayに代わるアーカイブディスク：光学技術でアーカイブストレージを構築 / Alexander Vasiliev、German Gavrilov;
• Badoo / Artyom Denisov のストレージとアップロード写真のアーキテクチャ。

- HighLoad.Guide — , , , . 30 . !



, — " ". , :)