Etiket: <span>Ruby (Ruby on Rails)</span>

Merhabalar, Ne zamandır arkadaşlarım rails için yazılım geliştirme ortamı sorup duruyorlar, aslında ortada çok fazla alternatif olduğu için kafa karışıklığına neden olabiliyor. Son (bir windows sunucu da host etmek zorunda…

Bilgisayar Ruby (Ruby on Rails)

Merhabalar,

Birkaç arkadaşım yazıları okuduktan sonra Kyoto Cabinet’in sorgu performansını merak etmiş. Bunun üzerine küçük bir çalışma ile sorgulama performanslarını sizlerle paylaşmak isterim.

Hemen sonuçları yazmakta fayda gÖrüyorum :)

MySQL üzerinden daha Önceki yazılarımda yer alan konfigurasyon ile (engine: Innodb, primary key üzerinden sorgulama yapılıyor.) 100 thread ile 1.000.000 kayit 48.56 sn’de sorgulanmıştır.

KyotoCabinet üzerinden daha Önceki yazılarımda yer alan konfigurasyon ile (engine: Hash, ek parametreler DB::OCREATE | DB::GCONCURRENT ve key üzerinden sorgulama yapılmıştır) 100 thread ile 1.000.000 kayit 4.54 sn’de sorgulanmıştır.

Şaka değil gerçek.

Bilgisayar Ruby (Ruby on Rails)

Merhabalar,

Bir Önceki yazımızda Ruby üzerinden KyotoCabinet’e 1.000.000 (1 milyon) veri girişini çok kısa bir sürede tamamlamıştık. Daha sonra içime bir kurt düştü, acaba mysql’de durum nasıldı? Yani aynı koşullar altında mysql veri tabanına 1.000.000 kayıdı kaç sn içerisinde yazabilecektim?

Makinanın Özelliklerini bir Önceki yazımızda vermiştim.

Bu işlemin testi için Öncelikle kendimize oldukça hızlı olduğuna inandığım, KyotoCabinet’in Ruby arabiriminde olduğu gibi C dili ile yazılmış MySQL/Ruby bir arabirim kütüphanesi buldum ve 2.8.2 versiyonunu kurdum. Bununla beraber MySQLClient versiyonunun 5.1.41 olduğunu sÖylemeliyim.

Daha sonra key, value tutacağımız bir veri tabanı oluşturdum. Öncelikle MyISAM motorunu kullanan bir tablo oluşturdum ve testlerimi bu tablo üzerinde yaptım.

CREATE TABLE `kyoto_cabinet`.`simple_table` (
  `key` CHAR(12) UNICODE NOT NULL,
  `value` CHAR(12) UNICODE NOT NULL,
  PRIMARY KEY (`key`)
)
ENGINE = MyISAM
CHARACTER SET utf8 COLLATE utf8_turkish_ci;

Bilgisayar Ruby (Ruby on Rails) SQL

Merhabalar,

Bir Önceki yazımıza kaldığımız yerden devam ediyoruz. Bu sefer Kyoto Cabinet’in insert (kayıt ekleme) performansını inceleyeceğiz.

Öncelikle bu bir performans çalışması olduğu için makinamın Özelliklerini verelim;
– 2 x AMD Athlon x64 3800+
– 2 G Ram
– Ubuntu 10.04 LTS
– FileSystem ext4
– Ruby 1.8.7 (2010-01-10 patchlevel 249)
– KyotoCabinet 1.2.2
– KyotoCabinet ruby kütüphanesi 1.14

En azından bu Özelliklerle yapılan bir test sizleri kodu kendi makinanıza alıp denemeniz için cezbedebilir. Sonuçta bir Önceki yazıdan kurulum işlemleri uygulayıp sonrasında aşağıda belirteceğim kod parçasını uygulayacaksınız. Sonuçları benimle paylaşabilirsiniz.

require 'kyotocabinet'
include KyotoCabinet

DB::process('subscribers.kch') { |db|
  # resmi sitede yer alan Örneklerde set_encoding olarak gÖsteriliyor fakat aslında tune_encoding olmalı.
  db.tune_encoding('utf-8')

  # Telco sektÖründe çalıştığımız için, numara bir MSISDN'e benziyor degil mi :)
  start_number = 905000000000

  start_time = Time.now
  puts "sira;gecen_sure;toplam_gecen_sure"
  100.times { |index|
    first_loop_start_time = Time.now
    10000.times {
      start_number += 1

      # Evet alt satirda KyotoCabinet üzerinde "Insert" islemi yapıyoruz.
      db[start_number] = start_number
    }
    loop_elapsed = Time.now.to_f - first_loop_start_time.to_f
    total_elapsed = Time.now.to_f - start_time.to_f
    puts index.to_s + ";" + loop_elapsed.to_s + ";" + total_elapsed.to_s
  }

  puts "1.000.000 kayit eklenmistir. Toplam süre: " + (Time.now.to_f - start_time.to_f).to_s
}

ruby kyoto_test01.rb > output.csv ile çalıştırırsanız çıktı dosyasını bir office programında açar ve performans analizinizi daha hızlı yapabilirsiniz. Unutmadan uygulamayı Netbeans veya Scite gibi editÖrlerin üzerinden çalıştırmayın toplamda benim makinamda 3 sn gibi fazlalıklara neden oldular.

İşte benim makinam üzerindeki sonuçların bir Özeti;

Bilgisayar Ruby (Ruby on Rails)

Merhabalar,

Uzun bir aradan sonra kendimde tekrar yazı yazabilecek enerjiyi bulabildim. Nasıl mı? Aslında ben de bilmiyorum. Yeni doğan kızım Nil (evet, artık benim bir kızım var, kendisi daha 22 günlük :) ) nedeniyle evde çok neşeli bir telaşımız var ama yine de bir cumartesi akşamı ben bu yazıyı yazabiliyorum.

Ayrıca bugünün cumartesi olması ve şu saatlerin de akşam olması ve artık bir kızımın olması nedeniyle ilk kez akşam gezintileri için “benden geçmiş” demek zorunda hissettim kendimi. :)

Neyse konumuza dÖnelim, konumuz Kyoto Cabinet‘in ruby’de kullanılması olacak. Öncelikle

Kyoto Cabinet nedir;
Aslında bilenler var ise Kyoto Cabinet, Tokyo Cabinet gibi, Memcache gibi yüksek performanslı non-relational (türkçe çevirisi için ‘ilişkisiz’ den daha iyi fikri olan sÖylesin) veri tabanı sistemidir. Limitleri oldukça yüksektir ve performans konusunda gerçekten dudaklarınızıda uçuklatabilir. Kesinlikle oracle, mysql veya postgre gibi relational (ilişkili) veri tabanı sistemleri ile kıyaslanmamadır. Bu elma ile armut kıyaslanması gibi olur.

Kyoto Cabinet aslında “Key” ve “Value” ikilisini bir veri tabanında (bir dosyada) tutmak ve yÖnetmek için yapılandırılmış bir kütüphanedir. Bir dosya üzerinde yer alan Key ve Value alanları farklı uzunluklara sahip ve farklı tiplere sahip olabilir. Ayrıca bu kayıtları B-Tree veya Hash olarak tutabilmektedir.

Peki hemen aklınıza bir soru gelebilir. Nedir bu B-Tree ve Hash denen arkadaşlar? Sayfaları ziyaret edin, kullanın Öğnenin diyorum başka da birşey demiyorum. Yaptığınız işe gÖre, kullanmanız gereken algoritmaya gÖre seçeceğiniz yapı yazılım performasını etkileyen en büyük unsur olacaktır. Ve malesef bunların bir tanesi hepsini dÖvmüyor/dÖvemiyor.

Hadi Kyoto Cabinet kuralım
0- Linux’da çalışıyor. Benim kullandığım ubuntu üzerinden kurulumu anlatacağım.

Bilgisayar Ruby (Ruby on Rails)

Merhabalar,

Öncelikle karşılaştırma derken, nasıl bir karşılaştırma yapacağımızı anlatmalıyım. Performans işlemleri karşılaştırma kriterlerim içerisinde bulunmuyor, bundan hiç bahsetmeyeceğim. Ama kodun okunabilirliği, hızlı yazılması, hatalara karşı ne kadar duyarlı olduğu ve tabii ki en Önemlisi tekrar kullanabilirliği.

Aslında bu son nokta yani ‘tekrar kullanılabilirlik’ başlı başına bir yazı konusu ama buna şimdilik pek değinmeyeceğim. Başlıkta yazdığı gibi dosya işlemlerini karşılaştıracağım.

Arşılaştırmayı sadece VBScript, JScript ve Ruby arasında yapacağım, neden mi ? hali hazırda yapmıştım da ondan.. bu yazıyı yazacağım diye oturup program yazmadım. Önce programları yazdım, sonra yazıyı yazmak aklıma geldi. Bu nedenle neden diye sormayın. :)

Ama belki daha sonraki zamanlarda Java ve C# versiyonlarının karşılaştırmalarını da eklerim.

Öncelikle sizlere problemden bahsedeyim.

Belirli bir server üzerinde ps ve txt (post script ve text) dosyaları online bir uygulama tarafından oluşturuluyor, daha sonrasında online uygulama üzerinden kullanıcı bu dosyaları temizlemeyi unutuyor ve dosya sisteminin şişmesi ile beraber performans problemleri ortaya çıkıyor. Bu nedenle dosyaların gün bazında Ömürlerinin olmasına ve Ömrünü doldurmuş olan dosyalarında sistem tarafından silinmesine, silme işlemi esnasında log almasını ve bu loglarında aynı Ömür kuralına tabii olmasını istiyoruz… işte bu program bu işi yapacak.. günde bir kez çalışacak ve bu işlemi yapacak. Microsoft Windows sistemde çalışmasını istediğimiz için VBScript ve JScript’de (JavaScript’in bire bir aynı klonu) ve platform bağımsız olan Ruby’de yazıldı. İşte Ruby Örneği;

Bilgisayar Ruby (Ruby on Rails)

Merhabalar,

Şu zamana kadar yazdığım yazılarda Ruby ile ilgili pek çok konuya değindik, bu konular arasında POP3 ve SMTP, HTTP ve FTP, Dosya İşlemleri, Çalışma zamanı, Module yapısı, Hata yakalama, Resim işlemleri, ODBC veri tabanı bağlantısı, Ruby nesnelerinin karşılaştırılması gibi konular mevcut. Aslında tüm bu yazılardan küçük bir kitap bile çıkabilirdi ama elbetteki yazım dilinin tekrar bir elden geçirilmesi gerekli. Her neyse, şu zamana kadar yazdığım yazılar umarım sizlerin de işine yaramıştır :). Benim yaradı valla, ben Ruby ile ilgili bazı konularda kendi bloğuma bakıyorum :).

SÖzü uzatmadan başlıktan da anlaşılacağı gibi yazımızın konusuna yani Thread’lere(Türkçe’sini tam kestiremedim, hoşgÖrün lütfen) geçelim. Şimdi eğer bir yazılımcıysanız, daha Önceden Multi-Thread uygulamalar ile uğraşmıssanız, kolay bir konu olmadığını bilirsiniz. Gerçekten Özellikle zor zamanlarda çok uyuz bir konu olabilir. Tüm bunlardan Öte, yapımı ve tasarlanması çok pahalıya patladığı için, yazılımcılar tarafından pek tercih de edilmez. Ama işler Ruby’de biraz daha farklı, çünkü Ruby’de bu işlemler oldukça basit ve etkileyici :).

Bilgisayar Ruby (Ruby on Rails)