Çevrimiçi işlem gerçekleştirme (OLTP)Online transaction processing (OLTP)

İşlem verileri bilgisayar sistemleri kullanarak yönetimini çevrimiçi işlem işleme (OLTP olarak) denir.The management of transactional data using computer systems is referred to as Online Transaction Processing (OLTP). Kuruluşunuzun gündelik işlemde oluşur ve çıkarımı yapmak için bu verileri sorgulamayı destekleme OLTP sistemleri iş etkileşimleri kaydeder.OLTP systems record business interactions as they occur in the day-to-day operation of the organization, and support querying of this data to make inferences.

İşlem verileriTransactional data

İşlemsel Veri izleyen bir kuruluşun eylemleriyle ilgili etkileşimleri bilgilerdir.Transactional data is information that tracks the interactions related to an organization's activities. Bu etkileşimlerin normal tedarikçiler, Envanter, siparişler gerçekleştirilen veya hizmetlerine gönderilen üstünden geçme ürünleri yapılan müşterilerden alınan ödemeler gibi ticari işlemler uygulanır.These interactions are typically business transactions, such as payments received from customers, payments made to suppliers, products moving through inventory, orders taken, or services delivered. İşlem temsil eder ve işlem olayları genellikle zaman boyutu, bazı sayısal değerleri ve diğer verilere başvuruda bulunur.Transactional events, which represent the transactions themselves, typically contain a time dimension, some numerical values, and references to other data.

İşlemler genellikle ihtiyacınız olacak şekilde atomik ve tutarlı.Transactions typically need to be atomic and consistent. Kararlılık tamamını bir işlem her zaman başarılı veya başarısız bir iş birimi, hiçbir zaman yarı tamamlanmış bir durumda bırakılır anlamına gelir.Atomicity means that an entire transaction always succeeds or fails as one unit of work, and is never left in a half-completed state. Bir işlem tamamlanamıyor, veritabanı sistemi bu işlemin bir parçası zaten yapıldığını herhangi bir adım geri alma gerekir.If a transaction cannot be completed, the database system must roll back any steps that were already done as part of that transaction. Bir işlem tamamlanamıyor, geleneksel bir RDBMS'de bu geri alma otomatik olarak gerçekleşir.In a traditional RDBMS, this rollback happens automatically if a transaction cannot be completed. Tutarlılık işlemleri geçerli bir durumda her zaman verileri bırakır anlamına gelir.Consistency means that transactions always leave the data in a valid state. (Bu, çok resmi olmayan açıklamaları kararlılık ve tutarlılık bulunur.(These are very informal descriptions of atomicity and consistency. Vardır, bu özellikler daha resmi tanımları gibi ACID.)There are more formal definitions of these properties, such as ACID.)

İşlem veritabanları güçlü tutarlılık tüm verilerin Kurumsal bağlamında kesinlikle tutarlı olduğundan emin olmak için kötümser kilitleme gibi çeşitli kilitleme stratejileri kullanarak işlemleri için tüm kullanıcı ve işlemler için destekleyebilir.Transactional databases can support strong consistency for transactions using various locking strategies, such as pessimistic locking, to ensure that all data is strongly consistent within the context of the enterprise, for all users and processes.

İşlem verilerini kullanan en yaygın dağıtım mimarisi 3 katmanlı mimaride veri deposu katmandır.The most common deployment architecture that uses transactional data is the data store tier in a 3-tier architecture. 3 katmanlı bir mimari, genellikle bir sunu katmanı, iş mantığı katmanı ve veri depolama katmanından oluşur.A 3-tier architecture typically consists of a presentation tier, business logic tier, and data store tier. İlgili dağıtım mimarisi N katmanlı birden fazla orta katman sahip olabilecek mimarisi işleme iş mantığı.A related deployment architecture is the N-tier architecture, which may have multiple middle-tiers handling business logic.

İşlemsel Veri tipik niteliklerTypical traits of transactional data

İşlem verilerini aşağıdaki nitelikler sahip eğilimindedir:Transactional data tends to have the following traits:

GereksinimRequirement AçıklamaDescription
NormalleştirmeNormalization Yüksek oranda normalleştirilmişHighly normalized
ŞemaSchema Yazma, kesin zorlanan şemasıSchema on write, strongly enforced
TutarlılıkConsistency Güçlü tutarlılık, ACID garantileriStrong consistency, ACID guarantees
BütünlükIntegrity Yüksek bütünlüğüHigh integrity
İşlemleri kullanırUses transactions EvetYes
Kilitleme stratejisiLocking strategy Kötümser veya iyimserPessimistic or optimistic
GüncelleştirilebilirUpdateable EvetYes
EklenebilirAppendable EvetYes
İş yüküWorkload Ağır yazma, Orta okurHeavy writes, moderate reads
DizinlemeIndexing Birincil ve ikincil dizinlerPrimary and secondary indexes
Veri boyutuDatum size Küçük ve orta boyutluSmall to medium sized
ModelModel İlişkiselRelational
Veri şekliData shape TabloTabular
Sorgu esneklikQuery flexibility Son derece esnekHighly flexible
ÖlçekScale (MB) küçük ve büyük (birkaç TB'a)Small (MBs) to Large (a few TBs)

Bu çözümü kullanmak ne zamanWhen to use this solution

Verimli bir şekilde işlemek ve iş işlemleri depolamak ve hemen istemci uygulamaları için tutarlı bir şekilde ayıklanarak gerektiğinde OLTP seçin.Choose OLTP when you need to efficiently process and store business transactions and immediately make them available to client applications in a consistent way. Bu mimari işleme somut kurtarmadaki gecikmeyi iş günlük işlemlerini üzerinde olumsuz bir etkiye sahip kullanın.Use this architecture when any tangible delay in processing would have a negative impact on the day-to-day operations of the business.

OLTP sistemleri, verimli bir şekilde işlemek ve işlemlerin yanı sıra, sorgu işlem verilerini depolamak için tasarlanmıştır.OLTP systems are designed to efficiently process and store transactions, as well as query transactional data. Verimli bir şekilde işleme ve tek tek işlemleri bir OLTP sistem tarafından depolama amacı kısmen tarafından veri normalleştirme gerçekleştirilir — diğer bir deyişle, verileri daha az gereksiz olduğunu daha küçük öbeklere ayırma.The goal of efficiently processing and storing individual transactions by an OLTP system is partly accomplished by data normalization — that is, breaking the data up into smaller chunks that are less redundant. Bu, çok sayıda işlem bağımsız olarak işlenecek OLTP sisteminde sağladığından, verimliliği destekler ve yedekli veri varlığında veri bütünlüğünün sürdürülmesi için gereken ek işlem önler.This supports efficiency because it enables the OLTP system to process large numbers of transactions independently, and avoids extra processing needed to maintain data integrity in the presence of redundant data.

ZorluklarChallenges

Uygulama ve bir OLTP sisteminde kullanarak bazı zorluklar oluşturabilirsiniz:Implementing and using an OLTP system can create a few challenges:

  • OLTP sistemlerindeki bulunmasına karşın özel durumlar, iyi planlanmış bir SQL Server tabanlı çözümü gibi her zaman toplamaları büyük miktarlarda verileri işlemek için iyi değildir.OLTP systems are not always good for handling aggregates over large amounts of data, although there are exceptions, such as a well-planned SQL Server-based solution. Toplama hesaplamaları üzerinde tek tek işlemleri milyonlarca kullanan, veri analizi için bir OLTP sistemi yoğun çok kaynak var.Analytics against the data, that rely on aggregate calculations over millions of individual transactions, are very resource intensive for an OLTP system. Yürütme ve yavaş olabilir diğer işlemleri veritabanına engelleyerek bir artışına neden.They can be slow to execute and can cause a slow-down by blocking other transactions in the database.
  • Ne zaman analiz gerçekleştirme ve yüksek oranda normalleştirilmiştir veri raporlama, sorguları birleştirmeleri kullanarak verileri seri durumdan Normalleştirilecek sorguların çoğu gerektiği için karmaşık olma eğilimindedir.When conducting analytics and reporting on data that is highly normalized, the queries tend to be complex, because most queries need to de-normalize the data by using joins. Ayrıca, OLTP sistemlerindeki veritabanı nesneleri için adlandırma kuralları kısa ve Sözün olma eğilimindedir.Also, naming conventions for database objects in OLTP systems tend to be terse and succinct. Terse adlandırma kuralları ile birlikte artan normalleştirme OLTP sistemlerindeki Sorgulanacak DBA veya veri Geliştirici Yardımı olmadan iş kullanıcılarına zorlaştırır.The increased normalization coupled with terse naming conventions makes OLTP systems difficult for business users to query, without the help of a DBA or data developer.
  • Herhangi bir tabloda çok fazla veri depolamak ve hareketleri geçmişini süresiz olarak saklamak depolanan işlemlerin sayısına bağlı olarak, sorgu performansı yavaş neden olabilir.Storing the history of transactions indefinitely and storing too much data in any one table can lead to slow query performance, depending on the number of transactions stored. OLTP sisteminde süre (örneğin, geçerli mali yıl) ilgili bir pencere korumak ve geçmiş verileri bir veri reyonu gibi diğer sistemlere yük boşaltması için ortak çözümüdür veya veri ambarı.The common solution is to maintain a relevant window of time (such as the current fiscal year) in the OLTP system and offload historical data to other systems, such as a data mart or data warehouse.

Azure'da OLTPOLTP in Azure

Barındırılan Web siteleri gibi uygulamaları App Service Web Apps, App Service'te çalışan REST API'leri veya mobil veya Masaüstü uygulamaları OLTP sisteminde, genellikle bir REST API aracı üzerinden iletişim kurar.Applications such as websites hosted in App Service Web Apps, REST APIs running in App Service, or mobile or desktop applications communicate with the OLTP system, typically via a REST API intermediary.

Uygulamada, çoğu iş yükü tamamen OLTP değildir.In practice, most workloads are not purely OLTP. Analitik bir bileşen de var. gibi eğilimlidir.There tends to be an analytical component as well. Ayrıca, gerçek zamanlı raporlama, işletimsel bir sistemle bağlantılı raporları çalıştırma gibi bir artan talebi yok.In addition, there is an increasing demand for real-time reporting, such as running reports against the operational system. Bu ayrıca HTAP (karma işlemsel ve analitik işleme) adlandırılır.This is also referred to as HTAP (Hybrid Transactional and Analytical Processing). Daha fazla bilgi için Online Analytical Processing (OLAP).For more information, see Online Analytical Processing (OLAP).

Azure'da tüm aşağıdaki veri depolarını OLTP için temel gereksinimler ve işlem veri yönetimini karşılar:In Azure, all of the following data stores will meet the core requirements for OLTP and the management of transaction data:

Temel seçim ölçütlerineKey selection criteria

Seçimleri daraltmak için bu soruyu yanıtlayarak başlatın:To narrow the choices, start by answering these questions:

  • Kendi sunucularınızı yönetmek yerine yönetilen bir hizmet istiyor musunuz?Do you want a managed service rather than managing your own servers?

  • Çözümünüzü Microsoft SQL Server, MySQL veya PostgreSQL uyumluluk için belirli bağımlılıkları var mı?Does your solution have specific dependencies for Microsoft SQL Server, MySQL or PostgreSQL compatibility? Uygulamanızı seçebileceğiniz depoları destekliyorsa veri deposuyla iletişim kurmak için sürücüleri veya hakkında veritabanı kullanılan kolaylaştırır varsayımlara dayalı veri sınırlayabilir.Your application may limit the data stores you can choose based on the drivers it supports for communicating with the data store, or the assumptions it makes about which database is used.

  • Yazma aktarım hızı gereksinimlerinizi, özellikle yüksek misiniz?Are your write throughput requirements particularly high? Evet, bellek içi tablolar sağlayan bir seçeneği belirleyin.If yes, choose an option that provides in-memory tables.

  • Çözüm çok kiracılı mı?Is your solution multitenant? Bu durumda, kapasite havuzları, elastik havuz, veritabanı başına sabit kaynakları yerine kaynakların birden çok veritabanı örnekleri burada yerleri destek seçeneklerini göz önünde bulundurun.If so, consider options that support capacity pools, where multiple database instances draw from an elastic pool of resources, instead of fixed resources per database. Bu, yardımcı daha iyi kapasite tüm veritabanı örnekleri arasında dağıtın ve çözümünüzü daha uygun maliyetli hale getirebilirsiniz.This can help you better distribute capacity across all database instances, and can make your solution more cost effective.

  • Verilerinizi birden çok bölgede düşük gecikme süresi ile okunabilir olması gerekiyor mu?Does your data need to be readable with low latency in multiple regions? Evet, okunabilir ikincil çoğaltma destekleyen bir seçeneği belirleyin.If yes, choose an option that supports readable secondary replicas.

  • Veritabanınızı grafik coğrafi bölgeler arasında yüksek oranda kullanılabilir olması gerekiyor mu?Does your database need to be highly available across geo-graphic regions? Evet, coğrafi çoğaltma destekleyen bir seçeneği belirleyin.If yes, choose an option that supports geographic replication. Ayrıca, bir ikincil çoğaltma otomatik yük devretme birincil çoğaltmadan destek seçenekleri göz önünde bulundurun.Also consider the options that support automatic failover from the primary replica to a secondary replica.

  • Veritabanınızı belirli güvenlik gereksinimleri var mı?Does your database have specific security needs? Yanıt Evet ise, satır düzeyi güvenlik, veri maskeleme ve saydam veri şifrelemesi gibi özellikler sağlayan seçenekleri inceleyin.If yes, examine the options that provide capabilities like row level security, data masking, and transparent data encryption.

Özellik MatrisiCapability matrix

Aşağıdaki tablolarda, Özellikler'deki temel farklılıklar özetlenmektedir.The following tables summarize the key differences in capabilities.

Genel özellikleriGeneral capabilities

ÖzellikCapability Azure SQL VeritabanıAzure SQL Database Azure sanal makine'de SQL ServerSQL Server in an Azure virtual machine MySQL için Azure VeritabanıAzure Database for MySQL PostgreSQL için Azure VeritabanıAzure Database for PostgreSQL
Olduğundan hizmet tarafından yönetilenIs Managed Service EvetYes HayırNo EvetYes EvetYes
Platform üzerinde çalıştırmaRuns on Platform YokN/A Windows, Linux, DockerWindows, Linux, Docker YokN/A YokN/A
Programlanabilirlik 1Programmability 1 T-SQL, .NET, RT-SQL, .NET, R T-SQL, .NET, R, PythonT-SQL, .NET, R, Python T-SQL, .NET, R, PythonT-SQL, .NET, R, Python SQLSQL

[1 OLTP veri deposuna bağlanın ve birçok programlama dili sağlayan istemci sürücü desteği dahil olmak üzere].[1] Not including client driver support, which allows many programming languages to connect to and use the OLTP data store.

Ölçeklenebilirliği özellikleriScalability capabilities

ÖzellikCapability Azure SQL VeritabanıAzure SQL Database Azure sanal makine'de SQL ServerSQL Server in an Azure virtual machine MySQL için Azure VeritabanıAzure Database for MySQL PostgreSQL için Azure VeritabanıAzure Database for PostgreSQL
En fazla veritabanı örnek boyutuMaximum database instance size 4 TB4 TB 256 TB256 TB 1 TB1 TB 1 TB1 TB
Kapasite havuzlarını desteklerSupports capacity pools EvetYes EvetYes HayırNo HayırNo
Destekler kümeleri ölçeklendirmeSupports clusters scale out HayırNo EvetYes HayırNo HayırNo
Dinamik ölçeklenebilirlik (büyütme)Dynamic scalability (scale up) EvetYes HayırNo EvetYes EvetYes

Analiz iş yükü özellikleriAnalytic workload capabilities

ÖzellikCapability Azure SQL VeritabanıAzure SQL Database Azure sanal makine'de SQL ServerSQL Server in an Azure virtual machine MySQL için Azure VeritabanıAzure Database for MySQL PostgreSQL için Azure VeritabanıAzure Database for PostgreSQL
Zamana bağlı tablolarTemporal tables EvetYes EvetYes HayırNo HayırNo
Bellek içi (bellek için iyileştirilmiş) tablolarIn-memory (memory-optimized) tables EvetYes EvetYes HayırNo HayırNo
Columnstore desteğiColumnstore support EvetYes EvetYes HayırNo HayırNo
Uyarlamalı sorgu işlemeAdaptive query processing EvetYes EvetYes HayırNo HayırNo

Kullanılabilirlik özellikleriAvailability capabilities

ÖzellikCapability Azure SQL VeritabanıAzure SQL Database Azure sanal makine'de SQL ServerSQL Server in an Azure virtual machine MySQL için Azure VeritabanıAzure Database for MySQL PostgreSQL için Azure VeritabanıAzure Database for PostgreSQL
Okunabilir ikincil veritabanıReadable secondaries EvetYes EvetYes HayırNo HayırNo
Coğrafi çoğaltmaGeographic replication EvetYes EvetYes HayırNo HayırNo
Otomatik Yük devretme ikincilAutomatic failover to secondary EvetYes HayırNo HayırNo HayırNo
Belirli bir noktaya geri yüklemePoint-in-time restore EvetYes EvetYes EvetYes EvetYes

Güvenlik özellikleriSecurity capabilities

ÖzellikCapability Azure SQL VeritabanıAzure SQL Database Azure sanal makine'de SQL ServerSQL Server in an Azure virtual machine MySQL için Azure VeritabanıAzure Database for MySQL PostgreSQL için Azure VeritabanıAzure Database for PostgreSQL
Satır düzeyi güvenlikRow level security EvetYes EvetYes EvetYes EvetYes
Veri maskelemeData masking EvetYes EvetYes HayırNo HayırNo
Saydam veri şifrelemesiTransparent data encryption EvetYes EvetYes EvetYes EvetYes
Belirli IP adreslerine erişimi kısıtlamaRestrict access to specific IP addresses EvetYes EvetYes EvetYes EvetYes
Yalnızca sanal ağ erişim izni vermek için erişimi kısıtlamaRestrict access to allow VNet access only EvetYes EvetYes HayırNo HayırNo
Azure Active Directory kimlik doğrulamasıAzure Active Directory authentication EvetYes EvetYes HayırNo HayırNo
Active Directory kimlik doğrulamasıActive Directory authentication HayırNo EvetYes HayırNo HayırNo
Multi-factor authenticationMulti-factor authentication EvetYes EvetYes HayırNo HayırNo
Destekler her zaman şifreliSupports Always Encrypted EvetYes EvetYes EvetYes HayırNo
Özel IPPrivate IP HayırNo EvetYes EvetYes HayırNo