XML: Performans Katili - Another Performance Killer

XML teknolojisi yazılım dünyasının işlerini bir çok noktada kolaylaştıran ama bir o kadar da zorlaştıran bir teknoloji. Özellikle Java ile uygulama geliştiriyorsanız XML'den olabildiğince uzak durmak gerekiyor. XML parsing & generating operasyonları sırasında çok fazla String işlemi olduğu için JVM memory ve CPU kullanımı korkunç artıyor. XML'e performans diye boşu boşuna dememişler.

Bu yazımın esas amacı aslında Java uygulamarında XML kullanmanın getirdiği maliyetleri ve Dennis Sosnoski amcamızın meşhur XML Model Benchmark Test'lerini tanıtmak.

XML'in performance killer 'dan nasıl proje katiline dönüşebileceğine bakmadan evvel öncelikle neden uygulamalarımızda XML kullanmak zorunda kaldığımıza bir bakalım.

XML kullanımı, özellikle Java dünyasında Web Service'lerin yaygınlaşması ile artmaya başladı. Web Service kullanımını arttıran da hepimizin yakından bildiği SOA (Service Oriented Architecture) oldu. 2000'li yılların başında SOA'nın moda olmaya başlamasıyla, dünyaca ünlü vendor'larımız her zaman yaptıkları gibi bu kavramı da hemen suistimal etmeye başladılar. Bir metodoloji çok tuttuğunda vendor'larımızın ilk yaptığı şey, satabilmek için ortaya zorlama bir ürün çıkarmaktır. SOA'nın bu ürünü de Web Servis implemantasyonları oldu. Web Service ailesi (XML-RPC , REST, SOAP) içinde de en fazla öne çıkarılan SOAP mesajları oldu.

Halbuki SOA'nın felsefisinde tüm servis hizmetlerinin web servisler aracılığı ile verilmesi diye bir zorunluluk yoktur. SOA'da bir servise dış veya iç sistemden erişim ihtiyacı varsa öncelikle servis hizmetini veren (server) ile alanın (client) ortamlarına bakmak gerekir.

1. Durum Servis hizmetini veren ve alanın aynı java container'ında olması.
2. Durum Servis hizmetini verenin ve alanın farklı java container'larında olması
3. Durum Servis hizmetini verenin java fakat alanın farklı bir dile (ASP,C#,vs.) ait container'da olması.

1. Durumda istemci ve sunucu aynı JVM'de olduğu için zaten web servis kullanmaya gerek yoktur. Fakat dikkat edilmesi gereken konu, SOA'nın şartlarından biri olan servisler arası bağımsızlığın (loose coupling) korunmasıdır. Spring Framework 'unun da kullandığı Inversion of Control diye adlandırılan patterni bu duruma güzel bir örnektir.

2. Durumda istemci ve sunucu farklı container'da olmasına rağmen iki taraf da java olduğu için yine web servis kullanmaya gerek yoktur. İlk bakışta servis çağırmak için RMI kullanmak en mantıklı çözüm gibi gözüksede, RMI teknolojisinin http protokolü kullanmaması nedeniyle firewall ve proxy'lerde problem yaşaması, farklı java versiyonları kullanan istemci/sunucu mimarilerinde sorun yaşanması gibi sebeplerden pek tercih edilmemektedir.

Bunun yerine en mantıklı çözüm serialized java objects kullanmaktır. Serializable java nesnelerini aynı web servis mantığı ile örnekteki gibi byte array'e çevirip container'lar arasında http üzerinden transfer edebilirsiniz. Objelerin serialVersionUID 'lerini değiştirmediğiniz sürece JDK 1.3 - 1.5 arasındaki container'lar arasında bile servis çağırabilirsiniz. Serialization&DeSerialization, XML parsing'e göre çok daha hızlı, daha az memory kullanan, binary olduğu için daha az data büyüklüğü oluşturan bir işlemdir. Vakti zamanında yaptığımız testlerde özellikle büyük datalarda 30 kata yakın performans elde etmiştik. Eğer bu konuda daha yetenekli, productionda kullanmaya hazır bir API'ye ihtiyaç duyarsanız JBoss Remoting 'e bir göz atabilirsiniz.

3. Durumda istemci java'dan başka bir container olduğunda web servis kullanmaktan başka bir çare yok. Fakat bu konuda da alınabilecek önlemler var. Eğer standart web servis implementasyonlarından herhangi birini seçme imkanınız var ise SOAP'dan kesinlike uzak durun derim. SOAP çok genel amaçlar için tasarlanmış ve sistem performansını en çok düşüren bir XML protokolüdür.

XML'in sisteminizin performansına olan etkisini belirleyen 3 önemli unsur vardır:

1. XML'in yapısı

Varsayalım elimizde 100KB. büyüklüğünde 2 farklı yapıda XML dosyası olsun. Birincisinin ağaç yapısında varsayalım:

XML teknolojisi yazılım dünyasının işlerini bir çok noktada kolaylaştıran ama bir o kadar da zorlaştıran bir teknoloji. Özellikle Java ile uygulama geliştiriyorsanız XML'den olabildiğince uzak durmak gerekiyor. XML parsing & generating operasyonları sırasında çok fazla String işlemi olduğu için JVM memory ve CPU kullanımı korkunç artıyor. XML'e performans diye boşu boşuna dememişler.

Bu yazımın esas amacı aslında Java uygulamarında XML kullanmanın getirdiği maliyetleri ve Dennis Sosnoski amcamızın meşhur XML Model Benchmark Test'lerini tanıtmak.

XML'in performance killer 'dan nasıl proje katiline dönüşebileceğine bakmadan evvel öncelikle neden uygulamalarımızda XML kullanmak zorunda kaldığımıza bir bakalım.

XML kullanımı, özellikle Java dünyasında Web Service'lerin yaygınlaşması ile artmaya başladı. Web Service kullanımını arttıran da hepimizin yakından bildiği SOA (Service Oriented Architecture) oldu. 2000'li yılların başında SOA'nın moda olmaya başlamasıyla, dünyaca ünlü vendor'larımız her zaman yaptıkları gibi bu kavramı da hemen suistimal etmeye başladılar. Bir metodoloji çok tuttuğunda vendor'larımızın ilk yaptığı şey, satabilmek için ortaya zorlama bir ürün çıkarmaktır. SOA'nın bu ürünü de Web Servis implemantasyonları oldu. Web Service ailesi (XML-RPC , REST, SOAP) içinde de en fazla öne çıkarılan SOAP mesajları oldu.

Halbuki SOA'nın felsefisinde tüm servis hizmetlerinin web servisler aracılığı ile verilmesi diye bir zorunluluk yoktur. SOA'da bir servise dış veya iç sistemden erişim ihtiyacı varsa öncelikle servis hizmetini veren (server) ile alanın (client) ortamlarına bakmak gerekir.

1. Durum Servis hizmetini veren ve alanın aynı java container'ında olması.
2. Durum Servis hizmetini verenin ve alanın farklı java container'larında olması
3. Durum Servis hizmetini verenin java fakat alanın farklı bir dile (ASP,C#,vs.) ait container'da olması.

1. Durumda istemci ve sunucu aynı JVM'de olduğu için zaten web servis kullanmaya gerek yoktur. Fakat dikkat edilmesi gereken konu, SOA'nın şartlarından biri olan servisler arası bağımsızlığın (loose coupling) korunmasıdır. Spring Framework 'unun da kullandığı Inversion of Control diye adlandırılan patterni bu duruma güzel bir örnektir.

2. Durumda istemci ve sunucu farklı container'da olmasına rağmen iki taraf da java olduğu için yine web servis kullanmaya gerek yoktur. İlk bakışta servis çağırmak için RMI kullanmak en mantıklı çözüm gibi gözüksede, RMI teknolojisinin http protokolü kullanmaması nedeniyle firewall ve proxy'lerde problem yaşaması, farklı java versiyonları kullanan istemci/sunucu mimarilerinde sorun yaşanması gibi sebeplerden pek tercih edilmemektedir.

Bunun yerine en mantıklı çözüm serialized java objects kullanmaktır. Serializable java nesnelerini aynı web servis mantığı ile örnekteki gibi byte array'e çevirip container'lar arasında http üzerinden transfer edebilirsiniz. Objelerin serialVersionUID 'lerini değiştirmediğiniz sürece JDK 1.3 - 1.5 arasındaki container'lar arasında bile servis çağırabilirsiniz. Serialization&DeSerialization, XML parsing'e göre çok daha hızlı, daha az memory kullanan, binary olduğu için daha az data büyüklüğü oluşturan bir işlemdir. Vakti zamanında yaptığımız testlerde özellikle büyük datalarda 30 kata yakın performans elde etmiştik. Eğer bu konuda daha yetenekli, productionda kullanmaya hazır bir API'ye ihtiyaç duyarsanız JBoss Remoting 'e bir göz atabilirsiniz.

3. Durumda istemci java'dan başka bir container olduğunda web servis kullanmaktan başka bir çare yok. Fakat bu konuda da alınabilecek önlemler var. Eğer standart web servis implementasyonlarından herhangi birini seçme imkanınız var ise SOAP'dan kesinlike uzak durun derim. SOAP çok genel amaçlar için tasarlanmış ve sistem performansını en çok düşüren bir XML protokolüdür.

XML'in sisteminizin performansına olan etkisini belirleyen 3 önemli unsur vardır:

1. XML'in yapısı

Varsayalım elimizde 100KB. büyüklüğünde 2 farklı yapıda XML dosyası olsun. Birincisinin ağaç yapısında olduğunu,ikincinin ise tek nod'dan oluştuğunu varsayalım:
Herhangi bir XML parser ile (DOM, SAX, PULL farketmez) yukarıdaki aynı büyüklükteki 2 farklı yapıdaki dosyayı parse ettiğinizde çok farklı sonuçlar (hız, cpu ve memory kullanımı) elde ettiğinizi göreceksiniz. Birazdan bahsedeceğimiz XML Parser'in seçimi ile XML'in yapısı arasında çok yakından bir ilişki vardır.

2. XML'in büyüklüğü

XML data'sı büyüdükçe sistem performansı doğal olarak düşer. Fakat XML verisinin büyüklüğü ile sistem performansı arasındaki oran logaritmiktir. Bunun sebebi ise XML'in daha evvel bahsettiğimiz gibi çok fazla memory ve cpu kullanmasıdır. Bir JVM'de aynı anda çok fazla XML parsing işlemi olduğunda CPU bu işlemleri sıraya koymaya başlıyacak, sırada bekleyen XML nesneleri çok fazla memory kullandığından heap'i doldurmaya başlıyacak, JVM heap'in dolduğunu görünce sık sık GC (Garbage Collector) çalıştırmaya başlıyacak, GC çalışırken çok fazla CPU kullandığı ve tüm sistemi çalıştığı sürece suspend ettiği için tüm sistem tabir yerinde ise ağır çekimde ilerleyecektir. Tabii bu durum son kullanıcıya program çöktü olarak yansıyacaktır.

3. XML Model

Buraya kadar anlattıklarımıza rağmen data alışverişlerinde hala XML kullanmaya kararlı iseniz o zaman yapmanız gereken doğru XML parseri seçmek. Aynı zamanda bir SOA danışmanı olan Dennis Sosnoski 'nin eski ama hala meşhur XML Model Benchmark sonuçlarını incelerseniz, farklı test tipleri için meşhur XML API'lerin nasıl değişik test sonuçları verdiğini görebilirsiniz.

Ben genelde parser olarak çok daha hızlı olan ve az memory kullanan PULL parser'ları tercih ediyorum. Bu konuda size de XPP3 'i önerebilirim. Fakat son yıllarda VTD-XML isminde XML datasını String olarak değilde byte olarak işleyen çok hızlı bir XML parser ön plana çıktı. (world's fastest XML processor benchmark results).

Sonuç

Buraya kadar anlattıklarımızı özetlersek çok çok mecbur kalmadıkça konfigürasyon dosyası dışında XML kullanmayın derim. (Bu konfigürasyon dosyalarını okumak için de lütfen kendiniz bir API yazmaya kalkmayın, Apache Commons Configuration'ı kullanın.) Diyelimki çok mecbur kaldınız o zaman aşağıdaki önerilere kulak asmanızda fayda var:

1) SOAP'tan uzak durun ve XML'in yapısını oldukça basit tutun. XML'in yapısı ne kadar basit ise o kadar hızlı işlenir.
2) Farklı yapılarda XML veriniz var ise hepsi için aynı XML Model'ini kullanmayan. Hatta process etmeden evvel, XML'in büyüklüğüne ve yapısına bakıp en uygun XML Model'ini seçen generic bir API bile yazabilirsiniz.
3) Veri büyüklüğünün üst sınırını bilemediğiniz servislerinizi XML ile sunmayın ya da limit koyun. Test ortamlarında ortalama 100Kb.'lık datalar ile çalışırken, production'da bir servis sonucu 10MB.'lık bir XML oluşursa çok ciddi üzülürsünüz :)
4) XML operasyonlarını servisi hazırladığınız veya karşıladığınız katmanda yapın ve XML objelerini hemen basit java objelerine çevirin. Business metodları içine XML objelerini geçirmeyin.
5) Vendorların her söylediğine hemen kanmayın (hatta şüphe ile yaklaşın). Unutmayın onların hedefi daha fazla ürün satmak, sizin hedefiniz ise projenin başarılı olması.

Bu aralar AJAX'ın çok moda olması nedeniyle XML konusunda bir hatırlatma daha yapmak istiyorum. Bildiğiniz gibi AJAX 'da client/server arasındaki data alışverişini mecburen XML ile yapıyor. Developer'lar AJAX kullanırken XML yüzünden sisteme binen yükün farkında değiller. Konu açılmışken AJAX'a henüz giriş yapmayanlar Sezer Yeşiltaş'ın AJAX konusundaki blog'una bir göz atabilirler

Performans katili, projelerimizin katili olmamalı! Önümüzdeki projelerde de buna dikkat etmeliyiz!

Konuyla ilgilenmek isteyen hem .NET'ciler hem de JAVA'cılar için birkaç link vermek istiyorum:

Comparing Web service perfomances(1):
http://msdn2.microsoft.com/en-us/vstudio/aa700840.aspx

Comparing Web Service performances (2):
http://www.sosnoski.com/presents/cleansoap/comparing.html

Checklist Web Service performances:
http://msdn2.microsoft.com/en-us/library/ms979173.aspx

Ve Sun 'ın olaya yanıtı:
http://java.sun.com/performance/reference/whitepapers/WS_Test-1_0.pdf

Adobe Acrobat: Please Die!! (Expirence during old AMVG Internship days)

Don’t get me wrong, Adobe makes some fine products. But for the life of me, I think their programmers are insane.

Up until six months or so ago, I used Adobe Acrobat to view, edit, create, etc. PDF files. And what happens every time you open Adobe Acrobat? It takes 5 minutes to load all of it’s fancy schmancy dlls and plugins just so that I can view a friggin PDF!

“No more!” said I six months ago, “this shall not continue!”

So I downloaded Foxit Reader to view my PDFs in. All well and good. You may ask why I’m posting this now, six months after the fact. because even though I can view PDFs in Foxit (without the 5 minute wait for Adobe), I can’t create or edit them. So, I have to keep Adobe installed for that purpose. Luckily, though, the need to create a customized PDF happens somewhat rarely, and most of the time I can just use the Bullzip PDF Printer from MS Word or Publisher or whatever. Sometimes though, I need the more advanced features of Adobe. Such an event occurred this very eve. I needed to make a PDF form…

So, I launch Adobe Acrobat, go make myself a cup of coffee while I wait, and proceed to create said PDF. Easy peasy, no fuss, etc. All done. Close Adobe and get a terse message that Adobe needs to download critical updates.

Now, having experienced the Adobe update routine before, I wasn’t too keen about it. I declined the request to update.

But Adobe wasn’t done yet.

Not by a long shot.

An hour goes by, the customer is happy with their PDF, and I decide to relax with a short game of Hacker Evolution. Midway through level 3, the game minimizes to the task bar (it runs full screen) and Adobe asks again to be updated.

“No!” I shout, worried about the progress of my game which was interrupted. Accordingly, I click the button to dismiss the dialog and go back to my game (which paused automatically, thank goodness). I successfully finish level 3 in record time!

Okay, back to work. Now I’m writing a letter to a past due customer, asking them if they would be so kind as to pay their friggin bill. But wait! Adobe needs to install it’s updates right now!!

Now I’m irritated. I fumble through the dialog looking for the “Don’t ever ask me again, you stupid cow!” button. I know there is one; not visible, perhaps. In frustration, I click the “Download and Install Now” button. Big mistake.

So here I am 6,348 reboots later with a fully updated Adobe. Big whoop.

I summary, here are some questions for the Adobe Acrobat team:

1. Why the heck do you need to load every single possible DLL and plugin that you can think of just to view a friggin PDF?! Why!?
2. Why is Acrobat the only program in existence that requires the entire computer be restarted after every single update?! Even Windows Updates don’t need that, and they’re patching the ***-da**ed operating system. Do they need to reboot after ever update? NO! They need only one, big reboot after installing as many updates as were needed. Come on! If you can’t figure out a way to patch an application without restarting the OS each time, then you need to change careers; there is no place for you in the programmers’ kingdom.
3. Why, oh why, do you feel it necessary to insert your bloatware into every possible orifice of an OS? I don’t want nor need your program to load with Windows, consuming resources and calling home every day in case their are any updates.

Useful Links:
Foxit Reader For Windows, an excellent free PDF viewer.

And i do not expect to get a reply message from Adobe Team encouraging me for development to do a better product, My answer is ready: G me the source, i'll give you the best :)

There, I feel better now.

Computer Sayings (My Favorites)

There are two ways to write error-free programs; only the third one works.

• A printer consists of three main parts: the case, the jammed paper tray and the blinking red light.
• The programmer's national anthem is 'AAAAAAAARRRRGHHHHH!!'.
• At the source of every error which is blamed on the computer, you will find at least two human errors, including the error of blaming it on the computer.
• Beta. Software undergoes beta testing shortly before it's released. Beta is Latin for "still doesn't work."
• Computer analyst to programmer: "You start coding. I'll go find out what they want."
• Computer Science: solving today's problems tomorrow.
• Hidden DOS secret: add BUGS=OFF to your CONFIG.SYS
• Hit any user to continue.
• I wish life had an UNDO function.

• If your computer says, "Printer out of Paper," this problem cannot be resolved by continuously clicking the "OK" button.
• It said "Insert disk 3..." but only 2 fit in the drive.
• Microsoft Windows: computing While U Wait
• 665.9238429876 - Number of the Pentium Beast
• I have yet to meet a C compiler that is more friendly and easier to use than eating soup with a knife.
• My software never has bugs. It just develops random features.
• Programming graphics in X is like finding sqrt(pi) using Roman numerals.
• "To know recursion, you must first know recursion"
• Life's unfair - but root password helps!
• Mountain Dew and doughnuts... because breakfast is the most important meal of the day.
• Hey! It compiles! Ship it!
• "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
• Intel: We put the "um..." in Pentium.
• Helpdesk tip #2: When the support analyst says "Click...", wait for the rest of the sentence.
• BREAKFAST.COM Halted...Cereal Port Not Responding
• BUFFERS=20 FILES=15 2nd down, 4th quarter, 5 yards to go!
• As a computer, I find your faith in technology amusing.
• Disinformation is not as good as datinformation.
• Smash forehead on keyboard to continue.....
• Enter any 11-digit prime number to continue...
• All wiyht. Rho sritched mg kegtops awound?
• A good programmer makes all the right mistakes.
• Managing programmers is like herding cats.
• "There is an old saying that if a million monkeys typed on a million keyboards for a million years, eventually all the works of Shakespeare would be produced. Now, thanks to Usenet, we know this is not true."
• "A good programmer is someone who looks both ways before crossing a one-way street."
• C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, it blows away your whole leg.
• A computer scientist is someone who, when told to "Go to Hell," sees the "go to," rather than the destination, as harmful.
• 1010011010 - The binary number of the Beast
• APATHY ERROR: Don't bother striking any key. Application has reported a "Not My Fault" in module KRNL.EXE in line 0200:103F
• "The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a software patch and a user with an idea."

Veritabanı Nedir?

GİRİŞ

• Bu dökümanda aşağıdaki konular ele alınacaktır

1. Veritabanı tanımı
2. SQL nedir?
3. Veritabanlarının kullanım alanları
4. Relational veritabanlarının açıklanması
5. Veritabanı çeşitleri ve açıklamaları
6. Hangi veritabanı nerede kullanılmalıdır?
7. e-posta listeleri

Veritabanı nedir?

http://www.m-w.com/ adresindeki Merriam-Webster sözlüğünde bir veritabanı :

“a usually large collection of data organized especially for rapid search and retrieval (as by a computer)” olarak tanımlanır. Şuanda çalışmakta olduğum ortramdan çıkardığım tanımıysa “You know DB is most complicated arena , just behind Operating system” olarak değerlendirilmesi gerken en karmaşık ve önemli yapılardandır.

• Kitaplıklar, uygulamalar ve yardımcı programların birleşmesinden oluşur.

• Verilerin saklanması ve yönetilmesi ile ilgili konulardaki ayrıntılardan veritabanı yöneticilerini kurtarır.

• Kayıtların güncellenmesi ve kayıtlar üzerinde araştırma yapılması da mümkündür.

• SQL (Structured Query Language)

• Veritabanı dilidir. Program geliştiriciler, bir veritabanına veri eklerken, silerken, güncellerken veya sorgularken bu dili kullanırlar.

• ANSI ve ISO standardıdır.

• Select, Delete, Update, Where

SQL Nedir?

• SQL (Structured Query Language)

• Veritabanı dilidir. Program geliştiriciler, bir veritabanına veri eklerken, silerken, güncellerken veya sorgularken bu dili kullanırlar.

• ANSI ve ISO standardıdır.

• Select, Delete, Update, Where

Neden Veritabanı?

• Gerçekten veritabanına gereksinmeniz var mı?

• Veritabanları, verilerin saklanması ve yönetilmesi için kullanılmalıdır.

• Küçük bilgiler için metin dosyaları yeterli olabilir.

• Amacınızın iyi belirlenmesi gerekir.

• Veri sadece bir konuyu içeren bir listenin içinde mi?

• Sorun karmaşık mı?

• İstatiksel bir analiz mi yapmak istiyorsunuz?

• Bir yönetim mi yapacaksınız?

• Metinsel veritabanları

• Kullanım kolaylığı

• Bilimsel formüllere gereksinmeniz olacak mı?

• Veriyi paylaşma gereksinmeniz olacak mı?

• Veriyi webde sunacak mısınız?

Relational Database Modeli (RDBMS)

• Tablolardaki kayıtlar matematiksel açıdan tuple olarak tanımlanırlar.

• Bir tuple tanımlanmış bir veri tipi olan bileşenlerden oluşan sıralı grup olarak tanımlanır.

• Tüm tuplelar aynı sayıda ve tipte bileşenlerden oluşur.

• {“ab01”, “Aydın”, “2001”}.

• {“ab02”, “İstanbul”, “2002”}

• Örnekteki her bir tuple da 3 bileşen bulunmaktadır:

• Kaçıncı akademik bilişim olduğu (string)

• Hangi ilde yapıldığı (string)

• Yıl (numeric)

• Relational veritabanlarında bu “kümeye” ya da tabloya eklenen tüm kayıtlar aynı biçemde olmalıdırlar

• {“ab02”, “Aydın”}

• – eksik bileşen

• {“ab02”, “Aydın”, “2002”, “Şubat” }

• – fazla bileşen

• {2002, “ab02”, “Aydın”}

• – yanlış bileşen tipleri (yanlış sırada)

• Ayrıca tuple lardan oluşan bir tabloda aynı veriler bulunmaz.(No duplicate record). Dolayısıyla relational veritabanlarındaki herhangi bir tabloda birbiriyle tamamen aynı iki kayıt (row or record) bulunamaz.

• Bu, çok gereksiz bir sınırlama olarak görünebilir. Örnek vermek gerekirse, aynı kullanıcının aynı malı iki kez sipariş etmesi görünürde engellenmiştir. Bunu da tabloya bir bileşen ekleyerek çözebilirsiniz.

• Bir kayıttaki her bir bileşen “atomik”, yani bir veri olmalıdır; başka bir kayıt ya da diğer bileşenlerin listesi olamaz.

• Tablodaki bileşenlerin veri tipleri de üsttekilerle ve dolayısıyla tablo tanımlarındakilerle aynı olmalıdır. (Veritabanı tarafından desteklenen veri tiplerinden biri olmalıdır.).

• Birbiriyle eş kayıtları ayırmak için kullanılan bileşenlere key denir.

• referential integrity.

• Tablodaki bir kaydı diğer tüm kayıtlardan ayırmak için kullandımız bileşene, primary key adı verilir. Primary key, o kaydı “unique” yapar. Tüm relational veritabanlarında her bir tablo ya da relationda mutlaka primary key olmalıdır.

Veritabanı çeşitleri

• Öncelikle ne yapılacağına karar verilmelidir:

1. Bu veritabanı ile neler yapacaksınız? Küçük bir şirket çalışanlarının özel bilgileri mi tutulacak, yoksa büyük bir şirketin binlerce müşterilerinin bilğileri mi?
2. Sitenizi günde kaç kişi ziyaret edecek?
3. Aynı anda kaç işlem yapılacak?
4. Güvenlik ne ölçüde olacak?

Verilerinizin güvenliği ne ölçüde olacak?

Yanlış bir kanı : “Paralı ürünler iyidir, ücretsiz ürünler iyi değildir!”

Linux, bu tezi çürüten, bilgisayar sektöründeki son yıllardaki en iyi konudur.

Bir veritabanının ücretsiz olup olmamasından çok işinizi görüp görmeyeceği önemlidir.

1. Microsoft Access (Hala bankalarda kullanılan m.ö’den kalan db)
2. MySQL (tam anlamıyla sp yazamadığın nasa’nın nasıl kullandığına hayret ettiğim db)
3. IBM DB2 (Yetenekleri hiçbirzaman Oracle kadar olamayacak pahalı db)
4. Informix
5. Microsoft SQL Server (Her ms ürünü gibi kullanmaya mecbur kalacağım db)
6. PostgreSQL (Favorim – Open Source’un en kral db’si)
7. Oracle (Hala var olan en yetenekli ve gelişmis db)
8. Interbase

MS Access

• Microsoft Office ürünüdür.

• Küçük ölçekli uygulamalar içindir.

• Tablo başına 2 GB a kadar veri depolayabilir.

• Aynı anda 255 bağlantıya izin verebilir.

• Linux/MAC sistemlerinde kullanılamaz.

• “Transaction locking” özelliğine sahiptir, ancak “trigger” ve “stored procedure” özelliklerine sahip değildir.

MySQL

• MySQL Inc.

• Windows, Linux, OS/2,Solaris, AIX vb.

• “trigger” ve “stored procedure” özelliklerine sahiptir, ancak “Transaction locking” özelliği bulunmamaktadır.

• Tablo başına 2 GB veri depolayabilir.

IBM DB2

• IBM

• Access ve MySQL e göre daha performanslı, ancak küçük işletmelere göre daha yüksek maliyete sahiptir.

• *nix ve Windows üzerinde çalışabilir.

• Transaction locking”, “trigger” ve “stored procedure” özelliklerine sahiptir.

Informix

• Illustra

• Ücretli ve güçlü bir veritabanıdır.

• Orta ölçekli işletmelerin yükünü kaldırabilecek kapasitededir.

• 1994’deki Postgres kodundan geliştirilmeye başlanmıştır.

MS SQL Server

• Microsoft

• Dezavantajı: Sadece Windows üzerinde çalışabilir. Yüksek maliyet

• Kullanım kolaylığı, güvenilirliği,işlem gücü

• Maliyeti diğer veritabanlarına göre yüksektir.

• Tablo başına 4 TB veri depolayabilmektedir.

• “Transaction locking”, “trigger” ve “stored procedure” özelliklerine sahiptir.

PostgreSQL

• PostgreSQL Global Development Group

• Linux, Unix, BSD, Windows, AIX vb.

• Ücretsiz, akademik bir veritabanı

• Çok güçlü işlem yapısı

• Veri güvenliği ön planda

• Tablo başına 64 TB veri tutabilme özelliği

• “Transaction locking”, “trigger” ve “stored procedure” özelliklerine sahiptir.

• Anlıyacağınız Oracle’ın ücretsiz haline yakındır, 14tb veri tuttuğunu gözlerimle gördüm :)

Oracle

• Oracle, Inc.

• Dünyanın en güçlü ve güvenilir veritabanı olarak gösterilmektedir.

• Support konusunda sorunu olmayacak, yüzlerce tool’u olan bir efsanedir.

• Çok yüksek maliyetlidir

• Windows, Unix, Linux

• Oracle, sınırsız sayıda tabloları desteklemektedir.

Hangi Veritabanını Seçmeli?

Çok derin ve stratejik bir karar olmakla birlikte çok çok sığ bakarsak olaya;

• Küçük yoğunlukta trafik: MySQL ya da Access

• Daha büyük ve orta ölçekli uygulamalar içinse, MS SQL ya da Linux makineler ve Server'lar üzerinde PostgreSQL kullanılabilir.

• Oracle ise çok yüksek güvenilirlik ve işlem gücü gerektiğinde tercih edilen bir veritabanı sunucusudur.

Port Forwarding Nedir?

Port yönlendirmeyi anlayabilmek için IP ve Port hakkında biraz ön bilgiye sahip olmak gerekiyor, buradan gün itibariyle hakim olduğum akademik bilgi ölçüsünde olay şöyle:


Her internete girdiğimizde bir adet global IP adresi alırız, bu IP adresi tüm dünyada tekil olduğu için aslında bizim bilgisayarımızın Internet üzerindeki adresine denk gelir. Gerçekte Internete bağlantı kuran cihaz modem olduğu için aslında internete giren modemdir, modem internet bağlantısını sağlayıp sonra kendisine bağlı bilgisayar(lar)la bunu paylaşır, tüm dünyada tekil olan IP adresini de modem almış olur. Modemle bilgisayarımız arasında da küçük bir lokal network oluşur, lokal networkteki her cihazın yine birer IP adresi olması gerekeceği için, sonuç olarak bilgisayarımızın bir adet, modemin ise iki adet IP adresi olur.Modemin sahip olduğu IP'lerden biri tüm dünyada tek olan global IP adresidir, diğeri de kendi lokal networkumuzde geçerli olan lokal IP adresidir. Bilgisayarımız ile internet arasında kurulan iletişim, gerçekte bilgisayar ile modem arasında lokal ip'ler üzerinden kurulur, modem port yönlendirme yaparak bizim isteklerimizi internette ilgili bilgisayarlara yönlendirir ve bu işlem otomatik olarak gerçekleştiği için biz bunun farkına varmayız ama bazı durumlar vardır ki bu port yönlendirme işlemi otomatik yapılamaz bu durumda bizim bir takım tanımlamalar yapmamız gerekir.
Hangi durumlarda port yönlendirmeyi bizim yapmamız gerekir?
Buradaki en önemli konu, iletişimi kimin başlattığını bilmektir. Çünkü bu bizi port yönlendirmeye ihtiyacımız var mı yok mu noktasına getirecektir. Eğer iletişimi başlatan taraf biz isek herhangi bir port yönlendirme işlemi yapmaya gerek yoktur, çünkü iletişime başlarken karşı tarafa nerde olduğumuzu iletiriz. Eğer bilgisayarımıza uzaktan erişilmesini istiyorsak bu durumda iletişimi uzaktaki bilgisayar başlatacaktır ve uzaktaki bilgisayar sizin IP adresinizi ve hangi port'u kullanarak iletişim kuracağını bilmesi gerekir. Internetteki IP adresinizi en pratik olarak http://www.checkip.net adresine girerek öğrenebilirsiniz. Bunu öğrenmek yeterli olmamaktadır çünkü bu IP ile bilgisayarımıza değil ancak modemimize erişilebilir, bu durumda modem'e demelisiniz ki "dışarıdan sana gelen bu istekleri benim bilgisayarıma yönlendir". Aslında dışarıdan gelen isteklerin içinde bir de port bilgisi olacağı için modeme tam olarak şunu demelisiniz "Dışarıdan senin X portuna gelen istekleri, benim bilgisayarımın X portuna yönlendir." bunun adı port yönlendirmedir. Eğer modeme birden fazla bilgisayar bağlı ise X portundan gelenleri A bilgisayarına, Y portundan gelenleri B bilgisayarına yönlendir diyebilirsiniz. Örneğin bu bilgisayarlardan biri WEB sunucu diğeri Email sunucu olabilir. Sahip olduğunuz bir IP adresi ile modeminize bağlı birden fazla bilgisayara erişim yapılması sağlanabilir, bu nedenledir ki Port Yönlendirme işlemine bir çok yerde Virtual Server (sanal sunucu) oluşturma adı da verilir.

Dia ile çizdiğim yukarıda şekil, Windows'un Remote Desktop uygulaması ile bilgisayarınızı uzaktan kullanırken oluşan akışı gösteriyor. Uzaktaki bilgisayar 'dan Remote Desktop programını başlattığınızda size bir IP soracaktır bu IP evdeki modeminizin internete bağlanırken aldığı IP'dir e.g. 160.75.114.119'dur.
3389 portunu siz vermiyorsunuz, Remote Desktop bu portu kendisi kullanarak bağlantı sağlıyor. Sonuçta IP ve Port bilgisi ile modeminize erişim sağlanıyor, modem ayarlarında yer alan port forwarding ya da virtual server bilgisi sayesinde bağlantı isteği, evdeki lokal networkte yer alan bilgisayarınıza yani örnekteki 192.168.1.2 numaralı IP'nin 3389 portuna yönlendiriliyor. Bundan sonra artık iki program arasında sağlanan iletişim ile evdeki bilgisayarınızı uzaktaki bilgisayar ile kullanmaya başlıyorsunuz.

Port Yönlendirme veya Virtual Server tanımlama işlemi modem yönetim programı ile yapılmaktadır, görüntüsü modem üreticisine göre farklılık gösteren ama genelde web tabanlı çalışan bu arayüzlerden gerekli örnekleri web'ten de bulabilrsiniz.

Tercih edilen üreticiler, arayüzlerinin gelişmişliği sırasıyla dlink, linksys, zoomve us robotics olarak verilebilir.