İndeks deliliği: veritabanı kaosundan nasıl kaçınılır

Techopedia Staff tarafından, 5 Ekim 2016

Paket servisi olan restoran: Sunucu Eric Kavanagh, Dr. Robin Bloor, Dez Blanchfield ve IDERA'dan Bert Scalzo ile veritabanı indekslemeyi tartışıyor.

Şu anda giriş yapmadınız. Lütfen videoyu görmek için giriş yapın veya üye olun.

Techopedia İçerik Ortağı

Techopedia Staff, Bloor Group'a bağlıdır ve sağdaki seçenekler kullanılarak iletişime geçilebilir. Sektör ortaklarıyla nasıl çalıştığımız hakkında bilgi için buraya tıklayın.

• Profil
• İnternet sitesi

Eric Kavanagh: Bayanlar ve baylar, merhaba ve tekrar hoş geldiniz. Çarşamba, saat 4'te Doğu ve programı bilenler, bunun ne anlama geldiğini biliyorlar, Hot Technologies'in başka bir bölümünün zamanı geldi. Evet kesinlikle. Benim adım Eric Kavanagh, bugünkü oturumun moderatörü olacağım: "Dizin Deliliği: Veritabanı Kaosundan Nasıl Kaçının?" Ya da son e-posta patlamasında bahsettiğim gibi, “veritabanı wrangling”. Bugünlerde sıcak dönem, “wrangling”. Herkes yapıyor. Sizinki hakkında gerçekten bir slayt var. Ve benim hakkımda yeterli.

Bu nedenle, Hot Technology serisi, sadece bire bir canlı analist brifingi olan Brifing Odası'nın aksine, belirli bir alanı tanımlamak için tasarlandı, Hot Tech için iki analist alıyoruz. Bugün, kendi Doktorumuz Robin Bloor ve veri bilimcimiz Dez Blanchfield olacak. Ve bugün piyasada olanların gerçekten oldukça sembolik olduğunu düşündüğüm bir konudan bahsediyoruz.

Sonuç olarak, bugünlerde karmaşıklık dünyasındayız. Gerçekten, on beş yıl ya da yirmi yıl düşünürseniz, o zamanlar özellikle veritabanı teknolojisi açısından çok farklı bir dünyaydı. Veritabanları eskiden oldukça basitti. Sadece bir avuç vardı; çoğu ilişkiseldi. Şimdi, tüm bu veritabanı teknolojileri panoply var. Kelimenin tam anlamıyla bir uygulama oluşturmak veya verilerle bir şeyler yapmak isteyen herkes için tablodaki seçenek puanları. Her şey değişiyor ve bu da bu sistemleri yönetmeye çalışan insanları etkiliyor. Bugün bu alanda gerçek bir uzman olan Bert Scalzo ile konuşacağız; IDERA'nın tüm bu verileri ele almak için neler yapabileceğiniz konusunda üst düzey ürün yönetimi. Bununla, doktor Robin Bloor'a götürüp götüreceğim. Robin, zemin senin.

Robin Bloor: Tamam, o tanıtım için teşekkürler. Bence - iki elle olduğu için, bu Hot Tech şovuna giriş olarak genel olarak veritabanı optimizasyonu hakkında konuşacağımı düşünüyorum. Hayata teknoloji ve analizde başladım - Hayata bunu yapmaya başladım çünkü DEC VAX platformunda veritabanlarının yetenekleri hakkında makaleler yazıyordum. Bu nedenle, veritabanı harcamacıları bana bilgi verirdi. Ve benim başıma böyle bir şey geliyor, neden bir veritabanınız olsun ki? Demek istediğim, o günlerde çok sayıda insan anahtar değer dosyaları oluşturmak ve bunları biz çağırdıkça bir tür dizin sıralı yanlışlığa sahip olmak için kullanıyordu, ancak bir çeşit veritabanı yeteneği oluşturmak için kullandılar ve biliyorsunuz, neden başka herhangi bir şey?

Ve bunun cevabı, bence Michael Stonebraker buna en iyi cevabı verdi ve “Bir veritabanı, verinin nerede olduğu ve ne kadar hızlı elde edilebileceği hakkında daha fazla bilgi sahibi olabilir” dedi. Ve bence bu ilginç; bu oyunun doğasıdır. Fakat 19 - 1989'da teknoloji analizine başladığım ve bilirsiniz ki, o zaman veritabanları çok basitti ve ilişkisel veritabanları çok basitti. Çok az yetenekleri vardı, yani, verileri saklayabilirlerdi, açıkçası ve yedekleyebilirdiniz ve ASID uyumluydular, ama gerçekten çok zayıf optimize edicilere sahiptiler. Aslında, optimize edici özelliğine sahip olduklarını iddia etmek zor olurdu.

Ve daha sonra daha iyi ve daha iyi hale geldiler, ama, bilirsiniz, bir veritabanı çalışmadığında - bu kangurular bir şekilde veya başka bir gösterge gibi göründüğü için - yavaşlamasına neden olmanın çok sayıda nedeni olabilir. Ve bu beni noktaya getiriyor: Veritabanlarının birçok işlevi var, ama en önemlisi sorgu optimizasyonu. Eğer bunu yapmazlarsa, onları kullanmazsınız. Bu, hızlı bir şekilde bilgi almakla ilgilidir, çok sayıda eşzamanlı kullanıcı olduğunda bunu yapabilmekle ilgilidir ve bu zor bir sorundur. Ve gerçekten baktığınızda, onlara olgun veritabanları diyelim, isterseniz - ama kesinlikle Oracle, biraz daha az ölçüde, Microsoft SQL Server, kesinlikle Teradata ve DB2 - bu veritabanlarının optimize edicileri on yıllardır bina. Bilirsiniz, iki kişi, bir yıl, bir projede altı adam oturmuyorlardı - ve biri birlikte çalıyorlardı. Böyle çalışmıyor. Optimizasyon yeteneği yavaş yavaş büyüdü ve çok büyümek gerekiyor. Her neyse, veritabanının arka planı hakkında konuşalım. Şimdi, NoSQL veritabanı hakkında söylenen çok şey var ve grafik veritabanı için çok fazla coşku var. Ve Hadoop üzerinde SQL kullanımı ve bunun gibi şeyler. Ancak, işin gerçeği şu anda bir veritabanı istiyorsanız, tamamen işlevsel, OLTP ve büyük sorgu trafiği yeteneğine sahip olmak istiyorsanız, ilişkisel bir veritabanı veya hiçbir şey değildir.

İlişkisel veritabanları arasında Oracle popülerlik açısından baskındır. Microsoft SQL Server, sanırım, ikinci. Her ikisi de OLTP ve sorgu iş yükü için kullanılabilir, ancak aslında bu iş yüklerini karıştırmaktan gerçekten kurtulamazsınız. OLTP iş yükleri ve sorgu iş yükleri için farklı olaylara ihtiyacınız vardır. SQL ve grafiğin alternatifleri vardır. Çoğu şirket belirli bir veritabanında standartlaşıyor, bu yüzden - diğer onlarla on yıllarca savaştıktan sonra Oracle en baskın olan oldu. Çünkü şirket lisansları satabildikleri için şirketler, Oracle'ı sadece istisnai ürünlerde alternatif ürünler kullanacaklardı. Ve veritabanları da geliştikleri için stratejiktir. Ve bu sunum için biraz araştırma yaptığımı biliyorsunuz ve bu biraz - bir süre sonra geleceğim, ancak bir DBA'nın konumundan bakmak açısından nasıl geliştikleri ilginç. Ben buna görünmez eğilim diyorum. Bu Moore yasası. Kabaca böyle: En büyük veritabanı ve yeni veritabanları, yutmak için çok daha fazla veriye sahip eski bir veritabanı yok. Normalde yeni bir soruna uygulanan bir veritabanıdır. Ve aslında veri hacimleri bakımından büyürler. Kabaca Moore'un küpünde yasa. Bu nedenle Moore yasası her altı yılda bir on kat faktörüdür. VLDB'ler her altı yılda bir bin faktör büyüme eğilimindedir. 1991, 1992'de büyük veritabanları megabayt olarak ölçülür. '97 ve '98'de gigabayt. 2003, '4, terabayt. 2009, '10, petabayt veritabanlarını görmeye başladınız. Sanırım şu anda orada bir veya iki exabyte veri tabanı var, ama duyduğum en büyük şey 200 petabayt zamanında ve biliyorsunuz, bir petabayt veritabanına veri alamıyor. Ancak, bunların çoğu yeni büyük web 2.0 şirketleri olacak, muhtemelen bu yönde Facebook başlığınız var.

Her neyse, buna gerçekten bakarsanız, bir veritabanının hacimsel olarak bu tür bir yükselişten geçmesini beklerseniz, çok soruyor. Ve dikkat çekici bir şekilde, kesinlikle petabayt düzeyine kadar, gayet iyi yapmışlar gibi görünüyor. Yani yeni ürünlerden çok eski ürünlerden bahsediyorum. Olağanüstü iyi performans göstermiş gibi görünüyorlar. Veritabanı performansına, darboğazlara bakarsak, bu beni gerçekten onları önemsediğim zamana geri götürüyor ve onlar için endişelenmem gerekiyordu. Bunun temel olarak donanımın bozulması olduğunu biliyorsunuz. CPU darboğazları vardır, muhtemelen bellek darboğazları vardır, muhtemelen disk darboğazları vardır. Bu, kedere neden olan ağ olabilir ve ne yaptığınıza bağlı olarak kilitleme ile ilgili problemler de alabilirsiniz, ancak normalde programın kilidi kimin arayacağını bilmemesi nedeniyle. Yani, bir veritabanını ayarlayacaksanız, aslında bu beş olası darboğaz arasında olabildiğince dans edebilmesi için onu ayarlamaya çalışıyorsunuz. Ve bu hiç de kolay değil, çünkü herhangi bir sunucuda yapılandırabileceğiniz bellek miktarı önemli ölçüde artırıldı. Sonra CPU'lar çok çekirdekli, disk haline geldi, sanırım şimdi, emtia sunucularında bile, yüzlerce terabayt, çeyrek petabayt, belki de bir emtia sunucusunda bile yapabileceğinizi düşünüyorum. Yani, tüm bunlardan, oynayabilirsiniz, ağ farklı hızlarda gidebilir, ancak çoğunlukla veritabanlarıyla uğraşırken, sunucular arasında fiber kablolara sahip olmak istersiniz ve bunun üzerinde çalışan başka bir şey yoktur, özellikle bu şekilde.

Veritabanı performans faktörleri. Yani, bunun ne hakkında olduğunu bırakıyorum, çünkü Dez bunun hakkında konuşacağını biliyorum, ama kötü veritabanı tasarımı kötü performans gösteren bir veritabanı anlamına geliyor. Kötü programlama tasarımı, bir veritabanına çok aptal SQL atmak anlamına gelebilir, bu da çok daha uzun sürer. Eşzamanlılık ve iş yükü karışımı, çok fazla eşzamanlılık darboğaz sorunlarına neden olacaktır. İş yükü karıştırma, çok küçük, kısa, keskin sorguları olan büyük sorgularınız olduğunda sorunlara neden olur. Bir yük dengeleme sorunu var. Çoğu veritabanı bununla ilgilenir, ancak karmaşık bir ürününüz yoksa, sadece birkaç sunucu ekleyerek, aslında bir kümenin boyutunu artırmak istiyorsanız tek yapmanız gereken bu değildir. Optimum performansa ulaşmadan önce yükü dengelemeniz gerekir. Kapasite planlaması yapmanız gerekir. Kesinlikle. Özellikle şimdi veri hacminin veritabanları için eskisinden daha dramatik bir şekilde arttığı günümüzde. Ve verileri nasıl yuttuğunuza, verileri nasıl taşıdığınıza dair tüm veri katmanı sorunları vardır. Veritabanına zamanında veri alınmaması daha sonra bir performans sorunu olabilir, çünkü Windows'ta çalışan veritabanlarından yirmi dörde yedi ila üç yüz yetmiş beş operasyona gittik ve yavaşlatabileceğiniz pencereler yok. veritabanı aşağı ya da bugünlerde olması muhtemel değildir.

Oracle DBA sorunu. Ben de böyle düşünüyordum. Oracle 7 ile Oracle'ın DBA'sında bulundum ve bunu nasıl ayarlayacağımı hatırlıyorum. Ve şimdi Oracle'a gerçekten bakarsanız, bu yol, yol - yol, daha fazla yetenek var. Bitmap indeksleme ve bunun gibi şeyler var, ama aslında şu anda bir Oracle veritabanında kaç ayar parametresinin olduğunu görmek ve görmek için zaman ayırdım. Ve üç yüz elli ayar parametresi var ve uzman DBA'ların bileceği yüz gizli parametre daha var, ancak normal Oracle DBA'ların bilmediği. Ve bu, bu tür bir veritabanının ayarlanmasının zor bir şey olduğu anlamına gelir. Hiç de basit bir şey değil. Bunun için bir fikir sahibi olmalısınız, uzun, uzun süredir yapmalısınız ve çözdüğünüzü düşündüğünüz sorunun tam olarak ne olduğunu bilmelisiniz, çünkü ayarlama performans zayıflar, ancak her şeyin performansı olmayabilir. Önemli olan belirli sorguların performansı olabilir ve belirli verileri ve belleği sabitleyerek bunu düzeltebilirsiniz veya dizine ekleyerek düzeltmeniz gerekebilir veya bölümlemeyi farklı bir şekilde yapmaya başlamanız gerekebilir. Yapabileceğiniz çok şey var, önemli olan nokta. Sonuç olarak, bunu başlarında yapmayacaklar - DBA'ların araçlara ihtiyacı var. Şimdi size endeksleme hakkında bilgi verecek olan Dez'e geçeceğim.

Eric Kavanagh: Pekala Dez, götürün onu.

Dez Blanchfield: Teşekkürler Robin ve kapak sayfasını seviyorum. Bence o kadar da heyecan verici bir şeye uzaktan yaklaşmam için dayağı yere fırlattın. Ancak, veritabanı yöneticileri için bugünün meydan okumasının neye dönüştüğüne dair görüşüm olarak, küçük galaksimizin bir görüntüsünü kullandım, çünkü bu, bir çevreye girdiğimde yarattığım zihinsel görüntü ve artık ben değilim artık veri tabanlarını yönetme ya da bu düzeyde veri tabanı tasarlama dünyasında. Ancak, sizin gibi, Robin ve ben de veritabanı dünyasında uzun yıllardır ya yönetici ya da geliştirici ya da sonunda mimar olduk ve daha sonra bir kabuk kazanmak için daha iyi şeyler yapabileceğimi fark ettik. Ancak bu veri galaksisine baktığınızı hissetme eğilimi gösterir ve daha da fazlası bugün, özetlediğiniz gibi, megabayttan petabaytlara ve exo-ölçeğe çok kısa bir süre içinde gittik, şeylerin büyük düzeninde. Ancak aklımda olan ifade, veritabanı dizinlerinin artık siyah bir sanat olduğu ve gerçekten de ölümlülerin kurumsal düzeyde iş uygulamaları ve sizi formüle etme türü için biraz uğraşması gereken şeyler değil. sadece hakkında konuşuyorlardı. Ancak, veritabanı dünyaları ile yaşadığım tarih türünün hızlı bir özetini incelemek ve bir sonuca varacağımız yere bağlam getirmek ve bugün arkadaşlarımızla bazı materyallerden geçmek istedim. IDERA, çünkü veritabanı performans ayarını nasıl alacağınız hakkında çok farklı düşünce olduğunu düşünüyorum ve bunlardan biri teneke atıyor. Karşılaştığım birçok dükkan için, veritabanı katmanında ve özellikle dizin katmanında performans ayarlaması yapma noktasına gelmiyorlar. .

Birçok insan bence büyük bir demir yaklaşım benimsiyorum ve burada Flash'ın bir resmim var, çünkü eski filmleri veya kesinlikle Flash ile en son TV şovunu izlediyseniz, Eski karakter Flash Gordon ve şimdi ona “Flash” dendiğine göre, çok, çok hızlı gitme eğiliminde ve her zaman enerjisi tükeniyor. Veritabanı performansına büyük demir attığınızda da olan budur. Deneyimime göre, oyuna yüksek performans, sıkı çalışma koyabilir, işletim sistemlerinizi optimize edebilir ve belirli bir noktaya ayarlayabilirsiniz. Uygulamanın daha hızlı çalışmasını sağlamak için hızlı çok çekirdekli, çok iş parçacıklı CPU'lara sahip olduğunuzdan emin olabilirsiniz, ona çok fazla RAM atabilir, yüksek verimli arka planlara sahip olabilirsiniz, sabit sürücülerden önbelleğe sabit sürücüye katı duruma geçebilirsiniz ve yüksek performanslı depolama dizisi. Ve şimdi bile, insanlar veritabanı motorlarına flash ve NVMe gibi şeyler atıyorlar, bu giriş zamanlarını iki performans kazanacaklarını düşünüyorlar. Ve her zaman bir miktar kazanç elde ederler. Ancak, hepsi aynı temel performans ayarlama sorunlarına geri dönüyor. Kümelerin hızlı çalışabilmesi için düşük gecikmeli ağ bağlantıları. Ve veritabanı altyapısını kümelendirerek, tüm işi yapan birden fazla makineniz var. Ancak aynı temel performans sorununa geri dönme eğilimindesiniz ve bu da verileri okumak. Verileri yazmak, çoğunlukla doğru bir şekilde yapılmadıkça, oldukça doğrusal bir sorundur.

Ve sonra bugünün dünyasında zorluk çekiyoruz: Tüm veritabanları eşit yaratılmıyor. Veritabanları ve teklif üzerine alıntı “veritabanı” var. Ve veritabanı motorlarını düşündüğümüzde, insanlar genellikle geleneksel, olağan şüphelileri SQL dünyasında oldukları gibi düşünüyorlar. Biliyorsunuz, Oracle ve Microsoft SQL Server'ımız var ve açık kaynak dünyasında, şimdi Oracle'a ait olan MySQL ile bir çift var, ancak hala açık kaynak. Ve sonra, endeksleme ve performans yönetimi konusunda hala bir sorunu olan olağandışı şüpheliler, NoSQL motorlarımız var ve bunlara çok fazla ayrıntıya girmeyeceğim, ancak artan sayıda var. işler her gün ortaya çıkıyor ve geliştiricilerin bakış açısından ve performans açısından veritabanı motorları gibi görünüyorlar ve hissediyorlar, ama çok, çok farklı yaratıklar ve dünyada da kendi küçük nişleri var. bellek içi performans veya disk üzerindeki doğrusal ölçek. Ama veritabanı dünyasında dünya böyle görünüyor. Bu 2016, bu, veritabanlarının nasıl göründüğüne dair sürekli devam eden peyzaj haritasını üreten bir dizi insanın haritasının üçüncüsü ve burası - süper insan veritabanı mimarı veya veritabanı yöneticisi bile mantıklı değil onun. Kelimenin tam anlamıyla yüzlerce, yüzlerce ve yüzlerce farklı marka, model, veritabanı üreticisi, her zaman SQL uyumlu. Ve ilginç olan, hepsi aynı zorluğa geri dönüyor. Veritabanı motoru etrafında ve özellikle verilerin nasıl endekslendiğiyle performans ve performans ayarlama.

Bu yüzden hızlı bir şekilde veritabanı indekslemesini ele alalım, çünkü ilginç bir konu ve demo ile daha ayrıntılı olarak ele almanız gerektiğine inanıyorum. Ancak, veri tabanı indeksi performans ayarının, verilerinizin hızlı ve hızlı bir biçimde erişilebilir olmasını sağlamak için dünyanın başladığı ve bittiği yerdir. Ancak veritabanı indeksleme nedir? Günlük insanlar olarak alışkın olduğumuz biçimde dizine eklemeyi düşünürsek, bir kitaptaki dizin sayfasını düşünün. Bir kitapta bir şey bulmak istiyorsanız - özellikle bir ansiklopedi gibi veya bir formun referans malzemesi gibi bir şey - bu sayfa gibi bir şey arıyorsanız, baraj konusu gibi şeyler arıyorum bir ansiklopedi. Genel olarak insan yapımı barajlar, su toplama ve geniş bir birikim alanı ile ilgili her referansı bulmak istiyorum. Arkaya gideceğim, alfabetik, sıralı bir listede, A'dan Z'ye, soldan sağa bulacağım ve D'yi bulacağım. “Barajlar” kelimesini bulacağım ve bunu görebiliyorum sayfa 16, 38, 41 bunlara bir referans var ve sonra bu sayfalara gidebilirim, gözlerimi tarayabilirim ve “baraj” kelimesine referans bulacağım. Bu aslında bir veritabanında aynı kavram, ama şimdi birçok yönden roket bilimi. Öyle ki, şimdiye kadar iyi bildiğim her veritabanı yöneticisi, deneyimlerinin, teneke kutu atma kadar ne kadar olabileceğine bakılmaksızın, herhangi bir veritabanı dünyasında performans ayarı için tek en kritik araç olduğunu düşünüyor veya durum ne olursa olsun.

Genellikle veritabanı indeksleme hakkında konuştuğumuzda, bazı ortak yaklaşımlar vardır. Veri tabanı endeksleri ne kadar karmaşık olursa, veri endeksleme yaklaşımı da o kadar karmaşık olur. Ancak temel olarak verileri endekslemeyi düşündüğünüzde - bir ad listesi olan bir dosyamız olduğunu hayal edin; alfabetik sıraya göre sıralanamazlar. Yirmi tane olduğunu düşünelim. Eğer sıralayacağız - eğer o listede, yukarıdan aşağıya veri arayacaksak ve bunun bir ad listesi olduğunu varsayalım. Rasgele bir ad seçersem ve bu listeyi yukarıdan aşağıya doğru doğrusal bir biçimde aşağı kaydırmaya başlarsam ve bu sıralanmamış bir listeyse, ortalama arama sürem ve maksimum arama sürem olarak düşündüğüm iki ölçüt vardır - ve İkinci satırda bir yazım hatası var, "maksimum arama süresi" olmalıdır üzgünüm - ama ortalama arama sürem esasen N artı bir, ikiye bölünmüş ve bu ortalama olarak, zamanın yüzde ellisini alır listenin en üstünden, listenin en altına kadar taramak için o listedeki herhangi bir rastgele şeyi bulun. Ve buradaki ikinci satır, lineer altında, “maksimum arama süresi” olmalıdır. Ancak maksimum arama süresi esasen öğe sayısıdır ve yirmi şeyden oluşan bir listem varsa, beni en fazla zaman alabilecek olan bu veritabanında bir şey aramak, yukarıdan aşağıya doğru gitmektir, yani bu basitleştirilmiş örnekte 20 öğe diyelim. Ve bu çok yavaş bir süreç ve performans ayarlamasının gerçekten bir yolu yok. Ve sonra, bu verileri almanın ve bir dizin oluşturmanın başka yolları da vardır; bu, gerçek verilerin ikili, B-ağacı, bitmap, karma, kümelenmiş ve kümelenmemiş olduğu yerlere yönelik kısa bir işaretçi listesi, ve sonra uzamsal, filtrelenmiş, XML ve tam metin gibi farklı veri türleri vardır.

İkili, verinin kendisine verdiği şeyler için çok yaygın olarak kullanılan bir ikiliktir. B-ağacı muhtemelen genel anlamda en yaygın olanıdır, tarihsel olarak, herhangi bir veri biçimine bir indeks yapılandırmanın ortak bir yoludur ve işaretçileri hareket ettirirken günlükçilere, seçimlere ve eklemelere ve silme işlemlerine nispeten kolaydır. işaretçiler, noktalar referans. Bitmap gibi başka türler de vardır, burada veri türlerinin ilişkili bir form aralığımız var gibi. Hashing, özellikle bloglar ve resimler gibi büyük nesneler için çok iyi çalışır. Ve verileri endekslemek için bir dizi farklı bilimsel yaklaşım, matematiksel yaklaşım olduğunu görebilirsiniz. Sadece ölümlü olanlar için, bu seviyede konuşmak ilginç bir mücadeledir. Bir veritabanı yöneticisi için performans düzeyinde konuştuğunuzda, gerçekten bir roket bilimcisi haline geliyorlar ve insanlar onlarda derece yapıyorlar ve Doktor Robin Bloor'un bunu kesinlikle yaptığını ve IBM ve son birkaç on yıldır diğer büyük markalar. Ve bence - benim görüşüme göre, aslında bir zamanlar geçirdik ki, bir zamanlar şahsen bir sistemin önünde oturabileceğim ve onu ayırabileceğim ve size gösterebileceğim tam olarak performans sorunlarının bir komut satırında veya bir grafik kullanıcı arabirimi başlatma aracında olduğu ve verilerin içine girip sorunların nerede olduğunu söylemeye başlayın ve dizinler, alt dizinler veya birincil ve ikincil dizinler oluşturun veri ve bir şeyler bulmak için kullanmaya başlayın. Ama size gösterdiğim manzarayı düşündüğünüzde, yüzlerce ve yüzlerce marka, marka ve model, üretici ve veri tabanı türümüz olduğu için, o zamanlar bir insanın yapabileceği iyi ve gerçekten geç kaldık sahip olduğumuz veritabanı motoru türlerini algılayabiliyoruz. Özellikle, Oracle'ın beğenisine geri dönsek bile, günümüzde ilişkisel veritabanı platformlarında baskın markalar.

ERP veya İK veya finans sistemi gibi tescilli bir platformdan veya çeşitli nedenlerle evde pişirilmiş bir platform olup olmadıklarına, sonlandırdığımız veritabanı ve veritabanı tablolarının ve kayıtlarının sayısına bakmaları gerekiyor uğraşmak sadece astronomiktir ve fiziksel olarak elle yapamazsınız. Ve şimdi, bir zamanlar bir veritabanı sunucusunun masanızın altında oturabileceği ek bir sorun yaşadık. Biliyorsunuz, okuldan sonra küçük bir çocuk olarak, başlangıçta Apple II'lerde ve daha sonra dBase II, dBase III gibi DOS PC tabanlı sistemlerde veritabanı yazılımları üzerinde çalışıyordum. aralık ve hatta VAXs ve PDP'ler ve günlük dosyası. Ve Saber gibi ve sonunda SQL veritabanlarının bir kısmı geldiğinde. Ancak bu günlerde veritabanı motorlarını düşündüğümüzde, sol alt köşeye benziyorlar. Veritabanı sunucusu artık masanın altında yerde oturan tek bir makine değil; veritabanı motorlarının ve kümelerinin kopyalarını çalıştıran yüzlerce makinedir ve petabaytlar olmasa da binlerce terabayt olan yüzlerce ve yüzlerce terabayt veriyi ölçeklendirirler. Ve Doktor Robin Bloor'un da belirttiği gibi, bazı özel kullanım durumlarının - özellikle havayolları, özellikle devlet kurumları - exabyte'lara ulaşabileceği uç noktalarda bile. Hala oldukça nişler, ama yüzlerce terabayt ve hatta onlarca petabayt artık sıra dışı değil, özellikle dotcom patlamasından şimdiye kadar web 2.0 şirketleri dediğimiz şey, Facebook, Google, Yahoo gibi ve benzerleri.

Ayrıca şimdi işler dış hizmete yöneliyor. Altyapı sağlayan bir hizmet yaklaşımı olarak altyapı platformumuz ve yazılımımız var. Özellikle Oracle ve bulut platformları, veritabanları ve sunucuları için satın alamadığımız platform hizmeti. Bu da uygulamanın çok hızlı bir şekilde geliştirilmesini ve sunuculara bir veritabanı eklememizi sağlıyor. Davlumbazın altında ne olduğunu düşünmek zorunda değiliz. Dezavantajı, sık sık veritabanını incitmeye başlayana ve performans bir sorun haline gelene kadar nasıl tasarladığımızı ve uyguladığımızı düşünmememiz ve ardından veritabanımızın neden acı verdiğini teşhis etmek için doğru aracı aramak zorunda kalmamızdır. performans sorunlarının olduğu yer. Ve her zaman bu verileri nasıl indekslediğimize ve bu veriler için kullandığımız dizin türlerine ve daha sonra da bizi insanüstü performans gereksinimine geri döndürme sorununa geri getiriyor. Ve doğru motorlara ve performans için doğru araçlara erişimi olan ve bu motorları ayarlayan ve bir etkin nokta bulmaya ve sorguların nerede olduğuna, verilerin hareket ettiği yere, sorgu türlerine, sorguların nasıl yapılandırıldığına, sorguları kim yapıyor ve sorguların kuyruğa alınıp alınmadığını ve önbelleğe alınması gerekip gerekmediğini. Ne tür bir kopya arıyorsunuz?

Bu nedenle, dünyanın en iyi veritabanı gurularının, aslında veritabanı mimarlarımızın, veritabanı yöneticimizin ve performans tabanlarımızın bile, doğru araçları kullanmaya başlamaya çok ihtiyaç duydukları bir noktada iyi ve gerçekten - bence - şimdi herhangi bir veritabanı motoru için en iyi performans indeksi ayarını sunmaktır. Çünkü uğraştığımız ölçek ve işlerin hareket hızı, bunu elle yapamayız ve bunu yapmaya çalışmak başka performans sorunları getirebilir, çünkü o alanda deneyimimiz olmayabilir. bir sorunu çözmeye çalışıyoruz. Ve bence Bert'e teslim olmak üzereyiz ve bu çeşitli sorunu nasıl çözdükleri ve araçlarının yapabileceği şeyler hakkında konuşmak üzereyiz. özellikle Oracle dünyası için. Ve orada, Bert, sana geçeceğim.

Bert Scalzo: Teşekkür ederim. Herkese hoş geldiniz, benim adım Bert Scalzo, IDERA için çalışıyorum. Bazı veritabanı ürünlerimizin kıdemli ürün müdürüyüm. Bugün bunlardan bazılarını göstereceğim. Ama dizinler hakkında konuşmak istiyorum, çünkü herkesin burada söylediği her şeye katılıyorum, özellikle de son slayt, dizinlerin o kadar karmaşık olduğunu şimdi bir araca ihtiyacınız olacak ve sizi ikna etmeyi umuyorum. Oracle dizin tasarımı, eskiden olduğu kadar kolay değil. Birçok insan seçeneklere baktıklarında kendilerinden emin olmayacaklar ve bunu tarihten çıkardığımı söyleyerek hoşuma gidiyor, “bu konularda, tek kesinlik, hiçbir şeyin kesin olmadığı.” Bu günlerde endeksler hakkında hissediyorum, çünkü cevabınızı X, Y veya Z indekslemeniz gerektiğini bilseniz bile, denemeden gerçekten emin olamazsınız, çünkü bu optimize ediciler bazen beklediğinizden farklı davranırlar. Dizin tasarımında çok fazla deneme yanılma var. Şimdi, eski güzel günlerde, bir endekse ihtiyacınız varsa, genellikle sadece iki soru ya da bir soru vardı. Benzersiz miydi yoksa benzersiz değil miydi? Ayrıca, “Tek bir tabloda maksimum kaç dizin olabilir?” Gibi başka şeyler de düşünmüş olabilirsiniz çünkü çok fazla dizin ekleme, güncelleme ve silme işlemlerinizi yavaşlatır. Ayrıca, veritabanı sisteminizde de olabilirsiniz, çok sütunlu bir dizinde kaç sütun olabileceğine dair kısıtlamalar olmuş olabilirsiniz, çünkü bazen veritabanı motorunuzun sayfasına veya blok boyutuna dayalı sınırlamalar vardı, ancak gerçekte oldukça basitti eski güzel günlerde. Dizine eklediniz veya eklemediniz. Ve gerçekten, her şey bir B ağacındaydı. Kopyalara izin verebiliriz ya da vermeyebiliriz ve bu da bununla ilgiliydi. Hayat güzeldi, hayat basitti.

Bugün hayat çok iyi ya da çok basit değil. Kırmızı Ghostbuster işaretini eskiden yaptığımız şekilde koydum, çünkü şimdi B-ağacına karşı bitmap, bitmap'e karşı. Ve bir anda bunların bazılarının ne olduğunu açıklayacağım. Kümelenmiş ve kümelenmemiş, benzersiz veya yinelenen, ileri veya geri sıralama, işlev tabanlı, bölümlenmiş veya bölümlenmemiş. Bölümleme söz konusuysa, küresel veya yerel bölümleme var mı? Bunu da açıklayacağım. Ve sonra dizinlenmiş bir organize tablo denilen bir şey var. Ve aslında burada bıraktığım yarım düzine kişi daha var, çünkü sanırım burada, dizinlerin düşündüğünüzden çok daha zor olduğuna ikna etmeniz gereken yeterince var. Bu slaytta diyagramın sol üst kısmında başlayacağım ve bir masam var. Ve karar vermem gereken ilk şey, veritabanı sürümünüze ve veritabanı satıcınıza bağlı olarak, nesne tablolarına izin veriyor mu yoksa yalnızca ilişkisel mi? Sağ taraftan aşağı ineceğim ve ilişkisel bir masa inşa ettiğimizi söyleyeceğim. Şimdi, kendime sormam gereken bir sonraki soru, bu bir kümede mi? Oracle'ı bir süredir yapan birçoğunuz, kümelerin 6 gün boyunca geri döndüğünü hatırlayacaksınız. Muhtemelen bugün çok fazla kullanılmıyorlar, ama önce o daldan aşağı inmeme izin verin.

Masamı bir kümeye koyacak olsaydım, o tabloda kümelenmiş bir dizin olması gerekirdi. Artık Oracle'da bir tabloyu kümelediğinizde, temelde satırları depolamıştınız veya satırlar değerlerin benzer olduğu yerde birbirine yakındı. Ve böylece, kümelenmiş bir dizin olması gerekir ve bu kümelenmiş dizin bölümlenmemiş olabilir. Başka bir deyişle, kümelenmiş bir tabloyu nasıl yapacağınıza dair gerçekten herhangi bir bölümleme yöntemi yoktu. Kesinlikle bölümlenmemişti. Ve bölünmemiş olduğu için küreseldi. Bir dakika içinde küresel olanın ne olduğunu açıklayacağım. Ve her zaman B ağacıydı. Başka bir deyişle, o şubeye gittiğimde, oldukça basitti, çok fazla seçeneğim yoktu. Şimdi, bazı sürümlerde izin verilen bir kümelenmiş tabloda kümelenmemiş bir dizin yaptıysam, yine bölümlenmemişti; bölümlenmediğinde, tek seçeneğiniz küreseldir. Ve böylece, B-ağacı veya bitmap seçeneğiniz var. Yine, veritabanı sürümünüze bağlıydı. Ama şimdi ilişkisel tabloya geri dönelim ve tekrar sağ tarafa inmeye başlayalım ve şimdi sadece sade, eski, düzenli, yığınlanmış bir masaya sahip olacağız: ilişkisel. Bir masa alanında olacak. İlk önce burada sağ tarafa iniyorum. Yani organizasyon, yığın. Kendime sormam gereken bir sonraki soru, “Bu tabloyu bölümlemek mi istiyor muyum, değil mi?” Şimdi, bazen bölümleme yaparsınız çünkü “Hey, optimize edici sorguları nasıl optimize edebileceği konusunda daha akıllı olacak. “Ancak birçok DBA size bunu yapma nedeninin idari amaçlar için olduğunu söyleyecektir. Yüz milyar satırlık bir tablonuz varsa, tabloyu bölümlere veya bölümlere ayırırsanız, son bölüme veri eklemek istediğinizde, sadece birkaç milyon satırlık bir alanı bırakıp dizine ekleyebilirsiniz. Bu verileri ekleyebilir ve daha sonra bu dizini yalnızca bu grupta yeniden oluşturabilirsiniz.

Bazıları için iyi bir teknik olsa da, bölüm eleme gibi optimizasyon teknikleri, gerçek değeri daha küçük parçalar üzerinde idari görevleri yönetebiliyordu ya da yapabiliyordu. Organizasyon yığınına gittiğimde, ilk soru “Ben bölümledim mi, değil miydim?” İdi. Sola gidelim, masayı bölümlere ayırmayacağım. Şimdi, size bunu söylediğimde garip gelebilir, ancak bölümlenmemiş bir tablonuz olabilir ve daha sonra alıştığınız gibi dizini bölümleyemezsiniz veya dizini bölümleyebilirsiniz. Dur ve düşün. Tablonuzda her zaman düşündüğünüz gibi temel olarak bir kova var ve yine de dizininizde birden çok kova olacak. Bu gerçekleştiğinde, bölüm ve tablo sayısı ile dizindeki bölüm sayısı arasında bir uyumsuzluk olduğunda, küresel olarak kastedilen budur. Ve böylece, tablo bölümlenmemişse ve dizin bölümlenmişse, küresel kabul edilir, çünkü bir uyumsuzluk vardır. Şimdi, organizasyon yığınıma geri döneyim ve bunun yerine bölüm tarafında aşağı ineyim. Şimdi, bir bölüm tablo varsa ve diyelim ki tablonun dört kova, dört bölüm, benim dizin dört kova olabilir, böylece benim dizin tablo tasarımı ile eşleşir. Ve böylece, sağ tarafta, bitti. Bu yerel kabul edilir. Yerel bir dizin temel olarak tablonun ve dizinin bölümlendirilmesinin aynı şekilde yapıldığı ve aynı sayıda kovaya sahip olduğu anlamına gelir. Ve sonra yerel indekse sahip olduğumda, bir B-ağacı veya bir bitmap olabilir ve bu tür yeşil bir ok yükselir, bir B-ağacı olsa bile hala yapılabilecek seçimler olduğunu gösterir. Fonksiyon tabanlı olabilir. Ve ayrıca, bir bitmap ise, farklı bitmap türleri vardır. Bitmap birleştirme dizini adı verilen bir şey var. Veri ambarı yapıyorsanız, bu, yıldız şeması veya tasarımı için çok popüler bir dizin türüdür. Olan şey, dizinin tabloda işaret ettiği satır satırlarına sahip olmasıdır, ancak üst tablolar için de satır kimlikleri olacaktır, böylece siz - şema tasarımına yıldız eklemeniz gerekir ve olgu tablosunda, olgu tablosundaki bu dizin sizi ilgilendiğiniz verilere ve boyutlarınızdaki her satıra yönlendirir, böylece yalnızca bir dizininiz olur.

Ve aslında, bu yıllar önce bir veritabanı olan Red Brick yüzünden ortaya çıktı - birçok insan bunu hatırlayabilir. Ve böylece, bu resme bakarsanız ve aklınızda bulundurursanız, bu resimdeki her şeyi koymadım çünkü resim çok daha büyük olurdu - hala sağ üst kısımda metinde yaşadığım ek sorunlar var . Ters sıralı bir dizin mi? Ve şöyle diyebilirsiniz: “Neden ters sıralı bir dizin isteyeyim? Bu hiç mantıklı değil. ”Oracle'da kümelenmiş bir ortamdaysanız, gerçek uygulama kümeleri yapıyorsanız, dizinlerinizi düzenli tutarsanız, tersine çevrilmez, isabet eden çok fazla işleminiz varsa aynı değerler veya aynı indeks değerleri, ne olacağı, B ağacınızın sıcak alanlarına sahip olacağınızdır. Yani, çekişmeye sahip olabilirsiniz ve muhtemelen bu şeylere erişmek ve erişmek için kilitlenirsiniz ve bunu bir ağdaki düğümler arasında yaparsınız. Ters sıralı bir indeks koyarsanız, şimdi bunu geri alabilirsiniz. “Peki, benzer değerler ağaçların farklı kısımlarında, bu yüzden ağaçtaki sıcak alanlar için yarışan ayrı düğümlerim yok” diyebilirsiniz. Ve sonra benzersiz olanın bazı seçeneklerle çalışmadığını da fark edin. . Eğer bakarsanız, üç, beş, sekiz ve on bir tane numaralandırdım, bu yüzden benzersiz bir endekse sahip olamadığım bazı durumlar var. Benzer şekilde, ters bir dizin oluşturamayacağım bazı durumlar da var ve daha sonra günlük kaydı veya günlük kaydı yok, paralel ve paralel olmayan gibi ek sorunlar var. Hafızadaki belirli bir alana bir şeyler atayabilirim.

Ve bu, Oracle'da hala biraz özellik bırakıyor. Oracle 12'ye baktığınızda, muhtemelen bu resme ekleyebileceğim yaklaşık yarım düzine şey olduğunu söyleyebilirim. Endeksleme gerçekten karmaşık ve önceki konuşmacıya gerçekten katılıyorum, bu konuda gezinmek ve iyi bir seçim yapmak için bir araca ihtiyacınız var. Belki böyle bir resme ihtiyacın var ve bir şeyleri nasıl seçeceğine dair bir çeşit metodoloji ve umarım bu araç oraya ulaşmana yardımcı olur. Ve sonra deneme yanılma olacak. İnsanlara her zaman indeksleme, “sıçramadan önce bak” derim. Ve sonra burada küçük köpeği görebiliyorsun, bakmadan atlıyor, köpekbalığıyla suya girecek ya da adam suya atlamaya hazırlanıyor ve kendini kazımak zorunda kalacak. İndekslemenizi düşünmelisiniz, çünkü bir indeks oluşturmak her zaman daha iyi olacağı anlamına gelmez. Aslında, bir dizin oluşturmak işleri yavaşlatabilir. Ve sorgu performansı, bir seçim diğerine göre daha iyi bir büyüklük sırası olabilir. Size iyi bir örnek vereceğim. Yıldız tasarım şeması yapıyorsanız ve boyut tablolarınızda bir durumda bitmap dizinleri kullanırsınız ve başka bir durumda “B-ağacı dizinleri kullanacağım” diyorsunuz, B- ağacı. Size bir çözümün büyüklük sırası veya muhtemelen birkaç büyüklük sırası diğerinden daha hızlı olacağını söyleyebilirim. Ancak bir veri ambarı ortamında olduğu gibi tek bir ortamda neyin işe yaradığını unutmayın, muhtemelen bir OLTP ortamında iyi bir seçim değildir.

Örneğin, bir işlem tablosu alıp bir bitmap dizinlerini bir işlem tablosuna koyacaksanız, bitmap'leri, bu uzun dizeleri ve böylece bir OLTP tablosunda tabloyu o kadar yoğun bir şekilde vurabilirsiniz. endeksi bozulabilir ve sadece güncellemeler için tasarlanmadığından sisteminizi yavaşlatabilir. Hızlı erişim için harikalar, ancak güncellemeler için iyi değiller. Ben dizin deneme yanılma alır düşünüyorum. Artık gerçekten altın bir kural yok - bu denklemde bilmek için çok fazla farklı değişken var - ve nihayetinde iyi seçimler yapıp yapmadığınızı görmek için veritabanınızda yürütmeye bakmak veya planları açıklamak zorunda kalacaksınız. Ve bazen, plan analizi neredeyse kendi başına bir bilim olabilir. Bugün bunu ele almayacağım - bu başka bir konu - ama endeks tasarımını kabul etmeyin. Önceki resimde size gösterdiğim ve önceki konuşmacının bahsettiği tüm bu çılgın dizin türlerinin olmasının meşru nedenleri var. Bunlar sadece bir veritabanı satıcısı için bir yerde bir kontrol listesi koymak için düzgün bir özellik olduğu için yaratılmadı; bu indekslerin önemli olduğu ve önemli bir fark yaratacağı kullanım senaryoları veya senaryoları vardır. Şimdi bununla, size araçlarımızdan birinde farklı dizin türlerinden bazı örnekler göstereceğim. İzleyebilmem için ekranımı açayım. Tamam, ben burada oturuyorum - bu uygulamayı en aza indirmeme izin verin. VMware'in içinde oturuyorum ve bir Windows Server 2012 VM çalıştırıyorum.

Gördüğünüz gibi, insanın bildiği hemen hemen her aletim var. Bir ürün yöneticisi olarak, rekabetimin farkında olmalıyım, bu yüzden sadece hangi araçlara sahibim değil, rakiplerim ne yapıyor? Ve burada zaten koştuğum DBArtisan adlı bir aracımız var, ama gidiyorum - bu yüzden sadece getireceğim. Gördüğünüz şey bu gerçekten güzel bir araç, çünkü kullanmak zorunda kalmak yerine, Oracle için bir kurumsal yönetici ve SQL Server için bir SQL Management Studio ve MySQL için MySQL Workbench ve desteklediğimiz on iki diğer veritabanını söyleyin, tüm veritabanlarımı tek bir araca yerleştirdim. DB2 var, MySQL, Oracle, Postgres, SQL Server ve Sybase var ve bu - bu özel şeyde sadece altı veritabanım var çünkü yapamıyorum - araç on iki veritabanını destekliyor, ancak zavallı sanal makinem, altı veritabanını aynı anda çalıştırıyor ve çalışıyor bir demo yapmak, donanımımın kolaylaştıracağı kadar. Şimdi Oracle'a geri dönmeme izin verin ve fark ederseniz, bunların hepsi aynı. DB2'deki performansımı ölçmek istersem, Oracle'da yapacağım seçeneklerle aynı. Şimdi kapakların altında çok farklı şeyler yapıyoruz, böylece neler olduğunu bilmek zorunda değilsiniz, ancak size tutarlı bir arayüz veriyoruz, böylece birden fazla veritabanı platformunda uzman olabilirsiniz. Bu, bu tartışmanın konusu olan dizinlerle çalışmayı da içerir.

Buraya gelmeme ve ilk önce bazı tablolara bakmaya başlamama izin verin ve birkaç tablo içeren bir film veri tabanım var. Müşteri tablosu gibi belirli bir masaya bakarsam, buraya getirdiğimde, masa tasarımımı görebilirim, işte masamdaki sütunlarım ve her sütun hakkında bilgi. Tablo özellikleri var, ama burada dizinler için bir sekme var ve burada tablodaki dizinler görebilirsiniz. Bu dizinlerden birinin birincil dizinim olan PK dizinim olduğuna dikkat edin. Bu diğerleri yalnızca sorgu erişimini iyileştirmek için dizinler olarak görünüyor, belki de ad veya soyadı ile sorgulıyoruz veya telefonlara ve posta kodlarına bakıyoruz. Ve burada bu posta kodu gibi belirli bir dizin seçersem ve üzerine çift tıklarsam, şimdi görebiliyorum, hey, benzersiz olmayan bir dizin ve burada diğer türlerden bazıları, bitmap, benzersiz olmayan, benzersiz, sıralı olsun ya da olmasın, bu günlüğe kaydetme olsun ya da olmasın, ters sırada olsun ya da olmasın, bir işlev tabanı olsun. Oh, işte eğlenceli bir tane. Aslında görünmez dizinlere sahip olabilirsiniz. Ve “Peki, neden halt görünmez bir indeks yapmak isteyeyim?” Dersiniz. Size iyi bir örnek vereyim. Üretim sisteminizdesiniz ve bir performans sorununuz var ve dizini oluşturmanın sorunu çözeceğinden emin değilsiniz, bu nedenle dizini oluşturmak ve üretimi yavaşlatmak istemiyorsunuz, ancak bir şekilde veya istediğiniz test edebilmek. Üretimde dizini görünmez olarak oluşturabilirsiniz, yani optimize ediciyi çağıran pek çok uygulama kodu bu dizini kullanmaz. Oluşturuldu, geçerli, ancak kullanılmayacak. Ardından, bu dizinin yardımcı olacağını düşündüğünüz bir sorgu veya bir dizi sorgu alabilir ve bir ipucu ekleyebilir ve “Hey, optimize edici, orada kullanmanızı ve izin vermenizi istediğim görünmez bir dizin var. işleri daha iyi yapıp yapmadığımı biliyorum. ”Ve şimdi üretimde bir şey test ettim, ama üretimde çalışan uygulamaları bozmadım. Görünmez bir endeksin kullanımı budur. İlk duyduğunuzda aptalca geliyor, ama bir yararı var.

Ayrıca, dizinlerde, paralel olup olmadıklarını ve kaç tane paralel paralel olduklarını tanımlayabiliriz. Şimdi, kümelenmemiş veya gerçek olmayan bir uygulama kümesi ortamında, bu nedenle rafsız, paralel, sorgumun denemek için kaç alt işlemin ve daha hızlı veya daha hızlı bir şekilde bir şeyleri denemek ve almak için çalışan alt işlemler anlamına geleceği anlamına gelir. . Ve paralel örnekler, eğer gerçek bir uygulama kümesindeysem, on düğümüm olduğunu varsayalım, bu çalışmanın kaç tanesine bölünmesine izin verilir? Belki on kişiden dördü ve her birinde dört alt süreç vardır. Bu bir örnek. Ve sonra anahtar sıkıştırmamız var. Gerçekten dizinleri sıkıştırabilir? Evet veya Hayır. Ve elbette dizinlerde belirtebileceğiniz depolama parametreleriniz var. Şimdi bunları kapsamadım çünkü bunlar bir dizin sorunundan çok bir depolama parametresi. Ve son olarak, bunları bölümlere ayrılmış ya da bölümlere ayırmayacak mıyız? Bir saniye burada bırakayım. Farklı bir şemaya gideceğim. Bu bir yıldız şemasıdır ve örneğin bu dönem tablosu bir boyut tablosudur. Yıldız şeması tasarımını daha önce yaptıysanız, bu veritabanında ve bu yıldız şemasında genellikle zaman için bir boyutunuz vardır, nokta bir zaman boyutudur. Şimdi, komik görüneceğini biliyorum, “Vay canına, tüm bu sütunlara bakın - adam normalleşmeyi duydu mu?” Bir veri ambarında veya bir yıldız şeması tasarımında olduğunuzda, tipik olarak, tipik olmayan bir kişinin bakacağı ve “Gee, bunlar çok iyi tasarlanmamıştır” diyebileceğiniz tablolarınız yoktur. Ama bunu veri ambarı ortamında yapmanın yolu budur.

Şimdi, ne olacağını izleyin, çünkü tamam, tüm bu sütunlar var, şuna bak, her sütunda bir indeks var. Şimdi, bir OLTP ortamında bu hayır-hayır olacaktır. Tüm operasyonlarımı yavaşlatacaktı. Veri ambarı ortamında, toplu yükleme döngülerim sırasında bunları düşürürüm. Yükü veya dizinleri olmadan yükleyin ve ben dizinleri yeniden. Tablonuzu bölümlediysem, tablodaki her kova için dizini bırakmak yerine, dizini o toplu yükleme döngüsü sırasında verilerin gireceği kovaya veya kovalara bırakabilirim. Ve sonra sadece bu bölümler için dizin bölümünü yeniden oluşturun. Ve bu onu çok yönetilebilir hale getiriyor. Ve eğer bakarsam - işte burada “Tatil Bayrağı” adlı bir sütun var ve bu evet ya da hayır. Bunun bir bitmap endeksi olduğuna dikkat edin ve çoğunuz için “Şey, bu mantıklı” diyeceksiniz. Evet veya hayır, Y veya N, mantıklı olan sadece iki değer var. Ve çünkü bitmap dizinleri için belgeleri okuduğunuzda, her zaman düşük kardinaliteye sahip bir şey seçmenizi söylerler.

Şimdi olgu tablolarımdan birine gireyim, işte burada emirlerim var. Ve bu benim günlük emirlerim. Ve şimdi göreceksiniz, yine birkaç sütunum var ve tekrar birkaç endeksim daha olacak. Ve tam burada, evrensel fiyat kodu adı verilen bir şey var. Bu bir perakende mağazası içindi, bu yüzden mağazada bir şey satın aldığınızda bu küçük barkodları biliyorsunuz, bu evrensel fiyat kodu. Şimdi milyonlarca evrensel fiyat kodu var. Şimdi, satış yapan bu şirket için, muhtemelen 1.7 ila 2 milyon evrensel fiyat koduna sahiptiler, bu yüzden bunun bitmap endeksi olmayacağını bekleyeceksiniz, çünkü 1.7 milyon farklı değer yüksek kardinalite gibi geliyor. Ancak gerçekte, veri ambarı ortamında bunun bir bitmap olmasını istiyorsunuz. Şimdi nedenini açıklayayım. Bu evrensel fiyat kodu için 1, 7 milyon farklı değer olabilir, bu sipariş tablosundaki satır sayısı yüz milyonlarca ila milyarlarca satır arasındadır. İndeksim, tablonun boyutuna veya kardinalitesine kıyasla düşük kardinalitedir. Bu onu düşük kardinalite yapar. Bu, bitmap dizinini, burada bitmap'i seçeceğiniz 1.7 milyon farklı değerle mantıksız olmasına rağmen, kullanışlı hale getirir. Şimdi, bir bitmap birleştirme endeksi kullanmak istediğimi bilseydim, şu anda ürün bunu desteklemiyor, bir sonraki sürüm için ekliyorum, ancak bu başka bir alternatif olacaktır. Ve bir yıldız şemasında, unutmayın, bitmap dizini olgu tablosunda olurdu ve B ağacındaki bir dizin, olgu tablosundaki satıra ve daha sonra bu olgu için boyut tablosunda görünen her satıra işaret eder . Ve burada başka bir seçeneğiniz daha var. Ve şimdi bakalım, şimdi tablolardan çıkmak istiyorum ve size hızlıca göstermek istiyorum, aynı bilgilere sahip olduğumu, dizinler altında ve aynı temel şeyi yapacağım.

Şimdi, bunu ortaya çıkarmamın nedeni, fark edebileceğinizdir, hey burada birincil anahtar yok. Birincil anahtarlar bir anahtar kısıtlamasıyla yapılır, bu yüzden aslında sınır tanımları kapsamındadır. Bunlar, kısıtlamanın bir parçası olmayan dizinler olacaktır. Şimdi, "Eh, bir dakika bekleyin, bu yabancı bir anahtar gibi görünebilir ve bir yabancı anahtar bir kısıtlamadır" diyebilirsiniz, ancak yabancı anahtarlar ve çoğu veritabanları, yabancı anahtar sütununda otomatik olarak bir dizin oluşturmaz, tavsiye ediyoruz ve işte gidiyorsunuz - yine aynı seçeneklere sahibim. Ve sadece sıkıştırılmak için değiştirmek istersem, bunu yapabilirim.

Şimdi sıkıştırma yalnızca bir B-ağacı dizininde çalışır. İzin veren şey, B ağacındaki çeşitli düğümlere baktığınızda, bazı değerlerin sıkıştırılmasına izin verir. Gerçekten tablo sıkıştırması gibi sıkıştırma değil, yaprak olmayan düğümlerdeki B ağacında depolananların bir sıkıştırmasıdır. Bir ton yerden tasarruf sağlamaz, ancak fark yaratabilir. Ve bununla birlikte, zamana oldukça yaklaşıyorum, bu yüzden yapmak istediğim şey, geri dönmek ve paylaşımımı durdurmak istiyorum. Ve idera.com'da on dört günlük deneme için ürünümüz var. Özellikle birden fazla veritabanı platformuyla çalışıyorsanız, oldukça iyi bir ürün. İki veya üç farklı veritabanıyla çalışıyorsanız, bu araç hayatınızı çok daha kolay hale getirecektir. Dizin tasarımı ve seçiminde size yardımcı olacak araçlarımız var, DB Optimizer adlı bir aracımız var. Bugün bunu başaramadım, bu çok fazla olurdu. Ve benimle iletişime geçmek istiyorsanız, e-posta adresim var, ya da özel e-postalarımda beni yakalayabilirsiniz ve bloglarım var, bir web sitem ve bloglarım var ve orada bir LinkedIn profili var. Bu yüzden, ürünle ilgili olmasa bile, herhangi bir konuda bana ulaşmaktan çekinmeyin, sadece veritabanları hakkında konuşmak istiyorsanız, kalpten bir inekim ve teknobabble hakkında gab'i sevmeyi seviyorum.

Eric Kavanagh: Pekâlâ, Dez, Robin, eminim en azýndan birkaç sorum olacak, burada bir kaç dakikamýz var. Dez, ne düşünüyorsun?

Dez Blanchfield: Size sormam gereken harika bir sorum var, aklımın arkasında oturuyor. Gördüğün en çılgın senaryo nedir? Blogunuzu okudum, sizi yakından takip ediyorum, - sen, muhtemelen neredeyse her yerde yaşayan birkaç kişiden birisin ve sanırım Dr. Robin Bloor tanıştığım ikinci kişi Hayatım boyunca. Ama, biliyorsunuz, muhtemelen her çılgın senaryoyu gördünüz, gördüğünüz en çılgın senaryolar nelerdir, karşılaştınız ve başa çıkamayan insanlar gibi, yürümeyi başardınız ve tüm bu DBArtisan ile Jedi zihin hileleri yapmak?

Bert Scalzo: Bir zamanlar, veritabanı tasarımlarında bir dosya düzeni tasarımında nasıl düşündüklerini çok düşündükleri bir müşterimiz vardı ve bu da - bir veritabanını normalleştirdiğinizde, yapmaya çalıştığınız ilk şey kurtulmak grupların tekrarlanması. Bir sütunları vardı ve uzun veya bir BLOB veya CLOB yaptılar ve içine değer, bir numara, noktalı virgül, ikinci değer, noktalı virgül, değer numarası, noktalı virgül koyacaklar ve binlerce değere sahip olacaklardı. orada, ancak o sütunda arama yapmaları gerekiyordu ve “Bu şey neden bu kadar yavaş çalışıyor?” gibi. Ve ben, “Şey, yaptığınız şey hakkında bir indeks oluşturamazsınız, sadece Bu yüzden, planları kullanarak onlara yapmaları gereken şeyin bu tabloyu normalleştirmek olduğunu gösterdik. Normalleştirme, işleri daha iyi hale getiren bir akademik alıştırma olduğu için değil, ancak bu alanda bir sorgulama istedikleri için, onu dizine ekleyebilmek istedikleri ve tekrarlayan bir grupta dizine ekleyemediğiniz veya en azından kolayca yapamayacağınız için . Ve bu muhtemelen şimdiye kadar gördüğüm en kötü şey.

Dez Blanchfield: Evet, ne sıklıkta karşılaştığınız ilginç, bence veritabanlarıyla ilgili zorluk, insanlar bunun bir bilim olduğunu unutuyor. Ve tüm bu alanda derece ve doktora yapan, üzerine kağıt yazan insanlar var ve TOAD el kitaplarınızı ve hafızadaki diğer şeyleri içeren bir yağma yazdınız. Şimdi "büyük veri" teklif alıntı eğilimi - Ben birçok kişi veritabanı mimarisi ve veritabanı teknolojisi, veritabanı bilimi, temel isterseniz unutuyorum görüyorum. Alanda, etkili bir şekilde yere çivi yaptığımızı geleneksel veritabanı platformlarından ve geleneksel veritabanı düşüncesinden uzaklaştıkça görüyorsunuz ve bu sadece performans ayarlama ve ölçeklendirme durumuydu. Bir çok insanın sadece orada oturdukları ve bir “a-ha” anı yaşadıkları, bir eureka anı gibi bir şeyler öğrendiklerini ve deneyimlediklerini görüyor musunuz, bu büyük veri şeyleri aslında gerçekten büyük veritabanlarıdır? Bu orada bir şey mi ve insanlar size geri dönüyor ve bir çeşit, “Unuttuk, ne bildiğimizi ve bizi karanlık taraftan geri getirebilir misiniz?”

Bert Scalzo: Hayır, hayır ve bu itiraf etmek korkunç bir şey, ancak ilişkisel veritabanı satıcıları da Kool-Aid'i içti. Hatırlarsanız, bilmiyorum, yaklaşık on yıl önce, yapılandırılmamış verileri ilişkisel veritabanlarına koymaya başladık, bu biraz garip bir şeydi ve sonra veriler, ilişkisel veritabanları şimdi NoSQL türünü ekliyor şey. Aslında, Oracle 12, CR2'de - henüz bitmediğini biliyorum - ama beta'ya bakarsanız, beta programındaysanız, parçalamayı destekler. Ve şimdi, NoSQL parçalama konseptine eklenmeyen ilişkisel bir veritabanınız var. Ve böylece, “a-ha” anı ilişkisel taraftaki “a-ha” ya giden insanlar için daha fazla gibi gözüküyor. Kimse bunu bir daha yapmayacak, veritabanı yöneticileri bile değil. gidip karanlık tarafa katılmalıyım.

Dez Blanchfield: Doğru, yani dağınık verilere birçoğu söylüyorsunuz, eğer doğru anlarsam, şu anda büyük veri platformları dediğimiz şeyin içine konuluyor, bu biraz komik, çünkü o kadar eski değil, ama bu onların kovaları için daha fazla patlama elde etmek için ilişkisel veritabanlarıyla ne yaptıklarına odaklandıkları anlamına gelmiyor mu?

Bert Scalzo: Hayır, genellikle, eğer büyük bir veri türü ihtiyacı olduğunu söyleyecek bir ihtiyacı varsa, diğer veritabanı platformuna gitmek ve olmayan bir şey yapmak yerine bunu buluyorlar. ilişkisel bir şekilde, veritabanı satıcıları şimdi bunları yapmak için ilişkisel veritabanı içinde aynı ilişkisel olmayan teknikleri veriyoruz. Yani, iyi bir örnek, bir JSON veri türü veya verilerin içine gömülü anlamı olan başka bir karmaşık veri türü gibi yapılandırılmamış verileriniz varsa, veritabanı satıcıları sadece bunu desteklemekle kalmaz, aynı zamanda size ACID verir. yapılandırılmamış verilere uygunluk. İlişkisel veritabanları daha yeni teknikleri ve teknolojileri benimsedi ve bu yüzden yine “a-ha” daha fazla görünmüyor gibi görünüyor, “Hey, uygulama geliştiricileri, bir şey öğrenmedik ve tekrar öğrenmemiz gerekiyor”, “Hey, şimdi bu şekilde yapıyoruz, geleneksel ilişkisel veritabanınızda nasıl bu şekilde yapabilirim ve bu veritabanında yaptığım gibi nasıl yapabilirim? ”ve bu daha yaygın hale geliyor ve dediğim gibi, veritabanı satıcılarının kendileri söyledi.

Dez Blanchfield: Doğru, DBArtisan aracı için bu alanda geleneksel şüpheliler kimler? Son zamanlarda yazdıklarınızla ilgili bazı ödevler yaptım ve bellekten bir şeyler yazmıştınız, bence bloglarınızdan biri, Oracle dünyasında aşırı veritabanı performansı. Ne zaman olduğunu hatırlayamıyorum, sanırım bu yıl hafızadan ya da geçen yılın sonlarından beri bu şeyi yazmıştınız. Bana öyle geliyor ki, bugün bahsettiğimiz konu türü için, insanların çok büyük ölçekli veritabanı ortamına gidecekleri ve içinde aşırı kazançlar dediğiniz şeyi arayan geleneksel, olağan bir şüpheliydi. DBArtisan'ı alıp iyi kullanıma sunan, orada gördüğünüz her zamanki şüpheliler kimler?

Bert Scalzo: Pek çok müşterimiz var, aslında, bugün çok büyük bir devlet kurumunda çalışıyordum - ve muhtemelen yazılımımızın 1.000 kopyasına yakın, çünkü insanların nasıl yapıldığını değil. Ve sorun değil, demek istediğim, herkes bir şeyi nasıl yapacağını bilmeli, ancak verimlilik “ne” yi yapıyor. Eğer iş benden bir görev yapmamı isterse, tüm ilgilendikleri budur. Ne zaman görev bittiğini söylemek için bir onay işareti aldım? Oraya ulaşmak için hangi tekniği veya hangi teknolojiyi kullanmadım. Ve böylece, aracımız neye odaklanmalarına izin veriyor ve çok daha üretken olmalarını sağlıyor ve bu gerçekten büyük avantaj ve dediğim gibi, bazı veritabanları sadece veritabanı platformları için bir araç sunuyor. On iki veritabanı platformu için sunuyoruz. Aynı iş akışına, aynı grafik kullanıcı arayüzüne, aynı navigasyonlara sahibim. Bir kullanıcıya nasıl ayrıcalık tanıyacağınızı veya bir tabloyu nasıl oluşturacağınızı veya veritabanında nasıl dizin oluşturacağınızı biliyorsanız, aynı görünüm ve his ve aynı iş akışı olduğu için bunu on ikide de yapabilirsiniz. Bunun müşterilerimiz için büyük bir değeri var.

Dez Blanchfield: Evet, sanırım insanlar insan kaynaklarından paraları için çok daha fazla patlama istiyorlar. Oracle, Ingres ve DB2'de bireysel uzmanların olduğu günler geride kaldı. İnsanların tüm esnafların Jack olması bekleniyor, bu yüzden bu şey kesinlikle hayatlarını kurtardı.

Doktor Robin Bloor'a teslim etmeden önce son bir an önce. On dört gün boyunca ücretsiz bir indirme olduğunu söylemiştiniz, ne yapacak - eğer devam edeceğim ve bunu yapacağım, bu arada, Bloor teknoloji laboratuvarına koyacağım ve bu şeyi döndüreceğim kalkıp kendim yap - bugün öncesinde bunu yapma şansım olmadı. On dört günlük bir denemeden bahsettiniz, bunu bilgisayarınızda bir VM'de çalıştırdığınızı söylediniz, bunun bir dizüstü bilgisayar olduğunu varsayıyorum. Birinin eline geçmesi ve on dört günlük denemeyi kullanması için Robin'in sorularına geri dönmeden hemen önce giriş seviyesi kurulumu nedir?

Bert Scalzo: Herhangi bir Windows ortamı, yani Windows 7, bir CPU ve dört gig bellek ile sanal makine. Gerçekten şişman ya da pahalı bir araç değiliz. Şimdi veritabanı sunucunuzu aynı Windows altında aynı VM'de çalıştırmak istiyorsanız, evet, daha fazlasını eklemeniz gerekir, ancak veritabanınızı bir veritabanı sunucusunda veya ayrı bir VM'de çalıştırıyorsanız, yüklenecek VM bizim ürün çalıştırmak çok hafif: bir CPU, dört gig bellek, hemen hemen tüm Windows sürümleri - ve biz hem otuz iki hem de altmış dört bit yüklemeleri destekliyoruz. Ancak veritabanı satıcınızın istemcisini kurmanız gerekir. Oracle'a bağlanmak istiyorsanız, SQL net istemcisini kurmanız gerekir, çünkü Oracle'ın bir veritabanıyla konuşabilmeniz için gereken budur.

Dez Blanchfield: Kulağa oldukça basit geliyor. Sanırım bundan bir şey, insanların almayı umduğum her şeyden daha fazlası, bu aracın hayatlarını kurtaracağının farkına varmak, gidip indirip onunla oynaması, on dört günlük ücretsiz deneme süresi sunduğunuz göz önüne alındığında. Ekstra bir şey yüklemeden mevcut dizüstü bilgisayarlarında çalışabilir, çünkü zaten veritabanı yönetimi yapıyorlarsa, zaten tüm bu araçlara sahip oldukları veritabanları ile çalışıyorlar ve yerel bir VM'de veya yerel masaüstü, yüklemek ve oynamak için ağrısız gibi görünüyor. Bu yüzden insanların bunu yapmasını tavsiye ederim.

Robin, eminim sorularınız var ve Eric, muhtemelen seyirciden bazılarınız var, bu yüzden Robin, size geçip sonra Eric'e geri dönmeye ne dersiniz?

Robin Bloor: Evet, tamam, söyleyecek bir şeyim var, yani, bu alanı her zaman büyüleyici buldum çünkü öyleydi - dişlerimi kestim. Ama gerçek şu ki, muhtemelen 1998, 1999'dan beri, Oracle'ın gerçekte neler yapabildiğinden rahatsız oluyordum. Ve Sybase ve Microsoft SQL Server'ı tanıyordum, her ikisi de Oracle'ın yapabileceklerine kıyasla oldukça basit. Sen beni güldürdün - yani, ağzımı örttüm, parçalanma hakkında konuşmaya başladığında. Oracle bunu daha önce yapmıştı. Oracle bir süre sonra tanıtıldı, nesne-ilişkisel fikirden endişe duydular, bu yüzden Oracle'da bir tür nesne gösterimi ve nesne depolama yaratma yeteneğini tanıttılar ve mühendislerinden biriyle konuştum, birkaç şey gibi yıllar sonra tanıttılar ve kaç kişi kullandığını sordum ve iki müşterinin denediğini düşündüğümü söyledi. Ve sanırım trend olan NoSQL şeylerini denemeye ve yapmaya başlarlarsa aynı şey olacak. Biliyorum, bence bu bir hata, yani, düşüncelerinle ne ilgilendiğimi düşünüyorum. Kesinlikle, onlar - Kool-Aid'i içiyorlar. Cassandra gibi büyük NoSQL veritabanlarına benzer iddialarda bulunabilmeleri gerektiğini düşünüyorlar, ama biliyorsunuz, bu sizin için bir anlam ifade ediyor mu?

Bert Scalzo: Hayır, kafasına çiviyi vurdun. Bana göre, ilişkisel yapacaksam, Oracle veya SQL Server veya DB2 veya Postgres gibi ilişkisel bir satıcı seçeceğim, ancak ilişkisel olmayan bir şey yapacağım, büyük veri alanında veya NoSQL alanında, doğru iş için doğru aracı seçeceğim. Ve bunun doğal olarak öncelikle ilişkisel veritabanı tedarikçime gideceğini düşünmüyorum. Ve sonra, diğer kırışıklığı eklersiniz, yani bulutta neler var? Veritabanlarını ön plana çıkarmak isteyen birçok insan. Sonra bulut sağlayıcınıza bakıp “Tamam, ne sağlıyorsunuz, benim için hangi veritabanlarına ihtiyacım var ve ne kadar satılabilir olduklarını ve açıkçası bu veritabanını kullanma ücretinin ne olduğunu söylemelisiniz. saatte veya günde bulutta. Ve gigabayt veya terabayt başına mı? ”Ve bulacağınız şey, Mongo veya Cassandra gibi nispeten daha yeni veritabanlarından bazılarıdır, belki de oranları daha ucuzdur, bu nedenle çok petabayt tipi büyük veriler yapacaksanız, - sadece maliyet açısından - buluttaki NoSQL veritabanlarını dikkate almak zorundalar çünkü bunu yapmanın en uygun maliyetli yolu olabilirler.

Robin Bloor: Evet, doğru. Demek istediğim, benim türüm - deneyimlerimdeki ilişkisel veritabanları hakkındaki şey - yara izleri olacak kadar uzun, elbette - uygulamaya başlarsanız ve - ilişkisel aslında ne olduğunu anlıyorsanız, Yani, bir müşteriyle bir kez danışmanlık yapacağımı hatırlıyorum ve beni bir odaya yönlendirdiler ve bir tür varlık diyagramı oluşturdular ve üçüncü normal bir form oluşturdular, şirketin birincil sistemlerinin nasıl bir model olduğunu. İki yüz kırk masa vardı ve dediler ki, “Peki, bunun hakkında ne düşünüyorsun? Bunun için bir veri tabanı oluşturacağız ”dedi ve“ Bunun hakkında ne düşünüyorsun? ”Dedim.“ Bunun işe yarayacağını sanmıyorum. ”Dedim. 11 birleşme yerlerinde belirli bir yapı oluşturmak için İlişkisel hakkında anlaşılması gereken şey budur. Bu yüzden, ne kadar kötü tasarımla karşılaştığınızla ilgileniyorum. DBArtisan ile herhangi bir sorunum yok - çok mantıklı şeyler yapıyor ve aslında birden fazla platformda gösterebileceğiniz gerçeği, bence, harika - ama tasarımın nerede olduğu konusunda orada ne kadar karşılaşıyorsunuz insanlar bunun hakkında kar tanesi y almak yerine bir yıldız şemasına gelirlerse, her türlü gönül yarasını çözebilirlerdi, biliyor musunuz?

Bert Scalzo: Öyle, küstah veya kibirli gibi gelmek istemiyorum, ama daha sık söylemezdim. Açıkçası, orada yer aldığım veritabanlarının çoğunda sorun ya da sorun var. Bu iyi, çünkü veritabanı iyileştirici aracımız gibi araçlarımız bu sorunları çözmelerine yardımcı olabilir ve benim için gerçekten komik olan şey, birçok sorunun tekrar tekrar aynı basit problemler olmasıdır. Geçen gün sadece on bir katılım sorgusu olan bir müşteriyle çalışıyordum ve “Tamam, neden bir cümle kullanmadınız?” Gibiydim ve onlar, “Eh, yapmadım Bunun ne olduğunu bilmiyorum. ”Ve sonra dedim ki, “ Ve burada sizin ilişkisel ve ilişkisel olmayanlarınızdaki alt seçimlerinize bakın, ”dedim, “ Bazı durumlarda, nerede olduğunuzda en derin hükmünüz var, dıştan bir tablo referansı. ”dedim, “ Bu, onu doğru seviyeye çıkarın, olması gerekenden daha derine gömmeyin, optimize ediciyi şaşırtacaksınız. ”Ve birkaç ince ayar ile biz yaklaşık iki saat süren bir şey aldı ve on dakikaya indirdi ve sadece - bu durumda yazdıkları SQL'i geliştirmek dışında bir şey yapmadık. Sorun şu ki, pek çok üniversite ve akademik olmayan bir ortamda programlamayı öğrenen birçok insan, bunu kaydedilmiş zaman süreçleri veya satır yönelimli süreç olarak öğreniyorlar ve ilişkisel doğa tarafından yönlendirilmiş bir kümedir ve böylece iyi SQL yazmak için setler halinde düşünmek zorunda.

Robin Bloor: Evet, bence bu kesinlikle doğru. Ve şunu anlamalısınız, bu gibi şeyler, insanlar böyle şeylerin ABC'lerini bilmelidir. Önemli değil. Eğer iyi tasarlanmış, iyi modellenmiş bir veritabanının bile birleşimin zaman alacağını, çeşitlerin zaman alacağını fark etmezseniz, rasyonel şeyler yapamayacaksınız. Bunu yaparlar çünkü dünya bunları hızlı bir şekilde yapmanın bir yolunu bulamamıştır. Verileri organize etmenin yollarını bulmuşlar, böylece aksi halde daha hızlı geçiyorlar ve NoSQL veritabanları için söylemem gereken coşku, birleştirme yapmaktan kaçınmaları. Veritabanlarını sadece aynı veri yayılımıyla oluşturmaya başlarlar, çünkü NoSQL veritabanlarından herhangi birine katılırsanız, kudretle emerler. Düşünmüyor musun?

Bert Scalzo: Kesinlikle. Ve gülmem gerekiyor, çünkü ilişkisel veritabanlarından önce ve Ingres İlişkisel Teknoloji Enstitüsü iken ve SQL'imiz olmadığında, SQL öncesi ilişkisel dillerimiz vardı. Bence Ingres'de o zamanlar Quel deniyordu. Böylece, ağ ve daha yüksek bir grafik veya hiyerarşik gibi eski veritabanı paradigmalarından aldınız ve birkaç on yıl sonra ilişkisel paradigmalardan geçiyorsunuz ve şimdi bana göre tekrar neredeyse hiyerarşik bir şekilde geri dönüyormuşuz gibi geliyor. Neredeyse geri döndük gibi.

Robin Bloor: Evet, doğru. Seni Eric'e versen iyi olur, çok fazla zaman harcıyorum ama seyirciden sorularımız var mı Eric?

Eric Kavanagh: Evet, birkaç tane var. Burada biraz uzun gidiyoruz ama sana bir çift atacağım. Görünmez endeksler hakkında birkaç sorumuz vardı. Bir soru, “Birinin bunları görmek için aracınızı kullanması gerekiyor mu?” Başka bir soru, “Peki, körseniz ne olur?”

Bert Scalzo: Bu iyi bir tane.

Eric Kavanagh: Meraklı bir soru da, sadece FYI.

Bert Scalzo: Hayır, aletlerimize sahip olmanıza gerek yok. Bu bir Oracle özelliği, görünmez dizin. Temel olarak veri sözlüğünde Oracle, “Optimizer, bu dizini yoksay” diyen bir meta veri parçası tutar. Burada, ancak fiziksel olarak SQL komutunda bir iyileştirici ipucu ile bir ipucu ile talimat verilmediği sürece, bunu kullanmayın. ”Ve böylece, hayır, araçlarımıza ve her açıdan buna sahip olmanıza gerek yok düz bir eski dizindir, herhangi bir araçta görebilirsiniz, sadece optimize edici "Normal sorgu işlemede görmezden geleceğiz" diyecektir. Kullanılmasını istiyorsanız yönlendirmeniz gerekir. Tanımladığım senaryo için gerçekten kullanışlıdır, eğer üretimde bir endeks oluşturmak istiyorsanız, ancak raporları veya halihazırda çalışmakta olan şeyleri kırma riski taşımıyorsanız, ancak bunları test etmek istiyorsanız, bunu yapabilirsiniz. Bunun için en kullanışlı olanı budur.

Eric Kavanagh: Bu iyi şeyler ve burada başka iyi bir soru daha vardı. “Bu yeni bellek içi veritabanlarından bazıları ne olacak? Bellek içi veritabanı teknolojisi oyunu dizine ekleme konusunda nasıl değiştirir? ”

Bert Scalzo: Oğlum, biz iyi - şimdi bu iyi, birisinin bu soruyu sorduğuna sevindim, yarım saat daha gitmemiz gerekecek. Hayır, bellek içi, veritabanı satıcısına bağlıdır. Şimdi, normalde, ben, Oracle'ın yaptığı her şeyi övmekten başka bir şey konuşmuyorum çünkü yaptıkları teknoloji inanılmaz, ancak kapakların altına yırtıldığında ve Oracle'da, Oracle'da bellekte ne olduğuna baktığınızda veritabanı, gerçekte hala diskte satır deposunu tutuyor ve bellekte depolanmış sütun deposunu alacak ve tüm tabloyu tutmak için yeterli bellek yoksa, bölümler için geri dönecek; belleğe sığmaz, satır deposuna sığar ve böylece tabloya karşı ve masanın yarısı için bir seçim yapabilirsiniz, masada geleneksel satırlara ve diğer yarısına isabet eden bir indeksleme kullanıyorsunuz. aslında dışarı çıkıyor ve sadece bir bellek içi aramadan her şeyi alıyor ve bu nedenle, SQL Server'ın örneğin Hekaton teknolojisi, bilirsiniz ve SQL 2014 ile uyguladığı şekliyle farklı ve geliştirildi SQL 2016'da, ancak bazı açılardan, onlarınki bellekte daha gerçek bir versiyonudur ve her uygulamanın bir artıları ve eksileri vardır, ancak kapakların altına bakmanız ve fark etmeniz gerekir. Çünkü, “Ah bu tablonun hafızasında - sadece tüm dizinleri hazırlayacağım” diyen bir müşterim vardı ve “Tablonun sunucudaki hafızanızdan daha büyük, bu yüzden bir noktada sorgunun bir kısmı diske çarpıyor. ”

Eric Kavanagh: Bu iyi bir açıklama; bu iyi şeyler. Millet, bu yılın geri kalanında bu adamlarla birkaç tane daha web yayını yapacağız, Bert'in bir sunumda olduğunu duyduğunuz her an geri döneceğiz, çünkü eşyalarını bildiğini biliyoruz. Uzmanlarla konuşmak her zaman eğlencelidir. Tüm bu web yayınlarını daha sonra izlemek üzere arşivliyoruz. İşte Bert'in iletişim bilgileri bir kez daha ve indirme için bu bağlantıyı kazmaya ve e-postayla göndermeye çalışacağız, ancak her zaman kendinize e-posta gönderebilirsiniz:, bunun için dizilmiş bir sürü daha fazla web yayınımız var yıl ve biz şu anda ed cal yapıyoruz, yani millet, gelecek yıl gerçekten duymak istediğiniz herhangi bir konu varsa, utanmayın: millet, bir dahaki sefere seninle konuşacağız. Güle güle.

Techopedia İçerik Ortağı

Techopedia Staff, Bloor Group'a bağlıdır ve sağdaki seçenekler kullanılarak iletişime geçilebilir. Sektör ortaklarıyla nasıl çalıştığımız hakkında bilgi için buraya tıklayın.

• Profil
• İnternet sitesi