在过去的几年中,我在MySQL空间设计了几个应用程序,然后不断改进性能和可扩展性方面,我感到很自在.我也有一些使用memcached的经验,可以在经常查询的结果集上提供应用程序端加速.最近我将Amazon SDB作为我电子商务实验的主要"数据库".
为了过度简化,我在脑海中使用SDB服务的快速理由是,使用无模式数据库结构可以让我专注于我的项目的逻辑问题,并在我的数据存储中快速累积内容.也就是说,不要担心事先设置和规范产品属性的所有可能排列; 只需开始加载产品,SDB就会记住所有可用的东西.
现在我已经设法完成了项目的前几次迭代,并且我需要为数据设置简单的接口,我正在运行我曾经认为与MySQL合作的问题.例如:在select语句中进行分组并限制语法以查询"items 50到100".我使用SDB的无架构体系结构获得的轻松优势,使用仅超过1800个项目查询/循环结果集而失去了性能.
现在我正在阅读像Tokyo Cabinet这样的项目,这些项目正在扩展内存中键值存储的概念,以极其快的速度提供伪关系功能(14x我在某处阅读).
我的问题:我作为应用程序设计人员/开发人员可以通过哪些基本指导或启发式方法来评估哪个数据库技术最适合我项目的每个阶段.
例如:在原型设计阶段,应用程序的逻辑/技术未知数使数据结构变得流畅:使用SDB.在用户可交付成为优先级的更成熟的阶段,使用传统工具,您不必花时间编写排序,分组或分页逻辑.
非常感谢使用这些工具的实际经验.
谢谢!
沙希布
您发现的问题是RDBMS专家为什么会看到一些带有黄疸眼睛的替代系统.是的,替代系统可以非常快速地处理某些特定要求,但是一旦你想用相同的数据做其他事情,最快就会变得落后.相比之下,RDBMS通常以更大的沉着来管理变化; 它可能没有最快的微型优化处理的专业工作量那么快,但在被要求处理其他查询时很少会恶化.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
