Azure Synapse Analytics의 Synapse SQL 풀에 대한 모범 사례(이전 명칭: SQL DW)Best practices for Synapse SQL pool in Azure Synapse Analytics (formerly SQL DW)

이 문서는 SQL 풀 배포에서 최적의 성능을 달성할 수 있는 모범 사례 모음입니다.This article is a collection of best practices to help you to achieve optimal performance from your SQL pool deployment. 이 문서의 목적은 몇 가지 기본 지침을 제공하고 중요한 주요 영역을 중점적으로 설명하는 것입니다.The purpose of this article is to give you some basic guidance and highlight important areas of focus.

일시 중지 및 규모 조정으로 비용 절감Reduce cost with pause and scale

일시 중지 및 크기 조정을 통해 비용을 절감하는 방법에 대한 자세한 내용은 컴퓨팅 관리를 참조하세요.For more information about reducing costs through pausing and scaling, see the Manage compute.

통계 유지 관리Maintain statistics

열에 대한 통계를 자동으로 검색하고 만들도록 SQL 풀을 구성할 수 있습니다.SQL pool can be configured to automatically detect and create statistics on columns. 최적화 프로그램으로 만든 쿼리 계획은 사용 가능한 통계만큼 훌륭합니다.The query plans created by the optimizer are only as good as the available statistics.

데이터베이스에 대해 AUTO_CREATE_STATISTICS를 사용하도록 설정하고 쿼리에 사용된 열에 대한 통계를 항상 최신 상태를 유지하도록 매일 또는 각 로드 후에 통계를 업데이트하는 것이 좋습니다.We recommend that you enable AUTO_CREATE_STATISTICS for your databases and keep the statistics updated daily or after each load to ensure that statistics on columns used in your queries are always up to date.

모든 통계를 업데이트하는 데 시간이 너무 오래 소요되는 경우 통계를 자주 업데이트해야 하는 열을 더 선별적으로 시도해볼 수 있습니다.If you find it is taking too long to update all of your statistics, you may want to try to be more selective about which columns need frequent statistics updates. 예를 들어 새 값이 매일 추가될 수 있는 날짜 열을 업데이트하려고 합니다.For example, you might want to update date columns, where new values may be added, daily.

조인에 포함된 열, WHERE 절에 사용된 열과 GROUP BY에 있는 열에서 통계를 업데이트하면 가장 큰 이점을 얻을 수 있습니다.You will gain the most benefit by having updated statistics on columns involved in joins, columns used in the WHERE clause and columns found in GROUP BY.

테이블 통계 관리, CREATE STATISTICSUPDATE STATISTICS도 참조하세요.See also Manage table statistics, CREATE STATISTICS, and UPDATE STATISTICS.

DMV를 사용하여 쿼리 모니터링 및 최적화Use DMVs to monitor and optimize your queries

SQL 풀에는 쿼리 실행을 모니터링하는 데 사용할 수 있는 여러 DMV가 있습니다.SQL pool has several DMVs that can be used to monitor query execution. DMV를 사용하여 워크로드 관리 문서에서는 쿼리 실행의 세부 정보를 확인하는 방법에 대한 단계별 지침을 자세히 설명합니다.The Monitor your workload using DMVs article details step-by-step instructions on how to look at the details of an executing query.

이러한 DMV에서 쿼리를 신속하게 찾으려면 쿼리에 LABEL 옵션을 사용하는 것이 도움이 될 수 있습니다.To quickly find queries in these DMVs, using the LABEL option with your queries can help.

또한 DMV를 사용하여 워크로드 모니터링, LABEL, OPTION, sys.dm_exec_sessions, sys.dm_pdw_exec_requests, sys.dm_pdw_request_steps, sys.dm_pdw_sql_requests, sys.dm_pdw_dms_workers, DBCC PDW_SHOWEXECUTIONPLANsys.dm_pdw_waits도 참조하세요.See also Monitor your workload using DMVs, LABEL, OPTION, sys.dm_exec_sessions, sys.dm_pdw_exec_requests, sys.dm_pdw_request_steps, sys.dm_pdw_sql_requests, sys.dm_pdw_dms_workers, DBCC PDW_SHOWEXECUTIONPLAN, and sys.dm_pdw_waits.

새로운 제품 향상으로 쿼리 성능 조정Tune query performance with new product enhancements

INSERT 문을 일괄 처리로 그룹화Group INSERT statements into batches

INSERT 문을 이용한 작은 테이블에 대한 일회성 로드 또는 조회의 정기적인 다시 로드는 INSERT INTO MyLookup VALUES (1, 'Type 1')와 같은 문으로 사용자 요구에 대해 제대로 수행될 수 있습니다.A one-time load to a small table with an INSERT statement or even a periodic reload of a look-up may perform well for your needs with a statement like INSERT INTO MyLookup VALUES (1, 'Type 1').

그러나 수천 또는 수백만 행을 하루 종일 로드해야 하는 경우 단일 항목 INSERTS만으로는 불가능할 수 있습니다.However, if you need to load thousands or millions of rows throughout the day, you might find that singleton INSERTS just can't keep up. 대신 파일에 기록하는 프로세스를 개발하고 다른 프로세스를 주기적으로 함께 제공하여 이 파일을 로드합니다.Instead, develop your processes so that they write to a file and another process periodically comes along and loads this file.

또한 INSERT도 참조하세요.See also INSERT.

PolyBase를 사용하여 데이터를 신속하고 로드하고 내보내기Use PolyBase to load and export data quickly

SQL 풀은 Azure Data Factory, PolyBase, BCP 등의 여러 도구를 통해 데이터 로드 및 내보내기를 지원합니다.SQL pool supports loading and exporting data through several tools including Azure Data Factory, PolyBase, and BCP. 성능이 중요하지 않은 소량의 데이터에는 어떤 도구를 사용해도 사용자 요구 사항을 충족할 수 있습니다.For small amounts of data where performance isn't critical, any tool may be sufficient for your needs. 그러나 대량의 데이터를 로드 또는 내보내거나 빠른 성능이 필요한 경우 PolyBase가 가장 좋습니다.However, when you are loading or exporting large volumes of data or fast performance is needed, PolyBase is the best choice.

PolyBase는 시스템의 분산 된 특성을 활용 하도록 설계 되었으며 다른 도구 보다 더 빠르게 크고 많을 데이터를 로드 하 고 내보냅니다.PolyBase is designed to leverage distributed nature of the system and will load and export data magnitudes faster than any other tool. PolyBase 로드는 CTAS 또는 INSERT INTO를 사용하여 실행할 수 있습니다.PolyBase loads can be run using CTAS or INSERT INTO.

CTAS를 사용하면 트랜잭션 로깅을 최소화하고 데이터를 가장 빠르게 로드할 수 있습니다.Using CTAS will minimize transaction logging and the fastest way to load your data.

또한 Azure Data Factory는 PolyBase 로드를 지원하며 CTAS와 비슷한 성능을 얻을 수 있습니다.Azure Data Factory also supports PolyBase loads and can achieve similar performance as CTAS. PolyBase는 Gzip 파일을 포함한 다양한 파일 형식을 지원합니다.PolyBase supports a variety of file formats including Gzip files.

참고

gzip 텍스트 파일을 사용할 때 처리량을 최대화하려면 파일을 60개 이상의 파일로 나누어 로드의 병렬 처리를 최대화합니다.To maximize throughput when using gzip text files, break up files into 60 or more files to maximize parallelism of your load. 총 처리량을 더 빠르게 하기 위해 데이터를 동시에 로드하는 것이 좋습니다.For faster total throughput, consider loading data concurrently.

또한 데이터 로드, PolyBase 사용 지침, SQL 풀 로딩 패턴 및 전략, Azure Data Factory를 사용하여 데이터 로드, Azure Data Factory를 사용하여 데이터 이동, CREATE EXTERNAL FILE FORMATCTAS(Create Table As Select)도 참조하세요.See also Load data, Guide for using PolyBase, SQL pool loading patterns and strategies, Load Data with Azure Data Factory, Move data with Azure Data Factory, CREATE EXTERNAL FILE FORMAT, and Create table as select (CTAS).

외부 테이블 로드 후 쿼리Load then query external tables

외부 테이블이라고도 하는 Polybase는 데이터를 로드하는 가장 빠른 방법일 수 있지만 쿼리에 적합하지는 않습니다.While Polybase, also known as external tables, can be the fastest way to load data, it is not optimal for queries. Polybase 테이블은 현재 Azure Blob 파일 및 Azure Data Lake 스토리지만 지원합니다.Polybase tables currently only support Azure blob files and Azure Data Lake storage. 이러한 파일에는 지원 컴퓨팅 리소스가 없습니다.These files do not have any compute resources backing them.

결과적으로 SQL 풀이 이 작업을 오프로드할 수 없으므로, 데이터를 읽기 위해서는 tempdb에 로드하여 전체 파일을 읽어야 합니다.As a result, SQL pool cannot offload this work and therefore must read the entire file by loading it to tempdb in order to read the data. 따라서 이 데이터를 쿼리하는 쿼리가 여러 개 있는 경우 이 데이터를 한 번 로드한 후 쿼리에서 로컬 테이블을 사용하는 것이 더 좋습니다.Therefore, if you have several queries that will be querying this data, it is better to load this data once and have queries use the local table.

또한 PolyBase 사용 지침도 참조하세요.See also Guide for using PolyBase.

해시 배포 대형 테이블Hash distribute large tables

기본적으로 테이블은 라운드 로빈 분산됩니다.By default, tables are Round Robin distributed. 따라서 사용자는 해당 테이블이 배포되는 방식을 결정하지 않고도 테이블 생성을 간편하게 시작할 수 있습니다.This makes it easy for users to get started creating tables without having to decide how their tables should be distributed. 라운드 로빈 테이블은 일부 워크로드에 대해서는 잘 작동하지만 대체로 배포 열을 선택하면 성능이 훨씬 향상됩니다.Round Robin tables may perform sufficiently for some workloads, but in most cases selecting a distribution column will perform much better.

열로 배포된 테이블이 라운드 로빈 테이블의 성능을 능가하는 가장 일반적인 예는 두 개의 대형 팩트 테이블이 조인된 경우입니다.The most common example of when a table distributed by a column will far outperform a Round Robin table is when two large fact tables are joined.

예를 들어 order_id로 배포되는 주문 테이블과 order_id로 배포되는 트랜잭션 테이블이 있고 주문 테이블을 order_id로 트랜잭션 테이블에 조인하는 경우 이 쿼리는 통과 쿼리가 되어 데이터 이동 작업을 제거합니다.For example, if you have an orders table, which is distributed by order_id, and a transactions table, which is also distributed by order_id, when you join your orders table to your transactions table on order_id, this query becomes a pass-through query, which means we eliminate data movement operations. 단계가 적을수록 쿼리는 빨라집니다.Fewer steps mean a faster query. 데이터 이동이 적을수록 쿼리는 빨라집니다.Less data movement also makes for faster queries.

분산된 테이블을 로드할 때 로드가 느려지므로 들어오는 데이터가 배포 키로 정렬되지 않도록 합니다.When loading a distributed table, be sure that your incoming data is not sorted on the distribution key as this will slow down your loads.

성능을 향상시킬 수 있도록 배포 열을 선택하는 방법과 CREATE TABLE 문의 WITH 절에서 분산된 테이블을 정의하는 방법은 아래 링크를 참조하세요.See the following links for more details on how selecting a distribution column can improve performance as well as how to define a distributed table in the WITH clause of your CREATE TABLE statement.

또한 테이블 개요, 테이블 배포, 테이블 배포 선택, CREATE TABLE, CREATE TABLE AS SELECT도 참조하세요.See also Table overview, Table distribution, Selecting table distribution, CREATE TABLE, CREATE TABLE AS SELECT.

과도한 분할 피하기Do not over-partition

데이터를 분할하면 파티션 전환 또는 파티션 제거로 스캔 최적화를 통해 데이터를 효율적으로 유지 관리할 수 있지만 과도하게 분할할 경우 쿼리 속도가 느려질 수 있습니다.While partitioning data can be effective for maintaining your data through partition switching or optimizing scans by with partition elimination, having too many partitions can slow down your queries. SQL Server에서 제대로 작동할 수 있는 높은 세분성 파티션 전략이 SQL 풀에서는 제대로 작동하지 않을 수 있습니다.Often a high granularity partitioning strategy, which may work well on SQL Server may not work well in SQL pool.

너무 많은 파티션을 포함하면 각 파티션에 100만 개 미만의 행이 포함된 경우 클러스터형 columnstore 인덱스의 효율성이 떨어질 수도 있습니다.Having too many partitions can also reduce the effectiveness of clustered columnstore indexes if each partition has fewer than 1 million rows. 배후에서 SQL 풀이 사용자 데이터를 60개 데이터베이스로 분할하므로 100개 파티션이 있는 테이블을 만들면 실제로는 6000개의 파티션이 생성됩니다.Keep in mind that behind the scenes, SQL pool partitions your data for you into 60 databases, so if you create a table with 100 partitions, this actually results in 6000 partitions.

각 워크로드가 서로 다르므로 가장 좋은 방법은 분할 실험을 통해 사용자의 워크로드에 가장 적합한 방법을 찾는 것입니다.Each workload is different so the best advice is to experiment with partitioning to see what works best for your workload. SQL Server에서 작업한 것보다 낮은 세분성을 고려합니다.Consider lower granularity than what may have worked for you in SQL Server. 예를 들어 매일 분할보다는 매주 또는 매달 분할을 사용하는 것이 좋습니다.For example, consider using weekly or monthly partitions rather than daily partitions.

테이블 분할도 참조하세요.See also Table partitioning.

트랜잭션 크기 최소화Minimize transaction sizes

INSERT, UPDATE, DELETE 문은 트랜잭션에서 실행되며 실패할 경우 롤백해야 합니다.INSERT, UPDATE, and DELETE statements run in a transaction and when they fail they must be rolled back. 긴 롤백에 대한 가능성을 최소화하려면 가능한 경우 항상 트랜잭션 크기를 최소화합니다.To minimize the potential for a long rollback, minimize transaction sizes whenever possible. INSERT, UPDATE 및 DELETE 문을 부분으로 나누어 이를 수행할 수 있습니다.This can be done by dividing INSERT, UPDATE, and DELETE statements into parts.

예를 들어 1시간이 소요될 것으로 예상되는 INSERT가 있는 경우 가능하면 INSERT를 4개의 부분으로 나누어 각각 15분 이내에 실행되도록 합니다.For example, if you have an INSERT that you expect to take 1 hour, if possible, break up the INSERT into four parts, which will each run in 15 minutes. CTAS, TRUNCATE, DROP TABLE 또는 INSERT와 같은 특수한 로깅 사례를 최소한 활용하여 롤백 위험을 줄입니다.Leverage special Minimal Logging cases, like CTAS, TRUNCATE, DROP TABLE, or INSERT to empty tables, to reduce rollback risk.

롤백을 제거하는 다른 방법은 데이터 관리를 위한 파티션 전환과 같은 메타데이터 전용 작업을 사용하는 것입니다.Another way to eliminate rollbacks is to use Metadata Only operations like partition switching for data management. 예를 들어 테이블에서 order_date가 2001년 10월인 모든 행을 제거하기 위해 DELETE 문을 실행하는 대신 데이터를 매달 분할한 후 해당 파티션을 다른 테이블의 비어 있는 파티션의 데이터로 전환할 수 있습니다(ALTER TABLE 예 참조).For example, rather than execute a DELETE statement to delete all rows in a table where the order_date was in October of 2001, you could partition your data monthly and then switch out the partition with data for an empty partition from another table (see ALTER TABLE examples).

분할되지 않은 테이블의 경우 DELETE를 사용하는 대신, 테이블에 유지할 데이터를 기록하도록 CTAS를 사용하는 것이 좋습니다.For unpartitioned tables, consider using a CTAS to write the data you want to keep in a table rather than using DELETE. CTAS에 동일한 시간이 소요되는 경우 최소한의 트랜잭션 로깅을 포함하므로 실행하기에 훨씬 더 안전한 작업이며 필요할 경우 신속하게 취소할 수 있습니다.If a CTAS takes the same amount of time, it is a much safer operation to run as it has minimal transaction logging and can be canceled quickly if needed.

또한 트랜잭션 이해, 트랜잭션 최적, 테이블 분할, TRUNCATE TABLE, ALTER TABLECTAS(Create Table As Select)도 참조하세요.See also Understanding transactions, Optimizing transactions, Table partitioning, TRUNCATE TABLE, ALTER TABLE, and Create table as select (CTAS).

쿼리 결과 크기 축소Reduce query result sizes

이 단계를 수행하면 많은 쿼리 결과로 인해 발생하는 클라이언트 쪽 문제를 방지할 수 있습니다.This step helps you avoid client-side issues caused by large query result. 쿼리를 편집하여 반환되는 행 수를 줄일 수 있습니다.You can edit your query to reduce the number of rows returned. 일부 쿼리 생성 도구를 사용하면 각 쿼리에 "top N" 구문을 추가할 수 있습니다.Some query generation tools allow you to add "top N" syntax to each query. 임시 테이블로 쿼리 결과 CETAS를 수행한 후 하위 수준 처리를 위해 PolyBase 내보내기를 사용할 수도 있습니다.You can also CETAS the query result to a temporary table and then use PolyBase export for the downlevel processing.

가능한 가장 작은 열 크기 사용Use the smallest possible column size

DDL을 정의할 때 데이터를 지원할 가장 작은 데이터 형식을 사용하면 쿼리 성능이 향상됩니다.When defining your DDL, using the smallest data type that will support your data will improve query performance. 이 방법은 CHAR 및 VARCHAR 열에 특히 중요합니다.This approach is particularly important for CHAR and VARCHAR columns.

열에서 가장 긴 값이 25자인 경우 열을 VARCHAR(25)로 정의합니다.If the longest value in a column is 25 characters, then define your column as VARCHAR(25). 모든 문자 열을 큰 기본 길이로 정의하지 마세요.Avoid defining all character columns to a large default length. 또한 반드시 필요한 경우에는 열을 NVARCHAR를 사용하는 것보다 VARCHAR로 정의하세요.In addition, define columns as VARCHAR when that is all that is needed rather than use NVARCHAR.

또한 테이블 개요, 테이블 데이터 형식, CREATE TABLE도 참조하세요.See also Table overview, Table data types, CREATE TABLE.

임시 데이터에 대해 임시 힙 테이블 사용Use temporary heap tables for transient data

일시적으로 데이터를 방문하는 경우 힙 테이블을 사용하면 전체 프로세스가 더 빨라지는 것을 알 수 있습니다.When you are temporarily landing data, you may find that using a heap table will make the overall process faster. 추가 변환을 실행하기 전의 준비 과정으로만 데이터를 로드하는 경우 힙 테이블에 테이블을 로드하는 것이 클러스터형 columnstore 테이블에 데이터를 로드하는 것보다 훨씬 더 빠릅니다.If you are loading data only to stage it before running more transformations, loading the table to heap table will be much faster than loading the data to a clustered columnstore table.

또한 데이터를 임시 테이블에 로드하면 테이블을 영구 스토리지에 로드할 때보다 훨씬 빠르게 로드됩니다.In addition, loading data to a temp table will also load much faster than loading a table to permanent storage. 임시 테이블은 "#"으로 시작되며 테이블을 생성한 세션에서만 액세스할 수 있으므로 제한된 시나리오에서만 작동할 수 있습니다.Temporary tables start with a "#" and are only accessible by the session that created it, so they may only work in limited scenarios.

힙 테이블은 CREATE TABLE의 WITH 절에 정의됩니다.Heap tables are defined in the WITH clause of a CREATE TABLE. 임시 테이블을 사용하는 경우 해당 임시 테이블에서도 통계를 작성해야 합니다.If you do use a temporary table, remember to create statistics on that temporary table too.

또한 임시 테이블, CREATE TABLE, CREATE TABLE AS SELECT도 참조하세요.See also Temporary tables, CREATE TABLE, CREATE TABLE AS SELECT.

클러스터형 Columnstore 테이블 최적화Optimize clustered columnstore tables

columnstore 클러스터형 인덱스는 SQL 풀에 데이터를 저장할 수 있는 가장 효율적인 방법 중 하나입니다.Clustered columnstore indexes are one of the most efficient ways you can store your data in SQL pool. 기본적으로 SQL 풀의 테이블은 클러스터형 ColumnStore로 만들어집니다.By default, tables in SQL pool are created as Clustered ColumnStore. columnstore 테이블에서 쿼리에 대해 최상의 성능을 얻으려면 좋은 세그먼트 품질을 갖는 것이 중요합니다.To get the best performance for queries on columnstore tables, having good segment quality is important.

메모리 부족 상황에서 행이 columnstore 테이블에 기록되는 경우 columnstore 세그먼트 품질이 저하될 수 있습니다.When rows are written to columnstore tables under memory pressure, columnstore segment quality may suffer. 세그먼트 품질은 압축된 행 그룹에 있는 행의 수로 측정할 수 있습니다.Segment quality can be measured by number of rows in a compressed Row Group. 클러스터형 columnstore 테이블에 대해 세그먼트 품질을 감지하고 개선하는 단계별 지침은 테이블 인덱스 문서의 Columnstore 인덱스 품질 저하 원인을 참조하세요.See the Causes of poor columnstore index quality in the Table indexes article for step-by-step instructions on detecting and improving segment quality for clustered columnstore tables.

고품질 columnstore 세그먼트가 중요하므로 데이터를 로드하기 위해서는 중간 규모 또는 대규모 리소스 클래스에 속하는 사용자 ID를 사용하는 것이 좋습니다.Because high-quality columnstore segments are important, it's a good idea to use users IDs that are in the medium or large resource class for loading data. 낮은 데이터 웨어하우스 단위를 사용하면 로드하는 사용자에게 더 큰 리소스 클래스를 할당하려는 것입니다.Using lower data warehouse units means you want to assign a larger resource class to your loading user.

columnstore 테이블은 일반적으로 테이블당 100만개 이상의 행이 있고 각 SQL 풀 테이블이 60개 테이블로 파티션될 때까지 데이터를 압축된 columnstore 세그먼트에 푸시하지 않으므로 경험에 따르면 테이블에서 행 수가 6천만 개를 초과하지 않는다면 columnstore 테이블은 쿼리에 이점을 제공하지 않습니다.Since columnstore tables generally won't push data into a compressed columnstore segment until there are more than 1 million rows per table and each SQL pool table is partitioned into 60 tables, as a rule of thumb, columnstore tables won't benefit a query unless the table has more than 60 million rows. 6천만 개 미만의 행이 있는 테이블의 경우 columnstore 인덱스를 포함하는 것이 적절하지 않을 수 있습니다.For table with less than 60 million rows, it may not make any sense to have a columnstore index. 오히려 상황을 악화시킬 수 있습니다.It also may not hurt.

또한 데이터를 분할하는 경우 클러스터형 columnstore 인덱스의 이점을 얻기 위해 각 파티션에는 100개의 행을 포함하는 것이 좋습니다.Furthermore, if you partition your data, then you will want to consider that each partition will need to have 1 million rows to benefit from a clustered columnstore index. 테이블에 파티션 수가 100개라면 클러스터형 columnstore에서 이점을 얻으려면 60억 개 이상의 행을 포함해야 합니다(60개 배포 100개 파티션 1백만 개 행).If a table has 100 partitions, then it will need to have at least 6 billion rows to benefit from a clustered columns store (60 distributions 100 partitions 1 million rows).

이 예에서 테이블에 60억 개의 행이 없으면 파티션 수를 줄이거나 대신 힙 테이블을 사용하는 것이 좋습니다.If your table does not have 6 billion rows in this example, either reduce the number of partitions or consider using a heap table instead. 또한 실험을 통해 columnstore 테이블 대신 보조 인덱스가 있는 힙 테이블로 더 나은 성능을 얻을 수 있는지도 확인할 수 있습니다.It also may be worth experimenting to see if better performance can be gained with a heap table with secondary indexes rather than a columnstore table.

columnstore 테이블을 쿼리할 때 필요한 열만 선택하면 쿼리가 더 빨리 실행됩니다.When querying a columnstore table, queries will run faster if you select only the columns you need.

참고 항목: 테이블 인덱스, Columnstore 인덱스 가이드, Columnstore 인덱스 다시 빌드See also Table indexes, Columnstore indexes guide, Rebuilding columnstore indexes

더 큰 리소스 클래스를 사용하여 쿼리 성능 향상Use larger resource class to improve query performance

SQL 풀은 메모리를 쿼리에 할당하는 방법으로 리소스 그룹을 사용합니다.SQL pool uses resource groups as a way to allocate memory to queries. 기본적으로 모든 사용자가 배포당 100MB의 메모리를 부여하는 소형 리소스 클래스에 할당됩니다.Out of the box, all users are assigned to the small resource class, which grants 100 MB of memory per distribution. 항상 60개의 배포가 있고 각 배포에는 최소 100MB가 부여되므로 시스템 전체에서 총 메모리 할당량은 6,000MB이거나 6GB가 약간 못됩니다.Since there are always 60 distributions and each distribution is given a minimum of 100 MB, system wide the total memory allocation is 6,000 MB, or just under 6 GB.

큰 조인 또는 클러스터형 columnstore 테이블에 로드와 같은 특정 쿼리는 큰 메모리를 할당하는 것이 도움이 됩니다.Certain queries, like large joins or loads to clustered columnstore tables, will benefit from larger memory allocations. 순수 검색과 같은 일부 쿼리에는 어떤 이점도 없습니다.Some queries, like pure scans, will yield no benefit. 하지만 더 큰 리소스 클래스를 활용하면 동시성이 축소되므로 모든 사용자를 큰 리소스 클래스로 이동하기 전에 이러한 영향을 고려하는 것이 좋습니다.However, utilizing larger resource classes reduces concurrency, so you will want to take this impact into consideration before moving all of your users to a large resource class.

또한 워크로드 관리를 위한 리소스 클래스도 참조하세요.See also Resource classes for workload management.

더 작은 리소스 클래스를 사용하여 동시성 증가Use Smaller Resource Class to Increase Concurrency

사용자 쿼리에 긴 지연이 있는 것처럼 보이는 경우 사용자가 큰 리소스 클래스에서 실행 중이고 많은 동시성 슬롯을 사용 중이어서 다른 쿼리가 큐에 대기할 수 있습니다.If you notice that user queries seem to have a long delay, it could be that your users are running in larger resource classes and are consuming many concurrency slots causing other queries to queue up. 사용자 쿼리가 큐에 대기되었는지 확인하려면 SELECT * FROM sys.dm_pdw_waits 를 실행하여 모든 행이 반환되었는지 확인합니다.To see if users queries are queued, run SELECT * FROM sys.dm_pdw_waits to see if any rows are returned.

또한 워크로드 관리를 위한 리소스 클래스, sys.dm_pdw_waits도 참조하세요.See also Resource classes for workload management, sys.dm_pdw_waits.

기타 리소스Other resources

또한 일반적인 문제 및 해결 방법에 대해서는 문제 해결 문서를 참조하세요.Also see our Troubleshooting article for common issues and solutions.

이 문서에서 원하는 내용을 찾지 못한 경우 이 페이지의 왼쪽에 있는 "문서 검색"을 사용하여 모든 Azure Synapse 문서를 검색해보세요.If you didn't find what you are looking for in this article, try using the "Search for docs" on the left side of this page to search all of the Azure Synapse documents. Azure Synapse에 대한 Microsoft Q&A 질문 페이지는 다른 사용자와 Azure Synapse 제품 그룹에 질문을 게시할 수 있는 곳입니다.The Microsoft Q&A question page for Azure Synapse is a place for you to post questions to other users and to the Azure Synapse Product Group. Microsoft는 이 포럼을 적극적으로 모니터링하여 사용자의 질문에 다른 사용자나 당사 직원이 응답하도록 합니다.We actively monitor this forum to ensure that your questions are answered either by another user or one of us.

스택 오버플로에 질문하는 것을 선호하는 경우 Azure Synapse Stack Overflow 포럼도 제공합니다.If you prefer to ask your questions on Stack Overflow, we also have an Azure Synapse Stack Overflow Forum.

Azure Synapse 피드백 페이지를 사용하여 기능 요청을 수행하세요.Please use the Azure Synapse Feedback page to make feature requests. 요청을 추가하거나 다른 요청에 투표를 하면 기능의 순위를 지정하는 데 도움이 됩니다.Adding your requests or up-voting other requests really helps us prioritize features.