Githubをカスタムデータウェアハウスとして使用する

データを保存するためのサービスを選択する際に重要なコンポーネントは、サービスの持続時間です。 プロジェクトの作者の熱意がホスティングとデータベースのために支払うお金で終わったとしても、私は少なくとも保存されたデータを読むことができることが彼から必要です。 私のプロジェクトのこのアプローチでは、ユーザーデータを無料で保存できるデータベースサービスを探していました。 有望なプロジェクトはParse.comで、これについては以前の記事「バックエンドのないサイト」で書きました。 しかし、2016年1月に、Parse.comは1年しか存続せず、閉鎖されることがわかりました。 この点で、ユーザーデータのストレージをGithubで公開されているgitリポジトリに転送することにしました。

サービススキーム

ユーザー<=> GitHubページ<=>有料VDS上の個別のAPI <=>同じVDS上のSSD上のgitリポジトリ<=> GitHub上のリポジトリ

上記の基準による重大な欠点は、有料VDSのAPIであり、いつかは永久に利用できなくなる可能性があります。 しかし、チェーン全体のおかげで、人間の形式とGithubでの機械可読の両方でデータを取得することが可能になります。 Github PagesのユーザーはJavaScriptを介してAPIと通信するため、プロジェクトのメインページは引き続き使用可能です。 何らかの理由でGithubをリンクから除外する必要がある場合は、すべての作業を別のホスティングリポジトリ（Bitbucketなど）に転送できます。

APIの代わりにプルリクエストシステムを使用しませんか？ 私は3つの理由を見つけました：

1. ユーザーはGithubのgitとPRシステムに精通している必要があります。
2. PRのユーザーが自分のファイルのみに影響することを確認して、承認システムを開発する必要があります。
3. とにかく、マークダウンファイルを再構築する別のサーバーが必要です。 それらを拒否しないでください。

その結果、サーバー上のコードを使用したソリューションは避けられないという結論に達しました。 このようなサーバーパーツとGithubの通信は、gitを介してのみ行われます。 sshキーを使用してGithubをプッシュすると、プロセスが簡単になります。

正当性

そのようなデータの構造について考えた後、この目的のためにGithubを使用することの正当性を研究しました。 問題に直接関係するサービス条件をより詳細に検討してみましょう。

A. 2

あなたは人間でなければなりません。 「ボット」または他の自動化された方法で登録されたアカウントは許可されていません。

Githubでリポジトリをプッシュするためのアカウントを手動で作成する必要があります（同時に有効なメールで）。

A. 4

あなたのログインは1人だけが使用できます。つまり、1人のログインを複数の人が共有することはできません-ただし、マシンのユーザーのアクションは複数の人によって指示される場合があります。 あなたの計画が許す限り多くの人々のために別々のログインを作成するかもしれません。

A. 7

1人の個人または法人は、複数の無料アカウントと、自動化タスクの実行専用に使用される1つのマシンユーザーアカウントを保持できません。

コミット（コミット）およびプッシュ（プッシュ）のすべてのアクションは、1つのアカウントから実行されます。 ただし、このようなアクションは自動化されているため、 machine user



の説明に適合します。

G. 12

帯域幅の使用量が他のGitHubの顧客の平均帯域幅使用量（GitHubによってのみ決定される）を大幅に超える場合、帯域幅の消費を削減できるまで、アカウントを直ちに無効にするか、ファイルホスティングを調整する権利を留保します。

プロジェクトはテキストファイルを使用し、プッシュは短い間隔でスケジュールに従って行われます。 実際には、この段落は違反されるべきではありません。

その他の推奨事項

一部の資料の Githubは追加情報を提供します。

リポジトリはそれぞれ1GB未満に保つことをお勧めします。 この制限は、大きなファイルがリポジトリに保持されない場合、簡単に維持できます。 リポジトリが1GBを超える場合、リポジトリを元に戻すためにリポジトリのサイズを小さくすることを要求する丁寧な電子メールをGitHubサポートから受信する場合があります。

さらに、サイズが100 MBを超えるファイルの厳密な制限を設けています。

理論的には、この部分は問題になる可能性があります。 読書用の会計サービスの2年間で、約8,000件の記録が保存されました。 リポジトリのサイズは約7 MBです。 最大ファイルのサイズは約500 KBです。これは、レコードのインデックスを持つサービスファイルです。 サービスには、送信されたテキストの長さに制限があり、意図したとおりにサービスを使用するため、すぐに制限を超えることはありません。 将来的には、シャーディングのオプションを検討できます。

そこでGithubは、バックアップを保存する手段または大きなsqlファイルを保存する手段として（git自体のように）設計されていないと言っています。 sqlファイルを保存する手段としてGithubを使用しません。データ構造が異なります。 また、データはマシンだけでなく人によってもGithub自体で読み取り可能である必要があるため、このような構造を純粋なバックアップと呼ぶこともできません。

データ構造

gitリポジトリに保存できる機能的で冗長ではないデータ構造の作成は、特定のプロジェクト内でのみ実行できます。 おそらく、この側面の設計に対する何らかの普遍的なアプローチを説明できますが、最も必要なものだけを残して最終バージョンを説明します。

そのため、Bookbookプロジェクトでは、ユーザーに関する情報（ID、エイリアス、最終更新日、そして最も重要なことには、彼が読んだ本のリスト）を保存する必要があります。 読んだ本について、ID、タイトル、著者、読書日、ユーザーのメモ、最終更新日を保存します。 このプロジェクトのアイデアは、ユーザーが自由な入力で本を好きなように表示することです。 これにより、既存のすべての書籍のレジストリを使用できなくなります。 つまり、各書籍のエントリは、それを作成したユーザーにのみ関連しています。

Jsonは、冗長性とgit-storageのアイデアとの良好な互換性のためにデータ形式として選択されました。 各json値を別々の行に保存すると、Githubで視覚的な差分を取得できます。

ユーザーとその書籍の他に、まだ何も保存する必要がないため、ユーザーの名前idを持つユーザーごとに個別のディレクトリを作成します。 このディレクトリ内に、基本的なユーザー情報を含むjsonファイルを保存します。 ブックディレクトリはここにあり、その中には、ブックIDをファイル名として持つ各ブックの個別のjsonファイルが格納されています。

補助ファイルについて考えてみましょう。 読んだ本に関する各レコードは特定のユーザーに関連しているという事実にもかかわらず、APIはそのIDで本をすばやく受信する必要がありました。 本の索引である補助ファイルを作成するパスをたどりました。 これは、IDとブックエントリへのフルパスを含むcsvファイルです 。 このようなファイルの作成は、特定のユーザーのコンテキストで書籍を検索する場合（ユーザーディレクトリでファイルを検索するのにさらに時間がかかる場合）、または一部がユーザーID（ID冗長性および非アトミック性）を持つ複合IDを作成する場合は回避できます。

次のヘルプファイルは、 latest_books.jsonおよびlatest_books_with_notes.jsonです。 投稿された最近の一定数の書籍に関する情報と、最近登録された一定数のユーザーを含むlatest_users.jsonが保存されます。 彼らのおかげで、このサービスはメモ付きの最新の追加書籍と最後のアクティブなユーザーを表示できます。

Githubを使用しているため、マークダウンを使用してリポジトリ自体に情報を表示できます。 これを行うには、新しい情報が追加されるたびに、上記のjsonファイルに基づいてREADME.mdファイルと、 latest_books_with_notes.mdを個別に再アセンブルします。 そして最も重要なことは、ユーザーが読んだもののリストを使用してユーザーページ自体を再構築できることです。

パスの1つのレベルでオブジェクトが多くなりすぎないように、最初のID文字でユーザーディレクトリをグループ化しました。

認証と承認

Parse.comとは異なり、パスワードを保存する方法はありませんが、それでも認証にuLoginを使用しました。これは、ユーザーからの登録を必要とせずに、多数のソーシャルネットワークとサイトを組み合わせます。 uLoginの操作は非常に簡単です。 ログインに成功した後、アクセストークンをクライアントに渡します。このトークンをサーバーに送信し、uLoginサーバーにリクエストを送信してトークンを検証し、ネットワークプロバイダーの名前やその中のユーザーIDなどの有用な情報を取得する必要があります。 この情報を使用して、選択したソーシャルネットワークでユーザーのデータをアカウントに直接バインドできることが判明しました。 これは、uLoginが終了した場合、同様のサービス（独自のサービスを含む）に置き換えることができることを意味します。 したがって、ユーザーIDとして、id-providerという形式の結合ID（ 83820536-yandex



など）を使用することにし83820536-yandex



。 このアプローチにより、どこでも非公開データのストレージに関する制限が回避されました。

サービスを計画するとき、ユーザーがソーシャルネットワークにアクセスできなくなるシナリオを想定しました。 このシナリオは、ロシア連邦でのLinkedInのブロックに関連して最近実現されました。 ユーザーがヘルプを要求しました。 「別のアカウントからレコードをコピー」機能がプロジェクトに登場しました。 すべてのデータが公開されているため、少なくとも誰かが自分自身を少なくとも誰かのリストをコピーできるという事実に害はありません。 ユーザーが「自分で足を撃たない」ように、いくつかの制限を追加することは合理的です。 その結果、ユーザーはコピー機能を使用してレコードにアクセスできるようになりましたが、現在はVKを介してサービスにログインしています。

次に、APIを使用する際のユーザー認証の問題について説明します。 開発の最初の段階で、認証後にユーザーIDがバインドされたランダムアクセストークンを作成し（接続自体はアプリケーションキャッシュに保存されました）、トークンはクライアントに返されました。 彼は、APIへのすべてのリクエストにそれを含める必要がありました。 しかし、将来はセッションとCookie（Cookie）の使い慣れたメカニズムに注目しました。 クッキーには良い利点があることが判明しました。 最初に、HttpOnlyをインストールできます。 この利点によりすべてのXSS攻撃が排除されたとは限りませんが、少なくとも1つのシナリオが少なくなりました。 第二に、クライアントがブラウザのjs上にある場合、Cookieは自動的に送信されますが、これはまさに私たちの場合です。

サーバー側のフレームワークの多くは、長期間有効なCookieを使用して「記憶」メカニズムを非常に簡単に実装できます。 その上で、彼はユーザーセッションをピックアップします。 追加の承認手順は、フレームワークのフレームワーク内で行われます。 もちろん、 ファイルシステムにデータを保存するためのエンティティとメカニズムを定義する必要がありますが、これはデータ構造に大きく依存します。 gitコミットのトランザクションの類似性を提供する必要があるとだけ言っておきましょう。 これにより、複数のエンティティの変更を1つのコミットにまとめることができます。

メリット

• 無料で

  
  
  
  
  
  
  

• すべての変更の履歴

  
  
  
  
  
  
  

• 準備変更ロールバックシステム

  
  
  
  
  
  
  

• すべてのデータの完全なコピーを迅速に取得する機能

  
  
  
  
  
  
  

• GitHub生データを使用して、APIをバイパスしてデータフラグメントを取得できます。

  
  
  
  
  
  
  
• 耐久性

短所

読み取りおよび書き込み速度 。 ホスティングにSSDを使用すると状況が明るくなりますが。 DigitalOceanをホストするssd： refをお勧めします。 ボーナスとリンクします。

スケーリングに問題があるかもしれません。 ポップとプルは、ストレージをリアルタイムで同期するには速すぎる操作ではありません。 おそらく、ユーザーによるシャーディングが役立つでしょう。

検索エンジン最適化の問題は未解決です。 Github Pages + Angularのプロジェクトでは、検索エンジンにはこれが表示されません。 おそらく、マークダウンファイルにインデックスが作成されるか、レコードがエクスポートされるソーシャルネットワーク上のページにインデックスが作成されます。

検索を実装するには、余分な労力が必要です。

Githubのマークダウンページのローカライズサポートはありません。 データの複製が役立つ場合がありますが、それほどきれいではありません。

おなじみのクエリ言語はありません。 受信と録音は、かなり低いレベルで独立して実装する必要があります。

おわりに

Githubをデータウェアハウスとして使用するプロジェクトは、実績があります。 記事の公開日現在、彼は3か月以上働いています。 おそらく、すべてがバラバラになったわけではありません。深刻な負荷やcな男がいなかったからです。 あるいは、少なくとも小さなプロジェクトでは、アイデアは実行可能です。

読んだ本のリストをどこに保存できるかまだわからないが、過去1年間にその本に関するレポートを編集したい場合は、歓迎します。

プロジェクトのすべての部分のソースコード：

• ユーザーとリポジトリ間の通信用のAPI （bitbucketからコピーするため、1つのコミット）
• クライアントサイト
• データウェアハウス