3.1 ASİT'in Ortaya Çıkışı

ASİT kısaltması ilk kez 1983 yılında Theo Haerder ve Andreas Reuter tarafından yazılan bir makalede kullanıldı. Metni basitleştirmek ve daha inandırıcı kılmak için bu makalenin bir kısmının çevirisini vereceğim (hafif kısaltmalarla). Bu snippet, paranın bir hesaptan diğerine aktarıldığı bir banka işlemi örneğini kullanır.

$BEGIN_TRANSACTIONÖrnekte ve arasındaki veritabanıyla tüm etkileşimleri içeren bir işlem kavramı, $COMMIT_TRANSACTIONtüm eylemlerin bölünmez bir şekilde gerçekleştirilmesini gerektirir: ya tüm eylemler veritabanının durumuna uygun şekilde yansıtılır ya da hiçbir şey olmaz. Herhangi bir zamanda $COMMIT_TRANSACTIONkullanıcı ulaşmadan önce ERRORiçeren bir ifade girerse $RESTORE_TRANSACTION, veritabanına hiçbir değişiklik yansıtılmaz.

Bu bölünmezliği elde etmek için, bir işlemin aşağıdaki dört özelliğe sahip olması gerekir:

Atomiklik (Atomiklik). İşlem, yukarıda açıklanan ya hep ya hiç türünde olmalı ve ne olursa olsun, kullanıcı işlemin hangi durumda olduğunu bilmelidir.

Tutarlılık (Tutarlılık). Normal işlem sonuna (EOT) ulaşan ve dolayısıyla sonuçlarını taahhüt eden bir işlem, veritabanı tutarlılığını korur. Başka bir deyişle, tanım gereği her başarılı işlem yalnızca geçerli sonuçları taahhüt eder. Bu koşul, dördüncü özelliği - dayanıklılığı desteklemek için gereklidir.

İzolasyon (İzolasyon). Bir işlem içinde meydana gelen olaylar, aynı anda yürütülen diğer işlemlerden gizlenmelidir. Bu koşul yerine getirilmezse, yukarıda belirtilen nedenlerle işlemin tekrar başa dönmesi mümkün olmayacaktır. İzolasyonu sağlamak için senkronizasyon adı verilen yöntemler kullanılır...

Dayanıklılık (Dayanıklılık). Bir işlem tamamlandıktan ve sonuçlarını veri tabanına kaydettikten sonra, sistem bu sonuçların sonraki başarısızlıklara karşı dayanıklı olmasını sağlamalıdır. İşlem kümelerini kapsayan bir denetim kapsamı olmadığından, veritabanı yönetim sisteminin (DBMS) işlem sınırlarının ötesinde bir denetimi yoktur.

Bu nedenle, kullanıcıya, sistem kendisine bir şey olduğunu bildirirse, bu "bir şeyin" gerçekten olduğu garanti edilmelidir. Tanım gereği, herhangi bir (başarıyla tamamlanan - S.K.) işlem doğru olduğundan, kaçınılmaz olarak ortaya çıkan hatalı işlemlerin (yani hatalı veriler içeren işlemler) sonuçları yalnızca ilgili "karşı" işlemle (karşı işlem) ortadan kaldırılabilir.

3.2 İşlemlerin ortaya çıkışı

Atomiklik, Tutarlılık, İzolasyon ve Dayanıklılık (ACID) olmak üzere bu dört özellik, veritabanı sistemi tasarımının birçok yönünü etkileyen işlem paradigmasının temel özelliklerini tanımlar. Bu nedenle, herhangi bir sistemin işlemleri destekleme yeteneğinin, bu sistemin kalitesinin mihenk taşı (ASİT testi) olduğuna inanıyoruz.

Bir hesaptan diğerine para aktaran basit bir PL/1-SQL programı.

FUNDS_TRANSFER. PROCEDURE,
 $BEGIN_TRANSACTION;
 ON ERROR DO;                                   /* in case of error */
          $RESTORE_TRANSACTION,                 /* undo all work */
          GET INPUT MESSAGE;                    /* reacquire input */
          PUT MESSAGE ('TRANSFER FAILED');      /* report failure */
          GO TO COMMIT;
          END;
 GET INPUT MESSAGE;                             /* get and parse input */
 EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
  AMOUNT FROM MESSAGE,
 $UPDATE ACCOUNTS                               /* do debit */
              SET BALANCE ffi BALANCE - AMOUNT
     WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
 $UPDATE ACCOUNTS                               /* do credit */
              SET BALANCE = BALANCE + AMOUNT
     WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
 $INSERT INTO HISTORY                           /* keep audit trail */
    <DATE, MESSAGE>;
 PUT MESSAGE ('TRANSFER DONE');                 /* report success */
COMMIT:                                         /* commit updates */
 $COMMIT_TRANSACTION;
 END;                                           /* end of program */

Aslında, ACID özelliklerinin bir yandan işlemleri desteklediğini iddia eden herhangi bir DBMS için gereksinimler olarak kabul edilebileceğini ve diğer yandan da bir işlemin tanımı olarak kabul edilebileceğini size hatırlatmak için bu kodun bir örneğini verdim. bir veri tabanı sistemi . Bu tanım, dünyevi pratikle tamamen tutarlıdır. Örneğin, bir bankacılık işlemi gerçekleştiren bir müşterinin (canlı bir veznedarın yardımıyla veya İnternet bankacılığını kullanarak) bankanın ASİT'in tüm özelliklerini karşılamasını beklemediğini hayal etmek zordur. İşlemleri için ASİT özelliklerini desteklemeyen bir banka, en iyi ihtimalle müşteri kaybeder ve en kötü ihtimalle iflas eder.

3.3 ASİT Bağlantısı

ASİT özelliklerinin ayrılmaz olması çok önemlidir, bunlardan herhangi birinin atılması kalan kombinasyonu anlamsız kılar. Özellikle, tutarlılık özelliğini (yukarıdaki alıntıda kullanıldığı anlamda) atarsak, bir işlemin doğruluğuna ilişkin kriteri kaybederiz. Veri tabanı sistemi, işlemlerin yapılmasına izin verilip verilmeyeceğine anlamlı bir şekilde karar veremeyecek ve veri tabanının mevcut durumunda gerçekleştirilen işlemlerin doğruluğuna yönelik tüm kontrollerin uygulama kodunda yapılması gerekecektir.

Bu durumda mantıksal tutarlılıktan bahsettiğimizi anlamalısınız. Banka müşterisi, bankanın kendisi tarafından belirlenen ve müşteriler tarafından bilinen kurallara göre çalışmasına ihtiyaç duyar, böylece bu kurallara aykırı herhangi bir işlemin gerçekleştirilmesi imkansız hale gelir, böylece aynı müşteri tarafından bir sonraki işlem gerçekleştirilir. çevre bu kurallara göre kararlaştırılır.

Çevrimiçi mağazanın müşterisi, kendisi tarafından sipariş edilen ve ödemesi yapılan malların zamanında (müşteri tarafından belirlenen ve bilinen kurallara uygun olarak) kendisine teslim edilmesini ister. Aksi takdirde bu mağazaya güvenmeyecektir. Aynı zamanda, ne bankanın müşterisi ne de İnternet mağazasının müşterisi, işletmenin iç mutfağını, işlemini tamamlamak için hangi iç önlemlerin alındığını umursamıyor. İstemci, bu işletmenin fiziksel tutarlılığının nasıl sağlandığını, fiziksel katmanda işlemlerin nasıl yapıldığını umursamaz.

DBMS, işlemlerin (ve veritabanının) mantıksal tutarlılığını korumaya özen gösterirse, uygulamalar daha basit, daha anlaşılır ve daha güvenilir hale gelir. Uygulama alanının (banka, mağaza, depo vb.) işlemlere ilişkin tüm mantığı ve verilerin geçerli durumu veri tabanı sistemine girilir. Ve bu sistemin gereksinimleri çok basit: uygulama tarafından veritabanında sağlanan tutarlılık kurallarını dikkate alarak ACID işlemleri için destek. Benim bakış açıma göre, ACID işlemlerinin reddedilmesi, müşterilerinin doğal ihtiyaçlarını karşılamak için beğenseniz de beğenmeseniz de benzer bir şeyi kendileri uygulamak zorunda kalacak olan uygulama geliştiricileri için aşırı zorluklar yaratıyor.

Ve bir kez daha ASİT özelliklerinin aslında bir işlem kavramını tanımladığını not ediyorum. Kanaatimce, işlem tutarlılığı özelliğinin desteklenmediği bir işlemsel veri yönetim sisteminden en azından bir şekilde bahsetme olasılığına sahip olmak için, bu durumda işlem terimi ile ne kastedildiğini kesinlikle tanımlamak gerekir.

Ne yazık ki, bugün birçok durumda (özellikle bu, NoSQL yönünün bir özelliğidir), insanlar ne tür işlemleri kastettiklerini hiç belirtmeden OLTP uygulamalarını desteklemekten bahsediyorlar. Bu nedenle, bu makalede, gerçek işlemlere atıfta bulunmak için ASİT işlemi kombinasyonunu kullanacağım ve niteliksiz terim işlemi , farklı bağlamlarda farklı olarak gayri resmi bir anlamda kullanılacaktır.

Şimdi CAP "teoremi"ni ele alalım ve Brewer'ın kullandığı anlamda tutarlılığın ne anlama geldiğini anlamaya çalışalım.