Kotlin Language Features Related to Null Handling

Any software engineer with a Java background would find the null handling features in the Kotlin language interesting. Let's summarize this topic with some examples. Nullable types: In Kotlin, types are non-nullable by default. If you want a variable to be able to hold a null value, you need to explicitly declare its type as nullable using the Type? syntax. For example, String? denotes a nullable string, while String represents a non-nullable string. Safe calls (?.): Kotlin introduces the safe call operator (?.) for handling nullable types. It allows you to safely invoke a method or access a property on a nullable object. If the object is null, the expression returns null instead of throwing a NullPointerException. Example: data class Person(val name: String, val age: Int, val address: String?) fun main() {     // Create a person with a nullable address     val person1 = Person("John Doe", 25, "123 Main Street")     val person2 = Person("Jane Doe", 30,...

NoSQL - Bölüm 1: NoSQL Hareketinin Ortaya Çıkışı

NoSQL hareketi nereden çıktı? Neden ilişkisel veritabanları dışında bir yapıya ihtiyaç duyuldu?

İlişkisel veritabanları 70'li yıllardan itibaren yazılım dünyasına ağırlığını koymuştu. Sunduğu avantajlar şunlardır:

  • Veriyi dosya sistemlerinden daha esnek bir biçimde depolayabilmek.
  • Eşzamanlı erişim (concurrency) konusunda bir çözüm sunmak. "Database Transaction" denilen yapı ile, eşzamanlılık problemlerini çözme olanağı.
  • Birden fazla uygulama ortak bir veritabanını kullanarak entegre çalışabilir. (Shared Database)
  • Herkesin bildiği standart bir veritabanı yapısı kullanılmış olunur. Farklı firmaların SQL implementasyonları farklılıklarına rağmen birbirine benzemektedir.
İlişkisel veritabanının birden fazla uygulama tarafından ortak olarak kullanılması (shared database) ve bu yolla entegrasyon sağlanması bazı sakıncaları da beraberinde getiriyor: 
  • Birden fazla uygulama tarafından kullanılan bir veritabanı daha karmaşık olmaya yatkındır.
  • Veritabanı yapısında değişiklik yapılacağı zaman, diğer uygulamalar ile de koordineli çalışmak gerekmektedir. Bazı firmalar veritabanı yapısı üzerinde değişiklik yapmayı yasaklamışlardır çünkü yapılan değişikliğin ne gibi sonuçlar doğuracağı öngörülememektedir.
  • Farklı uygulamaların performans gereksinimleri de farklıdır. Kendi uygulamanızın performansı için bir tabloya eklediğiniz indeks, başka bir uygulamanın performansını olumsuz etkileyebilir.
Web servislerinin ve Service Oriented Architecture yaklaşımının yaygınlaşması ile, yeni bir entegrasyon yöntemi benimsenmeye başlanmıştı. Artık veritabanınız uygulamanıza özel olabilirdi çünkü sizin sisteminizi servis olarak kullananlar veriyi nasıl depoladığınız ile ilgilenmiyordu. Böylece farklı veritabanı teknolojilerini kullanmak çok daha kolay olmaktaydı. Buna rağmen çoğu yazılım ekibi ilişkisel veritabanlarını kullanmaya devam etti. 

90'lı yıllarda nesne yönelimli programlamanın ortaya çıkması ve yaygınlaşması ile birlikte "nesne yönelimli veritabanı" teknolojileri de ortaya çıkmıştı. Birçok kişi nesne - ilişkisel uyumsuzluğu nedeniyle artık nesne yönelimli veritabanlarının yaygınlaşacağını düşünüyordu. Fakat böyle olmadı. 

İlişkisel veritabanlarına alternatiflerin uygulamaya konulması ölçeklenebilirlik (scalability) problemleri nedeniyle gerçekleşti. Google ve Amazon gibi firmalar kullanıcılara ait çok detaylı bilgi topluyordu ve verilerin boyutu müthiş büyüklüklere ulaşmıştı. Bunlar daha büyük ve güçlü makineleri gerektiriyordu fakat bu tip makineler çok pahalıdır. Bu nedenle belli bir güçteki çok sayıda makineyi paralel olarak kullanmak ve kümeleme (clustering) konusu ağırlık kazandı. İlişkisel veritabanları ile "sharding" yapılabiliyor ve bu yolla farklı veri setleri farklı makinelerde depolanabiliyordu. Fakat burada uygulamalar hangi veriyi hangi makineden çekeceğini bilmek zorundadır ve transaction yapısı birden fazla makineyi ilgilendiriyorsa eşzamanlı erişim konusunda sıkıntı sözkonusu olmaktadır. Kısacası ilişkisel veritabanları birden fazla makinede çalışabilecek şekilde tasarlanmamıştı ve bulunan çözümler biraz zorlama oluyordu. Buna ek olarak, veritabanı sistemi şirketleri cluster üzerinde çalışacak veritabanları için daha fazla para istiyordu. 

Google ve Amazon başarılı şirketler olmaları ve yeterli teknik birikime sahip personel barındırıyor olmaları sebebiyle veritabanı teknolojisine katkıda bulundular. Google BigTable ve Amazon da Dynamo teknolojilerini yayınladılar. Cluster üzerinde çalışmak üzere tasarlanmış veritabanları sadece Google gibi büyük şirketlerin değil, her türlü yazılım şirketinin ilgisini çekebilecek durumdadır. Çünkü giderek daha çok firma büyük miktarda veri üzerinde çalışmak konusunda istekli hale gelmektedir. 

"NoSQL" ismi ilk defa Strozzi tarafından bir ilişkisel veritabanı sistemine verilmiş. Bu sistemin özelliği sorgulama dili olarak SQL kullanmıyor olmasıymış.
Günümüzde kullanılan anlamıyla "NoSQL" ismi ise ilişkisel veritabanı teknolojilerine alternatif olan sistemlerle ilgili bir toplantıya isim ararken ortaya çıkmış. Johan Oskarsson kısa, akılda kalıcı ve twitter'da iyi bir hashtag olabilecek bir toplantı ismi olarak "NoSQL" ismini benimsemiş. Daha sonra bu isim malum teknolojilere verilen genel bir isim olarak benimsenmiş.


Kaynaklar:

  • NoSQL Distilled - Pramod J. SadalageMartin Fowler
  • Wikipedia








Comments

Popular posts from this blog

Trie Data Structure and Finding Patterns in a Collection of Words

Virtual Memory

NOTES ON COMPUTER ARCHITECTURE: Some important concepts in computer architecture