Yerli JPA implementasyonu Batoo

Bu röportajımızı, Batoo Yazılım ve Danışmanlık şirketi kurucusu Hasan Ceylan ile gerçekleştirdik. Hasan beye yönelttiğimiz sorular ve aldığımız cevaplarla, geliştirdiği JPA implementasyonunu sizlere tanıtmayı amaçlıyoruz.

Kodcu.Com: Projenin başlangıcından bahseder misiniz?

Hasan Ceylan: Projeyi 2012 Şubat ayında kodlanmaya başladım. Fakat, kişisel olarak JPA kullanımının ne derece pahalı olduğunun uzun zamandır farkındaydım. Özellikle kariyerimin son yıllarında benden istenen performans arttırım çalışmalarında JPA katmanının eklediği overhead’i gördükçe motivasyonum arttı. Şubat ayı içerisinde bu işin gerçekten bu kadar ağır olup olmadığını anlamak adına sadece persist() ve find() operasyonlarını uygulayan bir dummy JPA Provider yazdım. İlk rakamlar hayal kırıklığı olurken, bir kaç best-practice uygulaması ile bir anda yapmış olduğum prototip 50 katın üzerinde bir hız sergiledi. Bunun üzerine session management da eklenip, rakamlar hala ibreyi Batoo JPA tarafında göstermeye devam edince, aslında iyi bir performans sergileyen bir JPA implementasyonunu yazabileceğime karar verdim.

Mart ve Nisan aylarında daha çok devam eden başka projelerde çalışmam sebebi ile Batoo JPA’yı hala hobi projesi olarak kalırken, Mayıs ayı ile tam gaz kodlama başladı. Gündüz-gece, haftasonları derken, gittikçe spesifikasyonun sonuna geldim. Ağustos Ayı sonu itibari ile çekirdek biterken, Ağustos ayında da çeşitli uygulama sunucuları, Android -ki belirtmeliyim, Android üzerinde çalışan tek JPA implementasyonu Batoo JPA’dir- veri tabanı adaptörleri gibi dış dünya entegrasyonları tamamlandı. Eylül ayı ile proje kapalı bir grup ile paylaşılırken, 4 Ekim itibari ile release oldu.

Şu anda Batoo JPA, tam olarak Hibernate’den 23 kat, EclipseLink’den 15 kat hızlıdır. Ayrıca veri tabanını Hibernate’e göre %25, EclipseLink’e göre %30 daha az yorar.

Kodcu.Com: Bu projenin kullanıcılara sağlayacağı artılar nedir?

Hasan Ceylan: Performans, performans, performans. Batoo JPA projesi özelinde bir profiler yazıldı. Bu profiler ile her mikro geliştirme, “önce ve sonra” şeklinde performans testine tabi tutuldu. Profiler, geleneksel ev tipi başlangıç zamanı ve bitiş zamanı baz alma metoduna göre değil, direkt olarak Sun JVM’in sunduğu in-process profiling instrumentation ile direkt harcanan CPU zamanlarını kaydeden bir yapıya sahip. Ayrıca, profiler, stack içerisinde yerini de bilerek harcanan zamanın JPA ve DB katmanı ayrımını ve hatta satır nosunu da verebilmektedir. Her geliştirme iterasyonun ardından profilerın çalıştırılması ile yazılıan her satır kod geliştirme sonrası ölçüldü. Böylelikle istenen performans sağlandı.

Bir diğer şey ise, Batoo JPA’nın yeni bir framework olmadığıdır. Örneğin Hibernate’in aksine, tüm yapı Java Persistence API 2.0 spesifikasyonu üzerine kuruldu. Projeye has API’ler yaratmaktan özellikle uzak duruldu. Geliştirici ve Sistem Yöneticisi için kritik olan tüm yapılar implementasyonun içerisine gömüldü. Örneğin, çokça kayıt yaratan bir uygulama için Hibernate, kullanıcılarına hibernate.jdbc.batch_size, hibernate.order_updates gibi ayarlar yaptırıp, session’ı manuel olarak zaman zaman flush etmenizi önerirken, Batoo JPA için biz hiçbir şey önermiyoruz. Batoo JPA içerisindeki zeki algoritmalar bu kararları sizin için alıyor ve gerekli davranış değişikliğini uyguluyor.

Projenin tamamen JPA Spesifikasyonu üzerine kurulu olmasının bir diğer artısı da, geliştiricilerin yeni API, ayar, kodlama şekli gibi ek öğrenimlere ihtiyaç duymamasıdır. Dolayısı ile JPA bilen bir geliştirici, otomatik olarak Batoo JPA kullanımını biliyor demektir. Şunu eklemeliyim ki, Batoo JPA içerisinde, Hibernate’in aksine DBDialect, TransactionLookupManager gibi platform spesifik ayarlara bile ihtiyaç duymazsınız. Batoo JPA, çalıştığı ortamı kullanarak en uygun DB Adaptörünü sizin adınıza seçer, çalıştığı platformu denetleyerek, Transaction Manager’ı bulur. Uygulamanız, gerçek anlamda taşınabilir (WORA) olur.

Kodcu.Com:Performans dışında, diğer JPA alternatifleri arasında bu ürün kendini nasıl farklı kılıyor?

Hasan Ceylan:Performansa ekleyebileceğim şu olabilir, Batoo JPA kendisine güveniyor ve Vendor Lock-in denilen “mahkum kılma” yöntemlerine projeleri zorlamıyor. Batoo JPA, sırf projeye başlanırken propriety Batoo JPA API’leri kullanıldığı için projeyi mahkum kılmak yerine ortaya koyduğu dramatik performans kazancı ve yalın kullanım ile, geliştiricilerin mahkum oldukları için değil, aksine sadece istediği için Batoo JPA’yı kullanmasını istiyor. Hiç sanmıyoruz ama eğer bir şekilde Batoo JPA’dan memnun kalınmazsa, tüm proje JPA üzerine kodlandığı için, geliştirici, sadece bir satır değiştirerek başka bir JPA Implementasyonuna geçiş yapabilir.

Batoo JPA daha büyük bir parça olan J2EE serverların bir parçası değildir. Dolayısı ile başka bir ürünü forse etmek için değil, Açık Kaynak Kodlu yazılımlara ve yarattığı sinerjiye inanç ile LGPL ile yayınlanmıştır.

Kodcu.Com:Paralel, entity’ler arası ilişkiler ve caching mekanizmalarında ne tür yenilikler yer alıyor?

Hasan Ceylan:Batoo JPA, deployment fazını paralel olarak çalıştırıyor. Bu hep bahsettiğimiz runtime peformansının aksine geliştirme esnasında geliştiriciye zaman kazandırıyor. Özellikle relatif olarak büyükçe projelrede, 3, 4 kat hızlı deploy süresi ile her değişiklikte uygulama sunucusuna yapılan deployment çok kısa zaman alıyor ve duraklamalar azalıyor. Biliyorsunuz benzer yaklaşım 7 versiyonu ile deployment unite’ler seviyesinde JBoss tarafından da benimsendi ve uygulandı. JBoss 7 bu anlamda ağır J(2)EE geliştirme süresini kısaltarak oldukça iyi bir iş yaptı. Batoo JPA da sadece işletim adına değil, geliştiricinin zamanının verimini arttırma adına da bu anlamda doğru seçimdir.

Bunun dışında ilişkiler veya diğer şeyler anlamında Batoo JPA ek bir öğrenme veya geliştirme gerektirmiyor. Ben JPA Spesifikasyonunun, herkes için tamamıyla olmasa da, yeterli olduğunu düşünüyorum. Eğer bir özellik gerçekten JPA’nın doğasında var ise bu proprietary API’lar yerine JPA spesifikasyonunda belirlenmeli ve yine Java’nın motto’su olan WORA devam etmeli. Gelecekte Batoo JPA’nın kabul görmesi ile iştirak etmeyi umduğum JPA Spec Board’da da bu yönde duruş sergileyeceğim.

Cache konusuna gelince, mevcut yapısı ile Cache sistemleri, mevcut JPA Implementasyonlarının, yavaşlıklarına cevap olarak “pardon demesidir”. Günümüz veri tabanları, Table / Index / Query cachelemesi yapabilmektedir. Üstelik bir cache için en önemli olgu olan invalidation, mevcut implementasyonlar tafafından “sil gitsin hepsini” yaklaşımı ile implemente edilmiştir. Modern veri tabanları sizin için bunu en üst seviyede zeka ile sadece ilgili cache node’larını invalide etmek şeklide verimli bir şekilde yaparken, cache sistemleri ile serialization overhead’i eklemenin, ve uygulamanın cache ile dışarından veri tabanı yazmaya kapatılması zorunluluklarına katlanmanın yersiz olduğunu düşünüyorum. Cache’in genel JPA cachelemesi yerine, parametrik veri tutan, sayısı sınırlı olan entitiler için (örnek: Ülke, Müşteri Tipi v.b) olması gerektiğini düşünüyorum. Konu üzerine, highscalibility.com’da yayınlanan makalemin tartışma bölümünde yaptığımız münazarada tecrübeli Hibernate Geliştiricisi Anthony Patricio da hemfikir olmuş ve aynen şu ifadeyi kullanmıştır: “true about second level cache, it’s a false friend but many people will use it just to boost some benchmark results” – “Haklısın, L2 cache sizin kötü arkadaşınızdır, çoğu insan bazı benchmark sonuçlarını yüksek göstermek adına kullanmaktadır”. [1]

Hibernate bir tabu yaratmıştır adınına da LazyInitialationException demektedir. İnat ile bunu çözmek yerine sorumluğu daha üst katmanlara bırakarak, OpenSessionInView gibi saçma yaklaşımların ortaya çıkmasına neden olmuştur. Her ne kadar yeni connection açıp lazy parçanın initialize edilmesini, üstelik de insanlara çıkışarak “Transaction Demarcation’a tertir” diye refüze ederken, kapalı kapılar ardında henüz read only olan (herhangi bir write operasyonu başlatmamış) sesion’lar için, Hibernate nerede ise her DB etkileşimi için connection açıp kapatmaktadır. Az bilinir ki EclipseLink, Hibernate ile bu konuda fikir birliği yapmamış ve isole session içerisinde lazy parçaları initialize etmektedir. Batoo JPA da aynı yaklaşımı benimsemekle, Hibernate’in yarattığı bu kaosu bitirmeye niyetlidir. Tabii tüm bu argüman aynı JVM içerisinde olan kod parçaları içindir, serialize olmuş bir instance için bu anlamda yapılacak bir şey yoktur. Fakat uygulamaların büyük bir bölümünün aynı uygulama sunucusu içerisinde çalışan JPA katmanı ile konuşması sebebi ile, Batoo JPA, EclipseLink ile bu bayrağı olması gereken yere dikecektir.

Kodcu.Com: Bu implementasyon kendine özgü bir syntax getiriyor mu?

Hasan Ceylan: Kesinlikle hayır. Örneğin Hibernate için aynı ihtiyaç üzerine HQL ve JPQL varken, Batoo JPA’da bu gibi şeyler yoktur.

Kodcu.Com: Böyle bir implementasyon geliştirme ihtiyacı neden hissedildi, piyasada buna ihtiyaç var mı?

Hasan Ceylan: Kesinlikle var. Tipik bir uygulamada JPA, J2EE katmanı CPU kullanımının yarısı veya daha fazlasını almaktadır. Batoo JPA içerisinde yer alan benchmark çalıştırıldığında göreceksiniz ki, Hibernate veri tabanı tarafından harcanan işlemci kaynaklarının 2/3’ünü, EclipseLink ise 1/3’ünü harcamaktadır. Bir taraftan veri tabanı haklı olarak müthiş bir iş yaparak bu zamanları harcamayı hakederken, aracı bir framework’ün, bunun ciddi yüzdelerini tüketmesi kabul edilemez. Aynı ölçekte gururla söyleyebilirim ki Batoo JPA, veri tabanı kaynaklarına oranla sadece %2.5 CPU kaynağı harcamaktadır.

Bu şu anlama geliyor:

  • Uygulamanız bir cluster içerisinde mi çalışıyor, JPA provider’ınızı Batoo JPA’e değiştireken bir kaç gün içerisinde kapasitenizi ikiye katlayabilir ya da lisans ihtiyaçlarınızı, hardware’inizi, administration’ınınızı yarıya indirebilirsiniz.
  • Uygulamanız cluster friendly değil ise sadece daha iyi kapasite edinmek için dudak uçuklatıcı derecede pahalı masif serverlar edinmenize gerek yok. Batoo JPA kapsitenizi en azından ikiye katlayarak sizi rahatlatacaktır.

Diğer taraftan bildiğiniz gibi Android en üstte Java üzerine kurulu görsel ve yönetsel katmanı olan bir işletim sistemi. Fakat mobil işlemciler üzerinde çalışacak yapıların oldukça hafif olması gerekiyor. Mevcut JPA implementasyonlarını Android üzerinde kullanak isteyen bir çok kişi hayal kırıklığına uğradı. Fakat bugün Batoo JPA ile Android üzerinde JPA kullanmaya hemen başlayabilirsiniz.

Kodcu.Com: Bu implementasyonun kullanıldığı örnek bir proje var mı, kullanıcılar ile örnek bir proje paylaşabilir misiniz?

Hasan Ceylan: Dün çalıştığınız proje 🙂 Bunu şaka olarak söylemiyorum. Eğer HibernateSession değil de Hibernate’i EntityManager ile JPA kullanıyorsanız projenizi bir iki gün içerisinde Batoo JPA üzerinde çalıştırmaya başlayabilirsiniz.

Diğer taraftan GitHub repository’si üzerinde biri JSF, diğeri Android uygulaması olmak üzere iki örnek uygulama mevcuttur. [2] [3]

Kodcu.Com: Projenin release edilmesi sonrasında aldığınız ilk tepkiler nelerdir?

Hasan Ceylan: Proje 4 Ekim itibari ile release oldu. Akabinde highscalibility.com‘da yayınlanan makale ve The Server Side’da çıkan haber ile, binlerce kişi http://batoo.jp adresinden Batoo JPA hakkında fikir edinmeye geldi. İronik olarak hem sevindiğim hem üzüldüğüm konu, yükün çokluğu nedeni ile sitenin bir saat kadar down olmasıdır 🙂

Diğer taraftan bir çok kişi projeyi tweet’ledi, Github üzerinde bir kaç gün içerisinde defalarca forklandı, bir çok kişi taraftından start olarak işaretlendi. Türkiye’den ve yabancı pek çok yetenekli kişi hemen projeye amatör ve profesyonel olarak katılma isteklerini iletti ve destek vereye de hemen başladılar.

Şimdiden 2 Fortune 500 firması, Batoo JPA’yı incelemeye başladı.

Yani ilk tepkiler çok olumlu idi.

Kodcu.Com: Geleceğe ait planlarınız nelerdir?

Hasan Ceylan: Batoo JPA, JPA alanında devrim yaratacaktır. Fakat J(2)EE sadece JPA’dan oluşmamaktadır. Ben, kariyerim boyunca kullandığım diğer bazı frameworklerde de bir şeyler yapılabileceğine inanıyorum. Bunlara örnek; JSF, MVC, Expression Evaluation, MQ, JTA kafamdaki bazı frameworkler. Yaklaşık 3 yıl zarfında bunlardan en az ikisini, 5 yıl zarfında da tümünü yapmak süretiyle ciddi bir J(2)EE Suitine sahip olmayı umuyorum.

Grand Vizyon ise, 5 yıl zarfında Türkiye gibi gelişmekte olan bir ülkeden popüler bir uygulama sunucusu çıkarmak.

Türkiye’de mükemmel yetenekleri olan arkadaşlar var. Ve kuracağım takım ile bu, bir hayal değil aksine plan olacaktır!

Kodcu.Com: Bu röportaj ve paylaştığınız değerli bilgiler için teşekkür eder, çalışmalarınızda başarılar dileriz.

1 Comment

Post a Comment

Comment
Name
Email
Website