Оптимизация производительности с помощью технологий обработки в оперативной памяти в базе данных SQLOptimize performance by using In-Memory technologies in SQL Database

Технологии обработки в оперативной памяти в Базе данных SQL Azure позволяют повысить производительность приложений и уменьшить стоимость использования базы данных.In-Memory technologies in Azure SQL Database enable you to improve performance of your application, and potentially reduce cost of your database.

Когда следует использовать технологии в памятиWhen to use In-Memory technologies

С помощью технологий обработки в оперативной памяти в Базе данных SQL Azure вы можете добиться улучшения производительности с помощью различных рабочих нагрузок.By using In-Memory technologies in Azure SQL Database, you can achieve performance improvements with various workloads:

  • Транзакционные (оперативная обработка транзакций, OLTP), где большая часть запросов касается чтения или обновления малых набор данных (например, операции CRUD).Transactional (online transactional processing (OLTP)) where most of the requests read or update smaller set of data (for example, CRUD operations).
  • Аналитические (интерактивная аналитическая обработка, OLAP), где большинство запросов использует сложные вычисления для создания отчетов с определенным количеством запросов, которые загружают и добавляют данные в существующих таблицах (так называемая массовая загрузка) или удаляют данные из таблиц.Analytic (online analytical processing (OLAP)) where most of the queries have complex calculations for the reporting purposes, with a certain number of queries that load and append data to the existing tables (so called bulk-load), or delete the data from the tables.
  • Смешанные (гибридная транзакционная и аналитическая обработка, HTAP), где запросы OLTP и OLAP выполняются в одном наборе данных.Mixed (hybrid transaction/analytical processing (HTAP)) where both OLTP and OLAP queries are executed on the same set of data.

Технологии обработки в памяти могут повысить производительность этих рабочих нагрузок благодаря хранению обрабатываемых данных в памяти, с помощью собственной компиляции запросов или расширенной обработки, например пакетной обработки и инструкций SIMD, доступных на базовом оборудовании.In-memory technologies can improve performance of these workloads by keeping the data that should be processed into the memory, using native compilation of the queries, or advanced processing such as batch processing and SIMD instructions that are available on the underlying hardware.

ОбзорOverview

База данных SQL Azure поддерживает следующие технологии In-Memory.Azure SQL Database has the following In-Memory technologies:

  • Выполняющаяся в памяти OLTP повышает скорость выполнения транзакций и сокращает задержки при их обработке.In-Memory OLTP increases number of transactions per second and reduces latency for transaction processing. Выполняющуюся в памяти OLTP полезно использовать в следующих сценариях: обработка транзакций с высокой пропускной способностью, например для торговли и игр, прием данных о событиях или устройствах Интернета вещей, кэширование, загрузка данных, использование временных таблиц и табличных переменных.Scenarios that benefit from In-Memory OLTP are: high-throughput transaction processing such as trading and gaming, data ingestion from events or IoT devices, caching, data load, and temporary table and table variable scenarios.
  • Кластеризованные индексы columnstore снижают требования к вместимости хранилища (иногда до 10 раз) и повышают производительность запросов для отчетов и аналитики.Clustered columnstore indexes reduce your storage footprint (up to 10 times) and improve performance for reporting and analytics queries. Используйте их с таблицами фактов в киосках данных, чтобы разместить в базе больше данных и повысить ее производительность.You can use it with fact tables in your data marts to fit more data in your database and improve performance. Вы также можете использовать их с данными журналов в рабочей базе данных, чтобы архивировать и запрашивать в 10 раз больше данных.Also, you can use it with historical data in your operational database to archive and be able to query up to 10 times more data.
  • Некластеризованные индексы columnstore для гибридных сценариев транзакционной и аналитической обработки помогут вам получить информацию о параметрах бизнеса в режиме реального времени, напрямую запрашивая рабочую базу данных без необходимости выполнения ресурсоемких операций извлечения, преобразования и загрузки, а также без задержек при заполнении хранилища данных.Nonclustered columnstore indexes for HTAP help you to gain real-time insights into your business through querying the operational database directly, without the need to run an expensive extract, transform, and load (ETL) process and wait for the data warehouse to be populated. Некластеризованные индексы columnstore позволяют быстро выполнять аналитические запросы к базе данных OLTP, практически не оказывая влияния на рабочую нагрузку.Nonclustered columnstore indexes allow fast execution of analytics queries on the OLTP database, while reducing the impact on the operational workload.
  • Использование оптимизированных для памяти индексов columnstore для HTAP позволит ускорить для одного набора данных одновременно и обработку транзакций, и выполнение аналитических запросов.Memory-optimized clustered columnstore indexes for HTAP enables you to perform fast transaction processing, and to concurrently run analytics queries very quickly on the same data.

Индексы columnstore и выполняющаяся в памяти OLTP включены в выпуски SQL Server, начиная с версий 2012 и 2014 соответственно.Both columnstore indexes and In-Memory OLTP have been part of the SQL Server product since 2012 and 2014, respectively. Технология обработки в оперативной памяти схожим образом реализована в Базе данных SQL Azure и SQL Server.Azure SQL Database and SQL Server share the same implementation of In-Memory technologies. При этом новые возможности сначала предоставляются для Базы данных SQL Azure, а затем выпускаются для SQL Server.Going forward, new capabilities for these technologies are released in Azure SQL Database first, before they are released in SQL Server.

Преимущества технологии в памятиBenefits of In-memory technology

Благодаря более эффективной обработке запросов и транзакций технологии обработки в оперативной памяти также помогут снизить затраты.Because of the more efficient query and transaction processing, In-Memory technologies also help you to reduce cost. Вам не нужно переходить на более высокую ценовую категорию баз данных, чтобы добиться повышения производительности.You typically don't need to upgrade the pricing tier of the database to achieve performance gains. В некоторых случаях технологии обработки в оперативной памяти предусматривают даже переход на более низкую ценовую категорию без снижения производительности.In some cases, you might even be able reduce the pricing tier, while still seeing performance improvements with In-Memory technologies.

Вот несколько примеров того, как выполняющаяся в памяти OLTP помогла значительно улучшить показатели производительности:Here are two examples of how In-Memory OLTP helped to significantly improve performance:

Примечание

Технологии в памяти доступны в базах данных Azure SQL классов "Премиум" и "Критически важный для бизнеса", а также в эластичных пулах класса "Премиум".In-Memory technologies are available in Premium and Business Critical tier Azure SQL databases and Premium elastic pools.

В следующем видео демонстрируется потенциал роста производительности при использовании технологий In-Memory для Базы данных SQL Azure.The following video explains potential performance gains with In-Memory technologies in Azure SQL Database. Помните, что фактическое увеличение производительности всегда зависит от многих факторов, включая характер рабочей нагрузки и свойства данных, схему доступа к базе данных и т. д.Remember that the performance gain that you see always depends on many factors, including the nature of the workload and data, access pattern of the database, and so on.

В этой статье описываются особенности выполняющейся в памяти OLTP и индексов columnstore, которые применимы только к базе данных SQL Azure. Описание дополняется примерами.This article describes aspects of In-Memory OLTP and columnstore indexes that are specific to Azure SQL Database and also includes samples:

  • Сначала мы рассмотрим, как эти технологии влияют на использование хранилища и ограничения размера данных.You'll see the impact of these technologies on storage and data size limits.
  • Вы узнаете, как правильно изменять ценовую категорию для баз данных, в которых используются эти технологии.You'll see how to manage the movement of databases that use these technologies between the different pricing tiers.
  • Вы ознакомитесь с двумя примерами по использованию выполняющейся в памяти OLTP и индексов columnstore в Базе данных SQL Azure.You'll see two samples that illustrate the use of In-Memory OLTP, as well as columnstore indexes in Azure SQL Database.

Дополнительные сведения можно найти в разделеFor more information, see:

Выполняющаяся в памяти OLTPIn-memory OLTP

Технология обработки в памяти OLTP предоставляет исключительно быстрые операции доступа к данным с сохранением всех данных в памяти.In-memory OLTP technology provides extremely fast data access operations by keeping all data in memory. Она также использует специализированные индексы, собственную компиляцию запросов и доступ к данным без защелок доступа для повышения производительности рабочей нагрузки OLTP.It also uses specialized indexes, native compilation of queries, and latch-free data-access to improve performance of the OLTP workload. Существует два способа организации данных OLTP в памяти:There are two ways to organize your In-Memory OLTP data:

  • Формат оптимизированных для памяти rowstore, где каждая строка представляет собой отдельный объект в памяти.Memory-optimized rowstore format where every row is a separate memory object. Это классический формат OLTP в памяти, оптимизированный для высокой производительности рабочих нагрузок OLTP.This is a classic In-Memory OLTP format optimized for high-performance OLTP workloads. Существует два типа таблиц, оптимизированных для памяти, которые могут использоваться в формате rowstore, оптимизированных для памяти.There are two types of memory-optimized tables that can be used in the memory-optimized rowstore format:
    • Устойчивые таблицы (SCHEMA_AND_DATA), где строки, помещенные в память, сохраняются после перезапуска сервера.Durable tables (SCHEMA_AND_DATA) where the rows placed in memory are preserved after server restart. Этот тип таблицы ведет себя как стандартная таблица rowstore, но дает дополнительные преимущества оптимизации в памяти.This type of tables behaves like a traditional rowstore table with the additional benefits of in-memory optimizations.
    • Неустойчивые таблицы (SCHEMA_ONLY), где строки не сохраняются после перезапуска.Non-durable tables (SCHEMA_ONLY) where the rows are not-preserved after restart. Этот тип таблицы предназначен для временных данных (например, замены временных таблиц) или таблиц, когда необходимо быстро загрузить данные, прежде чем переместить их в сохраненную таблицу (так называемые промежуточные таблицы).This type of table is designed for temporary data (for example, replacement of temp tables), or tables where you need to quickly load data before you move it to some persisted table (so called staging tables).
  • Формат columnstore с оптимизацией памяти, где данные организованы в виде столбцов.Memory-optimized columnstore format where data is organized in a columnar format. Эта структура предназначена для сценариев HTAP, где необходимо выполнять аналитические запросы над той же структурой данных, где выполняется рабочая нагрузка OLTP.This structure is designed for HTAP scenarios where you need to run analytic queries on the same data structure where your OLTP workload is running.

Примечание

Технология OLTP в памяти предназначена для структур данных, которые могут полностью находиться в памяти.In-Memory OLTP technology is designed for the data structures that can fully reside in memory. Так как данные в памяти невозможно выгрузить на диск, убедитесь, что вы используете базы данных с достаточным объемом памяти.Since the In-memory data cannot be offloaded to disk, make sure that you are using database that has enough memory. См. раздел Ограничения на объем данных и емкость хранилища для OLTP в памяти.See Data size and storage cap for In-Memory OLTP for more details.

Краткое руководство по выполняющейся в памяти OLTP: быстрый запуск 1. технологии OLTP в памяти для повышения производительности T-SQL (другая статья поможет вам приступить к работе)A quick primer on In-Memory OLTP: Quickstart 1: In-Memory OLTP Technologies for Faster T-SQL Performance (another article to help you get started)

Подробные видеоролики об этих технологиях:In-depth videos about the technologies:

Вы можете программным методом узнать, поддерживает ли база данных In-Memory OLTP.There is a programmatic way to understand whether a given database supports In-Memory OLTP. Для этого выполните следующий запрос Transact-SQL:You can execute the following Transact-SQL query:

SELECT DatabasePropertyEx(DB_NAME(), 'IsXTPSupported');

Если запрос возвращает 1, база данных поддерживает In-Memory OLTP.If the query returns 1, In-Memory OLTP is supported in this database. Приведенные ниже запросы определяют все объекты, которые необходимо удалить перед переходом на ценовую категорию "Стандартный" или "Базовый".The following queries identify all objects that need to be removed before a database can be downgraded to Standard/Basic:

SELECT * FROM sys.tables WHERE is_memory_optimized=1
SELECT * FROM sys.table_types WHERE is_memory_optimized=1
SELECT * FROM sys.sql_modules WHERE uses_native_compilation=1

Ограничения на объем данных и емкость хранилища для In-Memory OLTPData size and storage cap for In-Memory OLTP

In-Memory OLTP включает оптимизированные для памяти таблицы, которые используются для хранения пользовательских данных.In-Memory OLTP includes memory-optimized tables, which are used for storing user data. Эти таблицы должны умещаться в памяти.These tables are required to fit in memory. Так как вы управляете памятью непосредственно в службе базы данных SQL, мы применяем концепцию квоты на пользовательские данные,Because you manage memory directly in the SQL Database service, we have the concept of a quota for user data. или хранилище выполняющейся в памяти OLTP.This idea is referred to as In-Memory OLTP storage.

Каждая поддерживаемая ценовая категория отдельных баз данных и эластичных пулов включает некоторый объем хранилища выполняющейся в памяти OLTP.Each supported single database pricing tier and each elastic pool pricing tier includes a certain amount of In-Memory OLTP storage. Ознакомьтесь с разделами Ограничения ресурсов на основе DTU — отдельная база данных, Ограничения ресурсов на основе DTU — эластичные пулы,Ограничения ресурсов на основе виртуальных ядер — отдельные базы данных и Ограничения ресурсов на основе виртуальных ядер — эластичные пулы.See DTU-based resource limits - single database, DTU-based resource limits - elastic pools,vCore-based resource limits - single databases and vCore-based resource limits - elastic pools.

При расчете емкости хранилища для выполняющейся в памяти OLTP используются следующие параметры.The following items count toward your In-Memory OLTP storage cap:

  • Активные строки пользовательских данных в оптимизированных для памяти таблицах и переменных таблиц.Active user data rows in memory-optimized tables and table variables. Обратите внимание, что старые версии строк не учитываются в объеме.Note that old row versions don't count toward the cap.
  • Индексы оптимизированных для памяти таблиц.Indexes on memory-optimized tables.
  • Операционные затраты на операции ALTER TABLE.Operational overhead of ALTER TABLE operations.

Когда ограничение будет достигнуто, вы получите ошибку с сообщением о том, что квота израсходована, и не сможете выполнять операции вставки и обновления данных.If you hit the cap, you receive an out-of-quota error, and you are no longer able to insert or update data. Чтобы устранить такую проблему, удалите часть данных или перейдите на более высокую ценовую категорию базы данных или пула.To mitigate this error, delete data or increase the pricing tier of the database or pool.

Дополнительные сведения о мониторинге использования хранилища выполняющейся в памяти OLTP и о настройке оповещений при приближении к установленным ограничениям см. в статье Мониторинг хранилища OLTP в памяти.For details about monitoring In-Memory OLTP storage utilization and configuring alerts when you almost hit the cap, see Monitor In-Memory storage.

О пулах эластичных баз данныхAbout elastic pools

При использовании пулов эластичных баз данных хранилище выполняющейся в памяти OLTP используется совместно всеми базами данных в пуле.With elastic pools, the In-Memory OLTP storage is shared across all databases in the pool. Следовательно, используемый объем одной базы данных может повлиять на другие базы данных.Therefore, the usage in one database can potentially affect other databases. Есть два пути устранения таких проблем.Two mitigations for this are:

  • Установите для баз данных значение Max-eDTU или MaxvCore ниже, чем значение eDTU или число виртуальных ядер для пула в целом.Configure a Max-eDTU or MaxvCore for databases that is lower than the eDTU or vCore count for the pool as a whole. Это новое ограничение eDTU на емкость хранилища выполняющейся в памяти OLTP будет действовать в отношении любой базы данных в пуле.This maximum caps the In-Memory OLTP storage utilization, in any database in the pool, to the size that corresponds to the eDTU count.
  • Установите для баз данных значение Min-eDTU или MinvCore больше нуля.Configure a Min-eDTU or MinvCore that is greater than 0. Это минимальное значение гарантирует, что каждая база данных в пуле получит определенный объем хранилища для выполняющейся в памяти OLTP в соответствии с указанным значением Min-eDTU или vCore.This minimum guarantees that each database in the pool has the amount of available In-Memory OLTP storage that corresponds to the configured Min-eDTU or vCore.

Изменение уровней служб баз данных, которые используют технологии OLTP в памятиChanging service tiers of databases that use In-Memory OLTP technologies

Вы всегда можете повысить базы данных или экземпляр до более высокого уровня, например от уровня общего назначения до критически важного для бизнеса (или с класса "Стандартный" до класса "Премиум").You can always upgrade your database or instance to a higher tier, such as from General Purpose to Business Critical (or Standard to Premium). Все доступные функции и ресурсы будут только расширяться.The available functionality and resources only increase.

Учтите, что понижение уровня может отрицательно повлиять на базу данных.But downgrading the tier can negatively impact your database. Такое влияние при переходе от критически важного для бизнеса уровня до уровня общего назначения (или с класса "Премиум" на "Стандартный" или "Базовый") будет особенно заметно, если база данных содержит объекты выполняющейся в памяти OLTP.The impact is especially apparent when you downgrade from Business Critical to General Purpose (or Premium to Standard or Basic) when your database contains In-Memory OLTP objects. После понижения ценовой категории или уровня оптимизированные для памяти таблицы станут недоступными (даже если останутся видимыми).Memory-optimized tables are unavailable after the downgrade (even if they remain visible). Эти замечания относятся и к переходу на более низкую ценовую категорию для пула эластичных баз данных, а также к перемещению баз данных, использующих технологии обработки в оперативной памяти, в пул эластичных баз данных уровня "Стандартный" или "Базовый".The same considerations apply when you're lowering the pricing tier of an elastic pool, or moving a database with In-Memory technologies, into a Standard or Basic elastic pool.

Важно!

OLTP в памяти не поддерживается базами данных класса "Стандартный" или "Базовый".In-Memory OLTP isn't supported in the General Purpose, Standard or Basic tier. Поэтому невозможно изменить уровень базы данных, содержащей любые объекты выполняющейся в памяти OLTP, на "Стандартный" или "Базовый".Therefore, it isn't possible to move a database that has any In-Memory OLTP objects to the Standard or Basic tier.

Прежде чем понижать базу данных до уровней "Стандартный" или "Базовый", удалите все оптимизированные для памяти таблицы и типы таблиц, а также все модули T-SQL, скомпилированные в собственном коде.Before you downgrade the database to Standard/Basic, remove all memory-optimized tables and table types, as well as all natively compiled T-SQL modules.

Масштабирование ресурсов на критически важный для бизнеса уровне. данные в таблицах, оптимизированных для памяти, должны помещаться в хранилище выполняющейся в памяти OLTP, связанное с уровнем базы данных или управляемый экземпляр, или в пуле эластичных БД.Scaling-down resources in Business Critical tier: Data in memory-optimized tables must fit within the In-Memory OLTP storage that is associated with the tier of the database or Managed Instance, or it is available in the elastic pool. Если вы попытаетесь понизить уровень базы данных или переместить базу данных в пул, в котором нет достаточного объема хранилища выполняющейся в памяти OLTP, операция завершится ошибкой.If you try to scale-down the tier or move the database into a pool that doesn't have enough available In-Memory OLTP storage, the operation fails.

Технология columnstore в памятиIn-memory columnstore

Технология columnstore в памяти позволяет хранить и запрашивать большой объем данных в таблицах.In-memory columnstore technology is enabling you to store and query a large amount of data in the tables. Она использует формат хранения по столбцам данных и пакетную обработку запросов, позволяя до 10 раз увеличить производительность запросов в рабочих нагрузках OLAP относительно традиционного хранилища, основанного на строках.Columnstore technology uses column-based data storage format and batch query processing to achieve gain up to 10 times the query performance in OLAP workloads over traditional row-oriented storage. Также, можно добиться 10-кратного сжатия данных относительно несжатых данных.You can also achieve gains up to 10 times the data compression over the uncompressed data size. Существует два типа моделей columnstore, которые можно использовать для организации данных.There are two types of columnstore models that you can use to organize your data:

  • Кластеризованный индекс columnstore, где все данные в таблице организованы в виде столбцов.Clustered columnstore where all data in the table is organized in the columnar format. В этой модели все строки в таблице помещаются в табличном формате, который существенно сжимает данные и допускает выполнение аналитических запросов и отчетов в таблице.In this model, all rows in the table are placed in columnar format that highly compresses the data and enables you to execute fast analytical queries and reports on the table. В зависимости от характера данных снижение объема может составлять от 10x до 100x.Depending on the nature of your data, the size of your data might be decreased 10x-100x. Кластеризованный индекс columnstore также позволяет быстро принимать большие объемы данных (массовая загрузка), поскольку большие пакеты данных (больше 100 тысяч строк) сжимаются перед сохранением на диске.Clustered columnstore model also enables fast ingestion of large amount of data (bulk-load) since large batches of data greater than 100K rows are compressed before they are stored on disk. Эта модель хорошо подходит для сценариев данных классического хранилища.This model is a good choice for the classic data warehouse scenarios.
  • Хранилище columnstore без кластеризации, где данные хранятся в стандартной таблице rowstore, а также есть индекс в формате columnstore, который используется для аналитических запросов.Non-clustered columnstore where the data is stored in traditional rowstore table and there is an index in the columnstore format that is used for the analytical queries. Эта модель допускает гибридную транзакционную аналитическую обработку (HTAP): возможность запускать аналитику в реальном времени с высокой производительностью на транзакционной рабочей нагрузке.This model enables Hybrid Transactional-Analytic Processing (HTAP): the ability to run performant real-time analytics on a transactional workload. Запросы OLTP выполняются в таблице rowstore, которая оптимизирована для доступа к небольшому числу строк, тогда как запросы OLAP выполняются в индексе columnstore, который лучше подходит для сканирования и анализа.OLTP queries are executed on rowstore table that is optimized for accessing a small set of rows, while OLAP queries are executed on columnstore index that is better choice for scans and analytics. Оптимизатор запросов базы данных SQL Azure динамически выбирает формат rowstore или columnstore на основе запроса.Azure SQL Database Query optimizer dynamically chooses rowstore or columnstore format based on the query. Индексы columnstore, отличные от кластерных, не позволяют уменьшить объем данных, так как исходный набор данных хранится в исходной таблице rowstore без изменений.Non-clustered columnstore indexes don't decrease the size of the data since original data-set is kept in the original rowstore table without any change. Тем не менее размер дополнительного индекса columnstore будет на порядок меньше, чем эквивалентный индекс сбалансированного дерева.However, the size of additional columnstore index should be in order of magnitude smaller than the equivalent B-tree index.

Примечание

Технология columnstore в памяти сохраняет в памяти только данные, необходимые для обработки, храня данные, которые не помещаются в памяти, на диске.In-memory columnstore technology keeps only the data that is needed for processing in the memory, while the data that cannot fit into the memory is stored on-disk. Таким образом, объем данных в структурах columnstore в памяти может превышать объем доступной памяти.Therefore, the amount of data in In-memory columnstore structures can exceed the amount of available memory.

Подробные видеоролики об этих технологияхIn-depth video about the technology:

Размер данных и хранилище для индексов сolumnstoreData size and storage for columnstore indexes

Индексы сolumnstore не обязательно должны помещаться в памяти.Columnstore indexes aren't required to fit in memory. Поэтому для размера индексов применяется только одно ограничение — на максимальный общий размер базы данных. См. подробнее о моделях приобретения на основе единиц DTU и виртуальных ядер.Therefore, the only cap on the size of the indexes is the maximum overall database size, which is documented in the DTU-based purchasing model and vCore-based purchasing model articles.

При использовании кластеризованных индексов сolumnstore для хранения базовых таблиц применяется сжатие по столбцам.When you use clustered columnstore indexes, columnar compression is used for the base table storage. Сжатие может значительно снизить объем хранимых пользовательских данных, позволяя разместить в базе данных больше информации.This compression can significantly reduce the storage footprint of your user data, which means that you can fit more data in the database. Этот эффект можно усилить, используя архивное сжатие по столбцам.And the compression can be further increased with columnar archival compression. Степень сжатия, которой можно добиться, зависит от характера данных. Вполне можно достигнуть 10-кратного сжатия.The amount of compression that you can achieve depends on the nature of the data, but 10 times the compression is not uncommon.

Например, если для базы данных установлен максимальный размер 1 терабайт (ТБ), а с помощью технологии columnstore удастся добиться 10-кратного сжатия, вы сможете хранить в этой базе данных 10 ТБ пользовательских данных.For example, if you have a database with a maximum size of 1 terabyte (TB) and you achieve 10 times the compression by using columnstore indexes, you can fit a total of 10 TB of user data in the database.

При использовании некластеризованных индексов columnstore базовая таблица по-прежнему хранится в традиционном формате rowstore,When you use nonclustered columnstore indexes, the base table is still stored in the traditional rowstore format. поэтому экономия места в хранилище будет не столь значительной, как с применением кластеризованных индексов сolumnstore.Therefore, the storage savings aren't as big as with clustered columnstore indexes. Но если вы при этом замените некоторое число традиционных некластеризованных индексов одним индексом columnstore, даже так вы заметите некоторое сокращение общего объема хранилища для этой таблицы.However, if you're replacing a number of traditional nonclustered indexes with a single columnstore index, you can still see an overall savings in the storage footprint for the table.

Изменение уровней служб базы данных, содержащей индексы columnstoreChanging service tiers of databases containing Columnstore indexes

Понижение уровня отдельной базы данных до базового или стандартного может оказаться невозможным, если ваш целевой уровень ниже S3.Downgrading single database to Basic or Standard might not be possible if your target tier is below S3. Индексы columnstore поддерживаются только в ценовой категории "Премиум" и "Критически важный для бизнеса" или "Стандартный" (S3 и выше), но не в ценовой категории "Базовый".Columnstore indexes are supported only on the Business Critical/Premium pricing tier and on the Standard tier, S3 and above, and not on the Basic tier. При переходе базы данных на неподдерживаемую ценовую категорию или уровень, индексы columnstore становятся недоступными.When you downgrade your database to an unsupported tier or level, your columnstore index becomes unavailable. Система сохранит ваш индекс columnstore, но не будет его использовать.The system maintains your columnstore index, but it never leverages the index. Если вы позднее перейдете на поддерживаемую ценовую категорию или уровень, индекс columnstore будет немедленно готов к использованию.If you later upgrade back to a supported tier or level, your columnstore index is immediately ready to be leveraged again.

Если у вас есть кластеризованный индекс columnstore, после понижения вся таблица станет недоступной.If you have a clustered columnstore index, the whole table becomes unavailable after the downgrade. Поэтому корпорация Майкрософт рекомендует удалить все кластеризованные индексы columnstore перед переходом базы данных на неподдерживаемую ценовую категорию или уровень.Therefore we recommend that you drop all clustered columnstore indexes before you downgrade your database to an unsupported tier or level.

Примечание

Управляемый экземпляр поддерживает индексы columstore на всех уровнях.Managed Instance supports ColumnStore indexes in all tiers.

Дальнейшие действияNext steps

Дополнительные ресурсыAdditional resources

Подробные сведенияDeeper information

Проектирование приложенийApplication design

СредстваTools