Ван Тантан (Си Мин)

Задний план

Системы заказов — это тип систем общего назначения, которые широко используются в различных отраслях, таких как заказы электронной коммерции, записи в банковских журналах и телефонные счета от поставщиков услуг связи. Традиционные методы для этих систем были установлены в течение десятилетий разработки. Однако развитие Интернета и все большее значение, придаваемое предприятиями данным, приводят к увеличению количества заказов, которые необходимо хранить и сохранять. Растущая важность и масштаб данных создают новые проблемы.

Сценарий

«Платформа электронной коммерции А» должна сохранять все данные о заказах, созданных на этой платформе. Между тем, на основе всех данных о заказе система должна предоставлять разнообразные службы запросов, ориентированные на несколько ролей: потребителей, владельцев магазинов и платформы. Потребители могут запрашивать свои исторические заказы, продавцы могут использовать статистику, чтобы найти самые продаваемые продукты, а платформа также может анализировать такую ​​информацию, как поведение пользователей и масштаб транзакций платформы. Основные методы запросов включают в себя многомерный поиск заказа, анализ данных заказа и статистику. Ниже приведены некоторые примеры:

Запрос, ориентированный на потребителей: [потребитель A] [последний год][продано компьютеров] запрос заказа;

Запрос, ориентированный на продавцов: [продавец Б] * [за последний месяц] заказы на продажу;

Технические соображения

В сценариях заказа необходимо учитывать несколько технических факторов, в том числе:

  • Возможности запроса: должны поддерживаться различные типы запросов, такие как многомерный запрос, запрос диапазона и нечеткий запрос; кроме того, требуются такие функции, как сортировка и статистика.
  • Объем данных: система заказов может хранить огромные объемы данных и соответствовать таким требованиям, как строгая согласованность, высокая доступность и низкая стоимость.
  • Производительность службы: требуется система заказов, чтобы обрабатывать много параллельных запросов и в то же время обеспечивать низкую задержку.

Многомерные запросы в режиме реального времени — основная функция решений для управления заказами. Для получения дополнительной информации проверьте Образец проекта на официальной веб-странице консоли.

Эволюция решения

В электронной коммерции традиционные решения MySQL обычно используются для удовлетворения требований сценариев заказа. Мощные возможности запросов реляционной базы данных позволяют пользователям реализовывать запросы многомерного порядка и статистику данных непосредственно с помощью операторов SQL. Расширение данных включает горизонтальное расширение и вертикальное расширение. Горизонтальное расширение данных означает постоянное итеративное добавление новых измерений поля, а вертикальное расширение данных означает увеличение общего объема хранилища данных. Одни только решения MySQL постепенно становятся все труднее справляться с этими двумя типами расширения данных. Комбинированное решение «SQL + NoSQL» (далее «комбинированное решение») внедряется и используется для удовлетворения потребностей в различных сценариях за счет использования преимуществ обеих баз данных. Однако комбинированное решение также создает новые проблемы: комбинированное решение требует более высоких затрат на хранение, увеличивает объем работ по разработке и усложняет обслуживание. Дополнительные затраты связаны с обеспечением согласованности данных.

Рассмотрим следующие обычные решения:

Обычные решения

(1) Разделение базы данных/таблицы MySQL

MySQL имеет мощный запрос данных и анализ. Создание систем заказов на основе MySQL может удовлетворить требования многомерного запроса данных о заказах и статистики. По мере роста объема данных заказа пользователи могут использовать псевдораспределенное решение для сегментирования базы данных/таблицы для решения проблем, связанных с расширением данных. Однако, как только объем данных достигает узкого места, необходимо заново создавать более крупные сегменты базы данных и выполнять полную миграцию данных, что вызывает непрекращающиеся проблемы. Решение MySQL не может решить проблемы, связанные с итерацией и расширением данных. Недостатки традиционных ордерных решений, зависящих от MySQL, становятся все более очевидными.

1) Вертикальное расширение данных (масштаб данных): для решения сегментирования базы данных/таблиц необходимо оценить масштаб базы данных при развертывании MySQL. Если объем данных достигает верхнего предела, требуется повторное развертывание и полная миграция данных.

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

(2) MySQL + HBase

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

1) Заказы в реальном времени (например, заказы за последние три месяца): заказы в реальном времени хранятся в базе данных MySQL. Это ограничивает скорость расширения общего объема заказов в реальном времени и обеспечивает многомерный запрос и анализ данных в реальном времени.

2) Исторические заказы (например, заказы, размещенные три месяца назад): исторические данные заказов хранятся в HBase. В качестве распределенной базы данных NoSQL HBase можно использовать для эффективного решения задач расширения данных. Это также может обеспечить постоянство исторических данных о заказах.

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

(3) MySQL +ElasticSearch

Еще одно комбинированное решение — MySQL + ElasticSearch. Это решение также разделяет данные для хранения на два типа, чтобы решить проблему увеличенных размерностей индекса порядка. Пользователи сами поддерживают службы синхронизации данных, чтобы обеспечить согласованность двух частей данных.

1) Полные данные: полные данные заказа хранятся в базе данных MySQL. Все данные, кроме идентификаторов заказов, хранятся в виде поля. Полные данные сохраняются и также используются для обратного просмотра неиндексированных полей.

2) Данные запроса: в ElasticSearch (база данных распределенного индекса на основе Lucene) сохраняются только те поля, которые необходимо получить. Возможность индексации Elasticsearch позволяет обрабатывать данные заказа с увеличением размерности и выполнять обратный поиск MySQL для получения полной информации о заказе.

Это решение может решить проблемы, связанные с расширением измерения данных. Однако по мере того, как объем заказов постоянно увеличивается, плохая масштабируемость MySQL снова становится очевидной. В то же время решение по синхронизации данных с ElasticSearch требует больших затрат на разработку и обслуживание. Само по себе это решение имеет некоторые недостатки.

Магазин столов

Решение SearchIndex от Table Store может идеально поддерживать систему заказов, содержащую 100 миллионов заказов. Table Store готов к работе и оплачивается по мере использования. SearchIndex — это оптимальное решение для управления большими объемами метаданных заказов электронной коммерции, которое можно создать в любое время.

Table Store — это полностью размещенная и распределенная служба хранения данных NoSQL от Alibaba Cloud, которая предоставляет такие функции, как хранение больших объемов данных, автоматическое сегментирование горячих данных и многомерное извлечение больших объемов данных. Table Store может эффективно решить проблему стремительного роста данных о заказах.

В то же время SearchIndex обеспечивает многомерный поиск данных, статистику и другие возможности на основе обеспечения высокой доступности пользовательских данных. Вы можете создать несколько индексов для нескольких сценариев, чтобы обеспечить поиск в нескольких режимах. Вы можете создавать и активировать индексы по мере необходимости. Хранилище таблиц обеспечивает согласованность синхронизации данных, значительно сокращая объем работы, необходимой для разработки решения, обслуживания и разработки кода.

Обзор системы заказов на основе Table Store

Образец интегрирован в консоль Table Store. Вы можете войти в консоль, чтобы поэкспериментировать с системой. (Если вы новый пользователь Table Store, вам нужно нажать «Активировать сейчас», чтобы получить пробную версию этой службы. Активация службы бесплатна. Данные заказа хранятся в общедоступных экземплярах. Пробная версия не использует хранилище, сетевой трафик или CU. .)

Примечание. В этом образце представлены данные о заказах примерно для 100 миллионов заказов. Официальный адрес консоли: Образец проекта

Подготовка к строительству

Если вас устраивает система заказов на 100 миллионов заказов, реализованная на базе Table Store, и вы хотите приступить к настройке собственной системы, просто выполните следующие действия:

(1) Активировать хранилище таблиц

Активируйте службу хранилища таблиц в консоли. Table Store готов к работе (оплачивается по факту) и оплачивается по факту использования. Table Store также предоставляет бесплатную квоту, достаточную для функциональных тестов. Для получения дополнительной информации посетите Консоль магазина таблиц и Описание бесплатной квоты.

(2) Создать экземпляр

Создайте экземпляр Table Store в консоли и выберите регион, который поддерживает SearchIndex. (В настоящее время функция SearchIndex не коммерциализирована и поддерживается в следующих регионах: Пекин, Шанхай, Ханчжоу и Шэньчжэнь. Эта функция будет постепенно доступна в других регионах.)

После создания экземпляра откройте билет, чтобы подать заявку на приглашение на бета-тестирование SearchIndex. (После коммерческого использования SearchIndex будет включен по умолчанию. Плата не взимается, если эта функция не используется.)

(3) Скачать SDK

Используйте SDK с SearchIndex (подробнее на официальном сайте). В настоящее время добавлены новые функции для Java, Go и Node.js SDK.

Java-SDK

<dependency>
    <groupId>com.aliyun.openservices</groupId>
    <artifactId>tablestore</artifactId>
    <version>4.8.0</version>
</dependency>

Go-SDK

$ go get github.com/aliyun/aliyun-tablestore-go-sdk

Nodejs-SDK

$ npm install [email protected]

(4) Создайте таблицу

Система заказов включает не только одну таблицу данных заказов. Система заказов должна включать такие таблицы, как таблицы потребителей, таблицы продавцов, таблицы продуктов, таблицы поставщиков, таблицы заказов транзакций и таблицы заказов платежей. В примере в основном используются четыре основные таблицы (таблица потребителей, таблица продавцов, таблица продуктов и таблица заказов транзакций). Возьмем, к примеру, таблицу заказов:

Имя таблицы: order_contract

Начать сборку (основной код)

(1) Создайте таблицу данных

Четыре таблицы: таблица заказов, таблица потребителей, таблица продавцов и таблица продуктов.

Пользователям нужно только поддерживать один экземпляр и создавать таблицы следующим образом: создавать таблицы данных и управлять ими через консоль (они также могут напрямую создавать таблицы данных через SDK):

(2) Создайте индекс таблицы данных

Table Store автоматически синхронизирует полные и добавочные данные индекса: пользователи могут создавать SearchIndex и управлять им через консоль (или они также могут создавать его с помощью SDK):

(3) Импорт данных

Вставьте некоторые тестовые данные (в образец консоли вставлено 100 миллионов записей данных. Пользователи могут вставить небольшое количество тестовых данных на консоль);

(4) Чтение данных

Чтение данных делится на два типа:

1. Чтение первичного ключа

Столбец первичного ключа получается на основе собственного хранилища таблиц: getRow, getRange, batchGetRow. Чтение первичного ключа используется для индексного (автоматического) обратного поиска. Пользователи также могут предоставить одну страницу запроса для первичного ключа (заказ MD5). И скорость запроса чрезвычайно высока в масштабе 100 миллионов записей данных. Многомерное извлечение не поддерживается для запроса с одним первичным ключом;

2. Чтение индекса

Запрос на основе новой функции SearchIndex: интерфейс поиска. Пользователи могут свободно создавать многомерные комбинированные запросы для полей индекса. Задавая и выбирая разные параметры запроса, создаются разные критерии запроса и разные методы сортировки. В настоящее время поддерживаются точный запрос, запрос диапазона, запрос префикса, запрос соответствия, запрос подстановочного знака, запрос соответствия фразы и запрос строки разбиения на слова, и они объединяются логическими операциями И и ИЛИ.

Например, комбинация [заказов потребителя c0001 с потреблением выше 99,99] выглядит следующим образом:

List<Query> mustQueries = new ArrayList<Query>();
TermQuery termQuery = new TermQuery();
termQuery.setFieldName("cId");
termQuery.setTerm(ColumnValue.fromString("c0001"));
mustQueries.add(termQuery);
RangeQuery rangeQuery = new RangeQuery();
rangeQuery.setFieldName("totalPrice");
rangeQuery.setFrom(ColumnValue.fromDouble(99.99)）;
mustQueries.add(rangeQuery);
BoolQuery boolQuery = new BoolQuery();
boolQuery.setMustQueries(mustQueries);

Ссылка: https://www.alibabacloud.com/blog/managing-hundreds-of-millions-of-orders-with-table-store_594801?spm=a2c41.12883479.0.0