yardıma ihtiyacım var! Görev çözülmedi, demirin sınırlamalarıyla karşılaşıyorum - sayfa 4
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Bunun hakkında düşündüm. Görüşlerle ilgileniyor:
Bir dosyayı okumaya kıyasla hızlanma ne olacak ve bellekte çalışmaya kıyasla yavaşlama ne olacak?
DBMS, tablolarını mümkün olduğunda belleğe yerleştirir.
ama sizin durumunuzda değil, tabii ki 32 GB RAM'iniz yoksa
bu nedenle, 20G'yi 4G'ye nasıl yayarsınız, beyninizi optimizasyon üzerinde rafa kaldırmanız gerekir.
Görevinizi basitleştirirseniz, bellekte normal bir RAM diski yapmak daha iyidir. ayrıca bir DBMS ile uğraşmayın.
Yapamıyorsan, o zaman git.
Bir dosyayı okumaya kıyasla hızlanma ne olacak ve bellekte çalışmaya kıyasla yavaşlama ne olacak?
Sonuçta, sadece bir dosyayı okumanız gerekmiyor, aynı zamanda aramanız, hesaplamanız, metni sayılara dönüştürmeniz, sıralamanız vb.
İlk olarak, veriler sık güncellenmiyorsa, veri aramasında yer alan nitelikler için (niteliklerin toplanması dahil) istediğiniz kadar dizin oluşturabilirsiniz. Böylece arama daha hızlı olacaktır (indeksler kullanıldığında), dolayısıyla hesaplamalar da daha hızlı olacaktır.
İkinci olarak, MySQL, MS SQL, Oracle ve diğer DBMS'nin tekrarlayan sorgular için veri önbelleğe alma teknolojisini kullandığını varsayalım, bu da biraz işlem hızı artı sağlar.
Üçüncüsü, tabloyu yıllara göre parçalara (bölümlere) bölebilirsiniz. Aynı zamanda, bir yıl için veri seçen sorgular, diğer bölümlerde bulunan verileri okumaz/aramaz.
Dördüncüsü, kaynak verileriniz metin biçiminde olduğundan, veritabanına yüklenirken, doğal türlere atılmalar nedeniyle hacmin azalması gerekir. Örneğin metin biçimindeki 124.223456221 sayısı 13 bayt, veri tabanında türüne göre 4-8; tarih ve saat "2014-08-17 10:23:35" 19 bayt, DB'de ise 8 bayttır.
Beşincisi, belirli periyotlar için sık sık toplu bilgiler kullanılıyorsa, bu veriler bir defada toplanabilir ve başka bir tabloda saklanabilir.
Tabii ki, sadece belleğe veri okumaktan bahsediyorsak, WinApi bunu daha hızlı yapacaktır, peki o zaman verilerle ne yapmalı? Verinin istediğiniz kısmını aramak için bile diskteki tüm verileri okumanız gerektiğini hayal edin. Veya dizin oluşturma işlevini kendiniz yazın, dosyadaki verileri sıralayın, tüm arama işlemleri için dizin dosyaları oluşturun, genel olarak DBMS işlevselliğinin yarısını yeniden yazın. Bu miktarda veriyi işlemek ve makul performansı arzulamak için bu bir zorunluluktur.
Benim düşüncem kesindir - özel bir makinede bir sunucu DBMS'si (MS Access, SQLite gibi dosya veritabanları burada çalışmayacaktır). Veri işlemede (SQL sorguları) oldukça makul bir performans ve kolaylık olacaktır. Aksi takdirde, dosyayı işlemek için düşük seviyeli "dahili" yazmak için çok zaman kaybedersiniz.
Bunun hakkında düşündüm. Görüşlerle ilgileniyor:
Bir dosyayı okumaya kıyasla hızlanma ne olacak ve bellekte çalışmaya kıyasla yavaşlama ne olacak?
(3 TB'den daha büyük bir veritabanı ve 10-100 gb nispeten cüce veritabanları ile deneyimim var)
ancak belirli bir donanımla ... diyelim ki 64 GB RAM ve üzeri iyi bir disk alt sistemi ile
bu durumda büyük bir dosyayla çalışmaya kıyasla
SQL'de hızlanma önemli olacaktır, ancak elbette hız SQL'deki uygulamaya bağlı olacaktır.
- doğru veritabanı geliştirme - doğru dizinler - doğru veritabanı yapılandırması
Dosyaları bölmeyi kastediyorum ( elugovoy'un doğru yazdığı şey bu)
Tam teşekküllü bir uygulama için ayrı bir sunucu gereklidir, sunucu işletim sistemi bir SQL veritabanıdır.
MS SQL ise 2008'den düşük değilse (yazılım için 64'ten düşük olmaması da istenir)
Ama benim düşünceme göre, uygulama donanım için oldukça zaman alıcı ve pahalı olacak ... (ideal olarak 64 bit)
--
makinede yalnızca 16 konser varsa ve makine bir istasyon olarak kullanılıyorsa
üzerine bir SQL sunucusu koymak çok iyi olmayacak - ancak bir metin dosyasıyla kendinize eziyet etmekten daha iyidir
ancak, SQL ile ilgili herhangi bir deneyim yoksa, uygulama sırasında biraz çaba gerekecektir.
Ve bu dosya bir arşivleyici tarafından sıkıştırılırsa, hacim ne olacaktır (sonuçta metin çok iyi sıkıştırılmalıdır)?
her geçişte arşivden çıkarma süresi performansı sıkı bir şekilde öldürür
her geçişte arşivden çıkarma süresi performansı sıkı bir şekilde öldürür
Açın demek istemedim. Arşivleme hacmi büyük ölçüde azaltabiliyorsa, bilgileri bir dizin dosyasına sıkıştırmak mantıklıdır.
aslen
Ve bu dosya bir arşivleyici tarafından sıkıştırılırsa, hacim ne olacaktır (sonuçta metin çok iyi sıkıştırılmalıdır)?
bu nedenle yazınıza tepki!
dizin dosyası - oluştur... ?! bu başka bir konu
Kendi (SQL gibi) sunucunuzu yazmak daha da güzel - ama neden?
aslen
bu nedenle yazınıza tepki!
dizin dosyası - oluştur... ?! bu başka bir konu
Kendi (SQL gibi) sunucunuzu yazmak daha da güzel - ama neden?
Başlangıçta, yazar için bir soru vardı - dosya ne kadar küçülecek. ....
Neden olduğunu sorabilir miyim?
Peki %70-80 oranında küçüldü diyelim, ne verecek? Yazar, tarif ettiği sorunu çözmede