Museria - 分散型音楽ストレージ

ある日、私は自分で音楽を選択し、自宅、路上、トレーニングなどで聴くためのアプリケーションを作成することにしました。 そして、私の参加を最小限に抑えながら、これらすべてが流れの中で機能するようにします。 私はアーキテクチャを思いつき、プロトタイプのスケッチを描き、最終的に XNUMX つの「小さな問題」に遭遇しました。

また、曲ファイル自体をどこで入手できるのかも明確ではありません。 この時までに、VKontakteはすでにAPIを閉鎖しており、大規模な音楽ポータルではすべてがミュートされており、解析されないように曲さえも断片的に提供されていました。 残ったのは、大量の広告とあらゆる種類のゴミ、あらゆる種類の疑わしいグラバープログラム、その他の「汚い」オプションを備えた個別のサイトだけでした。 一般に、本当に優れたソリューションは XNUMX つもありません。 もちろん、Yandex の音楽などのサブスクリプションを購入することもできます。 しかし、繰り返しになりますが、オープンなパブリック API はどこにも存在せず、プログラムから音楽にアクセスすることはできません。 いくつかの大企業は、他人の音楽へのアクセスを基本的に制限しています。 そもそもなぜこんなことが起こったのでしょうか？ さらに深く掘り下げていくと、主な問題は著作権であることが明らかになりました。 サブスクリプションという形式の現在のソリューションは、多くの商業音楽作者やこれらの同じ企業に適しています。 同時に、非営利および半営利の音楽も一般リストに含まれます。 すべての料金を支払うか、まったく何も聞かないかのどちらかです。

そして私はこれらすべてをどうするかを考え始めました。 音楽の無料配布をどのように組織できるでしょうか? 自分で音楽を作成していて、それでお金を稼ぎたい場合はどうすればよいでしょうか? 私の曲が海賊版になったら嬉しいですか? とにかく、どのような代替ソリューションがあるのでしょうか?

その結果、解決する必要がある主な問題が XNUMX つあります。

• ソフトウェアを含む、ほとんどの人にとって便利な方法を使用した音楽の無料配布の組織。
• 音楽クリエイターがお金を稼ぐための代替手段を提供する

グローバルな分散型音楽ストレージ

最初は、既存のソリューションを見つけて、これに基づいてすべてを作成しようとしました。 しばらく探した結果、最初に気に入ったのが、 ipfs。 私は自分のアイデアを実装し始めましたが、しばらくすると、このソリューションにいくつかの重大な問題があることがわかりました。

• Ipfs - すべてのものとすべての人のためのストレージ。 画像、音楽、ビデオなど、必要なものがすべてあります。 一般に、このような大きな惑星の「ゴミ箱」。 したがって、ノードを起動すると、すぐに大きな負荷がかかります。 車はただ痛みに悶えているだけだ。
• ある種の未完成の「ガベージ」収集メカニズム。 今はどうなっているのかわかりませんが、その時点では、ストレージを XNUMX ギガバイトのデータに制限したいと設定に書いたとしても、それは何の意味もありませんでした。 多くの構成パラメータを無視して、ストレージが増大しました。 その結果、ipfs が不要なものをリセットする方法を見つけるまで、膨大な量のハードディスクを確保する必要がありました。
• このライブラリを使用していた時点では (現在はどうかはわかりませんが)、クライアントにはタイムアウトが実装されていませんでした。 ファイルを受信するリクエストを送信し、ファイルが存在しない場合はハングするだけです。 もちろん、人々は問題を部分的に解決するあらゆる種類の回避策を考え出しましたが、それらは松葉杖でした。 これらは箱から出して出てくるはずです。

まだ小さな問題が多く、これではプロジェクトに使用できないという印象が明確でした。 私は保管施設を探し続け、さまざまな選択肢を検討しましたが、適切なものは見つかりませんでした。

最終的に、私は分散ストレージを自分で書いてみる価値があると判断しました。 たとえそれが惑星間であるかのように装っていないとしても、それは特定の問題を解決するでしょう。

それで判明しました 拡散可能, 倉庫, 胸郭, ムセリア, ムセリアグローバル.

拡散可能 - これは、ノードをネットワークに結合できるようにするメインの最下層です。 これにはアルゴリズムが含まれており、これまでに約 10000 台のサーバーに基づいて部分的に実装しました。 アルゴリズムの完全版は実装がはるかに難しく、さらに数か月 (おそらくそれ以上) を必要とします。

スプレッドブルについてはこの記事では詳しく説明しません。いつか別の記事で書くとよいでしょう。 ここではいくつかの機能に注目します。

• http/https 経由で動作します。
• 特定のタスクに対して個別のネットワークを作成できます。これにより、すべてのプロジェクトが同じネットワーク上にある場合よりも、個々のプロジェクトの負荷が大幅に軽減されます。
• タイムアウトやその他の小さな機能を備えたメカニズムが最初に考えられました。 これは、クライアントとノードの両方のすべてのメソッドで機能します。 アプリケーション内から設定を柔軟に管理できます。
• ライブラリはnodejsで書かれています。 スタックのパフォーマンスの問題は、その分散型の性質によって相殺されます。 ノードの数を増やすことで負荷を「分散」できます。 その代わりに、巨大なコミュニティ、シンプルさと使いやすさ、同型クライアント、外部依存関係がないなど、多くの利点があります。

倉庫 これは、ネットワーク上にファイルを保存できるようにする、spreadable から継承されたレイヤーです。 各ファイルには内容の独自のハッシュがあり、後でファイルを取得するために使用できます。 ファイルはブロックに分割されず、全体が保存されます。

胸郭 - Spreadable から継承されたレイヤー。ネットワーク上にデータを保存できますが、ファイルは保存できません。 インターフェイスは Nosql データベースに似ています。 たとえば、ファイルを storacle に追加し、そのハッシュを取得して、それを何かへのリンクとともに metastocle に書き込むことができます。

ムセリア - 胸郭と後胸郭から継承されます。 この層は音楽の保存を直接担当します。 ストレージは mp3 ファイルと id3 タグでのみ機能します。

曲の「キー」として、フルネームが次の形式で使用されます。 アーティスト (TPE1) - タイトル (TIT2)。 例えば、

• ブリムストーン - ザ・バーデン
• ハイレゾ - ロスト・マイ・ウェイ (feat. エミリオ・ロハス、ダニ・デヴィンチ)

曲名がどのように形成されるのかを可能な限り詳細に知ることができます。 ここで。 機能を確認する必要があります utils.beautifySongTitle().

ノード設定で定義された一致の割合が一致とみなされます。 たとえば、値 0.85 は、キー比較関数 (曲名) で 85% を超える類似性が見つかった場合、それが同じ曲であることを意味します。

類似性を判断するためのアルゴリズムは関数内にあります。 utils.getSongSimilarity().

後で受け取るために、曲のカバーをタグ経由で添付することもできます (APIC）。 ユーティリティには、タグを受信して​​処理するために必要なすべての方法が備わっています。

クライアントを介してストレージを操作する例は、次の場所にあります。 README.

上記のレイヤーはすべて自己完結型であり、他のプロジェクトの下位レイヤーとして個別に使用できます。 例えば、本を収納するための層を作るというアイデアはすでにあります。

ムセリアグローバル は、グローバル ミュージック ネットワークで独自のノードを起動するための構成済みの Git リポジトリです。 クローン作成 npm i && npm 始めて、基本的にはそれだけです。 さらに詳細に設定したり、Docker で実行したりできます。 詳細な情報は次のサイトで入手できます。 ギタベ.

リポジトリが更新されたら、ノードを更新する必要があります。 メジャー バージョン番号またはマイナー バージョン番号が変更された場合、このアクションは必須です。そうでない場合、古いノードはネットワークによって無視されます。

曲は手動でもプログラムでも操作できます。 各ノードは、さまざまなタスクのためにサーバーを実行します。 たとえば、デフォルトのエンドポイントにアクセスすると、音楽を操作するためのインターフェイスが表示されます。 たとえば、次の場所にアクセスできます。 ルートノード (リンクは後で関係なくなる可能性があります。入力ノードは次の方法でも取得できます) 電報、または Github で更新を探します)。

このようにして、曲を検索してストレージにアップロードできます。 曲のアップロードは、通常モードとモデレートモードの 1 つのモードで実行できます。 0 番目のモードは、作業がプログラムではなく人間によって実行されることを意味します。 追加するときにこのボックスをチェックすると、キャプチャを解決する必要があります。 曲は優先度 -1、1、または XNUMX で追加できます。優先度 XNUMX はモデレート モードでのみ設定できます。 既存の曲を新しい曲に置き換えようとするときに、ストレージが何をすべきかをより効果的に決定できるように、優先順位が必要です。 優先順位が高くなるほど、既存のファイルが上書きされる可能性が高くなります。 これはスパムと闘い、ダウンロードされた曲の品質を向上させるのに役立ちます。

ストレージに曲を追加し始める場合は、画像 (カバー) を添付してください。ただし、このフィールドは必須ではありません。 99% の場合、曲のタイトルに基づいて Google に表示される最初の画像はアルバム カバーです。

ファイルの追加が技術的にどのように行われるかを簡単に説明すると、次のようになります。

• クライアントは空きノードのアドレスを受け取り、そのノードがしばらくの間コーディネーターになります。
• 曲を追加する機能が (人またはコードによって) トリガーされ、エンドポイントにコーディネーターを追加するリクエストが行われます。
• コーディネーターは、保存する必要がある重複の数を計算します (構成可能なパラメーター)。
• 保存に最適なノードが検索されます。
• ファイルはこれらのノードに直接送信されます。

ファイルが技術的にどのように受信されるか:

• クライアントは空きノードのアドレスを受け取り、そのノードがしばらくの間コーディネーターになります。
• (人またはコードによって) 曲を受信する機能がトリガーされ、コーディネーターのエンドポイントで曲を受信するリクエストが行われます。
• コーディネーターは、キャッシュ内にリンクが存在するかどうかを確認します。 存在し、それが動作している場合は、すぐにクライアントに返されます。そうでない場合は、可用性についてノードがポーリングされます。
• ファイルが見つかった場合は、リンクからファイルを受信します。

音楽クリエイターのための代替手段

私は、多くの創作物の価値をどうやって客観的に評価できるのかという疑問に常に興味を持っていました。 たとえば、なぜ人は自分の音楽アルバムを 10 ドルで提供するのでしょうか? 20ドルか100ドルのどちらかです。 アルゴリズムはどこにあるのでしょうか? たとえば、ある物理的な製品やさまざまな種類のサービスについて話している場合、少なくともコストを計算し、そこから進めることができます。

さて、10 ドルを賭けたとしましょう。 これはとても効果的ですか？ どこかのアルバムかそこに収録されている曲を聴いて、感謝の気持ちを伝えようと思ったとします。 しかし、私の感情と私自身の能力によると、3ドルが私の上限です。 だから何をすべきか？ おそらく、ほとんどの人と同じように、私は何もしないでしょう。

クリエイティブな作品に一定の固定価格を設定することで、自分自身を制限するだけで、より多くの人があなたに送金する金額が少なくなるのを防ぐことができ、合計すると、設定した価格で購入する人よりも優れた効果を得ることができます。 私には、創造性こそが寄付が最初に支配されるべき領域であるように思えます。 これを行うには、次のものが必要です。

• このように感謝することを人々に教えてください。 クリエイター自身が、寄付を受け取りたいこと、さまざまな支払い方法へのリンクをあらゆる場所に追加することなどを明確に示す必要があります。
• これらのプロセスを簡素化し強化するには、さらに多くのメカニズムが必要です。 たとえば、著作権リンクを使用して創造性のために寄付できる、ある種のグローバル Web サイトを作成します。

  リンクが次のようなものであるとします。

  http://someartistsdonationsite.site/category/artist?external-info

  ミュージシャンに絞ると次のようになります。

  http://someartistsdonationsite.com/music/miyagi?song=blabla

  出演者は自分のニックネームを確認し、それに付ける必要があります。

  このようなリンクを生成する機能を museria クライアントに追加しており、リポジトリを使用するすべてのプロジェクトは、Web サイト/アプリケーション上の曲の横にこれらのリンクを含む寄付ボタンを配置できます。 ユーザーは非常に迅速かつ簡単に寄付を行うことができます。 当然のことながら、このアプローチはストレージだけでなく、あらゆるプロジェクトや創造性のカテゴリーに使用できます。

正確に音楽ストレージ施設が必要な理由は何ですか?また、それに参加するにはどうすればよいですか?

• あなたが音楽関連のプロジェクトに取り組んでいる場合、またはその作成を計画している場合、これがすべての目的です。 museria を使用して曲を保存および取得できるため、オンラインでの曲の流れが増加します。 同時に、少なくとも XNUMX つの独自のノードを構築して保持する能力があれば、これがネットワークの発展に最大限の貢献となるでしょう。
• おそらく、コードを手伝ったり、データベースに入力して管理したり、プロジェクトに関する情報を友達に配布したりするなど、他の役割を引き受ける準備ができているかもしれません。
• おそらくあなたはそのアイデアが気に入って、すべてが存続し発展するように経済的に支援する準備ができているでしょう。 ノードが多いほど、曲も多くなります。
• または、ある時点で曲を見つけてダウンロードする必要があります。 これは、たとえば次のように非常に簡単に行うことができます。 電報ボット.

プロジェクトは現在、まさに初期段階にあります。 テストネットワークが起動され、ノードが頻繁に再起動したり、更新が必要になる場合があります。 評価期間中に重大な問題がなければ、この同じネットワークがメインのネットワークに変換されます。

次のようなリンクを使用して、曲数、空き容量などのノードに関する情報を外部から表示できます。 http://node-address/status または http://node-address/status?pretty

私の連絡先：

• @オルテックス
• [メール保護]
• 英語の電報グループ。
• そう、このアイデア全体を生み出したウェブサイトです。

出所： habr.com