Frage Speichern und Sichern von 10 Millionen Dateien unter Linux


Ich betreibe eine Website, auf der ungefähr 10 Millionen Dateien (Buchumschläge) in 3 Ebenen von Unterverzeichnissen gespeichert sind, wobei [0-f]:

0/0/0/
0/0/1/
...
f/f/f/

Dies führt zu etwa 2400 Dateien pro Verzeichnis, was sehr schnell ist, wenn wir eine Datei abrufen müssen. Dies ist übrigens eine von viele Fragen.

Wenn ich diese Dateien jedoch sichern muss, dauert es viele Tage, um die 4k-Verzeichnisse zu durchsuchen, die 10m-Dateien enthalten.

Ich frage mich also, ob ich diese Dateien in einem Container (oder in 4k-Containern) speichern könnte, die jeweils genau wie ein Dateisystem (eine Art eingehängter ext3 / 4-Container?) Funktionieren würden. Ich denke, das wäre fast so effizient wie der direkte Zugriff auf eine Datei im Dateisystem, und dies hätte den großen Vorteil, dass sie sehr effizient auf einen anderen Server kopiert werden könnte.

Irgendwelche Vorschläge, wie man das am besten macht? Oder irgendeine brauchbare Alternative (noSQL, ...)?


25
2018-05-29 17:27


Ursprung


Welches Dateisystem verwendest du gerade? - cmcginty
NetApp ist eine gute Option, wenn Sie die Preise bezahlen können - Ian Ringrose
Ich benutze ext4 unter CentOS 5.6 - Benjamin
Neugierig, warum es "viele Tage dauern sollte, nur um die 4k-Verzeichnisse zu durchsuchen, die 10m Dateien enthalten", was viel zu langsam erscheint. Unter der Annahme von 150 Bytes pro Pfadname ergeben die 10-m-Dateinamen 1,5 GB Daten, also könnte es sich um den verfügbaren Speicher / die CPU handeln (einschließlich der Sortierung des Ergebnisses). Überprüfen Sie auch, ob das Aktivieren / Deaktivieren von dir_index hilft: lonesysadmin.net/2007/08/17/ ... plus verschiedene Tipps bei serverfault.com/questions/183821/... - RichVel
Hinweis 5 Jahre später: Ich habe alles auf Amazon S3 migriert, was perfekt geeignet ist, um so viele Dateien zu speichern. Außerdem muss ich Dateien nicht mehr in 3 Ebenen von Unterverzeichnissen aufteilen, da es für S3 keinen Unterschied macht (ein Pfad ist ein Pfad, ob er Schrägstriche enthält oder nicht, spielt keine Rolle). Und ich kann besser schlafen, da ich weiß, dass meine Daten sicher über mehrere Standorte hinweg repliziert werden. - Benjamin


Antworten:


Optionen für den schnellen Zugriff auf und Sicherung von Millionen von Dateien

Ausleihen von Menschen mit ähnlichen Problemen

Das klingt sehr nach einer einfacheren Art von Problem, mit dem USENET-Newsserver konfrontiert werden und Webproxys zwischengespeichert werden: Hunderte von Millionen kleiner Dateien, auf die nach dem Zufallsprinzip zugegriffen wird. Vielleicht möchten Sie einen Hinweis von ihnen nehmen (außer dass sie normalerweise keine Backups machen müssen).

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

Offensichtlich ist die zyklische Natur des zyklischen Nachrichten-Dateisystems für Sie irrelevant, aber das Konzept der unteren Ebene, mehrere Platten-Dateien / Geräte mit gepackten Bildern und einen schnellen Index von den Informationen, die der Benutzer zur Verfügung stellt, um die Standortinformationen zu finden, ist sehr geeignet.

Dedizierte Dateisysteme

Natürlich sind dies nur ähnliche Konzepte zu denen, über die Leute gesprochen haben, indem Sie ein Dateisystem in einer Datei erstellen und es über Loopback mounten, außer dass Sie Ihren eigenen Dateisystemcode schreiben müssen. Da Sie angegeben haben, dass Ihr System hauptsächlich gelesen wurde, können Sie natürlich eine Festplattenpartition (oder eine lvm-Partition für die Flexibilität bei der Größenbestimmung) diesem Zweck zuweisen. Wenn Sie eine Sicherungskopie erstellen möchten, mounten Sie das Dateisystem schreibgeschützt und erstellen Sie dann eine Kopie der Partitions-Bits.

LVM

Ich habe oben erwähnt, dass LVM nützlich ist, um eine dynamische Größenanpassung einer Partition zu ermöglichen, so dass Sie nicht viel leeren Speicherplatz sichern müssen. Aber natürlich hat LVM andere Funktionen, die sehr gut anwendbar sind. Insbesondere die "Schnappschuss" -Funktionalität, mit der Sie ein Dateisystem zu einem bestimmten Zeitpunkt einfrieren können. Irgendein Zufall rm -rf oder was auch immer den Schnappschuss nicht stören würde. Je nachdem, was genau Sie tun möchten, reicht das für Ihre Backup-Anforderungen aus.

RAID-1

Ich bin sicher, dass Sie bereits mit RAID vertraut sind und es wahrscheinlich bereits für Zuverlässigkeit verwenden, aber RAID-1 kann auch für Backups verwendet werden, zumindest wenn Sie Software-RAID verwenden (Sie können es mit Hardware-RAID verwenden, aber das tatsächlich gibt Ihnen eine geringere Zuverlässigkeit, da es möglicherweise erforderlich ist, dass derselbe Modell- / Revisionscontroller gelesen wird). Das Konzept besteht darin, dass Sie eine RAID-1-Gruppe mit einer weiteren Festplatte erstellen, als Sie tatsächlich für Ihre normalen Zuverlässigkeitsanforderungen benötigen (z. B. eine dritte Festplatte, wenn Sie Software-RAID-1 mit zwei Festplatten oder eine große Festplatte und eine Hardware verwenden). RAID5 mit kleineren Festplatten mit einem Software-RAID-1 auf der Hardware-RAID-5). Wenn es an der Zeit ist, eine Sicherungskopie zu erstellen, installieren Sie eine Diskette, bitten Sie mdadm, diese Diskette zur Raid-Gruppe hinzuzufügen, warten Sie, bis Vollständigkeit angezeigt wird, fragen Sie nach einer Überprüfung und entfernen Sie die Diskette. Abhängig von den Leistungsmerkmalen können Sie die Festplatte natürlich meistens installieren lassen und nur für den Austausch mit einer alternativen Festplatte entfernen, oder Sie können die Festplatte nur während der Sicherungen installieren.


11
2018-05-29 18:20



Sehr vollständige Antwort, die gute Lösungen zusammenfasst. Ich denke, ich werde meine bestehende Dateisystemstruktur beibehalten und LVM-Snapshots verwenden, die für meinen Anwendungsfall perfekt zu sein scheinen. - Benjamin


Sie könnten ein virtuelles Dateisystem mit dem Loopback-Manager mounten, aber dies würde Ihren Backup-Prozess zwar beschleunigen, aber den normalen Betrieb beeinträchtigen.

Eine weitere Alternative besteht darin, das gesamte Gerät mit dd zu sichern. Zum Beispiel, dd if=/dev/my_device of=/path/to/backup.dd.


9
2018-05-29 17:38



+1 Das Gerät selbst zu sichern ist eine gute Idee. - asm
Sie sollten, wenn Sie diesen Ansatz verwenden, die Wiederherstellung testen (das sollten Sie immer tun), denn wenn Ihre Eingabe eine Festplatte wie / dev / sdd ist, speichert dd die Partition sheme und die Größe. Wenn Sie es auf einer kleineren Festplatte wiederherstellen, erhalten Sie Fehler, und wenn Sie es auf einer größeren Festplatte wiederherstellen, wird es abgeschnitten angezeigt. Es funktioniert am besten, wenn Sie die Daten in einem anderen Exemplar des gleichen Plattentyps wiederherstellen. Nur das Wiederherstellen von Partitionen (/ dev / sdd1) wird weniger mühsam sein. - user unknown
Beachten Sie, dass, wenn sich das Gerät in LVM befindet, auch eine Sicherung durchgeführt werden kann, ohne den Datenträger mithilfe von LVM-Snapshots zu demontieren. - bdonlan
Ich unterstütze den LVM-Schnappschuss-Backup-Ansatz. Ich habe lvm in der Vergangenheit für die Live-DR-Replikation genutzt. Die Verwendung von dd in Kombination mit Snapshots erleichtert die Durchführung von Backups auf Blockebene. - slashdot
Ich habe es versucht dd Über nc und das macht einen guten Job! Ich habe jedoch möglicherweise inkonsistente / beschädigte Daten, anstatt LVM-Snapshots anstelle der Live-Partition zu verwenden. - Benjamin


Wie Sie wahrscheinlich wissen, ist Ihr Problem Lokalität. Ein typischer Disk-Suchlauf dauert etwa 10 ms. Wenn Sie einfach "stat" (oder open ()) für 10 Millionen zufällig platzierte Dateien aufrufen, sind 10 Millionen Suchvorgänge erforderlich, also ungefähr 100000 Sekunden oder 30 Stunden.

Sie müssen also Ihre Dateien in größere Container legen, sodass die relevante Nummer die Laufwerksbreite (normalerweise 50-100 MB / s für eine einzelne Festplatte) und nicht die Suchzeit ist. Außerdem können Sie damit ein RAID werfen, mit dem Sie die Bandbreite erhöhen (aber die Suchzeit nicht verringern).

Ich erzähle dir wahrscheinlich nichts, was du noch nicht weißt, aber mein Punkt ist, dass deine "Container" -Idee das Problem definitiv lösen wird, und fast jeder Container wird es tun. Loopback-Mounts funktionieren wahrscheinlich genauso gut wie alles andere.


8
2018-05-29 17:46



Gute Analyse, danke. - Benjamin
Yup, Ort ist entscheidend. Schau dir deine Nutzungsmuster an. Die meisten Probleme neigen dazu, dem Pareto-Prinzip zu folgen (80% der Prozesse erreichen 20% der Daten). Wenn Sie also herausfinden könnten, welche Dateien im RAM zwischengespeichert werden müssen, oder einfach eine separate Partition mit einem anderen Verzeichnis anlegen Es braucht weniger Verzeichnissuchen oder -suchen, es würde wahrscheinlich viel helfen. Das Verbreiten der häufig zugegriffenen Dateien auf verschiedenen Spindeln von Festplatten, so dass Suchvorgänge parallel ausgeführt werden könnten, könnte ebenfalls helfen. +1 für @Nemo, um die Fundstelle zu ermitteln. - Marcin


Es gibt ein paar Möglichkeiten. Das einfachste und sollte mit allen Linux-Dateisystemen funktionieren, ist dd Kopiere die gesamte Partition (/dev/sdb3 oder /dev/mapper/Data-ImageVol) zu einem einzelnen Bild und archiviere dieses Bild. Im Falle der Wiederherstellung einzelner Dateien, Loopback mounten Sie das Bild (mount -o loop /usr/path/to/file /mountpoint) und kopieren Sie die benötigten Dateien. Bei einer vollständigen Partitionswiederherstellung können Sie die Richtung der Initiale umkehren dd Befehl, aber Sie brauchen wirklich eine Partition von identischer Größe.

Nach Ihrem Anwendungsfall zu urteilen, sind einzelne Dateiwiederherstellungen ein sehr seltenes Ereignis, wenn sie überhaupt auftreten. Deshalb macht ein bildbasiertes Backup hier durchaus Sinn. Wenn Sie häufiger einzelne Wiederherstellungen durchführen müssen, ist die Verwendung von gestaffelten LVM-Snapshots viel praktischer. aber Sie müssen immer noch das Image-basierte Backup für diese kritischen "wir haben alles verloren" -Katastrophen. Bildbasierte Wiederherstellungen neigen dazu, zu gehen viel schneller als tar-basierte Wiederherstellungen, einfach weil es nur Blöcke wiederherstellt, es nicht eine ganze Menge von Metadaten Operationen mit jedem fopen / fclose, und kann auch eine sehr sequentielle Disk-Operation für weitere Geschwindigkeitserhöhungen sein.

Alternativ, wie das Google Video @casey auf halbem Weg erwähnt, ist XFS ein großartiges Dateisystem (wenn es komplex ist). Einer der besseren Dienstprogramme mit XFS ist der xfsdump Dienstprogramm, das ein gesamtes Dateisystem in eine einzige Datei ablegt und dies in der Regel schneller macht tar können. Es ist ein Dateisystem-spezifisches Dienstprogramm, also kann fs internals auf Weisen benutzen, die tar nicht können.


5
2018-05-29 23:27



Viele gute Antworten dort! XFS scheint interessant zu sein, aber ich fürchte, es ist etwas außerhalb meiner Reichweite. - Benjamin


Ich würde vorschlagen, dass Sie zuerst versuchen, auf EXT4 zu aktualisieren, wenn Sie es nicht bereits ausführen.

Google hat viel geforscht warum EXT4 ist eine gute Idee.

Danach sollten Sie die Bereitstellung einer verteilten Dateisystemarchitektur untersuchen. Zum Beispiel:


3
2018-05-29 19:56



Ich laufe ja schon EXT4, was super aussieht! - Benjamin


Wenn Sie mit einem Appliance-Modell für Ihren Datenspeicher zufrieden wären, könnten Sie vielleicht darüber nachdenken NexentaStor. Es läuft ZFS auf OpenSolaris unter der Haube, aber die gesamte Verwaltung erfolgt über eine Web-GUI.

Es gibt ein paar Funktionen, die bei Ihrem Problem helfen könnten.

  • Die Enterprise-Version unterstützt eine Art von Remote-Replikation basierend auf Snapshots, die nicht durch das gesamte Dateisystem gescannt werden muss.

  • Wenn es Ihnen nichts ausmacht, sich die Hände schmutzig zu machen, ist ZFS sehr praktisch ZFS diff Befehl, der Ihnen effizient sagt, welche Dateien seit dem letzten Snapshot hinzugefügt, geändert oder gelöscht wurden, ohne dass Sie das gesamte Dateisystem durchsuchen müssen. Sie könnten dies in Ihr Backup-System integrieren, um den Zeitaufwand für inkrementelle Backups erheblich zu reduzieren.


1
2018-05-30 02:39



Danke, wir werden es uns ansehen. Vielleicht würde es meinem Projekt jedoch ein wenig Komplexität hinzufügen! - Benjamin


Vielleicht eine simple Antwort, aber mein erster Gedanke war, etwas wie GridFS welches auf gebaut ist MongoDB. Viele der primären Sprachtreiber unterstützen es standardmäßig, daher sollten Sie es einfach mit den Dateileseabschnitten Ihres Codes austauschen können. Sie könnten auch Ihre vorhandenen Verzeichnispfade zu den Schlüsseln für diese Dateien machen.

Ein Problem, das Sie vielleicht haben, ist, dass Mongo dazu tendiert, ziemlich schnell zu verlangsamen, wenn es die ganze Zeit von der Festplatte sucht. Bei 10 Millionen Dateien erwarte ich, dass die meisten Daten auf der Festplatte gespeichert werden. Die Teile der Dateien in GridFS sind, wie ich mich erinnere, 4MB. Wenn Ihre Dateien also größer sind, machen Sie mehrere kostspielige Operationen, um eine Datei zu erhalten. Der Schlüssel, denke ich, wäre, Ihre Dateien basierend auf Ihrer bereits aufgeräumten Verzeichnisstruktur zu sharden, so dass Sie mehrere Mongo-Instanzen auf mehreren Boxen ausführen können, um die Last zu verringern. Ich weiß jedoch nicht, was Ihre Leistungsanforderungen sind, also könnte ich es überdenken.

Was bringt das alles? Leistung, die ziemlich genau mit den Lesevorgängen auf der Festplatte übereinstimmt wenn richtig gemacht. Ebenfalls, Mongo bietet mehrere großartige integrierte Backup-Möglichkeiten die gesamte Datenmenge in einer DB-Instanz schnell und sogar mit laufender Datenbank.


1
2018-05-30 03:55



Ich werde definitiv GridFS sehen, was ich nicht wusste, aber ich denke, dass ich am Ende alles auf Dateisystembasis halten werde, um den Arbeitsaufwand zu reduzieren, da alles bereits funktioniert! - Benjamin


Sie können einen Standard verwenden dump Dienstprogramm Zum Sichern des EXT4-Dateisystems mit vielen Dateien. Dieses Dienstprogramm prüft zunächst, welche Blöcke in einem Dateisystem verwendet werden, und sichert sie dann in der Festplattenreihenfolge, wodurch die meisten Suchvorgänge entfallen.

Es gibt ein entsprechendes restore Dienstprogramm zum Wiederherstellen von Backups erstellt von dump.

Es unterstützt inkrementelle Backups mit Level - Level 1 Backups Dateien vom letzten Level 0 (voll) Backup, Level 2 - modifiziert von Level 1 Backup und so weiter.


1
2017-10-07 22:38





Für inkrementelle Sicherungen wäre eine Option, eine zweite Schattenstruktur für neue Abdeckungen zu haben. Das heißt, Sie haben Ihren Hauptbaum, der für alle Leseoperationen verwendet wird. Du hättest auch eine newfiles/012345.....jpg Verzeichnis; Neu hinzugefügte Cover erstellen hier sowohl einen Hardlink als auch im Hauptbaum. Bei der Durchführung von Backups können Sie gelegentlich den Hauptbaum sichern, aber das Backup (viel kleiner) newfiles Baum viel regelmäßiger.

Beachten Sie, dass um das zu behalten newfiles Baum klein, bevor Sie eine neue Sicherung des Hauptbaums durchführen, können Sie den Baum newfiles leeren:

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

Sobald Sie dies tun, sind Sie natürlich verpflichtet, eine neue Sicherung des Hauptbaums zu erstellen.


0
2018-05-29 21:18



Interessanter Ansatz, vielen Dank für das Teilen. Aber ich fürchte, es würde viele Änderungen in der Anwendung erfordern, und es wäre schwierig, die Anwendung und den Speicherbedarf in zwei separaten Schichten zu halten. - Benjamin