Veri kümenizin boyutu arttıkça dizine eklemenin çok önemli olduğu göz önüne alındığında, birisi veritabanının agnostik düzeyde dizinin nasıl çalıştığını açıklayabilir mi?
Bir alanı dizine ekleme sorguları hakkında bilgi için Bir veritabanı sütununu nasıl dizinlerim ?
Yanıtlar:
Neden gerekli?
Veriler disk tabanlı depolama aygıtlarında depolandığında, veri blokları olarak saklanır. Bu bloklara bütünüyle erişilerek atomik disk erişim işlemi yapılır. Disk blokları, bağlantılı listelerle aynı şekilde yapılandırılmıştır; her ikisi de veri için bir bölüm, bir sonraki düğümün (veya bloğun) konumunu gösteren bir işaretçi içerir ve her ikisinin de bitişik olarak depolanması gerekmez.
Bir dizi kaydın yalnızca bir alanda sıralanabilmesi nedeniyle, sıralanmamış bir alanda arama yapmanın N/2blok Nerişimi (ortalama) gerektiren Doğrusal Arama gerektirdiğini (ortalama olarak), masa açık. Bu alan anahtar olmayan bir alansa (başka bir deyişle benzersiz girişler içermiyorsa), Nblok erişimlerinde tablo alanının tamamı aranmalıdır .
Sıralı bir alanla birlikte, log2 Nblok erişimi olan bir İkili Arama kullanılabilir . Ayrıca, veriler anahtar olmayan bir alana göre sıralandığından, daha yüksek bir değer bulunduğunda tablonun geri kalanının yinelenen değerler için aranması gerekmez. Böylece performans artışı büyüktür.
Endeksleme nedir?
Dizin oluşturma, birden çok alanda birkaç kaydı sıralamanın bir yoludur. Tablodaki bir alanda dizin oluşturmak, alan değerini tutan başka bir veri yapısı ve ilişkili kayıt için bir işaretçi oluşturur. Bu indeks yapısı daha sonra, Binary Search'lerin üzerinde yapılmasına izin verilerek sıralanır.
Endekslemenin dezavantajı, endekslerin MyISAM motorunu kullanan bir tabloda birlikte depolandığından, bu endekslerin diskte ek alan gerektirmesidir, aynı tablodaki birçok alan dizine eklendiğinde bu dosya temel dosya sisteminin boyut sınırlarına hızla ulaşabilir .
O nasıl çalışır?
İlk olarak, örnek bir veritabanı tablosu şemasının ana hatlarını çizelim;
Alan adı Veri türü Diskteki boyut id (Birincil anahtar) İmzasız INT 4 bayt firstName Karakter (50) 50 bayt lastName Karakter (50) 50 bayt Adres Char (100) 100 bayt
Not : char, disk değerinde doğru bir boyuta izin vermek için varchar yerine kullanılmıştır. Bu örnek veritabanı beş milyon satır içerir ve dizinsizdir. Şimdi birkaç sorgunun performansı analiz edilecektir. Bunlar id (sıralanmış anahtar alanı) ve firstName (anahtar olmayan sıralanmamış alan) kullanan bir sorgudur .
Örnek 1 - sıralanmamış alanlara göre sıralanmış
r = 5,000,000Sabit bir boyuttaki kayıtların örnek veritabanımıza göre, kayıt uzunluğu R = 204bayt verir ve bunlar varsayılan blok boyutu B = 1,024baytlarını kullanan MyISAM motoru kullanılarak bir tabloda saklanır . Tablonun engelleme faktörü bfr = (B/R) = 1024/204 = 5disk bloğu başına kayıt olacaktır . Tabloyu tutmak için gereken toplam blok sayısı N = (r/bfr) = 5000000/5 = 1,000,000bloktur.
Kimlik alanındaki bir doğrusal arama, id alanının N/2 = 500,000anahtar bir alan olduğu göz önüne alındığında, bir değer bulmak için ortalama bir blok erişimi gerektirir. Ancak kimlik alanı da sıralandığından, ortalama log2 1000000 = 19.93 = 20blok erişimi gerektiren bir ikili arama gerçekleştirilebilir . Anında bunun ciddi bir gelişme olduğunu görebiliriz.
Artık firstName alanı ne sıralanmış ne de anahtar alandır, bu nedenle ikili bir arama imkansız değildir ve benzersiz değerler değildir ve bu nedenle tablo, tam bir N = 1,000,000blok erişimi için sonuna kadar arama yapmayı gerektirecektir . Endekslemenin düzeltmeyi amaçladığı durum budur.
Bir dizin kaydının yalnızca dizinlenmiş alanı ve orijinal kaydın işaretçisini içerdiği göz önüne alındığında, işaret ettiği çok alanlı kayıttan daha küçük olacağı anlamına gelir. Bu nedenle dizinin kendisi orijinal tablodan daha az disk bloğu gerektirir, bu nedenle yineleme için daha az blok erişimi gerektirir. FirstName alanındaki bir dizinin şeması aşağıda özetlenmiştir;
Alan adı Veri türü Diskteki boyut firstName Karakter (50) 50 bayt (kayıt işaretçisi) Özel 4 bayt
Not : MySQL'deki işaretçiler tablonun boyutuna bağlı olarak 2, 3, 4 veya 5 bayt uzunluğundadır.
Örnek 2 - Dizinleme
r = 5,000,000Endeks kaydı uzunluğu R = 54bayt ve varsayılan blok boyutu B = 1,024bayt kullanan kayıt örnek veritabanımız verildi . Dizinin engelleme faktörü, bfr = (B/R) = 1024/54 = 18disk bloğu başına kayıt olacaktır . Dizini tutmak için gereken toplam blok sayısı N = (r/bfr) = 5000000/18 = 277,778bloktur.
Artık firstName alanını kullanan bir arama, performansı artırmak için dizini kullanabilir. Bu, ortalama log2 277778 = 18.08 = 19blok erişimi olan dizinin ikili aramasına izin verir . Okumak için daha fazla blok erişimi gerektiren gerçek blok adresini bulmak için toplam erişimi blok erişimine getirerek, dizinlenmemiş tabloda 19 + 1 = 20bir firstName eşleşmesi bulmak için gereken 1.000.000 blok erişiminden çok daha fazla ağlama gerekir .
Ne zaman kullanılmalıdır?
Bir dizin oluşturmanın ek disk alanı gerektirdiği (yukarıdaki örnekten 277.778 blok daha fazla, ~% 28 artış) ve çok fazla endeksin dosya sistemleri boyut sınırlarından kaynaklanan sorunlara neden olabileceği göz önüne alındığında, doğru seçimi seçmek için dikkatli düşünülmelidir dizine eklenecek alanlar.
Endeksler yalnızca kayıtlar içinde eşleşen bir alanı aramayı hızlandırmak için kullanıldığından, yalnızca çıktı için kullanılan indeksleme alanlarının bir ekleme veya silme işlemi yaparken basitçe bir disk alanı ve işlem süresi kaybı olması ve dolayısıyla kaçınılmalıdır. İkili bir araştırmanın doğası da dikkate alındığında, verilerin kardinalitesi veya tekliği önemlidir. Kardinalitesi 2 olan bir alanda endeksleme, verileri ikiye bölerken, 1.000'lik bir kardinalite yaklaşık 1.000 kayıt döndürür. Böyle düşük bir kardinalite ile etkinlik doğrusal bir sıraya indirgenir ve kardinalite kayıt numarasının% 30'undan azsa, sorgu optimize edici endeksi kullanmaktan kaçınır ve endeksi etkin bir şekilde alan kaybı haline getirir.
(N+1)/2. Mümkün olan tüm durumlar için blok erişim sayısını toplar ve bunu vaka sayısına böldüğümüzde, N*(N+1)/(2*n)hangisi olduğu ortaya çıkar (N+1)/2.
Klasik örnek "Kitaplarda Dizin"
Her biri 100 sayfalık 10 bölüme ayrılmış 1000 sayfalık bir "Kitap" düşünün.
Basit, ha?
Şimdi, " Simyacı " kelimesini içeren belirli bir Bölümü bulmak istediğinizi düşünün . Dizin sayfası olmadan, tüm kitabı / Bölümleri taramaktan başka seçeneğiniz yoktur. yani: 1000 sayfa.
Bu benzetme veritabanı dünyasında "Tam Tablo Taraması" olarak bilinir .
Ancak bir dizin sayfasıyla nereye gideceğinizi biliyorsunuz! Ve dahası, önemli olan herhangi bir Bölümü aramak için, dizin sayfasını her seferinde tekrar tekrar gözden geçirmeniz gerekir. Eşleşen dizini bulduktan sonra geri kalanını atlayarak bu bölüme etkili bir şekilde atlayabilirsiniz.
Ancak, gerçek 1000 sayfaya ek olarak, endeksleri göstermek için başka bir ~ 10 sayfaya ihtiyacınız olacak, bu yüzden toplam 1010 sayfa.
Bu nedenle, dizin, verimli aramalar için dizinlenmiş sütun + işaretçisi değerlerini dizinlenmiş satıra sıralı bir sırayla depolayan ayrı bir bölümdür.
Okullarda işler basit, değil mi? : P
Libraryya da Grocery Store bir markette bir indekse sahip değil misiniz? Where's The Beef?!? Oh its next to the Restrooms, a mop, and makeup
Bunu ilk okuduğumda bana çok yardımcı oldu. Teşekkür ederim.
O zamandan beri dizin oluşturmanın dezavantajı hakkında bir fikir edindim: bir dizine sahip bir tabloya ( UPDATEveya INSERT) yazarsanız, dosya sisteminde aslında iki yazma işleminiz vardır. Biri tablo verileri için, diğeri de dizin verileri için (ve bunun başvurusu (ve - kümelenmişse - tablo verilerinin tesisi)). Tablo ve dizin aynı sabit diskte bulunuyorsa, bu daha fazla zaman alır. Böylece indeksi olmayan bir tablo (yığın), daha hızlı yazma işlemlerine izin verir. (iki dizininiz varsa, üç yazma işlemiyle sonuçlanırsınız vb.)
Ancak, dizin verileri ve tablo verileri için iki farklı sabit diskte iki farklı konum tanımlamak, zaman maliyetinin artması sorununu azaltabilir / ortadan kaldırabilir. Bu, istenen sabit disklerdeki dosyalara göre ek dosya gruplarının tanımlanmasını ve istenen şekilde tablo / dizin konumunun tanımlanmasını gerektirir.
Dizinlerle ilgili bir başka sorun, veri eklendikçe zaman içinde parçalanmasıdır. REORGANIZEyardımcı olur, bunu yapmak için rutinleri yazmanız gerekir.
Belirli senaryolarda bir yığın, dizinleri olan bir tablodan daha yararlıdır,
Örneğin: - Çok sayıda rakip yazınız varsa ancak raporlama için çalışma saatlerinin dışında yalnızca bir gece okuyun.
Ayrıca, kümelenmiş ve kümelenmemiş dizinler arasındaki bir ayrım oldukça önemlidir.
Bana yardımcı oldu: - Kümelenmiş ve Kümelenmemiş dizin aslında ne anlama geliyor?
Dizin, yalnızca veritabanındaki belirli bir sütunda aramayı daha hızlı hale getiren bir veri yapısıdır. Bu yapı genellikle bir b-ağacı veya bir karma tablodur, ancak başka bir mantık yapısı olabilir.
Şimdi diyelim ki 'Abc' olarak adlandırılan çalışanların tüm ayrıntılarını bulmak için bir sorgu çalıştırmak istiyoruz?
SELECT * FROM Employee
WHERE Employee_Name = 'Abc'
Endeks olmadan ne olur?
Veritabanı yazılımının tam olarak bu tablodaki Çalışan_Adı'nın 'Abc' olup olmadığını görmek için Çalışan tablosundaki her bir satıra bakması gerekir. Biz de içinde adı 'Abc' ile her satır istiyoruz çünkü biz adı 'Abc' ile sadece bir satır bulduktan sonra adı ile diğer satırlar olabilir çünkü, biz sadece bakarak duramazsın Abc . Bu nedenle, son satıra kadar her satır aranmalıdır - yani bu senaryoda binlerce satır 'Abc' adındaki satırları bulmak için veritabanı tarafından incelenmelidir. Buna tam tablo taraması denir
Bir veritabanı dizini performansa nasıl yardımcı olabilir?
Bir endekse sahip olmanın asıl amacı, incelenmesi gereken bir tablodaki kayıt / satır sayısını azaltarak arama sorgularını hızlandırmaktır. Dizin, bir tablodaki belirli bir sütunun değerlerini depolayan bir veri yapısıdır (çoğunlukla bir B ağacı).
B-ağaçlar endeksi nasıl çalışır?
B-ağaçlarının indeksler için en popüler veri yapısı olmasının nedeni zaman etkili olmalarıdır - çünkü aramalar, silmeler ve eklemeler logaritmik zamanda yapılabilir. Ve B-ağaçlarının daha yaygın kullanılmasının bir başka önemli nedeni, B-ağacı içinde saklanan verilerin sıralanabilmesidir. RDBMS tipik olarak bir dizin için gerçekte hangi veri yapısının kullanılacağını belirler. Ancak, bazı RDBMS'leri içeren bazı senaryolarda, dizinin kendisini oluştururken veritabanınızın hangi veri yapısını kullanmasını istediğinizi belirtebilirsiniz.
Karma tablo dizini nasıl çalışır?
Hash indekslerinin kullanılmasının nedeni, hash tablolarının sadece değerlere bakma konusunda son derece verimli olmasıdır. Bu nedenle, bir dizeyle eşitliği karşılaştıran sorgular, bir karma dizini kullanıyorsa değerleri çok hızlı alabilir.
Örneğin, daha önce tartıştığımız sorgu Employee_Name sütununda oluşturulan bir karma dizinden yararlanabilir. Bir karma indeksinin çalışma şekli, sütun değerinin karma tablonun anahtarı olacağı ve bu anahtara eşlenen gerçek değerin sadece tablodaki satır verilerine bir işaretçi olacağıdır. Bir karma tablo temel olarak ilişkilendirilebilir bir dizi olduğundan, tipik bir girdi “Abc => 0x28939 ″ gibi bir şeye benzeyecektir; burada 0x28939, Abc'nin bellekte depolandığı tablo satırına bir referanstır. Karma tablo dizininde “Abc” gibi bir değere bakmak ve bellekteki satıra geri dönmek, Employee_Name sütununda “Abc” değerine sahip tüm satırları bulmak için tabloyu taramaktan çok daha hızlıdır.
Bir karma endeksinin dezavantajları
Karma tablolar sıralı veri yapıları değildir ve karma indekslerinin bile yardımcı olamadığı birçok sorgu türü vardır. Örneğin, 40 yaşın altındaki tüm çalışanları bulmak istediğinizi varsayalım. Karma tablo dizini ile bunu nasıl yapabilirsiniz? Bu mümkün değil çünkü bir karma tablo yalnızca anahtar / değer çiftlerini aramak için iyidir - bu eşitliği kontrol eden sorgular anlamına gelir
Veritabanı dizininin içinde tam olarak ne var? Böylece, artık bir tablodaki bir sütunda bir veritabanı dizini oluşturulduğunu ve dizinin bu belirli sütundaki değerleri depoladığını biliyorsunuz. Ancak, bir veritabanı dizininin değerleri aynı tablonun diğer sütunlarına kaydetmediğini anlamak önemlidir. Örneğin, Employee_Name sütununda bir dizin oluşturursak, bu, Employee_Age ve Employee_Address sütun değerlerinin de dizinde depolanmadığı anlamına gelir. Diğer tüm sütunları dizinde saklasaydık, tablonun tamamının başka bir kopyasını oluşturmak gibi olurdu - ki bu çok fazla yer kaplar ve çok verimsiz olurdu.
Bir veritabanı ne zaman endeks kullanılacağını nasıl bilir? “SELECT * FROM Employee WHERE Employee_Name = 'Abc'” gibi bir sorgu çalıştırıldığında, veritabanı sorgulanan sütunlarda bir dizin olup olmadığını kontrol eder. Employee_Name sütununun üzerinde bir dizin oluşturulduğunu varsayarsak, veritabanı, aranan değerleri bulmak için dizini kullanmanın gerçekten anlamlı olup olmadığına karar vermek zorundadır - çünkü veritabanı dizinini kullanmanın daha az verimli olduğu bazı senaryolar vardır ve tüm tabloyu taramak için daha verimlidir.
Veritabanı indeksine sahip olmanın maliyeti nedir?
Yer kaplar - tablonuz ne kadar büyükse, dizininiz o kadar büyük olur. Dizinlerle bir başka performans isabeti, ilgili tablodaki satırları her eklediğinizde, sildiğinizde veya güncellediğinizde, dizininize aynı işlemlerin yapılması gerektiğidir. Bir dizinin, dizinin kapsadığı tablo sütun (ları) ndakilerle aynı dakika verilerini içermesi gerektiğini unutmayın.
Genel bir kural olarak, bir dizin yalnızca dizinlenmiş sütundaki veriler sık sık sorgulanacaksa bir tabloda oluşturulmalıdır.
Ayrıca bakınız
CREATE INDEX ... INCLUDEyan tümcesini denetleyin . Bence cevabınızda çok fazla genelleme var.
create indexolarak diğer sütunları ve neden olması gerektiğini içermez. If we did just store all the other columns in the index, then it would be just like creating another copy of the entire table, which would take up way too much space and would be very inefficient.. Bu, dizinlerin daha genelleştirilmiş sürümüdür. CREATE INDEX ... INCLUDEdiğer sütunları dikkate alarak yeni sürümdür. Post Açıkladığım daha genel bir versiyon düşünüyor. Tüm veritabanlarını dikkate alırsak dizinler nasıl bir kitap olur? Öyle değil mi? Sizce cevap inmeyi hak ediyor mu?
Dizin, bir tabloda belirli bir sütunun değerlerini depolayan bir veri yapısından başka bir şey değildir . Bir tablonun sütununda bir dizin oluşturulur.
Örnek: UserÜç sütunlu - Name, Ageve adlı bir veritabanı tablonuz var Address. UserTablonun binlerce satırı olduğunu varsayın .
Şimdi diyelim ki 'John' adlı kullanıcıların tüm ayrıntılarını bulmak için bir sorgu çalıştırmak istiyoruz. Aşağıdaki sorguyu çalıştırırsak:
SELECT * FROM User
WHERE Name = 'John'
Veritabanı yazılımı, kelimenin tam anlamıyla Usertablodaki her bir satıra bakmak zorunda kalacaktır Name. Bu uzun zaman alacaktır.
Burası indexbize yardımcı olur: dizin, incelenmesi gereken bir tablodaki kayıt / satır sayısını azaltarak arama sorgularını hızlandırmak için kullanılır .
Dizin nasıl oluşturulur:
CREATE INDEX name_index
ON User (Name)
A index, bir tablodaki sütun değerlerinden (Örn: John) oluşur ve bu değerler bir veri yapısında saklanır .
Şimdi veritabanı, John adlı çalışanları bulmak için dizini kullanacaktır çünkü dizin muhtemelen Kullanıcılar adına göre alfabetik olarak sıralanacaktır. Ve sıralandığından, bir ad aramanın çok daha hızlı olduğu anlamına gelir çünkü “J” ile başlayan tüm isimler dizinde hemen yan yana olacak!
Sadece hızlı bir öneri .. İndeksleme ek yazma ve depolama alanı maliyeti olarak, uygulamanız daha fazla ekleme / güncelleme işlemi gerektiriyorsa, dizinsiz tablolar kullanmak isteyebilirsiniz, ancak daha fazla veri alma işlemi gerektiriyorsa, dizinli tablo.
Veritabanı Dizini'ni bir kitabın Dizini olarak düşünün.
Köpekler hakkında bir kitabınız varsa ve diyelim ki Alman Çobanları hakkında bir bilgi bulmak istiyorsanız, elbette kitabın tüm sayfalarını çevirebilir ve aradığınızı bulabilirsiniz - ama bu elbette zaman alıcı ve değil çok hızlı.
Başka bir seçenek de, kitabın Dizin bölümüne gidip aradığınız varlığın adını (bu örnekte, Alman Çobanları) kullanarak ve aradığınız sayfa numarasına bakarak aradığınızı bulabilmenizdir. aradığınızı çabucak bulun.
Veritabanında sayfa numarasına, veritabanını varlığın bulunduğu diskteki adrese yönlendiren bir işaretçi denir. Aynı Alman Çoban benzetmesini kullanarak, böyle bir şeye sahip olabiliriz (“Alman Çoban”, 0x77129), burada 0x77129Alman Çoban için satır verilerinin depolandığı adres.
Kısacası, bir dizin, sorgu aramayı hızlandırmak için belirli bir sütunun değerlerini bir tabloda depolayan bir veri yapısıdır.