Dağıtık SQL’in ne olduğunu, Spanner, CockroachDB ve YugabyteDB arasındaki farkları ve hangi gerçek dünya kullanım durumlarının çok bölgeli, güçlü tutarlı SQL gerektirdiğini öğrenin.
“Dağıtık SQL”, tablolar, satırlar, join’ler, işlemler ve SQL gibi tanıdık bir ilişkisel veritabanı deneyimi sunan, ancak birçok makine (ve sıklıkla birden fazla bölge) üzerinde çalışan ve yine de tek bir mantıksal veritabanı gibi davranacak şekilde tasarlanmış bir veritabanıdır.
Bu kombinasyon önemlidir çünkü üç şeyi aynı anda sağlamaya çalışır:
Klasik bir RDBMS (PostgreSQL veya MySQL gibi) genellikle her şeyin tek bir birincil düğümde yaşadığı durumda çalıştırması en kolay olanıdır. Okumaları replika ile ölçeklendirebilirsiniz, ancak yazmaları ölçeklendirmek ve bölgesel kesintilerden kurtulmak genellikle ek mimari (sharding, manuel failover ve dikkatli uygulama mantığı) gerektirir.
Birçok NoSQL sistemi tam tersini yaptı: öncelikle ölçek ve yüksek kullanılabilirlik, bazen tutarlılık garantilerini gevşeterek veya daha basit sorgu modelleri sunarak.
Dağıtık SQL ise ortada bir yol hedefler: ilişkisel modeli ve ACID işlemleri korur, ancak büyümeyi ve hataları otomatik olarak yönetmek için veriyi dağıtır.
Dağıtık SQL veritabanları şu tür sorunlar için inşa edilmiştir:
Bu nedenle Google Spanner, CockroachDB ve YugabyteDB gibi ürünler genellikle çok bölgeli dağıtım ve sürekli hizmet ihtiyaçları için değerlendirilir.
Dağıtık SQL otomatik olarak “daha iyi” değildir. Daha fazla hareketli parça ve farklı performans gerçekleri (ağ atlamaları, konsensüs, bölge arası gecikme) kabul ediyorsunuz, karşılığında dayanıklılık ve ölçek elde ediyorsunuz.
Eğer iş yükünüz tek bir iyi yönetilen veritabanına sığıyorsa ve basit bir replika kurulumu iş görüyorsa, geleneksel bir RDBMS daha basit ve daha ucuz olabilir. Dağıtık SQL, alternatifin özel sharding, karmaşık failover veya çok bölgeli tutarlılık ve çalışma süresi gerektiren iş gereksinimleri olduğu durumlarda kendini haklı çıkarır.
Dağıtık SQL, tanıdık bir SQL veritabanı hissi vermeyi hedeflerken veriyi birçok makineye (ve sıklıkla birçok bölgeye) dağıtır. Zor kısım, birçok bilgisayarı koordine edip güvenilir tek bir sistem gibi davranmalarını sağlamaktır.
Her veri parçası genellikle birkaç düğüme kopyalanır (replikasyon). Bir düğüm arızalanırsa, başka bir kopya okumaları sunmaya ve yazmaları kabul etmeye devam edebilir.
Replikaların ayrışmaması için Dağıtık SQL sistemleri konsensüs protokollerini kullanır—en yaygın olarak Raft (CockroachDB, YugabyteDB) veya Paxos (Spanner). Üst düzeyde konsensüs şunu ifade eder:
Bu “çoğunluk oyu” size güçlü tutarlılık verir: bir işlem taahhüt edildiğinde, diğer istemciler daha eski bir veri görmez.
Hiçbir tek makine her şeyi saklayamaz, bu yüzden tablolar daha küçük parçalara bölünür—shard/partition olarak (Spanner bunlara splits, CockroachDB ranges, YugabyteDB tablets der).
Her partition konsensüs ile çoğaltılır ve belirli düğümlere yerleştirilir. Yerleştirme rastgele değildir: politikalarla etkileşim kurabilirsiniz (örneğin AB müşterilerini AB bölgelerinde tutmak veya sıcak partitionları daha hızlı düğümlerde bulundurmak). İyi yerleştirme ağ üzerindeki yolculukları azaltır ve performansı daha öngörülebilir kılar.
Tek düğümlü bir veritabanında bir işlem genellikle yerel disk çalışmasıyla kabul edilebilir. Dağıtık SQL’de bir işlem birden fazla partition’a dokunabilir—farklı düğümlerde olabilir.
Güvenli bir şekilde commit etmek genellikle ek koordinasyon gerektirir:
Bu adımlar ağ turu ekler; bu yüzden dağıtık işlemler genellikle gecikme ekler—özellikle veri bölgeler arası olduğunda.
Dağıtımlar bölgeler arasında olduğunda sistemler işlemleri kullanıcılara “yakın” tutmaya çalışır:
Bu çok bölgeli denge işinin özü: yerel tepki sürelerini optimize edebilirsiniz, ama uzun mesafelerde güçlü tutarlılık hala ağ maliyeti ödetecektir.
Dağıtık SQL’e yönelmeden önce temel ihtiyaçlarınızı kontrol edin. Tek bir birincil bölgeniz, öngörülebilir yükünüz ve küçük bir operasyon ekibiniz varsa, geleneksel bir ilişkisel veritabanı (veya yönetilen Postgres/MySQL) genellikle hızlıca özellik sunmanın en basit yoludur. Tek bölge kurulumunu replika, önbellekleme ve dikkatli şema/index çalışmasıyla uzun süre idare edebilirsiniz.
Dağıtık SQL’i ciddi şekilde düşününce değer kazandığı durumlar:
Dağıtık sistemler karmaşıklık ve maliyet ekler. Dikkatli olun eğer:
İki veya daha fazlasına “evet” diyorsanız, dağıtık SQL değerlendirmeye değer:
Dağıtık SQL “her şeyi aynı anda al” gibi görünür, ama gerçek sistemler seçim yaptırır—özellikle bölgeler birbirleriyle güvenilir konuşamıyorsa.
Ağ bölünmesini bölge bağlantılarının kesildiği veya güvensiz olduğu an olarak düşünün. O anda bir veritabanı öncelik verebilir:
Dağıtık SQL sistemleri genellikle işlemler için tutarlılığı tercih edecek şekilde inşa edilir. Takımlar bunu genellikle ister—ta ki bir bölünme bazı işlemlerin beklemesi veya başarısız olması gerektiğini görene kadar.
Güçlü tutarlılık demek, bir işlem commit olduktan sonra sonraki her okumanın o commit edilmiş değeri döndürmesidir—“bir bölgede oldu ama diğerinde olmadı” gibi durumlar olmaz. Bu şu durumlar için kritiktir:
Eğer ürün vaadiniz “onayladığımızda gerçek” ise, güçlü tutarlılık bir özellik, lüks değil.
İki pratik davranış önemlidir:
Bölgeler arası güçlü tutarlılık genellikle konsensüs gerektirir (çoğunluk replikanın commit onayı). Kıtalar arasındaki yazmalar her seferinde on, yüz milisaniyeler ekleyebilir. Basitçe: coğrafi güvenlik ve doğruluk genellikle daha yüksek yazma gecikmesi demektir—yine de verinin nerede yaşadığını ve işlemlerin nerede commit edileceğini dikkatle seçerseniz bunu azaltabilirsiniz.
Google Spanner, esas olarak Google Cloud’da yönetilen bir hizmet olarak sunulan dağıtık SQL veritabanıdır. Tek bir mantıksal veritabanı isteyen, veriyi düğümler ve bölgeler arasında çoğaltan çok bölgeli dağıtımlar için tasarlanmıştır. Spanner iki SQL lehçesi seçeneği sunar—yerel GoogleSQL ve PostgreSQL uyumlu bir lehçe—bu yüzden taşınabilirlik, seçtiğiniz lehçeye ve uygulamanızın hangi özelliklere bağımlı olduğuna bağlı olarak değişir.
CockroachDB, PostgreSQL’e aşina ekiplerin rahat hissedebileceği bir dağıtık SQL veritabanı olmayı hedefler. PostgreSQL wire protokolünü kullanır ve PostgreSQL tarzı SQL’in büyük bir alt kümesini destekler, ancak birebir Postgres yerine geçmez (bazı uzantılar ve kenar durum davranışları farklıdır). Yönetilen bir hizmet (CockroachDB Cloud) olarak veya kendi altyapınızda self-hosted çalıştırabilirsiniz.
YugabyteDB, PostgreSQL uyumlu bir SQL API (YSQL) ve ek olarak Cassandra uyumlu bir API (YCQL) sunan dağıtık bir veritabanıdır. CockroachDB gibi, Postgres-benzeri geliştirme ergonomisini isterken düğümler ve bölgeler arasında ölçeklenmek isteyen ekipler tarafından değerlendirilir. Hem self-hosted hem de yönetilen (YugabyteDB Managed) seçenekleri vardır.
Yönetilen hizmetler genellikle operasyonel işi azaltır (güncellemeler, yedekler, izleme entegrasyonları), self-hosting ise ağ, örnek tipleri ve verinin fiziksel nerede çalıştığı üzerinde daha fazla kontrol verir. Spanner genellikle GCP üzerinde yönetilen olarak kullanılır; CockroachDB ve YugabyteDB hem yönetilen hem de self-hosted olarak, çoklu bulut ve on-prem seçeneklerinde görülür.
Üçü de “SQL” konuşur, ama günlük uyumluluk lehçe seçimine (Spanner), Postgres özellik kapsamına (CockroachDB/YugabyteDB) ve uygulamanızın belirli Postgres uzantılarına veya işlem semantiklerine bağlıdır.
Planlamaya vakit ayırın: sorgularınızı, migration’larınızı ve ORM davranışınızı erken test edin; drop-in eşdeğerlik varsaymayın.
Dağıtık SQL için klasik bir uyum B2B SaaS ürünüdür, müşterileri Kuzey Amerika, Avrupa ve APAC’e dağılmış—destek araçları, İK platformları, gösterge panoları veya pazar yerleri gibi.
İş gereksinimi basit: kullanıcılar “yerel uygulama” duyarlılığı istiyor, şirket ise tek mantıksal veritabanı ile her zaman erişilebilirlik istiyor.
Birçok SaaS ekibi şu karışık gereksinimlerle karşılaşır:
Dağıtık SQL, her kiracının birincil verisini belirli bir bölgede veya bölgeler kümesinde tutarak veri yerelleştirmesini temiz şekilde modelleyebilir. Böylece “bölge başına bir veritabanı” karmaşasından kaçınırken uyumluluk gereksinimlerini karşılayabilirsiniz.
Uygulamayı hızlı tutmak için genellikle hedef:
Çünkü bölge arası round trip’ler kullanıcı algısını domine eder. Güçlü tutarlılık olsa bile, iyi yerellik tasarımı çoğu isteğin kıtalararası ağ maliyeti ödememesini sağlar.
Teknik kazanımlar, operasyon yönetilebilir kaldığında anlamlıdır. Küresel SaaS için planlayın:
İyi yapıldığında, dağıtık SQL tek bir ürün deneyimi sunar ama hâlâ yerel hissettirir—mühendis ekibinizi “AB yığını” ve “APAC yığını” olarak bölmek zorunda kalmazsınız.
Finansal sistemlerde “er ya da geç tutarlılık” gerçek para kaybına dönüşebilir. Bir müşteri sipariş verdiğinde, ödeme yetkilendirildiğinde ve bakiye güncellendiğinde, bu adımların tek bir hakikat üzerinde anlaşması gerekir—hemen.
Güçlü tutarlılık kritiktir çünkü iki farklı bölge (veya iki farklı servis) makul bir karar verip daha sonra tutarsızlık yaratırsa yanlış defter oluşur.
Tipik bir iş akışında—sipariş oluştur → fon rezerve et → ödemeyi yakala → bakiye/defteri güncelle—şu garantileri istersiniz:
Dağıtık SQL burada uygundur çünkü düğümler arasında ACID işlemler ve kısıtlar sağlar; bu sayede defter invariant’ları hatalar sırasında bile korunur.
Çoğu ödeme entegrasyonu tekrar denemeye dayanır: zaman aşımı, webhook yeniden denemeleri ve işlerin yeniden işlenmesi normaldir. Veritabanı tekrarları güvenli hale getirmeye yardımcı olmalı.
Pratik yaklaşım, uygulama düzeyinde idempotency anahtarlarını veritabanında benzersizlik kısıtlarıyla eşleştirmektir:
idempotency_key saklayın.(account_id, idempotency_key) gibi benzersiz bir kısıt ekleyin.Böylece ikinci deneme zararsız bir no-op olur, çift çekim oluşmaz.
Satış etkinlikleri ve bordro çalıştırmaları ani yazma patlamaları yaratabilir. Dağıtık SQL ile düğüm ekleyerek yazma verimini artırabilirsiniz; aynı tutarlılık modelini koruyarak.
Anahtar nokta sıcak anahtarları (örn. tek bir tüccar hesabına tüm trafik) planlamak ve yükü yayacak şema desenleri kullanmaktır.
Finansal iş akışları genellikle değiştirilemez denetim izleri, izlenebilirlik (kim/ne/ne zaman) ve öngörülebilir saklama politikaları gerektirir. Belirli düzenlemeleri adlandırmasak bile şu varsayımla ilerleyin: eklenebilir defter girdileri, zaman damgalı kayıtlar, kontrollü erişim ve arşivleme kuralları denetimi bozmayacak şekilde olmalı.
Envanter ve rezervasyon basit görünür ama aynı kıtada olmayan birçok bölge aynı kıtaya hizmet ettiğinde zorlaşır: son konser koltuğu, “sınırlı drop” ürünü veya belirli gece için bir otel odası.
Zor olan kısım müsaitliği okumak değil—aynı öğeyi neredeyse aynı anda iki kişinin talep etmesini önlemektir.
Güçlü tutarlılık olmayan çok bölgeli bir kurulumda, her bölge hafifçe eski verilere dayanarak geçici olarak stokun olduğunu düşünebilir. Farklı bölgelerden iki kullanıcı checkout yaparsa, her ikisi de yerel olarak kabul edilebilir ve daha sonra uzlaşma sırasında çakışma olabilir.
Bu, çapraz bölge aşırı satışın nasıl oluştuğudur: sistem “yanlış” olduğu için değil, geçici olarak farklı gerçekliklere izin verdiği için.
Dağıtık SQL veritabanları burada genellikle tercih edilir çünkü yazma-ağırlıklı tahsislerde tek, yetkili sonucu uygulayabilir—böylece “son koltuk” gerçekten bir kez tahsis edilir.
Hold + confirm: Geçici bir hold (rezervasyon kaydı) bir işlemde konur, ardından ödeme ikinci adımda onaylanır.
Süre sonları: Hold’lar otomatik olarak süresi dolmalı (örn. 10 dakika) ki kullanıcı checkout’ı yarıda bıraktığında envanter sıkışmasın.
Transactional outbox: Bir rezervasyon onaylandığında, aynı işlem içinde bir “gönderilecek olay” satırı yazın; sonra bunu asenkron olarak e-posta, fulfillment veya mesaj kuyruğuna gönderin—böylece “kaydedildi ama onay gönderilmedi” boşluğu olmaz.
Sonuç: İşiniz bölgeler arası çifte tahsisi kaldıramıyorsa, güçlü işlemsel garantiler ürün özelliği haline gelir.
Yüksek kullanılabilirlik (HA), kesinti pahalıysa, öngörülemeyen arızalar kabul edilemezse ve bakımın sıkıcı olmasını istediğinizde Dağıtık SQL için uygundur.
Ama hedef “asla arızalanma” değil—belirli SLO’ları (ör. %99.9 veya %99.99 çalışma süresi) tutturmaktır; düğümler öldüğünde, zonelar karardığında veya güncellemeler uygulanırken bile.
“Her zaman açık”ı ölçülebilir beklentilere çevirin: aylık maksimum kesinti, kurtarma süresi hedefi (RTO) ve kurtarma noktası hedefi (RPO).
Dağıtık SQL sistemleri birçok yaygın arıza sırasında okumaları/yazmaları servis etmeye devam edebilir, ama sadece topoloji SLO’nuzla eşleşirse ve uygulamanız geçici hataları (retry, idempotency) düzgün ele alırsa.
Planlı bakım da önemlidir. Rolling upgrade ve örnek değiştirme, veritabanının liderlik/repikaları etkilenecek düğümlerden uzaklaştırabilmesiyle küme kapatılmadan daha kolay olur.
Çok zone dağıtımlar tek bir AZ/zone arızasından ve birçok donanım hatasından korur, genellikle daha düşük gecikme ve maliyetle. Uyumluluk ve kullanıcı tabanınız çoğunlukla tek bölgedeyse yeterli olur.
Çok bölge dağıtımlar tam bölge arızasından korur ve bölge düzeyinde failover’ı destekler. Tradeoff, güçlü tutarlılık gerektiren işlemler için daha yüksek yazma gecikmesi ve daha karmaşık kapasite planlamasıdır.
Failover’ın anında veya görünmez olduğunu varsaymayın. Hizmetiniz için “failover”ın ne anlama geldiğini tanımlayın: kısa hata artışları mı? salt okunur dönemler mi? birkaç saniyelik artan gecikme mi?
“Game day”ler yapın:
Senkron replika olsa bile yedekler ve geri yükleme tatbikatları yapın. Yedekler operatör hatalarına (kötü migration, yanlışlıkla silme), uygulama hatalarına ve çoğaltılabilecek bozulmalara karşı korur.
Point-in-time recovery (varsa), geri yükleme hızı ve üretime dokunmadan temiz bir ortama geri dönebilme yeteneğini doğrulayın.
Veri yerleşimi gereksinimleri, belirli kayıtların belirli ülke veya bölgede saklanması (ve bazen işlenmesi) gerektiğinde ortaya çıkar.
Bu kişisel veri, sağlık bilgisi, ödeme verisi, devlet işi veya sözleşmeyle yönlendirilen “müşteri sahibi verileri” için geçerli olabilir.
Dağıtık SQL, tek bir mantıksal veritabanını korurken veriyi fiziksel olarak farklı bölgelere koyabildiği için burada sıkça değerlendirilir—uygulama yığını bölgeler bazında tamamen ayrılmak zorunda kalmadan.
Regülatör veya müşteri “veri bölge içinde kalsın” isterse, sadece düşük gecikmeli replika yeterli değildir. Şunları garanti etmeniz gerekebilir:
Bu, konumun birinci sınıf kaygı olduğu mimarilere itebilir.
SaaS’te yaygın desen, kiracı başına veri yerleşimidir. Örneğin: AB müşterilerinin satırları veya partition’ları AB bölgelerine sabitlenir, ABD müşterileri ABD’ye.
Genelde şu üçü birleşir:
Amaç, operasyonel erişim, yedek geri yükleme veya bölge arası replika yoluyla yanlışlıkla yerleşim ihlalini zorlaştırmaktır.
Yerleşim ve uyumluluk yükümlülükleri ülkeye, sektöre ve sözleşmeye göre çok farklıdır ve zamanla değişir.
Veritabanı topolojisini uyumluluk programınızın parçası olarak ele alın ve varsayımları nitelikli hukuk danışmanları ve ilgili denetçilerle doğrulayın.
Yerleşim-dostu topolojiler küresel görünümleri karmaşıklaştırabilir. Müşteri verisi kasıtlı olarak ayrı bölgelerde tutuluyorsa, analiz ve raporlama şunları gerektirebilir:
Pratikte birçok ekip operasyonel iş yüklerini (güçlü tutarlılık, yerleşim farkındalığı) analitikten ayırır: analitik için bölgeye özel warehouse’lar veya kontrollü toplu veri setleri kullanılır.
Dağıtık SQL sizi acı kesintilerden ve bölgesel sınırlamalardan kurtarabilir, ama varsayılan olarak nadiren para tasarrufu sağlar. Önceden planlama, gereksiz “sigorta” için ödeme yapmaktan kaçınmanıza yardımcı olur.
Bütçeler genellikle dört kaleme ayrılır:
Dağıtık SQL sistemleri koordinasyon ekler—özellikle güçlü tutarlı yazmalar için çoğunluk onayı gerektiğinde.
Etkisini tahmin etmenin pratik yolu:
Bu, “yapmayın” demek değil; ama yolculukları ardışık yazmalardan kaçınacak şekilde tasarlamak (batch, idempotent retry, daha az chatty transaction) gerekir.
Kullanıcılarınız çoğunlukla bir bölgede ise, tek bölgeli Postgres iyi replika, güçlü yedekleme ve test edilmiş failover planı ile daha ucuz ve daha basit olabilir—ve hızlıdır.
Dağıtık SQL, gerçekten çok bölgeli yazmalar, sıkı RPO/RTO veya yerleşim farkındalığı gerektiğinde maliyeti haklı çıkarır.
Harcamayı şu şekilde değerlendirin:
Kaçınan kayıp (kesinti + churn + uyumluluk riski) süreklilik primi üzerindeyse, çok bölgeli tasarım haklıdır. Değilse, daha basit başla ve evrimleşme yolu bırakın.
Dağıtık SQL’e geçiş “veritabanını taşımak”tan ziyade verinin ve konsensüsün düğümler (ve muhtemelen bölgeler) arasında dağıldığında iş yükünüzün iyi davrandığını kanıtlamakla ilgilidir. Hafif bir plan sürprizleri önler.
Gerçek acıyı temsil eden bir iş yükü seçin: örn. checkout/booking, hesap oluşturma, defter kaydı.
Başarı metriklerini baştan tanımlayın:
PoC aşamasında daha hızlı ilerlemek isterseniz, sentetik benchmark’lar yerine küçük bir gerçekçi uygulama yüzeyi (API + UI) oluşturmak yardımcı olur. Örneğin ekipler bazen Koder.ai kullanarak chat ile React + Go + PostgreSQL başlangıç uygulaması açıp, sonra veritabanı katmanını CockroachDB/YugabyteDB ile değiştirerek işlem desenlerini, retry’leri ve hata davranışını uçtan uca test ederler. Amaç starter stack değil—fikri “ölçülebilir iş yüküne” dönüştürme süresini kısaltmaktır.
İzleme ve çalışma kitapları SQL kadar önemlidir:
Bir PoC sprinti başlatın, sonra üretime hazır olma incelemesi ve kademeli geçiş (mümkünse çift yazma veya gölge okuma) için zaman ayırın.
Eğer PoC bulgularınızı, mimari takaslarınızı veya geçiş derslerinizi belgelerseniz, bunları ekibinizle (ve mümkünse kamuya) paylaşın: Koder.ai gibi platformlar eğitim içeriği oluşturduğunuzda kredi kazanma veya başkalarını yönlendirme gibi yollar sunabilir—bu da değerlendirme maliyetlerini azaltabilir.
A distributed SQL database provides a relational, SQL interface (tables, joins, constraints, transactions) but runs as a cluster across multiple machines—often across regions—while acting like one logical database.
In practice, it’s trying to combine:
A single-node or primary/replica RDBMS is often simpler, cheaper, and faster for single-region OLTP.
Distributed SQL becomes compelling when the alternative is:
Most systems rely on two core ideas:
This is what enables strong consistency even when nodes fail—but it adds network coordination overhead.
They split tables into smaller chunks (often called partitions/shards, or vendor-specific names like ranges/tablets/splits). Each partition:
You usually influence placement with policies so “hot” data and primary writers stay close, reducing cross-network trips.
Distributed transactions often touch multiple partitions, potentially on different nodes (or different regions). A safe commit may require:
Those extra network round trips are the main reason write latency can increase—especially when consensus spans regions.
Consider distributed SQL when two or more are true:
If your workload fits in one region with replicas/caching, a conventional RDBMS is often the better default.
Strong consistency means once a transaction commits, reads won’t see older data.
In product terms, it helps prevent:
The tradeoff is that during network partitions, a strongly consistent system may block or fail some operations rather than accept divergent truths.
Rely on database constraints + transactions:
idempotency_key (or similar) per request/attempt(account_id, idempotency_key)This turns retries into no-ops instead of duplicates—critical for payments, provisioning, and background job reprocessing.
A practical separation:
Before choosing, test your actual ORM/migrations and any Postgres extensions you rely on—don’t assume drop-in replacement.
Start with a focused PoC around one critical workflow (checkout, booking, ledger posting). Validate:
If you need help scoping cost/tiers, see /pricing. For related implementation notes, browse /blog.