Внутренняя часть Couchbase

Question

Один вопрос, касающийся подхода выборки данных,

Первый подход:

Допустим, у меня есть два документа

userdoc1
{
“status”:“pending”
“usertype”:“VIP”
“userid”:“123”
}

для вышеуказанного документаскажем, что у меня documentmentid status :: usertype [просто чтобы уточнить, идентификатор этого документа в нашем случае будет уникальным]

userdoc2
{
“userid”:“123”,
“fname”:“abc”,
“lname”:“xyz”,
“age”:20;
“address”:“asdf”
}

для userdoc2, пусть скажем, userid - это моя документация

Если я это сделаюОперацию get я бы продолжил следующим образом (здесь идея состоит в том, чтобы извлекать данные на основе идентификатора документа)

select userid from userdoc1 with key “pending::VIP”;

, а затем

select * from userdoc2 with key “123”;

Второй подход:

У меня есть только один документ

userdoc
{
“status”:“pending”
“usertype”:“VIP”
“userid”:“123”
“fname”:“abc”,
“lname”:“xyz”,
“age”:20;
“address”:“asdf”
}

Здесь documentmentid - это «status :: usertype», и у нас есть вторичный индекс для идентификатора пользователя

Здесь, если получить такие данные (здесь идея заключается в том, чтобы извлекать данные на основе вторичного индекса):

select * from userdoc, где userd = «123»;

Не могли бы вы объяснить, какой подход даст высокую производительность чтения при условиивысокая загрузка данных со 100 узлами в кластере и XDCR и другие факторы ?

Answer 1

Доминирующим фактором (как говорит Йохан Ларсон в своем ответе), скорее всего, является количество в оба конца.Ваше первое решение будет иметь две двусторонние от приложения до кластера , а второе будет иметь только одну.Однако есть некоторые потенциальные нюансы.

Важно отметить, что поиск по ключу / значению всегда будет самым быстрым.Эти запросы будут направлены непосредственно на узлы, на которых работает служба данных.С помощью Couchbase клиенты получают доступ к узлу, содержащему данные напрямую, а не через систему master-slave.Другими словами, вы можете выполнить ak / v-запрос за одну поездку туда и обратно только с узлом данных, который имеет фактический документ.

Используя ваш первый подход, вы можете полностью избежать N1QL.Просто сделайте прямой k / v get с идентификатором status :: usertype, вытащите идентификатор пользователя, а затем используйте его для создания get второго документа.Вы даже можете использовать API поддокумента только для того, чтобы вернуть идентификатор пользователя.

Второй подход будет включать в себя индекс и запрос N1QL, так что вы потенциально можете использовать до трех разных машин в кластере.Будет ли это быстрее, зависит от топологии.Если ваше приложение работает рядом с вашим кластером (то есть пропускная способность / задержка сети аналогична времени внутри кластера), я думаю, что подход k / v может быть быстрее.Если задержка в сети от приложения к кластеру больше, второй подход, скорее всего, быстрее.

Есть дальнейшее рассмотрение.Если весь результат «покрывается» индексом, который вы создаете для запроса (то есть вы сохраняете все части документа, которые вам нужны, в своем индексе), тогда ответ может быть полностью предоставлен службой индекса.Это сократит подход N1QL до попадания в службу запросов и службу индексирования, что будет быстрее.

Если говорить более подробно, ваш вопрос включает в себя данные, индексацию и запрос.Couchbase разделяет эти функции на отдельные сервисы, что означает, что вы можете масштабировать каждую емкость независимо.Вот почему вы также можете использовать три разных компьютера с помощью запроса N1QL.

Это также будет зависеть от характера загрузки данных.Например, если он тяжелый для чтения или тяжелый для записи.Полнота записи с индексом будет означать обновления индекса, тогда как интенсивность чтения - нет.Точно так же XDCR будет зависеть от чтения против записи.

Answer 2

Вариант 1 будет иметь два обхода от клиента к серверу для выполнения двух дешевых запросов.Вариант 2 будет иметь одну поездку туда и обратно от клиента к серверу, чтобы выполнить один чуть более дорогой запрос.

Я не могу быть полностью уверен, не измеряя, но я бы поставил свои деньги на вариант 2. Затраты на туда и обратноможет быть сукой.

Обязательно используйте правильный индекс для идентификатора пользователя для варианта 2 и используйте подготовленный запрос с идентификатором пользователя в качестве параметра.Это должен быть самый быстрый вариант.