Veritabanları ve SQL hakkındaki bilgim çoğu üniversite dersine dayanmaktadır. Her neyse, veritabanlarıyla çalıştığım bir şirkette birkaç ay (neredeyse bir yıl) geçirdim.
Ben birkaç kitap okudum ve o şekilde veritabanları hakkında birkaç eğitimlere katılmış MySQL, PostgreSQL, SQLite, Oracleve ayrıca birkaç nonSQL dbbizi ler böyle MongoDB, Redis, ElasticSearchvb
Dediğim gibi, ben çok fazla bilgi eksikliği ile acemi değilim, ama bugün, birisi bir şey söyledi, tamamen benim acemi bilgisine karşı olan şey.
Açıklamama izin ver. SQL veritabanını alalım ve Personiçinde birkaç kayıt içeren basit bir tablo oluşturalım :
id | name | age
-----------------
1 | Alex | 24
2 | Brad | 34
3 | Chris | 29
4 | David | 28
5 | Eric | 18
6 | Fred | 42
7 | Greg | 65
8 | Hubert | 53
9 | Irvin | 17
10 | John | 19
11 | Karl | 23
Şimdi, odaklanmak istediğim kısım idbu INDEX.
Şimdiye kadar, bu şekilde çalıştığını düşündüm: bir tablo oluşturulduğunda INDEXboş. INDEXMasama yeni kayıt eklerken bazı alghortims dayalı yeniden hesaplanıyor. Örneğin:
Tek tek gruplama:
1 ... N
N+1 ... 2N
...
XN+1 ... (X+1)N
yani, benim örnek ile size = 11 elementsve N = 3böyle olacak:
id | name | age
-----------------
1 | Alex | 24 // group0
2 | Brad | 34 // group0
3 | Chris | 29 // group0
4 | David | 28 // group1
5 | Eric | 18 // group1
6 | Fred | 42 // group1
7 | Greg | 65 // group2
8 | Hubert | 53 // group2
9 | Irvin | 17 // group2
10 | John | 19 // group3
11 | Karl | 23 // group3Yani, ben sorgu kullanırken SELECT * FROM Person WHERE id = 8bazı basit hesaplama yapacağız 8 / 3 = 2, bu yüzden bu nesneyi aramak zorunda group2ve sonra bu satır döndürülür:
8 | Hubert | 53
Bu yaklaşım zamanlı olarak çalışır O(k)nerede k << size. Tabii ki, gruplar halinde satırları düzenlemek için bir alghoritm çok daha karmaşıktır, ancak bence bu basit örnek bakış açımı gösteriyor.
Şimdi, bugün bana gösterilen başka bir yaklaşım sunmak istiyorum.
Bu tabloyu bir kez daha alalım:
id | name | age
-----------------
1 | Alex | 24
2 | Brad | 34
3 | Chris | 29
4 | David | 28
5 | Eric | 18
6 | Fred | 42
7 | Greg | 65
8 | Hubert | 53
9 | Irvin | 17
10 | John | 19
11 | Karl | 23Şimdi, benzer bir şey yaratıyor Hashmapharitalar (aslında, tam anlamıyla bir Hash Haritası) idiçin addressbu kimliği ile satırın. Diyelimki:
id | addr
---------
1 | @0001
2 | @0010
3 | @0011
4 | @0100
5 | @0101
6 | @0110
7 | @0111
8 | @1000
9 | @1001
10 | @1010
11 | @1011Şimdi sorgumu çalıştırırken: SELECT * FROM Person WHERE id = 8
doğrudan id = 8bellekteki adrese eşlenir ve satır döndürülür. Elbette bunun karmaşıklığı O(1).
Şimdi birkaç sorum var.
1. Her iki çözümün de avantajları ve dezavantajları nelerdir?
2. Mevcut veritabanı uygulamalarında hangisi daha popüler? Belki farklı dbs farklı yaklaşımlar kullanır?
3. NonSQL dbs içinde var mı?
Şimdiden teşekkür ederim
KARŞILAŞTIRMA
| B-tree | Hash Table
----------------------------------------------------
---------------- one element -------------------
----------------------------------------------------
SEARCHING | O(log(N)) | O(1) -> O(N)
DELETING | O(log(N)) | O(1) -> O(N)
INSERTING | O(log(N)) | O(1) -> O(N)
SPACE | O(N) | O(N)
----------------------------------------------------
---------------- k elements -------------------
----------------------------------------------------
SEARCHING | k + O(log(N)) | k * O(1) -> k * O(N)
DELETING | k + O(log(N)) | k * O(1) -> k * O(N)
INSERTING | k + O(log(N)) | k * O(1) -> k * O(N)
SPACE | O(N) | O(N)N - kayıt sayısı
Haklı mıyım? Her ekleme / silme işleminden sonra B-ağacı ve Karma tablosunu yeniden oluşturma maliyeti nedir ? B-ağacı durumunda, bazı işaretçileri değiştirmemiz gerekir, ancak dengeli b-ağacı durumunda daha fazla çaba gerektirir. Ayrıca Hash tablosunda , özellikle operasyonumuz çakışmalar yaratıyorsa, çok az işlem yapmalıyız .
Of course, an alghoritm to organise rows in groups is for sure much more complicated but I think this simple example shows my point of view.Tabii ki, bunun çok daha karmaşık olduğunu biliyorum. Son olarak, kodumda INDEXhangi çözümlerimin ( 1. veya 2. ) bu gerçek olana daha yakın olduğunu söylerken ? Ve bir kayda göre erişmek için gereken süre ne olacak INDEX. Gerçekten O(1)mi? B-ağacı endeksi ile çok benzer O(log2(N)). Haklı mıyım?
O(1)Seninle ilgili kısım doğru anladı! İlk olarak, bir B-ağacı endeksini tanımladığınız anlaşılıyor, ancak bazı yanlış anlamalarınız var. Hesaplama yoktur (3'e veya herhangi bir şeye bölünme), ağacın daha fazla seviyesi olduğu için daha karmaşıktır (bir ağaçtır, büyük, küçük, daha küçük dalları vardır ... ve sonra ayrılır :)