Couchbase N1QL查询通常慢

时间:2018-03-08 19:57:50

标签: couchbase n1ql

我使用沙发基地已经有一段时间了,但我从来没有真正体验过沙发基地真的很快。它的速度相当慢。 我想知道我错过了什么设置。

我有一个具有以下规格的根服务器

  • 英特尔®至强®E5-2680V4(4核)
  • 12 GB DDR4 ECC
  • 60 GB SSD

我正在运行Couchbase 4.5.1-2844社区版(build-2844) 7.05GB RAM 已分配

存储桶有1个数据节点,使用4.93 GB, 3,093,889个文档存储桶类型为“Couchbase”缓存元数据设置为“值弹出”。副本已禁用。磁盘 I / O优化设置为低。未启用刷新。

这一百万份文件看起来都很熟悉:

{
  "discovered_by": 0,
  "color": "FFBA00",
  "updated_at": "2018-01-18T21:40:17.361Z",
  "replier": 0,
  "message": "Irgendwas los hier in Luckenwalde?",
  "children": "",
  "view_count": 0,
  "post_own": "FFBA00",
  "user_handle": "oj",
  "vote_count": [
    {
      "timestamp": "2018-01-19 09:48:48",
      "votes": 0
    }
  ],
  "child_count": 3,
  "share_count": 0,
  "oj_replied": false,
  "location": {
    "loc_coordinates": {
      "lat": 0,
      "lng": 0
    },
    "loc_accuracy": 0,
    "country": "",
    "name": "Luckenwalde",
    "city": ""
  },
  "tags": [],
  "post_id": "59aef043f087270016dc5836",
  "got_thanks": false,
  "image_headers": "",
  "cities": [
    "Luckenwalde"
  ],
  "pin_count": 0,
  "distance": "friend",
  "image_approved": false,
  "created_at": "2017-09-05T18:43:15.904Z",
  "image_url": ""
}

查询可能看起来像这样

  

从sauger中选择COUNT(*),其中color ='FFBA00'

没有索引它无法通过couchbase-webapp执行(超时),但索引

  

colorsauger

上创建索引color

结果最多需要 16秒,但经过一些尝试后,每次都需要 2到3秒

有6种不同的“颜色字符串”(如“FFBA00”),查询结果为466920(这是总文件的第6位)

上述查询的解释给了我:

[
  {
    "plan": {
      "#operator": "Sequence",
      "~children": [
        {
          "#operator": "IndexCountScan",
          "covers": [
            "cover ((`sauger`.`color`))",
            "cover ((meta(`sauger`).`id`))"
          ],
          "index": "color",
          "index_id": "cc3524c6d5a8ef94",
          "keyspace": "sauger",
          "namespace": "default",
          "spans": [
            {
              "Range": {
                "High": [
                  "\"FFBA00\""
                ],
                "Inclusion": 3,
                "Low": [
                  "\"FFBA00\""
                ]
              }
            }
          ],
          "using": "gsi"
        },
        {
          "#operator": "IndexCountProject",
          "result_terms": [
            {
              "expr": "count(*)"
            }
          ]
        }
      ]
    },
    "text": "select COUNT(*) from sauger where color = 'FFBA00'"
  }
]

所有内容都设置正确,但是这些简单的查询仍然需要很长时间(并且没有其他任何内容可以从数据库中编写或读取,并且运行它的服务器完全空闲)

1 个答案:

答案 0 :(得分:3)

确保您没有主索引。这将消耗很多索引服务的内存。你的声明说查询超时没有索引让我觉得有一个主索引,否则查询会立即失败。

修改:从Indexing Best Practices博文

添加有关主要索引的更多详细信息
  
      
  1. 避免生产中的主键
  2.         

    可能会发生意外的完整主扫描,并且应该通过在生产中完全避免主索引来消除此类事件发生的任何可能性。 N1QL索引选择是一个基于规则的系统,用于检查将满足查询的可能索引,如果不存在,则转向使用主索引。主索引具有文档的所有键,因此查询将从主索引获取所有键,然后跳转到数据服务以获取文档,然后应用过滤器。如您所见,这是一项非常昂贵的操作,应该不惜一切代价避免。

         

    如果没有创建主索引,并且查询无法找到匹配的索引来提供查询,则查询服务会出错,并显示以下消息。这很有用,可以帮助您适当地创建所需的二级索引:

         

    “键空间travel-sample上没有与您的查询匹配的索引。使用CREATE INDEX或CREATE PRIMARY INDEX创建索引,或检查您的预期索引是否在线。“