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