Paket servisi: Ev sahibi Eric Kavanagh, Dr. Robin Bloor, Rick Sherman ve IDERAs Bullett Manale ile yapılan tahminleri tartışıyor.
Videoyu izleyebilmek için bu etkinliğe kaydolmalısınız. Videoyu görmek için kayıt olun.
Eric Kavanagh: Bayanlar ve baylar, bir kez daha merhaba ve Hot Technologies web yayını dizisine tekrar hoş geldiniz! Benim adım Eric Kavanagh, Bugünün web seminerinde, “En Uygun Hava Tahminleriyle Zaman, Para ve Sorun Tasarrufu” konulu evsahibiniz olacağım. Bu şovda bu konuda. Bu yüzden, tabii ki Sıcak Teknolojiler, bugün dünyanın bazı harika ürünlerinin neler olduğunu, işletme teknolojisinin dünyasını, insanların ne yaptığını, nasıl çalıştıklarını, bu kadar eğlenceli şeyleri anlama konusundaki forumumuzdur.
Ve bugünkü konu, önerdiğim gibi, öngörme ile ilgilidir. Gerçekten de, organizasyonunuzda neler olacağını anlamaya çalışıyorsunuz. Ne yaparsanız yapın, kullanıcılarınızı nasıl mutlu edeceksiniz? Eğer analiz yapıyorlarsa, gerçek iş yapıyorlarsa, gerçek müşterilere işlem sistemleriyle karşı karşıya kalırlar, durum ne olursa olsun, sistemlerinizin nasıl çalıştığını ve neler olup bittiğini ve bugün ne hakkında konuştuğunu anlamak istersiniz. Bu komik bir şey çünkü tahmin yapmak sevdiğim bir şey değil, batıl inancım var, sanırım çok fazla tahmin edersem, kötü şeyler olacak, ama bu sadece benim. Benim ipucumu takip etme.
İşte bugün günümüz sunucularımız, sol üst köşede sizinkiniz, Rick Sherman Boston'dan arıyor, IDERA'dan dostumuz Bullett Manale ve kendi Dr. Robin Bloor. Ve bununla, onu Robin'e vereceğim ve sadece insanlara hatırlatıyor: Sorular sor, utangaç olmayın, iyi soruları seviyoruz, bugün bunları bugünkülere ve diğerlerine verelim. Ve bununla Robin, al onu.
Robin Bloor: Tamam, peki, söylediğim gibi ben direk pozisyonunda olduğum gibi, bugün bir SQL öyküsü anlatacağımı düşündüm, çünkü tartışmaya devam edecek olanın geçmişi ve kaçınılmaz olarak çarpışmayacak çünkü Rick buna odaklanmıyor. ve Rick'in söyledikleriyle çatışmayacak. Yani, SQL hikayesi, SQL hakkında bazı ilginç şeyler var çünkü çok baskın. Bakın, bu bir yazım hatası, SQL bir bildirim dilidir. Buradaki fikir, istediğinizi isteyebileceğiniz bir dil yaratabiliyor olmanızdı. Ve veritabanı onu nasıl elde edeceğini hesaplardı. Ve aslında oldukça iyi sonuç verdi, ancak BT endüstrisinin tamamını bir bildirimsel dile dayandırmanın sonuçları hakkında söylenmeye değer bazı şeyler var. Kullanıcı verinin fiziksel organizasyonunu bilmiyor veya umursamıyor ve bu da bildirim dili hakkında iyi bir şey - sizi tüm bunlardan ayırıyor ve hatta endişe duyuyor - sadece ne istersen ve veritabanını sor gidip onu alacağım.
Ancak kullanıcının, SQL sorgusunu yapılandırma biçiminin, sorgunun performansını etkileyip etkilemediği ve bunun bir dezavantajı olup olmadığı hakkında hiçbir fikri yoktur. Yüzlerce ve yüzlerce satır uzunluğunda, sadece bir SQL isteği olan, "select" ile başlayan ve sadece alt sorgularla devam eden sorgular gördüm. Ve aslında bir veritabanından belirli bir veri toplanmasını istiyorsanız, SQL ile farklı şekillerde isteyip istemediğinizi ve verilere biraz aşina olmanız durumunda aynı cevabı alabilirsiniz. Bu nedenle, bir SQL sorgusu mutlaka veri istemek için en iyi yol değildir ve veritabanları, içine koyduğunuz SQL'e göre oldukça farklı yanıtlar verecektir.
Ve böylece, SQL aslında performansı etkiliyor, bu yüzden SQL kullanan insanlar, bu onlar için geçerli, aynı zamanda SQL kullanan SQL programcıları için de geçerli ve odaklandıkları için etkileri hakkında düşünmeleri daha az muhtemel. aslında veri manipülasyonu üzerinedir, veri toplama, elde etme üzerine değildir. Aynı şey, BI araçları için de geçerlidir. İsterseniz, çeşitli veritabanlarının BI araçlarını sıkıştıran SQL'i gördüm ve şunu söylemeliyim ki, bunun çoğu, SQL sorguları yazmayacağım. bunun gibi. Biri, eğer istersen, parametreler ne olursa olsun, biraz SQL fırlatacağı ve yine de, SQL'in mutlaka verimli SQL olmayacağına dair küçük bir motor yarattı.
Daha sonra Id'nin empedans uyumsuzluğundan bahsettiğini düşündüm, programcıların kullandıkları veriler, sıralamadaki verilerden farklı. Dolayısıyla, DMS verilerimizi tablolarda depolar, nesneye yönelik kod çoğunlukla kodlayıcılar düzenlenir, günümüzde nesne yönelimli form programlama ve nesne yapılarında veri sipariş eder, bu nedenle birbiri ile eşleşmez. Dolayısıyla, programcının verileri ne düşündüğünden, veritabanının verilerin ne olduğunu düşündüğünden çevirme zorunluluğu vardır. Durum böyle olması için yanlış bir şey yapmış olmalıyız. SQL veri tanımı için DDL'ye sahiptir, DML - veri işleme dili - bu veriyi almak için seçin, projelendirin ve katılın. Şimdi, çok az matematik ve çok az zamana dayalı şeyler var, bu yüzden kusurlu dili, söylenmesi gerekmesine rağmen genişlemesi ve genişlemesi devam ediyor.
Ve sonra, her zaman diyagramdan daha sert olan SQL bariyer sorununu yaşarsınız, bununla birlikte birçok insan analitik nedenlerle sorular soruyorlardı, soru veri terimlerinin cevabını aldıktan sonra başka bir soru sormak istiyorlardı. Böylece, diyalog için bir şey olur, SQL diyaloglar için tasarlanmadı, aynı anda ne istediğinizi sormak için yapıldı. Ve bunu bilmeye değer, çünkü kullanıcı ve veriler arasında konuşmayı mümkün kılmak için SQL'den vazgeçen bazı ürünler var.
Veri tabanı performansı açısından - ve bu tür her şeye yayılır - evet, CPU, hafızası, diski var, ağın genel giderleri ve veriyi belirli bir zamanda özel olarak kullanmak isteyen birden fazla kişinin kilitleme sorunu var. zamanında gelin. Ancak zayıf SQL çağrıları da var; performans açısından SQL'i gerçekten optimize ederseniz yapılabilecek çok şey var. Dolayısıyla veritabanı performans faktörleri: Kötü tasarım, kötü program tasarımı, eksik iş yükü eşzamanlılığı, yük dengeleme, sorgu yapısı, kapasite planlaması. Bu veri artışı. Ve birkaç kelimeyle, SQL uygun, ancak kendi kendini optimize etmiyor.
Bunu söyledikten sonra, Rick'e geçebileceğimizi düşünüyorum.
Eric Kavanagh: Pekala Rick, sana WebEx arabanın anahtarlarını vereyim. Al onu.
Rick Sherman: Tamam, harika. Teşekkürler Robin, sunumun başlangıcında başladığımız gibi, grafiklerim hala oldukça sıkıcı ama devam et. Bu yüzden, Robin'in SQL tarafında konuştuğu her şeye katılıyorum. Ama şimdi biraz konsantre olmak istediğim, çok hızlı bir şekilde giden veri talebi, o alanda kullanılan araçlardaki tedarik veya o alandaki araçlara olan ihtiyaç.
Öncelikle, okuduğunuz her makalede bazıları büyük veriler, birçok veri, buluttan gelen yapılandırılmamış veriler, hayal edebileceğiniz her yerdeki büyük verilerle ilgili. Ancak veritabanı pazarının büyümesi sürekli olarak SQL ile olmuştur, muhtemelen 2015'ten itibaren ilişkisel veritabanı hala veritabanı pazarının yüzde 95'i kadardır. İlk üç ilişkisel satıcı o alandaki pazar payının yüzde 88'ine sahiptir. Öyleyse, Robin konuştuğu gibi SQL hakkında hala konuşuyorduk. Ve aslında, Hadoop platformuna bakmış olsa bile, bir veri bilimcisi olan oğlumun her zaman kullandığı Hive ve Spark SQL, kesinlikle insanların veri elde etmelerindeki en baskın yoldur.
Şimdi, veritabanı tarafında, iki geniş veri tabanı kullanım kategorisi vardır. Bunlardan biri operasyonel veritabanı yönetim sistemleri, yani kurumsal ilişki planlaması, müşteri ilişkileri yönetimi, yani Salesforce ERP'ler, Oracles, EPIC'ler, N4'ler, vb. Ve, veri ambarlarında ve diğer iş zekası tabanlı sistemlerde geniş bir miktarda ve genişleyen veri miktarı var. Her şeyin sebebi, nerede ve nasıl yakalandığına, depolandığına veya işlem yapıldığına bakılmaksızın sonuçta analiz edilir ve böylece veritabanlarının, özellikle de piyasadaki ilişkisel veritabanlarının kullanımında büyük bir talep ve artışa neden olur.
Şimdi, talep geldi, büyük miktarda veri geliyor. Ve ben gerçekten büyük verilerden bahsetmiyorum, her türlü işletme genelinde verilerin kullanımı hakkında konuşuyorum. Ancak, arz tarafından eşlik ederek, bu kaynakları yönetebilen insanlar için, önce biz varız, bir tür DBA kıtlığımız var. Çalışma İstatistikleri Bürosu’na göre, 2014-2024’den itibaren DBA’nın işleri sadece yüzde 11 oranında artacak - şimdi DBA’nın iş unvanı olan insanlar, ancak bunun hakkında ikinci bir saniyede - yüzde 40’a karşılık yıllık veri büyüme alanı. Ve bir sürü DBA'mız var; Ortalama olarak aynı çalışma hakkında konuşulan aynı çalışmada diğer BT mesleklerine göre oldukça yüksektir. Ve sonra alandan ayrılan, zorunlu olarak emekli olmayan, ancak başka yönlere, yönetime giren veya her neyse kaybolan birçok insan var.
Şimdi, ayrılma sebeplerinin bir kısmı, DBA işinin gittikçe daha da zorlaşmasından kaynaklanıyor. Öncelikle, birçok farklı veritabanını kendileri yöneten DBA'larımız, fiziksel veritabanları, her yerdeki farklı veritabanları gibi. Şimdi bu ilişkisel olabilir veya başka veritabanları da olabilir, bunlar da veritabanı türleri. Ancak ilişkisel olsa bile, aslında yönetmeye çalıştıkları bir, iki, üç, dört farklı satıcıdan birine sahip olabilirler. DBA'lar genellikle veritabanının veya uygulamanın tasarımından sonra dahil olurlar. Robin, veritabanlarının veya uygulamaların nasıl tasarlandığını, SQL'in nasıl tasarlandığını anlattı. Eh, veri modellemesinden, ER modellemesinden, genişletilmiş ER modellemesinden, boyut modellemesinden, gelişmiş boyut modellemesinden bahsederken, tipik olarak uygulama programcıları ve uygulama geliştiricileri, amaçlarını dikkate alarak tasarlarlar - veri tabanı yapısının verimliliğini tasarlamazlar. . Bu yüzden çok zayıf tasarımımız var.
Şimdi ticari işletme uygulama satıcılarından bahsetmiyorum; genellikle ER modelleri veya genişletilmiş ER modelleri var. Bahsettiğim şey, her şirkette uygulama geliştiricileri tarafından oluşturulan çok daha fazla iş süreci ve uygulaması - bunlar dağıtımın etkinliği veya etkinliği için mutlaka tasarlanmamış olanlardır. Ve DBA'ların kendileri çok çalışıyor ve bazen 7/24 sorumluluk alıyorlar, gittikçe daha fazla veritabanı alıyorlar. Bence, insanlar ne yaptığını ya da nasıl yaptıklarını tam olarak anlamadılar. Kendi küçük grupları ve insanları sadece “Tüm bu araçları kullanmak çok kolay, sadece iş yüklerinde daha fazla veritabanına atmaya devam edebiliriz” diye düşünmeye devam ediyorlar.
Bu bizi yarı zamanlı ve yanlışlıkla DBA'lara götürür. Küçük olan BT ekiplerimiz var ve mutlaka özel bir DBA alamazlar. Şimdi, veritabanı ve veritabanı uygulamalarının genişlemesinin son on yılda patladığı ve genişlemeye devam ettiği küçük ila orta ölçekli işletmeler için geçerli. Fakat aynı zamanda büyük şirketler söz konusu olduğunda, genellikle uzun zamandan beri veri depolama, iş zekası analizleri yapıyorlar. Uzun zaman önce, bu projeler için özel DBA'lar alıyorduk; Artık hiçbir zaman özel bir DBA alamıyoruz. Veritabanının tasarlanmasından sorumluydu, bu iyi, eğer deneyimi olan biri ise.Ancak, genel olarak, DBA'lar uygulama geliştiricileridir, bu rolü genellikle işlerinin yarı zamanlı bir parçası olarak görürler, içinde resmi bir eğitime sahip değillerdir ve tekrar hedefleri için tasarlarlar, verimlilik için tasarlamazlar.
Ve tasarım ve geliştirme, dağıtım ve yönetime karşı çok fazla fark var. Bu yüzden, projelerde ihtiyaç duyulan becerileri ve kaynakları elde etmeyi atlayan küçük bir kumbaralı “kuruş bilge, palavra aptal” var. Herkesin “İneklerin İntikamı” ndan geldiğini düşünmek, benim küçük resmim. Şimdi, insanların ihtiyaç duyduğu kadarıyla, SQL'de veritabanlarının ve verilerin genişleyen kullanımına sahibiz. Çok sayıda DBA'yı sınırlandırdık - bu ayar ve tasarım, yönetim ve dağıtım durumlarında yetenekli ve uzman insanlar. Ve biçimsel eğitime sahip olmayan insanlara yarı zamanlı veya kazayla DBA'lar gittikçe artıyor.
Öyleyse, bu veritabanlarının da ayarlanmadığı veya yönetilmediği gerçeğiyle ilgili olarak ortaya çıkan bazı şeyler nelerdir? Öncelikle, birçok kişi veritabanı sisteminin kendilerinin kendilerini yönetmek için yeterli araçlara sahip olduğunu varsaymaktadır. Ş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 planlaması, izleme vb. Böylece, ilk olarak, insanlar ihtiyaç duydukları tüm araçlara sahip olduklarını varsayıyorlar. İkincisi, yarı zamanlı veya kazara DBA iseniz, ne bilmediğinizi bilmiyorsunuz.
Sanırım oradaki ifadelerin bir kısmını unuttum, bu yüzden çoğu zaman sadece tasarımda veya veritabanlarını yönetirken veya çalıştırırken neye bakmaları gerektiğini bile anlamadılar. Eğer bu senin mesleğin değilse, o zaman ne yapman gerektiğini anlamayacaksın. Üçüncüsü, SQL bir go-to-to aracı olduğu için Robin, SQL hakkında konuştu ve ne kadar zayıf SQL'nin bazen yapıldığı veya sıklıkla yapıldığı hakkında konuştu. Ayrıca evcil hayvanlarımdan biri, BI veri depolama, veri taşıma, veri mühendisliği alanlarındaki görevlilerden biri, araçları kullanmak yerine, insanların pahalı bir veri entegrasyon aracı veya pahalı olsalar bile, SQL kodu, saklı yordamlar yazma eğiliminde olmalarıdır. BI aracı, genellikle sadece saklı yordamları çalıştırmak için kullanırlar. Böylece veritabanı tasarımını, SQL'in yapısını anlamanın önemi gittikçe daha fazla önem kazanıyor.
Ve nihayet, bireysel insanların bireysel veritabanlarına baktıkları bu silo yaklaşımı var. Uygulamaların nasıl çalıştığını ve birbirleriyle nasıl etkileşimde bulunduklarına bakmıyorlar. Ve ayrıca sıklıkla kullandıkları uygulamalara karşı veritabanlarına bakıyorlar. Bu yüzden, veritabanında elde ettiğiniz iş yükü tasarımda kritiktir, ayarlamada kritiktir, kapasite planlamasını vb. Anlamaya çalışmak için kritiktir. Dolayısıyla, ormandan ağaçlara bakarken insanlar yabani otların içindedir. , bireysel tablolara ve veritabanlarına bakmak ve bu uygulamaların iş yükündeki genel etkileşimine bakmamak.
Son olarak, insanların bakmaları gereken kilit alanlara bakması gerekir. Veritabanlarını yönetmeyi planladıklarında ilk önce bazı uygulama merkezli performans ölçütleri hakkında düşünmeleri, sadece bu tablonun nasıl yapılandırıldığına değil, özellikle nasıl modellendiğine bakmaları gerekir. Bu nedenle, tedarik zinciri yönetimi nedeniyle kurumsal bir uygulamanız varsa, internetten sipariş alıyorsanız, iş zekası yapıyorsanız - ne yapıyorsanız - kimlerin kullandığına, bunların nasıl kullanıldığına, verilerin ne kadar olduğuna bakmanız gerekir. , ne zaman olacak. Gerçekten aramaya çalıştığınız şey, bekleme süreleridir, çünkü ne olursa olsun, tüm uygulamalar bir şeyin ne kadar sürdüğüne, bir kişi veya yalnızca uygulamalar veya işlemciler arasındaki verilerin değiş tokuşuna bakılarak değerlendirilir. Ve tıkanıklıklar nelerdir? Sık sık, sorunların hatalarını gidermeye çalıştığınızda, elbette, gerçekten gerçek darboğazların neler olduğuna bakmaya çalışıyorsunuz - zorunlu olarak her şeyi nasıl ayarlayacağınız değil, bekleme süreleri ve iş hacmindeki performanstan nasıl kurtulur ve yükseltebilirsiniz? Bakman gerek.
Ve veri yakalamayı, işlemleri, veri tabanındaki dönüşümleri ve analizleri ayırmanız gerekiyor. Bunların her biri farklı tasarım modellerine sahip, her biri farklı kullanım modellerine sahip ve her birinin farklı ayarlanması gerekiyor. Bu nedenle, bu verilerin nasıl kullanıldığını, ne zaman kullanıldığını, ne için kullanıldığını düşünmeniz ve performans ölçümlerinin 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; Her iki veri yapısına da bakmak istersiniz, bu nedenle veritabanının indeksleri, bölümlenmesi ve diğer fiziksel yönleri, hatta veritabanının yapısı bile - ER modeli veya boyutsal modeli olsa da, yapılandırılmış olmasına rağmen - bütün bunların performans üzerinde etkisi vardır. , özellikle de farklı veri eksilerini yakalama analitiği ve gerçekleşen dönüşümler.
Ve Robin’in SQL tarafında bahsettiği gibi, bu farklı uygulamaların bu veritabanlarında çalıştırdığı SQL’e bakmak ve bunu ayarlamak çok önemlidir. Ve genel uygulama iş yüklerine ve bu veritabanlarının ve uygulamalarının üzerinde çalıştığı altyapı ortamına bakmak. Böylece, ağlar, sunucular, bulut - neyin üzerinde çalışıyorlarsa olsunlar - bu uygulamaların ve bu veritabanlarının bu bağlamda sahip olduğu etkiye bakarak, bunların hepsinin veritabanını ayarlayabilmesi etkileşimi var.
Ve son olarak, araçlara baktığınızda, bununla ilgili üç farklı analitik türüne bakabilmek istersiniz. Tanımlayıcı analizlere bakmak istersiniz: veritabanı ve uygulama performansı ile ilgili neler olup bittiğini. Sadece neler olduğunu değil aynı zamanda neden olduğunu, darboğazların nerede olduğunu, problemlerin nerede olduğunu, neyin iyi gittiğini, neyin iyi çalışmadığını anlamak için tanısal analitik yapma yeteneğine sahip olmak istiyorsunuz. Ancak, tasarım ya da yapmanız gerekenler için bunları ele almak için problemli alanları analiz edip inceleyebilirsiniz.
Ve son olarak, en agresif ya da proaktif analiz türü, gerçekte, 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 iş çıkarırsak, ne yapıyorsa, veritabanını neyin, nasıl ve nerede etkileyeceğini tahmin edebilmek, Uygulamalar, proaktif bir şekilde planlama ve planlama yapmamıza, darboğazların nerede olduğunu, bekleme sürelerinin nerede acı çekebileceğini ve işleri düzeltmek için ne yapmamız gerektiğini çözmemize olanak sağlar. Bu yüzden, performans ölçümlerini uygulayabilecek, bu üç tür analizde olduğu gibi performansı izleyebilecek araçlara sahip olmak istiyoruz. Ve bu benim genel bakışım.
Eric Kavanagh: Pekala, bırakmama izin ver - bu iki harika sunum, bu arada - oradan çıkarmak için bunu Bullett Manale'e vermeme izin ver. Ve millet, iyi sorular sormayı unutmayın; zaten iyi içeriğe sahibiz. Al onu, Bullett.
Bullett Manale: Kulağa iyi geliyor. Sağol Eric. Bu yüzden, Rick ve Robin’in söylediklerinin çoğu, yüzde 100’le aynı fikirdeyim. Bu slaydı yukarı çektiğimi söylerdim, çünkü uydurma olduğunu düşünüyorum, 80'lerde “A Takımı” hayranları olan sizler için bilmiyorum, John Hannibal Smith her zaman “hep sevdiğimi söylerdi” demiş. bir plan bir araya geldiğinde, ”ve sanırım özellikle odaklandığınız yer olan SQL Server hakkında konuşurken, bugün konuşacak olan ürün olan SQL Diagnostic Manager, kesinlikle bu şeylerden biri. sahip olmalısın; sahip olduğunuz verileri kaldırabilmeniz ve bu verilerden karar alabilmeniz ve bazı durumlarda bir karar aramamanız; kaynakların tükeneceği zaman, kaynakların tükeneceği zaman, bir darboğazınız olduğunda, bu tür şeyleri söyleyeceğiniz bir şey arayacaksınız.
Sadece belirli bir ölçümü izlemekten ibaret değil. Bu nedenle, Diagnostic Manager ile, çok iyi yaptığı şeylerden biri, iş yüklerine özgü tahmin ve iş anlayışı konusunda size yardımcı olacak ve bugün bunun hakkında konuşacaklar. Bu araç veri yöneticisi, DBA veya oyunculuk DBA'sı için tasarlandı, bu yüzden Rick'in bahsettiği şeylerin çoğu, oyunculuk DBA'sı çok doğru. Bir çok durumda, eğer bir DBA değilseniz, bir SQL ortamını yönetme zamanı geldiğinde, bilmediğiniz şeyler için sahip olacağınız birçok soru işareti olacaktır. Ve böylece size yardımcı olacak bir şey arıyorsanız, sizi bu süreçten geçirir ve ayrıca süreçte de eğitirsiniz. Ve bu yüzden, bu tür kararlar için kullandığınız aracın, bu kararların alınma nedenleri hakkında size bir fikir verecek olması, sadece size “Hey, şunu yap” demesi önemlidir.
Çünkü oyunculuk DBA'sı olduğumda, sonunda bu unvanı destekleyecek uzmanlık ve bilgi birikimine sahip tam gelişmiş DBA olabilirim. Demek ki, bir veritabanı yöneticisi olmaktan bahsederken - Ben her zaman ilk önce bu slaydı göstereceğim, çünkü DBA'nın bazı farklı rolleri var ve birlikte olduğunuz kuruma bağlı olarak, sahip olacaksınız, bunlar değişecek. bir yerden diğerine - ama genellikle, her zaman depolama alanınızdan, o depolama alanını planlamanız ve öngörme anlayışınızdan her zaman bir şekilde sorumlu olacaksınız, söylemeliyim ki, ne kadar alana ihtiyaç duyacağınız, yedekleriniz için mi, ya da veritabanları kendileri için. Bunu anlamanız ve değerlendirmeniz gerekecek.
Ek olarak, işleri ihtiyaç duyduğunuz şekilde anlayabilmeniz ve optimize edebilmeniz gerekecek ve ortamın izlenmesinden geçerken, ortam içinde değişen şeylere bağlı olarak ihtiyaç duyduğunuzda değişiklik yapmanız açık bir şekilde önemlidir. kendisi. Dolayısıyla, kullanıcı sayısı, uygulamaların popülaritesi, veritabanının mevsimsellik gibi şeyler, tahminlerinizi yaparken mutlaka göz önünde bulundurulmalıdır. Ve sonra, açıkçası, bu kararları vermekle ilgili olarak gerekli olan raporları ve bilgileri sağlayabilmek açısından başka şeylere bakmak. Bir çok durumda karşılaştırmalı analiz yapmak anlamına gelir; Özellikle belirli bir metriğe bakabilmek ve bu metriğin zaman içinde ne kadar değer taşıdığını anlamak, böylece ileriye doğru nereye gideceğini tahmin edebilmek demektir.
Peki, Diagnostic Manager aracının yaptığı bu yetenekler nelerdir ve insanlar her gün tahmini gibi şeyler yapabilmek için kullanırlar ve ben de kapasite planlamasının tanımını koydum. Ve oldukça geniş ve aslında oldukça belirsiz bir tanım, sadece bir kuruluşun ürünleri için değişen talepleri karşılamak için ihtiyaç duyduğu üretim kapasitesini belirleme süreci ve günün sonunda, gerçekte ne olduğu: Bir ya da başka yolunuz olduğuna dair bilgi alabilmek ve bu bilgileri almak ve veritabanlarınızın yaşam döngüsü boyunca ilerledikçe ilerlemenize yardımcı olacak kararlar almak. Ve böylece, insanların bunu yapması için gereken nedenler olan şeyler, her şeyden önce, çoğu durumda, para biriktirmek için açıktır. İşletmeler, belli ki, asıl amaç şu ki, para kazanmak ve para kazanmak. Ancak bununla birlikte süreçte, bu aynı zamanda kesinti sürenizin olmadığından emin olmanız anlamına gelir. Ve herhangi bir aksama süresinin oluşma ihtimalini azalttığınızdan emin olun, bu yüzden başlamasını bekleyin, başka bir deyişle, olmasını beklemeyin ve sonra buna tepki gösterin.
Genel olarak kullanıcılarınızın verimliliğini artırabilmenin yanı sıra, daha fazla iş yapabilmeniz için onları daha verimli kılmak, burada açıkça anahtardır, bu nedenle bunlar, DBA veya öngörme veya kapasiteye dahil olan bir kişi olarak ortaya çıkan şeylerdir. planlama, bu kararları alabilmek için bilgileri gözden geçirebilmelidir. Ve sonra, genel olarak, bu açıkça, yalnızca para açısından değil, aynı zamanda zaman ve diğer şeyler için kullanılabilecek kaynaklar açısından da muhtemelen atıkları ortadan kaldırmanıza yardımcı olacak. Böylece, bu atıkları elimine edebilmek, kendi israfına bağlı fırsat maliyetlerine sahip olmamak.
Öyleyse, bununla birlikte, bir DBA olan kişiye özgü olan ne tür sorular alıyoruz? Ne zaman alanım tükenecek? Bu çok büyük, sadece şu anda ne kadar alan tüketiyorum değil, trendlere ve geçmişe dayanarak ne zaman biteceğim? Gerçek SQL örnekleri ile aynı şey, veritabanları, hangi sunucuları birleştirebilirim? Bazı VM'leri koyacağım, hangi veritabanlarını birleştireceğim ve hangi SQL örneklerinde bulunmaları gerektiği konusunda ne mantıklı? Tüm bu tür soruların cevaplanabilmesi gerekir. Çünkü çoğu durumda, eğer bir DBAysanız ya da DBA'ysanız, bir zamanlar kariyerinizde konsolide edersiniz. Bir çok durumda sürekli olarak bunu yapacaksın. Bu yüzden, bu kararları hızlı bir şekilde verebilmelisiniz, söz konusu olduğunda tahmin oyunları oynamamanız gerekir.
Darboğazlardan ve bunların nerede olacağından bahsettik, bir kez daha, onların olmasını beklemek yerine bunu önceden tahmin edebilmek. Yani, açıkçası bütün bu şeyler hakkında konuşuyorduk, tarihsel verilere güveniyor olmanız anlamında mantıklı olmak, çoğu durumda, bu önerileri üretebilmek veya bazı durumlarda kararları kendiniz formüle edebilmek için mantıklı olmak. bu cevapları ile gelip. Ancak bana, menkul kıymet satan birisinin veya bunun gibi bir şey için 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 ve bu analizlerin yüzde 100 doğru olmayabileceği durumlara sahip olacaksınız. Ancak, geçmişte ve bilinen şeyler ile uğraşıyorsanız ve bu türden bir çok soru ile “eğer” i alıp yapabiliyorsanız, karşılaşacaksınız, çok değerli ve Tahmin oyununu oynamaktan çok daha fazlasını alırım.
Yani, bu tür sorular açıkça ortaya çıkacaklar, yani bu soruların çoğunu Diagnostic Manager ile nasıl başa çıkacağız, her şeyden önce tahmin yeteneklerimiz var, bunu veritabanında, masada da yapabiliyoruz. sürücü veya ses. Sadece “Hey, yer doluydu” diyebilmek için değil, bundan altı ay sonra, bundan iki yıl sonra, bundan beş yıl sonra, eğer bunun için bütçeliysem, bütçeye ne kadar yer ayıracağım? için? Bunlar, sormam gereken sorular, ve parmağımı havaya sokup tahmin etmek ve rüzgârın hangi yönde estiğini görmek için beklemek yerine, bunu yapmak için bazı yöntemler kullanabilmek zorunda kalacağım. Zaman zaman, maalesef, bu kararların çoğunun verilme şekli.
Buna ek olarak, yapabilmek - slaytım biraz kesilmiş gibi görünüyor - fakat öneriler şeklinde yardım sağlayabiliyor. Bu nedenle, size metriklerle dolu bir gösterge tablosu gösterip “Tamam, tüm metrikleri ve bunların nerelerde olduğunu” söyleyebilmek, ancak sonra ne yapabileceklerini veya bazı şeyleri anlayabilmek Bundan yola çıkarak başka bir sıçrama var. Bazı durumlarda, insanlar bu kararları alabilmeleri için DBA'nın rolü konusunda yeterince eğitimlidirler. Ve böylece araçta size yardımcı olacak bazı mekanizmalar var, bu da size birazdan gösterecektir. Ancak sadece tavsiyenin ne olduğunu gösterememek, aynı zamanda bu tavsiyenin neden yapıldığına dair bir içgörü sunabilmek ve bunun üzerine, bazı durumlarda, aslında otomatikleştiren bir komut dosyası bulabilmek Bu sorunun düzeltilmesi de idealdir.
Burada bir sonrakine geçmek, iyi olan, sadece normal olanın metrik seviyeye inen anlayışı. Neyin normal olduğunu bilmiyorsam, neyin normal olmadığını söyleyemem. Bu yüzden, anahtarın ölçülmesi için bir yolun olması ve sizin için birden çok alan türünü göz önünde bulundurmanız gerekir; örneğin - veya zaman dilimleri söylemeliyim - farklı sunucu grupları, bunu dinamik olarak yapabilmek Bir başka deyişle, gecenin ortasında, bakım penceremde, devam eden tüm bakımlara dayanarak CPU'mun yüzde 80'de çalışmasını bekliyorum. Bu yüzden, o kadar fazla etkinliğe sahip olmadığım zamanlarda, belki de günün ortasında, bu zaman dilimlerinde eşiklerimi daha yükseğe çıkarmak isteyebilirim.
Bunlar açıkça çevresel olacak bazı şeylerdir, ancak o çevreyi daha verimli bir şekilde yönetmenize yardımcı olmak ve yönetmeyi kolaylaştırmak için yönetilenlere uygulayabileceğiniz şeylerdir. Diğer alan açıkça, bu tür “eğer” sorularına cevap verebilecek raporları ve bilgileri genel olarak sunabiliyor. Ortamımda yeni bir değişiklik yaptıysam, bu etkinin ne olduğunu anlamak isterim, böylece aynı değişikliği ortamımdaki diğer örneklere veya diğer veritabanlarına da uygulayabilirim. Bu değişikliği bir miktar gönül rahatlığıyla yapabilmeyi ve bunun iyi bir değişim olacağını bilmesini sağlayacak bazı bilgiler veya bir cephaneye sahip olmak istiyorum. Dolayısıyla, karşılaştırmalı raporlama yapabilmek, SQL örneklerini sıralayabilmek, veritabanlarımı birbirlerine karşı sıralayabilmek, “En yüksek CPU tüketicim hangisi?” Diyebilmek, bekleyişler ve bunun gibi şeyler? Bu yüzden, bu bilgilerin birçoğu araçta da mevcut olacak.
Ve sonra, sonuncusu ama en az değil, sadece ne gibi bir durumla başa çıkabildiğini belirleyebilecek bir araca ihtiyacınız olan genel bir yetenek ve bu yüzden demek istediğim, eğer çok fazla büyük bir çevreye sahipseniz Bazı durumlarda, muhtemelen bir duruma göre bir DBA’nın izlemek istediği metrik olmayan metrikleri çekmeniz gereken durumlarla karşılaşacaksınız, o duruma bağlı olarak. Böylece, ek metrikler ekleyebilmek ve bu metrikleri kullanıma hazır bir şekilde kullanıyorsanız kullanacağınız biçim ve biçimde kullanabilmeniz için genişletilebilir, bir araca sahip olmak. Örneğin, metrik. Dolayısıyla, raporları çalıştırabilmek, alarm verebilmek, referans - her şey hakkında konuştuğumuz - aynı zamanda bu tahminde bulunmanın ve bunu yapmanın önemli bir parçasıdır, böylece yapmak için aradığınız cevapları alabilirsiniz. Bu kararlar, ilerlemeye devam ediyor.
Şimdi Diagnostic Manager'ın yaptığı gibi, 2000 ila 2016 örneklerine karşı veri toplayan bir hizmet grubu olan merkezi bir hizmetimiz var. Ve sonra yaptığımız şey, bu verileri alıp merkezi bir depoya koyduk ve o zaman bu verilerle ne yaptığımızın açıkçası daha fazla içgörü sağlayabilmek için çok şey yaptığımızdır. Şimdi, buna ek olarak - ve burada olmayan şeylerden biri - aynı zamanda, gecenin ortasında çalışan, tahmine dayalı analiz hizmetimiz olan ve bazı sayıların çırpılmasını sağlayan bir hizmetimiz var mı? ve bir DBA ya da oyunculuk DBA'sı olarak, bu tür tavsiyelerde bulunabilmeniz, bazlar hakkında bazı bilgiler verebilmeniz için size yardımcı olur.
Yani, Id'nin yapmayı sevdiği şey ve bu mimarinin sadece hızlı bir örneği, buradaki büyük paket servisi aslında yönettiğiniz durumlarda oturan hiçbir aracı veya hizmet değil. Ancak Id'nin yapmayı sevdiği şey aslında sizi buradaki uygulamaya götürmek ve hızlı bir demo vermek. Ve benim de dışarı çıkmama izin ver ve bunu gerçekleştir. Bana haber ver, sanırım Eric, bunu iyi 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 esasen, her şeyden önce yapmanız gereken bir şey olan türlerle başlayalım ya da ilerde gelecekte bir noktaya değinecek ve bu konuda size biraz bilgi verecek olan bir şey. Ve bu gerçekten tahmin edebiliyor olmak - ya da dinamik olarak tahmin etmek - söylemeliyim - olduğu gibi şeyler. Şimdi, raporlar durumunda, araçta sahip olduğumuz şeylerden biri üç farklı tahmin raporu. Ve örneğin, bir veritabanı tahmini durumunda, bir veritabanının büyüklüğünü belli bir süre boyunca tahmin edebilmek durumunda muhtemelen ne yapmalıyım ve bu konuda size birkaç örnek vereceğim. Bu yüzden, oldukça yoğun G / Ç olan denetim veritabanımı alacağım - bununla ilgili birçok veri var. Bunları burada yapalım, görelim, yapalım ve sağlık veri tabanını buradan seçelim.
Fakat mesele şu ki, sadece bunun üzerinde ne olduğunu görmüyorum, “Bakın, son yıllarda veri almaya bakalım” diyebilirim - ve burada birazcık titreyeceğim, gerçekten bir yıla sahip değilim veri değerinde, yaklaşık iki aylık veri değerim var - ancak burada ay örnekleme oranı seçtiğim için, bu durumda gelecek 36 birimi tahmin edebileceğim veya tahmin edebileceğimden, sonraki 36 birim için örnekleme oranımız aylara ayarlandı. - bu bir birim, bir ay - ve daha sonra, bu üç veri tabanı için gelecekteki büyümemizi nerede öngöreceğimi gösterecek bir rapor hazırlayabilirim. Ve üç farklı veritabanı arasında, özellikle tarihsel olarak kullandıkları veri miktarına göre değişen bir dereceye kadar farklılığımız veya farkımız olduğunu görebiliriz.
Buradaki veri noktalarının tarihsel verileri temsil ettiğini görebiliriz, sonra da bu durumu bize bildirecek rakamlar ile birlikte bize tahminde bulunacaktır. Böylece bunu masa seviyesinde yapabiliriz, hatta sürücü puanlarım dahil, sürücülerimin ne kadar büyük olacağını tahmin edebileceğim sürücü seviyesinde bile yapabiliriz. Aynı türde bilgiyi tahmin edebiliriz, ancak bir kez daha, örnekleme oranına bağlı olarak, tahmin etmek istediklerimizi kaç birim ve nereye götürdüğümü belirlememe izin vereceğim. Ayrıca farklı tahmin türlerine de dikkat edin. Böylece, tahminde bulunma zamanı geldiğinde birçok seçenek ve esneklik elde edersiniz. Şimdi, bu iyi bir şey, aslında size belirli bir tarih vermekte ve “Hey, bu tarihte verilerinizin büyümesini beklediğimiz yer” diyebilmemiz iyi bir şeydir. Buna ek olarak, size sağlayabiliriz. kapalı saatlerde yaptığımız analizlerin bir kısmı ile ilgili diğer içgörüler ve çalıştığı sırada hizmet ile. Yaptığı şeylerden bazıları, geçmişte meydana gelen olayların tarihine dayanarak, muhtemel olan şeyleri önceden tahmin etmeye çalışmasıdır.
Bu yüzden burada görebiliyoruz, aslında bir tahmin bize, geçmişte bir kez daha yaşanmış olan şeylere dayanarak akşam boyunca sorun yaşama olasılığımıza dair bazı bilgiler veriyor. Yani, tabii ki bu harika, özellikle de eğer bir DBA değilse, bu şeylere bakabilirim, ama bir DBA olmasaydım, daha da iyi olan şey bu analiz sekmesidir. Böylece, bu araçta burada olmadan önce üründen geçip ürünü insanlara gösterirdik ve onlar “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. ”Ve böylece burada sahip olduğumuz şey, benim sağlığımla bile yardımcı olmak için harekete geçecek olursam, performansla ilgili eylemde bulunacaksam, anlamanız için daha iyi bir yoldur. çevre, bu önerileri sağlamanın sıralı bir yolunu bulabilmenin yanı sıra, bu öneriler hakkında daha fazla bilgi edinmek için bilgi konusunda faydalı ipuçlarını ve aslında bu verilerin bir kısmı ile dış bağlantılara sahip olmamı, bu da beni neden gösterecek? bu öneriler yapılmıştır.
Ve birçok durumda, dediğim gibi, bu sorunların çözümünü otomatikleştirecek bir senaryo sağlayabilmek. Şimdi, bu analizle burada ne yaptığının bir parçası - ve ben bu örneğin özelliklerini yapılandırmak için girdiğimde size göstereceğim ve analiz yapılandırma bölümüne gidiyorum - burada listelenen birçok farklı kategorimiz var ve Bunun bir parçası olarak, dizin optimizasyonuna ve sorgu optimizasyonuna sahibiz. Yani sadece metrikleri ve bunun gibi şeyleri değil, aynı zamanda iş yükleri ve indeksler gibi şeyleri de değerlendiriyorlardı. Buradaki durumda, aslında bazı ek hipotetik indeks analizleri de yapılıyor. Yani, istemediğim durumlardan biri, pek çok durumda, ihtiyacım yoksa indeks eklemek istemiyorum. Ancak bir noktada “Bir tablo, iş yükü içinde çalışan sorguların boyutuna veya türlerine ulaşmaktır, şimdi bir endeks eklemek için bir anlam ifade ediyor. Ama belki altı hafta öncesinden bir anlam ifade etmeyecekti. ”Bu da, söylediğim gibi, ortamda olup bitenlere, iş yüklerinde neler olduğuna bağlı olarak performansı artıracak şeyler hakkında dinamik olarak bilgi sahibi olmanıza izin veriyor. bu tür şeyleri yapıyorum.
Ve böylece burada çok fazla iyi bilgi edinmenin yanı sıra bu şeyleri otomatik olarak optimize etme yeteneği de elde edersiniz. Dolayısıyla, bu, tahmine dayalı analiz dediğimiz anlamda, yardım edebileceğimiz başka bir alandır. Şimdi, buna ek olarak, söylemeliyim ki, genellikle karar vermenize yardımcı olmak için genellikle borç verdiklerini düşündüğüm başka alanlarımız da var. Karar vermekten bahsettiğimizde, bir kez daha, geçmiş verilere bakabilmek, bu performansı geliştirmek için gereken yere gitmemiz için bize biraz fikir verebilir.
Şimdi yapabileceğimiz şeylerden biri, istediğimiz ölçüyü seçerek seçmemize izin veren temel bir görselleştiriciye sahip olduğumuz - ve burada düzgün bir tane bulmama izin vermemiz - SQL CPU kullanımına gidiyorum, ama asıl nokta gidebilirsiniz. Bu resimleri boyamak için birkaç hafta sonra geri döndüğünüzde, aykırı kişilerinizin ne zaman olduğunu, genel olarak bu değerin, veri topladığı zaman dilimi içerisinde nerede olduğunu söylediklerini görmek için. Ve sonra, buna ek olarak, gerçek örneğe girdiğimizde, taban çizgilerimizi yapılandırabileceğimizi fark edeceksiniz. Ve taban çizgileri, şeyleri otomatik hale getirmenin yanı sıra her şeyden haberdar olmanın önemli bir parçasıdır. Ve DBA'ların çoğunun size söyleyeceği gibi zorluk, çevrenizin gün boyunca, akşama karşı ve aynı zamanda zamanın bakım periyotlarında olduğu gibi daha önce bahsettiğimiz gibi değil. yüksek CPU seviyelerine veya olabilecek her şeye sahip olmanız gerekir.
Yani, buradaki durumda, bu gerçek taban çizgileri ile, birden fazla taban çizgisine sahip olabiliriz, bu yüzden örneğin bakım saatlerinde bu şekilde bir taban çizgisine sahip olabilirim. Fakat üretim saatim için bir referans çizgisi oluşturabilirim. Ve bunu yapmamızın amacı, bir SQL örneğine girdiğimizde ve aslında bu çok sayıda temel hattımız olduğunda, o zaman bir tür otomasyon, bir tür iyileştirme veya genel olarak sadece alarm vermeyi bekleyip gerçekleştirebiliriz. farklı zaman pencerelerine özgü. Dolayısıyla, burada göreceğiniz şeylerden biri, oluşturduğumuz bu temel çizgileri, bu analizi sağlamak için tarihsel verileri kullanmaktır, ancak daha önemlisi, bu eşikleri statik olarak değiştirebilirim, ancak bunları dinamik olarak da otomatikleştirebilirim. Bu nedenle, bakım penceresi veya bakım temel penceresinin açılacağını söylemeliyim, bu eşikler otomatik olarak o zaman penceresi içinde karşılaştığım yüklere, yani yüklerimin olmadığı gibi günün ortasında iş yükleri o kadar etkili olmadığında.
Yani, bu baz olarak akılda tutulması gereken bir şey. Açıkçası bunlar, normal olanı anlama ve aynı zamanda kaynakların tükenmesi durumunda ne zaman meşgul olacağınız anlamında sizin için gerçekten yararlı olacak. Şimdi, araçta sahip olduğumuz diğer bir şey, karar vermenize yardımcı olacak, üstelik taban çizgileri ve bu taban çizgileri ve dinamik olarak oluşturduğunuz eşikler etrafında uyarılar düzenleyebilmek. Sadece olup bitenler hakkında soruları cevaplamama yardım eden sayısız raporları çalıştırabilmek.
Öyleyse, bir örnek olarak, 150 örneğim varsa yönetiyorum - benim durumumda yok, öyleyse burada taklit oyununu oynamalıyız - fakat tüm üretim örneklerim varsa ve bulunduğum bölgenin nerede olduğunu anlamam gerekiyorsa Başka bir deyişle, performansı iyileştirmek için bir yönetim biçimini gerçekleştirmek için sınırlı bir süreye sahip olacaksam, kilit alanlara odaklanmak istiyorum. Ve böylece, “Bu ortama dayanarak, örnekleri birbirime göre sırala ve bana bu tartışmaya göre sırala.” Diyebilecektim. Disk kullanımı, bellek kullanımı, bekleyip beklemeyeceği, Tepki süresi olsun, birbirleriyle olan bu örnekleri ilişkilendirebilir miyim - veya sıra söylemeliyim -. Açıkçası, her listenin en üstünde olan örnek, eğer aynı durumdaysa, muhtemelen odaklanmak istediğim bir şey bu, çünkü listenin en üstünde bir kez daha açıkça görülüyor.
Dolayısıyla, araçta ortamı örnekleme sırasına göre sıralamanıza yardımcı olacak birçok raporunuz var; Bunu veritabanlarımda da yapabilirim, burada veritabanlarımı birbirlerine karşı sıralayabilirim. Belirleyebileceğim eşiklere ve alanlara özel olarak, sadece belirli veritabanlarına odaklanmak istiyorsam, burada joker karakterler bile kurabilirim ancak asıl mesele, veritabanlarımı aynı şekilde karşılaştırabilmem. Ayrıca, diğer karşılaştırmalı analiz türleri ve bu araçtaki en büyüğü gibi, elimizdeki temel analizdir. Dolayısıyla, burada hizmet görünümüne ilerlerseniz, bir temel istatistik raporunun olduğunu göreceksiniz. Şimdi bu rapor açıkça, yalnızca metrik değerlerin ne olduğunu anlamamıza yardımcı olacak, ancak belirli bir örnek için dışarı çıkabileceğimi ve bu metriklerin herhangi biri için, bu metriklerin taban çizgilerini gerçekten inceleyebilecek.
Öyleyse, her ne olabilirse, yüzde olarak veya çıkabileceğim her şeyi söyleyeyim ve “Son 30 gün içinde bunun için temel çizgisini görelim” diyebilir, bu durumda bana taban çizgisine göre gerçek değerleri gösterecektir. Açıkçası, bu bilgiyi kullanarak bazı kararlar verebileceğimi açık bir şekilde söyleyebildim, o zaman bu, hangi soruya bağlı olacağı, o anda sorduğunuz durumlardan biridir. Fakat bu açıkça, bu sorular için size yardımcı olacak. Keşke her şeyi yapan bir raporumuz olduğunu söyleyebilseydim ve kolay rapor gibi, basıp butona basarsanız ve cevaplayabileceğiniz her “eğer” sorusuna cevap verir. Ancak gerçek şu ki, bu "aşağı" ifadelerinde aradığınız soruları formüle edebilmek için birçok özellik ve bu seçeneklerden birini seçebileceksiniz.
Dolayısıyla, bu raporların çoğu, bu tür soruları yanıtlayabilmeye yöneliktir. Ve bu yüzden, bu raporların ve ek olarak, daha önce de bahsettiğim gibi, aracın içinde göstermiş olduğunuz her şeyin, yeni ölçümleri dahil etme, yönetilebilme, hatta sayaç yaratma esnekliğine sahip olmaları da, asıl önemli olanı, veya yoklama aralıklarınıza dahil edilmiş SQL sorguları, bu soruları cevaplamama yardımcı olmak için, belki de izlemeyi beklememiş olduğumuz kutudan, o şeyleri ekleyebilirsiniz. Ve size daha önce gösterdiğim şeyleri yapabileceksiniz: temel, raporları çalıştırabilir ve bu metrikten raporlar oluşturabilir ve size burada gösterdiğim bu farklı türden birçok şeyi cevaplayabilir ve yapabilirsiniz.
Şimdi, buna ek olarak - ve son zamanlarda oldukça açık bir şekilde karşılaştığımız şeylerden biri - önce, herkes çevirip veya VM'lere geçiyordu. Ve şimdi biz de buluta doğru giden bir sürü insan var. Ve bu tür şeylerin etrafında ortaya çıkan birçok soru var. Buluta geçmek benim için anlamlı mı? Buluta geçerek para biriktirecek miyim? Bunları bir VM'ye, paylaşılan kaynak makinesine koyacak olsaydım, ne kadar para biriktirebilirim? Bu tür sorular açıkça belli olacak. Bu nedenle, birçoğunun akılda tutulması, Diagnostic Manager ile VMware ve Hyper-V'in sanallaştırılmış ortamlarını ekleyebilir ve bunlardan faydalanabiliriz. Ayrıca, bulutta bulunan örnekleri de ekleyebiliriz; böylece Azure DB gibi ortamlarınız, hatta RDS bile, bu ortamlardan metrikler çekebiliriz.
Dolayısıyla, çok fazla esneklik ve bu soruları, insanların yöneldiği diğer ortam türleriyle ilgili olarak yanıtlayabilmemizdir. Ve bu konuda hala birçok soru var ve insanların bu ortamları birleştirdiğini gördükçe, bu soruları cevaplayabilmeleri gerekecek. Yani, bu konu ile ilgili olarak Diagnostic Manager’ın oldukça iyi bir bakış, Id. İş zekası konusunun ortaya çıktığını ve bugün hakkında konuşmadığımız iş zekası için bir aracımız olduğunu biliyorum, ancak aynı zamanda küplerinizle ilgili olarak bu tür soruları yanıtlama konusunda da size bir fikir verecektir. tüm bu farklı şeyleri de. Ancak umarım bu, en azından bu ürünün iyi bir plan hazırlayabilmesinde nasıl yardımcı olabileceği konusunda iyi bir genel bakış olmuştur.
Eric Kavanagh: Tamam, iyi şeyler. Evet, hala dışarı çıkarsa, onu Rick'e fırlatacağım. Rick, senden bir soru var mı?
Rick Sherman: Evet, ilk önce, bu harika, hoşuma gitti. Özellikle VM'lere ve bulutlara yayılmayı seviyorum. Pek çok uygulama geliştiricisinin bulutta olması durumunda ayarlama yapmaları gerekmediğini düşündüğünü görüyorum. Yani-
Bullett Manale: Doğru, yine de ödemeliyiz, değil mi? İnsanların buluta koydukları şey ne olursa olsun hala para ödemek zorundasınız, bu nedenle eğer zayıf çalışıyorsa veya çok fazla CPU döngüsü oluşturuyorsa, daha fazla para ödemeniz gerekir, bu yüzden değil, yine de ölçmeniz gerekir. bu kesinlikle.
Rick Sherman: Evet, bulutta bir sürü kötü tasarım gördüm. Sormak istedim, bu ürün de kullanılacak mıydı - BI ürününden bahsettiğinizi ve birbirinizle etkileşime giren tonlarca başka ürününüz olduğunu biliyorum - ama bu araçtaki SQL sorgularına bakmaya başlayacak mısınız? Yoksa bunun için kullanılacak başka araçlar mı olurdu?
Bullett Manale: Hayır, bu kesinlikle olur. Bu, örtbas etmediğim ve istediğim şeylerden biri, bunun sorgular kısmı. Sorgu performansını tanımlamak için, bununla ilgili olarak, özellikle burada bu görüş üzerinde gördüğümüz gibi beklemeyle ya da genel olarak sorguların kaynak tüketimiyle ilgili olup olmadığını sorgulamanın analiz edebileceğimiz çok sayıda yolumuz var. verim. Süre, CPU, G / Ç ve bir kez daha, içgörü sağlamak için iş yüklerine bakabiliriz. Analiz bölümünde önerileri sağlayabiliriz ve ayrıca sorguların kendileri hakkında bilgi sağlayan web tabanlı bir sürümümüz de vardır. Böylece eksik indeksler ve yürütme planını ve bu tür şeyleri görme yeteneği hakkında öneriler alabilirim; aynı zamanda bir yetenek. Bu nedenle, kesinlikle, Pazar günleri (kahkahalar) sorguları yedi şekilde teşhis edebilir ve bu uygulamaların sayısı, kaynak tüketimi, bekler, süre, tüm bu iyi şeyler hakkında bilgi verebiliriz.
Rick Sherman: Tamam harika. Ve sonra tüm bu izlemeyle birlikte kendileri üzerindeki yük ne?
Bullett Manale: Bu iyi bir soru. Bu soruyu cevaplamanın getirdiği zorluk, buna bağlı olarak değişmesi, tıpkı herhangi bir şey gibi. Aracımızın sunacaklarının çoğu, esneklik sağlar ve bu esnekliğin bir parçası neyi toplayacağınızı ve neyi toplayamayacağınızı söylemenizdir. Örneğin, sorguların kendisiyle, bekleme bilgilerini toplamak zorunda değilim, veya yapabilirim. Bir süreyi geçen sorgular ile ilgili yürütme hakkında bilgi toplayabilirim. Bunun bir örneği olarak, configure sorgu izleyicisine girersem ve “Bu değeri sıfıra değiştirelim” derdim, gerçek şu ki, araç temelde çalışan her sorguyu toplar. Bu neden orada, ancak genel olarak konuşursak, eğer tüm sorgular için tam bir veri örneği sağlamak isteseydim, bunu yapabilirdim.
Bu nedenle, ayarlarınızın kutudan çıkan konuşmaları ile göreceli olarak çok ilgili. Yüzde 1-3 arasında bir yerde, ancak geçerli olacak diğer şartlar var. Aynı zamanda ortamınızda ne kadar port sorgusu çalıştığına da bağlı, değil mi? Ayrıca, bu sorguların toplanma yöntemine ve SQL'in hangi sürüm olduğuna da bağlıdır. Dolayısıyla, örneğin, SQL Server 2005, genişletilmiş olaylardan çekilemedi, buna rağmen bunu yapmak için bir izden çekecektik. Bu yüzden, bu veriyi toplamaya gideceğimiz yönden biraz farklı olurdu, ancak söylediğim gibi, 2004'ten bu yana bu ürünle ilgili sanırım için bulunduğumuzu söyledi. Çok uzun zaman oldu, binlerce müşterimiz oldu, bu yüzden yapmak istediğimiz son şey performans sorunlarına neden olan bir performans izleme aracına sahip olmaktır (gülüyor). Ve bundan mümkün olduğunca uzak durmaya çalışıyoruz, ancak genel olarak konuşursak, yaklaşık yüzde 1-3'ü iyi bir kuraldır.
Rick Sherman: Tamam, ve bu oldukça düşük, bu yüzden müthiş.
Eric Kavanagh: İyi. Robin, senden bir soru var mı?
Robin Bloor: Üzgünüm, dilsizdim. Birden fazla veritabanı yeteneğine sahipsiniz ve neden birden fazla veritabanına nasıl bakacağınızla ilgileniyorum ve bu nedenle daha büyük bir kaynak tabanının çeşitli sanal makineler arasında vb. İnsanların bunu nasıl kullandığıyla ilgileniyorum. Müşterilerin bununla ne yaptığıyla ilgileniyorum. Çünkü bu bana bakar, kesinlikle, veritabanlarıyla uğraşırken, asla elimde olmayan bir şeyi. Ve sadece bir vakayı herhangi bir zamanda herhangi bir anlamlı şekilde anlamlı bir şekilde ele alırdım. Peki insanlar bunu nasıl kullanıyor?
Bullett Manale: Genel olarak konuşursak, genel olarak sadece aracın kendisinden mi bahsediyorsunuz? Nasıl kullanıyorlar? Genel olarak, bunun çevrenin merkezi bir mevcudiyet noktasına sahip olabilmesi ile ilgili. İçiniz rahat olsun ve bir ekrana bakarlarsa ve yeşil görürlerse, her şeyin iyi olduğunu bilirler. DBA’nın bakış açısına göre çoğu durumda problemler yaşandığı ve açık bir şekilde ortaya çıktığı durumlarda, bu problemlerin çoğu konsolun önündeyken ortaya çıkar, bu yüzden problem ortaya çıktığı anda haberdar olun. Ancak buna ek olarak, sorunun ne zaman ortaya çıktığını anlayabilmek, kendilerine neyin meydana geldiğiyle ilgili bazı avantajlar sağlayan bilginin kalbine ulaşabilmek. Ve böylece, bence, en büyük kısmı: proaktif olmak, reaktif olmamak.
Konuştuğum DBA'ların çoğu - ve bilmiyorum, bunların iyi bir yüzdesi - maalesef hala reaktif ortamlardalar; bir tüketicinin onlara sorun olduğunu söylemek için onlara yaklaşmasını beklerler. Bu yüzden, birçok insanın bundan kaçmaya çalıştığını görüyoruz ve bence bu aracı sevenler neden proaktif olmalarına yardım ediyor, ama aynı zamanda neler olup bittiği hakkında fikir veriyor. , sorun ne, ama çoğu durumda, en azından bulduğumuz şey - ve belki de sadece DBA'lar bize bunu söylüyor - ama DBA'lar, algılamayı yazan uygulama geliştiricisi olsa bile, her zaman onların sorunu Bu doğru yazmamış, suçu üstlenecek olanlardır, bu uygulamayı sistemlerine veya sunucularına götürürler ve ardından performans kötü olduğunda, herkes DBA'ya “Bu senin suçun” diyor.
Bu yüzden, bu araç, DBA'nın “Hey, problemin yattığı ve benim değil.” (Gülüşler) ihtiyacımız olan yer burasıdır. Sorguların değişip değişmediğini veya olabileceği her şeyi düzeltin. Bazı durumlarda, sorumlulukları bakımından kovalarına düşeceklerdir, ancak en azından bunu anlamalarına ve bilmelerine yardımcı olacak bir araca sahip olmaları ve bunu zamanında yapmaları açıkça ideal bir yaklaşımdır.
Robin Bloor: Evet, aşina olduğum sitelerin çoğu, ama o zamandan beri orada çok çeşitli veritabanı sitelerine bakmaya başlıyorum, fakat çoğunlukla bulduklarım bir avuçta odaklanmış DBA'ların olacağıydı. veritabanları. Ve bunlar veri tabanları olacaktı, eğer düşselerdi iş için gerçekten büyük bir problem olurdu, vb. Ve diğeri, onlar şu anda sadece istatistik toplayacaklar ve daha sonra, alanlarının tükenmediğini ve hiçbir zaman onlara bakmadıklarını görmek için. Demoyu yaparken ben de ona bakıyordum ve iyi düşünüyordum, bir şekilde veya başka bir şekilde, sadece, çok fazla verip verdikleri veritabanları için böyle bir şey sağlayarak, hiç kimsenin çok fazla umursamadığı bir şeyi genişletiyorsunuz. , zaman zaman uygulama büyümesi var. DBA kapsamını oldukça çarpıcı bir şekilde genişletiyorsunuz. Yani sorunun asıl amacı bu, yani böyle bir araçla, kurumsal ağdaki her veri tabanına DBA hizmeti vermeyi başarabildiniz mi?
Bullett Manale: Tabii ki, zorluk şu ki, oldukça iyi bir şekilde söylediğiniz gibi, DBA'ların umursadığı bazı veri tabanları ve daha sonra umursadıkları bazı veritabanları gibi. Ve bu belirli ürünün, ruhsatlandırma yönteminin her bir durumda olması. Öyleyse, sanırım, insanlar “Hey, bu, bu araçla yönetmek istediğim kadar kritik bir örnek değil” kararını verdiklerinde bir eşik olduğunu söylersiniz. Bu, daha elimizde başka araçların da olduğunu söyledi. , Sanırım, daha az önemli olan SQL örneklerine hizmet ediyor. Bunlardan biri, durumlara karşı hafif sağlık kontrolleri yaptığımız Envanter Yöneticisi gibi olacak, fakat bunun yanında, keşif yaptığımıza göre, çevrimiçi hale getirilen yeni örnekleri tespit ettik ve sonra bu noktadan, DBA olarak söyleyebilirim ki, “Tamam, yeni bir SQL örneği var, şimdi Express mi? Ücretsiz sürüm mü yoksa işletme sürümü mü? ”Bu muhtemelen kendime sormak istediğim bir soru, ama ikincisi, bu örnek benim için ne kadar önemli? Bu kadar önemli değilse, bu aracın çıkmasını ve çalışmasını sağlayabilmeliyim, jenerik, genel sağlık kontrolleri olarak adlandırdığım şeye, DBA olarak önem verdiğim temel tür şeyler anlamındadır: Sürücü doluyor mu? Sunucu sorunlara yanıt veriyor mu? Ana şeyler değil mi?
Diagnostic Manager 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, oysa esas olarak odaklanmış. neye sahip olduğumu, neye sahibim ve bundan kim sorumlu? Hangi servis paketleri ve düzeltmelerim var? Sunucularım, sağlıklı bir SQL örneği olarak kabul edeceğim şeylerin ana bileşenleriyle çalışıyor mu? Bu yüzden sorunuzu cevaplamak için, biraz karışık var. Bu araca bakan insanlar olduğunda, genellikle daha kritik örneklere bakıyorlar. Bu, sahip oldukları her örneği satın alan ve yöneten bazı insanlara sahip olduğumuzu söyledi. Ancak, genel olarak, kesinlikle çevrelerini, bu örnekleri yönetmek için böyle bir araca sahip olacak kadar önemli olduğunu düşünenlerin eşiğine eşittir.
Robin Bloor: Tamam, Eric'e vermeden önce başka bir soru daha. Sanki endüstriyi izlemekten aldığımız izlenim, veritabanlarının hala bir ömre sahip olduğudur, ancak tüm veriler bu veri göllerinin tümüne vb. Akıyor. Bu gerçekten, bu yutturmaca ve yutturmaca asla gerçeği yansıtmıyor, bu yüzden orada ne tür bir gerçeklik algıladığınızla ilgileniyorum? 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ı balon yapım mı? Gördüğün resim ne
Bullett Manale: Bence birçok durum, verilerin bir kısmının, daha uygun hale geldiği diğer teknolojiler olduğunda daha anlamlı olduğu diğer bölümlere taşındığını görüyordu. Son zamanlarda, bazı büyük veri maddeleri. Ancak, bu veritabanlarının, çoğu durumda genelleştirilmesinin zor olduğunu, çünkü herkesin biraz farklı olduğunu söyleyebilirim. Genel olarak konuşursak, biraz sapma görüyorum. Gördüğüm gibi, insanlar birçok durumda elastik modellere geçiyorlar, çünkü kaynakları diğer alanlarda çok fazla değil, büyütmek istiyorlar. Bazı insanlar büyük verilere doğru ilerliyor. Ancak, algı için bir fikir edinmek zor, çünkü genel olarak herkesle konuştuğum kişilerin geleneksel veritabanları var ve bunu bir SQL Server ortamında kullanıyorlar.
Dedi ki, İD'in kendisi açısından SQL, kesinlikle pazar payını kazandığını düşünüyorum. Ve bence hala SQL gibi Oracle’ın diğer yerlerinden SQL’e doğru giden birçok insan var, çünkü daha uygun fiyatlı ve açıkça göründüğü gibi, SQL sürümleri daha gelişmiş hale geldiğinde - ve bunu daha yeni şeyler ile görüyorsunuz. SQL ile şifreleme ve onu bir ortam ya da veritabanı platformu yapan diğer tüm yetenekler açısından açıkçası bu çok kritik bir özelliktir, sanırım. Yani bence bunu da görüyordum. Bir kayma gördüğünüz yerde, hala oluyor. Demek istediğim, 10 yıl önce gerçekleşti, bence hala, ortamların büyüdüğü ve pazar payının arttığı SQL Server açısından oluyor.
Robin Bloor: Tamam Eric, izleyicinin bir iki sorusu olduğunu varsayıyorum?
Eric Kavanagh: Evet, sana hızlı bir tane atmama izin ver. Aslında çok güzel bir soru. Katılanlardan biri soruyor, bu araç sorgunun hızlandırılması için bir tablonun bir dizine ihtiyacı olup olmadığını söyleyecek mi? Eğer öyleyse, bir örnek gösterebilir misin?
Bullett Manale: Evet, özellikle bir indeks eklemek için bir tane olup olmadığımı bilmiyorum, ama burada görebilirsiniz, burada parçalanma önerileri var. Ben de sadece sahip olduğumuza inanıyorum ve bu web tabanlı sürümü sunan Teşhis Yöneticisinin bir parçasıydı, burada bana eksik bir indeksim var. Ve bu önerileri görebiliriz ve bize bu bilgiyi endeksleyerek potansiyel kazancımızı söyler. Bahsetmem gereken diğer şey, tavsiyelerde bulunduğumuzda, bunların çoğu için senaryo için oluşturulacak olmasıdır. Bunlar iyi bir örnek değil, ancak evet, bir indeksin - bir indeksin ya da bir indeksin eklenmesi - performansı artıracağını ve daha önce de söylediğim gibi, çok şey yaptığımızı görebileceksiniz. varsayımsal endeks analizi yoluyla bu. Bu nedenle, iş yükünü anlamak ve bunu tavsiyeye uygulayabilmek gerçekten yardımcı olur.
Eric Kavanagh: Bu harika bir şey ve buradaki son yorumlar için bana iyi bir dilek verecek. Robin ve ben ve Rick de, uzun yıllar boyunca duyduklarını duyduğumda, kendini ayarlayan veritabanları hakkında konuşurlar. Kendi kendine ayarlanan bir veritabanı! Söyleyebileceğim tek şey: Onlara inanma.
Bullett Manale: Yutturmaca inanmıyorum.
Eric Kavanagh: Dinamik olarak yapılan küçük küçük şeyler olabilir, ancak bu durumda bile, bunu kontrol etmek isteyip istemediğiniz bir şeyi yapmadığından emin olabilirsiniz. Dolayısıyla, bir süredir, veritabanı seviyesinde neler olup bittiğini anlamak için bunun gibi araçlara ihtiyaç duyacaktı ve Robin'in dediği gibi, veri gölleri etkileyici kavramlardı, ancak muhtemelen orada oldukları kadarını alma şansı hakkında Yakında bir Loch Ness Canavarı. Bu yüzden, tekrar söyleyeyim, gerçek dünyada çok fazla veritabanı teknolojisi var, bunlara bakmak ve sentezlemek için insanlara, DBA'lara ihtiyacımız var. Anlatabilirsin, bu işleri yapmak için ne yaptığını bilmen gerekir. Ama ne yaptığını bilmen için sana bilgi verecek araçlara ihtiyacın var. Yani, sonuçta DBA'lar gayet iyi olacak.
Bullett Manale ve IDERA'daki arkadaşlarımıza büyük teşekkürler. Ve elbette, Rick Sherman ve Robin Bloor. Tüm bu web yayınlarını arşivliyoruz, bu nedenle daha fazla bilgi için çevrimiçi insideanalysis.com veya ortak sitemiz www.techopedia.com'a atlayın.
Ve bununla, size veda edelim, millet. Tekrar teşekkürler, bir dahaki sefere konuşalım. Kendine iyi bak. Güle güle.