CouchDB使用地理空间索引
项目地址：https://gitee.com/xaotuman/couchdb-hastings-docker
国外加速（
大概？)：https://github.com/szx741/couchdb-hastings-docker
docker hub上的镜像地址：https://hub.docker.com/r/xaotuman/couchdb-hastings-3.1.1
起因
由于自己做的一个项目需要使用CouchDB来查询地理空间数据，那么就需要给CouchDB加上这样的功能。之前找了好久，发现有一个Geocouch的插件，但是因为版本太老了，是八年前的东西，只适配Couchdb1.x版本的，本来想硬着头皮魔改这个geocouch，但是经过我的不懈努力，在couchdb的issue中找到另一个希望，链接中这个人说可以将hastings/easton绑定couchdb实现地理空间查询。一下子有希望了啊，虽说他说是17年的文档，但我还是看到了希望，比起geocouch好多了。
战略性调研
于是接下来我去看他17年写的wiki文档，发现写的有模有样于是着手开始编译了。
但是我花了好几天时间在本地编译（其实就两天
)，发现怎么都不行啊，人有、尿，把能看的issue都看了一遍，都不行。因为我使用的Couchdb是3.1.1，而示例和Couchdb给的都是2.x，而且环境什么的也不是很确定，所以我最终还是没搞定，开组会的时候直接说还在试
。
我看了一下这两个仓库的更新，发现基本上都是17，18年更新的，确实那个时候只有2.x版本，虽然现在有些不痛不痒的更新，但是能不能支持3.x也是个问题，但能支持2.x也行，用老罗的话来讲，又不是不能用。
转机
再经过一波不懈努力，我找到一个使用这个做的docker镜像，一下子又找到希望了，真是山重水复疑无路，柳暗花明又一村。用了一下，发现能直接用，我靠，直接一波舒服了好吧。
但是他也不更新了，文件还是四年前的更新，couchdb是2.1.1版本的，就人有点尿好吧，当然目前的备用应急方法已经有了，至少能用，只不过版本老一点，但也没那么老，凑活用用也行。
但我这个人就是喜欢用新东西，不管是系统还是软件，我都升级到最新版，如果有问题么再回退，因为我不甘心止步于此，想要升级Couchdb版本。
塔塔开
由于之前是直接在linux上本地编译，会破坏环境，很不好，之前用原生couchdb也是通过docker的方式，使得环境干净一点，也不用编译。
因此这次改进前人的dockerfile，构建一个docker，版本先做到couchdb2.3.1，先把2.x版本拉到最顶，因为hastings和easton没有升级文档，只有git hash值，所以只能根据时间和实际修改内容一个一个试一下，判断一下哪个能够对应哪个couchdb版本，然后每次一次试，都会重新构建docker，虽然docker会有缓存机制，会从修改点重新开始构建，但是因为最主要的couchdb每次都要重新编译，相当麻烦费时，而且也不会修改难一点的错误。或者有时候编译成功了，但是你一用，报错，说缺少什么什么，但咱也不懂啊，哪懂这个，只想碰碰运气能不能碰出来。果然经过好几天的碰撞，就试出来了，把我高兴坏了。
一自摸塔塔开
我google搜索couchdb 和geo 这两个关键词的时候，搜到ibm的文档，发现cloudant，怎么这么熟悉，原来是因为hastings和easton是由cloudant-lab编写的，然后他们这个cloudant就是个项目。
IBM Cloudant 适用于超大规模、安全永续、全局可用应用的数据层，基于开源 Apache CouchDB
他们这个项目是基于couchdb实现的，但是加了一些其他东西，变成商业收费的了，里面正好有这个geospatial的功能，他们使用了！而且我看了一下几句使用语句，发现差不多基本上一模一样的，看来就是那个半死不活的hasting和easton做出来的，他们正好有个示例，给了一个url，这个就是couchdb的基础上查询geo。
https://education.cloudant.com/crimes/_design/geodd/_geo/geoidx?g=POINT(-71.0537124 42.3681995)&nearest=true&limit=5
然后couchdb查询版本号的话，只需要url就行了，也就是这一段https://education.cloudant.com，直接查询能看到版本号。我一看，居然是3.1.1！！！那么说明什么？说明他们就是用couchdb3.1.1实现的，那么我非常有希望能够把couchdb3.1.1也编译成功。
于是趁热打铁，一手高歌猛进，直接弄couchdb3.1.1版本的，hasting和easton选择到我觉的应该能成的版本，但是就是没有成功，我试了好几次，人又有点受到打击，于是我认真看一下docker里面的日志，发现报错，编译后的main.js文件中缺少Spatial这个库，我对这个库有印象，因为编译是我们自己写进去的，但怎么没有加载成功能，明明2.3.1都可以，我怀疑是3.1.1可能变动了什么，导致不能够成功，尝试看看能不能改一下，于是我进到docker里面看main.js文件，发现调用了Spatial，但是没有引入Spatial，我想着不对啊，这个文件我们编译的时候写了啊，编译完后应该会写进去啊，但是我说实话也不知道这个是怎么编译的，怎么把那个文件引入进去，我只能看看所有dockerfile进本所有的修改有没有成功，经过我的查找，发现就有一处，明明sed会把这句话加进去，居然没有，正好是JsFiles下的语句。虽然我不懂，但我大概明白，这是个jsfile编译，编译完生成main.js，然后里面有库，因为你jsfile下没有引入成功，所以生成的里面也没有。但我看sed插入的那一条语句明明存在，怎么会这样子呢，我于是找来了2.3.1和3.1.1这个文件，玩一手大家来找茬，果然被我找到了。
这是2.3.1版本的语句
JsFiles = ["share/server/json2.js",
"share/server/filter.js",
这是3.1.1版本的语句
JsFiles = [
"share/server/json2.js",
经过我缜密的判断，发现JsFiles和等于号之间多了一个空格，因此所以没有把新的库添加进去，就修改了这一个，发现居然成功了！！！！当时奥运团体女乒正好赢了，把我也给振奋了，把我整会了。而且2.3.1和3.1.1都是同一天搞定的，把我给舒服到了，有种拿到金牌的爽感。
后续
但是这个镜像发现有点大，太大了，2.68GB，这也太大了，前人的我没看，应该也才一个G多，再看原版的CouchDB3.1.1，才191MB，把我整尿了，因为我是拿debian构建的原因？因为有好多依赖要装，其中还有几个file需要make之后才能安装进去，但是过大了。ubuntu的iso镜像也才2点多G，我这一个docker就这么大了。但我也不会优化，笑死，根本不懂docker。于是上网查询docker压缩体积方法，发现十几篇都是一模一样的，中国互联网啊，抄袭太严重了。而且方法并不能适用于我，他们那种就是一个nodejs文件，一个java文件，说太大了，编译完只有一个文件这优化那肯定简单，关键我还需要好多个依赖，而且couchdb还不能脱离这些依赖，反正弄了大半天，最后放弃了，弄不来，就采用最朴素的方法，将能删的文件删掉，将不用的库删删掉，但一看，才掉了100M
。这不对啊，上网一查，原来是COPY进去的文件，虽然删除了，但是由于这个docker建立的过程是一步一步缓存起来的，那么之前的容量是叠加上去的，所以就很尿。那我把这些构建信息给删了就行了，将容器导出，再导入为镜像，这样子就能起到压缩效果。但是构建信息没有了，确实非常可惜，而且一些元数据、命令和端口映射也没有了，但镜像压缩到1.05GB了，但压不下去了。1G虽然很大，但是凑活用用也可以了。上传到docker hub的压缩包有460MB，也只能说勉勉强强还行。
于是，目前就到此为止了，希望他这个库能够不出幺蛾子，因为我看到有人说某个功能出错，巴拉巴拉的，我赶紧试一试所有的功能，希望别出问题，老天保佑。
_oo0oo_
o8888888o
88" . "88
(| -_- |)
0\ = /0
___/`---'\___
.' \\| |// '.
/ \\||| : |||// \
/ _||||| -:- |||||- \
| | \\\ - /// | |
| \_| ''\---/'' |_/ |
\ .-\__ '-' ___/-. /
___'. .' /--.--\ `. .'___
."" '< `.___\_<|>_/___.' >' "".
| | : `- \`.;`\ _ /`;.`/ - ` : | |
\ \ `_. \_ __\ /__ _/ .-` / /
=====`-.____`.___ \_____/___.-`___.-'=====
`=---='
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
佛祖保佑 永不宕机 永无BUG
