关于couchdb 想说的

1,(文档类型数据库) 属性结构

[

        {"_id":"Food",   "path":["Food"]},

        {"_id":"Fruit",  "path":["Food","Fruit"]},

        {"_id":"Red",    "path":["Food","Fruit","Red"]},

        {"_id":"Cherry", "path":["Food","Fruit","Red","Cherry"]},

        {"_id":"Tomato", "path":["Food","Fruit","Red","Tomato"]},

        {"_id":"Yellow", "path":["Food","Fruit","Yellow"]},

        {"_id":"Banana", "path":["Food","Fruit","Yellow","Banana"]},

        {"_id":"Meat",   "path":["Food","Meat"]},

        {"_id":"Beef",   "path":["Food","Meat","Beef"]},

        {"_id":"Pork",   "path":["Food","Meat","Pork"]}

 ]

这种方式向上，向下都很快，而且id 必须 是节点名称，既保证唯一性，又保证不需要额外的id 需要二次搜索

查看所有的父节点，直接path

查看所有的子节点 "path": {

        "$elemMatch": {

            "$eq": "Food"

        }

    }

插入 根目录，也就是bo中parent 为null，直接path，_id使用名称存入

插入子节点，_id 依然名称，path 在父节点的path后append 自己的名字

删除节点是不安全的（父节点可被删除），这个可以从业务上保证不能被删，也可以忽略它，反正不影响业务逻辑，就是难看而已

path中包含id 是个冗余，简化了查询操作

悲剧问题，id 是不能修改的，如果写错了只能删除，如果被引用哪就悲剧了，

所以还得添加name，url作为补充

差点被骗了，这个结构有严重问题，名称不可修改，看来还得二次查询，直接用名称作为id有大问题，所以id还是不要用名称

2,view 本身性能很好，如果include_docs 性能急剧下降，掉了4，5倍速度

3，bulk_get 根本没用性能提升，基本相当于多个get累加

4，原来一直以为是couchdb的并发没设置好，原来这孙子是疯狂消耗cpu，cpu成为瓶颈了，用linode 32核 192gB 的服务器每秒才5900+ 请求，单个核心才300+请求，shit 一样，这个性能问题2011年就提出来了，到现在2018年12月还是这个逼样子，couchdb项目负责人跟我说三台可用并发达到20k，你麻痹大概就是这个最高配再优化一下吧