Techopedia Staff, 19 Nisan 2017
Paket Servisi: Ev sahibi Eric Kavanagh, Dr. Robin Bloor, Rick Sherman ve IDERA'nın Bullett Manale ile tahminlerini tartışıyor.
Videoyu izlemek için bu etkinliğe kaydolmalısınız. Videoyu görmek için kaydolun.
Eric Kavanagh: Bayanlar ve baylar, bir kez daha merhaba ve Hot Technologies web yayını serisine tekrar hoş geldiniz! Benim adım Eric Kavanagh, “En İyi Tahminlerle Zaman, Para ve Sorundan Tasarruf Etme” adlı bugünkü web seminerine ev sahipliği yapacağım. Kurs “Buradaki En İyi Planlar” başlıklı bölümün ilk bölümünü kaçırdım. bu şovda hep bunun hakkında konuş. Bu nedenle, Hot Technologies, elbette bugün dünyada bazı harika ürünlerin neler olduğunu, kurumsal teknoloji dünyasını, insanların onlarla neler yaptığını, nasıl çalıştıklarını, bu tür eğlenceli şeyleri anlamaya yönelik forumumuzdur.
Ve bugünkü konu, önerdiğim gibi, tahminle ilgileniyor. Gerçekten kuruluşunuzda neler olacağını anlamaya çalışıyorsunuz. Ne yaparlarsa yapsınlar kullanıcılarınızı nasıl mutlu tutacaksınız? Analiz yapıyorlarsa, gerçek iş yapıyorlarsa, işlem sistemleri olan gerçek müşterilerle karşılaşıyorlar, durum ne olursa olsun, sistemlerinizin nasıl çalıştığını ve neler olduğunu anlamak istiyorsunuz ve biz de Bugün hakkında konuşacağım. Bu biraz komik çünkü tahmin yapmaktan hoşlandığım bir şey değil, çünkü batıl inançlıyım, sanırım çok fazla tahmin edersem kötü şeyler olacak, ama bu sadece benim. Beni takip etme.
İşte bugün bizim sunumcularımız, gerçekten sol üst köşede, Rick Sherman Boston'dan, IDERA'dan arkadaş Bullett Manale'den ve kendi Dr. Robin Bloor'umuzdan geliyor. Ve bununla Robin'e teslim edeceğim ve sadece insanlara hatırlatacağım: Soru sor, utangaç olma, iyi soruları seviyoruz, onları bugünkü sunumcularımıza ve diğerlerine dağıtacağız. Ve bununla, Robin, götür onu.
Robin Bloor: Tamam, dedikleri gibi kutup pozisyonunda olduğum için, bugün bir SQL hikayesi anlatacağımı düşündüm, çünkü devam edecek tartışmanın arka planı ve kaçınılmaz olarak çatışmayacak çünkü Rick buna odaklanmıyor ve Rick'in söyledikleriyle çatışmayacak. SQL hikayesi, SQL hakkında bazı ilginç şeyler var çünkü çok baskın. Bakın, bu bir yazım hatası, SQL bildirimsel bir dildir. Fikir, istediğinizi isteyebileceğiniz bir dil oluşturabileceğinizdi. Ve veritabanı bunu nasıl elde edeceğini hesaplar. Ve aslında oldukça iyi çalıştı, ancak bu konuda söylemeye değer bir dizi şey var, tüm BT endüstrisini bildirici bir dile dayandırmanın sonuçları. Kullanıcı verilerin fiziksel organizasyonunu bilmiyor veya umursamıyor ve bu bildirim dili hakkında iyi bir şey - sizi bunlardan ayırıyor ve hatta endişeleniyor - sadece ne istersen sor ve veritabanı gidip alacak.
Ancak, kullanıcının SQL sorgusunu yapılandırma biçiminin sorgunun performansını etkileyip etkilemeyeceği hakkında hiçbir fikri yoktur ve bu biraz dezavantajlıdır. Yüzlerce ve yüzlerce satır uzunluğunda, sadece bir SQL isteği olan sorgular gördüm, bilirsiniz, “select” ile başlar ve sadece alt sorgular vb. İle devam eder. Ve aslında, bir veritabanından belirli bir veri koleksiyonu istiyorsanız, SQL ile birçok farklı şekilde isteyebilir ve verilerle biraz aşina iseniz aynı cevabı alabilirsiniz. Bu nedenle, bir SQL sorgusu veri istemenin en iyi yolu değildir ve veritabanları, içine koyduğunuz SQL'e göre oldukça farklı yanıt verir.
Ve böylece, SQL aslında performansı etkiler, bu yüzden SQL kullanan insanlar, onlar için de geçerlidir, SQL kullanan SQL programcıları için de doğrudur ve sahip olacakları etki hakkında düşünmeleri daha az olasıdır, çünkü odaklarının çoğu aslında verinin manipülasyonu üzerinedir ve verinin elde edilmesi, yerleştirilmesi değil. Aynı şey BI araçları için de geçerlidir, isterseniz çeşitli veritabanlarının BI araçlarından sıkılan SQL'i gördüm ve söylenmesi gerekir ki, bunun birçoğu, t Böyle SQL sorguları yazmayın. Birisi, isterseniz, parametreler ne olursa olsun, biraz SQL atacak ve yine SQL'in verimli SQL olmayacağı küçük bir motor yarattı.
Sonra empedans uyumsuzluğundan söz edeceğimi düşündüm, programcıların kullandığı veriler sıralandığı gibi verilerden farklı. Bu nedenle, DMS'imiz verileri tablolarda depolar, nesne yönelimli kod çoğunlukla kodlayıcıdır, günümüzde nesne yönelimli formu programlıyor ve nesne yapılarında veri sipariş ediyorlar, bu yüzden birini diğerine eşlemiyorlar. Bu nedenle, programcının verileri düşündüğünden veritabanının verilerin ne olduğunu düşündüğüne çevirmesi gerekir. Bu durumun böyle olması için yanlış bir şey yapmış olmalıyız gibi görünüyor. SQL, veri tanımı için DDL'ye sahiptir, veri almak için DML - veri işleme dili - seçin, projelendirin ve katılın. Şimdi, çok az matematik ve çok az zamana dayalı şeyler var, bu yüzden kusurlu dil, ancak genişletilmiş ve genişletilmeye devam ettiği söylenmeli.
Ve sonra, her zaman diyagramdan daha düz olan SQL bariyer problemini elde edersiniz, ancak birçok insan analitik nedenlerden dolayı sorular soruyordu, soru veri terimlerinin cevabını aldıktan sonra başka bir soru sormak istiyorlar. Yani, bir iletişim kutusu haline geliyor, SQL, iletişim kutuları için oluşturulmadı, aynı anda ne istediğinizi sormak için tasarlandı. Ve bunu bilmeye değer, çünkü orada kullanıcı ve veri arasındaki konuşmayı mümkün kılmak için SQL'i terk eden bazı ürünler var.
Veritabanı performansı açısından - ve bu tür her şeye yayılıyor - evet, CPU var, bellek var, disk var, ağ ek yükleri var ve belirli bir verideki verileri özel olarak kullanmak isteyen birden fazla kişinin kilitleme sorunu var zaman içinde. Ancak zayıf SQL çağrıları da var, SQL'i performans açısından gerçekten optimize ederseniz yapılabilecek çok şey var. Yani, veritabanı performans faktörleri: kötü tasarım, kötü program tasarımı, eksik iş yükünün eşzamanlılığı, yük dengeleme, sorgu yapısı, kapasite planlama. Bu veri büyümesi. Ve birkaç kelimeyle, SQL uygundur, ancak kendi kendini optimize etmez.
Bunu söyledikten sonra, Rick'e geçebileceğimizi düşünüyorum.
Eric Kavanagh: Pekala Rick, sana WebEx arabanın anahtarlarını vereyim. Götürün.
Rick Sherman: Tamam, harika. Teşekkürler Robin, sunumun başlangıcında başladığımda grafiklerim hala oldukça sıkıcı, ama devam edeceğiz. Bu yüzden Robin'in SQL tarafında bahsettiği her şeye katılıyorum. Ama şimdi biraz konsantre olmak istediğim şey, çok hızlı bir şekilde geçeceğimiz veri talebi, o alanda kullanılan araçlarda olduğu gibi veya o alandaki araçlara olan ihtiyaçtır.
Öncelikle, okuduğunuz her makalede büyük veriler, çok sayıda veri, buluttan gelen yapılandırılmamış veriler, hayal edebileceğiniz her yerde büyük verilerle ilgili bazı şeyler var. Ancak veritabanı pazarının büyümesi, muhtemelen 2015 itibariyle ilişkisel veritabanı olan SQL ile sürekli olarak veritabanı pazarının yüzde 95'ini oluşturuyor. En büyük üç ilişkisel tedarikçi bu alandaki pazar payının yaklaşık yüzde 88'ine sahiptir. Robin'in söylediği gibi SQL hakkında hala konuşuyoruz. Aslında, Hadoop platformuna baksak bile, bir veri bilimcisi olan oğlumun her zaman kullandığı Hive ve Spark SQL - kesinlikle insanların verilere ulaşmasının en baskın yolu.
Şimdi, veritabanı tarafında, veritabanlarının kullanımının iki geniş kategorisi vardır. Biri operasyonel veritabanı yönetim sistemleri, yani kurumsal ilişki planlaması, müşteri ilişkileri yönetimi, yani Salesforce ERP'leri, Oracles, EPIC'ler, N4'ler, vb. Ve, veri ambarlarında ve diğer iş zekası tabanlı sistemlerde çok sayıda ve genişleyen miktarda veri var. Çünkü her şey, nerede ve nasıl yakalandığına, saklanmasına veya işlem görmesine bakılmaksızın, sonunda analiz edilir ve bu nedenle veritabanlarının, özellikle de pazardaki ilişkisel veritabanlarının kullanımında büyük bir talep ve artış olur.
Şimdi, talep var, çok büyük miktarda veri geliyor. Ve gerçekten sadece büyük verilerden bahsetmiyorum, her türlü kuruluşta veri kullanımı hakkında konuşuyorum. Ancak, bir arz açısından, bu kaynakları yönetebilen insanlar için, ilk önce bir çeşit DBA sıkıntısı çekiyoruz. İşgücü İstatistikleri Bürosu'na göre, 2014-2024'ten itibaren DBA işleri sadece yüzde 11 büyüyecek - şimdi DBA iş unvanları olan insanlar, ama bir saniye içinde - 40- artı yıllık veri büyüme alanı yüzdesi. Bir çok DBA'mız var; ortalama olarak aynı çalışmanın ortalama yaştan bahsettiği diğer BT mesleklerine göre oldukça yüksektir. Ve sonra, sahadan ayrılan, emekli olmak zorunda olmayan, ancak başka yönlere kaybolan, yönetime giren ya da her neyse birçok insanımız var.
Şimdi, ayrılma nedenlerinin bir kısmı, DBA işinin gittikçe sertleşmesi. Öncelikle, birçok farklı veritabanını yöneten DBA'larımız, her yerde bulunan fiziksel veritabanları ve farklı türdeki veritabanları var. Şimdi bu ilişkisel olabilir veya başka bir veritabanı, veritabanı türleri de olabilir. Ancak ilişkisel olsa bile, yönetmeye çalıştıkları bir, iki, üç, dört farklı satıcıdan herhangi birine sahip olabilirler. DBA'lar genellikle veritabanının veya uygulamanın tasarımından sonra dahil olur. Robin, veritabanlarının veya uygulamaların nasıl tasarlandığından, SQL'in nasıl tasarlandığından bahsetti. Veri modelleme, ER modelleme, genişletilmiş ER modelleme, boyut modelleme, gelişmiş boyutlu modelleme, ne olursa olsun, tipik olarak uygulama programcıları ve uygulama geliştiricileri nihai hedefleri düşünülerek tasarlanırlar - verimlilik için tasarlamazlar veritabanı yapısının kendisi. Yani çok kötü tasarımımız var.
Şimdi ticari kurumsal uygulama satıcılarından bahsetmiyorum; genellikle ER modelleri veya genişletilmiş ER modelleri vardır. Bahsettiğim, her şirkette uygulama geliştiricileri tarafından inşa edilen çok daha fazla iş süreci ve uygulama var - bunlar dağıtımın verimliliği veya etkinliği için tasarlanmamış olanlar. Ve DBA'ların kendileri aşırı çalışıyor ve bazen 7/24 sorumlulukları var, gittikçe daha fazla veritabanı alıyorlar. İnsanların ne yaptıklarını ya da nasıl yaptıklarını tam olarak anlamadıkları için bunun bir miktar etkisi olduğunu düşünüyorum. Kendi küçük grupları ve insanları sadece “Bütün bu araçların kullanımı çok kolay, iş yüklerinde daha fazla veri tabanına atmaya devam edebiliriz” diye düşünüyorlar.
Bu da bizi yarı zamanlı ve kazara DBA'lara götürüyor. Küçük IT ekiplerimiz var ve mutlaka özel bir DBA'ya gücü yetmiyor. Artık bu, veritabanı ve veritabanı uygulamalarının genişlemesinin son on yılda patladığı ve genişlemeye devam ettiği küçük ve orta ölçekli işletmeler için geçerlidir. Ancak, genellikle uzun, uzun süredir veri ambarı, iş zekası analizi yapan büyük şirketler için de geçerlidir. Uzun zaman önce bu projeler için özel DBA'lar alıyorduk; artık asla özel bir DBA elde edemiyoruz. Veritabanını tasarlamaktan sorumluyuz, ki eğer tecrübesi olan biri varsa sorun değil. Ancak genel olarak, DBA'lar uygulama geliştiricilerdir, genellikle bu rolü işlerinin yarı zamanlı bir parçası olarak alırlar, resmi eğitim almazlar ve yine son hedefleri için tasarlarlar, verimlilik için tasarlamıyor.
Tasarım ve geliştirme arasında, dağıtım ve yönetime kıyasla çok fazla fark var. Yani, orada küçük bir kumbara ile "kuruş bilge, kiloluk aptal" var, projelerde gereken beceri ve kaynakları elde atlayarak. Herkesin “İneklerin İntikamı” ndan olduğunu düşünerek, benim küçük resmim. Şimdi, insanların ihtiyaç duydukları kadarıyla, SQL'de veritabanları ve verileri yaygın bir şekilde kullanıyoruz. Kısıtlı sayıda DBA'mız var - bu ayarlama ve tasarım ve yönetim ve dağıtım durumlarında yetenekli ve uzman kişiler. Ve daha fazla yarı zamanlı veya tesadüfi DBA'mız var, resmi eğitimi almayan insanlar.
Peki, bu veritabanlarının da ayarlanmadığı veya yönetilmediği konusuna giren diğer şeylerden bazıları nelerdir? Öncelikle, birçok kişi veritabanı sisteminin kendilerini yönetmek için yeterli araçlara sahip olduğunu varsayar. Şimdi, araçlar daha kolay ve daha kolay hale geliyor - tasarım ve geliştirme - ancak bu, dağıtım için iyi bir tasarım ve iyi yönetim, kapasite planlama, izleme vb. İlk olarak, insanlar ihtiyaç duydukları tüm araçlara sahip olduklarını varsayarlar. İkinci olarak, yarı zamanlı veya yanlışlıkla bir DBA iseniz, ne bilmediğinizi bilmiyorsunuz.
Sanırım oradaki bazı ifadeleri unuttum, böylece çoğu zaman tasarımda neye bakmaları gerektiğini veya veritabanlarını yönetirken veya çalıştırırken ne anlamadıklarını anlamıyorlar. Bu sizin mesleğiniz değilse, ne yapmanız gerektiğini anlamayacaksınız. Üçüncüsü, SQL'in bir gitme aracı olması, Robin'in SQL'den ve SQL'in bazen ne kadar kötü inşa edildiğinden veya sıklıkla oluşturulduğundan bahsetti. Ayrıca, BI veri ambarı, veri taşıma, veri mühendisliği alanındaki evcil hayvanımdan biri, pahalı bir veri entegrasyon aracı kullanıyor olsalar bile, araçları kullanmak yerine, insanların SQL kodu, saklı yordamlar yazma eğilimi olduğu veya pahalı bir BI aracı, genellikle sadece saklı yordamları çalıştırmak için kullanırlar. Böylece veritabanı tasarımını, SQL inşasını anlamanın önemi gittikçe önem kazanıyor.
Ve son olarak, bireysel insanlara bireysel veritabanlarına baktığımız bu silo yaklaşımı var. Uygulamaların nasıl çalıştığına ve birbirleriyle nasıl etkileşime girdiğine bakmıyorlar. Ayrıca genellikle veritabanlarını, kullandıkları uygulamalara karşı incelerler. Bu nedenle, veritabanında aldığınız iş yükü tasarımda kritik, ayarlamada kritik, kapasite için nasıl planlanacağını anlamaya çalışırken kritik, vb. Yani, ormanlara ağaçlardan bakmak, insanlar yabani otlar içindedir, tek tek tablolara ve veritabanlarına bakarak ve bu uygulamaların iş yükündeki genel etkileşimlerine bakmıyoruz.
Son olarak, insanların bakmaları gereken kilit alanlara bakmaları gerekir. Veritabanlarını yönetmeyi planladıklarında, önce düşünmeleri, bazı uygulama merkezli performans metrikleri geliştirmeleri gerekir, bu yüzden sadece bu tablonun nasıl yapılandırıldığına değil, özellikle nasıl modellenmesine değil, nasıl kullanıldığına bakmaları gerekir? Dolayısıyla, tedarik zinciri yönetiminde olması gereken kurumsal uygulamanız varsa, web üzerinden sipariş alıyorsanız, BI yapıyorsanız - ne yaparsanız yapın - kimin kullandığına, nasıl olduklarına bakmanız gerekir veri hacminin ne olduğunu, ne zaman olacağını kullanır. Gerçekten aramaya çalıştığınız şey bekleme süreleridir, çünkü ne olursa olsun, tüm uygulamalar, bir kişi veya yalnızca uygulamalar veya işlemciler arasındaki veri alışverişi olsun, bir şeyin yapılması ne kadar sürdüğü ile değerlendirilir. Ve darboğazlar neler? Sıklıkla sorunları ayıklamaya çalışırken, elbette, gerçekten gerçek darboğazların ne olduğuna bakmaya çalışıyorsunuz - her şeyi nasıl ayarlayacağınız değil, ancak performanstan nasıl kurtulur ve performansı bekleme sürelerine nasıl yükseltirsiniz? ve verim - bakmanız gereken her şey.
Ve gerçekten de veri yakalamayı, işlemleri, veritabanındaki analizleri ve analitiği ayırmanız gerekiyor. Bunların her birinin farklı tasarım desenleri vardır, her birinin farklı kullanım desenleri vardır ve her birinin farklı ayarlanması gerekir. Bu nedenle, bu verilerin nasıl kullanıldığını, ne zaman kullanıldığını, ne için kullanıldığını düşünmeniz ve performans metriklerinin ne olduğunu ve bu kullanımla ilgili analiz etmek istediğiniz temel şeylerin ne olduğunu bulmanız gerekir. Şimdi, performansı izlemeye baktığınızda, veritabanı işlemlerinin kendisine bakmak istiyorsunuz; hem veri yapılarına bakmak istersiniz, böylece veritabanının dizinleri, bölümlenmesi ve diğer fiziksel yönleri, hatta veritabanının yapısı - ister ER modeli ister boyutsal modeli olsun, yapılandırılmış olsun - tüm bunların performans üzerinde etkisi vardır, özellikle farklı veri bağlamlarında analitiği ve gerçekleşen dönüşümleri yakalar.
Robin'in SQL tarafında da bahsettiği gibi, bu veritabanları arasında bu farklı uygulamalar tarafından çalıştırılan SQL'e bakmak ve bunu ayarlamak kritik önem taşır. Genel uygulama iş yüklerine ve bu veritabanlarının ve uygulamaların üzerinde çalıştığı altyapı ortamına bakalım. Böylece, ağlar, sunucular, bulut - ne çalışıyorlarsa çalışsınlar - bu uygulamaların ve bu veritabanlarının bu bağlamda yarattığı etkiyi inceleyerek, tüm bunların veritabanını ayarlayabilme etkileşimi vardır.
Ve son olarak, araçlara bakarken, bununla ilgili üç farklı analitik türüne bakmak isteyebilirsiniz. Açıklayıcı analize bakmak istiyorsunuz: neler olduğu ve nerede olduğu, veritabanı ve uygulama performansı ile ilgili. Sadece ne olduğunu değil, neden oluyor, darboğazlar nerede, problemler nerede, neyin iyi gittiğini, neyin iyi gitmediğini anlamak için tanısal analitik yapma yeteneğine sahip olmak istiyorsunuz. Ancak, tasarım için veya ne yapmanız gerekiyorsa, bunları ele almak için sorunlu alanları analiz edip inceleyebilmek.
Ve son olarak, en agresif veya proaktif analiz türü, aslında bazı tahmine dayalı analiz, tahmine dayalı analitik modelleme yapmaktır. Veritabanının ve uygulamaların bu bağlamda çalıştığını biliyoruz, kapasiteyi arttırırsak, daha fazla kullanıcı alırsak, daha fazla verim yaparsak, ne yaparsak yapalım, neyi, nasıl ve nerede projelendirebileceğimizi biliyoruz. veritabanını, uygulamaları etkilemek, proaktif olarak, darboğazların nerede olduğunu, bekleme sürelerinin nerede olabileceğini ve bir şeyleri düzeltmek için ne yapmamız gerektiğini planlamamıza ve çözmemize olanak tanır. Bu nedenle, bu üç analiz türünde olduğu gibi performans metriklerini uygulayabilen, performansı izleyebilen araçlara sahip olmak istiyoruz. Ve bu benim genel bakışım.
Eric Kavanagh: Pekâlâ, bırak onu - bu arada iki harika sunum - burayı oradan almak için Bullett Manale'ye bırakayım. Ve millet, iyi sorular sormayı unutmayın; zaten iyi içeriğimiz var. Götürün, Bullett.
Bullett Manale: Kulağa hoş geliyor. Teşekkürler, Eric. Rick'in söylediği ve Robin'in söylediklerinin çoğu, yüzde 100 katılıyorum. Bu slaydı yukarı çektiğimi söyleyebilirim, çünkü uygun olduğunu düşünüyorum, 80'lerde “A-Team” hayranları olanları bilmiyorum, John Hannibal Smith her zaman “Bir plan bir araya geldiğinde seviyorum” diyorum ve özellikle odaklandığımız SQL Server hakkında konuştuğunuzda, bugün konuşacağımız ürün olduğunu düşünüyorum, SQL Diagnostic Manager, kesinlikle sahip olmanız gereken şeylerden biri; sahip olduğunuz verilerden yararlanabilmeniz ve bu verilerden kararlar alabilmeniz ve bazı durumlarda bir karar aramamanız gerekir; bir şeyin kaynakları tükettiği zaman, kaynaklarınız tükendiğinde, bir darboğazınız olduğunda, bu tür şeyleri size söyleyecek bir şey arıyorsunuz.
Sadece belirli bir metriği izlemekle ilgili değil. Diagnostic Manager ile, çok iyi yaptığı şeylerden biri, tahmin ve iş yüklerine özgü anlayış açısından size yardımcı olacaktır ve bugün bunun hakkında konuşacağız. Araç, veri yöneticisi, DBA veya oyunculuk DBA için hazırlanmıştır, bu yüzden Rick'in bahsettiği birçok şey, oyunculuk DBA çok doğrudur. Birçok durumda, bir DBA değilseniz, bilmediğiniz şeyler, bir SQL ortamını yönetme zamanı geldiğinde sahip olacağınız birçok soru işareti olacaktır. Ve böylece size yardımcı olacak bir şeyler arıyorsunuz, sizi bu süreçten geçirin ve sizi de bu süreçte eğitin. Bu nedenle, bu tür kararlar için kullandığınız aracın, bu kararların alınmasının nedenleri hakkında size bir fikir vermesi önemlidir, size sadece “Hey, bunu yapın” demez.
Ben oyunculuk DBA'sım, nihayetinde bu başlığı desteklemek için gerçek uzmanlığa ve bilgiye sahip tam gelişmiş DBA olabilirim. Yani, bir veritabanı yöneticisi olmaktan bahsederken - her zaman önce bu slaydı göstereceğim, çünkü DBA'nın bazı farklı rolleri var ve birlikte olduğunuz organizasyona bağlı olarak, sahip olacaksınız, bunlar bir yerden başka bir yere değişecek - ancak tipik olarak, her zaman bir şekilde depolama alanınızdan, o depolamayı planlamanızdan ve ne kadar yer beklediğinizi anlamanızdan sorumlu olacaksınız. ister yedeklemeniz için olsun, ister veritabanlarının kendileri için olsun. Bunu anlamanız ve değerlendirmeniz gerekecek.
Buna ek olarak, işleri gerektiği gibi anlayabilmeniz ve optimize edebilmeniz gerekecek ve çevrenin izlenmesine devam ederken, ihtiyaç duyduğunuz şeyleri temel alarak, çevrenin kendisinde değişim. Dolayısıyla, kullanıcı sayısı, uygulamaların popülerliği, bir veritabanının mevsimselliği gibi şeyler, tahmininizi yaparken göz önünde bulundurulmalıdır. Ve sonra, açıkça raporları ve bu kararları vermekle ilgili olarak gerekli olan bilgileri sağlayabilme açısından başka şeylere bakmak. Birçok durumda bu karşılaştırmalı analiz yapmak anlamına gelir; belirli bir metriğe özel olarak bakabilmek ve bu metriğin değerinin zaman içinde ne olduğunu anlayabilmeniz, böylece ilerleyeceği yeri tahmin edebilmeniz anlamına gelir.
Teşhis Yöneticisi'nin yaptığı bir çok şey bu yeteneklere sahiptir ve insanlar her gün tahmin gibi şeyler yapmak için onu kullanır ve ben burada kapasite planlamasının tanımını koydum. Ve oldukça geniş ve aslında oldukça belirsiz bir tanımdır, bu sadece bir kuruluşun ürünleri için değişen talepleri karşılamak için ihtiyaç duyduğu üretim kapasitesini belirleme sürecidir ve günün sonunda, hepsi bununla ilgilidir: bir şekilde sahip olduğunuz bilgileri alabilmek ve bu bilgileri almak ve veritabanlarınızın yaşam döngüsünde ilerlerken ilerlemenize yardımcı olacak kararlar almak. Ve böylece, insanların bunu yapmasının nedenleri olan şey türleri, her şeyden önce, çoğu durumda, paradan tasarruf etmek için açıktır. İşletmeler, belli ki, ana hedefleri para kazanmak ve tasarruf etmektir. Ancak bu süreçle birlikte, bu aynı zamanda kesinti sürenizden emin olmamanız anlamına gelir, kesinti süresi yoktur. Ve herhangi bir kesinti oluşma olasılığını azalttığınızdan emin olabilmeniz için, bunun başlamadan, başka bir deyişle, gerçekleşmesini beklemeden ve sonra tepki vermekten kaçınmasını sağlayın.
Kullanıcılarınızın verimliliğini genel olarak artırabilmenin yanı sıra, daha fazla iş yapabilmeniz için onları daha verimli hale getirmek de burada anahtardır, bu nedenle bunlar DBA veya öngörme veya kapasiteye dahil olan şeylerdir. planlama, bu kararları alabilmek için bilgiden geçebilmelidir. Ve sonra, genel olarak, bu sadece para açısından değil, aynı zamanda zaman ve sadece genel olarak başka şeyler için kullanılabilecek kaynaklar açısından atıkları ortadan kaldırmanıza yardımcı olacaktır. Böylece, bu atığı ortadan kaldırabilmeniz, böylece atığın kendisine bağlı fırsat maliyetlerine sahip olmamanızı sağlar.
Bununla birlikte, DBA olan kişiye özgü aldığımız soru türleri nelerdir? Ne zaman yer kalmayacak? Bu büyük bir şey, sadece şu anda ne kadar yer harcadığım değil, trendlere ve geçmiş tarihe dayanarak ne zaman tükeneceğim? Gerçek SQL örnekleri ile aynı şey, hangi sunucuları birleştirebilirim? VM'lere biraz koyacağım, hangi veritabanlarını birleştireceğim ve hangi SQL örneklerinde bulunmaları açısından mantıklı olan şey nedir? Tüm bu tür soruların cevaplanabilmesi gerekir. Çünkü çoğu durumda, eğer bir DBA ya da oyunculuk yapan DBA iseniz, bunu kariyerinizde bir araya getireceksiniz. Birçok durumda, bunu sürekli olarak yapacaksınız. Yani, bu kararları hızlı bir şekilde verebilmelisiniz, söz konusu olduğunda tahmin oyunları oynamamalısınız.
Darboğazlar ve bir sonraki aşamada nerede gerçekleşecekleri hakkında konuştuk, bunun gerçekleşmesini beklemek yerine bir kez daha tahmin edebildik. Açıkçası, bahsettiğimiz tüm bu şeyler, çoğu zaman bu önerileri oluşturabilmek veya bazı durumlarda kararları kendiniz formüle edebilmek için tarihsel verilere güvendiğiniz mantıklıdır. bu cevapları bulabilmek. Ancak bana, menkul kıymet veya başka bir şey satan bir kişinin radyo reklamlarını duyduğunuzda, her zaman “geçmiş performans gelecekteki sonuçların göstergesi değildir” ve bu tür şeyleri hatırlatıyor. Aynı şey burada da geçerli. Bu tahminlerin yapıldığı durumlarınız olacak ve bu analizler yüzde 100 doğru olmayabilir. Ancak, geçmişte ve bilinen şeylerle uğraşıyorsanız ve bu tür soruların birçoğuyla “ne olursa olsun” alıp yapabilmeniz çok değerlidir. ve tahmin oyunu oynamaktan çok daha fazlasını elde edeceksiniz.
Yani, bu tür sorular açıkça ortaya çıkacaklar, bu yüzden bu soruların birçoğunu Teşhis Yöneticisi ile nasıl ele alacağız, her şeyden önce tahmin yeteneklerine sahibiz, bunu veritabanında, masada da yapabiliyoruz sürücü veya birim olarak. Sadece “Hey, yer doluyuz” diyebilmek için değil, altı ay sonra, iki yıl sonra, beş yıl sonra, bunun için bütçeliysem, ne kadar sürücü alanı gidiyorum bütçeye ihtiyacım var? Bunlar soracağım sorular ve tahmin etmek ve parmağımı havaya kaldırmak ve rüzgarın hangi yöne doğru patladığını görmek yerine bunu yapmak için bir yöntem kullanmam gerekecek, bu da maalesef bu kararların birçoğunun verilme şeklidir.
Buna ek olarak, - slaytımın orada biraz kesildiği gibi görünüyor - ama öneriler şeklinde biraz yardım sağlayabiliyor. Bu nedenle, size metriklerle dolu bir gösterge tablosu gösterebilmeniz ve “Tamam, işte tüm metrikler ve nerelerde olduklarını” söyleyebilmeniz, ancak daha sonra bir şeyler yapabilmeniz veya buna dayanarak ne yapılacağı başka bir sıçrayış. Ve bazı durumlarda, insanlar bu kararları alabilmek için DBA rolü konusunda yeterince eğitimlidir. Ve böylece araçta size yardımcı olacak bazı mekanizmalar var, ki bu size sadece bir saniyede göstereceğiz. Ancak, sadece tavsiyenin ne olduğunu göstermek değil, aynı zamanda bu tavsiyenin neden yapıldığına dair bir fikir vermek ve bunun da ötesinde, bazı durumlarda, gerçekte otomasyonu otomatikleştiren bir komut dosyası oluşturabilmek bu sorunun giderilmesi de idealdir.
Burada göreceğimiz bir sonrakine geçmek, genellikle normal olanı metrik seviyeye kadar anlamaktan bahsediyor. Normalin ne olduğunu bilmiyorsam, normal olmayanın ne olduğunu söyleyemem. Ve böylece, bunu ölçmek için bir yol olması ve birden fazla alan türünü göz önünde bulundurmanız gerekir, örneğin - veya zaman çerçeveleri demeliyim - farklı sunucu grupları, bunu dinamik olarak yapabilir, uyarıcı bir perspektiften, başka bir deyişle, gece yarısı, bakım pencerem boyunca, devam eden tüm bakıma göre CPU'mun yüzde 80 oranında çalışmasını bekliyorum. Bu nedenle, o zaman dilimlerinde, günün ortasında belki de çok fazla aktivite yapmadığım zamanlarda, eşiklerimi daha fazla artırmak isteyebilirim.
Bunlar açık bir şekilde çevresel olacak bazı şeylerdir, ancak yönetilenlere uygulayabileceğiniz, o ortamı daha verimli bir şekilde yönetmenize yardımcı olmak ve bunu daha kolay hale getirmek için uygulayabileceğiniz şeyler. Diğer alan, açıkçası, bu tür “eğer” sorularına cevap verebilmek için raporları ve bilgileri genel olarak sunabilmektir. Eğer çevremde yeni bir değişiklik yaptıysam, bu etkinin ne olduğunu anlamak istiyorum, böylece aynı değişikliği çevremdeki diğer örneklere veya diğer veritabanlarına da uygulayabilirim. Bu değişikliği gönül rahatlığıyla yapabilmek ve bunun iyi bir değişiklik olacağını bilerek bazı bilgilere veya mühimmat sahibi olmak istiyorum. Dolayısıyla, bu karşılaştırmalı raporlamayı yapabilmek, SQL örneklerini sıralayabilme, veritabanlarımı birbirlerine karşı sıralayabilme, “Hangisi en yüksek CPU tüketicim?” Veya hangisini en uzun süredir alıyor? bekleme şartları ve bunun gibi şeyler? Yani bu bilgilerin çoğu araçla da mevcut olacak.
Ve son olarak, en önemlisi, yolunuza çıkan herhangi bir durumla başa çıkacak bir araca ihtiyacınız olan genel bir yetenek ve bu yüzden demek istediğim, büyük bir ortamınız varsa, çoğu durumda, geleneksel olarak DBA'nın bazı durumlarda izlemek isteyeceği metrikler olmayan metrikleri bu duruma bağlı olarak çekmeniz gereken durumlarla karşılaşacaksınız. Bu nedenle, ek metrikler ekleyebilmek ve bu metrikleri, kutudan çıkmış olmanız durumunda kullanacağınız form ve tarzda kullanabilmek için genişletebileceğiniz bir araca sahip olmak metrik, örneğin. Bu nedenle, raporları çalıştırabilme, uyarabilme, taban çizgisi - bahsettiğimiz tüm şeyler - aynı zamanda bu öngörmeyi yapabilmenin ve yapmanın önemli bir parçasıdır, böylece aradığınız cevapları alırsınız bu kararları verebilme, ilerleyebilme.
Şimdi Diagnostic Manager'ın bunu yaptığı gibi, merkezi bir hizmetimiz var, çalışan bir hizmet grubumuz var, 2000 ila 2016 örneklerine karşı veri toplıyor. Ve sonra yaptığımız şey, bu verileri almak ve bunu merkezi bir depoya koymak ve sonra bu verilerle yapacağımız şey, açıkçası, daha fazla içgörü sağlamak için çok şey yapmak. Şimdi, buna ek olarak - ve burada olmayan şeylerden biri de - gecenin ortasında çalışan bir hizmetimiz var, bu bizim tahmin analiz hizmetimiz ve bu da bir miktar çatırtı yapıyor ve anlamaya yardımcı oluyor ve bu tür önerilerde bulunabilmeniz, taban çizgileri hakkında da fikir verebilmeniz için size bir DBA veya DBA rolüyle yardımcı olabilir.
Yani, yapmak istediğim şey, ve bu sadece mimariye hızlı bir örnek, buradaki büyük paket aslında yönettiğiniz örneklerde oturan herhangi bir ajan veya hizmet yok. Ama yapmak istediğim, aslında sizi buradaki uygulamaya götürmek ve hızlı bir demo sunmak. Ve ben de dışarı çıkayım ve bunu gerçekleştireyim. Bana bildirin, sanırım Eric, bunu görebiliyor musun?
Eric Kavanagh: Şimdi anladım, evet.
Bullett Manale: Tamam, bu yüzden sizi konuştuğum bu farklı bölümlerden bazılarına götüreceğim. Ve esas olarak, burada yapmanız gereken bir şey, ya da gelecekte gelecekte bir nokta olan bir şey ve size bunun hakkında bir fikir vereceğiz. Ve bu, olayları gerçekte olduğu gibi gerçekten tahmin edebiliyor - ya da dinamik olarak tahmin etmeliyim. Şimdi, raporlar söz konusu olduğunda, araçta sahip olduğumuz şeylerden biri üç farklı tahmin raporudur. Ve örneğin, bir veritabanı tahmini söz konusu olduğunda, bir süre boyunca bir veritabanının boyutunu tahmin edebilmek durumunda ne yapacağım ve size bunun birkaç örneğini vereceğim. . Bu yüzden, oldukça G / Ç yoğun olan denetim veritabanımı alacağım - çok fazla veri var. Bakalım, bakalım, bunu burada yapacağız ve sadece sağlık veritabanını burada seçelim.
Ama mesele şu ki, sadece bu alanın ne olduğunu görmüyorum, diyebilirim ki, “Bak, geçen yılki veriye bakalım” - ve burada biraz fibireceğim, Gerçekten bir yıllık verim yok, yaklaşık iki aylık veri var - ama, burada örnek bir ay oranı seçtiğim için, bunu tahmin edip tahmin edebileceğim Örnek 36 oranımız - yani bir birim, bir ay - olarak ayarlandığından sonraki 36 birim için, daha sonra, gelecekteki büyümemizi nereden tahmin edeceğimizi göstermek için bir rapor çalıştırabilirim. üç veritabanı. Ve üç farklı veritabanı arasında, özellikle tarihsel olarak tükettikleri veri miktarına göre değişen bir fark veya varyansımız olduğunu görebiliriz.
Buradaki veri noktalarının tarihsel verileri temsil ettiğini görebiliriz ve ardından bu satır, bize bunu destekleyecek sayılarla birlikte tahmin sağlayacaktır. Bunu masa düzeyinde yapabiliriz, bunu, montaj noktaları da dahil olmak üzere sürücülerimin ne kadar büyük olacağını tahmin edebileceğim sürücü düzeyinde bile yapabiliriz. Aynı tür bilgileri tahmin edebiliriz, ancak bir kez daha, örnekleme oranına bağlı olarak, tahmin etmek istediklerimizi kaç birim ve nerede aldığımızı belirlememe izin verir. Ayrıca farklı türde tahmin türlerine de sahibiz. Tahmin yapmanın zamanı geldiğinde, birçok seçenek ve esneklik elde edersiniz. Şimdi, yapacağımız şeylerden biri, aslında size belirli bir tarih vermek ve “Hey, bu tarihte, verilerinizin büyümesini öngördüğümüz yer” diyebilmemizdir. Buna ek olarak, mesai saatleri içinde gerçekleştirdiğimiz bazı analizlerle ve çalıştığı zaman hizmetle ilgili diğer bilgileri size sunar. Yaptığı şeylerden bazıları, geçmişte ne zaman meydana geldiğinin tarihine dayanarak, büyük olasılıkla gerçekleşecek şeyleri tahmin etmeye çalışmaktır.
Burada görebiliyoruz, aslında, bir tahmin bize bir kez daha geçmişte olan şeylerden yola çıkarak akşam boyunca sorun yaşama ihtimalimiz hakkında bir fikir veriyor. Açıkçası bu harika, özellikle de bir DBA değilim, bu şeylere bakabilirim, ancak bir DBA değilsem daha iyi olan bu analiz sekmesidir. Bu yüzden, burada araçta bulunmadan önce, ürünü insanlara gösterirdik ve “Bu harika, tüm bu sayıları görüyorum, her şeyi görüyorum, ama ne yapacağımı bilmiyorum” (gülüyor) “Bunun bir sonucu olarak.” Ve burada sahip olduğumuz şey, anlayabilmeniz için daha iyi bir yol, eğer performansa yardımcı olmak için harekete geçeceksem, hatta harekete geçeceksem ortamımın sağlığına yardımcı olmak, bu önerileri sunmanın sıralı bir yoluna sahip olmanın yanı sıra, bu öneriler hakkında daha fazla bilgi edinmek için bilgi konusunda yararlı ipuçlarına sahip olabilmek ve aslında bu verilerin bazılarıyla dış bağlantılara sahip olmak, beni bu önerilerin yapılma nedenlerine götür.
Ve birçok durumda, dediğim gibi, bu sorunların giderilmesini otomatikleştirecek bir komut dosyası sağlayabilme. Şimdi, bu analizle burada yaptığımızın bir kısmı - ve bu örneğin özelliklerini yapılandırmaya gittiğimde göstereceğim ve analiz yapılandırma bölümüne gidiyorum - birçok farklı kategorimiz var burada listelenen ve bunun bir parçası olarak, dizin optimizasyonu ve sorgu optimizasyonu var. Bu yüzden, yalnızca metrikleri ve bunun gibi şeyleri değil, iş yükleri ve dizinler gibi şeyleri de değerlendiriyoruz. Bu durumda, aslında bazı ek varsayımsal indeks analizi yapacağız. Yani, istemediğim durumlardan biri, çoğu durumda, gerekmiyorsa bir dizin eklemek istemiyorum. Ama bir noktada bir tür devrilme noktası var, burada diyorum ki, “Tabii, tablo iş yükü içinde çalışan sorguların boyutuna veya türlerine ulaşıyor şimdi bir dizin eklemek mantıklı. Ama belki altı hafta önce mantıklı olmazdı. ”Bu nedenle, dediğim gibi, çevrede olup bitenlere, iş yüklerinde neler olduğuna bağlı olarak performansı artıracak şeyler hakkında dinamik bir şekilde bilgi edinmenizi sağlar. ve bu tür şeyler yapıyor.
Ve böylece burada bir sürü iyi bilgi ve bunları otomatik olarak optimize etme yeteneği elde edersiniz. Öyleyse, bu tahmine dayalı analiz dediğimiz açıdan yardımcı olabileceğimiz başka bir alan. Buna ek olarak, söylemeliyim ki, karar vermenize yardımcı olmak için genellikle kendilerini ödünç verdiğimizi düşündüğüm başka alanlarımız da var. Ve karar vermekten bahsettiğimizde, bir kez daha, tarihsel verilere bakabilmek, bizi bu performansı iyileştirmek için ihtiyacımız olan yere götürmek için biraz fikir veriyor.
Şimdi, yapabileceğimiz şeylerden biri, hangi metriği istediğimizi seçerek seçmemize izin veren bir temel görselleştiricimiz var - ve burada iyi bir tane bulmama izin verin - SQL CPU kullanımına gidiyorum, ama mesele sensin bununla birlikte, aykırı değerlerinizin ne zaman olduğunu görmek, genellikle bu değerlerin veri topladığımız süreler içinde nereye düştüğünü görmek için bu resimleri boyamak için birkaç hafta geriye gidebilir. Ve sonra, buna ek olarak, asıl örneğe gittiğimizde, taban çizgilerimizi yapılandırma yeteneğine sahip olduğumuzu da fark edeceksiniz. Ve taban çizgileri, şeyleri otomatik hale getirmenin yanı sıra şeylerden haberdar olabilmenin gerçekten önemli bir parçasıdır. Ve çoğu DBA'nın size söyleyeceği gibi, ortamınızın gün boyunca, akşam ve akşam boyunca, örneğin bakım süreleriyle birlikte daha önce belirttiğimiz gibi, her zaman aynı şekilde çalışmamasıdır. yüksek CPU seviyesine veya olabilecek her şeye sahip.
Yani, bu durumda, bu gerçek taban çizgileriyle birden fazla taban çizgisine sahip olabiliriz, bu yüzden örneğin bir temel çizgim olabilir, bu da bakım saatlerim sırasında. Ama üretim saatlerim için bir taban çizgisi oluşturmak kadar kolay olabilirdi. Ve bunu yapmanın amacı, bir SQL örneğine girdiğimizde ve aslında bu birden fazla taban çizgisine sahip olduğumuzda, o zaman bir tür otomasyon, bir tür iyileştirme veya genel olarak uyarmak, tahmin edebilmek ve yapabilmek, bu zaman pencerelerine özgü. Burada, göreceğiniz şeylerden biri, ürettiğimiz bu taban çizgileri, bu analizi sağlamak için geçmiş verileri kullanıyor, ancak daha da önemlisi, bu eşikleri statik olarak değiştirebilirim, ancak bunları dinamik olarak da otomatikleştirebilirim. Bu nedenle, bakım penceresi olarak veya bakım taban çizgisi penceresinin geldiğini söylemeliyim ki, bu eşikler otomatik olarak o zaman aralığında karşılaştığım yüklere, yüklerimin olduğu gün ortasında iş yükleri o kadar etkili olmadığında değil.
Yani, bu, taban çizgisi açısından akılda tutulması gereken başka bir şey. Açıkçası, bunlar sizin için gerçekten yararlı olacaktır, ayrıca neyin normal olduğunu anlamak ve aynı zamanda anlayabilmek, kaynaklarınız tükenirken de meşgul olacaktır. Şimdi, araçta sahip olduğumuz diğer bir şey, karar vermenize yardımcı olacak, ayrıca temel çizgileri ve bu temel çizgileri ve dinamik olarak oluşturduğunuz eşikleri etrafında uyarılar ayarlayabileceğiniz gibi, daha önce söylediğim gibi, neler olup bittiğiyle ilgili soruları yanıtlamama yardımcı olacak sayısız rapor çalıştırabiliyordum.
Yani, örnek olarak, yönettiğim 150 bir örneğim varsa - benim durumumda yapmıyorum, bu yüzden burada taklit oyunu oynamalıyız - ama tüm üretim örneklerime sahipsem ve nerede olduğumu anlamam gerekiyorsa dikkat etmem gereken alan, başka bir deyişle, performansı artırmak için belirli bir yönetim türünü gerçekleştirmek için sınırlı bir zamanım olacaksa, kilit alanlara odaklanmak istiyorum. Ve böylece, şöyle diyebilirim ki, “Bu ortama dayanarak, örneklerimi birbirlerine karşı sırala ve bana çekişme borusuna göre sıralamayı ver” diyebilirim. Disk kullanımı, bellek kullanımı, beklesin, tepki zamanı olsun, bu örnekleri birbiriyle ilişkilendirebilirim - ya da rütbe diyebilirim. Açıkçası, her listenin en üstünde olan örnek, aynı örnekse, muhtemelen odaklanmak istediğim bir şeydir, çünkü açıkça listenin en üstünde yer alır.
Böylece, araçta ortamın örnek düzeyinde sıralanması konusunda size yardımcı olacak birçok raporunuz var; bunu veritabanı düzeyinde de yapabilirsiniz, burada veritabanlarımı birbirlerine karşı sıralayabilirim. Özellikle belirleyebileceğim eşikler ve alanlar için, yalnızca belirli veritabanlarına odaklanmak istersem, burada joker karakterler oluşturabilirim, ancak asıl mesele, veritabanlarımı aynı şekilde karşılaştırabileceğim. Ayrıca, diğer karşılaştırmalı analiz türleri ve bu araçtaki en büyük analiz, sahip olduğumuz temel analizdir. Dolayısıyla, burada hizmet görünümüne ilerlerseniz, bir temel istatistik raporu olduğunu görürsünüz. Şimdi bu rapor, sadece metrik değerlerin ne olduğunu anlamamıza yardımcı olacak, ancak belirli bir örnek için dışarı çıkabileceğim ve bu metriklerden herhangi biri için, bu metriklerin temel hatlarına gerçekten bakabileceğimiz açıktır.
Yani, ne olursa olsun, yüzde veya ne olursa olsun dışarı çıkıp “Son 30 günde bunun temelini görelim” deyin, bu durumda bana taban çizgisine karşı gerçek değerleri gösterecek ve Açıkçası, bu bilgiyi kullanarak bazı kararlar verebilirim, bu yüzden bu, hangi soruya bağlı olduğu, o zaman sorduğunuz durumlardan biridir. Ancak bu, bu soruların çoğunda size yardımcı olacaktır. Keşke her şeyi yapan bir raporumuz olduğunu söyleyebilseydim, bu kolay bir rapor gibi, bastığınız ve düğmeye bastığınız ve sadece cevaplayabileceğiniz her “ne olursa olsun” sorusunu cevaplar. Ama gerçek şu ki, aradığınız bu “ne olursa olsun” türündeki soruları formüle edebilmek için bu açılan menülerden seçim yapabileceğiniz birçok özelliğe ve seçeneğe sahip olacaksınız. .
Dolayısıyla bu raporların çoğu bu tür sorulara cevap verebilmeye yöneliktir. Ve böylece, bu raporların ve ek olarak, daha önce de belirttiğim gibi, araçta zaten gösterdiğimiz tüm şeylerin, yeni metrikleri dahil etme, yönetilebilme, hatta oluşturabilme esnekliğine sahip olması da çok önemlidir. bu soruları yanıtlamama yardımcı olmak için, belki de izlemeyi beklemediğimiz kutunun dışında, bu şeyleri ekleyebilirsiniz. Ve sonra size az önce gösterdiğim şeylerin hepsini yapabilirsiniz: taban çizgisi, raporlar çalıştırın ve bu metrikten raporlar oluşturun ve size gösterdiğim bu farklı şeylerin çoğunu yanıtlayabilir ve yapabilirsiniz buraya.
Şimdi, buna ek olarak - ve son zamanlarda açık bir şekilde karşılaştığımız şeylerden biri - ilk önce herkes VM'leri çeviriyor veya geçiş yapıyor. Ve şimdi buluta doğru ilerleyen birçok insanımız var. Ve bu tür şeylerin etrafında ortaya çıkan birçok soru var. Buluta geçmem benim için anlamlı mı? Buluta geçerek para biriktirecek miyim? Bunları sanal makineye, paylaşılan kaynak makinesine koyacak olsaydım, ne kadar tasarruf edebilirim? Açıkçası bu tür sorular da ortaya çıkacak. Bu nedenle, çoğu şey akılda tutuluyor, Tanı Yöneticisi ile hem VMware hem de Hyper-V'nin sanallaştırılmış ortamlarını ekleyebilir ve onlardan çekebiliriz. Ayrıca bulutta bulunan örnekleri de ekleyebiliriz, böylece Azure DB gibi ortamlarınız, hatta RDS gibi, bu ortamlardan da metrikler alabiliriz.
Bu nedenle, insanların yöneldiğini gördüğümüz diğer ortam türleri ile ilgili olduğu için bu sorulara çok fazla esneklik ve cevap verebilme. Ve hala bu konuda birçok soru var ve insanların bu ortamları pekiştirdiğini gördüğümüzde, bu soruları da yanıtlayabilmeleri gerekecek. Yani, bu konuyla ilgili olarak, Tanı Yöneticisi'ne oldukça iyi bir genel bakış derim. İş zekası konusunun geldiğini biliyorum ve iş zekası için bugün bahsetmediğimiz bir aracımız var, ama aynı zamanda bu tür soruları sizin ile ilgili olarak cevaplama konusunda size fikir verecektir. küpler ve tüm bu farklı şeyler de. Ancak umarım bu, en azından bu ürünün iyi bir plan formüle etmede nasıl yardımcı olabileceği açısından iyi bir genel bakış olmuştur.
Eric Kavanagh: Tamam, iyi şeyler. Evet, hala dışarıdaysa Rick'e fırlatacağım. Rick, senden soru var mı?
Rick Sherman: Evet, önce, bu harika, hoşuma gitti. Özellikle VM'lere ve bulutlara uzanmayı seviyorum. Birçok uygulama geliştiricisinin bulutta olması durumunda ayar yapmaları gerekmediğini düşündüğünü görüyorum. Yani-
Bullett Manale: Doğru, hala ödemek zorundayız, değil mi? İnsanların buluta koydukları her şey için hala ödeme yapmanız gerekiyor, bu yüzden zayıf çalışıyorsa veya çok fazla CPU döngüsüne neden oluyorsa, daha fazla para ödemeniz gerekiyor, bu yüzden değil, hala bu şeyleri ölçmek gerekiyor, kesinlikle.
Rick Sherman: Evet, bulutta birçok kötü tasarım gördüm. Sormak istedim, bu ürün de kullanılacak mı - BI ürününden bahsettiğinizi ve birbirinizle etkileşen tonlarca başka ürününüz olduğunu biliyorum - ancak SQL performansına, bu araçtaki bireysel sorgulara bakmaya başlar mısınız? Yoksa bunun için kullanılacak başka araçlar mı?
Bullett Manale: Hayır, bu kesinlikle. Bu, kapsamadığım şeylerden biri ve bunun sorgulama kısmı. Sorgu performansını tanımlamak, bununla ilgili olsun, özellikle bu görünümde gördüğümüz gibi beklemek veya genel olarak sorguların kaynak tüketimi ile ilişkili olup olmadığını belirlemek için birçok farklı yolumuz var, sorguyu analiz edebilmemizin birçok yolu var verim. Süre, CPU, I / O ve bir kez daha, bir miktar içgörü sağlamak için iş yüklerine de bakabiliriz. Analiz bölümündeki önerileri sağlayabiliriz ve ayrıca sorguların kendileri hakkında bilgi sağlayan web tabanlı bir sürümümüz vardır. Böylece eksik dizinler ve yürütme planını ve tüm bu tür şeyleri görüntüleme yeteneği hakkında öneriler alabilirim; aynı zamanda bir yetenek. Bu yüzden, kesinlikle, sorguları Pazar'a yedi şekilde teşhis edebiliriz (güler) ve kaynak tüketimi, beklemeler, süre, tüm bu iyi şeyler gibi yürütme sayısı açısından bu içgörü sağlayabiliriz.
Rick Sherman: Tamam, harika. Ve sonra tüm bu izlemeyle örneklerin kendileri üzerindeki yük nedir?
Bullett Manale: Güzel bir soru. Bu soruyu cevaplamanın zorluğu, başka bir şey gibi bağımlı olması. Aracımızın sunduğu birçok şey, esneklik sağlar ve bu esnekliğin bir parçası, neyi toplayıp neyi toplamayacağınızı söyleyebilmenizdir. Örneğin, sorguların kendisiyle, bekleme bilgilerini toplamak zorunda değilim, ya da yapabilirim. Bir süreyi aşan sorgular, yürütme hakkında bilgi toplayabilirim. Bunun bir örneği olarak, yapılandırma sorgu izleyicisine gidecek olsaydım ve “Bu değeri sıfıra değiştirelim” diyecektim, gerçek şu ki, aracı çalıştıran her sorguyu toplar ve neden orada olduğunu ruhu, ancak genel olarak tüm sorgular için tam bir veri örneği vermek istersem, bunu yapabilirim.
Yani, ayarlarınızın genel olarak, kutudan çıktığı haliyle çok göreceli. Yüzde 1-3-3 arasında bir yerdedir, ancak uygulanacak başka koşullar da vardır. Ayrıca ortamınızda ne kadar bağlantı noktası sorgusunun çalıştığına da bağlıdır, değil mi? Ayrıca, bu sorguların toplanma yöntemine ve SQL'in hangi sürümüne bağlı olduğuna da bağlıdır. Örneğin, SQL Server 2005, genişletilmiş olaylardan çekemeyeceğiz, oysa bunu yapmak için bir izden çekeceğiz. Bu nedenle, bu verileri toplamayla ilgili olarak biraz farklı olurdu, ama dediğim gibi, bu ürünle ilgili 2004'ten beri tahminimce etrafta olduğumuzu söyledi. Uzun zaman oldu, binlerce müşterimiz var, bu yüzden yapmak istediğimiz son şey performans sorunlarına neden olan bir performans izleme aracına sahip olmak (gülüyor). Ve bundan mümkün olduğunca uzaklaşmaya çalışıyoruz, ancak genel olarak konuşursak, yaklaşık yüzde 1-3 gibi iyi bir kural.
Rick Sherman: Tamam, bu oldukça düşük, bu yüzden müthiş.
Eric Kavanagh: Güzel. Robin, senden soru var mı?
Robin Bloor: Üzgünüm, sessizdim. Birden fazla veritabanı yeteneğiniz var ve ben neden birden çok veritabanına bakabileceğinizle ilgileniyorum ve bu nedenle daha büyük bir kaynak tabanının muhtemelen çeşitli sanal makineler arasında bölünmüş olduğunu vb. İnsanların bunu nasıl kullandıklarıyla ilgileniyorum. Müşterilerin bununla ne yaptığını merak ediyorum. Çünkü bu bana bakıyor, kesinlikle, veritabanlarıyla uğraştığımda, hiç elimde olmayan bir şey. Ve herhangi bir zamanda sadece bir örneği anlamlı bir şekilde düşünürdüm. Peki insanlar bunu nasıl kullanıyor?
Bullett Manale: Genel olarak, genel olarak sadece aracın kendisinden mi bahsediyorsunuz? Nasıl kullanıyorlar? Yani, genel olarak, çevrenin merkezi bir mevcudiyet noktasına sahip olmakla ilgilidir. İçinizin rahat olması ve bir ekrana bakıp yeşil görmeleri durumunda her şeyin iyi olduğunu bildiklerini bilmek. Sorunlar ortaya çıktığında ve vakaların çoğunun bir DBA perspektifinden olduğu zaman, çoğu zaman bu sorunlar konsolun önündeyken meydana gelir, bu nedenle sorun olur olmaz bildirilebilir. Ancak buna ek olarak, sorunun ne zaman meydana geldiğini anlayabilme, onlara neden gerçekleştiği konusunda bir bağlam sağlayan bilginin kalbine ulaşabilme. Ve bence, en büyük kısmı: bu konuda proaktif olmak, reaktif olmamak.
Konuştuğum DBA'ların çoğu - ve bilmiyorum, bunların iyi bir yüzdesi - maalesef hala reaktif bir ortam içindedir; tüketicilerin bir sorun olduğunu söylemek için onlara yaklaşmasını beklerler. Ve böylece, bundan kaçmaya çalışan birçok insan görüyoruz ve bence bu araç gibi insanların proaktif olmalarına yardımcı olmasının nedeninin büyük bir kısmı, ama aynı zamanda neler olup bittiğine dair içgörü sağlıyor, sorun nedir, ancak birçok durumda, en azından bulduğumuz şey - ve belki de sadece bunu söyleyen DBA'lar - ama DBA'lar, algıyı her zaman onların sorunu, uygulamayı yazan uygulama geliştiricisi olsa bile düzgün yazmamış olanlar, suçu üstlenecek olanlar onlar, çünkü bu uygulamayı sistemlerine veya sunucularına alıyorlar ve sonra performans kötü olduğunda, DBA'ya işaret ediyor, “Hey, bu senin hatan.”
Yani bu araç, birçok kez, DBA'nın “Hey, sorun burada yatıyor ve ben değilim” demesi için yardım etmek için kullanılacak. (Gülüyor) sorguları değiştiriyor olsun veya olmasın, bunu geliştirin. Bazı durumlarda sorumlulukları açısından kovalarına düşecektir, ancak en azından bunu anlamalarına ve bilmelerine yardımcı olacak araçlara sahip olmak ve bunu zamanında yapmak açık bir şekilde ideal bir yaklaşımdır.
Robin Bloor: Evet, aşina olduğum sitelerin çoğu, ama orada bulunduğumdan beri, çeşitli çoklu veritabanı sitelerine baktığımda bir süredir oldu, ama çoğunlukla bulduğum şey Bir avuç veri tabanına odaklanan DBA'lar. Ve bunlar veritabanları olurdu, eğer onlar aşağı inerse, iş için gerçekten büyük bir sorun olurdu, vb. Diğerleri ise, ara sıra istatistiklerini toplayacaklar ve yer kalmadıklarını görmek için onlara hiç bakmayacaklar. Ve demoyu yaparken buna bakıyordum ve iyi düşünüyordum, şu ya da bu şekilde, sadece, genellikle veritabanları için böyle bir şey sağlayarak, hiç kimse hakkında çok fazla umursamadı, çünkü veri büyümesi var, zaman zaman uygulama büyümesi de oluyor. DBA kapsamını oldukça dramatik bir şekilde genişletiyorsunuz. Yani asıl soru bu, bunun gibi bir dizi araçla, şirket ağındaki her veritabanına hemen hemen bir DBA hizmeti verebilmeniz mi?
Bullett Manale: Demek istediğim, zorluk şu ki, oldukça etkili bir şekilde söylediğin gibi, DBA'ların önemsediği bazı veritabanları var ve sonra o kadar umursamayanlar var. Ve bu belirli ürünün lisanslanma şekli, örnek başınadır. Yani, sanırım, insanlar “Hey, bu aracı ile yönetmek istediğim kadar kritik bir örnek değil” dediğinde bir eşik var. Yani, yaptığımız başka araçlar da var daha fazla var sanırım, SQL daha az önemli örnekleri için yiyecek ve içecek. Bunlardan biri, örneklere karşı hafif sağlık kontrolleri yaptığımız Envanter Yöneticisi gibi olacaktır, ancak yaptığımızın yanı sıra keşif yapmaktır, bu nedenle çevrimiçi hale getirilen yeni örnekleri tanımlarız ve bu noktadan sonra, DBA diyebilirim ki, “Tamam, işte SQL'in yeni bir örneği, şimdi Express mi? Ücretsiz sürüm mü yoksa kurumsal sürüm mü? ”Bu muhtemelen kendime sormak istediğim bir soru, ancak ikincisi, bu örnek benim için ne kadar önemli? Bu kadar önemli değilse, bu aracın dışarı çıkmasını ve genel jenerik sağlık kontrolleri diyebileceğim genel bir kontrol olduğunu söyleyebilirim, DBA olarak önem verdiğim temel şey türleri oldukları için: Sürücü dolduruyor mu? ? Sunucu sorunlara cevap veriyor mu? Ana şeyler, değil mi?
Teşhis Yöneticisi ile sadece size gösterdiğim araç, sorgu seviyesine inecek, indekslerin önerisine girecek, yürütme planına ve tüm bu iyi şeylere bakacak. kim neye sahip, neye sahibim ve bundan kim sorumlu? Hangi servis paketleri ve düzeltmelerim var? Ve sunucularımın SQL'in sağlıklı bir örneği olduğunu düşündüğüm ana içeriklerle çalışıyor mu? Sorunuzu cevaplamak için biraz karışık var. Bu araca bakan insanlara sahip olduğumuzda, genellikle daha kritik örneklere bakarlar. Bununla birlikte, sahip oldukları her örneği satın alan ve yöneten bazı milletlere sahibiz, bu yüzden sadece bağlıdır. Ama size, genel olarak, çevrelerinin bu örnekleri yönetmek için böyle bir araca sahip olacak kadar önemli olduğunu düşünen kesinlikle bir eşik olduğunu söylüyorum.
Robin Bloor: Tamam, Eric'e teslim etmeden önce başka bir soru. Sadece endüstriyi izlemekten edindiği izlenim, veritabanlarının hala bir yaşamı olduğu, ancak tüm verilerin tüm bu veri göllerine ve benzeri şeylere dökülmesidir. Bu hype, gerçekten ve hype asla gerçeği yansıtmıyor, bu yüzden orada ne tür bir gerçeklik algıladığınızı merak ediyorum? Bir kuruluş içindeki önemli veritabanları, yılda yüzde 10 olarak düşündüğüm geleneksel veri büyümesini yaşıyorlar mı? Yoksa bundan daha mı büyüyorlar? Büyük veri bu veritabanlarını balon yapıyor mu? Gördüğün resim nedir?
Bullett Manale: Bence pek çok vaka, mevcut olan başka teknolojiler olduğunda, verilerin daha anlamlı olduğu diğer bölümlere taşındığını görüyoruz. Son zamanlarda, bazı büyük veri şeyler. Ama bu veritabanları, bir çok durumda genelleme yapmak zor çünkü herkes biraz farklı. Genel olarak konuşursak, biraz sapma görüyorum. Gördüğüm gibi, dediğim gibi, insanlar birçok durumda elastik modellere yöneliyorlar, çünkü kaynakları başka alanlarda çok değil, büyümek istiyorlar. Bazı insanlar büyük verilere taşınıyor. Ama algılamak için bir fikir edinmek zor, çünkü genel olarak konuştuğum insanlar geleneksel veritabanlarına sahip ve bunu bir SQL Server ortamında kullanıyorsunuz.
Bununla birlikte, SQL'in kendisi açısından söyleyebilirim, kesinlikle pazar payı kazandığını düşünüyorum. Ve Oracle gibi diğer yerlerden hala SQL'e doğru giden birçok insan olduğunu düşünüyorum, çünkü daha uygun fiyatlı ve SQL sürümleri daha gelişmiş hale geldikçe açıkça görülüyor - ve bunu daha yeni şeylerle görüyorsunuz. SQL ile devam ediyor, şifreleme açısından ve onu bir ortam ya da bir veritabanı platformu yapan diğer tüm yetenekler - sanırım çok kritik bir görev. Sanırım bunu da görüyoruz. Bir vardiya gördüğünüz yerde, hala oluyor. Yani, 10 yıl önce gerçekleşiyordu, bence, çevrenin ve pazar payının arttığı SQL Server açısından oluyor.
Robin Bloor: Tamam, Eric, seyircinin bir iki sorusu olduğunu sanıyorum?
Eric Kavanagh: Evet, sana hızlıca bir tane atayım. Aslında oldukça iyi bir soru. Katılımcılardan biri soruyor, bu araç bana bir tablonun sorguyu hızlandırmak için bir dizine ihtiyacı olup olmadığını söyleyecek mi? Öyleyse, bir örnek gösterebilir misiniz?
Bullett Manale: Evet, bu yüzden özellikle bir indeks eklemek için bir tane var mı bilmiyorum, ama burada görebilirsiniz, burada parçalanma önerileri var. Ayrıca sadece sahip olduğumuza inanıyorum ve bu, web tabanlı sürümü sunan Tanı Yöneticisi'nin bir parçasıydı, burada bana eksik bir dizinim olduğunu söylüyor. Ve bu önerileri görebiliriz ve bu bilgiyi endeksleyerek bize bunun potansiyel kazanımını söyler. Sadece bahsetmemiz gereken diğer bir şey, önerileri yaptığımızda, bunların çoğu için, senaryo bunun için oluşturulacak. Bu iyi bir örnek değil, ancak evet, bir dizinin - yinelenen bir dizin veya bir dizin eklenmesi - performansı artırabileceği durumları görebileceksiniz ve daha önce de söylediğim gibi, varsayımsal indeks analizi ile. Bu nedenle, iş yükünü anlamak, bunu tavsiyeye uygulamak açısından gerçekten yardımcı olur.
Eric Kavanagh: Bu harika şeyler, bu da bana buradaki son yorumlara iyi bir selam verecek. Robin ve ben ve Rick de uzun yıllardır duyduk, kendi kendini ayarlayan veritabanları hakkında konuştuk. Kendi kendini ayarlayan bir veritabanı! Size söyleyebileceğim tek şey: Onlara inanmayın.
Bullett Manale: Hype'a inanma.
Eric Kavanagh: Dinamik olarak yapılan küçük küçük şeyler olabilir, ancak bu bile, kontrol etmek ve yapmasını istemediğiniz bir şey yapmadığından emin olmak isteyebilirsiniz. Bu nedenle, bir süre için, veritabanı düzeyinde neler olduğunu anlamak için böyle araçlara ihtiyacımız olacak ve Robin'in dediği gibi, veri gölleri büyüleyici kavramlar, ancak muhtemelen bunların olduğu gibi devralma şansı var yakında Loch Ness Canavarı olmak. Yani, tekrar söyleyebilirim ki, gerçek dünyada çok fazla veritabanı teknolojisi var, bu şeylere bakmak ve sentezlemek için insanlara, DBA'lara ihtiyacımız var. Anlatabilirsin, bu işlerin çalışması için ne yaptığını bilmen gerek. Ama ne yaptığınızı bilmek için size bilgi verecek araçlara ihtiyacınız var. Sonuç olarak, DBA'lar gayet iyi gidiyor olacak.
Ve IDERA'daki Bullett Manale ve dostlarımıza çok teşekkürler. Ve elbette, Rick Sherman ve Robin Bloor. Tüm bu web yayınlarını arşivliyoruz, bu yüzden tüm daha fazla bilgi için online insideanalysis.com veya ortak sitemiz www.techopedia.com'a atlayın.
Ve bununla, sana veda edeceğiz millet. Tekrar teşekkürler, bir dahaki sefere seninle konuşacağız. Kendine iyi bak. Güle güle.
