Как настроить CosmosDB, когда нужно искать «лайк» в строковых тегах - PullRequest
0 голосов
/ 15 октября 2019

У меня есть структура из 3 таблиц, Клиент , Счет , InvoiceItem , который я хотел бы попытаться переместить из реляционной БД и сохранить ее в CosmosDB,В настоящее время в таблице InvoiceItem выполняется довольно интенсивный запрос. Эта таблица InvoiceItem имеет до 10 необязательных столбцов TagX , которые в основном представляют собой текст, который может включать марку, группу, тип или что-то, что объединит этот InvoiceItem исделайте поиск доступным, сказав (упрощенно):

SELECT * FROM InvoiceItem WHERE Tag1 LIKE '%shirt%' AND Tag2 LIKE '%training%'

Подобный запрос к многомиллионной таблице может занять более 8 минут. Мы работаем над стратегией архивирования и индексами, чтобы ускорить процесс, но мне показалось, что в этом случае стоит попробовать CosmosDB, поскольку все данные представляют собой сценарий «однократная запись-многократное чтение».

Возвращаясь к CosmosDB, как мне работать с этими строковыми тегами в CosmosDB. Для начала я подумал о том, чтобы Invoice и InvoiceItem находились в одном разделе со свойством type, которое могло бы их отличать. Но тогда я нигде не могу прикрепить теги, чтобы их можно было легко найти. Есть идеи как его настроить?

Спасибо!

1 Ответ

0 голосов
/ 15 октября 2019

Проблема с производительностью базы данных учебников, вызванная отсутствием или неэффективным индексированием.

При таком количестве строк важна мощность индекса. Вы не хотите индексировать все поле, вы хотите индексировать только первые n символов столбцов, которые вы индексируете, и только индексированные столбцы, которые вы ищете, с помощью выражений join или direct where.

Идея состоит в том, чтобы индексы были как можно меньше, но при этом обеспечивали бы требуемую производительность запросов.

С 18 миллионами строк вы, вероятно, захотите начать с кардинальности индекса квадратного корня 18 м.

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

индексирование первых 3-4 букв было бы хорошей отправной точкой. Исходя из квадратного корня из 18000000, равного 4242, и ближайшего показателя в 26 (3) (при условии только буквенных символов), который выходит за рамки этого. Даже если алфавитно-цифровое значение, 3 символа по-прежнему являются хорошей отправной точкой.

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

Если я не в порядке, потому что производительность индекса в этой БД слишком высока. реляционная БД, вам нужно будет поэкспериментировать.

Насколько мне известно, запрос на выборку, который занимает более нескольких секунд, является неприемлемым, за исключением редких случаев. Я когда-то работал в охранной компании. Их система управления лицензиями потратила несколько минут, чтобы привлечь крупных клиентов.

После правильной индексации таблиц крупнейшему клиенту потребовалось менее 2 секунд. Мне пришлось просеять таблицу с миллиардами строк для количества загрузок, и у некоторых из этих запросов было 7 объединений.

Если эта база данных не может сделать это с 18-метровыми строками, я бы серьезно подумал о миграцииболее совершенной архитектуре, аппаратному обеспечению, программному обеспечению и т. д.

По мере увеличения количества элементов индекса прирост производительности падает до отрицательного значения по мере того, как количество элементов индекса приближается к количеству элементов таблицы, по сравнению с отсутствием индекса.

Как и в случаевсе вещи в жизни, умеренность. На другом конце спектра индекс с кардиналом 2 почти бесполезен. Половина 8 минут - это 4 минуты, при условии, что распределение почти одинаковое… бесполезно, поэтому обычно индексация логического поля не является хорошей вещью. Есть несколько жестких и быстрых правил. Много крайних случаев. Эксперимент - твой друг.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...