Çoklu Veri Saklama Altyapısı
Cahit Yiğit Çetiner, Merve Kaymak, Mustafa Karabacak ve Tuba YağlıHAVELSAN A.Ş.
Komuta Kontrol Savunma Teknolojileri Ankara, Türkiye
{ccetiner,mkaymak,mkarabacak,tkizik}@havelsan.com.tr Özet. Komuta Kontrol Bilgi Sistemlerinin (KKBS) öncelikli kullanım alanla-rından biri cari harekâtın takibidir. Cari harekâtın sağlıklı bir şekilde takip edi-lebilmesi için KKBS’lerin radar, sensör gibi donanımlar ile bütünleşik çalışa-bilmeleri gerekmektedir. Entegrasyon sırasında alınan duraksız verilerin (stre-aming data) KKBS bünyesindeki ilişkisel veri tabanında saklanması, gelen ve-rinin yoğunluğundan dolayı performans kaybına ve sergilemede gecikmelere sebep olabilmektedir. Duraksız verilerin saklanması için sütun temelli veri ta-banlarının kullanımı daha etkin olsa da, mevcut uygulamanın kullandığı veri yapısının bütünüyle değiştirilmesi kabul edilemez. Çelişen isterlerin olduğu bu gibi durumlarda, çoklu veri saklama altyapıları kullanılarak istere uygun veri saklama yöntemlerinin aynı anda kullanılabileceği değerlendirilmektedir. Bu doğrultuda, HAVELSAN tarafından KKBS’leri veri saklama yönteminden so-yutlayacak çoklu bir veri saklama altyapısı geliştirilmektedir. Bu makalede, hem ilişkisel veri tabanı hem de geliştirilen çoklu veri saklama altyapısı kullanı-larak örnek olay çalışması üzerinden performans karşılaştırması anlatılmakta ve altyapının kullanılabilirliği tartışılmaktadır.
Anahtar Kelimeler: Komuta kontrol uygulamaları, Çoklu veri saklama altya-pısı, Duraksız veri, İlişkisel veri tabanı, Sütun temelli veri tabanı
Polyglot Persistence Infrastructure
Cahit Yiğit Çetiner, Merve Kaymak, Mustafa Karabacak ve Tuba YağlıHAVELSAN
Command & Control and Combat Systems Ankara, Turkey
{ccetiner,mkaymak,mkarabacak,tkizik}@havelsan.com.tr Abstract. One of the priority usage areas of the Command and Control Infor-mation Systems (CCIS) is monitoring of the current operations. In order to monitor the current operation in a reliable way, CCIS should be able to work in-tegrated with equipment such as radar and sensor. Storing streaming data in the relational database within the CCIS may cause loss of performance and delay in display due to the density of incoming data. Although the use of column-based
databases for storing nonstop data is more efficient, it is unacceptable to com-pletely alter the data structure used by the current application. In such cases where there are conflicting requirements, it is considered that multiple data storage infrastructures can be used at the same time using appropriate data stor-age methods. Accordingly, HAVELSAN is developing a multiple data storstor-age infrastructure that will isolate the CCIS from the data storage method. In this ar-ticle, the performance comparison is discussed and the usability of the infra-structure is discussed by using both relational database and multiple data stor-age infrastructure developed.
Keywords: Command and control applications, Polyglot persistence, Streaming data, Relational database, Column-oriented database
1 Giriş
Komuta Kontrol Bilgi Sistemlerinin en önemli kullanım alanlarından biri muharebe sahasındaki muharebe elemanlarının güncel durum ve konum verileri ile istihbarat bilgilerinin takip edilmesidir. Bu kapsamda gerekli verilerin elde edilebilmesi için, dış sistemler ve donanımlar ile bütünleşik çalışabilen bir KKBS kurgusu kaçınılmazdır. Özellikle donanımların içinde bulunduğu entegrasyonlarda, KKBS’lerin gelen durak-sız verileri işlemesi, saklaması ve gerçeğe yakın zamanlı sergilemesi gerekmektedir.
Çoklu Veri Saklama yöntemi, mevcut çalışan uygulamanın kullandığı veri yapısını değiştirmeden, mevcut veri saklama çözümünün yanı sıra çelişen veya darboğaz yara-tan isterleri karşılamak için diğer veri saklama yöntemlerinin de çözüme dâhil edile-bilmesini amaçlamaktadır. Bu sayede tek bir veri modeli üzerinden birden fazla veri saklama yöntemi sunulmaktadır.
Bu makalede çoklu veri saklama altyapısı kullanılarak örnek olay çalışması üzerin-den performans karşılaştırması anlatılmakta, ayrıca altyapının geliştirilmesine dair kazanılmış deneyimler ve karşılaşılan sorunlar paylaşılmaktadır. İkinci bölümde prob-lem tanımı verilerek, güncel durumdaki KKBS sisteminin yapısı ve karşılaşılan sorun-lar anlatılmaktadır. Üçüncü bölümde çoklu veri saklama altyapı mimarisi anlatılmak-tadır. Dördüncü bölümde karşılaştırmalı bir örnek olay çalışması anlatılmakanlatılmak-tadır. Beşinci bölümde ise örnek olay çalışmasında toplanan sonuçlar ışığında sunulan çok-lu veri saklama altyapısının geçerliliği tartışılmaktadır.
2 Problem Tanımı
KKBS sistemleri, hassas veriler ile çalıştıkları için bütünlük, tutarlılık, bağımsızlık ve dayanıklılık özelliklerinden dolayı genellikle İlişkisel Veri Tabanı Yönetimi Sistemi (Relational Database Management System - RDBMS) temelli çözümleri benimse-mektedir. Bu makalede konu edilen örnek olay çalışmasında da, HAVELSAN bünye-sinde geliştirilen, ilişkisel veri tabanı üzerinde çalışan, NATO destekli JC3IEDM (The Joint C3 Information Exhange Data Model) [6] veri modeli kullanan ve duraksız
veri üzerinden entegrasyon ihtiyacı bulunan bir KKBS’nin, duraksız verileri saklama konusunda yaşadığı problemler temel alınmış ve bu problemlere olası çözüm yolları önerilmiştir.
KKBS uygulamasının çalışması sırasında yazma ve sorgulama performansını etki-leyecek en önemli etkenlerden biri kullanılan veri modelidir. KKBS uygulama altlığı olarak seçilen JC3IEDM veri modeli, asgari veri yedekliliği temel alınarak 3NF (Third Normal Form) olarak tasarlanmıştır. JC3IEDM, modelleme konusunda başarılı olsa da KKBS altlığı olarak kullanıldığı ve yoğun sorgulara maruz kaldığı durumlarda normalize yapısından kaynaklanan birleştirme (join) işlemleri nedeni ile istenilen performansı gösterememektedir.
Sorgu performansının artırılması için Şekil 1’de görüldüğü gibi gerçekleşmiş görü-nümler (materialized view) kullanılarak denormalize bir yapı elde edilmiş ve sorgu esnasındaki birleştirme maliyetlerinden kurtulma yoluna gidilmiştir. Bu durum, sorgu ağırlıklı ve nispeten aralıklı veri kaydı yapıldığı durumlarda kabul edilebilir bir per-formans sergilese de veri girişinin yoğun olduğu durumlarda yetersiz kalmaktadır. Özellikle dış veri kaynaklarından alınan duraksız verinin geçmişe yönelik saklanması veri tabanına yapılan kayıt işlemlerinin sayısını artırdığından güncel veriler üzerinden işlem yapılabilmesi için kullanılan gerçekleşmiş görünümlerin sıkça güncellenmesi gerekmektedir. Bu durum, genel sorgu performansını olumsuz etkileyerek durum sergilemede gecikmelere sebebiyet vermektedir.
Şekil 1. Güncel KKS Mimarisi
Karşılaşılan diğer bir sorun ise teknolojik olarak ödünleşen (trade-off) isterlerdir. KKBS bünyesinde işlenen duraksız verilerin geçmişe yönelik saklama isteri olduğu durumlarda (fiziksel silme, güncelleme yapılmadan) saklanan veri boyutu çok büyü-mekte ve verilerin işlendiği sorgular uzun süreler alabilbüyü-mektedir. Bu durumda, geçmi-şe yönelik duraksız veri saklama ve performans isterleri arasında ödünleşme durumu ortaya çıkarmaktadır.
Karşılaşılan bu tip sorunların çözümü için veri saklama yönteminin değiştirilmesi gerekmektedir. Ancak bu yöntem hem maliyetlidir hem de kullanımda olan KKBS’ler için uygulanabilir değildir.
3 Çoklu Veri Saklama Mimarisi
Çoklu veri saklama altyapısının temelinde “çoklu veri saklama çatısı” bulunmaktadır. Bu çatı içinde, Java Persistence API (JPA) [4] ile uyumlu olarak veri tabanı tabloları
ve uygulama tarafından kullanılan nesneler arasından eşleme yapılabilmekte, açıkla-ma (annotation) veya XML tabanlı yapılandıraçıkla-ma ayarları okunup uygulanabilmekte, yazılan sorgular biçimlendirilip işlenebilmektedir.
Çoklu veri saklama çatısı, yapılandırma ayarlarına göre birden fazla veri tabanı bağdaştırıcısı ile etkileşime geçebilmektedir. Veri tabanı bağımlı işlemler bağdaştırıcı bileşenler içine saklanmış, çoklu veri saklama çatısı içindeki işlemler ise tamamen JPA standardına uyumlu olarak geliştirilmiştir.
Çoklu bağdaştırıcı kullanan işlemler, varlıklar içindeki özniteliklere yapılan açık-lama (annotation) temelli eşlemelere göre ayrıştırılır ve ilgili veri tabanı bağdaştırıcı-sına yönlendirilir. Benzer şekilde, yapılan sorgu sonucu birden fazla veri tabanı bağ-daştırıcısı üzerinden toplanır ve çoklu veri saklama çatısı altında tek bir nesne içine toplanarak sorgu sonucu olarak sunulur.
Şekil 2. Çoklu Veri Saklama Altyapısı
İstemci uygulama tarafından yapılan bir “persist” isteği, konfigürasyona göre İliş-kisel Veri Tabanı veya Cassandra Veri Tabanlarından birisi kullanılarak saklanabildi-ği gibi (Polystore [7]), “persist” istesaklanabildi-ği ile gönderilen verinin bir kısmı İlişkisel Veri Tabanı diğer bir kısmı da Cassandra Veri Tabanında saklanabilmektedir (Polyglot [8]).
Benzer şekilde, istemci uygulama tarafından yapılan bir “read” isteği, konfigüras-yona göre kullanılan veri tabanlarından birine giderek veriyi çekebildiği gibi (Polysto-re), parçalı şekilde her iki veri tabanında saklandığı durumlarda her iki veri tabanına birden giderek ilgili kısımları toplamakta ve kullanıcıya farklı veri tabanlarında sakla-nan kısımları birleştirerek bütün bir nesne yapısı içinde sunmaktadır.(Polyglot).
Şekil 2’de gösterildiği gibi istemci uygulamalar altyapı ile JPA arayüzü üzerinden haberleşmektedirler. Başka bir deyişle istemci uygulama tarafından yapılan tüm veri saklama, okuma ve sorgulama işlemleri JPA kullanılarak standart bir arayüz üzerin-den gerçekleştirilmektedir. Çoklu Veri Saklama Altyapısı, JPA üzerinüzerin-den yapılan bu istekleri önceden yapılmış konfigürasyona göre farklı veri saklama teknikleri kullana-rak gerçekleştirmektedir. Bu sayede istemci uygulamalar aynı JPA arayüzlerini kul-landıklarından veri saklama yöntemi değişikliklerinden soyutlanmaktadırlar.
4 Örnek Olay Çalışması
KKBS entegrasyonları kapsamında alınan verinin içeriği genellikle iz, izin durumu ve konumu bilgilerini barındırmaktadır. Bu bilgiler incelendiğinde, en sık değişen veri-nin konum verisi olduğu gözlemlenmiştir. Bu bölümde, duraksız verilerin JC3IEDM
veri modeline kaydedilmesi esnasında darboğaz yaratan iz ve iz konumu ile ilgili veriler temel alınarak bir örnek olay çalışması ortaya konmuştur.
Duraksız iz ve iz konumu verisi sağlayabilmek için TCP-IP protokolü üzerinden veri sağlayacak olan sentetik veri üretici yazılım kullanılmıştır. Duraksız veri, ilk önce ilişkisel veri tabanı, sonrasında ise çoklu veri saklama altyapısı kullanılarak işlenecektir. Çoklu veri saklama altyapısı içinde iz bilgileri ilişkisel veri tabanı, izin konum bilgileri ise sütun temelli veri tabanı üzerinde tutulacak şekilde saklanıp çeki-lecektir. Her iki durumda da okuma ve yazma süreleri kayıt altına alınacaktır. 4.1 Deney Düzeneği ve Sentetik Veri Üretici
İlgili örnek olay çalışması için, Intel Core i7 işlemci ve 16 GB RAM özellikli dona-nıma ve Windows 8 işletim sistemine sahip bir çalışma ortamı kullanılmıştır. Sentetik veri üretici uygulaması ve veriyi işleyen uygulamalar aynı ortamda çalıştırılmakta, veri tabanı sunucuları ise aynı özelliklere sahip farklı ortamlarda çalıştırılmaktadırlar.
Simülatör tarafından oluşturulan sentetik veri içeriği yapısı temel iz bilgileri ve iz konumu verilerinden oluşmaktadır.
4.2 RDBMS Örnek Olay Çalışması
RDBMS örnek olay çalışması kapsamında kullanılan veri tabanı modelinin gerçek duruma en yakın sonuçları verebilmesi için JC3IEDM’e uygun bir veri modeli yapısı kullanılmıştır. Buna göre iz bilgilerinin saklanabilmesi için “object_item” tablosu, ize ait konum bilgilerinin saklanabilmesi içinse “location” ve “ob-ject_item_location” tabloları kullanılmıştır.
İlişkisel veri tabanı olarak kolay erişilebilir ve açık kaynaklı olmasından dolayı MySQL (5.7.13-log sürümü) [2] kullanılmıştır. Java tabanlı örnek uygulama ve veri tabanı arasındaki bağlantı Spring Data JPA (2.1.3.RELEASE sürümü) ile sağlanmış-tır.
Sentetik veri üreticiden gelen veriler, ilişkisel veri tabanı için kullanılan veri mode-line dönüştürülerek JPA çatısı kullanılarak MySQL veri tabanına saklanmakta ve çekilmektedir. Bu kapsamda alınan sonuçlar bölüm 4.4’de sunulmuştur.
4.3 Çoklu Veri Saklama Altyapısı Örnek Olay Çalışması
Çoklu veri saklama altyapısı örnek olay çalışması kapsamında, hem ilişkisel hem de sütun tabanlı veri tabanları kullanılmıştır. Bu kapsamda ilişkisel veri tabanı olarak bölüm 4.2 ile uyumlu şekilde MySQL (5.7.13-log sürümü), sütun temelli veri tabanı olarak da Apache Cassandra [1] kullanılmıştır. Buna göre temel iz bilgisi ilişkisel veri tabanında saklanırken, duraksız akan konum verisi ise sütun temelli veri tabanı üze-rinde saklanacaktır.
Sütun temelli veri tabanı kullanımı için Şekil 3’de belirtilen veri yapısı sadece ko-num bilgisi için değiştirilerek Şekil 4’teki gibi güncellenmiştir. Buna göre “ob-ject_item” tablo yapısı yine ilişkisel veri tabanında saklanacağından aynen korun-muş, “object_item_location” tablosu ise sütun temelli veri tabanı için kullanımı olmadığından dolayı çıkarılmıştır. Konum ve iz arasındaki ilişki ise “location” tablo-sundaki “trackId” alanı üzerinden kurulmuştur.
Şekil 4. Çoklu Model Veri Tabanı Modeli
İki farklı veri tabanı teknolojisi kullanılarak saklanan iki ayrı tablo üzerinde yaz-ma ve okuyaz-ma işlemlerinin aynı anda gerçekleştirilebilmesi için bir önceki bölümlerde bahsedilen “çoklu veri saklama çatısı” geliştirilmiş, böylece tek bir yazma ve okuma komutu ile ayrı veri tabanları ve ayrı tablolara veri yazılıp okunur hale getirilmiştir. Burada geliştirilen çatı genel olarak farklı veri tabanı yapılarına münferit “veri kayna-ğı” atanabilmesine ve gerekli işlemlerin bu kaynak üzerinden yapılabilmesine olanak sağlamaktadır. Bu sayede farklı veri tabanı teknolojilerinin güçlü yanlarının aynı anda kullanılabilmesine olanak sağlanmıştır.
4.4 RDBMS ve Çoklu Veri Saklama Altyapısı Örnek Olay Çalışması Karşılaştır-ması
Veri saklamak için kullanılan çoklu ve ilişkisel veri tabanı çözümünü karşılaştırmak için yazma ve okuma sorguları yürütülmüştür. Kullanılan veri modeline göre bir izin konumu güncellenmek istendiğinde geçmişe yönelik veri saklama zorunluluğundan
dolayı, konum verisi tabloya yeni bir kayıt olarak girilir, var olan değer silinmez ya da güncellenmez. Bu sebeple silme ve güncelleme sorguları kapsam dışı bırakılmıştır.
Karşılaştırma için kullanılan sorgular aşağıda belirtilmiştir:
1000 konum güncelleme: Duraksız veri ile alınan, 1000 konum verisinin aynı anda geldiği durumun yansıtılması amacı ile kullanılmaktadır.
10000 konum güncelleme: Duraksız veri ile alınan, 10000 konum verisinin aynı anda geldiği durumun yansıtılması amacı ile kullanılmaktadır
Tüm izlerin okunması: Duraksız veriden gelen konum verileri göz ardı edilerek sadece ize ait verilerin okunması durumu.
Bir ize ait tüm konumların geçmişe yönelik okunması: Duraksız veri üzerinden gelen konum verileri kaydedildikten sonra, bir ize ait tüm konum verilerinin geçmişe yöne-lik okunması durumu.
Bir izin en güncel konumunun okunması: Duraksız veri üzerinden gelen konum verile-ri kaydedildikten sonra, bir ize ait en güncel konum veverile-risinin okunması durumu.
Çoklu veri saklama ve RDBMS çözümlerinin yukarıda bahsedilen sorgular üze-rindeki performansları aşağıdaki şekillerde görselleştirilmiştir. Buna göre Şekil 5’te iz konumu güncelleme verileri gösterilmektedir. Çoklu veri saklama altyapısı ile yapılan güncelleme işlemleri ilişkisel veri tabanı üzerinden yapılan güncelleme işlemlerine oranla daha iyi bir performans sergilemektedir. Özellikle anlık güncellenecek konum sayısı arttıkça performans farkının da önemli ölçüde arttığı gözlemlenmiştir.
Şekil 7 kapsamında sadece iz bilgisinin saklandığı durumdaki performans karşılaş-tırması gösterilmektedir. Bu şekil, çoklu veri saklama yapısının sadece ilişkisel veri tabanı kullandığı durumu göstermektedir. Çoklu saklama altyapısı ile ilişkisel veri tabanı kullanılan durum arasında az bir performans farkı gözlemlenmektedir. Bunun sebebi ise çoklu veri saklama yapısında var olan veri tabanı bağdaştırıcısına yönlen-dirme işleminden kaynaklanan gecikmedir.
Şekil 6 ve Şekil 8’de ise kaydedilen konum verileri üzerinden yapılan sorgulama iş-lemlerinin performans karşılaştırılması verilmiştir. Hem güncel konum hem de geç-mişe yönelik konum okuma işlemlerinde çoklu veri saklama altyapısı kullanılan du-rumlarda performans artışı gözlemlenmektedir. Özellikle, var olan iz konum sayısı arttıkça bu performans farkının da arttığı gözlemlenmektedir.
Şekil 5. Konum Yazma Şekil 6. İze Ait Konumların Okunması (Geçmişe Yönelik)
Şekil 7. İzlerin Okunması Şekil 8. İze Ait Son Konumun Okunması
5 Sonuç
Yapılan örnek olay çalışması sonucunda, geliştirilen çatı ve oluşturulan çoklu veri saklama yaklaşımının, bileşenlerin güçlü özelliklerini sisteme kazandırma noktasında başarılı olduğu gözlemlenmiştir. Hem ilişkisel veri tabanlarının güçlü özelliklerini muhafaza etmek, hem de ilişkisel olmayan veri tabanlarının güçlü yönlerini sisteme kazandırmak mümkün olmuştur.
Verilen ölçüm süreleri temel alındığında, yazma ve okuma hızlarında yüksek fark-ların olması beklenen bir sonuçtur. Dolayısıyla aslında hem mevcut sistemlerin bu yapıya evrilmesinin, hem de gelecekte yapılacak çalışmaların bu kapsamda değerlen-dirilmesinin, bu alanda kronikleşmiş birçok problemin çözülmesine olanak sağlayaca-ğı değerlendirilmektedir.
Kaynakça
1. The Apache Software Foundation: Apache Cassandra, http://cassandra.apache.org/ 2. Oracle Corporation: MySQL Enterprise Edition, https://www.mysql.com
3. Polyglot Processing, http://datadventures.ghost.io/2014/07/06/polyglot-processing
4. Oracle Corporation: Java Persistence API,
https://www.oracle.com/technetwork/java/javaee/tech/persistence-jsp-140049.html
5. Wiese, L.: LWA 2015 Workshops: KDML, FGWM, IR, and FGDB. Polyglot Database Architectures. pp. 422-426, [Trier, Germany] (2015).
6. Multilateral Interoperability Programme (MIP) : The Joint C3 Infor-mation Exhange Data Model (JC3IEDM), Greding (2012)
7. Karimov, J., Rabl, T., Markl, V.: Molecular Orientation and Emission Characte-ristics of Ir Complexes and Exciplex in Organic Thin Films. pp. 24-41, Cham, (2019).
8. Araújo, A., Times, V., Urbano, M.: Int'l Conf. Internet Computing and Internet of Things. PolyEHR: A Fra-mework for Polyglot Persistence of the Electronic He-alth Record. pp. 71-77, [Las Vegas] (2016).
