Вариант использования: AirAsia AVA Chatbot

Прежде чем я начну, я хочу сделать несколько заявлений об отказе от ответственности:

• Я не работаю в AirAsia.
• То, что я предлагаю и пишу здесь, это только мое личное мнение и интерпретация, что означает, что я могу ошибаться.

Введение

История начинается, когда я забронировал рейс в Корею в ноябре следующего года через AirAsia. Однако я должен был отменить рейс по личным причинам, и отмена должна была быть выполнена через AVA чатбот,

Для возврата средств требуется, чтобы пользователь предоставлял определенную информацию последовательно:

1. Номер заказа (номер бронирования рейса)
2. Фамилия / Имя
3. Собственное имя
4. Дата рождения
5. Адрес электронной почты

Я также предоставил скриншот ниже.

Теперь мы понимаем поток возврата и какую информацию он требует. Давайте разработаем и макет базы данных.

Подготовка данных

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

Что мне нужно?

1. Мне нужен список записей, который содержит информацию о бронировании авиабилетов. Информация о бронировании включает в себя booking_no, first_name, last_name, date_of_birth и адрес электронной почты.Это обязательное поле в нашей коллекции. Я также создам еще два поля, которые являются источником и местом назначения,просто чтобы сделать это более похожим на реальные производственные данные.
2. Мне также требуется инструмент для генерации данных, чтобы сгенерировать набор данных из миллиона документов в нашу коллекцию, поскольку это позволяет нам находить более важные результаты, особенно во время запроса. После некоторого поиска в Google я обнаружил инструмент на GitHub, mgodatagen, что позволяет мне генерировать случайные данные в MongoDB с очень минимальной конфигурацией.

Без дальнейших церемоний, давайте погрузимся в шаг.

Шаг 1. Загрузите инструменты из библиотеки генерации данных. выпуск страница

Пожалуйста, загрузите библиотеку в соответствии с операционной системой вашей рабочей станции. Вы увидите исполняемый файл mgodatagen после извлечения. Скриншот предоставлен ниже.

Шаг 2. Создайте config.json

В соответствии с библиотекой генерации данных, существует некоторая обязательная конфигурация, которую мы должны указать, например, имя базы данных, имя коллекции, сколько документов вы хотите сгенерировать и т. Д.

Вот сутьconfig.jsonкоторый я создал на том же уровне каталога.

Суть в основном говорит нам:

• Где мы собираем данные - базу данных о рейсах и сбор заказов. Если эту базу данных и коллекцию еще предстоит создать, не беспокойтесь, поскольку MongoDB создаст ее для вас до вставки данных.
• Сколько данных мы генерируем - миллион, как мы определили в подсчетеключ.
• Какие документы мы генерируем и какие поля. Мы определили это в ключе содержимого. Мы добавили ключ, который нам нужен, а также их соответствующие типы. Например, booking_no - это строка длиной не менее 6 символов.

Теперь у нас есть все настройки, давайте выполним генерацию данных. Для генерации данных нам просто нужно выполнить следующую команду.

./mgodatagen -f config.json

Потребовалосьconfig.jsonмы определили ранее и сгенерировали данные. Ниже приведены скриншоты процесса генерации данных и результата успешной генерации данных.

Шаг 3. Проверьте генерацию данных

Теперь давайте проверим, что база данных и коллекция генерируются в вашей локальной MongoDB через Compass. Обратитесь к скриншоту ниже.

Идентификация проблемы

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

Давайте попробуем следующие сценарии:

• Запрос бронирования рейса с помощью booking_no
• Запросить бронирование рейса по фамилии
• Запросить бронирование рейса по имени

Давайте посмотрим, что у них общего

Есть три ключевых момента, которые мы должны рассмотреть здесь для производительности MongoDB.

1. Соотношение между возвращенными документами и проверенными документами. Чтобы найти это единственное бронирование, нам нужно отсканировать миллион документов, что является довольно плохим соотношением.
2. Фактическое время выполнения запроса. Чтобы найти это бронирование, потребовалось 899 мс, что уже довольно близко к 1 секунде. Это считается довольно плохим результатом.
3. Метод MongoDB использует для запроса документа. По умолчанию MongoDB использует сканирование коллекции, и мы можем оптимизировать это, внедрив сканирование индекса, которое будет обсуждаться в следующем разделе.

Реализация решения

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

Если у вас есть поток стандартных операционных процедур (SOP), то оптимизировать запрос к базе данных очень просто. Если ваш вариант использования тоже выглядит так, возможно, вы могли бы реализовать такое же решение, как и здесь.

В этом сценарии мы знали, что AirAsia всегда имеет следующий SOP, когда приходит в поток возврата. Они будут запрашивать информацию последовательно, а именно:

• Бронирование №
• Фамилия
• Имя

Шаг 1: Создать индекс для бронирования №.

Давайте создадим индекс для поля booking_no. Если ваш индекс включает только одно поле, мы называем это однополевый индекс, Создать индекс легко с помощью MongoDB Compass. Вы можете следовать пошаговой инструкции на скриншоте ниже.

Напишите имя индекса и настройте, какое поле является определением индекса. В этом случае мы настраиваем booking_noв качестве поля индекса. Порядок мы ставим в порядке возрастания первым

Готовы ли вы увидеть, насколько улучшается производительность запросов после этой простой конфигурации? (Ад да!)

Значительно улучшена производительность запросов благодаря простой настройке индексации.

1. Мы рассматриваем только один документ и возвращаем только один документ. Это соотношение (возвращенные документы, поделенные на изученные документы) 1 идеально.
2. Среднее время выполнения запроса сокращается почти в 50 раз. Сейчас только 18 мс, по сравнению с 899 мс ранее.
3. Мы используем лучший подход, который заключается в сканировании индекса вместо сканирования всей коллекции. Это приводит к лучшей производительности.

Шаг 2. Создайте составной индекс, используя фамилию и имя

Теперь мы улучшили производительность запроса, если пытаемся сделать запрос, используя booking_no,Но предположим, что Служба поддержки сообщает, что большинство наших клиентов не могут вспомнить номер своего бронирования. Вместо этого они предлагают использовать имя клиента.

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

С какими проблемами мы сталкиваемся здесь?

• Мы столкнулись с точно такими же проблемами с производительностью, которые у нас были до создания индекса, а это длительное время выполнения запроса с использованием метода сканирования коллекции.
• Есть еще одна проблема, с которой мы сталкиваемся: имя пользователя разделено на два поля: имя и фамилия. Попытка сделать запрос, используя только фамилию, вернет вам слишком много ненужных записей. Здесь мы должны создать составной индекс,

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

Создание составного индекса так же просто, как и в случае индекса с одним полем. Все, что вам нужно сделать, это просто добавить еще одно поле в компас MongoDB. Вы можете следовать на скриншоте ниже.

Теперь наш составной индекс для имени создан. Давайте проверим производительность запроса.

Как показано на втором снимке экрана выше, мы смогли оптимизировать производительность запроса, близкую к 0 мс, используя в запросе как фамилию, так и имя.

Мы оптимизировали случай, когда запросы включают в себя:

• Только фамилия
• Фамилия и имя

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

Это связано с тем, что составной индекс учитывает порядок полей при создании индекса. Мы ставим фамилию перед именем, когда создаем этот индекс.

Таким образом, фамилию всегда нужно указывать первой, если вы хотите использовать составной индекс, который вы только что создали.

Вывод

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

• Индексы одного поля
• Составные полевые индексы

В MongoDB есть еще много разных типов индексов, но пока это все.

Приятной оптимизации и спасибо за чтение.

Ссылки

• Университет MongoDB M201 Performance Course
• MongoDB Индексы Документация
• AirAsia AVA Chatbot