SQL Server’dan ElasticSearch’e Veri Aktarımı

SQL Server’dan ElasticSearch’e Veri Aktarımı

Bu yazıda MSSQL üzerinde yer alan bir tablomuzu ElasticSearch’e nasıl aktarabileceğimiz konusuna değineceğiz.

Bu aktarımları, alanında en iyi çözüm olarak gördüğüm Logstash kullanarak gerçekleştireceğiz. Ayrıca daha sonraki güncellemeleri de yapabilmemiz için aktarımını yapacağımız tabloda arayacağımız bir özelliğimiz olacak. Bu özellikten kastım otomatik artan bir integer alan yada her kaydın eklendiği tarihi ihtiva eden bir datetime alan.

Öncelikle aktaracağımız tabloyu tanıyarak başlayalım ve adım adım ilerleyelim.

Farz edelim ki okuldaki öğretmenlerin kayıtlarını içeren Ogretmen adında bir tablomuz var. Bu tablomuzda otomatik artan bir Id alanımız mevcut ve yine her kayıt ile birlikte otomatik olarak eklenen bir KayitTarihi alanı bulunmakta.

Adım adım devam edeceğiz.

    1. Adım : Logstash Nedir?

Logstash açık kaynak kodlu ve bir çok kaynaktan data okuyarak, bu datayı isteğinize göre dönüştürüp çeşitli kaynaklara yazabilmenizi sağlayan bir araçtır. Genellikle ElasticSearch için kullanılmakta olup diğer birçok ortam içinde tercih edilebilir. Logstashi tıklayarak indirebilirsiniz. Hem Windows hem de Linux ortamında çalışabilmektedir.

Logstash temelde iki parametreden oluşur, bunlar input ve output parametreleridir. Input parametresi verinin okunacağı yeri output parametresi ise yazılacağı yeri ifade etmektedir.

Öncelikle Logstash’in MSSQL ortamından dataya erişebilmesi için jdbc driverini indirelim.

 

    2. Adım : Config Yapılandırması.

Logstash’i ve JDBC Driver’ı indirdik gelelim config yapılandırmasına. İndirmiş olduğunuz Logstash Zip dosyasını açtığınızda ve içerisinde yer alan config klasörünün içinde logstash-sample.conf dosyasyını göreceksiniz.

Gördüğünüz config üzerinde değişiklikler yapmaya başlayalım.

    2.1. JDBC Driver

İndirdiğiniz jdbc driver’ı uygun bir klasör içerisine atın ve config içerisine gerekli kodları eklemeye başlayalım.

 

 

    2.2. Sql_last_value Değerini Kullanarak Sadece Yeni Kayıtların Aktarılması

Yukardaki şekilde ayarlanan bir input alanı sql sunucusuna gidecek ve tüm tabloyu okuyacaktır. Ancak bazı tablolar çok büyük olacağı için sadece gelen yeni kayıtları aktarmak isteyebiliriz. Sql_last_value parametresi ise tam bu noktada yardımımıza yetişiyor. Sql last value parametresi belirlediğimiz bir kolonun son aktarılan değerini bir dosyaya yazıyor ve sonrasında o dosyadan geri okuyarak kaldığımız yerden devam etmemizi sağlıyor. Hemen config üzerinde görelim.

Yine jdbc parantezleri arasına aşağıda yer alan parametreleri eklemeliyiz.

 

Tüm bu işlemleri yaptıktan sonra Sql komutumuzu da biraz değiştirmemiz gerekmektedir.

 

    2.3. Output

Output parametresi ise ElasticSearch bağlantı komutlarının olduğu kısımdır.

 

 

    3. Logstash’i Çalıştırmak

Config dosyamızı da ayarladıktan sonra geriye sadece çalıştırmak kaldı. Logstash Zip dosyasını çıkardığınız klasöre gidin “bin” klastörü içerisinde Komut istemi (CMD) aracılığı ile şu komutu yazın.

 

logstash –f C:config.conf

 

İşte hepsi bu kadardı. Config dosyasında belirttiğiniz zamanlama ile logstash çalışacak ve dataları aktaracaktır. Sadece JDBC Driver’ı değiştirerek Postgresql ve Mysql gibi ilişkisel veri tabanlarından da aynı mantık ile veri aktarabilirsiniz.

 

 

Benzer Yazılar

SQL SERVER SERViS RESTART HATASI

SQL Server 2 gün önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 3 hafta önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

Query Store Nedir?

SQL 3 hafta önce

Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]

0 Yorum

Yorum Yaz

Rastgele