用于用户提交的可扩展目录结构
我们的团队正在将媒体库存储引擎从数据库 BLOB 存储切换到文件系统（我们正在使用 LAMP 堆栈，PHP 版本为 5.3）。实际上，存储的所有内容都是将被拉入应用程序的图像数据，对其进行的大部分处理是使用 GD 进行一些调整大小/重新采样。数据库存储是以前构建遗留下来的工件，我们试图放弃它，以减少数据库服务器的压力。
我之前已经构建了一些像这样的基于文件系统的图像库，但我想巩固一些最佳实践，因为它会变得很大，并且一旦充满用户数据，将很难修改。
在我之前的构建中，我创建了一个具有读/写权限的“资源”文件夹。在该目录中，还有一个额外的目录层，这些目录根据内容与站点的“部分”相关而命名，通常按实现其中内容的模型或控制器的名称进行组织。在该层下是用户/配置文件 ID 或以数字命名的文件夹，它们共享数据库中决定主要所有权的任何主键的数量（在这种部署中，这些通常是图像来自的编译的画廊 ID，因为所有权特定用户对图库的访问可以通过数据库/对象模型进行处理。）
社区在这种情况下使用了哪些方法，哪些方法最具可扩展性？ Apache 是否有任何软件可以比简单地将其手动编码到模型中更有效地处理这种组织？我在 SO 和 Google 上尝试了一些有关文件系统媒体存储的类似线程的搜索，但除了我们已经或多或少建立的“不要使用 BLOB”效果之外，没有找到太多其他内容。有什么严格禁止的事项吗？
感谢您的指导！
Our team is in the process of switching over our media library storage engine from database BLOB storage over to file system (We are using the LAMP stack, PHP is ver 5.3). Virtually all the content being stored is image data that will be pulled into the application and the most processing that will be done on it is some resizing/resampling with GD. The database storage is an artifact left over from a previous build that we are trying to abandon in order to reduce the strain on the database server.
I have built a few filesystem-based image libraries like this before, but I'd like to solidify some best practices, since this is going to get large and once it is filled with user data it will be very difficult to modify.
In my previous builds, I had created a 'resources' folder that had read/write privileges. Within that directory, there was an additional layer of directories that were named for what "section" of the site the content was pertinent to, usually organized by the name of the model or controller that implemented the stuff in there. Under that layer were user/profile ids or numerically-named folders that shared the number of whatever primary key in the database determined primary ownership (these were typically, in this kind of deployment, gallery ids of the complilation the images came from, since ownership of the gallery by a specific user could be handled through the database/object models.)
What kind of approaches has the community used in this situation, and which were most scalable? Is there any software for Apache that could handle this kind of organization more effectively than simply manually coding it into the models? I tried a few searches on SO and Google for similar threads on filesystem media storage, but didn't find much other than things to the effect of "don't use BLOBs" which we've already more or less established. Is there any hard and fast do-nots?
Thanks for your guidance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
查看 MogileFS，它是一个分布式并行容错文件系统。
它提供自动复制、命名空间，并且可以与 nginx 集成（即不需要中间脚本来提供内容）。事实证明，它比文件系统更可靠、更可扩展，可以为我们的项目存储数百万张照片。
Check out MogileFS, it's a distributed parallel fault-tolerant file system.
It provides automatic replication, namespaces, and can be integrated with nginx (i.e. no intermediate script required to serve the content). It proved to be more reliable and scalable than filesystem for storing millions of photos for our project.