我一直在搞乱英国邮政编码/协调的军械调查Code-Point Open数据集。由于Couch.io提供了一个免费的托管CouchDB实例，我以为我会将我的地理数据放入其中一个，在此过程中学习一些关于CouchDB的内容。
这个想法是因为CouchDB应该善于处理大型数据集（邮政编码数据大约是170万条记录）并且本身使用REST / JSON，它可以很好地与客户端jQuery配合使用以与Google一起使用地图应用程序。
我最初的目标只是能够使用邮政编码作为参数进行AJAX调用，获取具有lat / lon属性的单个JSON对象，我可以在我的脚本中使用它（显示该邮政编码的标记） 。
我已经成功完成了这项工作，但是来自关系数据库背景，它比我想象的要复杂得多;当我阅读更多有关CouchDB的内容并稍微使用它时，我得到的印象是它不是真正适合这项工作的工具，我是否真的将它用于实际项目。
我是否认为动态查询对CouchDB来说有点弱点？是否更多的目的是返回大型数据集中不会经常改变的大型视图？在发挥其优势方面，CouchDB的“好”和“坏”用途可能是什么样的？
答案 0 :(得分：5)
我是Couchio的主要托管人。很高兴你正在享受CouchDB。
我的感觉是，基本上，关系数据库在大数据集不断变化的一次性查询中更加平坦。通过所有数据仍然需要永远。 SQL和NoSQL都不是那里的银弹。但是，从广义上讲，如果您已经知道要问什么问题，NoSQL数据库会更好。换句话说，这不是数据改变多少的问题，而是查询改变了多少。
这就是理论。对于您的具体项目，CouchDB是否合适？我的感觉是，在基本数据集上创建许多索引没有任何问题。仅索引查询的好处是，查询发生得非常快。 CouchDB特别需要重新索引新数据，即使对于平均值或XOR校验和等查询也是如此。
所以，即使您有可能执行的一百种不同类型的查询，如果您已经知道这些查询是什么，请将它们写下来。但是，如果你永远不会停止提出全新的问题，那么CouchDB将很难跟上。