最近在工作中，需要从公共DataWarehouse（数据仓库）中导出数据，放到属于我们团队自己账号的云存储资源中，然后在我们的应用中进行查询中的此类资源。需要导出数据是因为直接从DataWarehouse查询数据是一个缓慢的异步过程，而我们的应用程序数据查询需要实时性。现在要解决这个问题，有一些AWS服务我们可以选择，基本上分为两类：第一类是存储和内容交付（Storage&ContentDelivery）：CloudFront：CloudFront是用来将内容分发到不同的regions对用户来说，它在世界范围内有几个“边”，作为从相邻网络访问数据的入口。就像大型网站建立的CDN设备一样。这显然不是我需要的。Glacier：Glacier非常适合存储不常用的、压缩备份的海量文件数据。它是集中式文件存储服务中最便宜的。比如存储日志，归档数据等。当然，它牺牲了数据传输的性能和一致性。显然它也不适用于我的场景。S3：S3（SimpleStorageService）适合存储原始数据和大对象（单个上限5Tb），成本低于数据库服务。如果我最终决定使用文件系统来存储数据，它是一个不错的选择。另外，不管是Glacier还是S3，层次结构的概念最大，都是区域级别（在Glacier中叫做vault，在S3中叫做bucket，每一个这样的单元都位于一定的region中，比如AsinPacific），所以如果全球多个节点需要访问相同的数据，需要将额外的数据分布到各个区域。StorageGateway：StorageGateway用于整合内部部署的IT环境。支持基于网关缓存的优化或网关存储的优化，方便本地及相邻网络快速获取数据。可以用于公司内部不同地理位置的文件共享、镜像或者备份，不适合我这里的场景。选择文件存储不能提供数据库的条件查询等功能。目前，在我的场景中不需要它。我只需要根据不同地区和数据唯一键获取数据集即可。否则，我需要考虑数据库服务：DynamoDB：DynamoDB是一个挂在云端的NoSQL数据库服务。每张表都需要指定一个哈希主键或者一个哈希和范围的二级主键。同时它的数据读取和存储的最小单位是4KB，也就是说访问0.5KB和4KB的数据，性能几乎是一样的。从数据量来看，如果选择数据库服务，最适合解决我的问题。SimpleDB：类似于DynamoDB，是一种非关系型数据库。结构可以随意改变，数据自动建立索引，查询速度非常快。它的数据容量要小得多，一个典型的用法是用SimpleDB来存储S3文件地址，就像“指针”一样。但是，需要考虑其容量限制。每个域只有10G的上限，可以建立多个域，但那样的话，需要应用自行路由选择域。关于一致性，像DynamoDB，可以选择最终一致性和强一致性。当然，强一致性要花更多的钱，降低吞吐量。ElastiCache：将Memcached或Redis迁移到云端显然不是我所需要的。RDS：RDS（RelationalDatabaseService）相当于把关系数据库搬到了云端。它和DynamoDB或者SimpleDB的区别主要是RDB和NoSQLDB的区别。RedShift：RedShift是一种数据仓库服务，利用列式存储技术和节点间的并行分布式查询来优化P上的数据访问。在这里还可以找到这几个AWS数据库服务的不同之处，用一个表以此类推：如果您需要考虑使用管理最少的关系数据库服务AmazonRDS，一种完全托管的服务，提供MySQL、Oracle或SQLServer数据库引擎、扩展计算和存储、多可用区可用性等。一种快速、高度可扩展的NoSQL数据库服务AmazonDynamoDB，这是一种完全托管的服务，可提供极快的性能、无缝的可扩展性和可靠性、低成本等。适用于较小数据集的NoSQL数据库服务AmazonSimpleDB，一种提供无模式数据库、可靠性等的完全托管服务。您可以自行管理的关系数据库您选择的关系型AMIsonAmazonEC2和EBS提供规模计算和存储、对实例的完全控制等。技术选择的另一个例子是在web容器中选择Tomcat或Jetty。Jetty结构简单，易于定制其组件，即小而简单（这也是谷歌一开始选择它作为应用引擎的最重要原因）是它最大的优势。当Jetty同时处理大量连接，需要长时间维护这些连接时，在性能上更有优势，因为它是基于NIO而不是Tomcat的BIO来处理请求；但是我们也可以找到很多性能测试数据，在非常短暂和非常频繁的请求方面，Tomcat优于Jetty。以下是摘自《Jetty VS Tomcat Performance Comparison》的两者对比：JettyFeaturesandPowered：Full-featuredandstandards-based。可嵌入和异步。开源且可商业使用。在Apache和Eclipse下获得双重许可。灵活可扩展，企业可扩展。支持强大的工具、应用程序、设备和云计算。维护成本低。小而高效。TomcatFeaturesandPowered：Apache下的著名开源软件。更容易将Tomcat嵌入到您的应用程序中，例如-EL2.2支持。坚固且具有广泛的商业用途和用途。易于与其他应用程序（如Spring）集成。灵活可扩展，企业可扩展。更快的JSP解析。稳定。#p#我经常遇到这样或这样的选择题，以上两个例子是比较理性分析比较的例子。我们考虑的事项通常包括功能、性能、社区支持、可扩展性和定制化、已知问题和限制等等。然而讽刺的是，仔细想想，我们选择一种技术最重要的原因远不是那些“理智的分析”，而是以下：“因为大家都在用”比如项目是用Java实现的或者C++为主要语言。我想很多人和我一样，往往不会想太多。这似乎是一种思维惯性。“因为我没用过这个技术，所以有兴趣，也想学。”其实，这是可以理解的。我之前也经历过一个项目组。大多数人（包括主管）都反对使用新技术。原因是害怕风险。原则上我同意风险，但是给程序员在适度范围内自由选择技术从长远来看是有利的，尤其是技术有待提高。把所有问题都留给“工程商人”，只会让眼光太浅。“因为我只知道”更是如此。为什么选择C3P0连接池？因为那时候不知道还有什么其他的数据库连接池……工程师在选择技术的时候总是在寻找一定的平衡点。他们可能不会把这三个理由写在纸上，但在心里，自觉不自觉地，一定会向这三个理由倾斜。现在让我们退后一步。如果我们都理性的去评价同类技术的优缺点，但是当我们真正用技术去实现的时候，发现其实这些同类技术都是可以实现的，选择哪一个都无所谓。因为数据的规模和问题的大小，不足以区分同类技术的优劣。比如持久层是用MyBatis还是Hibernate，优秀的程序员可以说出各自的好处是什么，这对于大型项目来说可能是至关重要的；区别不是很明显，因为我的项目很小，需要的数据库读写也很简单。。。有人说小项目有助于开阔技术视野，但只有小项目无法深入理解技术本身，因为你无法比较和理解同类技术的优劣。这也是为什么《玩具代码》学习新东西有成就感，也很适合做技术分享片，但不能带给工程师持续成长的原因。你这么认为吗？原文链接：http://www.raychase.net/1638
