2016-02-07 5 views
0

Я страдаю от производительности N1QL. У меня есть установка узла узла с узлом 4.1, с 6 гб каждого узла и 1 набор реплик. Всего было добавлено 2 миллиона документов среднего размера 100 тыс. При выборе документа с использованием N1QL запрос объединяется в одном и том же ведре, поэтому может выглядеть как самосоединение. Я получаю данные за 21 минуту. Что ужасно. На ключе, к которому я присоединился, я уже создал индекс. Что еще мне не хватает. Для меня, если ForestDB действительно работает, он должен дать мне результат в секунду. Ищете ответ здесь. Тем не менее, не получило поддержки от форумов couchbase.Производительность N1QL с соединением

+1

Можете ли вы рассказать нам, какой документ имеет No_ в качестве первичного ключа, а какой нет в качестве внешнего ключа? Я маскирую о N и X. То есть, у N документов нет No_ в качестве первичного ключа, или у документов X есть No_ в качестве первичного ключа? – geraldss

+0

Не могли бы вы обновить свой вопрос с помощью запроса N1QL? Это может пролить свет на проблему ... – user1697575

+0

Как уже было сказано, это не вопрос, и обсуждение этой оптимизации производительности здесь: https://forums.couchbase.com/t/perfomance-issue-with-n1ql-self -join/6745/12. Я не уверен, почему вы говорите «не получал много поддержки», так как мои коллеги из Couchbase пытаются помочь вам там. –

ответ

3

Пожалуйста, создайте следующий индекс и попробуйте выполнить под ним запрос.

CREATE INDEX idx_gle_type_balance2 ON NAV(No_, Balance, Type) WHERE (Type = 'GLEntry') USING GSI; 

select 
X.No_ AS No_, 
IFNULL(Sum(X.Balance),0) as Balance 
from NAV X USE INDEX (idx_gle_type_balance2) 
Where X.Type = "GLEntry" 
and X.Balance IS NOT MISSING 
AND X.No_ IS NOT MISSING 
Group by X.No_; 

----- Обновление от Siddu, с новым индексом на месте, выполняется за 1,7 секунды.

Смежные вопросы