在Web应用中图片和长文本的处理策略总结
类别: JAVA教程 
不难认识到，在web应用中图片/多媒体和长文体的处理策略，很大程度上决定中一个系统的性能和负载能力。
这几天在处理图片上载的同时，也在考虑着最合理的对图片和长文本的存储。多年前，我喜欢把图片和长文本都存进oracle中，目的是备份方便，只需要 exp就可以连图片一起备分起来，不用一个个地照顾目录。但是缺点也随着访问量上升而一点点显示出来：一来是大大加重了数据库服务器的负担；二来使用 BLOG/CLOG并不是SQL92支持的标准SQL，令开发持久性的对象变得复杂;其三，oracle并不是一个适合存储文件的数据库，象他的 varchar2只能支持四千个字符，而使用CLob就不能直接使用sql显示；显然，mysql是更合适的文件数据库；它的text好象到现在还没有发现存储极限，而且完全可以使用标准的SQL读取和搜索。对于图文资料来说，事务并不重要，方便的查询和速度（意味着低负载）更为重要，反而是把它升级使用 BerklneyDB，添加事务回滚等，变得画虎不成反类犬。而oracle,应该让它专著于商务型的事务可靠性要求高的场合。 有朋友认为，长文本和图片都应该放在数据库以外，通过连接引用，我觉得对于mysql来说，它本身基本上就是一个图文文件系统，带有一个sql接口，所以文本没有必要存到外边，放在mysql中最合适。而图片，需要特别的BLOG处理，不能使用标准SQL，就应该放在数据库外面，减少系统的负担。 今天的数据库使用和开发模式实际上是一步步走向面向对象的存储和处理，这点特别是在JAVA（是中间件的主要工作语言）上表现得非常突出，无论是J2ee 还是Hibernate，还是我自已搞的dao/Processor，都是把java对象池看作是数据库对象向语言平台的延伸，直接面向对象的存储代替了通过SQL访问具体数据。尽管数据对象本身还是以关系结构的形式存在数据库中的，但它的细节被java对象的自动初始化隐藏起来。因此，尽可能令存储方式标准化（不要采用独特的存储方式）可以大幅度提高性能，简化数据对象化的程序，实际上提高了它的可靠性。正因如此，图片存储在文件系统而不是以二进制存在数据库中，是更合理的选择。 现在我的web平台主要是采用apache_catalina，这个平台在几年前使用后，很长一段时间没有使用了，实际上，它不但多变，而且文档极其缺乏 ——甚至于我现在还找不到server.xml中的Context对象属性的定义说明。当初把apache通过ajp13连系在一起，据说是因为 apache处理静态文件的能力远强于tomcat，但我一直不明白，它如何识别什么文件该阿帕奇，什么文件该tomcat?事实上我想最关键的文件是 worker.properties
info=Ajp13 forwarding over sockettomcatId=localhost:8009[uri:/jsp-examples/*][shm:]disabled=1
如果象上面那样uri:/jsp-examples/*的话，相信，apache屁用没有，根本上就是tomcat承受了一切的负担。 显然，如果是这样配置，系统承受的负担,我指的是java 服务器，将是大大超出应有的负荷的。应该修改上面的配置，让apache承但，主要是html和图片以及多媒体的下载任务，而不是tomcat,估计可以大大提供这个搭配系统的负载能力。
......前天写到这里，忽然觉得这个配置颇为眼熟，赶快去查一下，果然现在的项目中的设置就是这个样子的，但是进一步的测试就让我有点入歧途，一会儿证明是那样，一会儿就表明是那样。软件这东西如果缺乏逻辑必然的联系，人是没有什么好干的。无论如何，继续上面的思路，象上面的配置，表明所有/jsp- examples/*次级目录下的东东都是交由tomcat处理；Apache并没有相应的工作。正确的配置应该是：[uri:/jsp-examples/*.jsp][uri:/jsp-examples/servlet/*]
如果使用了如struts，大概还需要增加*.action这样的后缀。这样，非此类型的文件将会交给apache。而这样的设置：[uri:/*] 有极大的危险，将意味着所有的请求全部由tomcat响应；不过，看来ajp13作了预防性措施，事实上，这时侯ajp13把所有请求扔进了下水道，什么也不干。负作用就是虚拟主机的根目录我无论如何设不出它能够直接识别index.jsp引导。只能使用html代替，不过，这也没有什么大不了的，如果是小型的首页，可以就地转向，而假如是大型的首页，本身就会定时转换输出为html页面。
显然，在这种结构中使用通配符是最容易配出运行框架的，却也是错误的。
这几天在处理图片上载的同时，也在考虑着最合理的对图片和长文本的存储。多年前，我喜欢把图片和长文本都存进oracle中，目的是备份方便，只需要 exp就可以连图片一起备分起来，不用一个个地照顾目录。但是缺点也随着访问量上升而一点点显示出来：一来是大大加重了数据库服务器的负担；二来使用 BLOG/CLOG并不是SQL92支持的标准SQL，令开发持久性的对象变得复杂;其三，oracle并不是一个适合存储文件的数据库，象他的 varchar2只能支持四千个字符，而使用CLob就不能直接使用sql显示；显然，mysql是更合适的文件数据库；它的text好象到现在还没有发现存储极限，而且完全可以使用标准的SQL读取和搜索。对于图文资料来说，事务并不重要，方便的查询和速度（意味着低负载）更为重要，反而是把它升级使用 BerklneyDB，添加事务回滚等，变得画虎不成反类犬。而oracle,应该让它专著于商务型的事务可靠性要求高的场合。 有朋友认为，长文本和图片都应该放在数据库以外，通过连接引用，我觉得对于mysql来说，它本身基本上就是一个图文文件系统，带有一个sql接口，所以文本没有必要存到外边，放在mysql中最合适。而图片，需要特别的BLOG处理，不能使用标准SQL，就应该放在数据库外面，减少系统的负担。 今天的数据库使用和开发模式实际上是一步步走向面向对象的存储和处理，这点特别是在JAVA（是中间件的主要工作语言）上表现得非常突出，无论是J2ee 还是Hibernate，还是我自已搞的dao/Processor，都是把java对象池看作是数据库对象向语言平台的延伸，直接面向对象的存储代替了通过SQL访问具体数据。尽管数据对象本身还是以关系结构的形式存在数据库中的，但它的细节被java对象的自动初始化隐藏起来。因此，尽可能令存储方式标准化（不要采用独特的存储方式）可以大幅度提高性能，简化数据对象化的程序，实际上提高了它的可靠性。正因如此，图片存储在文件系统而不是以二进制存在数据库中，是更合理的选择。 现在我的web平台主要是采用apache_catalina，这个平台在几年前使用后，很长一段时间没有使用了，实际上，它不但多变，而且文档极其缺乏 ——甚至于我现在还找不到server.xml中的Context对象属性的定义说明。当初把apache通过ajp13连系在一起，据说是因为 apache处理静态文件的能力远强于tomcat，但我一直不明白，它如何识别什么文件该阿帕奇，什么文件该tomcat?事实上我想最关键的文件是 worker.properties
info=Ajp13 forwarding over sockettomcatId=localhost:8009[uri:/jsp-examples/*][shm:]disabled=1
如果象上面那样uri:/jsp-examples/*的话，相信，apache屁用没有，根本上就是tomcat承受了一切的负担。 显然，如果是这样配置，系统承受的负担,我指的是java 服务器，将是大大超出应有的负荷的。应该修改上面的配置，让apache承但，主要是html和图片以及多媒体的下载任务，而不是tomcat,估计可以大大提供这个搭配系统的负载能力。
......前天写到这里，忽然觉得这个配置颇为眼熟，赶快去查一下，果然现在的项目中的设置就是这个样子的，但是进一步的测试就让我有点入歧途，一会儿证明是那样，一会儿就表明是那样。软件这东西如果缺乏逻辑必然的联系，人是没有什么好干的。无论如何，继续上面的思路，象上面的配置，表明所有/jsp- examples/*次级目录下的东东都是交由tomcat处理；Apache并没有相应的工作。正确的配置应该是：[uri:/jsp-examples/*.jsp][uri:/jsp-examples/servlet/*]
如果使用了如struts，大概还需要增加*.action这样的后缀。这样，非此类型的文件将会交给apache。而这样的设置：[uri:/*] 有极大的危险，将意味着所有的请求全部由tomcat响应；不过，看来ajp13作了预防性措施，事实上，这时侯ajp13把所有请求扔进了下水道，什么也不干。负作用就是虚拟主机的根目录我无论如何设不出它能够直接识别index.jsp引导。只能使用html代替，不过，这也没有什么大不了的，如果是小型的首页，可以就地转向，而假如是大型的首页，本身就会定时转换输出为html页面。
显然，在这种结构中使用通配符是最容易配出运行框架的，却也是错误的。
