Storacle — decentraliseret filopbevaring

Storacle — decentraliseret filopbevaring

Før jeg begynder, vil jeg efterlade et link til den tidligere artikel, så det er klart, hvad det handler om.

I denne artikel vil jeg gerne gennemgå det lag, der er ansvarligt for filopbevaring, og hvordan det kan bruges af enhver. Storacle — et selvstændigt bibliotek, der ikke har nogen direkte forbindelse til musik. Det er muligt at organisere opbevaring af enhver type filer.

I den tidligere artikel var jeg lidt kritisk overfor ipfs, men det skete netop i konteksten af den opgave, jeg arbejdede med. Generelt set, synes jeg, at dette projekt er fantastisk. Jeg kan bare bedre lide muligheden for at skabe forskellige netværk til forskellige opgaver. Det giver en bedre organisering af strukturen og reducerer belastningen på de enkelte noder og netværket som helhed. Selv inden for et bestemt projekt, kan man om nødvendigt opdele netværket i sektioner efter visse kriterier, hvilket reducerer den samlede belastning.

Så, storacle bruger mekanismen spreadable til at organisere netværket. Hovedtræk:

  • Filer kan tilføjes i opbevaringen via enhver node.
  • Filer gemmes i sin helhed, ikke i blokke.
  • Hver fil har sin egen unikke hash baseret på indholdet til videre behandling.
  • Filer kan duplikeres for øget pålidelighed.
  • Antallet af filer på en node er kun begrænset af filsystemet (der er en undtagelse, som jeg vil nævne nedennede).
  • Antallet af filer i netværket er begrænset af mulighederne i spreadable i forhold til antallet af tilladte noder i netværket, som i den anden version vil kunne tillade arbejde med et uendeligt antal noder (mere om dette i en anden artikel).

Et simpelt eksempel på, hvordan dette fungerer fra programmet:

Server:

const Node = require('storacle').Node;

(async () => {
  try {
    const node = new Node({
      port: 4000,
      hostname: 'localhost'
    });
    await node.init();
  }
  catch(err) {
    console.error(err.stack);
    process.exit(1);
  }
})();

Kunde:

const Client = require('storacle').Client;

(async () => {
  try {
    const client = new Client({
      address: 'localhost:4000'
    });
    await client.init();
    const hash = await client.storeFile('./my-file');
    const link = await client.getFileLink(hash);
    await client.removeFile(hash);
  }
  catch(err) {
    console.error(err.stack);
    process.exit(1);
  }
})();

Et indblik fra indersiden

Under the hood, there’s nothing supernatural. Information about the number of files, their total size, and other aspects is stored in an in-memory database and updated when files are added or removed, so there is no need to frequently access the file system. The exception is during garbage collection, which requires the circulation of files when certain storage sizes are reached, rather than blocking the addition of new ones. In this case, it is necessary to traverse the storage, and working with a large number of files (> a million, let's say) can lead to significant loads. It’s better to keep fewer files and run more nodes. If the "cleaner" is turned off, then there’s no such problem.

The file storage consists of 256 folders and 2 levels of nesting. Files are stored in the second-level folders. This means that with 1 million files, there will be about 62500 files in each such folder (1000000 / sqrt(256)).

The names of the folders are generated from the file hash to enable quick access, knowing the hash.

This structure was chosen based on a large number of different requirements for the storage: support for weak file systems, where it is undesirable to have too many files in one folder, quick traversal of all folders when necessary, etc. A kind of golden mean.

Caching

When files are added or retrieved, links to the files are written to the cache.
Thanks to this, it is often unnecessary to traverse the entire network in search of a file. This speeds up link retrieval and reduces network load. Caching also occurs through HTTP headers.

Isomorphism

The client is written in JavaScript and isomorphic; it can be used directly from the browser. 
You can upload a file https://github.com/ortexx/storacle/blob/master/dist/storacle.client.js as a script and access window.ClientStoracle or import it via the build system, etc.

Deferred links

An interesting feature is also the "deferred link." This is a link to a file that can be obtained synchronously, here and now, while the file will be pulled in once it is found in storage. This is very convenient when, for example, you need to display some images on a website. Simply set a deferred link in the src, and that's it. Many use cases can be imagined.

Client API

  • async Client.prototype.storeFile() — saving a file
  • async Client.prototype.getFileLink() — obtaining a direct link to the file
  • async Client.prototype.getFileLinks() — få listen over direkte links til filen fra alle noder, hvor den findes
  • async Client.prototype.getFileToBuffer() — få filen til bufferen
  • async Client.prototype.getFileToPath() — få filen til filsystemet
  • async Client.prototype.getFileToBlob() — få filen til blob (til browserversionen)
  • async Client.prototype.removeFile() — slette filen
  • Client.prototype.createRequestedFileLink() — oprette en forsinket link

Eksport af filer til en anden server

For at flytte filer til en anden node kan man:

  • Bare kopiere hele lagermappen sammen med indstillingerne. (i fremtiden kan dette muligvis ikke fungere)
  • Kun kopiere mappen med filer. Men i så fald skal man én gang køre funktionen node.normalizeFilesInfo(), for at genberegne alle data og indtaste dem i databasen.
  • Brug funktionen node.exportFiles(), som starter kopiering af filer.

Hovedindstillinger for noden
Når man starter lager noden, kan man angive alle nødvendige indstillinger.
Jeg vil beskrive de vigtigste, resten kan findes på GitHub.

  • storage.dataSize — størrelsen på mappen med filer
  • storage.tempSize — størrelsen på den midlertidige mappe
  • storage.autoCleanSize — minimumsstørrelsen på lageret, som skal opretholdes. Hvis man angiver denne parameter, vil de mindst brugte filer blive slettet, så snart pladsen begynder at mangle.
  • file.maxSize — maksimal filstørrelse
  • file.minSize — minimal filstørrelse
  • file.preferredDuplicates — foretrukket antal duplikater af filen i netværket
  • file.mimeWhitelist — tilladte filtyper
  • file.mimeBlacklist — ikke tilladte filtyper
  • file.extWhitelist — tilladte filudvidelser
  • file.extBlacklist — ikke tilladte filudvidelser
  • file.linkCache — forskellige indstillinger for caching af links

Næsten alle parametre relateret til størrelser kan angives både i absolutte og relative enheder.

Arbejder via kommandolinjen
Biblioteket kan bruges via kommandolinjen. For at gøre dette skal det installeres globalt: npm i -g storacle. Efter dette kan man køre de nødvendige handlinger fra kataloget med projektet, hvor noden er. For eksempel, storacle -a storeFile -f ./file.txt -c ./config.js, for at tilføje en fil. Alle handlinger kan findes i https://github.com/ortexx/storacle/blob/master/bin/actions.js

Hvorfor kan du have brug for dette

  • Hvis du ønsker at oprette et decentraliseret projekt, hvor det planlægges at gemme og arbejde med filer på bekvemme metoder. For eksempel, projektet med musik beskrevet i linket i starten af artiklen bruger storacle.
  • Hvis du arbejder med andre projekter, hvor filer skal opbevares decentralt, kan du nemt opbygge dit eget lukkede netværk, tilpasse noderne fleksibelt og tilføje nye, når det er nødvendigt.
  • Hvis du blot har brug for et sted at opbevare filer til dit website, og det føles besværligt at skrive alt selv, kan dette bibliotek være et bedre valg for dig.
  • Hvis du har et projekt, hvor du arbejder med filer, men ønsker at udføre alle handlinger fra browseren, kan du undgå at skrive serverkode.

Mine kontaktoplysninger:

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster