SSD'ler Veritabanlarının kullanışlılığını azaltır mı?


28

Bugün sadece Robert Martin'i duydum ve yazılım dünyasında dikkat çekici bir figür gibi görünüyor, bu yüzden başlığım bir tıklama yemi gibi görünüyor veya ağzına kelimeler sokuyormuş gibi görünmüyor, ama bu sadece ondan duyduğum şeyi sınırlı deneyim ve anlayışla nasıl yorumladım.

Bugün bir video izliyordum (yazılım mimarisinde), Robert C. Martin'in yaptığı bir konuşmada ve videonun son yarısında veritabanlarının konusu ana odak noktasıydı.

Söylediklerini anladığım kadarıyla SSD'lerin veri tabanlarının yararlılığını azaltacağını söylüyor gibi görünüyordu ( önemli ölçüde ).

Bu yoruma nasıl geldiğimi açıklamak için:

HDD'lerin / eğirme disklerinin veri almanın nasıl yavaş olduğunu anlattı. Ancak bu günlerde SSD kullanıyoruz. “RAM geliyor” ile başlıyor ve daha sonra RAM disklerinden bahsederek devam ediyor, ancak daha sonra RAM disk diyemediğini söylüyor, bu yüzden sadece RAM diyerek başvuruyor. Bu yüzden RAM ile indekslere ihtiyacımız yok, çünkü her byte'ın aynı zamanda alınması gerekiyor. ( bu paragraf bana göre yazılmıştır )

Bu yüzden, RAM'in (bilgisayar belleğinde olduğu gibi) DB'lerin yerine geçmesini önerdiğini (ifadesini şöyle yorumladığım gibi) anlam ifade etmiyor çünkü bu, tüm kayıtların bir uygulamanın ömrü boyunca hafızada işlendiğini söylemek gibi bir şey ( talep üzerine bir disk dosyasından çekmediğiniz sürece)

Bu yüzden RAM tarafından düşünmeye başvurdum, o SSD demektir. Yani, bu durumda, SSD'lerin veritabanlarının yararını azalttığını söylüyor. Hatta "Ben Oracle olsaydım korkardım. Varlığımın temeli buharlaşıyor" diyor.

SSD'leri çok az anladığımdan, O(n)zaman arayan (sanırım) HDD'lerin aksine , SSD'ler O(1)neredeyse neredeyse rasgele. Bu yüzden önerisi benim için ilginçti, çünkü hiç böyle düşünmemiştim. Birkaç yıl önce veritabanlarına ilk kez girdiğimde, bir profesörün düzenli dosya sistemine göre faydalarını anlattığı zaman, bir veritabanının birincil rolünün temelde çok endeksli bir dosya sistemi olduğu (optimizasyonlar, önbellekleme, eşzamanlı erişim gibi) olduğu sonucuna vardım. etc), bu nedenle, eğer SSD'de indekslere ihtiyaç duyulmuyorsa, bu tür veritabanları daha az kullanışlı hale getirir.

Yine de, ne olursa olsun, yeni biri olduğumu tercih etmekle, herkes hala DB'leri saf dosya sistemi yerine uygulamalarının birincil noktası olarak kullanıyor ve sanki basitleştiriyormuş gibi hissettiğinden, daha az faydalı olduklarına inanmayı zor buluyorum. veritabanlarının rolü.

Not : Farklı bir şey söylemediğinden emin olmak için sonuna kadar izledim.

Referans için: 42:22 tüm veritabanı konusu ortaya çıktığında, 43:52 "Neden veritabanlarımız bile var?"

Bu cevap SSD'lerin DB'leri önemli ölçüde hızlandırdığını söylüyor. Bu soru optimizasyonun nasıl değiştiğini soruyor.

To TL; DR sorumu, (yaklaşan var ya zaten oldu olsun) veritabanlarının yararlılığını azaltır sunucu pazarında yaygın SSD kullanımının gelişini yapar?

Sunucunun iletmeye çalıştığı gibi görünüyordu, SSD'lerle, verileri diske kaydedebiliyordu ve SSD'lerde olduğu gibi, arama sürelerinin yakın olduğu zamanlarda eski HDD'lerde olduğu gibi almak için ne kadar yavaş olduğu konusunda endişelenmek zorunda kalmıyor gibiydi. O(1)(Bence). Bu nedenle, bu doğru olduğunda, varsayımsal olarak sahip olduğu avantajlardan birini kaybeder: endeksleme, çünkü daha hızlı arama süreleri için endekslere sahip olma avantajı ortadan kalkar.

Yanıtlar:


59

SSD'leri kullanırken veritabanında ayarlanması gereken bazı şeyler var . Örneğin, PostgreSQL için konuşma ayarlayabilir effective_io_concurrencyve random_page_cost. Ancak, daha hızlı okuma ve daha hızlı rastgele erişim, veritabanının yaptığı gibi değildir. Sağlar

Sadece indekslerde yanılıyor. Tüm tablo ram içine okunabiliyorsa, bir dizin hala yararlıdır. Bana inanma Düşünce deneyi yapalım

  • Dizinlenmiş bir sütunu olan bir tablonuz olduğunu hayal edin.

    CREATE TABLE foobar ( id text PRIMARY KEY );
  • Bu tabloda 500 milyon satır olduğunu hayal edin.

  • 500 milyon satırın bir araya getirildiğini hayal edin.

Daha hızlı

  1. grep 'keyword' file
  2. SELECT * FROM foobar WHERE id = 'keyword'

Bu sadece verinin nerede olduğu değil, onu nasıl sipariş ettiğiniz ve hangi işlemleri yapabileceğiniz ile ilgili değildir. PostgreSQL, B ağacı, Hash, GiST, SP-GiST, GIN ve BRIN indekslerini (ve bir uzantı yoluyla Bloom) destekler. Tüm bu matematik ve işlevselliklerin ortadan kalktığını düşünmek aptallık eder çünkü daha hızlı rastgele erişime sahipsiniz.


31
Sadece bir Zeyilname - OP “rastgele erişimi” ile “içerik-adreslenebilir erişim” ile birleştirmemeye özen göstermelidir. OP'nin de belirttiği gibi "rasgele erişim", hafızanın her bir baytına ulaşmanın O (1) olduğu anlamına gelir. Bununla birlikte, bu "rasgele erişim belleğindeki" BULMA verileri hala sırayla araştırmayı gerektirir; olduğuna göre, hafızayı soramazsın "gibi görünüyor bu bana verileri bulmak bu ve sihirli size teslim olması".
Bob Jarvis - Monica'yı tekrar

2
@ BobJarvis Haklısın. Yorumunuz, daha da netleşmenize yardımcı olur @ EvanCarroll'un neden endekslemenin ve hatta alt indeksleme maddesinin neden daha hızlı olduğuna dair "Hızlı olan" örneği ve O(1)bir DB'nin sağladığı kullanım durumları için sadece kapma yeterli değil
Abdul

12

Gönderinize göre, açık bir mesaj olarak RDBMS arama zamanı optimizasyonlarının IO zamanını ihmal edilebilir kılan donanım ile değiştirildiği anlaşılıyor.

Bu kesinlikle doğru. Yüksek (gerçek) RAM'le birleştirilmiş veritabanı sunucularındaki SSD, GÇ'yi önemli ölçüde kısaltır. Bununla birlikte, RDBMS endeksleme ve önbellekleme hala değerlidir çünkü bu devasa IO nimetine sahip sistemler bile kötü indekslemenin neden olduğu kötü performans gösteren sorgulardan IO darboğazları alabilir ve alacaktır. Bu genellikle yalnızca yüksek iş yükü uygulamaları veya kötü yazılmış uygulamalar altında bulunur.

RDBMS sistemlerinde genel olarak anahtar değer, veri tutarlılığı, veri kullanılabilirliği ve veri toplamasıdır. Bir excel elektronik tablosu, csv dosyası veya bir "veri tabanı" tutmanın başka bir yöntemini kullanmak garanti vermez.

SSD sizi birincil sunucunuzdan korumaz, hiçbir nedenle kullanılamaz hale gelir (ağ, işletim sistemi bozulması, elektrik kesintisi). SSD sizi kötü veri değişikliklerinden korumaz. SSD, analitiği "sadece sahip olma" durumuyla karşılaştırmayı hızlandırmaz.


Daha iyi fikir edindiniz rağmen, ben / HDD w DB veri depolama vs ham SSD veri depolama bağlamında soruyordu ve cevap (benden dolayı zayıf soru phrasing kadar) SSD DB bağlamında ise
Abdul

4
@Abdul Bu karşılaştırma elma-süspansiyon köprülerdir. Ham bir cihaz size büyük miktarda depolama alanı sağlar; Bir veritabanı size, veri depolama modeline göre bu depolamayı düzenlemenin ve erişmenin bir yolunu sunar. Josh'un buradaki amacı, eğer bir ham SSD'nin harika bir şey olduğu yıldızlı gözle fikrini kullanmaya başlarsanız, çünkü bu "hızlı" ve bu ham ciltteki tüm veri depolamanızı yapmak için kod yazacaksınız. , sonunda bir veritabanı yazmaya başlayacaksın.
Blrfl

8

Bob Amca muhtemelen Redis veya Gemfire gibi hafıza içi veritabanlarından bahsediyordu . Bu veritabanlarında, veritabanındaki her şey gerçekten RAM'de bulunur. Veri tabanı boş başlayabilir ve kısa ömürlü verilerle (önbellek olarak kullanılır) dosyalanabilir veya her şeyi diskten yükleyerek ve periyodik olarak diskte kontrol noktası değişikliklerini yaparak başlayabilir.

Bu gittikçe daha popüler hale geliyor çünkü RAM ucuzlaşıyor ve bellek içi kümelenmiş bir veritabanında depolanan bir terabayt veriye sahip olmak mümkün oluyor. Nesnelere anında erişmenin hızının SSD gibi hızlı bir diskten ziyade RAM'e yerleştirmeyi değerli kıldığı birçok kullanım durumu vardır. Bunların bazıları için SQL kullanmaya devam edebilir bile.

Bu neden Oracle'ı endişelendirmeli? Veriler büyüyor ve RDBMS'lerin kaybolması muhtemel değil. Bununla birlikte, yıllar boyunca Oracle'ın mühendislik zamanlarının çoğu, dönen disklerle ilgili verileri hızlı bir şekilde almanın yollarını aramaya başladı. Oracle'ın tamamen farklı bir depolama katmanına adapte olması gerekecek. Bunlar birlikte, şunlardır Anısına Oracle Veritabanı , ancak geçmişte farklı rekabete maruz ediyoruz. Sorgu en iyi duruma getiricisinin diskteki şeylerin düzenine göre doğru stratejileri seçtiğinden emin olmak için ne kadar zaman geçtiğini düşünün ....


Ah. Orada hafıza içi veritabanları gibi şeyler bilmiyordum
Abdul

1
Başka bir örnek olarak, SQLite bellekte çalışabildiği için farklı bir veritabanı kullanmanıza gerek kalmaz
user151019

8

Topluluk Wiki yayını başlangıçta soru yorumu olarak bırakılan yanıtları toplama


Ben tam tersini söyleyebilirim. Okuma / yazma hızları çok hızlı olduğu için, artık sayıları daha da hızlı bir şekilde azaltmak için GPU hızlandırılmış bir veritabanı (örn. BlazingDB veya Alenka ) alabilirsiniz. Artık daha karmaşık sorguların daha hızlı çalışmasını sağlayabilirsiniz. Artık insanların kaçmayı düşünmediği sorgular makul bir hızda çalıştırılabilir. Ne kadar karmaşık ve o kadar fazla veri sizin için o kadar iyidir - cybernard

Bob Martin uzun zamandır buralardayken ve görüşleri genellikle dinlenmeye değer olsa da (:-) ile aynı fikirde olmazsa, bu durumda “İlişkisel Veritabanlarının Ölümünün Bizde Olduğu” kalabalığına daldığını düşünüyorum) Ben bir ortak üyeyim :-). İçin bazı altında şeyler sınırlı durumlarda biraz ikna edici olmayan ilişkisel veritabanı teknolojileri bir kenar sağlayabilir yapılabilir. Bununla birlikte, IMO'nun olduğu gibi çeşitli ve çeşitli şekillerde kusurlu olan ilişkisel modelin söylendiğine göre, bugün hala mevcut olan en iyi genel amaçlı veritabanı modelini sunmaktadır. YMMV. - Bob Jarvis

Biz veritabanlarını kullanan başlıca nedeni diskler yavaş (bir neden olarak gerçekten de başlangıçta belirtilen olduğu, çünkü değil değil veritabanlarını kullanmak için), daha çok veri karmaşıktır çünkü . Bir veritabanının birincil amacı, birden fazla uygulamanın / kullanıcının doğru verileri bulabilmesini ve hatta aynı anda kontrollü bir şekilde değiştirebilmesini sağlamaktır. Bunu hızlıca yapmak, veritabanlarının yalnızca ikincil bir amacıdır. - RBarryYoung

RDBMS yakında yakın zamanda gitmiyor; bazı uygulama türleri için en iyi seçimdir ve NoSQL (Mongo, vb.) diğerleri için en iyi seçimdir. Kurslar için atlar. - sh1rts

Veri tabanı verilerin düzenlenmesine yardımcı olur. Zaten ilk etapta verilere hızlı erişim için gerçekten tasarlanmamıştır. - JI Xiang

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.