Индексирование данных из База данных SQL Azure

Из этой статьи вы узнаете, как настроить индексатор, который импортирует содержимое из База данных SQL Azure или управляемого экземпляра SQL Azure и делает его доступным для поиска в службе "Поиск ИИ Azure".

В этой статье описано , как создать индексатор с информацией, относяющейся к SQL Azure. В нем используются портал Azure и REST API для демонстрации трех частей рабочего процесса, общего для всех индексаторов: создание источника данных, создание индекса, создание индексатора. Извлечение данных происходит при отправке запроса create Indexer.

Эта статья также содержит следующее:

• Описание политик обнаружения изменений, поддерживаемых индексатором SQL Azure, чтобы настроить добавочное индексирование.

• Раздел часто задаваемых вопросов и ответов на вопросы о совместимости функций.

Необходимые компоненты

• База данных SQL Azure с данными в одной таблице или представлении или Управляемый экземпляр SQL с общедоступной конечной точкой.

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

  Используйте представление, если необходимо объединить данные из нескольких таблиц. Большие представления не идеально подходят для индексатора SQL. Обходной путь — создать новую таблицу только для приема в индекс поиска ИИ Azure. Вы можете использовать встроенное отслеживание изменений SQL для отслеживания новых и измененных строк, что упрощает реализацию, чем high water Mark.

• Разрешения на чтение. Поиск ИИ Azure поддерживает проверку подлинности SQL Server, где имя пользователя и пароль предоставляются в строка подключения. Кроме того, можно настроить управляемое удостоверение и использовать роли Azure.

Для работы с примерами, приведенными в этой статье, вам потребуется портал Azure или клиент REST. Если вы используете портал Azure, убедитесь, что доступ ко всем общедоступным сетям включен в брандмауэре SQL Azure и что клиент имеет доступ через правило входящего трафика. Для клиента REST, работающего локально, настройте брандмауэр SQL Server, чтобы разрешить входящий доступ с IP-адреса устройства. Другие подходы к созданию индексатора SQL Azure включают пакеты SDK Azure.

Попробуйте использовать примеры данных

Используйте эти инструкции для создания и загрузки таблицы в База данных SQL Azure для тестирования.

1. Скачайте hotels-azure-sql.sql из GitHub, чтобы создать таблицу на База данных SQL Azure, которая содержит подмножество примера набора данных отелей.

2. Войдите в портал Azure и создайте базу данных SQL Azure и сервер базы данных. Рассмотрите возможность настройки проверки подлинности SQL Server и проверки подлинности Идентификатора Microsoft Entra. Если у вас нет разрешений на настройку ролей в Azure, можно использовать проверку подлинности SQL в качестве обходного решения.

3. Настройте брандмауэр сервера для всех входящих запросов с локального устройства.

4. В базе данных SQL Azure выберите редактор запросов (предварительная версия) и выберите новый запрос.

5. Вставьте и запустите скрипт T-SQL, который создает таблицу отелей.

   CREATE TABLE tbl_hotels
    (
        Id TINYINT PRIMARY KEY,
        Modified DateTime NULL DEFAULT '0000-00-00 00:00:00',
        IsDeleted TINYINT,
        HotelName VARCHAR(40),
        Category VARCHAR(20),
        City VARCHAR(30),
        State VARCHAR(4),
        Description VARCHAR(500)
    );
   

6. Вставьте и запустите скрипт T-SQL, который вставляет записи.

    -- Insert rows
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (1, CURRENT_TIMESTAMP, 0,  'Stay-Kay City Hotel', 'Boutique', 'New York', 'NY', 'This classic hotel is fully-refurbished and ideally located on the main commercial artery of the city in the heart of New York. A few minutes away is Times Square and the historic centre of the city, as well as other places of interest that make New York one of Americas most attractive and cosmopolitan cities.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (10, CURRENT_TIMESTAMP, 0, 'Countryside Hotel', 'Extended-Stay', 'Durham', 'NC', 'Save up to 50% off traditional hotels. Free WiFi, great location near downtown, full kitchen, washer & dryer, 24\/7 support, bowling alley, fitness center and more.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (11, CURRENT_TIMESTAMP, 0, 'Royal Cottage Resort', 'Extended-Stay', 'Bothell', 'WA', 'Your home away from home. Brand new fully equipped premium rooms, fast WiFi, full kitchen, washer & dryer, fitness center. Inner courtyard includes water features and outdoor seating. All units include fireplaces and small outdoor balconies. Pets accepted.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (12, CURRENT_TIMESTAMP, 0, 'Winter Panorama Resort', 'Resort and Spa', 'Wilsonville', 'OR', 'Plenty of great skiing, outdoor ice skating, sleigh rides, tubing and snow biking. Yoga, group exercise classes and outdoor hockey are available year-round, plus numerous options for shopping as well as great spa services. Newly-renovated with large rooms, free 24-hr airport shuttle & a new restaurant. Rooms\/suites offer mini-fridges & 49-inch HDTVs.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (13, CURRENT_TIMESTAMP, 0, 'Luxury Lion Resort', 'Luxury', 'St. Louis', 'MO', 'Unmatched Luxury. Visit our downtown hotel to indulge in luxury accommodations. Moments from the stadium and transportation hubs, we feature the best in convenience and comfort.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (14, CURRENT_TIMESTAMP, 0, 'Twin Vortex Hotel', 'Luxury', 'Dallas', 'TX', 'New experience in the making. Be the first to experience the luxury of the Twin Vortex. Reserve one of our newly-renovated guest rooms today.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (15, CURRENT_TIMESTAMP, 0, 'By the Market Hotel', 'Budget', 'New York', 'NY', 'Book now and Save up to 30%. Central location. Walking distance from the Empire State Building & Times Square, in the Chelsea neighborhood. Brand new rooms. Impeccable service.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (16, CURRENT_TIMESTAMP, 0, 'Double Sanctuary Resort', 'Resort and Spa', 'Seattle', 'WA', '5 Star Luxury Hotel - Biggest Rooms in the city. #1 Hotel in the area listed by Traveler magazine. Free WiFi, Flexible check in\/out, Fitness Center & espresso in room.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (17, CURRENT_TIMESTAMP, 0, 'City Skyline Antiquity Hotel', 'Boutique', 'New York', 'NY', 'In vogue since 1888, the Antiquity Hotel takes you back to bygone era. From the crystal chandeliers that adorn the Green Room, to the arched ceilings of the Grand Hall, the elegance of old New York beckons. Elevate Your Experience. Upgrade to a premiere city skyline view for less, where old world charm combines with dramatic views of the city, local cathedral and midtown.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (18, CURRENT_TIMESTAMP, 0, 'Ocean Water Resort & Spa', 'Luxury', 'Tampa', 'FL', 'New Luxury Hotel for the vacation of a lifetime. Bay views from every room, location near the pier, rooftop pool, waterfront dining & more.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (19, CURRENT_TIMESTAMP, 0, 'Economy Universe Motel', 'Budget', 'Redmond', 'WA', 'Local, family-run hotel in bustling downtown Redmond. We are a pet-friendly establishment, near expansive Marymoor park, haven to pet owners, joggers, and sports enthusiasts. Close to the highway and just a short drive away from major cities.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (20, CURRENT_TIMESTAMP, 0, 'Delete Me Hotel', 'Unknown', 'Nowhere', 'XX', 'Test-case row for change detection and delete detection . For change detection, modify any value, and then re-run the indexer. For soft-delete, change IsDelete from zero to a one, and then re-run the indexer.');
   
   

7. Выполните запрос, чтобы подтвердить отправку.

   SELECT Description FROM tbl_hotels;
   

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

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

Теперь, когда у вас есть таблица базы данных, вы можете использовать портал Azure, клиент REST или пакет SDK Azure для индексирования данных.

Использование портала Azure

С помощью мастера импорта данных или мастера импорта и векторизации данных можно автоматизировать индексирование из таблицы базы данных SQL или представления. Конфигурация источника данных аналогична обоим мастерам.

1. Запустите мастер.

2. При подключении к данным выберите или убедитесь, что тип источника данных является База данных SQL Azure или базой данных SQL.

   Имя источника данных ссылается на объект подключения к источнику данных в службе "Поиск ИИ Azure". При использовании мастера векторов имя источника данных автоматически создается с помощью настраиваемого префикса, указанного в конце рабочего процесса мастера.

3. Укажите имя сервера, имя базы данных и таблицу или имя представления.

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

   

4. Укажите метод проверки подлинности, имя входа SQL Server, определенное во время установки сервера или управляемое удостоверение.

   Если вы настроите поиск ИИ Azure для использования управляемого удостоверения и создадите назначение ролей на сервере базы данных, который предоставляет участнику SQL Server или участнику базы данных SQL разрешения на удостоверение, индексатор может подключиться к SQL Azure с помощью идентификатора и ролей Microsoft Entra.

5. В мастере импорта и векторизации данных можно указать параметры отслеживания изменений и удаления.

   • Отслеживание удаления основано на обратимом удалении с помощью пользовательских метаданных.

   • Отслеживание изменений основано на встроенном отслеживании изменений SQL Server или отслеживании изменений с высоким уровнем воды.

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

   • Краткое руководство. Мастер импорта данных

   • Краткое руководство. Мастер импорта и векторизации данных

использованию REST API

В этом разделе показаны вызовы REST API, которые создают источник данных, индекс и индексатор.

Определение источника данных

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

1. Создайте источник данных или создайте или обновите источник данных, чтобы задать его определение:

    POST https://myservice.search.windows.net/datasources?api-version=2024-07-01
    Content-Type: application/json
    api-key: admin-key
   
    {
        "name" : "myazuresqldatasource",
        "description" : "A database for testing Azure AI Search indexes.",
        "type" : "azuresql",
        "credentials" : { "connectionString" : "Server=tcp:<your server>.database.windows.net,1433;Database=<your database>;User ID=<your user name>;Password=<your password>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;" },
        "container" : { 
            "name" : "name of the table or view that you want to index",
            "query" : null (not supported in the Azure SQL indexer)
            },
        "dataChangeDetectionPolicy": null,
        "dataDeletionDetectionPolicy": null,
        "encryptionKey": null,
        "identity": null
    }
   

2. Укажите уникальное имя источника данных, который следует соглашениям об именовании поиска ИИ Azure.

3. Задайте для параметра type "azuresql" (обязательный).

4. Задайте для параметра "учетные данные" строка подключения:

   • Вы можете получить полный доступ строка подключения из портал Azure. Использовать параметр ADO.NET connection string. Задайте имя пользователя и пароль.

   • Кроме того, можно указать управляемое удостоверение строка подключения, включающее секреты базы данных со следующим форматом. Initial Catalog|Database=<your database name>;ResourceId=/subscriptions/<your subscription ID>/resourceGroups/<your resource group name>/providers/Microsoft.Sql/servers/<your SQL Server name>/;Connection Timeout=connection timeout length;

   Дополнительные сведения см. в разделе "Подключение к База данных SQL Azure индексатору с помощью управляемого удостоверения".

Добавление полей поиска в индекс

В индексе поиска добавьте поля, соответствующие полям в базе данных SQL. Убедитесь, что схема индекса поиска совместима с исходной схемой с помощью эквивалентных типов данных.

1. Создайте или обновите индекс , чтобы определить поля поиска, в которые хранятся данные:

   POST https://[service name].search.windows.net/indexes?api-version=2024-07-01
   Content-Type: application/json
   api-key: [Search service admin key]
   {
       "name": "mysearchindex",
       "fields": [{
           "name": "id",
           "type": "Edm.String",
           "key": true,
           "searchable": false
       }, 
       {
           "name": "description",
           "type": "Edm.String",
           "filterable": false,
           "searchable": true,
           "sortable": false,
           "facetable": false,
           "suggestions": true
       }
     ]
   }
   

2. Создайте поле ключа документа ("key": true), которое однозначно идентифицирует каждый документ поиска. Это единственное поле, необходимое в индексе поиска. Как правило, первичный ключ таблицы сопоставляется с полем ключа индекса. Ключ документа должен быть уникальным и ненулевым. Значения могут быть числовыми в исходных данных, но в индексе поиска ключ всегда является строкой.

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

Сопоставление типов данных

Настройка и запуск индексатора SQL Azure

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

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

   POST https://[service name].search.windows.net/indexers?api-version=2024-07-01
   Content-Type: application/json
   api-key: [search service admin key]
   {
       "name" : "[my-sqldb-indexer]",
       "dataSourceName" : "[my-sqldb-ds]",
       "targetIndexName" : "[my-search-index]",
       "disabled": null,
       "schedule": null,
       "parameters": {
           "batchSize": null,
           "maxFailedItems": 0,
           "maxFailedItemsPerBatch": 0,
           "base64EncodeKeys": false,
           "configuration": {
               "queryTimeout": "00:04:00",
               "convertHighWaterMarkToRowVersion": false,
               "disableOrderByHighWaterMarkColumn": false
           }
       },
       "fieldMappings": [],
       "encryptionKey": null
   }
   

2. В разделе "Параметры" есть параметры, относящиеся к SQL Azure:

   • Время ожидания запроса по умолчанию для выполнения SQL-запроса — 5 минут, которые можно переопределить.

   • "ConvertHighWaterMarkToRowVersion" оптимизирует политику обнаружения изменений с высоким уровнем воды. Политики обнаружения изменений задаются в источнике данных. Если вы используете собственную политику обнаружения изменений, этот параметр не действует.

   • "disableOrderByHighWaterMarkColumn" приводит к тому, что SQL-запрос, используемый политикой высокой водяной метки, опустит предложение ORDER BY. Если вы используете собственную политику обнаружения изменений, этот параметр не действует.

3. Укажите сопоставления полей, если существуют различия в имени или типе поля, или если в индексе поиска требуется несколько версий исходного поля.

4. Дополнительные сведения о других свойствах см. в статье "Создание индексатора ".

Индексатор запускается автоматически при его создании. Это можно предотвратить, задав для параметра "Отключено" значение true. Чтобы управлять выполнением индексатора, запустите индексатор по запросу или поместите его в расписание.

Проверка состояния индексатора

Чтобы отслеживать состояние индексатора и журнал выполнения, проверьте журнал выполнения индексатора в портал Azure или отправьте запрос REST API состояния индексатора

GET https://myservice.search.windows.net/indexers/myindexer/status?api-version=2024-07-01
  Content-Type: application/json  
  api-key: [admin key]

    {
        "status":"running",
        "lastResult": {
            "status":"success",
            "errorMessage":null,
            "startTime":"2022-02-21T00:23:24.957Z",
            "endTime":"2022-02-21T00:36:47.752Z",
            "errors":[],
            "itemsProcessed":1599501,
            "itemsFailed":0,
            "initialTrackingState":null,
            "finalTrackingState":null
        },
        "executionHistory":
        [
            {
                "status":"success",
                "errorMessage":null,
                "startTime":"2022-02-21T00:23:24.957Z",
                "endTime":"2022-02-21T00:36:47.752Z",
                "errors":[],
                "itemsProcessed":1599501,
                "itemsFailed":0,
                "initialTrackingState":null,
                "finalTrackingState":null
            },
            ... earlier history items
        ]
    }

Журнал выполнения содержит до 50 последних завершенных выполнений, которые сортируются в обратном хронологическом порядке, чтобы последнее выполнение было первым.

Индексирование новых, измененных и удаленных строк

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

Чтобы включить добавочное индексирование, задайте свойство dataChangeDetectionPolicy в определении источника данных. Это свойство сообщает индексатору, какой механизм отслеживания изменений используется в таблице или представлении.

Для индексаторов SQL Azure существует две политики обнаружения изменений:

• "SqlIntegratedChangeTrackingPolicy" (применяется только к таблицам)

• "HighWaterMarkChangeDetectionPolicy" (работает для таблиц и представлений)

Интегрированная политика отслеживания изменений SQL

Мы рекомендуем использовать SqlIntegratedChangeTrackingPolicy для его эффективности и возможности идентификации удаленных строк.

Требования к базе данных:

• SQL Server 2012 с пакетом обновления 3 (SP3) и более поздних версий, если используется SQL Server на виртуальных машинах Azure
• База данных Azure SQL или управляемый экземпляр SQL
• Только таблицы (без представлений)
• В базе данных включите отслеживание изменений для таблицы.
• Составной первичный ключ (первичный ключ, содержащий более одного столбца) в таблице
• Кластеризованные индексы в таблице не отображаются. В качестве обходного решения любой кластеризованный индекс необходимо удалить и повторно создать как некластеризованный индекс, однако производительность может повлиять на источник по сравнению с кластеризованным индексом.

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

POST https://myservice.search.windows.net/datasources?api-version=2024-07-01
Content-Type: application/json
api-key: admin-key
    {
        "name" : "myazuresqldatasource",
        "type" : "azuresql",
        "credentials" : { "connectionString" : "connection string" },
        "container" : { "name" : "table name" },
        "dataChangeDetectionPolicy" : {
            "@odata.type" : "#Microsoft.Azure.Search.SqlIntegratedChangeTrackingPolicy"
        }
    }

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

Политика обнаружения изменений максимального уровня

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

Столбец с высокой водой должен соответствовать следующим требованиям:

• при каждой вставке указывается значение для столбца;
• при всех обновлениях элементов также изменяется значение столбца;
• значение этого столбца растет с каждой вставкой или обновлением;
• Возможно эффективное выполнение запросов со следующими предложениями WHERE и ORDER BY: WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column].

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

POST https://myservice.search.windows.net/datasources?api-version=2024-07-01
Content-Type: application/json
api-key: admin-key
    {
        "name" : "myazuresqldatasource",
        "type" : "azuresql",
        "credentials" : { "connectionString" : "connection string" },
        "container" : { "name" : "table or view name" },
        "dataChangeDetectionPolicy" : {
            "@odata.type" : "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
            "highWaterMarkColumnName" : "[a rowversion or last_updated column name]"
        }
    }

convertHighWaterMarkToRowVersion

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

• Использует тип данных rowversion для столбца высокой водяной метки в sql-запросе индексатора. Использование правильного типа данных повышает производительность запросов индексатора.

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

Чтобы включить это свойство, создайте или обновите индексатор со следующей конфигурацией:

    {
      ... other indexer definition properties
     "parameters" : {
            "configuration" : { "convertHighWaterMarkToRowVersion" : true } }
    }

queryTimeout

Если возникают ошибки времени ожидания, задайте queryTimeout для параметра конфигурации индексатора значение, превышающее 5-минутное время ожидания по умолчанию. Например, чтобы задать время ожидания, равное 10 минутам, создайте или обновите индексатор, используя приведенную ниже конфигурацию.

    {
      ... other indexer definition properties
     "parameters" : {
            "configuration" : { "queryTimeout" : "00:10:00" } }
    }

disableOrderByHighWaterMarkColumn

Можно также отключить предложение ORDER BY [High Water Mark Column]. Однако это не рекомендуется, так как если выполнение индексатора прерывается ошибкой, индексатор должен повторно обработать все строки, если он выполняется позже, даже если индексатор уже обработал почти все строки во время его прерывания. Чтобы отключить предложение ORDER BY, используйте параметр disableOrderByHighWaterMarkColumn в определении индексатора.

    {
     ... other indexer definition properties
     "parameters" : {
            "configuration" : { "disableOrderByHighWaterMarkColumn" : true } }
    }

Политика обнаружения обратимого удаления столбца

Строки, удаляемые из исходной таблицы, вероятно, также следует удалить из индекса поиска. Если вы используете интегрированную политику отслеживания изменений SQL, это происходит автоматически. Однако политика отслеживания изменений максимального уровня не затрагивает удаленные строки. Что делать?

Если строки физически удаляются из таблицы, служба "Поиск ИИ Azure" не может определить наличие записей, которые больше не существуют. Тем не менее можно использовать метод обратимого удаления, чтобы логически удалять строки, не удаляя их из таблицы. Добавьте специальный столбец в таблицу или представление и помечайте удаленные строки с помощью этого столбца.

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

    {
        …,
        "dataDeletionDetectionPolicy" : {
           "@odata.type" : "#Microsoft.Azure.Search.SoftDeleteColumnDeletionDetectionPolicy",
           "softDeleteColumnName" : "[a column name]",
           "softDeleteMarkerValue" : "[the value that indicates that a row is deleted]"
        }
    }

SoftDeleteMarkerValue должен быть строкой в представлении JSON источника данных. Используйте строковое представление фактического значения. Например, если имеется столбец целочисленных значений, в котором удаленные строки помечаются значением 1, то следует использовать "1". Если имеется битовый столбец, в котором удаленные строки помечаются логическим значением true, то используйте строковый литерал "True" или "true", при этом регистр значения не имеет.

Если вы настраиваете политику обратимого удаления из портал Azure, не добавляйте кавычки вокруг значения маркера обратимого удаления. Содержимое поля уже понимается как строка и автоматически преобразуется в строку JSON. В предыдущих примерах просто введите 1True или true в поле портал Azure.

Вопросы и ответы

Вопрос. Можно ли индексировать столбцы Always Encrypted?

Нет, столбцы Always Encrypted в настоящее время не поддерживаются индексаторами поиска ВИ Azure.

Вопрос. Можно ли использовать индексатор SQL Azure с базами данных SQL на виртуальных машинах IaaS в Azure?

Да. Тем не менее необходимо разрешить службе поиска подключаться к базе данных. Дополнительные сведения см. в статье "Настройка подключения от индексатора поиска ИИ Azure к SQL Server на виртуальной машине Azure".

Вопрос. Можно ли использовать индексатор SQL Azure с локальными базами данных SQL?

Не напрямую. Мы не рекомендуем или не поддерживаем прямое подключение, так как для этого потребуется открыть базы данных в Интернет-трафик. Клиенты преуспели в этом сценарии, используя технологии моста, такие как фабрика данных Azure. Дополнительные сведения см. в статье "Отправка данных в индекс поиска ИИ Azure" с помощью Фабрика данных Azure.

Вопрос. Можно ли использовать вторичную реплику в отказоустойчивом кластере в качестве источника данных?

Это зависит от ряда обстоятельств. Для полной индексации таблицы или представления можно использовать вторичные реплики.

Для добавочного индексирования поиск ИИ Azure поддерживает две политики обнаружения изменений: интегрированное отслеживание изменений SQL и высокий уровень воды.

В репликах только для чтения База данных SQL не поддерживает встроенное отслеживание изменений. Таким образом необходимо использовать политику максимального уровня.

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

Если вы попытаетесь использовать rowversion в реплике только для чтения, вы получите следующую ошибку:

"Использование столбца rowversion для отслеживания изменений не поддерживается во вторичных (только для чтения) реплик доступности. Обновите источник данных и укажите подключение к первичной реплике доступности. Текущее свойство "Updateability" базы данных — "READ_ONLY".

Вопрос. Можно ли использовать другой столбец, не rowversion, для отслеживания изменений максимального уровня?

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

• Вы можете убедиться, что при запуске индексатора отсутствуют незавершенные транзакции в таблице, которая индексируется (например, все обновления таблиц выполняются как пакет по расписанию, а расписание индексатора поиска Azure ИИ не перекрывается с расписанием обновления таблицы).

• Вы периодически выполняете полное повторное индексирование, чтобы обнаружить все пропущенные строки.