Nedir bu NoSQL?

Günümüzde yazılımla uğraşıp, SQL (Structured Query Language) bilmeyen ve duymayan kalmamıştır herhalde. Nasıl yabancı dil eğitimi İlkokullara kadar indiyse, SQL’in temellerinin de İlköğretim Eğitim Programı içine alıp, gençleri erken yaşta veritabanı ve onun küresel dili olan SQL ile tanıştırmanın zamanı geldi de geçiyor. Buradan Milli Eğitim Bakanlığı’na bir mesaj vermiş de olayım.

Ama bu yazının temel konusu SQL değil, NoSQL!

SQL kullanan veritabanlarının geleneksel nimetlerini anlatmayacağım. 1970’lerde IBM için çalışan iki bilim insanı, Donald D. Chamberlin ve Raymond F. Boyce tarafından tasarlanan bu veri işleme dili, bütün ilişkisel veri tabanları için neredeyse standart hale geldi ve günümüze kadar ulaştı.

Öncelikle şu fark ile başlayalım.

SQL; ilişkisel veri tabanlarında, saklanan verileri yönetmek için kullandığımız, veritbanı bağımsız bir dil.

NoSQL ise yeni bir veritabanı sistemi veya modeli olarak adlandırılabilir.

Geleneksel veri tabanı üreticileri (IBM, Oracle, Microsoft vb.) geliştirdikleri veritabanlarıyla (DB2, Oracle, SQLServer) geleneksel veri tiplerini saklamak, yönetmek üzerine tasarlanmış, verinin doğruluğunu, herzaman tutarlı ve kararlı olarak saklanabilmesini, ulaşılabilir olmasını temel kriterleri olarak önceliklendirmişler ve bunlara göre çok sağlam motorlar geliştirmişlerdir. Bu veritabanları yıllar boyunca öncelikle “mission-critical” veri saklanmasını gerektiren bütün alanlarda görevlerini yapmaya devam etmektedirler.

NoSQL olarak adlandırılan model, yukarıdaki geleneksel modelin dışında, veri saklama, veriye ulaşma ve tutarlılığının ikinci planda kaldığı ihtiyaçların daha öne çıkması ile gözüktü. Bıg Data ihtiyaçları, Web ve Mobile uygulamaların ciddi derecede artması NoSQL olgusunu çok geliştirdi. Bu modelde saklanan veriler “yapısal olmayan” verilerden oluşuyor ve “mission-critical” ihtiyaçlar genel olarak yok. Böyle beklentilerin olmadığı NoSQL veritabanları bu anlamda yatay ölçeklemeye daha yatkın olarak düşünülebilir. Daha çok iş yükünü çalıştırmak için daha güçlü sunucular kullanarak dikey büyüme yöntemi yerine, daha ucuz sunucular ile yatay büyümenin tercih edildiği, “High Availability” çözümlerinin veritabanı olanaklarından çok, yazılım geliştirme teknolojileri ile sağlandığı yeni bir dünya burası. Bu dünyada merkezi veritabanından çok, dağıtık veritabanı özendirilir. Geleneksel veritabanlarının olmazsa olmazı ACID (Atomicy, Consistency, Isolation, Durability) kuralları NoSQL dünyasında sağlanmayabilir.

NoSQL veritabanlarında, SQL dili kullanılmıyor anlamı çıkmasın. Bazı yazarlar bunu “Not Only SQL” olarak da tanımlıyorlar yani bir nevi SQL’de kullanabildiğiniz ilişkisel model olmayan veritabanı gibi.

NoSQL veritabanları veriyi saklama metodlarından dolayı “çok büyük” veriyi, ilişkisel olarak saklama ihtiyacının olmadığı, bu veriyi daha hızlı getirmek ön koşulu  üzerine tasarlanmışlardır. Yani geleneksel veritabanlarındaki gibi birbiri ile ilişkili tablolar arasındaki verileri bulup, filtreleyip, işleyip getirmek gibi ihtiyaçlara burada cevap bulmak zordur. İlişkisel Model, veriyi alır birbiri ile ilişkili tablolarda kolon/satır şeklinde saklar. Örneğin “Document Store” modelini kullanan bir NoSQL veritabanı, JSON formatında gelen verilerin her bir kümesini ayrı bir veritabanı nesnesi gibi saklar.

Istatistik Hesaplar, Gerçek-Zamanlı Analizler, sürekli, hızlı ve kontrolsüz büyüyen verilerin saklanması (Twitter) gibi alanlar en yoğun kullanım şekilleridir. Özellikle Twitter gibi uygulamalar, “extreme scale” diyebileceğimiz şekilde büyük ve ucuz ölçekleme ihtiyacı göstermektedir. NoSQL bu alanı adreslemektedir.

Günümüz uygulama geliştirme süreçleri çok hızlı beklentiler içinde olduğundan (rapid application development) ve DBA gereksinimini en aza indirmek içinde NoSQL veritabanları ilgi görmektedir.

Klasik veritabanı API’lerinin veri erişimindeki göreceli olarak “overhead”leri daha fazla olduğundan ve NoSQL API’leri bu anlamda uygulama geliştiriciler tarafından daha revaçta olmaktadır.

Şu günlerde 122’den fazla kendini NoSQL sınıfına koyan veritabanı bulunmaktadır. Daha derin teknik detayları bir başka yazı konusuna bırakarak, kendini NoSQL veritabanı olarak tarifleyenlerin 4 ana grubundan bahsedeyim. 122 ününün yaklaşık %65’i bu 4 modelden birini benimsiyor.

Key Value Stores: Key değerleri, hash olarak tutuluyor. Key kısmındaki veri kısmı ise binary olarak saklanıyor. MemcacheD, REDIS, WebSphere eXtreme Scale bu modele uyan örnekler.

Document Stores: Saklanan veriler/dökümanlar tagged elementler gibi tutuluyor. MongoDB, couchDB bu modeli kullanan NoSQL veritabanları

Column Family: Her Storage bloğunda sadece bir kolon veya kolon kümesine ait veriler saklanıyor. Hbase, Cassandra güzel iki örnek

Graph Store: Key değerleri “graph yapısı” denen bir modelleme ile ilişkilendirilip saklanıyor. Jena, Sesame iki örnek. 

Öyleki, en yukarıda örneklerini verdiğim klasik veritabanları da, mevcut motorlarına yukarıdaki dört modelden birisini seçerek, ek “NoSQL” özellikleri ekliyor.

Örneğin Oracle, Key Value Stores, kullanarak, NoSQL desteği verirken, IBM - DB2 ise  Graph Store modelini kullanarak yollarına devam edeceklerini açıkladılar. Bunun anlamı, JSON dökümanlarına, SQL ile erişilebilecek olması çok yakında. Bu olanak geldiğinde yılların SQL bilgisine sahiplik yok olup gitmeyecek ve aynı becerileri kullanarak NoSQL veritabanlarını kullanabileceğiz.

Şimdilik görünen bunlar ama bu alanda o kadar hızlı gelişmeler oluyor ki siz bu satırları okurken bile bazı şeyler değişmiş olacak.

"Big Data" nedir? Geleneksel "Veri Yönetimi"ne etkisi ne olur?

Teknolojinin yaygınlaşması, herkes tarafından ulaşılabilir olması ve kullanım biçiminin dönüşmesi, üretilen ve işlenen verinin büyüklüğünün de devasa olarak artmasını beraberinde getirdi. Nasıl ki kişisel hayatlarımızda iki üç disket veya birkaç CD'ye sığan bilgilerimiz artık 1TB'lık yüksek kapasiteli disklere zor sığar hale geldiyse, kurumlar da bu devasa hız ve çeşitlilikte artan verilerini nereye sığdıracaklarını bilemiyorlar. Büyük miktarda veri ile uğraşmak BT’nin yabancı olduğu bir konu değil fakat BIG DATA konusu, veri ambarı, ODS, iş analizi ve veri analizi başlıklarından oldukça farklı.

Verinin üretilme hızı ve çeşitliliği o kadar fazla ki, veri saklama cihazlarının teknolojileri ve üretilme hızları, bu hızın gerisinde kalıyorlar. Saklama ve veri işlemenin birim maaliyetleri azalsa da, hızlı üreyen veriyi saklamak ve işlemenin toplam maaliyeti artıyor.

- 2020'lerde toplam sayısal verinin 35ZettaByte olması bekleniyor. 1 ZettaByte = 1Milyar TeraByte. Bloglar, sosyal medya, elektronik sensörler vb cihazlar tamamen yapısal olmayan yepyeni bir dünya sunuyorlar.
- Cep telefonları, Internet'deki yapılan her tık, sayısal fotoğraf makineleri veri üreten birer fabrikaya dönüştü. Geçen on yıldan beri veri tabanı sunucularının sayısı 6 kat artarak, 32 Milyon'a çıktı.
- Mevcut verilerin %80'i yapısal değil; Eposta, fotograf, video, müzik dosyası, XML, vb şeklinde ortaya çıkan, geleneksel ilişkisel veri tabanlarında saklanmayan, “Gri Data” olarak adlandırılan “Ham” veri.
- Özellikle sağlık ve finans sektörü ile hükümetlerin "BIG DATA" konusuna daha çok kafa yormaları gerekecek. Çünkü hukuki olarak geriye dönük bu devasa sayısal bilgilerin saklanması, yedeklenmesi, arşivlenmesi ve gerektiğinde hızlı olarak erişilebilir olması gerekiyor. İlk tahminler, ABD’nin sağlık sektörünün yıllık 300Milyar Dolarlık “BIG DATA” katma değerinde iş hacmine sahip olduğu yönünde.

McKinsey'in bir raporuna göre 2010'da ABD ve Avrupa'daki toplam saklama kapasitesi 30ExaByte ama üretilen veri 1.2ZettaByte. Bu durumda üretilen ama saklanmayan, saklanmadığı için de işlenmeden yok olan veri oldukça fazla. Bu yaklaşımdan yola çıkarsak, "veri işleme" konusunda da ezber bozan çözümler üretilmesi gerekiyor. IBM, Samsung, GE Global saklama ve özellikle veriyi "kaynağında işleyecek" teknolojiler üretme konusunda çalışıyorlar.

"Big Data" olgusunu tarifleyen 5 bileşen var
-Volume (Veri Büyüklüğü): IDC istatistiklerine göre 2020'de ulaşılacak veri miktarı, 2009'un 44 katı olacak. Şu anda kullanılan, "büyük" diye adlandırdığımız kapasiteleri ve "büyük sistemleri" düşünüp, bunların 44 kat büyüklükte verilerle nasıl başa çıkacaklarını hayal etmek gerekiyor! Kurumun veri arşivleme, işleme, entegrasyon, saklama vb teknolojilerinin bu büyüklükte veri hacmi ile nasıl başa çıkacağının kurgulanması gerekli hem de hemen.

- Velocity (Hız): "Big Data"nın üretilme hızı çok yüksek ve gittikçe artıyor. Daha hızlı üreyen veri, o veriye muhtaç olan transaction sayısının ve çeşitliliğinin de aynı hızda artması sonucunu doğuruyor.

- Variety (Çeşitlilik): Üretilen verinin %80'i yapısal değil ve her yeni üretilen teknoloji, farklı formatlarda veri üretebiliyor. Telefonlardan, tabletlerden, entegre devrelerden gelen türlü çeşitlilikte "Veri Tipi" ile uğraşılması gerekiyor. Bir de bu verilerin farklı dillerde, Non-Unicode olabileceğini düşünürseniz, entegre olmaları, birbirlerine dönüşmeleri de gerekli.

- Verification (Doğrulama): Bu bilgi yoğunluğu içinde verinin akışı sırasında "güvenli" olması da bir diğer bileşen. Akış sırasında, doğru katmadan, olması gerektiği güvenlik seviyesinde izlenmesi, doğru kişiler tarafından görünebilir veya gizli kalması gerekiyor.

- Value (Değer): En önemli bileşen ise değer yaratması. Bütün yukarıdaki eforlarla tariflenen BIG DATA'nın veri üretim ve işleme katmanlarınızdan sonra kurum için bir artı değer yaratıyor olması lazım. Karar veriş süreçlerinize anlık olarak etki etmesi, doğru kararı vermenizde hemen elinizin altında olması gerekiyor. Örneğin sağlık konusunda stratejik kararlar alan bir devlet kurumu anlık olarak bölge,il,ilçe vb detaylarda hastalık, ilaç, doktor dağılımlarını görebilmeli. Hava Kuvvetleri, bütün uçucu envanterindeki taşıtlarının anlık yerlerini ve durumlarını görebilmeli, geriye dönük bakım tarihçelerini izleyebilmeli. Bir Banka, kredi vereceği kişinin, sadece demografik bilgilerini değil, yemek yeme, tatil yapma alışkanlıklarını dahi izleyebilmeli, gerekirse sosyal ağlarda ne yaptığını görebilmeli.

BIG DATA’nın temel olgusu aslında yeni birşey de değil; adı değişse de geçmişte de vardı. Internet kullanımının patlama yapması ve sanal olarak da olsa insanlığın daha çok sosyalleşmesi, birçok yeni teknolojinin ulaşılabilir ve ucuz hale gelmesi bizi bu devasa büyüyen veri okyanusunda yeni arayışlara itti. İş yapış biçimi de bizi buralara getirdi; geleneksel yaklaşımda iş sahibinin soru, sorun ve ihtiyaçlarına göre, BT mimariyi çıkartır; ihtiyaca cevap sağlardı. Günümüzde ise BT sunduğu platform ile iş sahibinin özgürce veriyi keşfetmesini sağlayacak altyapılar sunmak zorunda. Geleneksel ilişkisel veri tabanları güncelliğini, OLTP işlevini artarak yerine getirmeye devam edecek olsa da, BIG DATA’nın yeni ihtiyaçlarından dolayı, veriyi kaynağında işleyecek ya da IBM-Netezza, Oracle-Exadata, IBM-DB2 Analytical Machine vb “appliance” olarak anlamlandırılan yazılım, uygulama ve donanımı içinde barındıran çözümler ve NoSQL, Hadoop, Cassandra, JAQL, HBASE vb daha emekleme aşamasındaki çözümler BIG DATA’yı adreslemeye çalışacak.

BIG DATA yeni bir platform ve veri işleme anlayışı getirecek, zaman içinde yazılım firmalarından bu konuda onlarca çözüm çıkacak ve mevcut Bilgi Depolarına entegre edilerek büyümesi ve beraber yaşamaları kaçınılmaz hale gelecek. İlk çıkan ürünlerin çoğunluğu Açık Kaynak kodlu prototip uygulamalar olduğundan, ileri seviye danışmanlık ve küresel destek hizmetlerinden yoksunlar. Ama kurumsal sürümlerinin çıkması ve yine küresel yazılım şirketleri tarafından paylaşılması an meselesi.

BT Haber : http://www.bthaber.com.tr/?p=17464

DBA Activities

I’m working on a presentation about DBA Activities and requesting some statistics from DBAs. Would you please share your thoughts for the following two simple questions?

1) What are the TOP 5 daily routine activites of a DBA?
2) What’s the percentage of those activities in a normal business day?

Please share your thoughts as a comment in blog or send me email to cuneytgoksu@usa.net
Thank you

DB2 & HP-UX Itanium

Oracle kullanan HP Itanium müşterileri'nin dikkatine.

Oracle 12g sürümünden itibaren HP-UX platformundaki desteğini kapatıyor. Bu konuda ki alternatifleriniz için aşağıdaki linke göz atabilirsiniz.

http://smarterquestions.org/2011/05/ibm-committed-to-supporting-hp-ux-for-years-to-come/

Countering Larry Ellison's claims about DB2 - Q&A

ORACLE: "We blew the doors off of IBM. We crushed them." [Referring to
TPC-C benchmark results] In a machine that took up less than 10% the
floor space, of IBM's record setting computer. We ran faster, we ran a
lot faster: using a tiny fraction of the floor space, a tiny fraction of
the power, cost less."


IBM: Until late last year, DB2 enjoyed a massive 49% lead over Oracle.
With Oracle's most recent result, they have taken the lead by 25% (and
by the way, they used more than six times as many CPU cores to do it).
We are confident that DB2 will retain its lead this year. Also,
remember that DB2 has dominated TPC-C performance leadership over the
past seven years, with almost twice as many days of leadership as Oracle
Database.
Regarding the claim of using less space and power, this is a result of
Oracle using flash memory and comparing it with an IBM benchmark using
conventional disk technology. If Oracle compared its benchmark to an IBM
system using flash memory, they could not make these outlandish claims.
For a more detailed look at Oracle's outlandish claims, see
http://www.ibm.com/systems/migratetoibm/getthefacts/powersystem.html

ORACLE: "SAP chooses the Oracle Database to run under SAP in almost all
their large accounts."


IBM: SAP themselves favor DB2 for their own systems. They operate more
than a thousand SAP systems, and all of those systems run on DB2
(www.youtube.com/watch?v=DZNXbqorQU0). Not only that, but the past
couple of years has seen literally hundreds of SAP clients ripping out
Oracle Database and replacing it with DB2 (
http://www.ibm.com/press/us/en/pressrelease/28403.wss). They have been
migrating off Oracle Database and on to DB2 to lower costs, improve
performance, and ease administration.

ORACLE: "We have the best Unix in the world"


IBM: AIX has demonstrated performance leadership with 7 of top 10 TPC-C
performance results (
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp). Also, the ITIC
2009 Global Server Hardware & Server OS Reliability Survey Results
reveal that AIX is 2.3 more reliable than the closest UNIX competitor.

ORACLE: "The Oracle Database scales out, IBM DB2 for Unix does not. Let
me see, how many servers can IBM put together for an OLTP application?
Let's see, how many can they group together? Um, one. They can have up
to one server attacking really big jobs. When they need more capacity,
they make that server bigger. And then they take the old server out,
put a bigger one in. And when you've got the biggest server, that's it.
That's all the can do for OLTP."


ORACLE: "They can't scale out, they can't do cloud, they can't do
clusters, the can't do any of this."


IBM: This statement has been false since the inception of DB2. DB2
Parallel Edition was brought to market in 1995, along with the
capability to scale to a system of over a 100 Unix servers. DB2 for LUW
scalability is proven in many of the world's largest OLTP environments.
In fact, IBM believes that DB2 for LUW powers one of the largest OLTP
system in the world, if not the largest (
http://www.ibm.com/press/us/en/pressrelease/19698.wss). As regards
support for clusters, DB2 pureScale was introduced to market in 2009.
For a cluster of 64 nodes, DB2 pureScale maintains 95% efficiency. At
128 nodes, DB2 pureScale maintains 84% efficiency. This is important
because if you are growing a cluster to handle bigger workloads, you
want your hardware to be doing productive work, not handling system
overhead. On the other hand, Oracle RAC [Real Application Clusters]
has a 100 server limit. And to my knowledge, Oracle has yet to publish
any efficiency numbers.

ORACLE: "You would've thought, years ago, that IBM would have come out
with a database machine. I mean its so obvious, they've got hardware,
they've got DB2. Why in the world didn't they come out with a database
machine? It's fascinating."


IBM: Remember that IMS and DB2 have made System z a database machine for
more than 40 years. In recent years, IBM has also brought “database
machines” to market. In 2005, IBM introduced an integrated offering for
data warehousing that has evolved into the IBM Smart Analytic System. In
2009, IBM also introduced DB2 pureScale, an integrated hardware/software
stack for OLTP.

ORACLE: "IBM doesn't have the same assets, and that's a big problem for
them. They don't have Java, they don't have the Oracle Database. What
they've got is a problem."


IBM: He's right. IBM does not have the same assets as Oracle. We have
more. Oracle does not have System z, the world's top performing, most
reliable and secure server; does not have business consulting arm such
as 4,000 business analytics consultants with industry specific expertise
and IBM Research - a leader in developing patents for the 17th year in a
row.

ORACLE: "They're so far behind, I don't think they have any chance at
all. I'm serious. I mean they've been working on this DB2 thing for I
don't know how long, and they still can have up to one. I would say in
database, they're a decade or so behind us. I'm serious. "


IBM: IBM has led the industry in developing patents for the last 17
years. In 2009, IBM produced 4914 patents while Oracle did not even
place in the top 50 patent leaders. A search of the US Patent office
database reveals 1588 patents with "database" in the patent description
while Oracle produced only 184 patents. (
http://www.ificlaims.com/IFI%202009%20patents%20011210%20final.htm)

ORACLE: "They are not competitive in the database business, except on
the mainframe. The IBM DB2 product on mainframe is a good product. In
fact the two best databases on the planet are IBM on mainframes and
Oracle. The trouble is that Oracle runs on modern computer systems and
IBM on mainframes runs on mainframes.


IBM: Larry is on record saying, "Our vision for 2010 is the same as
IBM's in the 1960." IBM has added 50 years of experience in hardware
software and services since then. Oracle is giving IBM the sincerest
form of flattery by attempting to imitate IBM.