标签: couchdb-2.0

我目前正在开发一个docker-compose设置,可用于部署CouchDB 2节点集群.我终于让节点工作并且数据在节点间同步,但除非我弄错了,否则看起来CouchDB不会同步用户会话.

我的设置有3个节点,并使用几乎与haproxy.cfg相同的haproxy设置.根据我的配置,haproxy将端口5984上的传入流量路由到所有3个节点上的端口5984.

假设管理员用户名root和密码为password.

我首先登录:

curl -vX POST http://localhost:5984/_session -H 'Content-Type: application/x-www-form-urlencoded' -d 'name=root&password=password'

请注意,返回的AuthSession在下面用作AUTHSESSION.

然后,我发出以下内容:

curl -X PUT http://localhost:5984/mydb --cookie AuthSession=AUTHSESSION -H "X-CouchDB-WWW-Authenticate: Cookie" -H "Content-Type: application/x-www-form-urlencoded"

这通常会失败,"你不是服务器管理员."我可以继续发出相同的PUT,它最终会成功,因为我认为haproxy最终将请求路由到我通过身份验证的单个节点.由于haproxy使用循环法,我将有三分之一的机会击中目标节点.

我认为CouchDB 2可以处理跨节点同步用户会话.我在这做一个愚蠢的假设吗？

(请通过docker-compose查看运行集群以复制我的设置)

使用docker-compose设置的特定解决方案进行更新

根据@lossleader,您需要在[couch_httpd_auth]部分中设置秘密,以使其在节点之间相同.此外,您需要在[admins]部分中设置相同的管理员用户名和密码.我在这里错过的细节是所有节点必须在.ini文件中具有完全相同的密码哈希.拥有相同的明文密码是不够的,否则,每个节点将生成自己的salt并生成不同的哈希.

有关我的完整设置,请参阅通过docker-compose运行集群.

当用户想要搜索数据库时,我使用Couchdb进行Mango查询.他们可以搜索文档中的多个字段.

为了简化,我有一个包含三个字段的文档,所有这些字段都可以搜索以查找文档.

FieldOne: cow
FieldTwo: pig
FieldThree: dog

为查询创建芒果索引时,我应该使用哪些字段？我应该用多个字段创建和索引吗？订单重要吗？

在字段中还定义了三种不同的文档类型(A,BC).我只需要搜索一个,是否可以从索引中排除其他类型以使其更快？

Field_Type: A

能够针对视图运行索引以仅搜索我感兴趣的文档是有意义的.这可能吗？

示例索引

已知出现在查询中的字段上的一个索引

  {
       "index": {
          "fields": [
             "FieldOne"
          ]
       },
       "name": "foo-json-index",
       "type": "json"
    }

多个索引,不确定是否使用？

 {
       "index": {
          "fields": [
             "FieldOne",
             "FieldTwo",
             "FieldThree"
          ]
       },
       "name": "foo-json-index",
       "type": "json"
    }

或者多个索引在构建查询时选择正确的索引？

获得最快搜索结果的正确方法是什么？

由于我的服务器上运行着多个 couchjs 进程，我正在尝试将 couchdb 视图转换为 Erlang。

我浏览了一些教程和一些 stackoverflow 问题，但没有看到任何人谈论我应该在哪里输入代码并按保存按钮（或 http api）。旧文档谈到了临时视图，但似乎这个功能在 couchdb 2.1 中不存在。

我已经启用了native-erlang-query-server

编辑：我尝试更改语言，但收到此错误。仅将内容类型更改为multipart/form-data也不起作用

EDIT2：正如胡安霍·罗德里格斯所说，与 PUT 合作

I\xe2\x80\x99m 深入研究 CouchDB 2，并且 I\xe2\x80\x99m 发现一些意外的序列号排序。在一种情况下，我发现 _changes feed 中的早期更改具有序列号

99-g1AAAAI-eJyd0EsOgjAQBuAGiI-dN9C9LmrBwqzkJtrSNkgQV6z1JnoTvYneBEvbhA0aMU1mkj6-_NMSITTJfYFm2anOcsFT10mpTzyG-LxpmiL32eqoN8aEAcWE9dz_jPCFrnzrHGQchiFM4kSgaV0JqQ6VFF-AtAV2DggMgCEGxrNhQfatc3bOyDiKUalg2EBVoCu66KapazcUh41e69-GssjNIvcWWRokk2oNofwj0MNazy4QFURhGQ0J9LKI-SHPIBHEgiak51nxBhxnrRk\n

对于同一数据库，我的 _changes feed 中的最后一个序列号是

228-g1AAAAJFeJyd0EkOgjAUBuAGTJCdN9AjlIKFruQm2jFAEFes9SZ6E72J3gQ7JW7QCGnyXtLhy-vfAgCWVSjAip96XglW-o5afRJQwNbDMDRVSOuj3ogQJRgiOnL_O8I2urKdd4B1KCRpkRcCxH0npKo7KX4ApQH2HogsAElOKOPTBjkY5-yd2DqKYqnItA91C13BRTdNXY0VWouRrV7JDOvmrLuxlLW4VAlJ5Qzr4aznJ2wskIIy-y9sh7wcYoMKLJKRXOACjTxr3uHcsBE\n

在浏览器控制台中，以下内容是错误的

'228-g1AAAAJFeJyd0EkOgjAUBuAGTJCdN9AjlIKFruQm2jFAEFes9SZ6E72J3gQ7JW7QCGnyXtLhy-vfAgCWVSjAip96XglW-o5afRJQwNbDMDRVSOuj3ogQJRgiOnL_O8I2urKdd4B1KCRpkRcCxH0npKo7KX4ApQH2HogsAElOKOPTBjkY5-yd2DqKYqnItA91C13BRTdNXY0VWouRrV7JDOvmrLuxlLW4VAlJ5Qzr4aznJ2wskIIy-y9sh7wcYoMKLJKRXOACjTxr3uHcsBE' > '99-g1AAAAI-eJyd0EsOgjAQBuAGiI-dN9C9LmrBwqzkJtrSNkgQV6z1JnoTvYneBEvbhA0aMU1mkj6-_NMSITTJfYFm2anOcsFT10mpTzyG-LxpmiL32eqoN8aEAcWE9dz_jPCFrnzrHGQchiFM4kSgaV0JqQ6VFF-AtAV2DggMgCEGxrNhQfatc3bOyDiKUalg2EBVoCu66KapazcUh41e69-GssjNIvcWWRokk2oNofwj0MNazy4QFURhGQ0J9LKI-SHPIBHEgiak51nxBhxnrRk'\n

这是一个错误还是我需要使用其他方法来比较序列号？

在查看我的 _changes feed 中的其他序列号时，看起来它们通常按照我的预期进行排序，但在这种情况下，当第一个数字（例如 99）从 2 位数字跳到 3 位数字时，排序会中断。如果将其归结为一个简单的字符串比较示例，您可以看到 '228' > '99' => false

假设我的一些文档具有以下结构:

{  
   "something":{  
      "a":"b"
   },
   "some_other_thing":{  
      "c":"d"
   },
   "what_i_want":{  
      "is_down_here":[  
         {  
            "some":{  
               "not_needed":"object"
            },
            "another":{  
               "also_not_needed":"object"
            },
            "i_look_for":"this_tag",
            "tag_properties":{  
               "this":"that"
            }
         },
         {  
            "but_not":{  
               "down":"here"
            }
         }
      ]
   }
}

是否有可以成功选择"i_look_for"具有该值的Mango JSON选择器"this_tag"？它在一个数组内(我知道它在数组中的位置).我也有兴趣过滤结果,所以我只得到 "tag_properties"结果.

我尝试了很多东西,包括$ elemMatch,但一切都回归"无效的json".

这甚至是芒果的用例还是应该坚持观点？