yardıma ihtiyacım var! Görev çözülmedi, demirin sınırlamalarıyla karşılaşıyorum - sayfa 7
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
fikir net...
ve henüz endüstriyel veri tabanlarında bunun için (hızlı bir arama ile) bir metodoloji yoktur.
görünüşe göre sebepler var
Evet, sıkıştırılmış verilerde kimse aramadan bahsetmiyor. İki sıkıştırılmış diziyi karşılaştırmak hakkında konuşun.
Bir dizi diyelim, "aaa", "bbb", "www". Üç dizi öğesinin her biri, diğerlerinden bağımsız olarak kendi başına sıkıştırılabilir. Diyelim ki sıkıştırdık ve "a", "b", "c" dizisini aldık.
Dizide bulunması gereken istenen "bbb" dizgisine sahibiz. Aramadan önce sıkıştırır ve "b" alırız. Şimdi arıyoruz ve buluyoruz.
Açıklığa kavuşturalım, sizin durumunuzda, tekrar sayısını atladığınız için sıkıştırılmış bir biçimde 3a, 3b ve 3c olmalıdır.
Böyle bir algoritmanın %70-80 sıkıştırma vereceğini düşünüyorsanız yanılıyorsunuz. Rusça metinlerde bile (sayılardan bahsetmiyorum bile), bu yaklaşım yalnızca verileri şişirecektir.
Örneğin, "Uzman" kelimesi "1E1k1s1p1e1r1t" olarak kodlanacak ve tek bir bit ile sıkıştırılmayacak, iki katına çıkacaktır. "1" i atlarsanız, yine de sıkıştırma olmayacaktır.
Datetime 2014.08.18 13:45:45 yolunuza sıkıştırma yapmaz.
Alıntılardan bahsetmiyorum bile... Yani bu durumda bu tür yeniden kodlamanın verimliliği 0'a yakındır. Bu sözde. PCX formatında kullanılan RLE algoritması.
1. Açıklığa kavuşturalım, sizin durumunuzda, tekrar sayısını atladığınız için sıkıştırılmış bir biçimde 3a, 3b ve 3c olmalıdır.
Böyle bir algoritmanın %70-80 sıkıştırma vereceğini düşünüyorsanız yanılıyorsunuz. Rusça metinlerde bile (sayılardan bahsetmiyorum bile), bu yaklaşım yalnızca verileri şişirecektir.
Örneğin, "Uzman" kelimesi "1E1k1s1p1e1r1t" olarak yeniden kodlanacak ve biraz küçülmeyecek, ancak iki kez şişecek. "1" i atlarsanız, yine de sıkıştırma olmayacaktır.
Datetime 2014.08.18 13:45:45 yolunuza sıkıştırma yapmaz.
Alıntılardan bahsetmiyorum bile... Yani bu durumda bu tür yeniden kodlamanın verimliliği 0'a yakındır. Bu sözde. PCX formatında kullanılan RLE algoritması.
1. Gerçek değil. Belki veriler öyledir ki her şey üç kez gider, yani bu basit bir sıkıştırma algoritmasıdır.
Gerisi... Oh, teşekkürler, dünyaya gözlerimi açtın, sensiz bilmiyordum kısa veri dizileri sıkıştırıldığında boyutlarının arttığını.
Çünkü veritabanı, tüm verileri RAM'e yüklemeden mükemmel bir arama işi yapıyor.
Aslında, iyi oluşturulmuş ve doğru bir şekilde oluşturulmuş bir SQL sunucusu - (örneğin, demirin 64 g - 128 RAM'i varsa)
64 g ... 128 g işletim sisteminin neredeyse tüm ihtiyaçlarını karşılar
ve 20 gigabaytlık veri arama (önbelleğe alınmış veriler) - pratik olarak bellekte olur ...
bu nedenle, sıkıştırma - bu durumda hiçbir anlam ifade etmiyor
--
Nasıl ima edersin:
Nasıl arama yapılır, biraz önce yazdım.
Öncelikle "ipucu" ve "ifade" farklı kavramlardır.
İkincisi, benim sözlerimde buna dair bir ipucu bile yok, bir kez daha tekrar ediyorum Kaynak dosya için bir ağaç olacak ve bulunması gereken veri kısmı için tamamen farklı olacak.
Ve az çok ciddi bir sıkıştırma algoritması kullanarak (herhangi bir klasik, hatta Huffman bile) bir arama yapamazsınız. Hatta teorik olarak.
Çünkü veritabanı, tüm verileri RAM'e yüklemeden mükemmel bir arama işi yapıyor.
Öncelikle "ipucu" ve "ifade" farklı kavramlardır.
İkincisi, benim sözlerimde buna dair bir ipucu bile yok, bir kez daha tekrar ediyorum Kaynak dosya için bir ağaç olacak ve bulunması gereken veri kısmı için tamamen farklı olacak.
Ve az çok ciddi bir sıkıştırma algoritması kullanarak (herhangi bir klasik, hatta Huffman bile) bir arama yapamazsınız. Hatta teorik olarak.
Aynı veriler sıkıştırılmışsa, neden bir veri bölümü için birdenbire farklı bir ağaç olsun ki? Veriler farklıysa, farklı bir ağaca sahip olmasına izin verin. Aynı veriler sıkıştırıldığında sıkıştırılmış verileri eşleştirmemiz bizim için önemlidir.
Dmitry - mümkün olsaydı
uzun zaman önce endüstriyel bir SQL veritabanı oluşturmuşlardı - iyi (%80-%90) sıkıştırılmış verilerde (FAST) arama ile ...
ayrıca Ekle Güncelleme Sil ile
1. Gerçek değil. Belki veriler öyledir ki her şey üç kez gider, yani bu basit bir sıkıştırma algoritmasıdır.
Gerisi... Oh, teşekkürler, dünyaya gözlerimi açtın, sensiz bilmiyordum kısa veri dizileri sıkıştırıldığında boyutlarının arttığını.
Gözleri açık tutmak için küçük bir tartışma daha. Herhangi bir kodlamanın belirli bir amacı vardır.
Dekompresyon kodlaması vardır, amaç ikili verileri yalnızca teletype (örneğin, e-posta ile resimler) destekleyen iletişim kanalları üzerinden aktarmaktır, genellikle Radix algoritmasına dayalı olarak Base64 kullanılır.
Veri düzeltmeyle ilişkili yedekli kodlama (örneğin, CD Aduio) amaç - verilerin fiziksel bir ortamdaki hasara karşı maksimum korunmasını sağlamak.
Sıkıştırma kodlaması, amaç - veri depolama/arşivleme .
Dmitry - mümkün olsaydı
uzun zaman önce endüstriyel bir SQL veritabanı oluşturmuşlardı - iyi (%80-%90) sıkıştırılmış verilerde (FAST) arama ile ...
İkinci tura gittin mi? Sayfa 5-6'dan tekrar okumaya başlayın. Gönderiyi dikkatlice okuyun.
Önerdiğim şeyi bana atfetme. Birbirinden bağımsız olarak sıkıştırılmış sıkıştırılmış dizileri karşılaştırmayı önerdim. Bir seferde ayrı olarak sıkıştırılmış büyük bir dosyada ayrı olarak sıkıştırılmış küçük bir metin aramak yerine.