Daftar Isi:
Oleh Staf Techopedia, 5 Oktober 2016
Takeaway: Host Eric Kavanagh membahas pengindeksan database dengan Dr. Robin Bloor, Dez Blanchfield dan Bert Scalzo dari IDERA.
Anda saat ini belum masuk. Silakan masuk atau daftar untuk melihat video.
Mitra Konten Techopedia
Staf Techopedia berafiliasi dengan Bloor Group dan dapat dihubungi menggunakan opsi di sebelah kanan. Untuk info tentang cara kami bekerja dengan mitra industri klik di sini.- Profil
- Situs web
Eric Kavanagh: Hadirin sekalian, halo, dan selamat datang kembali sekali lagi. Ini hari Rabu, pukul empat Timur, dan Anda yang tahu programnya, tahu artinya, saatnya untuk episode lain dari Hot Technologies. Ya memang. Nama saya Eric Kavanagh, saya akan menjadi moderator Anda untuk sesi hari ini: "Indeks Kegilaan: Cara Menghindari Kekacauan Basis Data." Atau seperti yang saya sebutkan di email terakhir untuk keluar, "pertikaian basis data." Istilah panas akhir-akhir ini, "pertikaian." Semua orang melakukannya. Benar-benar ada slide tentang dirimu. Dan cukup tentang saya.
Jadi, seri Teknologi Panas benar-benar dirancang untuk mendefinisikan ruang tertentu, berbeda dengan Ruang Briefing yang hanya satu-satu briefing analis hidup, untuk Hot Tech kami mendapatkan dua analis. Hari ini, itu akan menjadi Dokter Robin Bloor dan ilmuwan data kami Dez Blanchfield. Dan kita berbicara tentang suatu topik yang menurut saya sangat lambang dari apa yang terjadi di pasar saat ini.
Intinya adalah bahwa kita berada di dunia yang penuh kompleksitas akhir-akhir ini. Sungguh, jika Anda berpikir kembali lima belas tahun, atau dua puluh tahun, itu adalah dunia yang sangat berbeda saat itu, terutama yang berkaitan dengan teknologi database. Database dulu cukup sederhana. Hanya ada beberapa dari mereka; kebanyakan dari mereka bersifat relasional. Sekarang, kami memiliki seluruh teknologi database yang lengkap. Secara harfiah skor opsi di atas meja untuk siapa saja yang ingin membangun aplikasi atau melakukan sesuatu dengan data. Semuanya berubah dan itu memengaruhi orang-orang yang mencoba mengelola sistem ini. Kita akan berbicara hari ini dengan Bert Scalzo, yang adalah seorang ahli nyata di lapangan; dia adalah manajemen produk senior untuk IDERA, tentang apa yang dapat Anda lakukan untuk menangani semua data itu. Dengan itu, saya akan menyerahkannya kepada Dokter Robin Bloor untuk membawanya pergi. Robin, lantai milikmu.
Robin Bloor: Oke, terima kasih untuk perkenalan itu. Saya pikir - karena ini adalah masalah dua tangan, saya pikir saya hanya akan berbicara tentang pengoptimalan basis data secara umum sebagai pengantar acara Hot Tech ini. Saya memulai hidup - dalam teknologi dan analisis - saya mulai hidup melakukan ini karena saya biasa menulis artikel tentang kemampuan basis data pada platform DEC VAX. Dan untuk alasan itu, para pembelanja basis data biasa memberi tahu saya. Dan hal semacam itu terjadi pada saya adalah itu, mengapa Anda memiliki database? Maksud saya, pada masa itu banyak sekali orang yang digunakan untuk membuat file nilai kunci dan menggunakannya untuk memiliki semacam kesalahan indeks berurutan seperti yang kita sebut, tetapi untuk membuat semacam kemampuan basis data, dan Anda tahu, mengapa Anda harus ada yang lain?
Dan jawabannya, saya pikir Michael Stonebraker memberikan jawaban terbaik untuk itu, dan dia berkata, "Basis data dapat mengetahui lebih banyak tentang di mana data itu dan seberapa cepat untuk mendapatkannya, daripada program mana pun yang bisa tahu." Dan saya pikir itu menarik; itu adalah sifat permainan. Tetapi pada 19 - sekitar tahun 1989 yang saya mulai dalam analisis teknologi dan Anda tahu, pada saat itu, basis data sangat sederhana dan basis data relasional sangat sederhana. Mereka memiliki kemampuan yang sangat sedikit, maksud saya, mereka dapat menyimpan data, jelas, dan Anda dapat membuat cadangan dan mereka memiliki, mereka mematuhi ACID, tetapi mereka benar-benar memiliki pengoptimal yang sangat lemah. Bahkan, akan sulit untuk membantah bahwa mereka memiliki kemampuan pengoptimal sama sekali.
Dan kemudian mereka menjadi lebih baik dan lebih baik, tetapi, Anda tahu, ketika sebuah database tidak berfungsi - karena kanguru ini tampaknya menunjukkan satu atau lain cara - mungkin ada banyak alasan mengapa itu berjalan lambat. Dan itu membawa saya pada intinya: Database memiliki banyak fungsi, tetapi yang paling penting adalah optimasi kueri. Jika mereka tidak melakukan itu, Anda tidak akan menggunakannya. Ini tentang mendapatkan informasi dengan cepat, ini tentang bisa melakukannya ketika ada banyak pengguna secara bersamaan, dan itu masalah yang sulit. Dan ketika Anda benar-benar melihat, mari kita sebut mereka basis data yang matang, jika Anda suka - tetapi tentu saja Oracle, sedikit lebih rendah, Microsoft SQL Server, tentu saja Teradata dan DB2 - pengoptimal dari basis data itu, sudah puluhan tahun di bangunan. Anda tahu, mereka tidak - seseorang tidak duduk - enam pria di proyek dua orang, tahun, dan hanya mengetuk satu bersama. Itu tidak berfungsi seperti itu. Kemampuan pengoptimalan telah tumbuh secara bertahap, dan butuh banyak pertumbuhan. Bagaimanapun, mari kita bicara tentang latar belakang ke basis data. Nah, ada banyak sekali yang dikatakan tentang database NoSQL sekarang, dan bahkan ada banyak antusiasme untuk basis data grafik. Dan penggunaan SQL lebih dari Hadoop dan hal-hal seperti itu. Tapi, kebenarannya adalah bahwa jika Anda menginginkan database saat ini, jika Anda menginginkan OLTP yang berfungsi penuh, mampu, dan lalu lintas permintaan yang besar, ini adalah basis data relasional, atau bukan apa-apa.
Di antara basis data relasional, Oracle dominan dalam hal popularitas. Microsoft SQL Server, saya pikir, adalah yang kedua. Keduanya mampu digunakan untuk OLTP dan kueri beban kerja, tetapi sebenarnya Anda benar-benar tidak bisa lepas dengan mencampur beban kerja tersebut. Anda memerlukan insiden berbeda untuk beban kerja OLTP dan kueri beban kerja. Ada alternatif untuk SQL dan grafik. Sebagian besar perusahaan melakukan standarisasi pada satu basis data spesifik, itulah sebabnya - maksud saya setelah beberapa dekade berjuang dengan semua pemain lain, Oracle menjadi yang paling dominan. Hanya karena mereka akhirnya dapat menjual lisensi perusahaan, dan karenanya perusahaan hanya akan menggunakan produk-produk alternatif dalam produk-produk istimewa Oracle tidak akan melakukannya. Dan database strategis karena mereka juga berkembang. Dan Anda tahu saya melakukan sedikit riset untuk presentasi ini, dan ini semacam - Saya akan membahasnya sebentar, tapi agak menarik bagaimana mereka berkembang, dalam hal melihatnya dari posisi DBA. Inilah yang saya sebut tren tak terlihat. Ini hukum potong dadu Moore. Ini kira-kira seperti ini: Basis data terbesar adalah, dan database baru, tidak ada database lama yang mendapatkan lebih banyak data untuk dicerna. Biasanya database yang diterapkan untuk masalah baru. Dan mereka benar-benar tumbuh dalam hal volume data. Kira-kira di kubus Moore hukum. Jadi hukum Moore adalah faktor sepuluh kali setiap enam tahun. VLDB cenderung menumbuhkan faktor seribu setiap enam tahun. Pada tahun 1991, 1992, basis data besar diukur dalam megabyte. Di '97 dan '98, gigabytes. 2003, '4, terabyte. 2009, '10, Anda mulai melihat basis data petabyte. Saya pikir mungkin ada satu atau dua database exabyte di luar sana sekarang, tapi yang terbesar yang pernah saya dengar adalah 200 petabyte tepat waktu, dan Anda tahu, tidak mendapatkan data ke database petabyte. Tapi, sebagian besar jelas akan menjadi perusahaan web 2.0 besar baru, mungkin, Anda punya Facebook menuju ke arah itu.
Tapi bagaimanapun, jika Anda benar-benar melihat itu, mengharapkan database untuk melalui peningkatan volume semacam itu, itu banyak bertanya. Dan yang luar biasa, tentu saja hingga tingkat petabyte, mereka tampaknya telah melakukannya dengan cukup baik. Maksud saya, saya berbicara tentang produk yang lebih lama daripada yang baru. Mereka tampaknya telah melakukannya dengan sangat baik. Jika kita melihat kinerja database, kemacetan, ini membawa saya kembali ke waktu saya benar-benar peduli dengan mereka, dan harus khawatir tentang mereka. Anda tahu ini pada dasarnya kerusakan perangkat keras. Ada kemacetan CPU, mungkin, ada kemacetan memori, mungkin, ada kemacetan disk, mungkin. Ini bisa jadi jaringan yang menyebabkan Anda berduka, dan Anda juga bisa mendapatkan masalah dengan penguncian, tergantung pada apa yang Anda lakukan, tetapi biasanya itu karena program tidak tahu siapa yang harus dipanggil kunci. Jadi, jika Anda akan menyetel basis data, Anda sebenarnya mencoba untuk menyetelnya sehingga bisa menari di antara lima kemacetan yang mungkin terjadi dan juga bisa melakukannya. Dan itu bukan masalah mudah, karena jumlah memori yang dapat Anda konfigurasi pada server mana pun meningkat secara dramatis. Kemudian CPU telah menjadi multicore, disk, yah kita sekarang dapat melakukannya, saya pikir, bahkan pada server komoditas, saya pikir Anda dapat melakukan ratusan dan terabyte, seperempat petabyte, mungkin, bahkan pada server komoditas. Jadi, dari semua hal ini, Anda dapat bermain dengan, jaringan tentu saja dapat berjalan dengan kecepatan yang berbeda, tetapi sebagian besar ketika Anda berurusan dengan database, Anda benar-benar ingin memiliki kabel serat antara server dan tidak ada yang berjalan pada itu, khususnya seperti itu.
Faktor kinerja basis data. Maksud saya, saya mengabaikan semua ini, karena saya tahu Dez akan membicarakannya, tetapi desain database yang buruk berarti database yang berkinerja buruk. Desain pemrograman yang buruk dapat berarti membuang SQL yang sangat bodoh ke dalam database, yang hanya akan memakan waktu lebih lama. Pencampuran konkurensi dan beban kerja, terlalu banyak konkurensi akan menyebabkan masalah bottlenecking. Pencampuran beban kerja, saat Anda memiliki kueri besar dengan kueri sangat kecil, pendek, tajam, yang menyebabkan masalah. Ada masalah penyeimbangan beban. Sebagian besar database mengatasinya, tetapi jika Anda tidak memiliki produk yang canggih, maka Anda tahu, hanya menambahkan beberapa server, tidak semua yang Anda lakukan jika Anda benar-benar ingin meningkatkan ukuran cluster. Anda benar-benar harus menyeimbangkan beban sebelum mendapatkan kinerja optimal. Anda perlu melakukan perencanaan kapasitas. Benar. Terutama sekarang di hari-hari ini ketika volume data meningkat lebih dramatis daripada sebelumnya untuk database. Dan ada masalah seluruh lapisan data tentang bagaimana Anda menelan data, bagaimana Anda memindahkan data. Tidak mendapatkan data ke database tepat waktu dapat menjadi masalah kinerja di kemudian hari karena kami telah beralih dari database yang bekerja di Windows, menjadi dua puluh empat kali tujuh kali tiga ratus tujuh puluh lima operasi dan tidak ada jendela di mana Anda dapat memperlambat database turun atau tidak mungkin akan ada saat ini.
Masalah Oracle DBA. Inilah yang saya pikirkan. Saya sudah berada di DBA Oracle dengan Oracle 7, dan saya ingat bagaimana menyetelnya. Dan jika Anda benar-benar melihat Oracle sekarang, itu cara, cara - itu punya cara, kemampuan yang jauh lebih besar. Ada pengindeksan bitmap dan hal-hal seperti itu, tetapi saya benar-benar meluangkan waktu untuk melihat dan melihat berapa banyak parameter penyetelan yang sebenarnya ada dalam database Oracle saat ini. Dan ada lebih dari tiga ratus lima puluh parameter penyetelan dan ada lebih dari seratus parameter tersembunyi, yang mungkin diketahui oleh DBA spesialis, tetapi DBA Oracle normal tidak tahu. Dan itu berarti bahwa menyetel basis data semacam ini adalah hal yang sulit. Itu sama sekali bukan hal yang sederhana. Anda harus memiliki perasaan untuk itu, Anda harus melakukannya untuk waktu yang sangat lama, dan Anda harus tahu persis apa masalah yang Anda pikir Anda selesaikan, karena penyetelan dimulai ketika kinerja menjadi buruk, tetapi mungkin bukan kinerja segalanya. Mungkin kinerja kueri spesifik yang penting, dan Anda mungkin dapat memperbaikinya dengan menyematkan data dan memori tertentu, atau Anda mungkin perlu memperbaikinya dengan mengindeks, atau Anda mungkin perlu mulai melakukan partisi dengan cara yang berbeda. Ada banyak hal yang dapat Anda lakukan, intinya. Jadi, akibatnya, mereka tidak akan melakukannya di kepala mereka - DBA membutuhkan alat. Sekarang saya akan meneruskan kepada Dez siapa yang akan memberi tahu Anda tentang pengindeksan, saya pikir.
Eric Kavanagh: Baiklah Dez, bawa pergi.
Dez Blanchfield: Terima kasih, Robin, dan saya suka halaman sampulnya. Saya pikir Anda telah melemparkan tantangan di sana untuk saya datang bahkan mendekati sesuatu yang menarik. Tapi saya telah menggunakan gambar galaksi kecil kita, seperti pandangan saya tentang apa tantangan hari ini bagi administrator database telah berubah, karena ini adalah gambar mental yang saya cenderung untuk menyulap ketika saya masuk ke lingkungan dan saya tidak lagi di dunia administrasi basis data atau mendesain basis data di tingkat itu lagi. Tetapi, seperti Anda, Robin dan saya telah bertahun-tahun terlibat dalam dunia basis data, baik sebagai administrator atau pengembang, atau akhirnya arsitek, dan kemudian menyadari bahwa saya dapat melakukan hal-hal yang lebih baik untuk mendapatkan lapisan kulit. Tapi itu cenderung merasa seperti Anda sedang menatap galaksi data ini, dan lebih lagi hari ini, ketika kita beralih dari, seperti yang Anda uraikan, kita telah beralih dari megabita menjadi petabita dan skala exo dalam waktu yang sangat singkat., dalam skema besar hal. Tetapi frasa yang ada dalam benak saya adalah, bahwa indeks basis data sekarang menjadi seni hitam dan mereka tidak benar-benar jenis barang yang hanya bisa dilakukan oleh manusia biasa, untuk aplikasi bisnis tingkat perusahaan dan jenis perumusan Anda baru saja berbicara tentang. Tapi, saya ingin melalui ikhtisar singkat tentang jenis sejarah yang saya miliki dengan dunia basis data dan membawa ke konteks di mana kita akan menarik kesimpulan, dan kemudian menjalankan beberapa materi hari ini dengan teman-teman kita di IDERA, karena saya pikir ada banyak pemikiran berbeda tentang cara mendapatkan penyempurnaan kinerja database dan salah satunya adalah melempar timah pada benda itu. Untuk banyak toko yang saya temui, mereka biasanya tidak sampai pada titik melakukan penyetelan kinerja pada lapisan basis data dan khususnya lapisan indeks sampai mereka telah melewati jalur yang sulit berpikir mereka dapat melemparkan tuner ke sana. .
Banyak orang hanya mengambil pendekatan besar untuk itu, dalam pikiran saya, dan saya punya gambar The Flash di sini karena jika Anda pernah menonton film lama atau tentu acara TV terbaru dengan The Flash, seperti pada Flash Gordon karakter lama, dan sekarang dia dipanggil "The Flash, " dia cenderung pergi sangat, sangat cepat dan selalu energinya habis. Dan inilah yang terjadi ketika Anda melemparkan besi besar pada kinerja database. Selalu, dalam pengalaman saya, Anda dapat menempatkan kinerja tinggi, kerja keras dalam permainan, Anda dapat mengoptimalkan sistem operasi Anda dan menyetelnya ke titik tertentu. Anda dapat memastikan bahwa Anda memiliki multicore yang cepat, CPU multithreading untuk membuat aplikasi berjalan lebih cepat, Anda dapat membuang banyak RAM, Anda dapat memiliki backplane throughput tinggi, Anda dapat beralih dari hard drive ke caching hard drive ke solid state, dan larik penyimpanan berkinerja tinggi. Dan bahkan sekarang, orang-orang melempar hal-hal seperti flash dan NVMe di mesin database mereka, berpikir bahwa mereka akan mendapatkan login kali ini dua peningkatan kinerja. Dan selalu mereka mendapatkan beberapa keuntungan. Tapi, itu semua kembali ke masalah penyetelan kinerja dasar yang sama. Banyak koneksi jaringan latensi rendah, sehingga cluster bekerja dengan cepat. Dan mengelompokkan infrastruktur basis data, jadi Anda memiliki lebih dari satu mesin yang melakukan semua pekerjaan. Tetapi Anda cenderung kembali ke masalah kinerja dasar yang sama, yaitu membaca data. Menulis data, sebagian besar, merupakan tantangan yang cukup linier dan kecuali jika dilakukan dengan benar.
Dan kemudian kita memiliki tantangan di dunia saat ini: Tidak semua database dibuat sama. Ada database dan kutipan-on-kutipan "database." Dan ketika kita berpikir tentang mesin database, orang sering berpikir tentang tersangka tradisional yang biasa seperti mereka di dunia SQL. Anda tahu, kami memiliki Oracle, dan Microsoft SQL Server, dan ada beberapa di sekitarnya di dunia open source dengan MySQL, yang sekarang dimiliki oleh Oracle, tetapi masih open source. Dan kemudian kita punya tersangka yang tidak biasa, mesin NoSQL, yang masih memiliki masalah seputar pengindeksan dan manajemen kinerja, dan saya tidak akan membahasnya secara mendetail, tetapi ada peningkatan jumlah ini segala sesuatu bermunculan setiap hari dan mereka terlihat dan terasa seperti mesin basis data dari sudut pandang pengembang dan dari sudut pandang kinerja, tetapi mereka adalah binatang yang sangat, sangat berbeda dan mereka memiliki ceruk kecil mereka sendiri di dunia untuk mengukir kinerja dalam memori atau skala linier pada disk. Tapi seperti inilah dunia di dunia basis data. Ini adalah 2016, ini adalah versi tiga peta, oleh sejumlah orang yang menghasilkan peta lanskap yang sedang berlangsung ini seperti apa bentuk database, dan ini adalah tempatnya - bahkan arsitek basis data manusia super atau administrator basis data tidak masuk akal itu. Secara harfiah ratusan, dan ratusan, dan ratusan merek, model, pabrikan database berbeda, selalu sesuai dengan SQL. Dan yang menarik adalah, mereka semua kembali ke tantangan yang sama. Performa dan penyetelan kinerja di sekitar mesin basis data, dan terutama dengan cara data diindeks.
Jadi mari kita cepat-cepat membahas pengindeksan basis data, karena ini adalah topik yang menarik, dan Anda harus membahasnya lebih detail dengan demo, saya percaya. Tapi, saya pikir ini cukup diterima dan praktik industri standar bahwa penyempurnaan kinerja indeks basis data adalah tempat dunia dimulai dan berakhir sejauh memastikan data Anda dapat diakses dalam format cepat dan cepat. Tapi apa itu pengindeksan basis data? Jika kita berpikir tentang pengindeksan dalam bentuk yang biasa kita gunakan sebagai manusia biasa, pikirkan sebuah halaman indeks dalam sebuah buku. Jika Anda ingin menemukan sesuatu di buku - terutama yang suka ensiklopedia, atau sesuatu seperti bahan referensi dari beberapa bentuk - jika Anda mencari sesuatu seperti halaman ini, di mana saya mencari hal-hal seperti topik bendungan dalam ensiklopedia. Saya ingin menemukan setiap referensi untuk bendungan, tangkapan air dan area penumpukan yang besar, buatan manusia pada umumnya. Saya akan pergi ke belakang, saya akan menemukannya di daftar alfabet, diurutkan, A ke Z, kiri ke kanan, dan saya akan menemukan D. Saya akan menemukan kata "bendungan" dan saya dapat melihatnya di halaman 16, 38, 41 ada referensi untuk mereka, dan kemudian saya bisa pergi ke halaman-halaman itu, saya dapat memindai mata saya dan saya akan menemukan referensi ke kata "bendungan." Ini pada dasarnya konsep yang sama dalam database, tapi sekarang ilmu roket dalam banyak hal. Sebegitu jauh, sehingga secara efektif setiap administrator basis data yang pernah saya kenal dengan baik, menganggap indeks sebagai alat paling penting untuk penyesuaian kinerja di dunia basis data apa pun, terlepas dari apa pengalaman mereka sejauh melemparkan timah ke dalamnya, atau apapun masalahnya.
Secara umum ketika kita berbicara tentang pengindeksan basis data, ada sejumlah pendekatan umum. Dan semakin kompleks indeks basis data, semakin kompleks pendekatan untuk mengindeks data. Tetapi pada dasarnya ketika Anda berpikir tentang pengindeksan data - bayangkan bahwa kita memiliki file yang memiliki daftar nama; mereka mungkin tidak diurutkan dalam urutan abjad. Mari kita bayangkan ada dua puluh di antaranya. Jika kita akan mengurutkan - jika kita akan mencari data dalam daftar itu, dari atas ke bawah, dan katakanlah itu daftar nama. Jika saya memilih nama acak dan saya mulai menggulir ke bawah daftar itu, dari atas ke bawah, dalam format linear dan ini adalah daftar yang tidak terurut, ada dua kriteria yang saya pikirkan sebagai waktu pencarian rata-rata dan waktu pencarian maksimum - dan Saya telah salah ketik pada baris kedua, seharusnya “waktu pencarian maksimum, ” maaf - tetapi waktu pencarian rata-rata saya pada dasarnya adalah N ditambah satu, dibagi dua, dan itu rata-rata, saya butuh lima puluh persen dari waktu untuk memindai dari bagian atas daftar, ke bagian bawah daftar untuk menemukan hal-hal acak dalam daftar itu. Dan baris kedua di sana, di bawah linear, harus "waktu pencarian maksimum." Tetapi waktu pencarian maksimum pada dasarnya adalah jumlah item, dan itu adalah bahwa jika saya memiliki daftar dua puluh hal, yang paling banyak waktu dapat membawa saya untuk mencari sesuatu dalam database itu adalah pergi dari atas ke bawah, yaitu katakanlah 20 item dalam contoh sederhana ini. Dan ini adalah proses yang sangat lambat dan benar-benar tidak ada cara untuk menyelaraskan kinerja itu. Dan kemudian, ada jenis cara lain untuk mengambil data itu dan membuat indeks, yang secara efektif adalah daftar pendek petunjuk ke mana data aktual berada, seperti biner, B-tree, bitmap, hashing, clustered dan non-clustered, dan kemudian ada berbagai jenis data seperti spasial, difilter, XML, dan teks lengkap.
Biner adalah yang sangat umum digunakan untuk hal-hal di mana data cocok untuknya. B-tree mungkin adalah satu-satunya yang paling umum dalam pengertian umum, secara historis, dalam hal ini adalah cara yang umum untuk menyusun indeks ke segala bentuk data dan memungkinkan penebang, seleksi, dan penyisipan dan penghapusan relatif mudah ketika Anda memindahkan pointer di sekitar referensi ke pointer, poin. Ada tipe-tipe lain, seperti bitmap, di mana tipe-tipe data terkait seperti jika kita memiliki rentang yang terkait dari suatu bentuk. Hashing berfungsi sangat baik untuk objek besar, terutama blog dan gambar. Dan Anda dapat melihat bahwa ada sejumlah jenis pendekatan ilmiah, pendekatan matematika, hingga pengindeksan data. Bagi manusia biasa, itu adalah tantangan yang menarik untuk dibicarakan di tingkat ini. Ketika Anda membicarakannya di tingkat kinerja untuk administrator basis data, mereka benar-benar menjadi ilmuwan roket dan orang-orang melakukan gelar di dalamnya, dan saya tahu bahwa Dokter Robin Bloor telah melakukan itu, dan menulis buku tentang itu untuk orang-orang seperti IBM dan merek besar lainnya selama beberapa dekade terakhir. Jadi, - pandangan saya, adalah bahwa kita telah benar-benar melewati masa di mana, Anda tahu sekali waktu saya secara pribadi dapat duduk di depan suatu sistem dan saya akan dapat memisahkannya, dan menunjukkan kepada Anda persis di mana masalah kinerja berada di baris perintah atau di alat mulai antarmuka pengguna grafis, dan mulai menggali data dan memberi tahu Anda di mana masalah itu, dan membangun indeks, atau sub-indeks, atau indeks primer dan sekunder ke dalam data dan mulai menggunakannya untuk menemukan sesuatu. Tetapi ketika Anda berpikir tentang lanskap yang saya tunjukkan kepada Anda, di mana kami memiliki ratusan dan ratusan merek, merek dan model, dan produsen dan jenis basis data, kami benar-benar melewati masa itu sekarang, di mana manusia dapat membuat merasakan jenis-jenis mesin database yang kami punya. Khususnya, bahkan jika kita kembali ke Oracle, merek-merek utama akhir-akhir ini dalam platform basis data relasional.
Jumlah basis data yang harus mereka tangani baik dari platform berpemilik seperti ERP atau SDM atau sistem keuangan, atau apakah itu platform buatan sendiri karena berbagai alasan, jumlah basis data dan tabel serta catatan basis data yang akhirnya kita dapatkan berurusan dengan hanya astronomi dan Anda secara fisik tidak dapat melakukannya dengan tangan. Dan kami mengalami komplikasi tambahan sekarang, di mana pada suatu waktu, server database mungkin hanya duduk di bawah meja Anda. Anda tahu, sebagai anak muda sepulang sekolah, saya biasa pergi dan bekerja pada perangkat lunak basis data pada, awalnya, Apple IIes dan kemudian sistem berbasis PC DOS, seperti dBase II, dBase III, melewati era dengan mainframe dan mid- rentang dan bahkan VAXs dan PDPs dan log file itu. Dan sejenisnya Sabre, dan akhirnya ketika beberapa database SQL muncul. Tetapi hari-hari ini ketika kita berpikir tentang mesin basis data, mereka terlihat seperti sudut kiri bawah. Server database bukan hanya satu mesin yang duduk di lantai di bawah meja lagi; itu adalah ratusan mesin yang menjalankan salinan mesin basis data, dan kelompok, dan mereka meningkatkan skala hingga ratusan dan ratusan terabyte data, jika bukan petabyte data, yaitu ribuan terabyte. Dan bahkan secara ekstrim, seperti yang disebutkan oleh Dokter Robin Bloor, bahwa beberapa kasus penggunaan khusus - maskapai penerbangan, lembaga pemerintah khususnya - dapat mencapai exabytes. Mereka masih cukup niche-y, tetapi ratusan terabyte dan bahkan puluhan petabytes sudah tidak biasa lagi, terutama dari booming dotcom hingga sekarang, semacam apa yang kita sebut perusahaan web 2.0, seperti Facebook, Google, Yahoo Dan seterusnya.
Kami juga mengalami komplikasi sekarang karena banyak hal beralih ke layanan eksternal. Kami memiliki platform dan perangkat lunak infrastruktur sebagai pendekatan layanan yang menyediakan infrastruktur. Dan khususnya layanan platform di mana kita tidak bisa hanya membeli untuk orang-orang seperti Oracle dan platform cloud mereka, database dan server. Jadi ini memungkinkan kita untuk melakukan pengembangan aplikasi yang sangat cepat dan cukup tancapkan kembali database ke server. Kita tidak harus memikirkan apa yang ada di balik tudung. Kelemahannya, adalah bahwa kita sering tidak memikirkan bagaimana kita merancang dan mengimplementasikan basis data kembali sampai mulai sakit dan kinerja menjadi masalah dan kemudian kita akhirnya harus mencari alat yang tepat untuk mendiagnosis mengapa basis data kita sakit dan di mana masalah kinerja. Dan selalu membawanya kembali ke masalah umum tentang bagaimana kita telah mengindeks data itu dan jenis indeks yang kita gunakan untuk data itu dan yang kemudian membawa kita kembali ke persyaratan kinerja manusia super. Dan seseorang yang memiliki akses ke sistem yang tepat dan alat yang tepat untuk kinerja menyetel mesin tersebut, dan mulai menemukan titik panas dan melihat di mana kueri berada, di mana data bergerak, jenis kueri, bagaimana kueri disusun, siapa yang melakukan kueri, dan apakah kueri sedang dalam antrian, dan harus di-cache. Replikasi apa yang Anda cari?
Dan jadi kami baik dan benar-benar - dalam pandangan saya - pada titik sekarang di mana bahkan guru basis data terbaik dunia, pada dasarnya arsitek basis data kami dan administrator basis data kami dan basis kinerja, dalam pandangan saya mereka sangat perlu untuk mulai meningkatkan alat yang tepat untuk memberikan penyempurnaan indeks kinerja optimal untuk setiap mesin basis data. Karena skala yang kita hadapi dan kecepatan bergeraknya hal-hal, kita tidak bisa melakukannya dengan tangan, dan berusaha melakukan itu selalu dapat menimbulkan masalah kinerja lain, karena kita mungkin tidak memiliki pengalaman dalam ruang yang kami mencoba untuk menyelesaikan masalah. Dan saya percaya bahwa di situlah kami akan menyerahkan kepada Bert, dan kami akan berbicara tentang bagaimana mereka telah memecahkan berbagai masalah ini dan jenis hal yang dapat dilakukan alat mereka lakukan, khususnya untuk dunia Oracle. Dan dengan itu di sana, Bert, aku akan menyerahkan padamu.
Bert Scalzo: Terima kasih. Selamat datang semuanya, nama saya Bert Scalzo, saya bekerja untuk IDERA. Saya manajer produk senior untuk beberapa produk basis data kami. Saya akan menunjukkan beberapa dari mereka hari ini. Tetapi saya ingin berbicara tentang indeks, karena saya setuju dengan semua yang dikatakan semua orang di sini, terutama slide terakhir, bahwa indeks sekarang sangat kompleks sehingga Anda memerlukan alat, dan saya berharap dapat meyakinkan Anda. Jadi desain indeks Oracle, tidak semudah dulu di masa lalu. Banyak orang tidak yakin akan diri mereka sendiri ketika mereka melihat pilihan, dan saya suka mengatakan ini bahwa saya menarik diri dari sejarah, "dalam hal ini, satu-satunya kepastian, adalah bahwa tidak ada yang pasti." rasakan tentang indeks hari ini, karena bahkan jika Anda pikir Anda tahu jawaban Anda harus indeks X, Y atau Z, Anda benar-benar tidak dapat memastikan sampai Anda mencobanya, karena pengoptimal itu kadang-kadang berperilaku berbeda dengan cara yang Anda harapkan. Dan ada banyak trial and error dengan desain indeks. Sekarang, di masa lalu yang indah, jika Anda membutuhkan indeks biasanya hanya ada dua pertanyaan, atau satu pertanyaan. Apakah itu unik atau tidak unik? Dan Anda mungkin telah memikirkan hal-hal lain seperti, "Berapa banyak indeks yang dapat saya miliki maksimum pada satu tabel?" Karena terlalu banyak indeks memperlambat insert, pembaruan, dan penghapusan Anda. Anda juga mungkin telah berada di sistem database Anda, memiliki batasan pada berapa banyak kolom yang bisa berada dalam indeks multi-kolom, karena kadang-kadang ada batasan berdasarkan halaman atau ukuran blok mesin database Anda, tetapi pada kenyataannya itu cukup sederhana kembali di masa lalu yang indah. Anda mengindeksnya atau tidak. Dan sungguh, semuanya ada di pohon-B. Kami dapat mengizinkan duplikat atau tidak, dan hanya itu saja. Hidup itu baik, hidup itu sederhana.
Nah hari ini, hidup tidak begitu baik atau sangat sederhana. Saya telah memasang tanda Ghostbuster merah melalui cara yang biasa kami lakukan, karena sekarang kami memiliki B-tree versus bitmap, versus bitmap bergabung. Dan saya akan menjelaskan beberapa hal ini sebentar lagi. Clustered dan non-clustered, unik atau duplikat, urutan maju atau mundur, berbasis fungsi, dipartisi atau tidak dipartisi. Jika ada partisi yang terlibat, apakah itu partisi global atau lokal? Saya akan menjelaskan itu juga. Dan kemudian juga ada sesuatu yang disebut tabel terorganisir yang diindeks. Dan sebenarnya ada setengah lusin lainnya yang saya tinggalkan di sini, karena saya pikir saya sudah cukup di sini sekarang yang akan meyakinkan Anda bahwa indeks jauh lebih sulit daripada yang Anda kira. Dalam slide khusus ini, saya akan mulai di bagian kiri atas diagram dan saya punya tabel. Dan hal pertama yang harus saya putuskan adalah, tergantung pada versi database Anda dan vendor database Anda, apakah mereka mengizinkan tabel objek atau hanya relasional? Saya akan turun ke sisi kanan dan mengatakan bahwa kita sedang membangun tabel relasional. Sekarang, pertanyaan berikutnya yang harus saya tanyakan pada diri saya adalah, apakah itu dalam sebuah cluster? Dan banyak dari Anda yang telah melakukan Oracle selama beberapa waktu akan ingat bahwa cluster kembali selama 6 hari Oracle. Mereka mungkin tidak terlalu banyak digunakan hari ini, tapi biarkan aku turun cabang itu dulu.
Jika saya akan meletakkan meja saya di sebuah cluster, saya harus memiliki indeks cluster di atas meja itu. Sekarang, di Oracle, ketika Anda mengelompokkan tabel, Anda pada dasarnya menyimpan baris atau baris dekat satu sama lain di mana nilainya sama. Jadi, Anda harus memiliki indeks berkerumun dan indeks berkerumun itu bisa non-dipartisi. Dengan kata lain, sebenarnya tidak ada metode partisi untuk bagaimana Anda akan melakukan tabel berkerumun. Itu benar-benar non-partisi. Dan karena itu tidak dipartisi, itu bersifat global. Saya akan menjelaskan apa itu global dalam satu menit. Dan itu selalu pohon-B. Dengan kata lain, ketika saya pergi ke cabang itu, itu sangat sederhana, saya tidak punya banyak pilihan. Sekarang, jika saya melakukan indeks non-clustered pada tabel clustered, yang diizinkan dalam beberapa versi, sekali lagi itu non-partisi; ketika tidak dipartisi, maka satu-satunya pilihan Anda adalah global. Jadi, di sana Anda memiliki pilihan B-tree atau bitmap. Sekali lagi, itu tergantung pada versi database Anda. Tapi sekarang, mari kita kembali ke meja relasional dan mulai turun ke sisi kanan lagi dan sekarang kita hanya akan memiliki meja polos, tua, teratur, tumpukan: relasional. Ini akan berada di ruang meja. Aku agak turun ke sisi kanan di sini dulu. Jadi ini organisasi, heap. Pertanyaan berikutnya yang harus saya tanyakan pada diri saya adalah, "Apakah saya ingin mempartisi tabel ini atau tidak?" Sekarang, kadang-kadang Anda akan mempartisi karena Anda berpikir, "Hei, pengoptimal akan lebih pintar tentang bagaimana dapat mengoptimalkan permintaan. “Tetapi banyak DBA akan memberi tahu Anda bahwa alasan Anda melakukan itu adalah untuk keperluan administrasi. Jika Anda memiliki tabel ratusan miliar baris, jika Anda memecahnya menjadi partisi atau ember, ketika Anda ingin menambahkan data ke ember terakhir, Anda bisa menjatuhkan dan mengindeks itu hanya beberapa juta baris. Anda dapat memasukkan data itu dan kemudian Anda dapat membangun kembali indeks itu hanya pada ember itu.
Sementara itu adalah teknik yang baik untuk beberapa orang, teknik optimasi seperti penghapusan partisi, nilai sebenarnya adalah mampu mengelola atau melakukan tugas-tugas administratif pada potongan-potongan kecil. Ketika saya pergi ke tumpukan organisasi, pertanyaan pertama adalah, "Apakah saya mempartisi atau tidak?" Mari kita pergi ke kiri, saya tidak akan mempartisi tabel. Sekarang, mungkin terasa aneh ketika saya memberi tahu Anda ini, tetapi Anda bisa memiliki tabel non-dipartisi dan kemudian Anda tidak dapat mempartisi indeks seperti Anda terbiasa, atau Anda dapat mempartisi indeks. Berhenti dan pikirkan. Meja Anda pada dasarnya memiliki satu ember, seperti yang selalu Anda pikirkan, namun indeks Anda akan memiliki beberapa ember. Ketika itu terjadi, di mana ada ketidakcocokan antara jumlah ember dan tabel, dan jumlah ember dalam indeks, itulah yang dimaksud dengan global. Jadi, jika tabel tidak dipartisi, dan jika indeks dipartisi, itu dianggap global, karena ada ketidakcocokan. Sekarang, izinkan saya kembali ke tumpukan organisasi saya, dan turun di sisi partisi. Sekarang, jika saya memiliki tabel partisi, dan katakanlah tabel memiliki empat ember, empat partisi, indeks saya bisa memiliki empat ember sehingga indeks saya cocok dengan desain tabel saya. Dan itu sudah berakhir, jauh di sebelah kanan. Itu akan dianggap lokal. Indeks lokal pada dasarnya berarti bahwa partisi tabel dan indeks dilakukan dengan cara yang sama dan memiliki jumlah ember yang sama. Dan setelah saya memiliki indeks lokal, itu bisa berupa B-tree atau bitmap, dan panah hijau semacam itu naik, menunjukkan kepada Anda bahwa bahkan jika itu adalah B-tree, masih ada pilihan yang bisa dibuat. Itu bisa berbasis fungsi. Dan juga, jika itu adalah bitmap, ada berbagai jenis bitmap. Ada sesuatu yang disebut bitmap join index. Jika Anda melakukan pergudangan data, itu semacam indeks yang sangat populer untuk skema atau desain bintang. Apa yang terjadi adalah bahwa indeks memiliki ID baris untuk apa yang ditunjukkan dalam tabel, tetapi juga akan memiliki ID baris untuk tabel induk sehingga ketika Anda - Anda harus membintangi desain skema dan Anda mencari pada tabel fakta, indeks pada tabel fakta mengarahkan Anda ke data yang Anda minati, dan mengarahkan Anda ke setiap baris di dimensi Anda, sehingga Anda hanya perlu memiliki satu indeks.
Dan sebenarnya, ini muncul karena Bata Merah, yang merupakan basis data bertahun-tahun yang lalu - banyak orang mungkin ingat itu. Jadi, jika Anda melihat gambar ini - dan perlu diingat saya tidak meletakkan semuanya di gambar ini karena gambarnya akan jauh lebih besar - masih ada masalah tambahan, yang saya miliki di teks di sini di bagian kanan atas . Apakah ini indeks pesanan terbalik? Dan Anda mungkin berkata, “Mengapa saya ingin indeks urutan terbalik? Itu tidak masuk akal sama sekali. ”Ya, jika Anda berada di lingkungan berkerumun di Oracle, jika Anda melakukan cluster aplikasi nyata, jika Anda menjaga indeks Anda dalam urutan, jadi non-terbalik, jika Anda memiliki banyak pemrosesan yang mengenai nilai yang sama atau nilai indeks yang sama, apa yang akan terjadi adalah, Anda akan memiliki area panas dari B-tree Anda. Berarti Anda akan memiliki pertentangan dan kemungkinan mengunci untuk mencoba dan mengakses hal-hal itu, dan Anda akan melakukannya di seluruh node dalam jaringan. Nah, jika Anda memasukkan indeks urutan terbalik, sekarang Anda dapat membatalkannya. Anda dapat mengatakan, "Ya, nilai-nilai yang sama ada di berbagai bagian pohon, jadi saya tidak memiliki simpul terpisah yang bersaing untuk area panas di pohon." Dan kemudian perhatikan juga bahwa unik tidak berfungsi dengan beberapa opsi. . Jika Anda melihat, saya sudah nomor tiga, lima, delapan dan sebelas, jadi ada beberapa kasus di mana saya tidak dapat memiliki indeks yang unik. Demikian juga, ada beberapa kasus di mana saya tidak dapat memiliki indeks balik, dan kemudian ada masalah tambahan seperti pencatatan atau tidak ada pencatatan, dan paralel dan non-paralel. Saya dapat menetapkan hal-hal pada area tertentu dalam memori.
Dan ini meninggalkan sedikit fitur di Oracle. Saya akan mengatakan bahwa ketika Anda melihat Oracle 12, mungkin ada lagi sekitar setengah lusin hal yang bisa saya tambahkan ke gambar ini. Pengindeksan sangat kompleks dan saya sangat setuju dengan pembicara sebelumnya, untuk menavigasi melalui ini dan membuat pilihan yang baik, Anda memerlukan alat. Anda membutuhkan, mungkin, gambar seperti ini, dan semacam metodologi tentang bagaimana Anda akan memilih sesuatu dan mudah-mudahan alat ini akan membantu Anda sampai di sana. Dan itu akan menjadi trial and error. Saya selalu memberi tahu orang-orang tentang pengindeksan, "lihatlah sebelum kamu melompat." Dan kemudian kamu bisa melihat anjing kecil di sini, dia melompat tanpa melihat, dia akan berakhir di air bersama hiu, atau orang itu bersiap-siap untuk melompat ke air, dan dia akan menusuk dirinya sendiri. Anda harus memikirkan pengindeksan Anda, karena membuat indeks tidak selalu berarti segalanya menjadi lebih baik. Bahkan, membuat indeks dapat memperlambat segalanya. Dan kinerja permintaan bisa menjadi urutan yang lebih baik dengan satu pilihan di atas yang lain. Dan saya akan memberi Anda contoh yang baik. Jika Anda melakukan skema desain bintang, dan pada tabel dimensi Anda, Anda menggunakan indeks bitmap dalam satu kasus, dan dalam kasus lain Anda mengatakan, "Saya akan menggunakan indeks B-tree, " Anda memiliki bitmap versus B- pohon. Saya dapat memberitahu Anda bahwa satu solusi akan menjadi urutan besarnya atau mungkin beberapa kali lipat lebih cepat dari yang lain. Tetapi perlu diingat apa yang bekerja di satu lingkungan, seperti di lingkungan pergudangan data, mungkin bukan pilihan yang baik di lingkungan OLTP.
Misalnya, jika Anda mengambil tabel transaksional, dan meletakkan indeks bitmap pada tabel transaksional, itu mahal untuk menghitung dan mereset bitmap, string panjang ini, dan dalam tabel OLTP, Anda dapat menekan tabel dengan sangat keras sehingga bitmap indeks dapat menjadi rusak dan memperlambat sistem Anda karena itu tidak dimaksudkan untuk pembaruan. Mereka bagus untuk akses cepat, tetapi tidak bagus untuk pembaruan. Saya pikir indeks membutuhkan trial and error. Tidak ada lagi aturan emas - ada terlalu banyak variabel berbeda dalam persamaan ini yang perlu diketahui - dan pada akhirnya Anda harus melihat eksekusi atau menjelaskan rencana dalam database Anda untuk melihat apakah Anda membuat pilihan yang baik atau tidak. Dan kadang-kadang, analisis rencana hampir bisa menjadi ilmu tersendiri. Saya tidak akan membahas hal itu hari ini - itu topik lain - tetapi jangan anggap desain indeks begitu saja. Ada alasan sah mengapa ada semua tipe indeks gila yang saya tunjukkan ini, pada gambar sebelumnya, dan yang dibicarakan oleh pembicara sebelumnya. Ini tidak hanya dibuat karena itu adalah fitur yang rapi untuk dimasukkan ke dalam daftar periksa di suatu tempat untuk vendor database; ada kasus penggunaan atau skenario di mana indeks ini penting dan akan membuat perbedaan yang signifikan. Sekarang dengan itu, saya akan menunjukkan kepada Anda beberapa contoh dari berbagai jenis indeks di salah satu alat kami. Biarkan saya naikkan layar saya sehingga Anda bisa melihatnya. Oke, jadi di sini saya duduk di dalam - biarkan saya meminimalkan aplikasi ini. Saya duduk di dalam VMware dan saya menjalankan Windows Server 2012 VM.
Dan Anda bisa lihat, saya punya hampir setiap alat yang dikenal manusia. Sebagai manajer produk, saya harus tetap waspada terhadap pesaing saya, jadi bukan hanya alat apa yang saya miliki, tetapi apa yang dilakukan pesaing saya? Dan kita punya alat ini di sini bernama DBArtisan, yang sudah saya jalankan, tapi saya akan - jadi saya akan membawanya saja. Dan apa yang dapat Anda lihat adalah ini adalah alat yang sangat bagus, karena daripada harus menggunakan, katakanlah manajer perusahaan untuk Oracle dan Studio Manajemen SQL untuk SQL Server, dan Workbench MySQL untuk MySQL, dan dua belas basis data lain yang kami dukung, Yah, aku punya semua database saya dibangun ke dalam alat yang satu ini. Ada DB2, ada MySQL, Oracle, Postgres, SQL Server dan Sybase, dan itu - saya hanya punya enam basis data dalam hal ini karena saya tidak bisa - alat ini mendukung dua belas basis data tetapi VM saya yang buruk, menjalankan enam basis data secara bersamaan, dan mencoba untuk melakukan demo, kira-kira sebanyak perangkat keras saya akan memfasilitasi. Jadi izinkan saya kembali ke Oracle sekarang, dan jika Anda perhatikan, semua hal ini sama. Jika saya ingin mengukur kinerja saya di DB2, itu adalah pilihan yang sama dengan yang saya miliki di Oracle. Sekarang di bawah sampul kami melakukan banyak hal yang berbeda sehingga Anda tidak perlu tahu apa yang terjadi, tetapi kami memberikan Anda antarmuka yang konsisten sehingga Anda bisa menjadi ahli dengan berbagai platform basis data. Dan itu termasuk bekerja dengan indeks, topik diskusi ini.
Biarkan saya masuk ke sini dan biarkan saya mulai dengan melihat beberapa tabel, dan saya punya database film yang hanya memiliki beberapa tabel. Dan jika saya melihat tabel tertentu, seperti tabel pelanggan, ketika saya membawanya ke sini, saya bisa melihat desain meja saya, inilah kolom saya di tabel saya, dan inilah informasi tentang setiap kolom. Saya punya properti untuk tabel, tetapi perhatikan bahwa saya memiliki tab di sini untuk indeks dan saya bisa lihat di sini adalah indeks di atas meja. Perhatikan bahwa salah satu indeks ini adalah indeks PK saya, kunci utama saya. Yang lain ini terlihat hanya sebagai indeks untuk meningkatkan akses kueri, mungkin kita kueri berdasarkan nama depan, atau nama belakang, atau kita melihat ponsel dan kode pos. Dan jika saya memilih indeks tertentu, seperti kode pos ini di sini, dan saya klik dua kali padanya, sekarang saya dapat melihat bahwa, hei, ini adalah indeks yang tidak unik dan di sini ada beberapa jenis lain, bitmap, non-unik, unik, apakah itu diurutkan atau tidak, apakah itu log atau tidak, apakah itu urutan terbalik, apakah itu basis fungsi atau tidak. Oh, ini menyenangkan yang tidak saya bahas. Anda sebenarnya dapat memiliki indeks yang tidak terlihat. Dan Anda akan berkata, “Baiklah, mengapa saya ingin melakukan indeks yang tidak terlihat?” Baiklah, saya akan memberi Anda contoh yang baik. Anda berada dalam sistem produksi Anda dan Anda memiliki masalah kinerja dan Anda tidak yakin membuat indeks akan memperbaiki masalah, jadi Anda tidak ingin membuat indeks dan memperlambat produksi, tetapi entah bagaimana atau yang lain yang Anda ingin dapat mengujinya. Anda dapat membuat indeks dalam produksi sebagai tidak terlihat, artinya tidak banyak kode aplikasi, memanggil pengoptimal, akan menggunakan indeks itu. Sudah dibuat, valid, tetapi tidak akan digunakan. Kemudian Anda dapat mengambil kueri yang menurut Anda akan membantu indeks ini, atau serangkaian pertanyaan, dan Anda dapat memasukkan petunjuk dan berkata, "Hei, pengoptimal, ada indeks tak terlihat di luar sana yang saya ingin Anda gunakan dan biarkan saya tahu apakah saya telah membuat segalanya lebih baik. ”Dan sekarang saya telah menguji sesuatu dalam produksi, tetapi saya belum merusak aplikasi dalam produksi yang sedang berjalan. Itulah gunanya indeks yang tidak terlihat. Kedengarannya bodoh ketika Anda pertama kali mendengarnya, tetapi ada gunanya.
Kita juga dapat, pada indeks, menentukan apakah itu paralel, dan juga berapa banyak contoh yang paralel. Sekarang, dalam lingkungan aplikasi cluster non-clustered atau non-real, jadi non-rack, paralel akan berarti berapa banyak sub-proses yang dapat saya coba sampaikan untuk mencoba, dan proses pekerja, untuk mencoba dan menyelesaikan sesuatu dengan lebih cepat atau lebih cepat . Dan contoh paralelnya adalah, jika saya berada dalam aplikasi cluster nyata, katakan saya punya sepuluh node, berapa banyak node yang saya boleh pisahkan pekerjaan? Mungkin empat dari sepuluh, dan pada masing-masing dari mereka, empat sub-proses. Itu contohnya. Dan kemudian kita memiliki kompresi kunci. Anda benar-benar dapat menekan indeks? Ya atau tidak. Dan tentu saja Anda memiliki parameter penyimpanan yang dapat Anda tentukan pada indeks. Sekarang, saya tidak membahas ini karena mereka lebih merupakan parameter penyimpanan daripada masalah indeks. Dan akhirnya, kita memiliki apakah ini akan dipartisi atau tidak. Biarkan saya jatuhkan itu di sini sebentar. Saya akan pergi ke skema yang berbeda. Ini adalah skema bintang dan, misalnya, tabel periode ini adalah tabel dimensi. Jika Anda pernah melakukan desain skema bintang Anda biasanya memiliki dimensi waktu dan dalam database ini dan skema bintang ini, periode adalah dimensi waktu. Sekarang, saya tahu itu akan terlihat lucu, Anda akan berkata, "Wah, lihat semua kolom itu - apakah orang itu pernah mendengar tentang normalisasi?" Nah, ketika Anda berada di gudang data atau desain skema bintang, Anda biasanya memiliki non - Anda memiliki tabel yang orang biasa akan melihat dan berkata, "Wah, ini tidak dirancang dengan sangat baik." Tapi itulah cara Anda melakukannya di lingkungan pergudangan data.
Sekarang, perhatikan apa yang akan terjadi karena, oke, ada semua kolom ini, lihat itu, saya punya indeks di setiap kolom. Sekarang, di lingkungan OLTP yang akan menjadi tidak-tidak. Ini akan memperlambat semua operasi saya. Dalam lingkungan pergudangan data, saya akan menjatuhkannya selama siklus pemuatan batch. Muat tanpa overhead atau indeks, dan saya akan membuat ulang indeks. Dan jika saya mempartisi meja saya, maka alih-alih harus menjatuhkan indeks untuk setiap ember di tabel, saya bisa saja menjatuhkan indeks pada ember atau ember tempat data akan dimasukkan selama siklus pemuatan batch tersebut. Dan kemudian buat ulang hanya bagian indeks untuk ember itu. Dan itu membuatnya sangat mudah dikelola. Dan jika saya melihat - jadi inilah kolom yang disebut "Holiday Flag" dan pada dasarnya itu adalah ya atau tidak. Perhatikan bahwa ini adalah indeks bitmap, dan bagi sebagian besar dari Anda, Anda akan berkata, "Yah, itu masuk akal." Ya atau tidak, Y atau N, hanya ada dua nilai yang masuk akal. Dan karena ketika Anda membaca dokumentasi untuk indeks bitmap, mereka selalu memberi tahu Anda memilih sesuatu dengan kardinalitas rendah.
Sekarang biarkan saya masuk ke salah satu tabel fakta saya, jadi di sini kita punya pesanan saya. Dan ini pesanan saya per hari. Dan Anda akan melihat sekarang, bahwa sekali lagi saya memiliki beberapa kolom, dan sekali lagi, saya akan memiliki lebih dari beberapa indeks. Dan di sini, kami memiliki sesuatu yang disebut kode harga universal. Ini untuk toko ritel, jadi Anda tahu kode batang kecil itu ketika Anda membeli sesuatu di toko, ini adalah kode harga universal. Sekarang, ada jutaan kode harga universal. Sekarang, untuk perusahaan khusus ini yang menjual barang, mereka mungkin memiliki 1, 7 hingga 2 juta kode harga universal, jadi Anda akan berharap bahwa ini tidak akan menjadi indeks bitmap karena 1, 7 juta nilai berbeda terdengar seperti kardinalitas tinggi. Namun pada kenyataannya, di lingkungan pergudangan data, Anda ingin ini menjadi bitmap. Sekarang, izinkan saya menjelaskan alasannya. Ya, mungkin ada 1, 7 juta nilai berbeda untuk kode harga universal ini, jumlah baris dalam tabel pesanan ini adalah ratusan juta hingga miliaran baris. Indeks saya adalah kardinalitas rendah dibandingkan dengan ukuran atau kardinalitas tabel. Itu membuatnya kardinalitas rendah. Itu membuat indeks bitmap berguna, meskipun bertentangan dengan 1, 7 juta nilai berbeda yang akan Anda pilih bitmap di sini. Sekarang, jika saya tahu bahwa saya ingin menggunakan indeks bergabung bitmap, saat ini produk tidak mendukung itu, saya menambahkannya untuk rilis berikutnya, tetapi itu akan menjadi alternatif lain di sini. Dan dalam skema bintang, ingat, indeks bitmap akan berada di tabel fakta dan bahwa satu indeks di B-tree akan menunjuk ke baris di tabel fakta dan kemudian ke setiap baris yang terlihat di tabel dimensi untuk fakta itu . Jadi, Anda punya pilihan lain di sana. Jadi, mari kita lihat, saya ingin keluar dari meja sekarang dan saya hanya ingin menunjukkan kepada Anda dengan cepat bahwa saya memiliki informasi yang sama, di bawah indeks, dan saya akan melakukan hal dasar yang sama.
Sekarang, alasan saya mengemukakan ini adalah agar Anda memperhatikan, hei tidak ada kunci utama di sini. Kunci primer dilakukan dengan batasan kunci, sehingga sebenarnya ditutupi oleh definisi batasan. Ini akan menjadi indeks yang bukan bagian dari kendala. Sekarang Anda mungkin berkata, "Baiklah, tunggu dulu, itu mungkin terlihat seperti kunci asing, dan kunci asing adalah kendala, " tetapi kunci asing dan sebagian besar basis data tidak secara otomatis membuat indeks pada kolom kunci asing, meskipun itu disarankan, dan begitulah - saya punya semua pilihan yang sama lagi. Dan jika saya ingin mengubah hanya untuk dikompresi, saya bisa melakukannya.
Sekarang kompresi hanya berfungsi pada indeks B-tree. Apa yang memungkinkan adalah, ketika Anda melihat berbagai node di B-tree, memungkinkan untuk kompresi beberapa nilai. Ini sebenarnya bukan kompresi seperti kompresi tabel, ini adalah kompresi dari apa yang disimpan di B-tree di node non-leaf. Itu tidak menghemat banyak ruang, tetapi bisa membuat perbedaan. Dan dengan itu saya perhatikan itu, saya semakin dekat dengan waktu, jadi yang ingin saya lakukan adalah, saya ingin kembali, dan berhenti berbagi. Dan, kami memiliki produk kami di luar sana untuk uji coba empat belas hari di idera.com. Ini adalah produk yang cukup bagus, terutama jika Anda bekerja dengan berbagai platform basis data. Jika Anda bekerja dengan dua atau tiga database berbeda, alat ini akan membuat hidup Anda jauh lebih mudah. Kami memiliki alat untuk membantu Anda dengan desain dan pemilihan indeks, kami memiliki alat yang disebut DB Optimizer. Saya tidak bisa membahasnya hari ini, itu terlalu banyak. Dan jika Anda ingin menghubungi saya, ada alamat email saya, atau Anda dapat menangkap saya di email pribadi saya, dan saya punya blog, saya punya situs web dan blog, dan profil LinkedIn di sana. Jadi jangan ragu untuk menghubungi saya tentang apa pun, bahkan jika itu tidak terkait dengan produk, jika Anda hanya ingin berbicara tentang basis data, saya adalah seorang geek di hati dan saya suka mengobrol tentang masalah teknis.
Eric Kavanagh: Baiklah, baiklah Dez, Robin, saya yakin Anda masing-masing memiliki beberapa pertanyaan, kita masih punya beberapa menit di sini. Dez, bagaimana menurutmu?
Dez Blanchfield: Saya punya satu pertanyaan besar yang harus saya tanyakan, sudah ada di benak saya. Apa skenario paling gila yang pernah Anda lihat? Saya sudah membaca blog Anda, saya mengikuti Anda dengan seksama, - Anda, Anda mungkin salah satu dari sedikit orang yang hidup hampir di setiap kesempatan, dan saya pikir Dr. Robin Bloor adalah orang kedua yang saya temui. seumur hidupku Tapi, Anda tahu, Anda mungkin telah melihat setiap skenario gila, apa saja skenario paling gila yang pernah Anda lihat, yang pernah Anda temui, dan seperti manusia yang tidak bisa mengatasinya, Anda sudah berhasil berjalan dan melakukan trik pikiran Jedi dengan seluruh DBArtisan ini?
Bert Scalzo: Kami pernah memiliki pelanggan yang, dalam desain basis data mereka, mereka sangat memikirkan cara mereka berpikir dalam desain tata letak file, dan, itu - ketika Anda menormalkan basis data, hal pertama yang Anda coba lakukan adalah menyingkirkan kelompok berulang. Yah, mereka memiliki kolom dan mereka membuatnya panjang, atau Gumpalan atau Gumpalan, dan di dalamnya mereka akan memberi nilai, nomor satu, titik koma, nilai nomor dua, titik koma, angka nilai, titik koma, dan mereka akan memiliki ribuan nilai di sana, tetapi mereka perlu mencari di kolom itu dan mereka seperti, "Mengapa hal ini berjalan sangat lambat?" Dan saya seperti, "Yah, Anda tidak dapat membuat indeks pada apa yang Anda lakukan, hanya saja tidak diizinkan. ”Jadi kami benar-benar menunjukkan kepada mereka, menggunakan rencana, bahwa apa yang perlu mereka lakukan adalah menormalkan tabel itu. Bukan karena normalisasi adalah latihan akademis yang membuat segalanya lebih baik, tetapi karena mereka menginginkan kueri di bidang itu, yang berarti mereka ingin dapat mengindeksnya, dan Anda tidak dapat mengindeksnya pada grup berulang, atau setidaknya tidak dengan mudah . Dan mungkin itu hal terburuk yang pernah saya lihat.
Dez Blanchfield: Ya, menarik betapa seringnya Anda bertemu, saya pikir tantangan dengan basis data, orang lupa bahwa itu adalah sains. Dan ada orang yang melakukan gelar dan PhD di seluruh ruang ini, menulis makalah tentang itu, dan Anda telah menulis barang curian termasuk buku pegangan TOAD Anda dan hal-hal lain dari memori. Tren menuju semacam, "data besar" kutipan-on-quote sekarang - Saya melihat banyak orang melupakan dasar-dasar arsitektur database dan teknologi database, ilmu database, jika Anda suka. Apa yang Anda lihat di lapangan sejauh pergeseran dari platform basis data tradisional dan pemikiran basis data tradisional yang telah kami lakukan secara efektif, dan itu hanya masalah penyesuaian dan penskalaan kinerja. Apakah Anda melihat banyak orang belajar kembali dan memiliki pengalaman di mana mereka hanya duduk di sana dan memiliki momen "a-ha", seperti momen eureka, di mana mereka menyadari, data besar ini sebenarnya hanya semacam database yang sangat besar? Apakah itu sesuatu di luar sana dan orang-orang menjawab Anda kembali dan agak, "Kami lupa, apa yang kami ketahui dan dapatkah Anda membawa kami kembali dari sisi gelap?"
Bert Scalzo: Ya, tidak, dan ini mengerikan karena harus semacam mengakui, tetapi vendor database relasional telah minum Kool-Aid juga. Jika Anda ingat, saya tidak tahu, sekitar satu dekade yang lalu, kami mulai memasukkan data tidak terstruktur ke dalam basis data relasional, yang merupakan hal yang aneh untuk dilakukan, dan kemudian data, basis data relasional, sekarang menambahkan tipe NoSQL barang. Bahkan, di Oracle 12, CR2 - Saya tahu itu belum keluar - tetapi jika Anda melihat beta, jika Anda berada di program beta, itu mendukung sharding. Jadi, sekarang Anda punya database relasional yang tidak menambahkan konsep dari sharding NoSQL. Jadi, momen "a-ha" tampaknya lebih untuk orang-orang di sisi relasional yang akan "a-ha." Tidak ada yang akan melakukannya dengan benar lagi, bahkan manajer basis data, jadi kami sudah harus pergi dan bergabung dengan sisi gelap.
Dez Blanchfield: Benar, jadi Anda mengatakan pergeseran ke banyak data yang berantakan, jika saya mengerti benar, dimasukkan ke dalam, apa yang sekarang kita sebut platform data besar, yang agak lucu, karena mereka tidak setua itu, tetapi bukankah itu berarti bahwa mereka memfokuskan kembali pada apa yang mereka lakukan dengan basis data relasional mereka untuk mendapatkan lebih banyak keuntungan?
Bert Scalzo: Tidak, biasanya, jika mereka memiliki kebutuhan dalam - itu akan mengutip "kebutuhan tipe data besar, " mereka menemukan bahwa alih-alih harus pergi ke platform database lain dan melakukan sesuatu dalam -Dengan cara yang rasional, vendor database sekarang memberi mereka teknik non-relasional yang sama di dalam database relasional mereka, untuk melakukan hal-hal itu. Maksud saya, contoh yang baik adalah, jika Anda memiliki data yang tidak terstruktur, seperti tipe data JSON atau tipe data kompleks lainnya yang memiliki makna tertanam dalam data itu sendiri, vendor database tidak hanya mendukung itu, tetapi mereka akan memberi Anda ACID kepatuhan pada data yang tidak terstruktur. Database relasional telah merangkul teknik dan teknologi yang lebih baru sehingga, sekali lagi "a-ha" tampaknya lebih bukan itu, "Hei kami, pengembang aplikasi, telah menghapus sesuatu dan kami perlu mempelajarinya lagi, " itu "Hei", kami melakukannya dengan cara ini sekarang, bagaimana saya bisa melakukannya dengan cara itu dalam database relasional tradisional Anda dan melakukannya seperti yang saya lakukan di database ini di sini? ”dan itu menjadi lebih lazim, dan seperti yang saya katakan, vendor database sendiri memungkinkan bahwa.
Dez Blanchfield: Benar, siapa tersangka tradisional di ruang ini untuk alat DBArtisan dan itu? Saya melakukan beberapa pekerjaan rumah tentang apa yang Anda tulis baru-baru ini, dan dari memori Anda telah menulis sesuatu, saya pikir itu adalah salah satu blog Anda, pada kinerja basis data ekstrem di dunia Oracle. Saya tidak ingat kapan itu, saya pikir itu tahun ini dari ingatan, atau dari akhir tahun lalu, Anda menulis hal ini. Dan bagi saya itu adalah tersangka tradisional yang biasa untuk jenis topik yang kita bicarakan hari ini, di mana orang akan pergi ke lingkungan basis data berskala sangat besar dan mencari apa yang Anda sebut keuntungan ekstrem di dalamnya. Siapa tersangka yang biasa Anda temui di luar sana yang menerima DBArtisan dan memanfaatkannya dengan baik?
Bert Scalzo: Ya, kami memiliki banyak pelanggan, pada kenyataannya, hari ini saya bersama agensi pemerintah yang sangat besar - dan mereka mungkin benar-benar mendekati 1.000 salinan perangkat lunak kami, karena itu memungkinkan orang untuk fokus pada apa yang mereka lakukan. sedang melakukan, dan bukan bagaimana melakukannya. Dan tidak apa-apa, maksud saya, semua orang harus tahu bagaimana melakukan sesuatu, tetapi produktivitas adalah "apa" yang dilakukan. Jika bisnis meminta saya melakukan tugas, itu saja yang membuat mereka tertarik. Kapan saya mendapatkan tanda centang untuk mengatakan kapan tugas itu dilakukan? Bukan teknik apa atau technobabble apa yang saya gunakan untuk sampai ke sana. Jadi, alat kami membuat mereka fokus pada apa, dan membuat mereka jauh lebih produktif, dan itu benar-benar keuntungan besar, dan seperti yang saya katakan, beberapa basis data menawarkan alat hanya untuk platform basis data mereka. Kami menawarkannya untuk dua belas platform basis data. Saya memiliki alur kerja yang sama, antarmuka pengguna grafis yang sama, navigasi yang sama. Jika Anda tahu cara memberikan hak istimewa kepada pengguna atau cara membuat tabel atau membuat indeks dalam database, Anda bisa melakukannya di semua dua belas karena itu terlihat dan terasa sama dan alur kerja yang sama. Itu memiliki nilai besar bagi pelanggan kami.
Dez Blanchfield: Ya, saya kira, orang ingin mendapatkan lebih banyak uang dari sumber daya manusia mereka. Dan hari-hari memiliki spesialis perorangan di Oracle, Ingres dan DB2 semuanya hilang. Orang-orang diharapkan menjadi Jack dari semua perdagangan, jadi saya pikir hal ini benar-benar menyelamatkan hidup mereka.
Hanya satu hal cepat terakhir sebelum saya serahkan ke Dokter Robin Bloor. Anda menyebutkan ada unduhan gratis selama empat belas hari, apa yang terjadi - jika saya akan melanjutkan dan saya akan melakukannya, ngomong-ngomong, saya akan meletakkannya di lab teknologi Bloor dan memutar benda ini berdiri dan dapatkan sendiri - saya belum punya kesempatan untuk melakukan itu sebelum hari ini. Anda menyebutkan uji coba empat belas hari, Anda mengatakan Anda menjalankannya pada VM di komputer Anda, saya berasumsi itu laptop. Apa sajakah, seperti apa pengaturan entry-level bagi seseorang untuk digunakan dan menggunakan tampilan uji coba empat belas hari, tepat sebelum saya kembali ke Robin untuk pertanyaannya?
Bert Scalzo: Setiap lingkungan Windows, demikian juga Windows 7, mesin virtual dengan satu CPU dan empat pertunjukan memori. Kami bukan alat yang sangat gemuk atau mahal. Sekarang jika Anda ingin menjalankan server database Anda pada VM yang sama di bawah Windows yang sama, ya, Anda perlu menambahkan lebih banyak, tetapi jika Anda menjalankan database Anda pada server database atau pada VM yang terpisah, VM untuk memuat dan menjalankan produk kami sangat ringan: satu CPU, empat gigs memori, hampir semua versi Windows - dan kami mendukung pemasangan tiga puluh dua dan enam puluh empat bit. Tetapi Anda harus menginstal klien vendor database Anda. Jadi jika Anda ingin terhubung ke Oracle, Anda harus menginstal SQL net client, karena itulah yang diperlukan Oracle agar Anda dapat berbicara dengan database.
Dez Blanchfield: Kedengarannya sangat mudah. Saya pikir satu hal dari ini lebih dari apa pun yang saya harap orang-orang akan ambil, selain kesadaran bahwa alat ini akan menyelamatkan hidup mereka, adalah mereka harus pergi dan mengunduhnya dan bermain dengannya, mengingat bahwa Anda menawarkan uji coba gratis empat belas hari. Dan itu dapat berjalan di laptop mereka saat ini tanpa menginstal apa pun tambahan, karena jika mereka sudah melakukan administrasi database, mereka sudah bekerja dengan database mereka punya semua alat di tempat dan apakah itu berjalan pada VM lokal atau pada mereka desktop lokal, sepertinya tidak ada masalah untuk menginstal dan bermain. Jadi saya sangat merekomendasikan orang melakukan itu.
Robin, saya yakin Anda punya pertanyaan dan Eric, Anda mungkin mendapat beberapa dari hadirin, jadi Robin, bagaimana kalau saya sampaikan kepada Anda, dan kemudian kembali ke Eric?
Robin Bloor: Ya, oke, saya punya banyak hal untuk dikatakan, maksud saya, saya selalu menemukan daerah ini menarik karena - Saya memotong gigi saya di atasnya. Tetapi kenyataannya adalah, mungkin sejak sekitar tahun 1998, 1999, saya telah terpaut pada apa yang sebenarnya mampu dilakukan oleh Oracle. Dan, saya tahu Sybase dan Microsoft SQL Server, keduanya cukup sederhana dibandingkan dengan apa yang bisa dilakukan Oracle. Anda membuat saya tertawa ketika Anda - maksud saya, saya menutup mulut saya, ketika Anda mulai berbicara tentang sharding. Oracle melakukan ini sebelumnya. Oracle memperkenalkan pada beberapa titik waktu, mereka merasa gugup dengan ide objek-relasional, jadi mereka memperkenalkan kemampuan untuk membuat semacam notasi objek dan penyimpanan objek di Oracle, dan saya berbicara dengan salah satu insinyur mereka, sesuatu seperti beberapa bertahun-tahun setelah mereka memperkenalkannya dan saya bertanya berapa banyak orang yang menggunakannya, dan dia bilang saya pikir dua pelanggan sudah mencobanya dan hanya itu. Dan saya pikir hal yang sama akan terjadi jika mereka mulai mencoba dan melakukan trending hal-hal NoSQL. Anda tahu, saya pikir itu kesalahan, maksud saya, saya agak tertarik dengan apa yang Anda pikirkan. Tentu saja - mereka minum Kool-Aid. Mereka merasa seolah-olah mereka harus dapat membuat klaim yang mirip dengan database NoSQL besar seperti Cassandra, tetapi Anda tahu, apakah itu masuk akal bagi Anda?
Bert Scalzo: Tidak, Anda telah memukul paku tepat di kepala. Bagi saya, saya akan, jika saya akan melakukan relasional, saya akan memilih vendor relasional seperti Oracle atau SQL Server atau DB2 atau Postgres, tetapi jika saya akan melakukan sesuatu yang non-relasional, di ruang data besar, atau ruang NoSQL, saya akan memilih alat yang tepat untuk pekerjaan yang tepat. Dan saya tidak berpikir bahwa itu akan secara alami pergi ke vendor basis data relasional saya terlebih dahulu. Dan kemudian, Anda menambahkan kerutan lainnya ke dalamnya, yaitu, apa yang tersedia di cloud? Begitu banyak orang yang ingin mendapatkan basis data mereka. Maka Anda harus melihat penyedia cloud Anda dan berkata, "Oke, apa penyedia Anda, database apa yang Anda miliki untuk saya yang sesuai dengan kebutuhan saya dan seberapa laku mereka, dan terus terang berapa tarif atau biaya untuk menggunakan database itu di awan per jam, atau per hari. Dan per gigabyte atau terabyte? ”Dan apa yang akan Anda temukan adalah mungkin beberapa database yang relatif lebih baru seperti Mongo atau Cassandra, mungkin tarifnya lebih murah, jadi jika Anda akan melakukan data besar multi-petabyte, Anda mungkin harus - hanya dari sudut pandang biaya - harus mempertimbangkan basis data NoSQL di cloud karena mereka mungkin cara yang paling hemat biaya untuk melakukannya.
Robin Bloor: Ya, benar. Maksud saya, jenis saya - hal tentang database relasional dalam pengalaman saya - yang cukup lama untuk memiliki bekas luka, itu sudah pasti - ada banyak akal sehat bahwa jika Anda mulai menerapkannya dan - Anda memahami apa sebenarnya hubungan itu, bahwa Maksudku, aku ingat akan melakukan konsultasi dengan satu pelanggan sekali, dan mereka membawaku ke sebuah ruangan dan mereka telah melakukan semacam diagram entitas dan menciptakan bentuk normal ketiga, model seperti apa sistem utama perusahaan itu. Itu memiliki dua ratus empat puluh meja dan mereka berkata, “Bagaimana menurutmu? Kami akan membangun database untuk ini, "dan berkata, " Apa pendapat Anda tentang hal itu? "Saya berkata, " Saya pikir itu tidak akan berhasil. "Dan itu benar, Anda tahu, karena mereka berakhir untuk membuat struktur tertentu dalam gabungan sebelas arah. Dan itu hal yang perlu dipahami tentang relasional. Jadi saya agak tertarik dalam hal seberapa buruk desain yang Anda temui. Maksud saya, saya tidak punya masalah dengan DBArtisan - itu melakukan hal-hal yang sangat masuk akal dan fakta bahwa Anda benar-benar dapat ditampilkan di berbagai platform, saya pikir, luar biasa - tetapi berapa banyak yang Anda temui di luar sana di mana desainnya menjadi masalah di mana orang bisa memecahkan sendiri segala macam sakit hati jika mereka datang ke skema bintang daripada mendapatkan kepingan salju-y tentang hal itu, Anda tahu?
Bert Scalzo: Ya, saya tidak ingin terdengar seperti, sombong atau sombong, tetapi saya akan mengatakan lebih sering daripada tidak. Jelas, sebagian besar database yang saya terlibat di luar sana, mereka memiliki masalah atau masalah. Yang bagus, karena alat kami, seperti alat pengoptimal database kami, dapat membantu mereka untuk menyelesaikan masalah tersebut, dan, tapi yang benar-benar lucu bagi saya, adalah bahwa banyak masalah adalah masalah sederhana yang sama berulang-ulang. Saya hanya bekerja dengan seorang pelanggan di suatu hari yang memiliki sebelas cara bergabung dengan permintaan, dan saya seperti, "Oke, mengapa Anda tidak menggunakan klausa dengan?" Dan mereka seperti, "Ya, saya tidak tahu apa itu. "Dan kemudian saya berkata, " Dan lihat sub-seleksi Anda di sini pada Anda yang berkorelasi dan non-berkorelasi Anda, "kataku, " Dalam beberapa kasus Anda memiliki klausa di mana Anda berada di tingkat mana yang paling dalam, referensi tabel membentuk bagian luar. "Saya berkata, " Itu, pindahkan ke tingkat yang tepat, jangan tanamkan lebih dalam dari yang seharusnya, Anda akan membingungkan pengoptimal. "Dan dengan beberapa penyesuaian kami mengambil sesuatu yang berjalan sekitar dua jam dan mendapatkannya hingga sepuluh menit dan itu hanya - dalam hal ini kami tidak melakukan apa pun selain meningkatkan SQL yang telah mereka tulis. Saya pikir masalahnya adalah bahwa banyak universitas dan banyak orang yang belajar pemrograman dalam lingkungan non-akademik, mereka mempelajarinya sebagai proses waktu yang direkam atau proses yang berorientasi baris dan relasional adalah himpunan yang berorientasi pada alam, dan oleh karenanya Anda harus berpikir dalam set untuk menulis SQL yang bagus.
Robin Bloor: Ya, saya pikir itu benar sekali. Dan Anda harus mengerti, itu hal-hal seperti, orang harus tahu ABC hal-hal seperti ini. Itu tidak masalah. Anda tidak akan dapat melakukan hal-hal yang rasional jika Anda tidak menyadari bahwa bahkan database yang dirancang dengan baik dan dimodelkan dengan baik, bergabung akan membutuhkan waktu, jenis akan membutuhkan waktu. Mereka melakukannya karena dunia tidak pernah menemukan cara untuk membuat mereka berjalan cepat. Mereka telah menemukan cara mengatur data sehingga mereka pergi lebih cepat daripada yang lain, dan banyak antusiasme yang harus saya katakan untuk database NoSQL hanyalah bahwa mereka menghindari melakukan penggabungan. Mereka baru saja mulai membangun basis data dengan penyebaran data yang sama di dalamnya, karena jika Anda bergabung dengan salah satu basis data NoSQL, mereka akan sangat payah. Bukankah begitu?
Bert Scalzo: Oh, tentu saja. Dan saya harus tertawa karena, saya mulai jauh sebelum database relasional dan kembali ketika Ingres adalah RTI, Institut Teknologi Relasional, dan kami tidak memiliki SQL, kami memiliki bahasa relasional pra-SQL. Saya pikir di Ingres, saat itu, itu disebut Quel. Jadi Anda dapatkan dari paradigma basis data lama seperti jaringan dan grafik yang lebih tinggi, atau hierarkis, dan Anda melewati paradigma relasional setelah beberapa dekade dan sekarang bagi saya rasanya seperti kita akan kembali ke hampir hierarkis lagi. Ini hampir seperti kita telah kembali.
Robin Bloor: Ya, benar. Lebih baik menyerahkanmu pada Eric, aku menghabiskan terlalu banyak waktu, tetapi apakah kita punya pertanyaan dari penonton, Eric?
Eric Kavanagh: Ya, kami punya beberapa. Kami akan agak lama di sini tapi aku akan melemparkan beberapa padamu. Kami memiliki beberapa pertanyaan di sekitar indeks yang tidak terlihat. Satu pertanyaan adalah, "Apakah seseorang perlu menggunakan alat Anda untuk melihatnya?" Pertanyaan lain adalah, "Nah, bagaimana jika Anda buta?"
Bert Scalzo: Itu bagus.
Eric Kavanagh: Pertanyaan aneh juga, jadi hanya FYI.
Bert Scalzo: Tidak, Anda tidak harus memiliki alat kami. Itu fitur Oracle, indeks tidak terlihat. Pada dasarnya di kamus data, Oracle hanya menyimpan sepotong metadata yang mengatakan, “Pengoptimal, abaikan indeks ini. Itu ada di sini, tetapi kecuali jika Anda secara fisik diinstruksikan melalui petunjuk dalam, petunjuk pengoptimal dalam perintah SQL, jangan gunakan ini. "Jadi, tidak, Anda tidak harus memiliki alat kami, dan dalam segala hal itu adalah indeks lama yang biasa, Anda dapat melihatnya di alat apa pun, hanya saja pengoptimal akan mengatakan, "Kami akan mengabaikannya dalam pemrosesan permintaan normal." Anda harus mengarahkannya jika Anda ingin digunakan. Ini sangat berguna untuk skenario yang saya jelaskan yaitu, jika Anda ingin membangun indeks dalam produksi tetapi tidak berisiko melanggar laporan, atau hal-hal yang sudah berjalan, tetapi Anda ingin mengujinya, Anda bisa melakukannya. Itulah gunanya yang paling berguna.
Eric Kavanagh: Itu hal yang bagus dan kemudian ada pertanyaan bagus di sini. “Bagaimana dengan beberapa dari database di memori yang baru ini? Bagaimana teknologi basis data dalam memori mengubah game sehubungan dengan pengindeksan? "
Bert Scalzo: Boy, well we – now that's a good, I'm glad someone asked that question, we're going to have to go another half hour. No, the in-memory, it depends on the database vendor. Now, normally, I am, I speak nothing but praise of anything that Oracle does because it's amazing the technology they've built, but when you tear back under the covers and you look at what in-memory is in Oracle, in the Oracle database, what it is in reality is it still kept row store on disk, and it will get loaded column-store in-memory, and if there's insufficient memory to hold the whole table, it will revert back to for the portions; it won't fit in memory, to doing it row store, and so you could actually do a select against the table and for half the table, you 're using an indexing hitting traditional rows at the table, and for the other half of the select it's actually going out and just grabbing everything from an in-memory search, and so, it's different in the way that SQL Server, for example, implemented it with their Hekaton technology, you know, and SQL 2014, and it's been improved in SQL 2016, but in some respects, theirs is a more true version of in-memory, and, but each implementation has a pros and cons, but you have to kind of look under the covers and realize. Because, I had a customer who said, “Oh this table's in-memory – I'm just going to draw up all the indexes, ” and I'm like, “The table's bigger than the memory that you have on the server, so at some point some of the query's got to hit disk.”
Eric Kavanagh: That's a good description; that's good stuff. Well, folks, we're going to have a few more webcasts with these guys over the rest of this year, come back anytime you hear of Bert being on a presentation because we know he knows his stuff. It's always fun to talk to the experts. We do archive all these webcasts for later viewing. Here's Bert's contact information once again, and we'll try to dig up that link for the download and send it out as well by email, but you can always email yours truly:, we've got a bunch more webcasts lined up for this year and we're doing the ed cal right now, so, folks, if there's any topics you really want to hear about next year, don't be shy: Take care, folks, we'll talk to you next time. Sampai jumpa.
Mitra Konten Techopedia
Staf Techopedia berafiliasi dengan Bloor Group dan dapat dihubungi menggunakan opsi di sebelah kanan. Untuk info tentang cara kami bekerja dengan mitra industri klik di sini.- Profil
- Situs web
