MySQL performans vs CSV

6 Cevap php

PHP5 MySQL5 ve CSV dosyaları ile çalışmak için aynı ortamları varsayalım. MySQL barındırılan komut gibi aynı ana üzerindedir.

MySQL zaman CSV kayıtları ekleme / silme / değiştirme / arama / retriving daha hızlı olacak?

Ya PHP + CSV performanslı veritabanı sunucusu kullanarak daha iyidir bunun altında bir miktar verinin var?

6 Cevap

CSV, hızlı arama için dizin oluşturmanıza izin vermez.

Her zaman aksi takdirde, CSV hızlıdır (application settings için) gibi tek bir tablodan tüm verileri gerekiyorsa.

Hatta CSV kesinlikle olduğu gibi, SQL queries, transactions, data manipulation ya da concurrent access burada düşünmüyoruz bunlar için.

Hayır, MySQL'in ekleyerek (bir CSV ekleme çok hızlı) ve tablo tarama (non-endeks bazlı) aramalar için daha yavaş olacaktır.

Güncellenmesi veya CSV silme nontrivial - Ben okuyucu için bir alıştırma olarak bırakıyorum.

Bir CSV kullanın, aksi takdirde kötü veri veya bozuk dosya alırsınız, doğru birden çok iş parçacığı / süreçlerini işlemek için çok dikkatli olmak gerekir.

Ancak, diğer avantajları da vardır. Bir CSV üzerinde ALTER tablo nasıl çalışmak ister misin?

Hiç UPDATE'ler, silmeleri, ALTER tablo veya bir defada birden fazla süreç dosyaya erişmek için gerekiyorsa bir CSV kullanarak çok kötü bir fikirdir.

Veritabanları, veri saklamak ve almak için vardır. Düz hat giriş / ek veya toplu liste daha fazla bir şey gerekiyorsa, neden veritabanı yolu için gitmek değil mi? Aksi takdirde temel işlevselliği (dahil silme, sıralama vb) kendiniz kod olurdu.

CSV inanılmaz kırılgan biçimidir ve tüm biçimlendirme ve calcuations yapmak için uygulamasını gerektirir. Bir CSV spesifik bir kaydı güncelleştirmek gerekiyorsa, önce tüm csv dosyasını okumak bellekte giriş değiştirmeniz gerekir bulmak, sonra tekrar tüm dosyayı yazmak zorunda kalacak. Bu çok hızlı bir şekilde çok yavaş olur. CSV readd kez uygulamaları yazın kez sadece yazmak için yararlıdır.

Veri endüstrisinden gelen bir kişi olarak, ben tam olarak bu durumu ele.

Generally speaking, MySQL will be faster.

Ancak, gelişmekte olan uygulama tipini devlet yok. Eğer ağırlıklı olarak arama ve kayıt alımı için kullanılan bir veri ambarı uygulaması geliştiriyoruz? Kaç alanlar kayıtlarında tümörigenezinin? Kaç kayıt veri dosyaları genellikle mevcut? Bu dosyalar birbirlerine herhangi ilişkisel özellikleri var mı, yani müşterilerin dosya ve müşteri siparişleri bir dosya var mı? Ne kadar zaman bir sistem geliştirmek gerekiyor?

Cevap daha önce listelenen sorulara cevap bağlıdır. Ancak, genel bir kılavuz olarak aşağıdakileri kullanabilirsiniz:

Eğer bir milyondan fazla kayıtları ile bir veri ambarı uygulaması bina varsa, hem hendek açılması ve bir Column Oriented Database hareket düşünebilirsiniz.

CSV muhtemelen daha küçük veri kümeleri için daha hızlı olacaktır. Ancak, CSV kendi insert rutinleri haddeleme ağrılı olabilir ve veritabanı indeksleme avantajlarını kaybedebilir.

Benim genel tavsiye ben çoğu durumda daha hızlı olacağını, daha önce söylediğim gibi, sadece, MySQL kullanmak olacaktır.

@ MarkR dediği gibi saf performans açısından, tamamen, yaptığın işlemi bağlıdır. Düz bir dosyaya ekleme çok hızlı. (Non-endeksli arama veya diğer amaçlar için) tüm dosya okuma gibi.

Lütfen platformda kullanım durumları için daha iyi çalışır emin bilmek için tek yolu, gerçek profilleme yapmaktır. Ben bir milyon satır veritabanı üzerinde tam tablo taraması yapan bir milyon satır CSV dosyası üzerinde grep daha yavaş olacağını size garanti edemez. Ama bu muhtemelen kullanım gerçekçi bir örnek değil. "Kırılma noktaları" sizin özel karışımı bağlı çılgınca değişir, endeksli arama, non-endeksli arama, güncelleme, ekleme almak.

Bana göre, bu bir performans sorunu değildir. Sizin veri kaydı odaklı sesler ve MySQL veri bu tür ile başa çıkmak için (genel anlamda) çok üstündür. Lütfen kullanım durumlarda bile verileri büyük alır zaman karmaşık biraz iseniz, 100k hat CSV dosyası ile ilgili hiçbir tarafından (ki performans marjinal daha iyi olsa bile, bir 100k rekor db tabloya göre korkunç olacak ) garanti anlamına gelir.