Museria - 분산형 음악 저장소

어느 날 나는 음악을 직접 선택하여 집/거리/운동 등에서 들을 수 있는 애플리케이션을 작성하기로 결정했습니다. 그리고 이 모든 것이 나의 참여를 최소화하면서 흐름에 따라 작동하도록 합니다. 아키텍처를 구상하고, 프로토타입을 스케치하다가 결국 하나의 '작은 문제'에 부딪혔습니다.

그리고 노래 파일 자체를 어디서 구할 수 있는지도 확실하지 않습니다. 이때까지 VKontakte는 이미 API를 닫았고 대규모 음악 포털에서는 모든 것이 음소거되었으며 심지어 노래도 구문 분석되지 않도록 조각으로 제공되었습니다. 남은 것은 수많은 광고와 온갖 종류의 쓰레기, 온갖 종류의 모호한 그래버 프로그램 및 기타 "더러운"옵션이 있는 개별 비행 사이트뿐이었습니다. 일반적으로 정말 좋은 솔루션은 하나도 없습니다. 물론 일부 Yandex 음악 등을 구독할 수도 있습니다. 하지만 다시 말하지만, 어디에도 공개 공개 API가 없으며 프로그래밍 방식으로 음악에 액세스할 수 없습니다. 몇몇 대기업은 본질적으로 다른 사람의 음악 액세스를 제한했습니다. 왜 이런 일이 일어 났습니까? 더 깊이 파고들자 주된 문제는 저작권이라는 것이 분명해졌습니다. 구독 형태의 현재 솔루션은 많은 상업 음악 작가와 동일한 회사에 적합합니다. 동시에 비상업적, 준상업적 음악도 일반 목록에 포함됩니다. 당신은 모든 비용을 지불하거나 전혀 듣지 않습니다.

그리고 나는 이 모든 것을 어떻게 해야 할지 생각하기 시작했습니다. 음악의 무료 배포를 어떻게 조직할 수 있나요? 내가 직접 음악을 만들고 그것으로 돈을 벌고 싶다면 어떻게 해야 할까요? 내 노래가 불법 복제되면 좋아할까요? 어쨌든 어떤 대체 솔루션이 있습니까?

결과적으로 해결해야 할 두 가지 주요 문제가 있습니다.

• 소프트웨어를 포함하여 대부분의 사람들에게 편리한 방법을 사용하여 음악을 무료로 배포합니다.
• 음악 창작자가 돈을 벌 수 있는 대안 제공

글로벌 분산형 음악 저장소

처음에는 기존 솔루션을 찾고 이를 기반으로 모든 것을 만들려고 노력했습니다. 한참을 검색한 끝에 가장 마음에 들었던 것은 ipfs. 나는 내 아이디어를 구현하기 시작했지만 얼마 후 이 솔루션에서 몇 가지 중요한 문제를 발견했습니다.

• Ipfs - 모든 것과 모든 사람을 위한 스토리지입니다. 이미지, 음악, 비디오 등 원하는 모든 것이 있습니다. 일반적으로 그러한 큰 행성 "쓰레기통"입니다. 따라서 노드를 시작하면 즉시 엄청난 로드가 발생합니다. 차가 아파서 몸부림칠 뿐입니다.
• 일종의 미완성 "쓰레기" 수집 메커니즘입니다. 지금은 어떤지 모르겠지만 그 순간에는 저장 공간을 XNUMXGB의 데이터로 제한하겠다고 구성에 썼다면 아무 의미가 없었습니다. 많은 구성 매개변수를 무시하고 스토리지가 증가했습니다. 결과적으로 ipfs가 불필요한 것을 재설정하는 방법을 알아낼 때까지 엄청난 양의 하드 디스크를 확보해야 했습니다.
• 라이브러리를 사용할 당시(지금은 어떤지 모르겠습니다) 클라이언트에 시간 초과가 구현되지 않았습니다. 파일 수신 요청을 보내고 파일이 없으면 그냥 멈춥니다. 물론 사람들은 문제를 부분적으로 해결하는 온갖 종류의 해결 방법을 생각해 냈지만 이것은 목발이었습니다. 이런 것들은 상자에서 나와야합니다.

여전히 사소한 문제가 많았고 인상은 분명했습니다. 프로젝트에 사용할 수 없습니다. 계속해서 저장 시설을 찾고 다양한 옵션을 모색했지만 적합한 곳을 찾지 못했습니다.

결국 저는 분산형 저장소를 직접 작성해 볼 가치가 있다고 결정했습니다. 행성 간 척하지 않더라도 특정 문제를 해결할 것입니다.

그래서 그것은 밝혀졌습니다 퍼질 수 있는, 저장고, 중퇴골, 무세리아, 뮤지리아-글로벌.

퍼질 수 있는 - 노드를 네트워크로 결합할 수 있는 기본, 최하위 계층입니다. 여기에는 제가 지금까지 약 10000대의 서버를 기반으로 부분적으로 구현한 알고리즘이 포함되어 있습니다. 알고리즘의 정식 버전은 구현하기가 훨씬 더 어려우며 추가로 몇 달(어쩌면 그 이상)이 필요할 것입니다.

이 글에서는 Spreadable에 대해 자세히 설명하지 않을 것이므로 언젠가는 별도로 작성하는 것이 좋습니다. 여기서는 몇 가지 기능만 언급하겠습니다.

• http/https를 통해 작동합니다.
• 특정 작업을 위해 별도의 네트워크를 생성할 수 있으며, 이는 모두 동일한 네트워크에 있을 때보다 각 개별 프로젝트의 로드를 크게 줄여줍니다.
• 시간 초과 및 기타 사소한 기능이 포함된 메커니즘은 처음에 고려되었습니다. 이는 클라이언트와 노드 모두의 모든 메소드에 적용됩니다. 애플리케이션 내에서 설정을 유연하게 관리할 수 있습니다.
• 라이브러리는 nodejs로 작성되었습니다. 스택의 성능 문제는 분산된 특성으로 인해 상쇄됩니다. 노드 수를 늘려 부하를 "확산"할 수 있습니다. 그 대가로 거대한 커뮤니티, 단순성과 사용 용이성, 동형 클라이언트, 외부 종속성 없음 등 많은 이점이 있습니다.

저장고 네트워크에 파일을 저장할 수 있게 해주는 Spreadable에서 상속된 레이어입니다. 각 파일에는 해당 내용에 대한 자체 해시가 있으며 나중에 검색하는 데 사용할 수 있습니다. 파일은 블록으로 나누어지지 않고 전체적으로 저장됩니다.

중퇴골 - Spreadable에서 상속된 레이어로, 네트워크에 데이터를 저장할 수 있지만 파일은 저장할 수 없습니다. 인터페이스는 Nosql 데이터베이스와 유사합니다. 예를 들어, 저장소에 파일을 추가하고, 해당 해시를 가져와서 링크와 함께 메타스토클에 쓸 수 있습니다.

무세리아 - 저장고와 후돌기에서 유전됩니다. 이 레이어는 음악 저장을 직접적으로 담당합니다. 저장소는 mp3 파일과 id3 태그로만 작동합니다.

노래의 "키"로서 전체 이름은 다음 형식으로 사용됩니다. 아티스트(TPE1) - 제목(TIT2). 예 :

• 유황 - 부담
• Hi-rez - Lost My Way (feat. Emilio Rojas, Dani Devinci)

노래 제목이 어떻게 구성되는지 최대한 자세히 알아볼 수 있습니다. 여기에. 기능을 살펴봐야 합니다 utils.beautifySongTitle().

노드 설정에 정의된 일치 비율은 일치로 간주됩니다. 예를 들어 값이 0.85이면 키 비교 기능(노래명)에서 85% 이상의 유사성을 찾았다면 동일한 노래라는 의미입니다.

유사성을 결정하는 알고리즘은 함수에 있습니다. utils.getSongSimilarity().

나중에 받을 수 있도록 노래 표지를 태그(APIC). 유틸리티에는 태그를 수신하고 처리하는 데 필요한 모든 방법이 있습니다.

클라이언트를 통한 스토리지 작업의 예는 다음에서 찾을 수 있습니다. 추가 정보.

위의 레이어는 모두 독립적이며 다른 프로젝트의 하위 레이어로 별도로 사용할 수 있습니다. 예를 들어, 책을 보관하기 위한 레이어를 만드는 아이디어가 이미 있습니다.

뮤지리아-글로벌 글로벌 음악 네트워크에서 자신의 노드를 시작하기 위해 이미 구성된 git 저장소입니다. 복제 npm 나는 && npm 시작하면 기본적으로 그게 다입니다. 좀 더 자세히 구성하고 Docker에서 실행하는 등의 작업을 수행할 수 있습니다. 자세한 정보는 다음에서 확인할 수 있습니다. 기타베.

저장소가 업데이트되면 노드를 업데이트해야 합니다. 주 또는 부 버전 번호가 변경되면 이 작업은 필수입니다. 그렇지 않으면 이전 노드가 네트워크에서 무시됩니다.

수동 및 프로그래밍 방식으로 노래 작업을 수행할 수 있습니다. 각 노드는 다양한 작업을 위해 서버를 실행합니다. 또한 기본 엔드포인트를 방문하면 음악 작업을 위한 인터페이스를 받게 됩니다. 예를 들어, 다음으로 갈 수 있습니다. 루트 노드 (링크는 나중에 관련이 없을 수도 있습니다. 입력 노드는 다음에서 얻을 수도 있습니다. 전보, 또는 Github에서 업데이트를 찾아보세요).

이렇게 하면 노래를 검색하고 저장소에 업로드할 수 있습니다. 노래 업로드는 일반 모드와 일반 모드의 두 가지 모드로 이루어질 수 있습니다. 두 번째 모드는 프로그램이 아닌 사람이 작업을 수행한다는 의미입니다. 그리고 추가시 이 체크박스를 체크하시면 보안문자를 풀어주셔야 합니다. 노래는 우선순위 -1, 0 또는 1로 추가할 수 있습니다. 우선순위 1은 중재 모드에서만 설정할 수 있습니다. 기존 노래를 새 노래로 교체하려고 할 때 스토리지가 어떻게 해야 할지 더 효과적으로 결정할 수 있도록 우선 순위가 필요합니다. 우선순위가 높을수록 기존 파일을 덮어쓸 가능성이 높아집니다. 이는 스팸을 방지하고 다운로드한 노래의 품질을 높이는 데 도움이 됩니다.

저장소에 노래를 추가하기 시작하면 이 필드가 필수는 아니지만 이미지(표지)를 첨부해 보세요. 99%의 경우 Google에서 노래 제목을 기반으로 한 첫 번째 이미지는 앨범 표지입니다.

기술적으로 파일을 추가하는 방법을 간단히 말하면 다음과 같습니다.

• 클라이언트는 한동안 코디네이터 역할을 할 무료 노드의 주소를 받습니다.
• 노래를 추가하는 기능이 (사람이나 코드에 의해) 실행되고 엔드포인트에 코디네이터를 추가하라는 요청이 이루어집니다.
• 코디네이터는 얼마나 많은 중복 항목을 저장해야 하는지 계산합니다(구성 가능한 매개변수).
• 저장에 가장 적합한 노드가 검색됩니다.
• 파일은 이러한 노드로 직접 이동됩니다.

기술적으로 파일을 받는 방법:

• 클라이언트는 한동안 코디네이터 역할을 할 무료 노드의 주소를 받습니다.
• (사람이나 코드에 의해) 노래를 수신하는 기능이 실행되고, 코디네이터의 엔드포인트에서 수신을 요청합니다.
• 코디네이터는 캐시에 링크가 있는지 확인합니다. 노드가 있고 작동 중이면 즉시 클라이언트에 반환되고, 그렇지 않으면 노드의 가용성이 폴링됩니다.
• 파일이 발견되면 링크에서 파일이 수신됩니다.

음악 창작자를 위한 대안

나는 많은 창작 작품의 가치를 어떻게 객관적으로 평가할 수 있는지에 대한 질문에 항상 관심을 가져 왔습니다. 예를 들어, 어떤 사람이 자신의 음악 앨범을 10달러에 제공하는 이유는 무엇입니까? 20달러든 100달러든 말이죠. 알고리즘은 어디에 있나요? 예를 들어, 일부 실제 제품이나 다양한 유형의 서비스에 대해 이야기할 때 최소한 비용을 계산하고 이를 진행할 수 있습니다.

좋아, 우리가 10달러를 걸었다고 가정해보자. 이것이 매우 효과적인가요? 내가 어딘가에서 앨범이나 그곳의 노래를 듣고 감사함을 표현하기로 결정했다고 가정해 보겠습니다. 하지만 내 감정과 능력에 따르면 3달러가 내 한도입니다. 그럼 우리는 어떻게 해야 할까요? 아마도 나는 대부분의 사람들처럼 아무것도 하지 않을 것입니다.

창의적인 작업에 대해 고정된 가격을 설정하면 자신을 제한할 수 있으며, 더 많은 사람이 적은 돈을 보내는 것을 방지할 수 있으며, 이는 전체적으로 귀하가 설정한 가격으로 구매하는 사람들보다 더 인상적일 수 있습니다. 제가 보기에는 창의성이 바로 기부가 가장 먼저 지배되어야 하는 영역인 것 같습니다. 이렇게 하려면 다음이 필요합니다.

• 사람들에게 이렇게 감사하도록 가르치십시오. 창작자 자신이 기부를 받고 싶다는 점을 명확하게 보여야 하며, 어디서나 다양한 결제 방법에 대한 링크를 추가해야 합니다.
• 이러한 프로세스를 단순화하고 강화하려면 더 많은 메커니즘이 필요합니다. 예를 들어, 저작권 링크를 사용하여 창의성을 위해 기부할 수 있는 일종의 글로벌 웹사이트를 만드세요.

  링크가 다음과 같다고 가정해 보겠습니다.

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

  음악가로 범위를 좁히면 다음과 같습니다.

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

  출연자는 자신의 닉네임을 확인하고 첨부해야 합니다.

  우리는 museria 클라이언트에 이러한 링크를 생성하는 기능을 추가하고 있으며 저장소를 사용하는 모든 프로젝트는 웹사이트/애플리케이션의 노래 옆에 이러한 링크가 포함된 기부 버튼을 배치할 수 있습니다. 사용자는 매우 빠르고 쉽게 기부할 수 있는 기회를 갖게 됩니다. 당연히 이 접근 방식은 스토리지를 통해서만이 아니라 모든 프로젝트 및 창의성 범주에 사용될 수 있습니다.

음악보관시설이 정확히 왜 필요하며, 어떻게 참여할 수 있나요?

• 음악과 관련된 프로젝트를 진행 중이거나 프로젝트를 만들 계획이라면 모든 것이 의도된 것입니다. museria를 사용하여 노래를 저장하고 검색하여 온라인에서 노래의 흐름을 높일 수 있습니다. 동시에 자신의 노드를 하나 이상 키우고 보유할 수 있는 능력이 있다면 이는 네트워크 개발에 가장 큰 기여가 될 것입니다.
• 아마도 당신은 다른 역할을 맡을 준비가 되어 있을 것입니다: 코드에 대한 도움, 데이터베이스 작성 및 조정, 프로젝트에 대한 정보를 친구에게 배포 등.
• 어쩌면 당신은 아이디어가 마음에 들었고 모든 것이 살아 있고 발전할 수 있도록 재정적으로 도울 준비가 되어 있을 것입니다. 노드가 많을수록 노래가 많아집니다.
• 아니면 어느 시점에서 노래를 찾아서 다운로드하면 됩니다. 예를 들어 다음을 통해 매우 간단하게 이 작업을 수행할 수 있습니다. 텔레그램 봇.

이 프로젝트는 이제 시작 단계에 있습니다. 테스트 네트워크가 시작되었으며 노드가 자주 재부팅되고 업데이트가 필요할 수 있습니다. 평가 기간 동안 심각한 문제가 없으면 동일한 네트워크가 기본 네트워크로 전환됩니다.

다음과 같은 링크를 사용하여 외부에서 노래 수, 여유 공간 등 노드에 대한 정보를 볼 수 있습니다. http://node-address/status 또는 http://node-address/status?pretty

내 연락처 :

• @ortex
• [이메일 보호]
• 영어로 된 전보 그룹.
• 글쎄요, 이 모든 아이디어를 탄생시킨 웹사이트입니다.

출처 : habr.com