Archive for the ‘veritabanı sistemleri’ Category

Mysql rolling record appender procedure

Tuesday, January 24th, 2012

Bir tablo üzerinde bir alana bağlı kalarak son birkaç kaydı tutmam gerekti, ben de bir prosedür yazdım. Bu prosedür önce yeni kaydı yapıyor, ardından son kaydı bularak (örnekte 3 kayıda göre çalışıyor) ondan eski kayıtları siliyorum. Bütün bu işlemleri de transaction içerisinde yaparak daha da sağlıklı çalışmasını bekliyorum.

DELIMITER $$
CREATE DEFINER=`dbuser`@`%` PROCEDURE `update_visits`(_member_id int, _last_visit datetime)
BEGIN
declare _max_date date;
start transaction;
insert into VISITS (member_id, last_visit) value (_member_id, _last_visit);
select last_visit into _max_date from VISITS where member_id = _member_id order by last_visit desc limit 2, 1;
delete from VISITS where member_id = _member_id and last_visit < _max_date;
commit;
END

Apache Pig ile Veri İşleme

Monday, September 12th, 2011
Hadoop üzerindeki verileri işlemek amacıyla SQL syntax’ına benzer bir dil olan Apache Pig projesini inceliyorum. Örnek olarak log dosyalarındaki ip adreslerini gruplayarak gösteren bir Pig scripti yazdım, şöyle:

/**
* @author haqen
*/
register pig-utils.jar;
A = LOAD ‘error.log’ using com.haqen.pig.MyCustomLoader() AS (in: map[]);
B = FILTER A by in#’_ip’ is not null;
C = GROUP B by in#’_ip’;
D = FOREACH C GENERATE group, COUNT($1) as ip_count;
E = FILTER D BY ip_count > 1;
F = ORDER E BY ip_count DESC;
G = LIMIT F 30;
DUMP G;

Log’u parse etmek için kendi Loader’ımı yazdım. Bu yaştan sonra SQL öğreniyormuş gibi, öğrenmesi sıkıcı ama sonuç alınca keyifli oluyor. Buna alternatif olarak Hive projesi var, onu da kullanıyorum ancak Hive daha ziyade işlenmiş veri üzerinde analiz yapmaya yarıyor diye düşünüyorum. Pig ile ise Map Reduce yazamadan, Java ile uğraşmadan analiz yapabiliyorsunuz. İncelemeye devam edeceğim.

mysql’de prepared statement’la dinamik sql çağırma

Tuesday, September 28th, 2010

Projelerden bir tanesinde loglar aylık isimlendirilen tablolarda tutuluyor. Bir stored procedure yardımı ile logdaki hataların sayısını almak istediğim zaman tablo ismi dinamik olduğu için dinamik sql yazmak gerekti. Mysql ile dinamik sql oluşturmak için prepared statement’lar kullanılıyormuş.

Son 1 saat içerisinde Fail olmuş logların sayısını alan procedure şöyle birşey oluyor bu durumda:


DELIMITER $$

DROP PROCEDURE IF EXISTS `project`.`proc_error_logs`$$
CREATE DEFINER=`project`@`%` PROCEDURE `proc_error_logs`()
BEGIN
set @dyn_sql=concat('select count(*) from project_log_', date_format(now(), '%Y%m'), ' where LOG_STATUS=\'Failed\' and LOG_TIME > date_sub(now(), interval 1 hour)');
prepare s1 from @dyn_sql;
execute s1;
deallocate prepare s1;
END$$

DELIMITER ;

Prepared statement’lara parametre de geçebiliyorsunuz, sql cümlesi içerisinde ? deyip execute ifadesinde using deyip ard arda verebiliyorsunuz, şöyle:

EXECUTE s1 USING @min_val;

işinize yaraması dileğiyle…

Sunucularınızı öldürmek için yapılması gereken 6 madde

Saturday, August 28th, 2010

Ölçeklenebilirlik (Scalability) konusunu zor yollardan öğrenmiş Steffen Konerow isimli şahsın yazdığı güzel bir yazı buldum. Yazıda 1 milyon kullanıcının ziyaret ettiği bir web uygulamasının nasıl çöktüğü, çöküşe engel olabilmek için neler yaptıkları ve hatalarını çok güzel anlatmış. Ben de elimin altında bulunsun diye bu 6 maddeyi yazayım dedim. (Bize soraydı biz de yardım ederdik heheh)

1. Dosyaları ağ üzerindeki bir alanda tutun ve sunucunuz ölsün. (Lokal diskte tutun ya da çok erişilen dosyaları hafızada (ramdisk) tutun.)

2. Web sunucunuzun ayarlarıyla oynamayın direkt kurup kullanın ve sunucunuz ölsün. (Sunucusu ayarlarında optimizasyon yapın, daha performanslı web sunucuları (ngix gibi) tercih edin.)

3. Tek bir veritabanı sizi sonsuza kadar idare eder diye düşünün ve sunucunuz ölsün. (En güçlü veritabanı sunucunun bile bir limiti vardır. Limitlere ulaşmadan master-slave yapısı ya da cluster yapısına geçin.)

4. Sunucu yavaşlayınca daha iyisini alırım diyin ve sunucunuz ölsün. (Daha fazla donanıma para harcamak yerine açık kaynaklı yazılımları araştırın, mesela memcached gibi. Doğru cache’leme ile veritabanınızı rahatlatabilirsiniz.)

5. Bütün dosyaları tek bir dizinde tutun ve sunucunuz ölsün. (Çok sayıda dosyayı tek bir dizinde tutmayın, dosyaları farklı klasörlere yayın ya da farklı dosya sistemleri (ReiserFS vs) deneyin.)

6. Tamam artık süper çalışıyor daha fazla geliştirmeye gerek yok diyin ve sunucunuz ölsün (Geliştirmeyi hiç bırakmayın, sürekli öğrenin, araştırın.)

Yazının tamamı şurda: http://highscalability.com/blog/2010/8/23/6-ways-to-kill-your-servers-learning-how-to-scale-the-hard-w.html

Jopr | java monitoring uygulaması

Wednesday, September 2nd, 2009

Jopr, http://www.jboss.org/jopr adresinden detaylı bilgi alabileceğiniz, java ile yazılmış bir monitoring uygulaması. Ücretsiz ve çok geniş özelliklere sahip. Embedded Jopr, jboss içerisinde deploy ediliyor ve jboss’un en büyük eksiklerinden biri olan administration için gerekli grafik arayüzü bize sağlıyor. Jopr server sürümü ise sunucularda çalıştırılacak ufak bir jar vasıtası ile o sunuculardaki tüm cpu, memory, network vs bilgilerinin yanı sıra apache, tomcat, jboss sunucu uygulamalarının bilgilerini de monitör edebiliyor. Kesinlikle kullanmalı…