在您拥有处理所有业务事务的关系数据库的环境中,将 SimpleDB 用于所有数据查询以进行更快、更轻量级的搜索是一个好主意吗?
因此,主数据存储将是一个关系数据库,它被“复制”/“转换”为 SimpleDB,以提供非常快速的只读查询,因为不需要 JOINS 和复杂的子选择。
在您拥有处理所有业务事务的关系数据库的环境中,将 SimpleDB 用于所有数据查询以进行更快、更轻量级的搜索是一个好主意吗?
因此,主数据存储将是一个关系数据库,它被“复制”/“转换”为 SimpleDB,以提供非常快速的只读查询,因为不需要 JOINS 和复杂的子选择。
您正在考虑的过早优化的气味...
您是否对您的应用程序进行了基准测试?您是否将搜索查询确定为性能瓶颈?您是否在数据库中正确实现了索引?
如果(这是一个很大的假设)没有办法使用关系数据库为您的用户提供体面的搜索时间,那么使用 NOSQL 可能是值得考虑的事情......但不是在此之前!
如果数据大部分是只读的,请尝试使用索引视图。否则,将数据缓存在应用程序中。
我仍然很难相信,但我们的实验表明,从 EC2 实例到 simpledb 的往返平均为 300 毫秒左右,在美好的一天!在糟糕的一天,我们看到它下降到 1.5 秒。这是针对单个插入的。我很想看到有人复制实验来验证这些结果,但事实上...... simpledb 除了后处理之外没有其他解决方案——在请求/响应周期中,它只会减慢速度。
SimpleDB 是一项很好的技术,但它声名鹊起的并不是比关系数据库更快的查询。将查询卸载到复制的 SimpleDB 不太可能显着提高查询响应时间。