Yapay zekadan makale özeti
- Kısa
- Ayrıntılı
- Bu video, Ankara'nın Cloud Meni'de gerçekleştirilen dokuzuncu etkinlikte Ensar Basri Kahveci tarafından sunulan teknik bir eğitim içeriğidir. Ensar Basri Kahveci, Hecast'ta Distributed Systems Engineer olarak çalışan ve Bilkent Üniversitesi'nde PhD yapmaktadır.
- Video, veritabanı replication teknolojileri, CAP teoremi ve NoSQL veritabanı sistemleri hakkında kapsamlı bilgiler sunmaktadır. İlk bölümde Hecast veritabanı teknolojisi tanıtılmakta, ardından replication kavramı, CAP teoremi ve farklı replication modelleri (Primary Copy, Multi-Leader, Eager ve Lazy replication) detaylı olarak anlatılmaktadır. Son bölümde ise konflik çözüm yöntemleri, konsensüs algoritmaları ve yazılım geliştirme/test süreçleri ele alınmaktadır.
- Sunumda ayrıca Cassandra, Kafka, Zookeeper, DynamoDB gibi farklı veritabanı sistemlerinin replication modelleri ve konsensüs algoritmaları örneklerle açıklanmakta, W ve R değerlerinin sistemin tutarlılığına etkisi, vektör saat (vector clock) algoritması gibi konular detaylandırılmaktadır. Video, açık kaynak kodlu ürünlerin geliştirme süreçleri ve test stratejileri hakkında da bilgiler içermektedir.
- 00:15Sunumun Tanıtımı
- Ankara'nın Cloud Meni'de gerçekleştirilen dokuzuncu etkinlikte, Nova veritabanlarında replication metodları anlatılacak.
- Sunumcu Ensar Basri Kahveci, Hecast'te distribute systems engineer olarak çalışmakta ve Bilkent'te PhD yapmaktadır.
- Sunum, NoSQL veritabanlarında kullanılan çeşitli replication metodlarından bahsedecektir.
- 01:30Hecast Tanıtımı
- Hecast, in-memory data grid olarak kendini tanımlayan ve NoSQL veritabanı olarak da kullanılabilen bir sistemdir.
- Sistem sadece storage değil, üzerinde computation yapabilen ve pub-sub service olarak da kullanılabilen bir platformdur.
- Türkler tarafından başlatılan proje şu an Amerika'ya taşınmış olup, hem Türk hem Avrupalı mühendisler tarafından geliştirilmektedir.
- 02:12Hecast'in Özellikleri
- Hecast, elastik cluster özelliği sayesinde istediğiniz kadar node başlatabilir ve datayı otomatik olarak rebalance edebilir.
- Highli-awable özelliği sayesinde cluster'daki memberların bazıları fail etse bile sistem kitlenmez ve kaybolan dataları kurtarır.
- Java'nın collection ve conquence interface'lerinin distribüt versiyonlarını kullanarak başlamış ve zamanla cashing, high density store gibi özellikler eklenmiştir.
- 04:11Hecast'in Çalışma Modları
- Hecast, kendi uygulamanıza embed edilebilen veya server-client modeliyle çalıştırılabilen iki modda kullanılabilir.
- Sistem, Java, Scala, C++, C, Python, Go gibi farklı dillerden erişilebilen özel bir client protokolüne sahiptir.
- Cloudfriendli bir sistem olan Hecast, çeşitli cloud ortamlarında çalışabilir ve Tom, Highbinate gibi sistemlerle entegre olabilir.
- 05:44Hecast'in Yeni Özellikleri
- Hecast'in 3.8 versiyonunda, çalışan cluster'ı indirmeden değişiklik yapabilme özelliği (rolling upgrade) sunulmuştur.
- Hot restart özelliği sayesinde, büyük veri setleriyle çalışan sistemlerin saniyeler içinde geri ayağa kaldırılması mümkün hale gelmiştir.
- Bir node bozulduysa bile, ayarlanmış back-up sayesinde verinin %100'ünü geri kurtarabilmek için iyileştirmeler yapılmıştır.
- 08:23Veri Tabanı Kopyalama (Replication) Kavramı
- Veri tabanı kopyalama (replication), veriyi birden fazla bilgisayarda tutma yöntemidir.
- Kopyalama, performans artırmak ve gecikmeyi azaltmak için yapılır; örneğin veriyi farklı şehirlerdeki sunucularda tutarak kullanıcıların yakın sunuculardan erişmesini sağlar.
- Kopyalama, sunucu başarısızlığı durumunda veri erişimini devam ettirmek için de kullanılır; bir kopya kaybedilse bile diğer kopyalardan veriye erişilebilir.
- 09:32Partitioning ve Kopyalama Sorunları
- Kopyalama genellikle partitioning (bölütleme) yöntemiyle birlikte kullanılır; veri önce parçalara bölünür, sonra her parçanın kopyaları oluşturulur.
- Veri sadece okunuyorsa kopyalama basittir, ancak veri güncellendiğinde sorunlar ortaya çıkar.
- Güncelleme sırasında oluşabilecek hatalar (örneğin bir kopya güncellendiğinde diğer kopyaların güncel olmaması) veri tutarlılığını bozabilir.
- 11:30CAP Teoremi
- CAP teoremi, 2000 yılında Eric Brewer tarafından öne sürülmüş ve 2002 yılında ispatlanmış bir teoremidir.
- Teorem, dağıtılmış bir veri deposunda (birden fazla kopya olan) kopyalar arasındaki ağ bağlantısı her an kopabileceği durumda, aynı anda mükemmel tutarlılık (consistency) ve mevcutluk (availability) garantisi verilemeyeceğini belirtir.
- Sistem tasarımı sırasında CAP teoremi doğrultusunda ya tutarlılık (CP) ya da mevcutluk (AP) tercih edilir; CP modunda ağ bağlantısı koparsa bazı düğümler bloke edilirken, AP modunda tüm düğümler işlem yapabilir ancak sonradan veri tutarlılığı sağlanır.
- 14:17CAP Teoremi ve Özellikleri
- CAP teoremi, network partitioning problemi hakkında konuşmakta ve node'ların fail etme durumlarını ele almamaktadır.
- Zoeper gibi bir tool kullanırken, beş node'dan üçü çalışıyorsa sistemi kullanabilirsiniz, ancak bir node daha kaybederseniz sistem duracaktır.
- CAP teoremi, sistemin ya strong consistency ya da availability sağlaması gerektiğini belirtir, ancak gerçek dünyada bu ikisi arasında bir spektrum vardır.
- 16:12Consistency Modelleri
- Stone consistency modelleri, network partitioning durumunda sistemin kullanılabilirliğini kaybetmesine neden olabilir.
- Monotonic flow consistency modelleri, sistemin yüksek kullanılabilirliğini sağlayarak yazma ve okuma işlemlerini devam ettirebilmesini sağlar.
- Data-centric modelde, sistemin global bir görüntü sunması gerekirken, bu mümkün değilse her client'a kendi açısından consistant bir model gösterilebilir.
- 18:30Replication Metotları
- Jim Grey tarafından 1990'ların sonunda yayınlanan bir çalışmanın replication metotlarını iki boyutta incelediği belirtilmektedir: update işleminin nerede ve ne zaman yapılacağı.
- Primary copy tekniğinde, bir replika seçilir ve bu replika update işlemlerini yapar, diğer replikalar ise passif olarak bekler.
- Bu tekniğin avantajı implementasyonunun kolay olması ve conflict handing logic gerektirmemesidir, ancak dezavantajı bir point of failure oluşturmasıdır.
- 21:41Update Teknikleri
- Update anywhere tekniğinde her node update işlemini başlatabilir, ancak bu durumda conflict olma ihtimali yüksektir.
- Multi leader tekniğinde, genellikle bir leader vardır ancak internet bağlantısı kesildiğinde telefon gibi cihazlar geçici olarak leader olabilir.
- Eager replication (syncro replication veya pesimistick replication) tekniğinde, bir update geldiğinde aynı transaction içinde tüm replikalar güncellenmeye çalışılır.
- 24:06Konsensus Algoritmaları ve Güvenilirlik
- Strom Consis adı verilen data content halini elde etmek için kullanılan modelde, bir node fail ederse client'e cevap dönmemesi sorunu yaşanabilir.
- Zeb diye adlandırılan konsensus algoritması, bir update geldiğinde majority güncellemeye çalışır; örneğin 5 node'dan 3'ünü güncelleyebilirse yanıt alır, aksi takdirde bekler.
- Lazer application modelinde, bir update geldiğinde hemen lokalde işletilir ve daha sonra diğer replikaya iletilir, bu sayede daha fazla request işlenebilir.
- 25:50Partition Owner ve Anti-Entropi Sistemi
- Partition owner sisteminde, veri put edildiğinde önce hangi partisine gideceği hesaplanır ve o parti kimin tarafından yönetiliyor ona gönderilir.
- Hecast üzerinden konuşulurken, bir update işlemi sırasında network bağlantısı sorunu yaşanabilir.
- Anti-entropi sistemi periyodik olarak çalışır ve partition owner kendi yönettiği data üzerine özet bilgiyi back-up'a göndererek senkronizasyon sağlar.
- 27:00Konsensus Modeli Türleri
- Primary copy eager application modelinde bir leader seçilir ve update geldiğinde herkesi güncellemeye çalışır, bu model strong consistency sağlar.
- Eager replication, aynı anda bütün replikaları tek bir transaction ile update etmeye çalışmak zor bir yöntemdir.
- Leaderless eager replication'da herkes transaction başlatabilir ve aynı anda bütün replikaları güncellemeye çalışabilir, bu modelde concurrency sorunları yaşanabilir.
- 29:18Lazy Application Modeli
- Primary copy lazy application modelinde bir leader var ve update'leri o yapar, asenkron bir şekilde back-up'ları günceller.
- Bu modelde eventual consistency elde edilir ve update'ler kaybolabilir.
- Her node update'leri proses eder ve asenkron bir şekilde diğerlerine söyler, bu modelde high availability sağlanır ancak eventuel consistency vardır.
- 31:46Uygulama Örnekleri
- Primary copy eager replication modelini kullanan ürünler: Zookeeper, Kafka, Walt DB, etcd ve Consul.
- Zookeeper gibi sistemler genellikle meta veri için kullanılır, gerçek veri değil.
- Primary copy lazy application modelini kullanan ürünler: Hecast, MongoDB, Elasticsearch ve Redis.
- 33:31Cluster State Change İşlemi
- Hecast'te cluster state change özelliği bulunur ve bakım senaryolarında kullanılır.
- Bir node kapatılıp açılacağı durumda, sistem otomatik olarak rebalancing yapmaz, cluster freeze edilir.
- Bu durumda gelen requestler bekler ve cluster tekrar aktif edildiğinde işlemeye devam eder.
- 35:07Veritabanı Tasarım Modelleri
- Amazon'un DynamoDB ürünü, Cassandra ve Riak gibi benzer ürünlerin geliştirilmesinde etkili olmuştur.
- Konuşmacı, veritabanı tasarımlarının iki boyutunu tek tek anlatmış ve bunların kesişimlerini ele almıştır.
- 35:41Primary Copy Eager Replication
- Bu modelde, primar fail ettiğinde yeni bir primar seçmek gerekir ve primar ile iletişim kesintisi durumunda sistem yanıt veremez.
- Majority (çoğunluk) yaklaşımı kullanılarak, örneğin 5 node'dan 3'ünün çalıştığı sürece sistem sorunsuz çalışır.
- Kafka'da Insync Replica seti kullanılarak, senkron olmayan replikalar setten çıkarılır ve aynı anda birden fazla transaction başlatma sorunu yaşanabilir.
- 38:10Primary Copy Lazy Application
- Bu modelde update'ler hızlı yapılabilir çünkü replikaların yanıtını beklemeye gerek yoktur.
- Dezavantajı replication lag olabilir ve primar fail ettiğinde tamamlanmamış replikasyonlar nedeniyle data kaybı yaşanabilir.
- Secondary'ler okuma işlemleri için kullanılabilir, bu sayede datalar yavaş yavaş güncellenebilir.
- 39:10Dynamo Stili Tasarım
- Dynamo stili tasarımlar yüksek kullanılabilirliğe sahiptir ve her node'dan request atıldığında yanıt alınabilir.
- Aynı anda yapılan update'ler conflict olabilir ve bu durumlar ele alınmalıdır.
- Conflict'leri çözmek için farklı yöntemler kullanılabilir: conflict'i engellemek, göz ardı etmek, tespit etmek ve çözmek.
- 40:22Conflict Çözüm Stratejileri
- Conflict'leri tespit edip çözmek için merge function kullanılabilir ve son karar kullanıcıya bırakılabilir.
- Node'lar diverge olabilir ve aynı key farklı değerlerde tutabilir, bu durumda veriler zamanla converge etmelidir.
- Conflict'leri çözmek için write sırasında, read sırasında veya sistem kendi kendine çözebilir.
- 41:48Cassandra'da Replikasyon Stratejileri
- Cassandra'da W+R>N kuralı uygulanır (W: write sayısı, R: read sayısı, N: replika sayısı).
- Bu kurala göre, yazılan ve okunan node'ların kesişimi olduğunda güncel veri okunabilir.
- Hinted Handoff mekanizması ile, bir node'a yazma başarısız olduğunda geçici olarak başka bir node'a yazılır ve sonra orijinal node'a aktarılır.
- 44:51Config Free Replicator Data Type (CRDT)
- CRDT, akademik bir çalışma olarak başlayan ve sonrasında ürünlerde uygulanmış bir sistemdir.
- Bu sistemde replikalar güncellendiğinde birbirleriyle iletişim kurarak kendi datalarını merce ederler.
- Merch function'un matematiksel özellikleri sayesinde replikalar en sonunda aynı duruma gelir ve hiçbir configte çözülemeyen bir durum oluşmaz.
- 45:45Küme Örneği ve Silme Sorunu
- Küme oluşturma örneğinde, replikalar birleştiğinde setin özelliklerinden dolayı en son durumda hepsi aynı değerlere ulaşır.
- Silme işlemlerinde ise, replikaların güncelleme sırası değişebilir ve farklı sonuçlara ulaşabilirler.
- Silme işlemlerinde "tumstone" (mezartakı) kavramı kullanılarak, silinen öğelerin tekrar ekleneceği durumları engellemek mümkündür.
- 47:10CRDT Kullanımı ve Alternatif Çözümler
- CRDT fikri güzel olsa da uygulaması zor ve maliyetli olduğu için yaygın database'lerde kullanılmamaktadır.
- Alternatif bir çözüm olarak, konflikleri göz ardı edebiliriz; replikalar arasında zaman damgası kullanarak güncel olanı kabul edebiliriz.
- Saat problemi, marketten alınan bilgisayarların saatlerinin senkron olmayabileceği durumunda ortaya çıkabilir.
- 49:08Konflik Tespiti ve Çözümü
- Konflikleri tespit etmek için her güncelleme işleminin bir veri versiyonuna karşı yapıldığı ve versiyon numarasının tutulduğu bir yöntem kullanılır.
- Vektör saat (vector clock) algoritması, konflikleri tespit etmek için kullanılır ve hangi işlem önce gerçekleştiğini belirler.
- Konflik tespit edildiğinde, kullanıcıya hangi güncelleme seçileceğini belirlemesi için bir seçenek sunulur.
- 53:49Anti-Entropi ve Özeti
- Anti-entropi, konfliklerin hemen çözülmesi ve geride kalan dataların güncellenmesi anlamına gelir.
- Replikalar periyodik olarak birbirleriyle veri özetlerini paylaşarak konflikleri tespit eder ve çözümler.
- Kullanılan ürünün dökümanında bu metotların isimleri geçtiği için hangisinin kullanıldığını kolayca anlayabilirsiniz.
- 54:28Veritabanı Kopyalama Sistemleri
- Veritabanı kopyalama sistemlerinde (replication) farklı protokoller bulunur ve her birinin avantajları ve dezavantajları vardır.
- Teorik olarak her zaman tutarlı (consistent) olacak, istediğiniz zaman erişebileceğiniz ve düğümleri fail edebileceğiniz bir kopyalama sistemi yoktur.
- Bu konuda iddialı ürünler kullanılmamalıdır çünkü teorik olarak mümkün değildir.
- 55:17İşletme İlanı
- Şirket, İstanbul ana geliştirme ofisinde ve Ankara'dan da uzaktan çalışan elemanlar aramaktadır.
- Java bellek modeli, tutarlılık ve görünürlük konularında deneyimli geliştiriciler aranmaktadır.
- Performans ve kalite ekibinde, cluster testleri yapan ve kaos testleri gerçekleştiren kişiler aranmaktadır.
- 56:01Test Senaryoları
- Release yapmadan önce cluster'a iki gün boyunca sürekli veri ekleme ve çıkarma testleri yapılır.
- Kaos testlerinde cluster başlatılır, veri eklenir, sonra cluster'ın yarısı öldürülür ve sistemin kendini toplayabilmesi test edilir.
- Test senaryoları yazılır ve işletilir, sonuçlar incelenir.
- 56:46Çözüm Arşiteleri
- Şirkette müşteriye yazılım kullanımını anlatan ve sorunlarını çözen çözüm arşiteleri bulunmaktadır.
- Çözüm arşiteleri müşterilere eğitim verir ve sorunlarını çözer.
- Bu pozisyonlar daha çok müşteriyle iletişim kurma ve konuşma becerisine sahip kişiler için uygundur.
- 57:35Veritabanı Kopyalama Senaryoları
- Veritabanı kopyalama senaryoları, veri merkezleri veya farklı bölgeler arasında yapılabilir.
- Amerika ve Asya gibi farklı bölgelere veri koyulduğunda mutlaka gecikme (latency) olacaktır.
- Kullanım senaryosuna göre sistem konfigüre edilmelidir, örneğin aynı veriyi güncelleyecek iki merkezli senaryoda gecikme sorunları yaşanabilir.
- 59:06Okuma-Yazma Performansı
- Okuma ve yazma performansı genellikle birbirine karşıt olarak değerlendirilir, genellikle birine odaklanılır.
- Dynamo gibi sistemler yazma performansına odaklanır ve sürekli yazma imkanı sağlar.
- Kullanım senaryosuna göre okuma ve yazma performansı ayarlanabilir, Cassandra gibi sistemlerde farklı konfigürasyonlar yapılabilir.
- 1:00:39İç Test Araçları
- Şirket, kendi geliştirdiği test araçları kullanmaktadır.
- Bu araçlarla adım adım senaryolar yazılabilir, düğümler başlatılabilir ve öldürülebilir.
- Sistem durumu programatik olarak izlenebilir ve raporlanabilir.
- 1:02:09Açık Kaynak Kullanımı
- Şirkette Türk ve Avrupalı geliştiriciler arasında kültür farkları yaşanmaktadır.
- Açık kaynak sistemlerde GitHub'da depo oluşturulur, pull request gönderilir ve review süreci geçer.
- Türkçe geliştiriciler genellikle hızlı çözüm ararken, yabancı geliştiriciler daha kuralcı ve kaliteli kod üretmeye odaklanır.
- Konuşmacı, zamanla açık kaynak kültürünü sevmeye başlamış ve bu kültürün şirket içi kod geliştirme için de uygulanması gerektiğini düşünmektedir.
- 1:04:41Yazılım Test Süreci
- Yeni bir sürüm (release) için önce code coverage kontrolü yapılır ve test覆盖率低的类需要添加更多测试以确保内部稳定。
- 在亚马逊上通常会在周五启动10个节点，进行为期48小时的持续高强度测试，检查新功能是否正常工作。
- 分布式系统中的错误可能难以重现，因为需要特定的并发条件。在这种情况下，通常会通过强制系统进入特定状态来触发错误，以便进行调试。
- 1:07:02竞品比较与基准测试
- 公司会与其他提供类似产品的竞争对手进行比较，使用相同的算法来评估性能。
- 基准测试需要透明度，测试结果必须可复现，即任何人在相同条件下应得到相同的结果。
- 理论算法在实际应用中可能遇到未预见的问题，需要对算法进行调整以适应现实情况。
- 1:08:42算法实现中的挑战
- 例如，Two Phase Commit算法在实际应用中可能导致系统阻塞，如果发起者和同意者同时失败，其他节点将无法确定是否应回滚事务。
- 即使使用相同的算法，不同实现之间也会存在差异，因为需要解决实际应用中的特定问题。
- 有时会遇到不可解的问题（impossibility result），即某些设计目标在特定条件下无法实现。