问题标签 [blob]

目前，我将图像（最大 6MB）作为 BLOB 存储在 InnoDB 表中。随着数据量的增长，每晚备份的速度越来越慢，阻碍了正常的性能。

因此，二进制数据需要进入文件系统。（指向文件的指针将保存在数据库中。）

数据具有树状关系：

现在我希望数据通过目录结构均匀分布。我应该如何做到这一点？

我想我可以尝试MD5('userId, albumId, imageId');对结果字符串进行切片以获取我的目录路径：

这将允许我将第一个字符映射到服务器并将目录结构均匀地分布在多个服务器上。

然而，这不会保持每个用户的图像组织，可能会将 1 个相册的图像分布在多个服务器上。

我的问题是：
将图像数据以平衡的方式存储在文件系统中，同时将用户/相册数据保存在一起的最佳方法是什么？

我在思考正确的方向吗？或者这完全是错误的做事方式？

更新：
我将md5(user_id)在最高级别进行字符串切片。然后将所有用户数据放在同一个桶中。这将确保数据的均匀分布，同时将用户数据存储在一起。

我想我会使用从后面拆分的 albumId（我喜欢这个主意！）以保持每个目录的专辑数量更小（尽管对于大多数用户来说这不是必需的）。

谢谢！

我正在尝试在 group_concat 命令中使用 concat_ws 。使用查询，简化如下：

我将附件列作为 Blob 类型。是否可以将其作为字符串而不是 Blob 获取？

我正在尝试通过 Kohana 的 ORM 库在 MySQL 表中创建和检索 BLOB。

代码看起来像：

我已经通过将数据输出到文件来验证此时数据是否正常。但是，当我检索数据时，它会损坏。我已经设法进一步缩小范围 - 我使用 MySQL 查询工具来提取数据库中保存的数据，并且我可以验证数据库中的数据是否已损坏，因此问题一定出在 INSERT .

此外，输入的文件并不总是损坏 - 较小的文件（例如图像）往往没问题。

有人有想法么？

我的文档管理系统的要求是：

1. 必须通过简单复制目录、文件等来防止被盗。
2. 必须防止传统病毒感染（物理文件感染）
3. 必须快速检索
4. 临时（目录）浏览用户等不能看到存储库。

我决定将所有文档（和扫描的图像）作为 blob 存储在数据库中，到目前为止，我的体验非常棒，文档检索也非常快 - 它符合上面的所有标准，甚至还有一些额外的优势，例如自动存储文档及其相关实体，轻松快速地搜索内容，删除围绕文档打开和命名等的各种用户活动等。

我的问题是 - 在这个设计和实现中是否有任何严重的风险或我忽略的事情？

编辑说明：DB 是 PostgreSQL，可以很好地处理 BLOBS 并且可以很好地扩展。环境是多用户的。

我有一个包含 BLOB 文件的 sqlite 表，但需要对 blob 进行大小/长度检查，我该怎么做？

根据我确实找到的一些文档，使用 length(blob) 不起作用，因为 length() 仅适用于文本，并且在第一个 NULL 之后将停止计数。我的经验测试表明这是真的。

我正在使用 SQLite 3.4.2

更新：

因此，从 SQLite 3.7.6 开始，似乎 length() 函数返回了正确的 blob 值——我检查了 sqlite 的各种更改日志，但没有看到在哪个版本中得到了更正。

从 Sqlite 3.7.6 开始：

文档已更改以反映这一点。

我需要从 SQL Server 2005 数据库中提取一些 BLOB 数据并生成一个 SQL 脚本以将相同的数据插入到另一个数据库中，另一个服务器中。

我只能使用 SQL 脚本来执行此操作，我不能使用任何其他实用程序或用 Java 或 .NET 编写程序来执行此操作。

我的另一个大限制是，当我运行脚本时，我无法访问原始数据库（原始 BLOB 数据所在的位置），将 BLOB 数据复制到目标数据库，因此数据应该已经在其中编码SQL 脚本文件。

总结：有没有办法将 BLOB 数据编码为文本，以便我可以将其转储到脚本文本文件中的 SQL INSERT 命令中并运行它？

如果需要，我可以运行特殊的 T-SQL 语句和存储过程。

我有一个用于将文档元数据存储到表中的对象。文档的正文可能非常大，有时 > 2GB，因此我会将其存储到 SQL 2008 中的 nvarchar(max) 字段中。稍后我将使用 SQL 2008 来索引该字段。我不会使用文件流，因为它们对数据库非常严格，并且会阻止某些类型的并发锁定方案。

该对象通过 LinqToSQL 公开给开发人员。我担心该字段会太大，如果文本> 1.5 GB，我已经看到.Net 爆炸并出现OutOfMemory 异常。

所以我想知道，我可以将这个 blob 视为带有 Linq 的流吗？或者如果我想使用 blob，我是否必须完全绕过 Linq？

我有一张表格

它在 blob 列中有大约 160,000 行和大约 2GB 的数据（平均每个 blob 14kb）。另一个表具有该表的外键。

大约有 3000 个斑点是相同的。所以我想要的是一个查询，它会给我一个重新映射表，允许我删除重复项。

天真的方法在 30-40k 行上花费了大约一个小时：

由于其他原因，我碰巧有一个具有 blob 大小的表：

通过为 fk 和另一个为 sz 建立索引，直接查询大约需要 24 秒，有 50k 行：

但是，这是对 da（数据表）进行全表扫描。鉴于命中率应该相当低，我认为索引扫描会更好。考虑到这一点，添加了第 3 个数据副本作为第 5 次连接以获得该数据，并丢失了大约 3 秒。

好的，问题是：我会比第二个选择好得多吗？如果是这样，怎么做？

一个推论是：如果我有一个表，其中键列的使用非常频繁，但其余的应该很少使用，那么我最好添加该表的另一个连接以鼓励索引扫描而不是完整的表扫描？

#mysql@irc.freenode.net 上的 Xgc 指出，添加一个实用程序表（如大小但具有唯一约束）fk可能会有很大帮助。触发器带来一些乐趣，而不会让它保持最新状态甚至还不错。

在编写实用程序脚本以将图像插入数据库时​​，我想知道是否有一种更规范的方法。最后解决了一些类似的问题：

必须有一种更时髦的方法，有人可以启发我吗？

我正在向我的网站添加一些功能，以便用户可以上传自己的个人资料图片，所以我想知道是将它们作为 BLOB 存储在数据库中，还是将它们放在文件系统中。

我在这里发现了一个与此类似的问题：Storing images in DB: Yea or Nay，但给出的答案更适合人们期待成千上万甚至数百万张图像，而我更关心小图像（JPEG 最高可能是 150x150 像素），并且数量很少：可能最多一两千。

对于这种情况，DB BLOB 与文件系统有何感受？客户端如何从数据库缓存图像与从文件系统缓存图像？

如果存储在数据库中的 BLOB 是要走的路 - 我应该知道在哪里存储它们吗？由于我认为我的大多数用户不会上传图片，我是否应该在需要时创建一个user_pics表以（外部）加入常规users表？

编辑：我重新打开这个问题，因为它不是你链接到的那两个的重复。这个问题专门针对少量图像使用 DB 或 FS 的优缺点。正如我上面所说，另一个问题是针对需要存储成千上万张大图像的人。