Große Objekte in Couchbase speichern - Best Practice?

Question

In meinem System kann ein Benutzer sehr große Dateien hochladen, die ich in Couchbase speichern muss. Ich brauche solche sehr großen Objekte nicht, um im Speicher zu bleiben, aber ich will, dass sie immer von/auf Platte gelesen/geschrieben werden. Diese Dateien sind schreibgeschützt (nie geändert). Der Benutzer kann sie hochladen, löschen, herunterladen, aber niemals aktualisieren. Bei einigen technischen Einschränkungen kann mein System diese Dateien nicht im Dateisystem speichern, sodass sie in der Datenbank gespeichert werden müssen.

Ich habe etwas recherchiert und einen Artikel [1] gefunden, der besagt, dass das Speichern großer Objekte in einer Datenbank generell eine schlechte Idee ist, vor allem bei Couchbase, aber gleichzeitig gibt es einen Ratschlag: Erstelle einen sekundären Bucket mit niedriges RAM-Kontingent, Abstimmung der Richtlinie für Wert/vollständige Räumung. Meine Sorge ist die vom Autor erwähnte Grenze von 20Mb. Meine Dateien wären viel größer als das.

Was ist der beste Ansatz, um große Dateien in Couchbase zu speichern, ohne sie im Speicher zu behalten? Ist es möglich, das Limit von 20 MB zu erhöhen, falls? Soll ich einen sekundären Bucket mit einem sehr niedrigen RAM-Kontingent und einer vollständigen Räumungsrichtlinie erstellen?

[1] http://blog.couchbase.com/2016/january/large-objects-in-a-database

Answer 1

Generell empfehlen Couchbase Ingenieure, dass Sie große Dateien in Couchbase nicht speichern. Stattdessen können Sie die Dateien auf einem Dateiserver (wie AWS oder Azure Blob oder etwas) speichern und stattdessen die Metadaten über die Dateien in Couchbase speichern.

Answer 2

Es gibt eine couchbase blog posting, die eine ziemlich detaillierte Aufschlüsselung gibt, wie Sie tun, was Sie in Couchbase tun möchten.

Dies ist Java API-spezifisch, aber der allgemeine Ansatz kann mit jedem der Couchbase SDKs arbeiten, ich bin gerade dabei, etwas ziemlich ähnliches jetzt mit dem Node SDK zu tun.

Ich kann nicht für das sprechen, was couchbase-Ingenieure empfehlen, aber sie haben diesen Blogeintrag veröffentlicht, der beschreibt, wie man es macht.

Für große Dateien möchten Sie sicherlich in Stücke aufgeteilt werden. Versuchen Sie nicht, eine große Datei in einem Dokument zu speichern. Der Ansatz, den ich sehe, besteht darin, die Daten zu zerhacken und sie unter der Datei sha1-Hash einzufügen. Also würde die Datei "Foo.docx" in etwa 4 Teile aufgeteilt werden, was "sha1 | 0", "sha1 | 1" usw. wäre, wobei sha1 der Hash des Dokuments ist. Dies würde auch ein Setup ermöglichen, bei dem Sie die gleiche Datei unter vielen verschiedenen Namen speichern können.

Kompromisse - wenn die Integration mit Amazon S3 eine Option für Sie ist, könnten Sie damit besser dran sein. Im Allgemeinen werden Chunking-Daten in einer DB, wie ich es beschreibe, komplizierter zu implementieren und viel langsamer, als etwas wie Amazon S3 zu verwenden. Aber das muss man mit anderen Anforderungen umgehen, etwa ob man sensible Dateien in S3 behalten kann oder nicht, oder ob man sich mit der Pflege eines Dateisystems und der damit verbundenen Skalierung beschäftigen will.

Es hängt also davon ab, was Ihre Anforderungen sind. Wenn Sie Geschwindigkeit/Leistung wünschen, legen Sie Ihre Dateien nicht in Couchbase ab - aber können Sie das tun? Sicher. Ich habe es selbst gemacht, und der Blog-Post oben beschreibt einen separaten Weg, um es zu tun.

Es gibt alle möglichen interessanten Erweiterungen, die Sie je nach Ihren Anforderungen implementieren möchten. Wenn Sie beispielsweise häufig viele verschiedene Dateien mit ähnlichem Inhalt speichern, können Sie eine Blockierungsstrategie implementieren, die das Speichern einzelner Segmente aus vielen gemeinsamen Segmenten ermöglicht, um Speicherplatz zu sparen. Andere Lösungen wie S3 werden gerne Kopien von Kopien von Kopien von Kopien speichern und Ihnen dafür riesige Mengen an Geld zur Verfügung stellen.

EDIT als Follow-up, gibt es this other Couchbase post darüber reden, warum das Speichern in der DB möglicherweise keine gute Idee ist. Angemessene Dinge zu beachten - aber auch hier kommt es auf Ihre anwendungsspezifischen Anforderungen an. "Benutze S3" Ich denke, das wäre im Allgemeinen ein guter Rat, wird aber nicht für alle funktionieren.