Bởi nhân viên Techopedia, ngày 19 tháng 4 năm 2017
Takeaway: Người dẫn chương trình Eric Kavanagh thảo luận về dự báo với Tiến sĩ Robin Bloor, Rick Sherman và IDett's Bullett Manale.
Bạn phải đăng ký cho sự kiện này để xem video. Đăng ký để xem video.
Eric Kavanagh: Thưa quý vị và các bạn, xin chào một lần nữa và chào mừng bạn quay trở lại với loạt phim truyền hình Hot Technologies! Tên tôi là Eric Kavanagh, tôi sẽ là chủ nhà của bạn cho hội thảo web ngày hôm nay, được gọi là tiết kiệm thời gian, tiền bạc và rắc rối với dự báo tối ưu. Khóa học 'Tôi đã bỏ lỡ phần đầu tiên của tiêu đề ở đó, đó là kế hoạch trả tiền tốt nhất. luôn luôn nói về điều đó trong chương trình này. Vì vậy, Hot Technologies tất nhiên là diễn đàn của chúng tôi để hiểu một số sản phẩm tuyệt vời trên thế giới hiện nay, thế giới công nghệ doanh nghiệp, những gì mọi người đang làm với họ, cách họ làm việc, tất cả những thứ thú vị đó.
Và chủ đề hôm nay, như tôi đề xuất, liên quan đến dự báo. Thực sự bạn đang cố gắng để hiểu những gì sẽ xảy ra trong tổ chức của bạn. Làm thế nào bạn sẽ giữ cho người dùng của bạn hạnh phúc, bất kể họ đang làm gì? Nếu họ đang phân tích, nếu họ đang làm việc thực sự, họ sẽ đối mặt với khách hàng thực sự với các hệ thống giao dịch, bất kể trường hợp nào, bạn muốn hiểu hệ thống của bạn đang hoạt động như thế nào và những gì đang xảy ra, và đó là những gì chúng ta ' hôm nay sẽ nói về Thật là buồn cười vì dự báo không phải là điều tôi thích làm, vì tôi mê tín, như tôi nghĩ nếu tôi dự báo quá nhiều, những điều tồi tệ sẽ xảy ra, nhưng đó chỉ là tôi. Đừng theo sự dẫn dắt của tôi.
Vì vậy, đây là những người thuyết trình của chúng tôi ngày hôm nay, bạn thực sự ở góc trên bên trái, Rick Sherman đang quay số từ Boston, Bullett Manale bạn thân của chúng tôi từ IDERA và Tiến sĩ Robin Bloor của chúng ta. Và với điều đó, tôi sẽ trao nó cho Robin và chỉ nhắc nhở mọi người: Đặt câu hỏi, đừng ngại, chúng tôi yêu những câu hỏi hay, chúng tôi sẽ gửi chúng cho những người thuyết trình và những người khác hôm nay. Và với điều đó, Robin, mang nó đi.
Robin Bloor: OK, vì tôi đang ở vị trí cực như họ nói, tôi nghĩ tôi đã kể một câu chuyện SQL ngày hôm nay, bởi vì đó là nền tảng cho những gì cuộc thảo luận sẽ diễn ra và chắc chắn sẽ không đụng độ bởi vì Rick không tập trung vào điều này, và sẽ không đụng độ với những gì Rick nói. Vì vậy, câu chuyện SQL, có một số điều thú vị về SQL vì nó quá nổi trội. Hãy xem, đó là một lỗi đánh máy, SQL là một ngôn ngữ khai báo. Ý tưởng là bạn có thể tạo một ngôn ngữ mà bạn sẽ yêu cầu những gì bạn muốn. Và cơ sở dữ liệu sẽ tìm ra cách để có được nó. Và thực tế nó đã hoạt động khá tốt, nhưng có một số điều đáng nói về nó, hậu quả của việc dựa trên toàn bộ ngành CNTT trên một ngôn ngữ khai báo. Người dùng không biết hoặc không quan tâm đến tổ chức vật lý của dữ liệu và đó là điều tốt về ngôn ngữ khai báo - nó tách bạn ra khỏi tất cả những điều đó, và thậm chí lo lắng về nó - chỉ cần hỏi bất cứ điều gì bạn muốn và cơ sở dữ liệu sẽ đi và lấy nó
Nhưng người dùng không biết liệu cách họ cấu trúc truy vấn SQL sẽ ảnh hưởng đến hiệu năng của truy vấn hay không và đó là một nhược điểm. Tôi đã thấy các truy vấn dài hàng trăm và hàng trăm dòng, đó chỉ là một yêu cầu SQL, bạn biết đấy, bắt đầu với một lựa chọn, và tiếp tục với các truy vấn phụ, v.v. Và nó thực sự chỉ ra rằng nếu bạn muốn có một bộ sưu tập dữ liệu cụ thể từ cơ sở dữ liệu, bạn có thể yêu cầu nó theo nhiều cách khác nhau với SQL và nhận được câu trả lời tương tự nếu bạn có một chút quen thuộc với dữ liệu. Vì vậy, một truy vấn SQL không nhất thiết là cách tốt nhất để yêu cầu dữ liệu và cơ sở dữ liệu sẽ phản hồi hoàn toàn khác nhau theo SQL mà bạn đưa vào chúng.
Và vì vậy, SQL thực sự ảnh hưởng đến hiệu suất, vì vậy những người sử dụng SQL, điều đó đúng với họ, điều đó cũng đúng với các lập trình viên SQL sử dụng SQL và họ thậm chí ít nghĩ về tác động mà họ sẽ gây ra, bởi vì hầu hết sự tập trung của họ thực sự là vào việc thao túng dữ liệu chứ không phải vào việc lấy, đưa dữ liệu. Và điều tương tự cũng đúng với các công cụ BI, tôi đã thấy SQL, nếu bạn thích, vắt kiệt các công cụ BI của các cơ sở dữ liệu khác nhau và phải nói rằng, rất nhiều trong số đó, tôi sẽ không t viết các truy vấn SQL như thế. Có ai đó đã tạo ra, nếu bạn thích, một động cơ nhỏ cho dù đó là tham số nào, nó sẽ loại bỏ một số SQL và một lần nữa, SQL đó không nhất thiết phải là SQL hiệu quả.
Sau đó, tôi nghĩ rằng tôi đã đề cập đến sự không phù hợp trở kháng, dữ liệu mà các lập trình viên sử dụng khác với dữ liệu sắp xếp. Vì vậy, DMS của chúng tôi lưu trữ dữ liệu trong các bảng, tổ chức mã hướng đối tượng chủ yếu là các lập trình viên, hiện đang lập trình dạng hướng đối tượng và họ sắp xếp dữ liệu trong các cấu trúc đối tượng, vì vậy nó không ánh xạ cái này sang cái khác. Vì vậy, cần phải dịch từ những gì lập trình viên nghĩ dữ liệu sang cơ sở dữ liệu nghĩ dữ liệu đó là gì. Có vẻ như chúng ta đã làm điều gì đó sai cho trường hợp đó. SQL có DDL để định nghĩa dữ liệu, nó có DML - ngôn ngữ thao tác dữ liệu - chọn, chiếu và tham gia, để lấy dữ liệu đó. Bây giờ, có rất ít toán học và rất ít thứ dựa trên thời gian, vì vậy đó là ngôn ngữ không hoàn hảo, mặc dù phải nói rằng nó đã được mở rộng và tiếp tục được mở rộng.
Và sau đó, bạn gặp vấn đề về rào cản SQL, vốn luôn căng thẳng hơn sơ đồ, nhưng rất nhiều người đã đặt câu hỏi vì lý do phân tích, một khi họ đã có câu trả lời cho các thuật ngữ dữ liệu câu hỏi, muốn hỏi một câu hỏi khác. Vì vậy, nó trở thành một hộp thoại, tốt, SQL không được tạo cho các hộp thoại, nó được xây dựng để hỏi bạn muốn gì cùng một lúc. Và thật đáng để biết điều đó, bởi vì có một số sản phẩm thực sự bỏ qua SQL để tạo ra cuộc trò chuyện giữa người dùng và dữ liệu.
Về hiệu suất cơ sở dữ liệu - và loại này lan tỏa ra mọi thứ - vâng, có CPU, có bộ nhớ, có đĩa, có chi phí mạng và có vấn đề khóa của hơn một người muốn sử dụng dữ liệu độc quyền ở một mức nhất định điểm trong thời gian. Nhưng cũng có các cuộc gọi SQL kém, có rất nhiều điều có thể được thực hiện nếu bạn thực sự tối ưu hóa SQL, về mặt hiệu suất. Vì vậy, các yếu tố hiệu suất cơ sở dữ liệu: thiết kế xấu, thiết kế chương trình xấu, thiếu đồng thời khối lượng công việc, cân bằng tải, cấu trúc truy vấn, lập kế hoạch năng lực. Đó là tăng trưởng dữ liệu. Và trong một vài từ, SQL là thuận tiện, nhưng nó không tự tối ưu hóa.
Phải nói rằng, tôi nghĩ chúng ta có thể truyền lại cho Rick.
Eric Kavanagh: Được rồi, Rick, hãy để tôi đưa chìa khóa cho chiếc xe WebEx. Mang nó đi.
Rick Sherman: Được rồi, tuyệt vời. Xin cảm ơn Robin, khi chúng tôi bắt đầu vào phần đầu bài thuyết trình, đồ họa của tôi vẫn còn khá nhàm chán, nhưng chúng tôi sẽ làm theo. Vì vậy, tôi đồng ý với mọi thứ mà Robin nói về phía SQL. Nhưng điều tôi muốn tập trung một chút bây giờ là nhu cầu về dữ liệu, chúng tôi sẽ nhanh chóng thông qua, việc cung cấp như trong các công cụ được sử dụng trong không gian đó hoặc nhu cầu về các công cụ trong không gian đó.
Trước hết, có một số trong mỗi bài viết mà bạn đọc phải làm với dữ liệu lớn, nhiều dữ liệu, dữ liệu phi cấu trúc đến từ đám mây, dữ liệu lớn ở mọi nơi mà bạn có thể tưởng tượng. Nhưng sự phát triển của thị trường cơ sở dữ liệu đã liên tục xảy ra với SQL, cơ sở dữ liệu quan hệ có lẽ tính đến năm 2015, vẫn chiếm 95% thị trường cơ sở dữ liệu. Ba nhà cung cấp quan hệ hàng đầu có khoảng 88 phần trăm thị phần trong không gian đó. Vì vậy, chúng ta vẫn đang nói, như Robin đã nói, về SQL. Và trên thực tế, ngay cả khi chúng tôi đang tìm kiếm trên nền tảng Hadoop, Hive và Spark SQL - mà con trai tôi, một nhà khoa học dữ liệu, sử dụng mọi lúc - chắc chắn là cách thống trị để mọi người truy cập dữ liệu.
Bây giờ, về phía cơ sở dữ liệu, có hai loại sử dụng cơ sở dữ liệu rộng lớn. Một là dành cho các hệ thống quản lý cơ sở dữ liệu hoạt động, do đó, lập kế hoạch quan hệ doanh nghiệp, quản lý mối quan hệ khách hàng, Salesforce ERPs, Oracles, EPIC, N4s, v.v., trên thế giới. Và, có một lượng lớn và mở rộng lượng dữ liệu trong kho dữ liệu và các hệ thống dựa trên kinh doanh thông minh khác. Ause Nguyên nhân tất cả mọi thứ, bất kể nó được nắm bắt, lưu trữ hoặc giao dịch ở đâu và cuối cùng được phân tích và do đó có nhu cầu rất lớn và tăng việc sử dụng cơ sở dữ liệu, đặc biệt là cơ sở dữ liệu quan hệ trên thị trường.
Bây giờ, chúng tôi có nhu cầu, chúng tôi có lượng dữ liệu khổng lồ sắp tới. Và tôi không thực sự chỉ nói về dữ liệu lớn, tôi đang nói về việc sử dụng dữ liệu trên tất cả các loại doanh nghiệp. Nhưng đi kèm với điều đó từ phía cung, đối với những người có thể quản lý các tài nguyên đó, trước hết chúng tôi có một sự thiếu hụt DBA. Theo Cục Thống kê Lao động, từ 2014202024, các công việc DBA sẽ chỉ tăng 11% - bây giờ đó là những người có chức danh DBA, nhưng chúng ta sẽ nói về điều đó trong một giây - so với 40- cộng với phần trăm không gian tăng trưởng dữ liệu hàng năm. Và chúng tôi có rất nhiều DBA; trung bình cùng một nghiên cứu nói về độ tuổi trung bình là khá cao so với các ngành CNTT khác. Và sau đó chúng tôi có rất nhiều người rời khỏi lĩnh vực này, không nhất thiết phải nghỉ hưu, mà chuyển sang các khía cạnh khác, đi vào quản lý, hoặc bất cứ điều gì.
Bây giờ, một phần lý do họ rời đi, là vì công việc DBA ngày càng khó khăn hơn. Trước hết, chúng tôi có các DBA tự quản lý nhiều cơ sở dữ liệu khác nhau, cơ sở dữ liệu vật lý, được đặt ở khắp mọi nơi, cũng như các loại cơ sở dữ liệu khác nhau. Bây giờ có thể là quan hệ, hoặc chúng có thể là cơ sở dữ liệu khác, các loại cơ sở dữ liệu, quá. Nhưng ngay cả khi nó có liên quan, họ có thể có bất kỳ một, hai, ba, bốn nhà cung cấp khác nhau mà họ thực sự đang cố gắng quản lý. Các DBA thường tham gia sau khi thiết kế cơ sở dữ liệu hoặc ứng dụng. Robin đã nói về cách cơ sở dữ liệu hoặc ứng dụng được thiết kế, cách SQL được thiết kế. Chà, khi chúng ta nói về mô hình hóa dữ liệu, mô hình ER, mô hình ER mở rộng, mô hình hóa kích thước, mô hình hóa chiều tiên tiến, bất cứ điều gì, điển hình là các lập trình viên ứng dụng và nhà phát triển ứng dụng thiết kế với mục tiêu cuối cùng của họ - họ không thiết kế cho hiệu quả của cấu trúc cơ sở dữ liệu chính nó. Vì vậy, chúng tôi có rất nhiều thiết kế kém.
Bây giờ, tôi không nói về các nhà cung cấp ứng dụng doanh nghiệp thương mại; họ thường có mô hình ER hoặc mô hình ER mở rộng. Điều tôi đang nói đến là có rất nhiều quy trình và ứng dụng kinh doanh đang được xây dựng bởi các nhà phát triển ứng dụng ở mỗi công ty - đó là những quy trình không nhất thiết phải được thiết kế cho hiệu quả hoặc hiệu quả của việc triển khai. Và bản thân các DBA đã làm việc quá sức và đôi khi họ có trách nhiệm 24/7, họ tiếp tục nhận được ngày càng nhiều cơ sở dữ liệu. Tôi nghĩ rằng điều đó đã làm một chút với mọi người rằng họ không hiểu những gì họ làm hoặc cách họ làm điều đó. Nhóm nhỏ của riêng họ và mọi người cứ nghĩ mãi, tất cả những công cụ này đều rất dễ sử dụng, chúng ta có thể tiếp tục sử dụng ngày càng nhiều cơ sở dữ liệu về khối lượng công việc của họ, đó không phải là trường hợp.
Điều này dẫn chúng ta đến các DBA bán thời gian và tình cờ. Chúng tôi có các nhóm CNTT nhỏ và họ không nhất thiết phải có một DBA chuyên dụng. Bây giờ điều đó đúng với các doanh nghiệp vừa và nhỏ, nơi việc mở rộng cơ sở dữ liệu và ứng dụng cơ sở dữ liệu đã bùng nổ trong thập kỷ qua và tiếp tục mở rộng. Nhưng đó cũng là trường hợp của các tập đoàn lớn, thường là làm kho dữ liệu, phân tích thông tin kinh doanh trong một thời gian dài. Từ lâu chúng ta đã từng có được các DBA chuyên dụng cho các dự án đó; chúng tôi không bao giờ có được một DBA chuyên dụng nữa. Chúng tôi chịu trách nhiệm thiết kế cơ sở dữ liệu, điều này tốt, nếu đó là người có kinh nghiệm. Nhưng nói chung, các DBA là nhà phát triển ứng dụng, họ thường đảm nhận vai trò đó như một phần công việc bán thời gian, họ không được đào tạo chính thức về nó và một lần nữa, họ đang thiết kế nó cho mục tiêu cuối cùng của họ, họ không thiết kế nó cho hiệu quả.
Và có rất nhiều sự khác biệt giữa thiết kế và phát triển, so với triển khai và quản lý. Vì vậy, chúng ta có những đồng xu khôn ngoan, ngốc nghếch, có một con heo nhỏ ở đó, bỏ qua việc có được các kỹ năng và nguồn lực cần thiết trong các dự án. Nghĩ rằng tất cả mọi người đến từ Hồi Revenge of the Nerds, hình ảnh nhỏ của tôi ở đó. Bây giờ, theo như những gì mọi người cần, vì vậy chúng tôi có việc sử dụng mở rộng cơ sở dữ liệu và dữ liệu trong SQL. Chúng tôi đã hạn chế số lượng DBA - những người có kỹ năng và chuyên gia trong các tình huống điều chỉnh và thiết kế và quản lý và triển khai này. Và chúng tôi ngày càng có nhiều DBA bán thời gian hoặc tình cờ, những người chưa được đào tạo chính thức.
Vì vậy, một số điều khác cũng đang đi vào vấn đề thực tế là các cơ sở dữ liệu này cũng không được điều chỉnh, hoặc được quản lý? Trước hết, nhiều người cho rằng bản thân hệ thống cơ sở dữ liệu có đủ công cụ để tự quản lý. Giờ đây, các công cụ ngày càng dễ thực hiện hơn - thiết kế và phát triển - nhưng điều đó khác với việc thiết kế tốt, và quản lý tốt, lập kế hoạch năng lực, giám sát, v.v. để triển khai. Vì vậy, trước hết, mọi người cho rằng họ có tất cả các công cụ họ cần. Thứ hai, nếu bạn là một DBA bán thời gian hoặc tình cờ, bạn không biết những gì bạn không biết.
Tôi đoán rằng tôi đã quên một số cụm từ ở đó, vì vậy nhiều lần họ không hiểu những gì họ thậm chí cần xem trong thiết kế hoặc khi họ đang quản lý hoặc vận hành cơ sở dữ liệu. Nếu đó không phải là nghề nghiệp của bạn, thì bạn sẽ không hiểu những gì bạn cần làm. Thứ ba, là SQL là một công cụ đi tới, vì vậy Robin đã nói về SQL và đôi khi SQL được xây dựng kém như thế nào, hoặc thường được xây dựng. Và cũng là một trong những thú cưng của tôi trong kho dữ liệu BI, di chuyển dữ liệu, không gian kỹ thuật dữ liệu là thay vì sử dụng các công cụ, mọi người có xu hướng viết mã SQL, các thủ tục được lưu trữ, ngay cả khi họ đang sử dụng một công cụ tích hợp dữ liệu đắt tiền hoặc một công cụ BI đắt tiền, họ thường thực sự sử dụng nó chỉ để chạy các thủ tục được lưu trữ. Vì vậy, tầm quan trọng của việc hiểu thiết kế cơ sở dữ liệu, về xây dựng SQL, ngày càng trở nên quan trọng hơn.
Và cuối cùng là cách tiếp cận silo này, trong đó chúng ta có những người riêng lẻ nhìn vào cơ sở dữ liệu cá nhân. Họ không nhìn vào cách các ứng dụng hoạt động và tương tác với nhau. Và họ cũng thực sự thường nhìn vào cơ sở dữ liệu so với các ứng dụng mà họ sử dụng chúng cho. Vì vậy, khối lượng công việc mà bạn nhận được trên cơ sở dữ liệu là rất quan trọng trong thiết kế, rất quan trọng trong việc điều chỉnh nó, rất quan trọng trong việc cố gắng tìm ra cách lập kế hoạch cho công suất, v.v. Vì vậy, nhìn vào rừng từ cây, mọi người đang ở trong đám cỏ dại, nhìn vào các bảng và cơ sở dữ liệu riêng lẻ và không nhìn vào sự tương tác tổng thể của các ứng dụng này trong khối lượng công việc.
Cuối cùng, mọi người cần nhìn vào các lĩnh vực chính mà họ cần xem xét. Khi họ dự định quản lý cơ sở dữ liệu, trước tiên họ cần nghĩ về, phát triển một số số liệu hiệu suất tập trung vào ứng dụng, vì vậy họ cần xem xét không chỉ bảng này được cấu trúc như thế nào, nó được mô hình hóa cụ thể như thế nào, mà nó được sử dụng như thế nào? Vì vậy, nếu bạn có ứng dụng doanh nghiệp do quản lý chuỗi cung ứng, nếu bạn nhận đơn đặt hàng trên web, nếu bạn đang làm BI - bất cứ điều gì bạn đang làm - bạn cần xem ai đang sử dụng nó, họ đang như thế nào sử dụng nó, khối lượng dữ liệu là gì, khi nào nó sẽ xảy ra. Điều bạn thực sự đang cố gắng tìm kiếm là thời gian chờ đợi, bởi vì dù thế nào, tất cả các ứng dụng đều được đánh giá bằng cách mất bao lâu để hoàn thành công việc, cho dù đó là người hay chỉ là trao đổi dữ liệu giữa các ứng dụng hoặc bộ xử lý. Và những vướng mắc là gì? Vì vậy, thông thường khi bạn đang cố gắng gỡ lỗi các vấn đề, tất nhiên, bạn thực sự đang cố gắng xem xét các nút thắt thực sự là gì - không nhất thiết là làm thế nào để điều chỉnh mọi thứ, nhưng làm thế nào để bạn thoát khỏi và tăng hiệu suất trong thời gian chờ đợi và thông lượng - bất cứ điều gì bạn cần xem xét.
Và bạn thực sự cần tách biệt việc thu thập dữ liệu, các giao dịch, các khía cạnh chuyển đổi trong cơ sở dữ liệu cùng với các phân tích. Mỗi trong số chúng có các mẫu thiết kế khác nhau, mỗi trong số chúng có các mẫu sử dụng khác nhau và mỗi trong số chúng cần được điều chỉnh khác nhau. Vì vậy, bạn cần suy nghĩ về cách sử dụng dữ liệu này, khi nó được sử dụng, nó được sử dụng để làm gì và tìm ra số liệu hiệu suất và những điều quan trọng bạn muốn phân tích liên quan đến việc sử dụng đó. Bây giờ, khi bạn đang xem giám sát hiệu suất, bạn muốn xem xét chính các hoạt động của cơ sở dữ liệu; bạn muốn xem xét cả cấu trúc dữ liệu, vì vậy các chỉ mục, phân vùng và các khía cạnh vật lý khác của cơ sở dữ liệu, thậm chí cả cấu trúc của cơ sở dữ liệu - dù là mô hình ER hay mô hình thứ nguyên, tuy nhiên nó có cấu trúc - tất cả những điều đó có ảnh hưởng đến hiệu suất, đặc biệt là trong các bối cảnh khác nhau của phân tích thu thập dữ liệu và các biến đổi xảy ra.
Và như Robin đã đề cập về phía SQL, xem xét SQL đang được chạy bởi các ứng dụng khác nhau trên các cơ sở dữ liệu này và điều chỉnh nó là rất quan trọng. Và nhìn vào khối lượng công việc ứng dụng tổng thể, và môi trường cơ sở hạ tầng mà các cơ sở dữ liệu và ứng dụng này chạy. Vì vậy, rằng các mạng, máy chủ, đám mây - bất cứ thứ gì chúng đang chạy - cũng xem xét tác động của các ứng dụng và cơ sở dữ liệu này trong bối cảnh đó, tất cả đều có khả năng điều chỉnh cơ sở dữ liệu.
Và cuối cùng, khi bạn đang xem các công cụ, bạn muốn có thể xem xét ba loại phân tích khác nhau liên quan đến điều đó. Bạn muốn xem xét phân tích mô tả: những gì đang xảy ra và ở đâu, liên quan đến cơ sở dữ liệu và hiệu suất ứng dụng. Bạn muốn có khả năng phân tích chẩn đoán để tìm ra không chỉ những gì đang xảy ra mà tại sao nó lại xảy ra, những nút thắt ở đâu, những vấn đề ở đâu, những gì đang chạy tốt, những gì không chạy tốt? Nhưng có thể phân tích và đi sâu vào các lĩnh vực có vấn đề để giải quyết những vấn đề đó, cho thiết kế hoặc bất cứ điều gì bạn cần làm.
Và cuối cùng, loại phân tích tích cực hoặc chủ động nhất là thực sự thực hiện một số phân tích dự đoán, mô hình phân tích dự đoán, bất cứ điều gì. Chúng tôi biết rằng cơ sở dữ liệu và các ứng dụng hoạt động trong bối cảnh này, nếu chúng tôi tăng dung lượng, nếu chúng tôi có được nhiều người dùng hơn, nếu chúng tôi làm được nhiều thông lượng hơn, bất cứ điều gì chúng tôi đang làm, có thể dự đoán những gì, làm thế nào và ở đâu tác động đến cơ sở dữ liệu, các ứng dụng, cho phép chúng ta lập kế hoạch và tìm ra sự chủ động, nơi tắc nghẽn, thời gian chờ đợi có thể bị ảnh hưởng và những gì chúng ta cần làm để khắc phục mọi thứ. Vì vậy, chúng tôi muốn có các công cụ có khả năng thực hiện các số liệu hiệu suất, theo dõi hiệu suất, như trong ba loại phân tích này. Và đó là tổng quan của tôi.
Eric Kavanagh: Được rồi, hãy để tôi đưa nó ra - đó là hai bài thuyết trình tuyệt vời - nhân tiện - hãy để tôi đưa nó cho Bullett Manale để đưa nó từ đó. Và mọi người, đừng quên hỏi những câu hỏi hay; chúng tôi có một số nội dung tốt Mang nó đi, Bullett.
Bullett Manale: Nghe hay đấy. Cảm ơn, Eric. Vì vậy, rất nhiều những gì Rick nói và Robin nói, rõ ràng tôi đồng ý với 100%. Tôi sẽ nói rằng tôi đã kéo slide này lên, vì tôi nghĩ nó phù hợp, tôi không biết với những người hâm mộ của nhóm A-Team-hồi hồi thập niên 80, John Hannibal Smith luôn nói rằng anh ấy luôn luôn nói, tôi rất thích nó khi một kế hoạch kết hợp với nhau, và tôi nghĩ rằng khi bạn nói về đặc biệt là SQL Server, nơi chúng tôi đang tập trung, đó là sản phẩm mà chúng ta sẽ nói đến hôm nay, Trình quản lý chẩn đoán SQL, đó chắc chắn là một trong những điều mà bạn phải có; bạn phải có khả năng tận dụng dữ liệu mà bạn có và có thể đưa ra quyết định từ dữ liệu đó và trong một số trường hợp, bạn không tìm kiếm quyết định; bạn đang tìm kiếm thứ gì đó để nói với bạn khi nào đó sẽ cạn kiệt tài nguyên, khi bạn sắp hết tài nguyên, khi bạn sắp có một nút cổ chai, những thứ đó.
Nó không chỉ là về việc theo dõi một số liệu cụ thể. Vì vậy, với Trình quản lý chẩn đoán, một trong những điều nó làm rất tốt sẽ giúp bạn về mặt dự báo và hiểu cụ thể về khối lượng công việc và chúng ta sẽ nói về rất nhiều điều đó ngày hôm nay. Công cụ này hướng đến người quản lý dữ liệu, DBA hoặc DBA diễn xuất, vì vậy rất nhiều điều mà Rick đã đề cập, DBA diễn xuất là rất đúng. Trong rất nhiều trường hợp, nếu bạn không phải là một DBA, sẽ có rất nhiều dấu hỏi mà bạn sẽ có khi đến lúc quản lý môi trường SQL, những điều bạn không biết. Và vì vậy, bạn đang tìm kiếm một cái gì đó để giúp bạn, đưa bạn qua quá trình đó, và cũng giáo dục bạn trong quá trình đó. Và vì vậy, điều quan trọng là công cụ bạn sử dụng cho những loại quyết định đó sẽ cung cấp cho bạn cái nhìn sâu sắc về lý do tại sao những quyết định đó được đưa ra, nó không chỉ nói với bạn, mà Hey, hãy làm điều này.
Bởi vì tôi là DBA diễn xuất, cuối cùng tôi có thể là DBA toàn diện với chuyên môn và kiến thức thực tế để hỗ trợ cho danh hiệu đó. Vì vậy, điều đó nói rằng, khi chúng ta nói về việc trở thành một quản trị viên cơ sở dữ liệu - tôi luôn thể hiện slide này trước tiên, bởi vì DBA có một số vai trò khác nhau và tùy thuộc vào tổ chức mà bạn sẽ tham gia, chúng sẽ thay đổi từ nơi này sang nơi khác - nhưng thông thường, bạn sẽ luôn chịu trách nhiệm về việc lưu trữ của bạn, kế hoạch lưu trữ đó và hiểu về dự đoán, tôi nên nói, bạn sẽ đi bao nhiêu không gian cần, cho dù đó là cho bản sao lưu của bạn, hoặc cho dù đó là cho cơ sở dữ liệu. Bạn sẽ cần phải hiểu và đánh giá điều đó.
Ngoài ra, bạn sẽ cần có khả năng hiểu và tối ưu hóa mọi thứ trên cơ sở cần thiết và khi bạn thực hiện giám sát môi trường, rõ ràng bạn cần thay đổi khi cần dựa trên những thứ cần thiết thay đổi trong chính môi trường Vì vậy, những thứ như số lượng người dùng, những thứ như sự phổ biến của các ứng dụng, tính thời vụ của cơ sở dữ liệu, tất cả nên được xem xét khi bạn thực hiện dự báo của mình. Và sau đó, rõ ràng nhìn vào những thứ khác về khả năng cung cấp các báo cáo và thông tin cần thiết vì nó liên quan đến việc đưa ra các quyết định đó. Trong rất nhiều trường hợp có nghĩa là thực hiện phân tích so sánh; điều đó có nghĩa là có thể xem xét cụ thể một số liệu cụ thể và hiểu giá trị của số liệu đó theo thời gian là gì, để bạn có thể dự đoán nơi nó sẽ tiến lên.
Vì vậy, rất nhiều công cụ Trình quản lý chẩn đoán thực hiện có những khả năng đó và mọi người sử dụng nó hàng ngày để có thể thực hiện những việc như dự báo và tôi đã đưa ra định nghĩa về lập kế hoạch năng lực. Và đó là một định nghĩa khá rộng và thực sự khá mơ hồ, đó chỉ là quá trình xác định năng lực sản xuất cần thiết của một tổ chức để đáp ứng nhu cầu thay đổi cho các sản phẩm của mình, và cuối cùng, đó thực sự là tất cả về nó: về việc có thể lấy thông tin mà bạn có cách này hay cách khác và lấy thông tin đó và đưa ra quyết định để giúp bạn tiến lên khi bạn tiến bộ trong vòng đời của cơ sở dữ liệu. Và vì vậy, các loại điều là lý do tại sao mọi người cần phải làm điều này rõ ràng là đầu tiên và quan trọng nhất, trong hầu hết các trường hợp, để tiết kiệm tiền. Các doanh nghiệp, rõ ràng, đó là mục tiêu chính của họ là kiếm tiền và tiết kiệm tiền. Nhưng trong quá trình đó, điều đó cũng có nghĩa là có thể chắc chắn rằng thời gian chết của bạn, không có thời gian chết. Và có thể chắc chắn rằng bạn giảm thiểu bất kỳ cơ hội ngừng hoạt động nào xảy ra, vì vậy, giữ cho nó không xảy ra để bắt đầu, nói cách khác, không chờ đợi nó xảy ra và sau đó phản ứng với nó.
Cũng như có thể tăng tổng năng suất của người dùng của bạn, làm cho họ hiệu quả hơn để bạn có thể hoàn thành công việc nhiều hơn rõ ràng là chìa khóa ở đây, vì vậy đây là những loại mà DBA hoặc ai đó tham gia dự báo hoặc năng lực lập kế hoạch sẽ phải có khả năng lội qua thông tin để có thể đưa ra những quyết định đó. Và sau đó, về tổng thể, điều này rõ ràng sẽ giúp bạn loại bỏ lãng phí, không chỉ lãng phí về tiền bạc, mà còn về thời gian và về mặt nói chung chỉ là các tài nguyên có thể được sử dụng cho những thứ khác, có thể. Vì vậy, có thể loại bỏ chất thải đó để bạn không có chi phí cơ hội gắn liền với chất thải.
Vì vậy, với những gì đã nói, các loại câu hỏi mà chúng tôi nhận được, cụ thể cho người đó là một DBA là gì? Khi nào tôi sẽ hết không gian? Đó là một vấn đề lớn, không chỉ tôi đang tiêu tốn bao nhiêu không gian, mà là khi nào tôi sẽ hết, dựa trên các xu hướng và lịch sử trong quá khứ? Điều tương tự với các phiên bản thực tế của SQL, cơ sở dữ liệu, máy chủ nào tôi có thể hợp nhất? Tôi sẽ đưa một số vào máy ảo, điều gì có ý nghĩa về mặt cơ sở dữ liệu nào tôi sẽ hợp nhất và họ nên cư trú ở trường hợp nào của SQL? Tất cả những loại câu hỏi cần phải có thể được trả lời. Bởi vì trong hầu hết các trường hợp, nếu bạn là DBA hoặc DBA hoạt động, bạn sẽ củng cố nó đôi khi trong sự nghiệp của mình. Trong rất nhiều trường hợp bạn sẽ làm điều đó trên cơ sở liên tục. Vì vậy, bạn cần có khả năng đưa ra những quyết định đó một cách nhanh chóng, không chơi các trò chơi đoán khi nói đến điều đó.
Chúng tôi đã nói về những vướng mắc và nơi chúng sẽ xảy ra tiếp theo, có thể dự đoán rằng, một lần nữa, thay vì chờ đợi chúng xảy ra. Vì vậy, rõ ràng tất cả những điều chúng ta đang nói đến, có ý nghĩa theo nghĩa là bạn đang dựa vào dữ liệu lịch sử, trong hầu hết các trường hợp, để có thể tạo ra các đề xuất này hoặc trong một số trường hợp có thể tự mình đưa ra quyết định, để có thể đưa ra những câu trả lời này. Nhưng nó làm tôi nhớ đến, khi bạn nghe quảng cáo trên đài phát thanh cho ai đó bán chứng khoán hoặc đại loại như thế, thì hiệu suất trong quá khứ không phải là biểu hiện của kết quả trong tương lai. Và điều tương tự cũng đúng ở đây. Bạn sẽ có những tình huống trong đó những dự báo và những phân tích này có thể không đúng 100%. Nhưng nếu bạn đang đối phó với những điều đã xảy ra trong quá khứ và đã biết, và có thể thực hiện và thực hiện điều gì đó nếu mà với rất nhiều loại câu hỏi này, bạn sẽ gặp phải, rất có giá trị và nó sẽ giúp bạn tiến xa hơn là chơi trò chơi đoán.
Vì vậy, những loại câu hỏi này rõ ràng là chúng sẽ xuất hiện, vì vậy cách chúng tôi xử lý rất nhiều câu hỏi này với Trình quản lý chẩn đoán, trước hết chúng tôi có khả năng dự báo, cũng có thể thực hiện điều này tại cơ sở dữ liệu, tại bàn. như ổ đĩa hoặc âm lượng. Có thể nói, không chỉ có thể nói, Hey Hey, chúng ta còn đầy không gian, mà còn sáu tháng nữa, hai năm kể từ bây giờ, năm năm nữa, nếu tôi dự trù ngân sách cho điều đó, tôi sẽ lái bao nhiêu không gian Cần ngân sách cho? Đó là những câu hỏi tôi sẽ phải hỏi, và tôi sẽ cần có thể sử dụng một số phương pháp để làm điều đó hơn là đoán và đưa ngón tay lên không trung và chờ xem gió thổi theo hướng nào, Thật không may, rất nhiều lần, thật không may, cách mà rất nhiều những quyết định này được đưa ra.
Ngoài ra, việc có thể - có vẻ như slide của tôi bị cắt ở đó một chút - nhưng có thể cung cấp một số trợ giúp dưới dạng các khuyến nghị. Vì vậy, đó là một điều để có thể hiển thị cho bạn bảng điều khiển có đầy đủ các số liệu và có thể nói, OK OK, đây là tất cả các số liệu và họ đang ở đâu, nhưng sau đó có thể thực hiện một số hoặc có một số hiểu biết về Phải làm gì, dựa trên đó là một bước nhảy vọt khác. Và trong một số trường hợp, mọi người được giáo dục đủ vai trò của DBA để có thể đưa ra những quyết định đó. Và vì vậy, chúng tôi có một số cơ chế trong công cụ sẽ giúp với điều đó, chúng tôi sẽ chỉ cho bạn thấy trong một giây. Nhưng việc có thể chỉ ra không chỉ đề xuất là gì, mà còn cung cấp một số thông tin chi tiết về lý do tại sao khuyến nghị đó được đưa ra và trên hết, trong một số trường hợp, có thể thực sự đưa ra một kịch bản tự động hóa khắc phục vấn đề đó là lý tưởng là tốt.
Chuyển sang phần tiếp theo ở đây, mà chúng ta sẽ thấy, nói chung chỉ là hiểu về mức độ bình thường là điều bình thường. Tôi không thể nói cho bạn biết những gì không bình thường nếu tôi không biết bình thường là gì. Và vì vậy, có một số cách để đo lường đó là chìa khóa và bạn đã có thể xem xét nhiều loại lĩnh vực, ví dụ - hoặc tôi nên nói khung thời gian - các nhóm máy chủ khác nhau, có thể thực hiện điều này một cách linh hoạt, từ góc độ cảnh báo, nói cách khác, vào giữa đêm, trong cửa sổ bảo trì của tôi, tôi hy vọng CPU của tôi sẽ chạy ở mức 80 phần trăm dựa trên tất cả các bảo trì đang diễn ra. Vì vậy, tôi có thể muốn tăng ngưỡng của mình cao hơn, trong các khung thời gian đó so với có thể vào giữa ngày, khi tôi không có nhiều hoạt động.
Đó là một số thứ rõ ràng sẽ là môi trường, nhưng những thứ bạn có thể áp dụng cho những gì đang được quản lý, để có thể giúp bạn quản lý môi trường đó hiệu quả hơn và làm cho nó dễ dàng hơn. Rõ ràng, khu vực khác, có thể chỉ cung cấp tổng thể các báo cáo và thông tin để có thể trả lời các loại câu hỏi này nếu câu hỏi của Martin. Nếu tôi vừa thực hiện thay đổi cho môi trường của mình, tôi muốn hiểu tác động đó là gì, để tôi có thể áp dụng thay đổi đó cho các trường hợp khác hoặc cơ sở dữ liệu khác trong môi trường của mình. Tôi muốn có thể có một số thông tin hoặc một số đạn dược để có thể tạo ra sự thay đổi đó với sự an tâm và biết rằng đó sẽ là một thay đổi tốt. Vì vậy, để có thể thực hiện báo cáo so sánh đó, có thể xếp hạng các phiên bản SQL của tôi, có thể xếp hạng các cơ sở dữ liệu của tôi với nhau, có thể nói, đó là người tiêu dùng CPU cao nhất của tôi? điều khoản của sự chờ đợi và những thứ như vậy? Vì vậy, rất nhiều thông tin sẽ có sẵn với công cụ này.
Và sau đó, cuối cùng nhưng không kém phần quan trọng, chỉ là một khả năng tổng thể mà bạn cần một công cụ có thể xử lý mọi tình huống xảy ra theo cách của bạn, và ý tôi là, nếu bạn có một môi trường rộng lớn với rất nhiều trường hợp, có lẽ bạn sẽ gặp phải tình huống cần rút các số liệu mà theo truyền thống không phải là số liệu mà DBA muốn theo dõi trong một số trường hợp, tùy thuộc vào tình huống cụ thể đó. Vì vậy, có một công cụ mà bạn có thể, có thể mở rộng, để có thể thêm các số liệu bổ sung và có thể sử dụng các số liệu đó theo cùng một hình thức và thời trang mà bạn sẽ sử dụng chúng nếu bạn đang sử dụng ngoài hộp số liệu, ví dụ. Vì vậy, việc có thể chạy báo cáo, có thể cảnh báo, điều cơ bản - tất cả những điều chúng ta đang nói đến - cũng là một phần quan trọng để có thể thực hiện dự báo này và đưa ra câu trả lời mà bạn đang tìm kiếm có thể đưa ra những quyết định, tiến về phía trước.
Bây giờ cách Trình quản lý chẩn đoán thực hiện việc này, chúng tôi có một dịch vụ tập trung, một nhóm dịch vụ chạy, thu thập dữ liệu theo các phiên bản 2000 đến 2016. Và sau đó, những gì chúng tôi làm là chúng tôi lấy dữ liệu đó và chúng tôi đưa dữ liệu đó vào một kho lưu trữ trung tâm và sau đó chúng tôi sẽ làm gì với dữ liệu đó, rõ ràng, chúng tôi sẽ làm rất nhiều để có thể cung cấp cái nhìn sâu sắc hơn nữa. Bây giờ, ngoài điều đó - và một trong những điều không có ở đây - là chúng tôi cũng có một dịch vụ chạy vào giữa đêm, đó là dịch vụ phân tích dự đoán của chúng tôi, và điều đó có một số giòn giã và nó giúp hiểu và giúp bạn với tư cách là một DBA hoặc DBA hoạt động, để có thể đưa ra các loại khuyến nghị đó, để có thể cung cấp một số cái nhìn sâu sắc về các đường cơ sở.
Vì vậy, những gì tôi muốn làm, và đây chỉ là một ví dụ nhanh về kiến trúc, điều đáng nói ở đây là không có bất kỳ đại lý hoặc dịch vụ nào thực sự ngồi trong các trường hợp mà bạn đang quản lý. Nhưng những gì tôi muốn làm chỉ là thực sự đưa bạn vào ứng dụng ở đây và cung cấp cho bạn bản demo nhanh. Và hãy để tôi đi ra ngoài, và làm cho điều đó xảy ra. Vì vậy, hãy cho tôi biết, tôi nghĩ Eric, bạn có thể thấy điều đó không?
Eric Kavanagh: Tôi hiểu rồi, yeah.
Bullett Manale: OK, vì vậy tôi sẽ đưa bạn qua một số phần khác nhau mà tôi đã nói. Và về cơ bản, hãy bắt đầu với những thứ phù hợp hơn với những thứ bạn cần làm, hoặc đây là một điều gì đó trong thời gian tới trong tương lai và chúng tôi sẽ cung cấp cho bạn cái nhìn sâu sắc xung quanh nó. Và điều này có thể thực sự dự đoán - hoặc tôi nên nói một cách linh hoạt dự đoán - mọi thứ đang diễn ra. Bây giờ, trong trường hợp báo cáo, một trong những điều chúng tôi có trong công cụ là ba báo cáo dự báo khác nhau. Và trong trường hợp, ví dụ, về dự báo cơ sở dữ liệu, những gì tôi có thể sẽ làm trong tình huống có thể dự đoán kích thước của cơ sở dữ liệu trong một khoảng thời gian và tôi sẽ chỉ cho bạn một vài ví dụ về điều đó . Vì vậy, tôi sẽ lấy cơ sở dữ liệu kiểm toán của mình, khá chuyên sâu vào / ra - nó có rất nhiều dữ liệu được gửi đến nó. Chúng ta đã có, hãy xem, chúng ta sẽ làm điều này ở đây, và hãy chọn cơ sở dữ liệu chăm sóc sức khỏe ở đây.
Nhưng vấn đề là, tôi không chỉ nhìn thấy không gian trên đó là gì, tôi có thể nói, Nhìn Nhìn, hãy lấy dữ liệu của năm ngoái - và tôi sẽ tìm hiểu thêm một chút, Tôi thực sự không có dữ liệu trong một năm, tôi có dữ liệu khoảng hai tháng - nhưng, vì tôi đang chọn một tỷ lệ mẫu của các tháng ở đây, tôi sẽ có thể dự đoán hoặc dự đoán về điều này trong trường hợp 36 đơn vị tiếp theo vì tỷ lệ mẫu của chúng tôi được đặt thành tháng - đó là một đơn vị, là một tháng - và sau đó tôi sẽ có thể, sau đó chạy một báo cáo để cho tôi biết về cơ bản chúng tôi sẽ dự đoán sự tăng trưởng trong tương lai của chúng tôi ba cơ sở dữ liệu. Và chúng ta có thể thấy chúng ta có một mức độ khác nhau hoặc phương sai khác nhau, giữa ba cơ sở dữ liệu khác nhau, đặc biệt là lượng dữ liệu họ đang tiêu thụ trong lịch sử.
Chúng ta có thể thấy các điểm dữ liệu ở đây đại diện cho dữ liệu lịch sử và sau đó dòng sẽ cung cấp cho chúng ta dự báo, cùng với các con số để sao lưu dữ liệu đó. Vì vậy, chúng tôi có thể làm điều đó ở cấp độ bảng, chúng tôi có thể làm điều đó ngay cả ở cấp độ ổ đĩa, nơi tôi có thể dự đoán mức độ lớn của ổ đĩa của mình, bao gồm các điểm gắn kết. Chúng tôi có thể dự báo loại thông tin tương tự này, nhưng một lần nữa, tùy thuộc vào tỷ lệ mẫu, sẽ cho phép tôi xác định có bao nhiêu đơn vị và nơi chúng tôi lấy những gì chúng tôi muốn dự báo. Cũng lưu ý rằng chúng ta có các loại dự báo khác nhau. Vì vậy, bạn nhận được rất nhiều lựa chọn và linh hoạt khi đến lúc thực hiện dự báo. Bây giờ, đó là một điều chúng tôi sẽ làm, trong khi thực sự cung cấp cho bạn ngày cụ thể và có thể nói về Hey Hey vào ngày này, đây là nơi chúng tôi dự đoán sự phát triển của dữ liệu của bạn. Tuy nhiên, ngoài ra, chúng tôi có thể cung cấp cho bạn những hiểu biết khác có liên quan đến một số phân tích mà chúng tôi thực hiện trong giờ nghỉ và dịch vụ khi nó chạy. Một số điều nó làm, là nó cố gắng dự đoán những điều có thể sẽ xảy ra, dựa trên lịch sử khi mọi thứ xảy ra trong quá khứ.
Vì vậy, chúng ta có thể thấy ở đây, thực sự, một dự báo đang cung cấp cho chúng ta một cái nhìn sâu sắc về khả năng chúng ta gặp vấn đề trong suốt buổi tối dựa trên những điều đã một lần nữa xảy ra trong quá khứ. Vì vậy, rõ ràng điều này thật tuyệt, đặc biệt nếu tôi không phải là một DBA, tôi có thể xem xét những điều này, nhưng điều tuyệt vời hơn nữa nếu tôi không phải là một DBA, là tab phân tích này. Vì vậy, trước đây, đây là công cụ chúng tôi sẽ giới thiệu và giới thiệu sản phẩm cho mọi người và họ sẽ rất tuyệt. Tôi thấy tất cả những con số này, tôi thấy tất cả mọi thứ, nhưng tôi không biết phải làm gì (cười) Vì đó là kết quả của điều đó. Và đó là những gì chúng tôi có ở đây, là cách tốt hơn để bạn có thể hiểu, nếu tôi sẽ hành động để giúp thực hiện, nếu tôi sẽ hành động để thậm chí giúp đỡ với sức khỏe của môi trường của tôi, có thể có cách cung cấp các khuyến nghị đó, cũng như các mẹo hữu ích trong thông tin để tìm hiểu thêm về các đề xuất đó và thực sự có các liên kết bên ngoài với một số dữ liệu đó, sẽ cho tôi thấy và đưa tôi đến những lý do tại sao những khuyến nghị này được thực hiện.
Và trong nhiều trường hợp, việc có thể cung cấp một kịch bản sẽ tự động hóa, như tôi đã nói, việc khắc phục các vấn đề này. Bây giờ, một phần của những gì chúng tôi đang làm ở đây với phân tích này - và tôi sẽ chỉ cho bạn khi tôi đi vào để định cấu hình các thuộc tính của trường hợp này và tôi đi đến phần cấu hình phân tích - chúng tôi có rất nhiều danh mục khác nhau được liệt kê ở đây, và một phần trong đó, chúng tôi có tối ưu hóa chỉ mục và tối ưu hóa truy vấn. Vì vậy, chúng tôi đang đánh giá không chỉ bản thân các số liệu và những thứ tương tự, mà cả những thứ như khối lượng công việc và chỉ mục. Trong trường hợp ở đây, chúng tôi thực sự sẽ thực hiện một số phân tích chỉ số giả thuyết bổ sung. Vì vậy, đó là một trong những tình huống mà tôi không muốn, trong nhiều trường hợp, tôi không muốn thêm chỉ mục nếu tôi không cần. Nhưng tại một thời điểm nào đó, có một điểm bùng phát, theo tôi nói, thì Vâng, bảng đang có kích thước hoặc các loại truy vấn đang chạy trong khối lượng công việc có ý nghĩa ngay bây giờ để thêm chỉ mục. Nhưng điều đó sẽ không có ý nghĩa gì trong sáu tuần trước. Vì vậy, điều này cho phép bạn có được sự hiểu biết sâu sắc về những điều có thể, như tôi đã nói, cải thiện hiệu suất dựa trên những gì xảy ra trong môi trường, những gì xảy ra trong khối lượng công việc và làm những việc đó
Và vì vậy, bạn nhận được rất nhiều thông tin tốt ở đây, cũng như khả năng tối ưu hóa những điều này một cách tự động. Vì vậy, đó là một lĩnh vực khác mà chúng tôi có thể giúp đỡ, theo những gì chúng tôi gọi là phân tích dự đoán. Bây giờ, ngoài điều đó, tôi nên nói, chúng tôi cũng có những lĩnh vực khác mà tôi nghĩ chỉ nói chung là cho vay để giúp bạn đưa ra quyết định. Và khi chúng ta nói về việc đưa ra quyết định, một lần nữa, có thể nhìn vào dữ liệu lịch sử, cung cấp một số hiểu biết để đưa chúng ta đến nơi chúng ta cần để cải thiện hiệu suất đó.
Bây giờ, một trong những điều chúng ta có thể làm là chúng ta có một trình hiển thị cơ sở cho phép chúng ta chọn lọc một cách chọn lọc bất kỳ số liệu nào chúng ta muốn - và hãy để tôi tìm một số liệu tốt ở đây - Tôi sẽ sử dụng CPU SQL, nhưng vấn đề là bạn có thể quay lại tuy nhiên nhiều tuần để vẽ những bức tranh này để bạn thấy khi nào ngoại lệ của bạn, để xem nói chung nói rằng giá trị đó nằm trong khoảng thời gian mà chúng tôi đã thu thập dữ liệu. Và sau đó, ngoài ra, bạn cũng sẽ nhận thấy rằng khi chúng ta đi ra ngoài thực tế, chúng ta có khả năng định cấu hình các đường cơ sở của chúng ta. Và các đường cơ sở là một phần thực sự quan trọng về khả năng tự động hóa mọi thứ cũng như có thể được thông báo về mọi thứ. Và thách thức, như hầu hết các DBA sẽ nói với bạn, đó là môi trường của bạn không phải lúc nào cũng chạy như vậy, trong suốt cả ngày, so với buổi tối và không có gì như chúng tôi đã đề cập trước đó trong ví dụ về thời gian bảo trì, khi chúng ta có mức CPU cao hoặc bất cứ điều gì có thể xảy ra.
Vì vậy, trong trường hợp ở đây, với các đường cơ sở thực tế này, chúng ta có thể có nhiều đường cơ sở, vì vậy tôi có thể có một đường cơ sở, ví dụ, đó là trong giờ bảo trì của tôi. Nhưng tôi có thể dễ dàng tạo ra một đường cơ sở cho giờ sản xuất của mình. Và quan điểm của việc đó là khi chúng ta đi vào một phiên bản của SQL và chúng ta thực sự có nhiều đường cơ sở này, thì chúng ta sẽ có thể dự đoán và có thể thực hiện một số loại tự động hóa, một số loại khắc phục hoặc chỉ cảnh báo nói chung, khác nhau cụ thể cho các cửa sổ thời gian. Vì vậy, một trong những điều bạn sẽ thấy ở đây, là những đường cơ sở mà chúng tôi tạo ra đang sử dụng dữ liệu lịch sử để cung cấp phân tích đó, nhưng quan trọng hơn, tôi có thể thay đổi các ngưỡng này một cách tĩnh, nhưng tôi cũng có thể tự động hóa các ngưỡng này một cách linh hoạt. Vì vậy, như cửa sổ bảo trì, hay tôi nên nói là cửa sổ cơ sở bảo trì xuất hiện, các ngưỡng này sẽ tự động chuyển cụ thể sang các tải mà tôi gặp phải trong thời gian đó, so với có thể vào giữa ngày khi tải của tôi không nhiều, khi khối lượng công việc không ảnh hưởng nhiều.
Vì vậy, đó là điều khác cần ghi nhớ, về cơ bản. Rõ ràng những điều này sẽ thực sự hữu ích cho bạn, về mặt cũng hiểu điều gì là bình thường và cũng có thể hiểu, tham gia khi bạn sắp hết tài nguyên. Bây giờ, một thứ khác mà chúng ta có trong công cụ, đó là sẽ giúp bạn đưa ra quyết định, ngoài ra còn có cơ sở và có thể thiết lập cảnh báo xung quanh các đường cơ sở đó và ngưỡng mà bạn tạo ra một cách linh hoạt, như tôi đã nói trước đó, chỉ có thể chạy toàn bộ vô số báo cáo giúp tôi trả lời các câu hỏi về những gì đang xảy ra.
Vì vậy, ví dụ, nếu tôi có 150 trường hợp tôi đang quản lý - trong trường hợp của tôi thì không, vì vậy chúng tôi phải chơi trò chơi giả vờ ở đây - nhưng nếu tôi có tất cả các trường hợp sản xuất của mình và tôi cần phải hiểu đâu là Nói cách khác, lĩnh vực mà tôi cần chú ý, nói cách khác, nếu tôi chỉ có một khoảng thời gian giới hạn để thực hiện một số loại quản trị để cải thiện hiệu suất, tôi muốn tập trung vào các lĩnh vực chính. Và như vậy, với điều đó, tôi có thể nói, dựa trên môi trường đó, xếp hạng các trường hợp của tôi với nhau và đưa tôi xếp hạng đó theo đường ống tranh chấp. Vì vậy, liệu đó có phải là sử dụng đĩa, sử dụng bộ nhớ, cho dù đó là chờ đợi, cho dù đó là thời gian phản hồi, tôi có thể tương quan - hoặc tôi nên nói thứ hạng - những trường hợp đó với nhau. Rõ ràng là ví dụ đứng đầu mỗi danh sách, nếu đó là cùng một ví dụ, đó có lẽ là điều tôi thực sự muốn tập trung vào, bởi vì rõ ràng nó lại một lần nữa đứng đầu danh sách.
Vì vậy, bạn có rất nhiều báo cáo trong công cụ giúp bạn về mặt xếp hạng môi trường ở cấp độ cá thể; bạn cũng có thể làm điều này ở cấp cơ sở dữ liệu, nơi tôi có thể xếp hạng cơ sở dữ liệu của mình với nhau. Đặc biệt là các ngưỡng và khu vực mà tôi có thể đặt, tôi thậm chí có thể thiết lập các ký tự đại diện ở đây nếu tôi muốn, chỉ tập trung vào các cơ sở dữ liệu cụ thể, nhưng vấn đề là tôi có thể so sánh các cơ sở dữ liệu của mình theo cùng một cách. Ngoài ra, theo như các loại phân tích so sánh khác và loại lớn trong công cụ này, là phân tích cơ bản mà chúng ta có. Vì vậy, nếu bạn cuộn xuống chế độ xem dịch vụ tại đây, bạn sẽ thấy rằng có một báo cáo thống kê cơ bản. Bây giờ báo cáo này rõ ràng sẽ giúp chúng tôi hiểu không chỉ các giá trị số liệu là gì, mà trong một trường hợp cụ thể tôi có thể đi ra ngoài, và đối với bất kỳ số liệu nào trong số này, có thể thực sự xem xét các đường cơ sở cho các số liệu này.
Vì vậy, dù có thể là bao nhiêu phần trăm hay bất cứ điều gì tôi có thể nói ra, thì Hãy xem đường cơ sở cho điều này đã bị phá vỡ trong 30 ngày qua, trong trường hợp đó sẽ cho tôi thấy các giá trị thực so với đường cơ sở và Rõ ràng, tôi có thể đưa ra một số quyết định bằng cách sử dụng thông tin đó, vì vậy đây là một trong những tình huống, nơi nó sẽ phụ thuộc vào câu hỏi đó là gì, mà bạn đang hỏi vào lúc đó. Nhưng điều này rõ ràng sẽ giúp bạn cho rất nhiều câu hỏi. Tôi ước tôi có thể nói rằng chúng tôi đã có một báo cáo thực hiện tất cả, và nó giống như một báo cáo dễ dàng, nơi bạn nhấn và nhấn nút và nó chỉ trả lời cho mọi câu hỏi nếu câu hỏi mà bạn có thể trả lời. Nhưng thực tế là, bạn sẽ có rất nhiều thuộc tính và rất nhiều tùy chọn để có thể lựa chọn trong những lần kéo xuống này để có thể hình thành nên những điều đó nếu những câu hỏi mà bạn đang tìm kiếm. .
Vì vậy, rất nhiều trong số các báo cáo này hướng đến việc có thể trả lời các loại câu hỏi đó. Và vì vậy, điều thực sự quan trọng là các báo cáo này và ngoài ra, tất cả những điều chúng tôi đã trình bày cho bạn trong công cụ, như tôi đã đề cập trước đây, có thể linh hoạt kết hợp các số liệu mới, để được quản lý, thậm chí có thể tạo bộ đếm hoặc truy vấn SQL được tích hợp vào các khoảng thời gian bỏ phiếu của bạn, để có thể giúp tôi trả lời những câu hỏi này, có thể ngoài hộp chúng tôi không lường trước được để theo dõi, bạn có thể thêm nội dung đó. Và sau đó bạn sẽ có thể thực hiện tất cả những điều tương tự tôi vừa trình bày cho bạn: đường cơ sở, chạy báo cáo và tạo báo cáo từ số liệu đó, và có thể trả lời và thực hiện nhiều loại khác nhau mà tôi đang chỉ cho bạn đây.
Bây giờ, ngoài điều đó - và một trong những điều rõ ràng chúng ta gặp phải gần đây là - đầu tiên, đó là, mọi người lật hoặc chuyển sang VM. Và bây giờ chúng ta đã có rất nhiều người đang hướng đến đám mây. Và có rất nhiều câu hỏi được đặt ra xung quanh những loại điều đó. Liệu nó có ý nghĩa đối với tôi để di chuyển lên đám mây? Tôi sẽ tiết kiệm tiền bằng cách di chuyển lên đám mây? Nếu tôi đặt những thứ này lên máy ảo, trên máy chia sẻ tài nguyên, tôi có thể tiết kiệm được bao nhiêu tiền? Những loại câu hỏi, rõ ràng là sẽ được đưa ra là tốt. Vì vậy, rất nhiều thứ cần lưu ý, với Trình quản lý chẩn đoán, chúng ta có thể thêm và lấy từ các môi trường ảo hóa của cả VMware và Hyper-V. Chúng tôi cũng có thể thêm các trường hợp xuất hiện trên đám mây, vì vậy, các môi trường của bạn như Azure DB, hoặc thậm chí RDS, chúng tôi cũng có thể lấy số liệu từ các môi trường đó.
Vì vậy, có rất nhiều tính linh hoạt và rất nhiều khả năng để trả lời những câu hỏi đó vì nó liên quan đến những loại môi trường khác mà chúng ta thấy mọi người hướng đến. Và vẫn còn rất nhiều câu hỏi xung quanh công cụ này, và như chúng ta thấy mọi người hợp nhất những môi trường đó họ sẽ cần để có thể trả lời những câu hỏi đó. Vì vậy, đó là một tổng quan khá tốt, tôi nói, về Trình quản lý chẩn đoán, vì nó liên quan đến chủ đề này. Tôi biết rằng chủ đề về trí tuệ kinh doanh đã xuất hiện và chúng tôi cũng có một công cụ cho trí tuệ kinh doanh mà chúng tôi không nói đến ngày hôm nay, nhưng nó cũng sẽ cung cấp cho bạn cái nhìn sâu sắc về việc trả lời các loại câu hỏi này vì nó liên quan đến bạn hình khối và tất cả các loại khác nhau, là tốt. Nhưng hy vọng rằng đây là một tổng quan tốt, ít nhất là về cách sản phẩm này có thể giúp với việc có thể xây dựng một kế hoạch tốt.
Eric Kavanagh: Được rồi, thứ tốt. Vâng, tôi sẽ ném nó ra cho Rick, nếu anh ta vẫn ở ngoài đó. Rick, có câu hỏi nào từ bạn không?
Rick Sherman: Vâng, vì vậy, lần đầu tiên, điều này thật tuyệt, tôi thích nó. Tôi đặc biệt thích việc mở rộng ra VM và các đám mây. Tôi thấy rất nhiều nhà phát triển ứng dụng nghĩ rằng nếu nó ở trên đám mây thì họ không cần phải điều chỉnh nó. Vì thế-
Bullett Manale: Phải, chúng ta vẫn phải trả tiền cho nó, phải không? Bạn vẫn phải trả tiền cho mọi thứ mà mọi người đang đưa lên đám mây, vì vậy nếu nó hoạt động kém hoặc nếu nó gây ra nhiều chu kỳ CPU, thì bạn sẽ phải trả nhiều tiền hơn, vì vậy, không phải vậy, bạn vẫn cần phải đo công cụ này, hoàn toàn.
Rick Sherman: Vâng, tôi đã thấy rất nhiều thiết kế nghèo nàn trên đám mây. Tôi đã muốn hỏi, liệu sản phẩm này cũng sẽ được sử dụng - Tôi biết bạn đã đề cập đến sản phẩm BI và bạn có hàng tấn sản phẩm khác tương tác với nhau - nhưng bạn có bắt đầu xem hiệu suất SQL, các truy vấn riêng lẻ trong công cụ này không? Hay nó sẽ là những công cụ khác sẽ được sử dụng cho điều đó?
Bullett Manale: Không, điều này sẽ, hoàn toàn. Đó là một trong những điều mà tôi không đề cập đến và ý tôi là, phần truy vấn của nó. Chúng tôi có rất nhiều cách khác nhau để xác định hiệu suất truy vấn, cho dù đó là liên quan đến, cụ thể là chờ đợi như chúng tôi thấy ở chế độ xem này ở đây hoặc liệu có liên quan đến mức tiêu thụ tài nguyên của các truy vấn hay không, có rất nhiều cách chúng tôi có thể phân tích truy vấn hiệu suất. Cho dù đó là thời lượng, CPU, I / O và một lần nữa, chúng ta cũng có thể xem xét khối lượng công việc để cung cấp một số thông tin chi tiết. Chúng tôi có thể cung cấp các đề xuất trong phần phân tích và chúng tôi cũng có phiên bản dựa trên web cung cấp thông tin xung quanh các truy vấn. Vì vậy, tôi có thể nhận được các đề xuất về các chỉ mục bị thiếu và khả năng xem kế hoạch thực hiện và tất cả các loại công cụ đó; đó cũng là một khả năng. Vì vậy, hoàn toàn, chúng ta có thể chẩn đoán truy vấn bảy cách đến Chủ nhật (cười) và có thể cung cấp cái nhìn sâu sắc đó về số lượng thực thi, có thể là tiêu thụ tài nguyên, chờ đợi, thời lượng, tất cả những thứ tốt.
Rick Sherman: OK, tuyệt vời. Và sau đó, những gì tải về các trường hợp với tất cả giám sát này?
Bullett Manale: Đó là một câu hỏi hay. Thách thức với việc trả lời câu hỏi đó là, có phụ thuộc không, nó giống như mọi thứ khác. Rất nhiều những gì công cụ của chúng tôi cung cấp, nó cung cấp tính linh hoạt và một phần của tính linh hoạt đó là bạn có thể nói với nó những gì cần thu thập và những gì không thu thập. Vì vậy, ví dụ, với chính các truy vấn, tôi không phải thu thập thông tin chờ, hoặc tôi có thể. Tôi có thể thu thập thông tin liên quan đến các truy vấn vượt quá thời gian thực hiện. Một ví dụ về điều đó, nếu tôi đi vào màn hình truy vấn cấu hình và tôi muốn nói, thì Hãy để chúng tôi thay đổi giá trị này thành số không, thực tế là về cơ bản, nó làm cho công cụ thu thập mọi truy vấn chạy và thực sự không phải là tinh thần tại sao lại ở đó, nhưng nói chung nếu tôi muốn cung cấp một mẫu dữ liệu đầy đủ cho tất cả các truy vấn, tôi có thể làm điều đó.
Vì vậy, nó rất liên quan đến những gì cài đặt của bạn, nói chung, nằm ngoài hộp. Đó là bất cứ nơi nào từ khoảng 1 trên 3 phần trăm, nhưng có những điều kiện khác sẽ được áp dụng. Nó cũng phụ thuộc vào số lượng truy vấn cổng đang chạy trên môi trường của bạn, phải không? Nó cũng phụ thuộc vào phương pháp thu thập các truy vấn đó và phiên bản SQL nào. Vì vậy, ví dụ, SQL Server 2005, chúng tôi sẽ không thể lấy từ các sự kiện mở rộng, trong khi đó chúng tôi sẽ lấy từ một dấu vết để làm điều đó. Vì vậy, sẽ có một chút khác biệt về cách chúng ta sẽ thu thập dữ liệu đó, nhưng như đã nói, như tôi đã nói, chúng tôi đã loanh quanh tôi đoán từ khoảng năm 2004 với sản phẩm này. Đã từ rất lâu, chúng tôi có hàng ngàn khách hàng, vì vậy điều cuối cùng chúng tôi muốn làm là có một công cụ giám sát hiệu suất gây ra các vấn đề về hiệu suất (cười). Và vì vậy, chúng tôi cố gắng tránh xa điều đó, càng nhiều càng tốt, nhưng nói chung, như vậy, khoảng 1% 3 phần trăm là một quy tắc tốt.
Rick Sherman: OK, và nó khá thấp, thật tuyệt vời.
Eric Kavanagh: Tốt. Robin, có câu hỏi nào từ bạn không?
Robin Bloor: Tôi xin lỗi, tôi đã bị câm. Bạn đã có nhiều khả năng cơ sở dữ liệu và tôi quan tâm đến việc vì sao bạn có thể xem nhiều cơ sở dữ liệu và do đó bạn có thể biết một cơ sở tài nguyên lớn hơn có thể được phân chia giữa các máy ảo khác nhau, v.v. Tôi quan tâm đến cách mọi người thực sự sử dụng nó. Tôi quan tâm đến những gì khách hàng đang làm với điều đó. Bởi vì điều đó đối với tôi, tốt, chắc chắn, khi tôi đang loay hoay với cơ sở dữ liệu, một thứ tôi chưa bao giờ có trong tay. Và tôi sẽ chỉ xem xét một trường hợp theo bất kỳ cách có ý nghĩa tại bất kỳ thời điểm nào. Vì vậy, làm thế nào để mọi người sử dụng này?
Bullett Manale: Nói chung, bạn đang nói chung chỉ là công cụ? Họ đang sử dụng nó như thế nào? Ý tôi là, nói chung, đó là về việc có thể có một điểm trung tâm của sự hiện diện của môi trường. Yên tâm và biết rằng nếu họ nhìn chằm chằm vào màn hình và họ thấy màu xanh lá cây, họ biết mọi thứ đều tốt. Đó là khi sự cố xảy ra và rõ ràng hầu hết các trường hợp theo quan điểm của DBA, rất nhiều lần những sự cố đó xảy ra khi chúng ở phía trước bàn điều khiển, vì vậy có thể được thông báo ngay khi sự cố xảy ra. Nhưng bên cạnh đó, có thể hiểu được khi nào sự cố xảy ra, có thể đi vào trung tâm của thông tin cung cấp cho họ một số bối cảnh về lý do tại sao nó xảy ra. Và vì vậy, tôi nghĩ, phần lớn nhất: chủ động về nó, không phản ứng.
Hầu hết các DBA tôi nói chuyện - và tôi không biết, đó là một tỷ lệ tốt trong số họ - thật không may vẫn thuộc loại môi trường phản ứng; họ chờ đợi một người tiêu dùng tiếp cận họ để nói với họ rằng có một vấn đề. Và vì vậy, chúng tôi thấy rất nhiều người cố gắng thoát khỏi điều đó và tôi nghĩ đó là một phần lớn lý do tại sao mọi người thích công cụ này là nó giúp họ chủ động nhưng nó cũng cung cấp cho họ cái nhìn sâu sắc về những gì đang diễn ra Vấn đề là gì, nhưng trong rất nhiều trường hợp, những gì chúng ta tìm thấy ít nhất - và có thể đó chỉ là các DBA nói với chúng ta điều này - nhưng các DBA, nhận thức luôn là vấn đề của họ, ngay cả khi đó là nhà phát triển ứng dụng đã viết ứng dụng Điều đó không đúng, họ là những người sẽ nhận lỗi, vì họ đã đưa ứng dụng đó vào hệ thống hoặc máy chủ của họ và sau đó khi hiệu suất kém, mọi người chỉ vào DBA nói, Đây là lỗi của bạn.
Vì vậy, công cụ này, rất nhiều lần, sẽ được sử dụng để giúp đỡ trong việc đưa ra trường hợp để DBA nói rằng, Hey Hey, đây là vấn đề nằm ở chỗ và đó không phải là tôi. cải thiện điều này, cho dù nó đang thay đổi các truy vấn hoặc bất cứ điều gì có thể. Trong một số trường hợp, nó sẽ rơi vào nhóm của họ về trách nhiệm của họ, nhưng ít nhất có công cụ để có thể giúp họ hiểu điều đó và biết điều đó, và thực hiện nó một cách kịp thời rõ ràng là cách tiếp cận lý tưởng.
Robin Bloor: Vâng, hầu hết các trang web mà tôi quen thuộc, nhưng đã được một thời gian kể từ khi tôi ở ngoài đó, nhìn vào các trang web đa cơ sở dữ liệu khác nhau, nhưng chủ yếu là những gì tôi từng tìm thấy là sẽ có Các DBA tập trung vào một số ít cơ sở dữ liệu. Và đó sẽ là cơ sở dữ liệu, rằng nếu họ từng đi xuống, đó sẽ là một vấn đề lớn thực sự cho doanh nghiệp, v.v. Và những người khác, họ sẽ chỉ thu thập số liệu thống kê mỗi lần để thấy họ không hết dung lượng và họ sẽ không bao giờ nhìn vào chúng. Và trong khi bạn đang thực hiện bản demo, tôi đã xem xét điều này và tôi đã suy nghĩ tốt, bằng cách này hay cách khác, bạn mở rộng, chỉ bằng cách cung cấp một cái gì đó như thế này cho cơ sở dữ liệu thường, không ai quan tâm quá nhiều, vì chúng có sự tăng trưởng dữ liệu, họ cũng có sự phát triển ứng dụng. Bạn đang mở rộng phạm vi bảo hiểm DBA theo một cách khá ấn tượng. Vì vậy, đó là những gì câu hỏi thực sự là, với một bộ công cụ như thế này, cuối cùng bạn có thể cung cấp dịch vụ DBA cho mọi cơ sở dữ liệu trong mạng công ty không?
Bullett Manale: Chắc chắn, ý tôi là, thách thức là, giống như bạn nói khá hùng hồn, giống như có một số cơ sở dữ liệu mà các DBA quan tâm và sau đó có một số họ không quan tâm nhiều. Và cách mà sản phẩm cụ thể này, cách nó được cấp phép là trên cơ sở từng trường hợp. Vì vậy, tôi đoán là bạn đã nói, một ngưỡng khi mọi người quyết định về Hey Hey, đây không phải là một ví dụ đủ quan trọng mà tôi muốn quản lý nó bằng công cụ này. Đó là những công cụ khác mà chúng tôi làm tôi đoán có nhiều hơn thế, phục vụ cho những trường hợp ít quan trọng hơn của SQL. Một trong số họ sẽ giống như Trình quản lý kho, nơi chúng tôi kiểm tra sức khỏe nhẹ đối với các trường hợp, nhưng ngoài ra, những gì chúng tôi làm là phát hiện ra, vì vậy chúng tôi xác định các trường hợp mới được đưa trực tuyến và sau đó, từ thời điểm đó, với tư cách là một DBA, tôi có thể nói, OK OK, đây là một phiên bản mới của SQL, bây giờ có phải là Express không? Đây có phải là phiên bản miễn phí hay là phiên bản dành cho doanh nghiệp? Đây có lẽ là một câu hỏi tôi muốn tự hỏi mình, nhưng thứ hai, ví dụ đó quan trọng như thế nào đối với tôi? Nếu nó không quan trọng, tôi có thể cho công cụ này ra ngoài và thực hiện nó, chung chung, cái mà tôi gọi là kiểm tra sức khỏe chung theo nghĩa chúng là loại nguyên tố mà tôi quan tâm khi là một DBA: Ổ đĩa có đầy không ? Là máy chủ phản ứng với các vấn đề? Những điều chính, phải không?
Trong khi đó với Trình quản lý chẩn đoán, công cụ tôi vừa trình bày cho bạn, nó sẽ đi xuống mức truy vấn, nó sẽ đi vào đề xuất của các chỉ mục, xem xét kế hoạch thực hiện và tất cả những thứ tốt, trong khi điều này chủ yếu tập trung Ai sở hữu cái gì, tôi sở hữu cái gì và ai chịu trách nhiệm cho nó? Tôi có gói dịch vụ và bản sửa lỗi nóng nào? Và các máy chủ của tôi có chạy với các thành phần chính của những gì tôi sẽ coi là một ví dụ lành mạnh của SQL không? Vì vậy, để trả lời câu hỏi của bạn, có một chút hỗn hợp. Khi chúng ta có người nhìn vào công cụ này, họ thường nhìn vào một tập hợp các trường hợp quan trọng hơn. Điều đó nói rằng, chúng tôi có một số người mua mọi phiên bản mà họ có và quản lý nó, vì vậy nó chỉ phụ thuộc. Nhưng tôi nói với bạn, về tổng thể, chắc chắn có một ngưỡng của những người coi môi trường của họ đủ quan trọng để có một công cụ như thế này để quản lý các trường hợp đó.
Robin Bloor: Được rồi, một câu hỏi khác trước khi tôi đưa nó cho Eric. Ấn tượng người ta có được, chỉ từ việc xem ngành là cơ sở dữ liệu vẫn có một cuộc sống, nhưng tất cả dữ liệu đang đổ vào tất cả các hồ dữ liệu này, v.v. Đó thực sự là sự cường điệu và sự cường điệu không bao giờ phản ánh đúng thực tế, vì vậy tôi quan tâm đến loại thực tế nào bạn đang cảm nhận ngoài kia? Là các cơ sở dữ liệu quan trọng trong một tổ chức, họ có đang trải qua sự tăng trưởng dữ liệu truyền thống, mà tôi từng nghĩ là 10% một năm không? Hay họ đang phát triển hơn thế? Là dữ liệu lớn làm cho các cơ sở dữ liệu bóng? Hình ảnh bạn nhìn thấy là gì?
Bullett Manale: Tôi nghĩ rằng rất nhiều trường hợp chúng ta đang thấy một số dữ liệu được chuyển vào các phân đoạn khác, nơi nó có ý nghĩa hơn, khi có các công nghệ khác đã sẵn sàng. Gần đây, một số công cụ dữ liệu lớn hơn. Nhưng những cơ sở dữ liệu này, tôi có thể nói, thật khó để khái quát trong nhiều trường hợp vì mọi người có một chút khác biệt. Nói chung, mặc dù, tôi thấy một số khác biệt. Tôi thấy, như tôi đã nói, mọi người đang chuyển sang các mô hình đàn hồi trong rất nhiều trường hợp, bởi vì họ muốn phát triển tài nguyên và không quá nhiều trong các lĩnh vực khác. Một số người đang chuyển sang dữ liệu lớn. Nhưng thật khó để cảm nhận, bạn nói, về nhận thức, bởi vì nói chung những người mà tôi đang nói chuyện đều có cơ sở dữ liệu truyền thống và đang sử dụng điều này trên môi trường SQL Server.
Điều đó nói rằng, tôi nói về bản thân SQL, tôi chắc chắn vẫn nghĩ rằng nó đang chiếm thị phần. Và tôi nghĩ rằng có rất nhiều người vẫn đang hướng tới SQL từ những nơi khác như Oracle, bởi vì nó có giá cả phải chăng hơn và dường như rõ ràng, khi các phiên bản SQL trở nên tiên tiến hơn - và bạn đang thấy điều này với những điều gần đây hơn đang diễn ra với SQL, về mặt mã hóa và tất cả các khả năng khác đang biến nó thành một môi trường hoặc một nền tảng cơ sở dữ liệu - đó rõ ràng là nhiệm vụ rất quan trọng có khả năng, tôi đoán vậy. Vì vậy, tôi nghĩ rằng chúng ta cũng đang thấy điều đó. Khi bạn đang nhìn thấy một sự thay đổi, nó vẫn xảy ra. Ý tôi là, nó đã xảy ra cách đây 10 năm, tôi nghĩ nó vẫn xảy ra theo SQL Server, nơi môi trường đang phát triển và thị phần đang tăng lên.
Robin Bloor: OK, Eric, tôi đoán khán giả có một hoặc hai câu hỏi?
Eric Kavanagh: Vâng, hãy để tôi ném nhanh cho bạn. Đó thực sự là một câu hỏi hay. Một trong những người tham dự đang hỏi, công cụ này có cho tôi biết nếu một bảng có thể cần một chỉ mục để tăng tốc truy vấn không? Nếu vậy, bạn có thể đưa ra một ví dụ?
Bullett Manale: Vâng, vì vậy tôi không biết nếu tôi có một chỉ số cụ thể để thêm một chỉ mục, nhưng bạn có thể thấy ở đây, chúng tôi có các đề xuất phân mảnh ở đây. I also just believe we just had and this was part of the Diagnostic Manager offering the web-based version, where it's telling me I have a missing index. And we can view those recommendations and it'll tell us the potential gain of that by indexing that information. The other thing I should just mention is that when we do the recommendations, for many of these, the script will be built for it. That one's not a good example, but you would be able to see, yes, the situations where an index – either a duplicate index, or the addition of an index – would improve performance, and like I said earlier, we do a lot of that through hypothetical index analysis. So, it really helps in terms of understanding the workload, to be able to apply that to the recommendation.
Eric Kavanagh: That's great stuff, and this will give me a good segue to the final comments here. Robin and I and Rick as well, have heard over many years now, there's talk about self-tuning databases. It's a self-tuning database! All I can tell you is: Don't believe them.
Bullett Manale: Don't believe the hype.
Eric Kavanagh: There may be some small little things that get done dynamically, but even that, you might want to check it out and make sure it's not doing something you don't want it to do. So, for quite some time, we're going to need tools like this to understand what's happening at the database level and like Robin said, data lakes are fascinating concepts, but there's probably about as much chance of them taking over as there is of there being a Loch Ness Monster anytime soon. So, I would just say again, the real world has a lot of database technology, we need people, DBAs, to look at this stuff and synthesize it. You can tell, you need to know what you're doing to make this stuff work. But you need the tools to give you the information to know what you're doing. So, bottom line is DBAs are going to be doing just fine.
And big thanks to Bullett Manale and our friends at IDERA. And of course, Rick Sherman and Robin Bloor. We do archive all of these webcasts, so hop online insideanalysis.com or to our partner site www.techopedia.com for more information on all that.
And with that, we'll bid you farewell, folks. Thanks again, we'll talk to you next time. Bảo trọng. Tạm biệt.
