在我的系统中，用户可以上传非常大的文件，我需要将其存储在 Couchbase 中。我不需要如此大的对象来保留在内存中，但我希望它们始终从磁盘读取/写入。这些文件是只读的（从未修改过）。用户可以上传它们、删除它们、下载它们，但永远不能更新它们。由于某些技术限制，我的系统无法将这些文件存储在文件系统中，因此必须将它们存储到数据库中。
我做了一些研究，发现一篇文章说在数据库中存储大对象通常是一个坏主意，特别是对于 Couchbase，但同时提供了一些建议：创建一个具有低 RAM 配额的辅助存储桶，调整价值/全面驱逐政策。我关心的是作者提到的20Mb 的限制。我的文件会比那个大得多。
将大文件存储到 Couchbase 而不让它们保留在内存中的最佳方法是什么？万一可以提高20Mb的限制吗？我应该创建一个具有非常低的 RAM 配额和完整驱逐策略的辅助存储桶吗？
一般来说，Couchbase 工程师建议您不要在 Couchbase 中存储大文件。相反，您可以将文件存储在某些文件服务器上（例如 AWS 或 Azure Blob 等），并将有关文件的元数据存储在 Couchbase 中。
有一篇 couchbase 博客文章 非常详细地介绍了如何在 Couchbase 中完成您想做的事情。
这是特定于 Java API 的，但一般方法可以与任何 Couchbase SDK 一起使用，实际上我现在正在使用 Node SDK 做一些非常类似的事情。
我不能代表 couchbase 工程师的建议，但他们已经发布了这篇博客文章，详细说明了如何做到这一点。
对于大文件，您肯定会希望将其分成多个块。不要尝试将大文件全部存储在一个文档中。我正在研究的方法是将数据分块，并将其插入到文件 sha1 哈希值下。因此，文件“Foo.docx”将被分成 4 个块，即“sha1|0”、“sha1|1”等，其中 sha1 是文档的哈希值。这也将启用一个设置，您可以在其中以许多不同的名称存储相同的文件。
权衡 - 如果您可以选择与 Amazon S3 集成，那么这样做可能会更好。一般来说，像我所描述的那样，对数据库中的数据进行分块实施起来会比使用 Amazon S3 之类的东西更复杂，而且速度要慢得多。但这必须权衡其他要求，例如您是否可以在 S3 中保留敏感文件，或者您是否想要处理维护文件系统及其相关的扩展。
所以这取决于您的要求。如果您想要速度/性能，请不要将文件放在 Couchbase 中 - 但您能做到吗？当然。我自己已经完成了，上面的博客文章描述了一种单独的方法。
根据您的需要，您可能希望实现各种有趣的扩展。例如，如果您通常存储许多具有相似内容的不同文件，则可以实施阻止策略，允许单个存储许多常见段，以节省空间。其他解决方案（例如 S3）会很乐意存储副本的副本的副本的副本，并乐意为此向您收取大量费用。
编辑作为后续内容，还有另一篇 Couchbase 帖子讨论了为什么存储在数据库中可能不是一个好主意。需要考虑的合理事项 - 但这同样取决于您的应用程序特定要求。我认为“使用 S3”通常是个好建议，但并不适合所有人。
MongoDB 有一个选项可以执行此类操作，并且几乎所有驱动程序都支持它：GridFS。你可以在 Couchbase 中做类似 GridFS 的事情，即创建一个元数据集合（桶）和一个具有固定大小 blob 的块集合。 GridFS 允许您更改每个文件的 blob 大小，但所有 blob 的大小必须相同。文件大小存储在元数据中。典型的块大小为 2048，并且限制为 2 的幂。
您不需要文件的内存缓存，您可以在应用程序服务器中排队下载块。你可能想先在 Mongo 上尝试 GridFS，然后看看是否可以适应 Couchbase，但总是这样：https://github.com/couchbaselabs/cbfs
这是最佳实践：不要将 couchbase 数据库作为主数据库，将其视为同步数据库，因为无论您如何将数据分成小块，它都会超过 20MB 大小，从长远来看，这会对您造成影响，因此拥有一个强大的数据库像中间的 MySQL 将有助于保存这些大数据，然后仅使用 couchbase 进行实时和同步。