1.5 MB Habrネットワークファイルシステム

おそらく誰もが知っているわけではありませんが、Habrは、サーバー上のデータストレージをすべての登録ユーザーに提供することで、マーケットリーダーに遅れをとっていません。 GoogleやYandexほど大きくはなく、メガバイトだけですが、サイトに関連付けられた多数のドラフト記事やその他のデータを保存できるので、スクリプトでクロスドメインアクセスなしでそれらをサイト資料と一緒に使用できます。 すべてのニーズに対して、1 MBのUnicode文字のみが必要であると想定しています。 システムは何を提供しますか?



利用可能なタイプとボリューム:



1)ドラフト記事の形式(著者のみが閲覧可能)。 各ドラフトには少なくとも10万文字が格納されます。 下書き-条件付きで無制限の量。



2)ユーザーへのメモの形式(作成者にのみ表示されますが、ユーザーがアカウントを閉じたときに脆弱性、リーク、削除を保証するものはありません)。 1つのメモには最大65535文字が保存されます。 注-作成者と同数(ただし、システムノートの数の制限は確認されていません)。 自分にメモを書くことはできません。



3)対談者へのプライベートメッセージ。 (自分に書き込むことはできません)。



4)個人ページの最大65 Kのパブリックメッセージ(パブリックであることに加えて、第3レベルの別の隣接ドメインにもあります)。



5)(少し公的に(s))、habrastorageファイルで、だれにも名前を言わないなら、あなたは非常にコンパクトにそしてほとんど気付かないほど多くのデータを保存することができます。 ただし、いつ削除されるかはわからないため、すべてのバージョンがすべてのユーザーに無期限に読み込まれます。



ブラウザのlocalStorage APIをほぼ参照するために、これらの豊富な機能をドライバーに記述することは残っています。 データ配布を有効にするには、最適化プラグマ(使用する将来の形式の指示)が必要になります。



これらの方法は、下書きや個人メッセージを誤って他人に公開する場合を警告なしに考慮しない限り、他の読者に不便をもたらすことはありません。 個人ページでの公開メッセージの公開でさえ、HTMLタグで隠すことができ、読者には見えません。



使い方は?



合計で1 MBのキャラクターを保存するには、16個のノートまたは10個(またはそれ以下)の下書きが必要です。 最もエラー保護された方法は、メモを作成することです。 したがって、ドラフトにはより大きな情報ブロックが格納される可能性がありますが、他の方法は検討しません。



それどころか、大きな情報ブロックが常に必要なわけではありません。 ほとんどの場合、それらは小さく、ここではノートも勝ちます。なぜなら、それらは限られたサイドバーで表示され、下書きは完全なサイドバー(読み取りモード)で表示されるからです。 全体として、ストレスの少ない設計、不要なトラフィックが判明しました。



リスト内のメモが最初のN文字ではなく、完全に表示されるのはあまり便利ではありません。 これは、メモをダンプする場合や、完全な読み取りの別の理由がある場合に便利です。 ただし、各ノートの最初に保存できるインデックス情報を表示するのは不便です。 しかし、これはそうではないため、インデックスに1-2ノート(実際のディスクシステムのようにインデックスを複製するために2つ)を選択し、ほとんどの場合、事前にそれらのユーザー名を知って個々のノートのみを読み取ります。



その後、16個のユーザー名を選択し、場合によっては、インデックスファイルのコンテンツ用に個人用の読み取り専用アカウントを作成して、削除されないようにします。 小さいながらも実際のボリュームを読み取る必要がある場合があるため、ファイルシステムのいくつかのアカウントを小さいファイルに割り当てる必要があります。 すべてのアカウントに大きなメモが含まれるわけではありません。 1つの長い行に書き込み、1行の不変データを強制的に読み取るよりも、数倍多くのアカウント名を持っている方が有利です。 したがって、ファイルシステムでは、16の数倍のアカウント名を準備する必要があります。たとえば、100。



重複したインデックスのペアには、アカウント名ごとのファイルの分布のテーブルが含まれます。



誰かの名前を使用しても、アカウント所有者が「ロード」されるわけではないことに注意してください。 彼らにとって、メモは存在しません。これはユーザーの個人情報です。 正式には-それらについてですが、実際には-任意です。 ユーザーは、アカウントを削除することでファイルを破損できます。 管理者は、ユーザーアカウントを削除するか、メモを削除することで同じことを実行できます。



信頼性のため、およびアカウントのないユーザーに対して同じシステムを維持するには、メモを保存するためのバックアップサーバーが必要です。 20〜100個のテキストファイルのシステムを維持すると、このメガバイトの情報を扱う作業が大幅に簡素化されます。 実際、ブラウザのローカルストレージに似た高度に構造化された情報ですが、ネットワーク上にあります。 単一レベルの構造(ハッシュ、辞書)へのアピールを通じて、同じ原則でそれを扱うことが可能になります。 その中の行は、構造をシリアル化できます。



ファイルシステム全体がJS上で実行され、Ajaxリクエストを介して実行されます。



継続しますが、今のところは、この無料ホスティングの所有者への要望を策定します。リリースまでに何かを完成させる時間があるかもしれません。

1.インデックス(100〜300文字)として使用するために、テキストの先頭からノートのリストを編集することが非常に望ましい。

2. aa00..aa99のような計算された名前を持つ100人の非リムーバブルユーザーのリストを用意します。

3.登録せずにリストとメモを読むモードがあります-各リクエストで18Kバイトを節約してください!

4.ストーリーから画像を作成者に削除して、公開データとして使用できるようにします。たとえば、画像の形式で記事を書き、修正やコメントを公開します。 その後、記事のテキストを展開し、バイナリイメージデータから修正するためのスクリプトがあれば十分です。 スクリプトのユーザーだけが読むことができるので、この形式は開発者の間で一般的になり、電話レビューの割合は写真で減少します。

5.ノートページに負担をかけないように、非表示の入力でデータを複製しないでください。



交渉と承認は行われますが、少なくとも記載されている既存のサイト機能を使用して、ファイルシステムのドライバーを作成することができます。 それらはクロスドメインであるため、サイトの容量を使用しなくても、同様の形式で別のドメインのストレージの動作を妨げることはありません。



プロジェクトはクラウドソーシング( このような )です。コードはGithubに投稿されます。 実用的なタスクとして、読者には質問が残されています。

1.システムが保持する1つのLANメッセージの最大音量は?

2.ドラフトでサポートされる記事の最大サイズはどれくらいですか? (100Kが保存されていることを確認しました。)

3.合計で保存できるプライベートデータの最大量はいくらですか?



All Articles