Giriş

Dijital çağın hızla değişen talepleri, veri tabanı teknolojilerinde yenilikçi yaklaşımların önünü açmaktadır. Bu dinamik ortamda, modern uygulamalar, sadece yüksek performans değil, aynı zamanda yüksek erişilebilirlik ve esnek ölçeklenebilirlik gibi özellikler de beklemektedir. CockroachDB, bu talepleri karşılamak üzere tasarlanmış, güçlü özellikleriyle ön plana çıkan, dağıtık mimarili bir veri tabanı çözümüdür. Yenilikçi mimarisi, yüksek düzeydeki hata toleransı, otomatik ölçeklenme yetenekleri ve veri bütünlüğüne olan katkılarıyla bu veri tabanı çözümü, modern uygulama geliştiricilerinin karşılaştığı zorlu sorunlara etkili çözümler sunmaktadır.

PostgreSQL ile olan yüksek uyumluluğu sayesinde mevcut PostgreSQL kullanıcılarının CockroachDB’ye geçişi oldukça kolay bir şekilde gerçekleştirilebilmektedir. Bu, PostgreSQL’de bulunan SQL tabanlı sorgu dilleri ve araç setlerini kullanarak daha güçlü ve ölçeklenebilir bir sistem inşa edilmesine olanak tanımaktadır. Aynı zamanda, coğrafi olarak yayılmış veri merkezlerinde bile yüksek performans ve erişilebilirlik sağlayan CockroachDB, küresel çapta faaliyet gösteren uygulamalar için ideal bir tercih haline gelmektedir.

Bu yazıda, CockroachDB’nin modern yazılım geliştirme dünyasında nasıl bir rol oynadığı ve sağladığı katkılar vurgulanarak okuyucuları bu yenilikçi veri tabanı çözümüyle tanıştırmak amaçlanmıştır.

Geleneksel Merkezi Veri Tabanı Sistemleri

Kullanıcılar web uygulamalarından, temelde üç unsur beklemektedir. Bunlar hız, tutarlılık ve erişilebilirliktir. Geleneksel merkezi veri tabanı sistemleri, başlangıçta bu ihtiyaçlar için yeterli olmaktadır. Ancak bu sistemler, modern uygulamaların artan kullanıcı sayısı ve işlem hacmi karşısında milyonlarca eşzamanlı isteği işleme, ölçeklendirme ve erişilebilirlik gibi konularda yetersiz kalabilmektedir. Çünkü bu veri tabanı sistemleri, verileri tek bir sunucuda saklar ve yönetir. Tek sunucu bulunması durumunda;

• Sistem kaynakları (bellek, CPU ve depolama gibi) sınırlıdır. Bu kaynaklar yüksek talep altında tükenmekte ve sistemin performansı düşmektedir.
• Sunucunun kaynaklarını arttırmak (dikey ölçeklendirme) maliyetli ve belirli bir noktadan sonra pratik olmayan bir çözümdür.
• Sunucuda yaşanacak herhangi bir sorun, tüm sistem için kesintiye neden olabilmekte ve sistem erişilemez hale gelebilmektedir.

Yaşanabilecek bu sorunları önlemek ve artan talepleri karşılamak amacıyla “NewSQL” terimi ortaya çıkmıştır.

NewSQL

“NewSQL” terimi, geleneksel İlişkisel Veri Tabanı Sistemleri’nin (RDBMS) sağladığı ACID (Atomicity, Consistency, Isolation, Durability) özellikleri ile NoSQL sistemlerinin ölçeklenebilirlik ve dağıtık işleme yeteneklerini birleştiren yeni nesil veri tabanı sistemlerini tanımlamak için kullanılmaktadır.

Peki, nedir bu ACID özellikleri? Öncelikle buna bakalım.

ACID (Atomicity, Consistency, Isolation, Durability)

ACID, veri tabanı işleminin doğru ve güvenilir olduğunu garanti etmek için tasarlanmıştır. Ayrıca ACID, veri tabanı işlemlerinin dört temel prensibini ifade etmektedir:

1. Atomiklik: Bir işlem ya tamamen gerçekleşir ya da hiç gerçekleşmez. Başka bir deyişle, bir işlemde birden fazla adım varsa ve bu adımlardan herhangi biri başarısız olursa, tüm işlem geri alınır (rollback). Eğer tüm adımlar başarılı olursa, işlem onaylanır (commit).
2. Tutarlılık: İşlemlerin, veri tabanı bütünlük kurallarına ve kısıtlamalarına (constraint) uygun bir şekilde gerçekleştirilmesini ve veri tabanının her zaman tutarlılığını korumasını sağlar.
3. İzolasyon: Paralel işlemlerin birbirlerini etkilemeden yürütülmesini sağlar. Bu özellik, eşzamanlı işlemlerin birbirlerine karışmasını engeller.
4. Dayanıklılık: Bir işlem onaylandıktan (commit) sonra, sonuçları kalıcıdır. Sistemin çökmesi veya güç kesilmesi gibi durumlarda dahi kaybolmamaktadır. Genellikle bu durum değişikliklerin sabit diske yazılmasıyla sağlanmaktadır.

NewSQL veri tabanı sistemleri, modern veri yönetimi ve işlem ihtiyaçlarına cevap vermek için tasarlanmıştır. Sunduğu özellikler:

• Yatay Ölçeklenebilirlik ve Elastiklik: Birden fazla sunucu üzerinde veri ve işlemleri dağıtarak, sistem kaynaklarının genişletilmesi ve yüksek talebin karşılanabilmesini sağlar.
• Yüksek Erişilebilirlik ve Dayanıklılık: Verileri birden fazla düğümde replike ederek, tek bir noktada arıza durumunda [Single Point of Failure (SPOF)] bile veri kaybının önlenmesini ve sürekli hizmet sunulmasını sağlar.

Bu sistemler, aynı zamanda dağıtık mimarileri destekler. Bu nedenle “Dağıtılmış (Distributed) SQL” olarak da sınıflandırılmaktadırlar.

Dağıtılmış (Distributed) SQL

Dağıtılmış SQL, veri tabanlarının dağıtık bir mimaride çalışmasını ve verilerin birden fazla fiziksel lokasyonda saklanmasını sağlayan SQL tabanlı sistemleri tanımlamaktadır. Bu sistemlerin ana amacı, veri tabanı işlemlerinin birden fazla sunucu veya düğüm arasında dağıtılmasını sağlayarak yüksek ölçeklenebilirlik ve dayanıklılık sunmaktır.

CAP Teoremi

CAP Teoremi, dağıtılmış sistemlerin temel sınırlamalarını tanımlamaktadır. CAP, Tutarlılık (Consistency), Erişilebilirlik (Availability) ve Bölünme Toleransı (Partition Tolerance) kelimelerinin baş harflerinden oluşmaktadır. Teorem ise dağıtılmış veri tabanının, CAP’i oluşturan bu üç özellikten yalnızca ikisini aynı anda tam olarak sağlayabileceğini belirtmektedir.

1. Tutarlılık: Her düğümde aynı verinin görüntülenebilmesidir.
2. Erişilebilirlik: Her istekte yanıt alınabilmesidir.
3. Bölünme Toleransı: Sistemin, bazı iletişim kesintilerine (ağ bölünmelerine) rağmen çalışmaya devam edebilmesidir.

Bu bağlamda veri tabanları genelde CA, CP ve AP olmak üzere 3 gruba ayrılmaktadır. Her grup, CAP teoreminin iki özelliğine odaklanmakta ve bunun sonucunda diğer üçüncü olan özellikten ödün vermektedir.

1. CA (Consistency and Availability)

• Bu sistemler, veri tutarlılığı ve erişilebilirlik sağlarlar. Yani her sorgu için güvenilir bir cevap verirler ve veri hep güncel tutulur.
• Örnek: Microsoft SQL Server, Oracle, MySQL ve PostgreSQL
• Ödün: Bu sistemler, bölünme toleransına sahip değildir. Ağ kesintisi durumunda, sistem çökebilir.

2. AP (Availability and Partition Tolerance)

• Bu sistemler, her zaman erişilebilir ve ağ bölünmelerine karşı dayanıklıdır. Yani herhangi bir ağ kesintisinde bile sisteme erişim mümkündür ve sistem isteklere yanıt vermeye devam eder.
• Örnek: CouchDB, Apache Cassandra, Amazon DynamoDB
• Ödün: Tutarlılık bazen göz ardı edilir. Yani tüm düğümlerde her zaman en güncel veri olmayabilir ve veri tutarsızlıkları meydana gelebilir. Bunlar genellikle “nihai tutarlılık” (eventual consistency) ile çözülür.

3. CP (Consistency and Partition Tolerance)

• Bu sistemler, ağ bölünmelerine karşı dayanıklıdır ve tutarlılık sağlarlar. Yani ağ kesintisi durumunda bile çalışmaya devam edebilir ve veri tutarlılığını koruyabilirler.
• Örnek: Google Cloud Spanner, CockroachDB, YugabyteDB
• Ödün: Ağ bölünmeleri durumunda, AP sistemlerinden farklı olarak, tutarlılığı ön planda tutarlar. Bu nedenle erişilebilirlik bazen göz ardı edilebilir ve sistem, tüm isteklere hızlı bir şekilde yanıt veremeyebilir.

CAP ve CockroachDB

CockroachDB, tutarlı ve bölünme toleranslı (CP) bir sistemdir. Bu kapsamda ağ bölünmesi durumunda, tutarsız sonuçlara yol açabilecek herhangi bir işlem yerine sistemi kullanılamaz hale getirmeyi tercih etmektedir. CockroachDB, "Yüksek Erişilebilirlik" [High Availability (HA)] özelliği de taşımaktadır. Yüksek erişilebilirlik, CAP teoremindeki erişilebilirlikten farklıdır.

CAP teoreminde erişilebilirlik kesin bir yargı içermektedir; sisteme erişim ya vardır ya da yoktur. HA’da ise erişilebilirlik yüzdelik (ör. %99.999 erişilebilirlik) olarak ifade edilmektedir. CockroachDB’nin CP ve HA olması durumunda; sunucuların yarısından fazlası birbirleriyle iletişim kurabiliyorsa, işlemlerin devam edebileceği anlamına gelmektedir. Örneğin, üç veri merkezine dağıtılmış bir sistemde; bir bağlantı kesilirse, diğer iki veri merkezi birkaç saniyelik kesintiyle normal işlem yapmaya devam edebilmektedir.

CockroachDB

CockroachDB, yüksek erişilebilirlik, ölçeklenebilirlik ve güvenilir veri tutarlılığı sağlamayı hedefleyen, dağıtılmış bir SQL veri tabanıdır.

• Yatay Ölçeklenebilirlik: Kolayca düğüm/sunucu ekleyerek ve çıkararak ölçeklenebilir.
• Yüksek Erişilebilirlik: Sunucu arızalarına dayanıklı ve sürekli erişilebilir.
• Merkezi Olmayan (Masterless) Yapı: Tüm düğümleri eşittir, her biri okuma ve yazma işlemleri için kullanılabilir.
• Küresel (Global) Dağılım: Veriler coğrafi olarak farklı lokasyonlarda tutulabilir. Bu sayede verilere yakınlık prensibiyle düşük gecikme süresi sağlayabilir.
• Otomatik Parçalama (Sharding): Veri tabanı, verileri birden çok düğüm arasında otomatik olarak bölümlere (shard) ayırır. Bu, okuma ve yazma işlemlerini yüksek derecede ölçeklenebilir kılar.
• Otomatik Failover: Bir düğüm arızalanırsa, işlemler otomatik olarak diğer düğümlere yönlendirilir. Manuel müdahaleye gerek kalmaz.
• ACID Uyumlu İşlemler: Güçlü veri tutarlılığı sağlar ve veri bütünlüğünü korur.
• SQL Tabanlı Sorgulama: Standart SQL sorgularını destekler. Bu durum mevcut uygulamalar ve araçlar ile kolay entegrasyon sağlar.

CockroachDB, verilerin tutarlılığını sağlamak ve dağıtık işlemleri koordine etmek için raft algoritmasını kullanmaktadır.

Raft Algoritması

Raft, dağıtılmış sistemlerde güçlü tutarlılık ve veri bütünlüğü sağlamak için tasarlanmış bir consensus (ortak karar) algoritmasıdır.

Peki, raft algoritması nasıl çalışır? Esas olarak üç ana rol vardır:

1. Lider: Sistemdeki tüm değişiklikleri yönetir ve tüm veri değişikliklerinin diğer düğümlere (takipçilere) uygulanmasını sağlar. Herhangi bir veri değişikliği talebi önce lider tarafından alınır ve ardından takipçilere replike edilir.
2. Takipçi (Follower): Lider tarafından gönderilen veri değişikliklerini kabul eder ve uygular. Takipçiler, liderin çöktüğünü veya erişilemez olduğunu algılarsa, yeni bir lider seçimi başlatılabilir.
3. Aday (Candidate): Lider çökerse veya belirli bir zaman aşımına uğrarsa, takipçilerden bazıları liderlik için aday olabilirler.

Raft, veri tutarlılığını şu özellikleriyle sağlar:

• Log Replikasyonu: Lider, değişiklikleri bir loga yazar ve bu logu takipçilere gönderir. Takipçiler, logdaki değişiklikleri kendi kopyalarına uygulayarak veri tabanını güncel tutar.
• Lider Seçimi: Lider çöktüğünde veya belirli bir süre içinde iletişim kurmadığında, bir veya birden fazla takipçi aday olur ve diğer düğümlerden lider olmak için oy ister. En çok oyu alan düğüm yeni lider olur.

Şekil 3’te görülen örnekte, timeout süresi en kısa olup en fazla loga sahip olan üç numaralı düğüm yeni lider seçilir.

• Güvenlik: Raft, yanlış bir düğümün lider olarak seçilmesini engelleyen ve yalnızca en güncel verilere sahip düğümlerin yeni lider olabileceğini garantileyen mekanizmalar içerir.
  • Log Eşleştirme Prensibi: Bir adayın lider olabilmesi için, en güncel log girdisine sahip olması gerekir. Bu, lider seçilen düğümün tüm önemli verilere sahip olduğunu garanti eder.
  • Log Ekleme Kuralı: Lider, loga yalnızca yeni girdiler ekleyebilir; mevcut girdileri silmez veya değiştirmez. Bu, veri tutarlılığını korur.
  • Seçim Güvenliği: Aynı termde (“term” kavramı, liderlik dönemlerini tanımlamak için kullanılır) yalnızca bir lider seçilebilir, bu da sistemde birden fazla liderin olmasını önler.

Bölümleme (Partitioning)

Verileri bölmek (Data partitioning), bir uygulamaya ait verileri ayrı parçalara veya bölümlere (partition) ayırma işlemini ifade eder. Bu bölümler, ayrı ayrı depolanabilir, erişilebilir ve yönetilebilir.

CockroachDB, verileri otomatik olarak bölümlere ayırır. Bu özelliğini; veri tabanının performansını artırmak, ölçeklenebilirliği sağlamak ve yüksek erişilebilirlik elde etmek için kullanılır.

Genel olarak veriler, yatay ve dikey olarak bölünür. Tablo 2’deki verileri iki yöntemle de bölebiliriz.

Dikey Bölümleme (Vertical Partitioning)

Dikey bölümleme, tablonun sütun temelli bölündüğü durumdur. Burada “balance” sütunu çok sık güncelleniyorsa, ancak “username” ve “city” sütunları nispeten sabitse, tabloyu dikey olarak bölmek ve yüksek performanslı bir sunucuda Partition 2’yi bulundurmak mantıklı olabilir. Diğer yandan, Partition 1 verisi, kullanıcı tarafından daha az kullanıldığı için daha düşük performanslı makinelerde depolanabilir.

Yatay Bölümleme (Horizontal Partitioning)

Yatay bölümleme, tablonun satırlara göre bölündüğü durumdur. Tablo 2’deki örnekte 10001 adet veri bulunmaktadır. Bu veriler 2 partition’a 1-500 ve 501-10001 olacak şekilde yatay olarak bölünmüştür.

CockroachDB, performansı ve ölçeklenebilirliği artırmak amacıyla genellikle tabloları birden fazla sunucuya yatay olarak böler, bu işleme sharding denir. Bu sayede artan yük ve talepler karşılanır, yüksek erişilebilirlik sağlanır ve hata durumlarında sistem kendini iyileştirebilir.

Ayrıca, bölümleme işlemlerini kendimiz de yönetebiliriz ancak çoğu zaman buna gerek yoktur. (Detaylı bölümleme özellikleri ücretli olarak sunulmaktadır.)

Indeks Yönetimi

1. Veri Dağıtımı:
   • CockroachDB, verileri “range” adı verilen birimlere böler. Her range, bir tablonun satırlarını içeren bir veri aralığıdır.
   • Bu rangeler, bir Consistent Hashing algoritması kullanılarak otomatik olarak düğümler (node) arasında dağıtılır. Bu, yükün eşit olarak dağılmasını sağlar.
   • Her range, belirli bir veri güvenilirliği ve yüksek erişilebilirlik sağlamak için birden çok düğümde çoğaltılır (replicate). Raft consensus algoritması, bu replikalar arasındaki tutarlılığı ve senkronizasyonu sağlar.
2. Indexleme:
   • CockroachDB, SQL tabanlı bir veri tabanı olduğu için, verileri hızlıca sorgulayabilmek için B-Tree benzeri yapıları kullanır.
   • İlk oluşturulduğunda her tablo için birincil anahtar üzerinde bir index oluşturulur. İlave indexler, sorgu performansını iyileştirmek için manuel olarak oluşturulabilir.
3. Veri Bulma:
   • Bir düğüm, bir sorgu aldığında, sorgunun hangi rangeleri ilgilendirdiğini belirlemek için içinde “range descriptor” denilen metadata’yı kullanır. Bu descriptor, range’nin hangi anahtar aralığını kapsadığı ve hangi düğümlerde replikalarının bulunduğu bilgisini içerir.
   • Eğer sorgulanan veri, o düğümde mevcut değilse, sorgu ilgili düğüme yönlendirilir.
4. Sorgu Yürütme:
   • Sorgular, “gateway” düğümünde başlatılır. Bu düğüm, sorguyu parçalara ayırır ve gerekli olan her range için alt sorgular oluşturur.
   • Her alt sorgu, ağ üzerinde uygun düğümlere dağıtılır. Bu düğümler, kendi local rangeleri üzerinde sorguyu çalıştırır.
   • Sonuçlar gateway düğümüne geri gönderilir ve orada birleştirilerek son kullanıcıya iletilir.
5. Ölçeklenebilirlik ve Yüksek Erişilebilirlik:
   • CockroachDB, veri dağıtımını ve çoğaltmayı otomatik olarak yönetir, böylece sistem ölçeklendiğinde ya da düğümler arızalandığında bile veri erişimi sağlanmaya devam eder.
   • Yeni düğümler eklendiğinde, veri otomatik olarak yeniden dengelenir ve yük yeni duruma göre dağıtılır.

CockroachDB ve PostgreSQL

CockroachDB, PostgreSQL'in çoğu SQL dil özelliğini, veri tiplerini ve sorgularını destekler. Bu uyumluluk, PostgreSQL'den CockroachDB'ye geçişi kolaylaştırır, böylece mevcut PostgreSQL sorguları ve veri tabanı yapıları genellikle doğrudan veya minimal değişikliklerle CockroachDB'ye taşınabilir. (CockroachDB’nin desteklediği SQL özelliklerine buradan erişebilirsiniz.)

Desteklenmeyen SQL Özellikleri

1. XML Fonksiyonları: xmlparse, xmlserialize, xpath, xmlelement vb.
2. Saklı Yordamlar (Stored Procedures): CockroachDB, saklı yordamlar yerine kullanıcı tanımlı fonksiyonları (UDFs) destekler. Saklı yordamlar, karmaşık iş mantığını ve işlemleri veri tabanı seviyesinde kapsüllemek için daha güçlüdür. UDF’ler daha basit işlemler için uygundur, ancak karmaşık işlemler için sınırlı olabilir.
3. Tetikleyiciler & Olaylar (Triggers & Events): CockroachDB, veri tabanı seviyesinde tetikleyici desteği sunmaz; bunlar uygulama mantığına entegre edilmelidir. PostgreSQL’de tetikleyiciler, veri tabanındaki belirli olaylara (örneğin bir tabloya ekleme, güncelleme veya silme işlemi) yanıt olarak otomatik şekilde çalıştırılan fonksiyonlardır. Bu, veri bütünlüğünü korumak, otomatik işlemleri gerçekleştirmek veya karmaşık iş mantığını uygulamak için kullanılabilir.
4. Birincil Anahtarı Kaldırmak (Drop Primary Key): CockroachDB’de her tablonun birincil anahtarı olmak zorundadır. Tek bir işlem (transaction) içinde eskisini kaldırıp yenisini eklemek mümkündür.
5. Sütun Bazlı Ayrıcalıklar (Column-Level Privileges): PostgreSQL’in sütun düzeyinde ayrıcalıklar özelliği, daha ince ayarlı bir güvenlik kontrolü sağlar. Bu özellik, belirli sütunlara erişimi kısıtlamak veya belirli kullanıcılara sadece bazı sütunlara erişim izni vermek için kullanılabilir. CockroachDB’de bu özelliğin bulunmaması, hassas verilerin ve detaylı güvenlik gereksinimlerinin olduğu durumlarda problem yaratabilir.
6. Bir Tablodan Tek Bir Bölümü Kaldırmak: CockroachDB’nin dağıtılmış mimarisi, veri dağılımını ve replikasyonunu bölümler arasında otomatik olarak yönetir. Bölümlerin ayrı ayrı silinmesi, veri bütünlüğü ve sorgu performansı üzerinde beklenmeyen etkilere yol açabilir. Bu nedenle, CockroachDB bütünsel bir bölümleme yönetimi sunar. Ayrıca mevcut bölümleri yeniden yapılandırmak ve verileri farklı bölümlere taşımak mümkündür.
7. XA Sözdizimi (XA Syntax)
8. Şablondan (Template) Veri Tabanı Oluşturma
9. Yabancı Veri Sarıcıları (FDW - Foreign Data Wrappers)

Bu farklılıklar, CockroachDB’nin öncelikle dağıtılmış mimariye ve ölçeklenebilirliğe odaklanmasından kaynaklanmaktadır. PostgreSQL’e özgü bu özelliklerin eksikliği, CockroachDB’nin belirli kullanım senaryoları için uygun olmadığı anlamına gelebilir. (Desteklenmeyen özelliklere buradan erişebilirsiniz.)

Yedekleme ve Kurtarma (Backup & Recovery)

• Tam Yedekleme (Full Backup), veri tabanının bütün durumunun bir kopyasını oluşturur.

• Manuel Yedekleme, otomatikleştirilmiş bir süreç olmadan, elle veri yedekleme komutlarının çalıştırılmasıdır.

• Artımlı Yedekleme (Incremental Backup), en son ki yedeklemenin ardından, sadece değişen verilerin yedeklendiği yöntemdir.

• Zamanlanmış Yedekleme (Scheduled Backup), verilerin önceden tanımlanmış zamanlarda otomatik olarak kopyalanması için planlanan bir yedekleme işlemidir. PostgreSQL, zamanlanmış yedeklemeleri doğrudan desteklemez, ancak işletim sistemi seviyesinde zamanlanmış görevler (cron jobs) ile bu işlevsellik dolaylı olarak sağlanabilir.

• Coğrafi Olarak Dağıtılmış Yedekleme (Geographically Distributed Backup), verilerin felaket ve arıza durumlarında erişilebilirliğini sağlamak için farklı konumlarda yedeklerinin oluşturulması işlemidir.

• Zamana Bağlı Veri Kurtarma [Point-in-Time Recovery (PITR)], veri tabanını belirli bir tarih ve saate kadar olan verileri içerecek şekilde geri yükleyebilme işlemidir.

• Bulut Depolama Entegrasyonu (Cloud Storage Integration), veri yedekleme, saklama ve erişim için sistemlerin ve uygulamaların bulut tabanlı depolama hizmetleriyle birleştirilmesi sürecidir.

Local Ortamda PostgreSQL’den CockroachDB’ye Geçiş

Şimdi, hali hazırda PostgreSQL ile çalışan bir uygulamamızı CockroachDB’ye nasıl geçirebileceğimizi ve karşılaşabileceğimiz sıkıntıları inceleyelim.

Docker ile CockroachDB Kurulumu

Adım 1: Docker kullandığımız bir projede, docker-compose.yaml dosyasına CockroachDB düğümlerini eklememiz gerekir.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
roach1:
    image: cockroachdb/cockroach:v23.1.13
    hostname: roach1
    command: start --insecure --join=roach1,roach2,roach3
    volumes:
      - ~/DockerVolumes/tedarik/cockroach/node1:/cockroach/cockroach-data
      - ./create-dbs.sql:/docker-entrypoint-initdb.d/create-dbs.sql
    ports:
      - "26257:26257"
      - "8082:8080"
    restart: always

roach2:
    image: cockroachdb/cockroach:v23.1.13
    hostname: roach2
    command: start --insecure --join=roach1,roach2,roach3
    volumes:
      - ~/DockerVolumes/tedarik/cockroach/node2:/cockroach/cockroach-data
    restart: always

roach3:
    image: cockroachdb/cockroach:v23.1.13
    hostname: roach3
    command: start --insecure --join=roach1,roach2,roach3
    volumes:
      - ~/DockerVolumes/tedarik/cockroach/node3:/cockroach/cockroach-data
    restart: always

Bu yapılandırmadan, üç tane CockroachDB düğümü (roach1, roach2, roach3) oluşur.

• image: cockroachdb/cockroach:v23.1.13: CockroachDB’nin Docker imajını ve kullanılacak olan sürümünü belirtir.
• hostname: konteynerin ağ içinde tanımlanacağı adı belirler. Docker ağında konteynerler arası iletişimde kullanılır.
• ports: Konteyner ve localimiz arasındaki port yönlendirmelerini tanımlar.
  • "26257:26257": CockroachDB’nin varsayılan SQL portunu (26257) localimizdeki aynı porta yönlendirir.
  • "8082:8080": CockroachDB’nin web arayüzü için 8080 portunu localimizdeki 8082 portuna yönlendirir.
• volumes: Konteyner içindeki dosya sistemini localimiz ile eşleştirir.
  • ~/DockerVolumes/tedarik/cockroach/node1:/cockroach-data: Veri tabanı verilerini saklamak için localimizdeki bir dizini konteyner içindeki /cockroach-data dizinine bağlar.
  • ./create-dbs.sql:/docker-entrypoint-initdb.d/create-dbs.sql: İlk başlatma sırasında çalıştırılacak SQL scriptini (create-dbs.sql) konteyner içindeki belirli bir konuma yerleştirir.
• command: start --insecure --join=roach1,roach2,roach3: CockroachDB’nin güvensiz (insecure) modda birden fazla düğüm ile başlatılmasını sağlar.
• restart: always: Konteyner herhangi bir nedenle durdurulduğunda otomatik olarak yeniden başlatılmasını sağlar.

Adım 2: Docker-compose.yaml dosyasındaki değişiklikleri tamamladıktan sonra docker compose up -d komutunu terminalde çalıştırarak konteynerlerin başlatılmasını sağlarız.

Adım 3: Cockroach kümesi (clusterı) ilk kez oluştuğu için, bir sefere mahsus başlatılması gerekir. (Bunu herhangi bir düğümün terminalinden yapabiliriz.)

1
cockroach init --insecure --host=roach1

Adım 4: CockroachDB kullanıma hazır hale gelir ve localimizde 8082 portuna giderek CockroachDB arayüzüne ulaşabiliriz.

Adım 5: Veri tabanı bağlantısını Şekil 5’teki gibi oluşturabiliriz. (Güvensiz modda başlattığımız için şifre girmemize gerek yoktur ve defaulttaki kullanıcı adı “root”tur.)

Adım 6: Uygulamamızda kullanacağımız veri tabanlarını yaratmak için roach1’e volume olarak eklediğimiz create-dbs.sql dosyasını düğümlerden birinde çalıştırmamız gerekir.

• create-dbs.sql dosyası aşağıdaki gibidir:

  1
  create database mydb;
  

• Düğümde Çalıştırılması Gereken Komut:

  1
  cockroach sql --insecure --host=roach1 --execute="$(cat /docker-entrypoint-initdb.d/create-dbs.sql)"
  

Spring Boot Uygulamasının CockroachDB ile Bağlanması

Uygulamamızın properties dosyasındaki datasource ayarlarını, CockroachDB ayarlarımıza uygun olacak şekilde güncellememiz gerekir.

1
2
spring.datasource.url=jdbc:postgresql://localhost:26257/mydb
spring.datasource.username=root

Karşılaşılan Problemler

Uygulamamız ayağa kalkarken mevcuttaki SQL komutlarımızda bazı uyumsuzluklar ortaya çıkabilir. Karşılaştığımız sorunlar ve çözümler aşağıdaki gibidir:

1. Sorun: Birincil anahtar olarak tanımlanmış alan not null kısıtlamasına (constraint) sahip olmadığı için hata alınmaktadır.

Çözüm: Alanı not null olarak tanımlamak gerekir.

2. Sorun: CockroachDB’nin default hali ALTER COLUMN TYPE komutunu desteklemez. Sütun tipini değiştirmek, dağıtılmış bir veri tabanında karmaşık bir işlemdir çünkü bu değişiklik kümenin her düğümünde tutarlı ve eşzamanlı olarak gerçekleştirilmelidir. Bu tür bir değişiklik sistemin performansını etkileyebilir, bu nedenle dikkatli yapılmalıdır.

Çözüm: Belirledikleri enable_experimental_alter_column_type_general flagini ALTER COLUMN TYPE içeren sqli çalıştırmadan önce true olarak setlersek, istediğimiz değişikliği yapabiliriz.

1
SET enable_experimental_alter_column_type_general = true

3. Sorun: PostgreSQL kullanırken tablomuz ilk yaratıldığında herhangi bir birincil anahtar oluşturulmamış ve daha sonrasında bu tabloya bir birincil anahtar eklenmiş. CockroachDB, bir tabloyu oluştururken her zaman birincil anahtar bulundurmak zorunda olduğu için böyle bir durumda kendisi default olarak rowid isminde bir sütun ekleyerek bunu birincil anahtar olarak tanımlar. Bu nedenle yeni bir birincil anahtar tanımlamak istediğimizde birden çok birincil anahtar tanımlanamayacağı ile ilgili hata alırız.

Çözüm: Desteklenmeyen SQL özellikleri kısmındaki 7. maddede anlattığımız gibi yeni bir birincil anahtar tanımlaması yapacağımızda aynı işlem (transaction) içinde önce mevcut birincil anahtarı kaldırmalı ve sonrasında yenisini eklemeliyiz.

1
2
3
4
5
BEGIN;
ALTER TABLE alt_kurulusa_ait_yetkiler DROP CONSTRAINT "eski_pkey";
ALTER TABLE alt_kurulusa_ait_yetkiler ADD CONSTRAINT "yeni_pkey" PRIMARY KEY (id);
COMMIT;

Böylece PostgreSQL’den CockroachDB’ye geçerken yaşanabilecek zorluklardan bazılarını görmüş olduk.

CockroachDB Ne Zaman Kullanılmalı?

1. Büyük Ölçekli Projeler: Büyük ölçekli projeler, genellikle yüksek hacimli veri işleme ve birden fazla işlemi eş zamanlı olarak yönetme kapasitesi gerektirir. CockroachDB, veri dağıtımını ve çoğaltmayı otomatik olarak yönetir, böylece büyük miktarda veri üzerinde çalışırken yüksek performans ve güvenilirlik sağlar.
2. Küresel (Global) Dağıtım Gerektiren Projeler: CockroachDB, küresel dağıtım için optimize edilmiş bir veri tabanıdır; verileri coğrafi olarak dağıtarak, her kullanıcıya en yakın sunucudan hizmet verilmesini sağlar. “Geo-partitioning” özelliği ile verileri belirli bölgelerde saklayarak yerel yasalara uyumu ve düşük gecikme süreleri garanti eder. Bu yaklaşım, küresel ölçekte yüksek kullanılabilirlik ve hızlı veri erişimi sunar. Bu nedenle, çok bölgeye yayılmış uygulamalar için idealdir.
3. Yüksek Erişilebilirlik Gerektiren Projeler: Kesintisiz hizmet sunması gereken uygulamalar için CockroachDB, hata toleransı ve otomatik failover özellikleriyle yüksek erişilebilirlik sağlar. Bu özellikler, bir düğüm veya veri merkezi çöktüğünde bile uygulamanın çalışmaya devam etmesini sağlar.
4. Ölçeklenebilirlik İhtiyacı Olan Projeler: İş yükünün ve veri hacminin zaman içinde değişebileceği projeler için CockroachDB, ölçeklenebilir bir yapı sunar. Yeni düğümler kolayca eklenebilir ve sistem veri dağıtımını ve yük dengesini otomatik olarak yeniden düzenleyerek ölçeklenmeye izin verir.

CockroachDB Ne Zaman Kullanılmamalı?

1. Küçük Ölçekli Projeler: CockroachDB’nin sunmuş olduğu karmaşıklık ve yönetim gereksinimleri, genellikle küçük ölçekli projeler için fazla olabilir, bu durumda daha basit bir veri tabanı kullanılabilir.
2. Gelişmiş Analitik ve Büyük Veri İşlemleri İçeren Projeler: CockroachDB, çevrim içi işlem işleme (OLTP) uygulamaları için uygundur. Ancak büyük veri analitiği veya karmaşık veri depolama gibi gelişmiş analitik işlemler içeren uygulamalar için uygun değildir.
   • OLTP (Online Transaction Processing), gerçek zamanlı işlem işleme sistemlerini ifade eder. Bu tür sistemler, veri tabanı güncellemeleri, ekleme ve silme gibi kısa, hızlı işlemleri yönetmek üzere tasarlanmıştır. Örnek olarak, perakende satış noktası sistemleri, bankacılık işlemleri veya çevrim içi rezervasyon sistemleri sayılabilir.
   • OLAP (Online Analytical Processing), büyük veri kümeleri üzerinde karmaşık sorgular yapmak için tasarlanmıştır. Bu sistemler, genellikle veri ambarlarında kullanılır ve veri analizi, raporlama veya iş zekâsı uygulamaları için uygundur. Örnek olarak, finansal raporlama ve büyük veri analizi verilebilir.
3. Belge Tabanlı Veri Modelleri Kullanan Projeler: Belge tabanlı bir veri tabanı gerektiğinde, örneğin MongoDB gibi, CockroachDB bu spesifik ihtiyacı tam anlamıyla karşılayamayabilir.

Sonuç

Bu yazımızda; CockroachDB'nin yapısına, CAP teoremi ile ilişkisine, sunduğu özelliklere, kullandığı algoritmaya, hangi tür projeler için uygun olup olmadığına, PostgreSQL ile olan uyumluluk ve uyumsuzluklarına, CockroachDB’ye geçerken karşılaşabileceğimiz zorluklara ve çözümlerine odaklandık. CockroachDB'nin bu avantaj ve dezavantajlarını göz önünde bulundurarak, projelerimizin büyüklüğü ve ihtiyaçlarına uygun olacak şekilde veri tabanı seçimi yapabiliriz.

Okuduğunuz için teşekkür ederiz.

Kaynakça

• https://www.cockroachlabs.com/
• https://www.youtube.com/watch?v=IujMVjKvWP4&t=3s
• https://www.linkedin.com/pulse/cap-theorem-distributed-systems-francis-mutiso/
• ChatGPT