Veritabanında çok geniş bir dizge / kayıt listesi içinde hızlıca arama

Aşağıdaki sorunu yaşıyorum: 2 milyondan fazla kayıt içeren bir veritabanım var. Her kaydın bir X string alanı vardır ve X alanının belirli bir dize içerdiği kayıtların bir listesini görüntülemek istiyorum. Her kaydın boyutu yaklaşık 500 bayttır.

Daha somutlaştırmak için: başvurumun GUI'sinde bir dize girebileceğim bir metin alanına sahibim. Metin alanının üstünde, metin alanındaki dizeyle eşleşen (ilk N, örneğin 100) kayıtları gösteren bir tablom var. Metin alanına bir karakter yazdığımda veya sildiğimde, tablo içeriği anında güncellenmelidir.

Bunu uygun indeks yapıları ve / veya önbellek kullanarak yapmanın etkili bir yolu olup olmadığını merak ediyorum. Yukarıda açıklandığı gibi, yalnızca sorguyla eşleşen ilk N öğesini görüntülemek istiyorum. Bu nedenle, N küçük için, eşleşen öğeleri veritabanından yüklemek büyük bir sorun olmamalıdır. Ayrıca, ana bellekteki öğelerin önbelleğe alınması, erişimi daha hızlı hale getirebilir.

Bence asıl problem, kalıp dizgisine verilen eşleme maddelerinin hızlıca nasıl bulunacağı. Bazı DBMS özelliklerine güvenebilir miyim, yoksa bazı bellek içi endeksleri kendim mi oluşturmalıyım? Herhangi bir fikir?

DÜZENLE

İlk deneyi yaptım. Kayıtları farklı metin dosyalarına böldüm (dosya başına en fazla 200 kayıt) ve dosyaları farklı dizinlere koydum (dizin ağacını belirlemek için bir veri alanının içeriğini kullandım). 40000 dizinde yaklaşık 50000 dosya ile son bulurum. Dosyaları indekslemek için Lucene'yi çalıştırdım. Lucene demo programı ile bir dize aramak oldukça hızlı. Bölme ve dizin oluşturma birkaç dakika sürdü: bu benim için tamamen kabul edilebilir çünkü sorgulamak istediğim statik bir veri seti.

Bir sonraki adım, Lucene'yi ana programa entegre etmek ve ilgili kayıtları ana hafızaya yüklemek için Lucene'nin geri gönderdiği isabetleri kullanmaktır.

Verilerinizi DB içine koymak yerine, bunları ayrı ayrı bir belge kümesi (metin dosyaları) olarak tutabilir ve bağlantıyı (yol / URL vb.) DB'de saklayabilirsiniz.

Bu önemlidir, çünkü tasarım gereği SQL sorgusu hem alt dizede aramada hem de alımda çok yavaş olacaktır.

Şimdi, probleminiz, dizeleri içeren metin dosyalarını aramak zorunda kalmak şeklinde formüle edildi. Burada iki olasılık var.

1. Alt-dize eşleşmesi Eğer metin bloblarınız tek bir acı ya da kelime ise (herhangi bir beyaz boşluk olmadan) ve içinde rastgele bir alt-dizinde arama yapmanız gerekir. Bu gibi durumlarda, eşleşen en iyi dosyaları bulmak için her dosyayı ayrıştırmanız gerekir. Bir Boyer Moor algoritması gibi algoritmalar kullanır. Ayrıntılar için buna ve buna bakın. Bu ayrıca grep'e eşdeğerdir - grep, içinde benzer şeyler kullanır. Ancak, geri dönmeden önce hala en az 100+ grep (en kötü durum 2 milyon) yapabilirsiniz.

2. Dizinlenmiş arama. Burada, metnin bir dizi kelime içerdiğini ve aramanın sabit kelime uzunlukları ile sınırlı olduğunu varsayıyorsunuz. Bu durumda, belge kelimelerin olası tüm oluşumları üzerinde indekslenir. Buna genellikle "Tam Metin araması" denir. Bunu yapmak için algoritmalar ve doğrudan kullanılabilecek açık kaynak projeleri sayısı var. Birçoğu, aşağıdaki gibi joker arama, yaklaşık arama vb. Destekler:
   a. Apache Lucene: http://lucene.apache.org/java/docs/index.html
   b. OpenFTS: http://openfts.sourceforge.net/
   c. Sfenks http://sphinxsearch.com/

Sorgu olarak "sabit kelimelere" ihtiyacınız varsa, büyük olasılıkla iki yaklaşımı çok hızlı ve etkili olacaktır.

Aradığınız teknoloji tam metin indekslemedir. Çoğu RDBMS burada işe yarayacak bir tür yerleşik yeteneklere sahiptir ya da meraklısı olmak ve / veya sadece bellekte çalıştırmak istiyorsanız Lucene gibi bir şey kullanabilirsiniz.

Bir trie düşündün mü ? Temel olarak ortak ön ekler kullanarak bir ağaç oluşturursunuz, bu nedenle aynı harflerle başlayan tüm kelimeler aynı düğümün çocuklarıdır. Herhangi bir alt dize eşleştirmeyi destekleyecekseniz, o zaman bir tür izinli dizin oluşturup bu sayede bilginizi oluşturmak zorunda kalırsınız . Yine de, depolama gereksinimlerinizi dışarı atıyor olabilir.

Wyatt Barnett'in cevabını, uygun sütunda tam metin indeksleme özelliğine sahip bir RDBMS çözümünün işe yarayacağına cevabını eklemek isterim, ancak daha önce alınmış kayıtların yerel önbelleğini kullanmak istiyorsanız, bu önbelleğe alınmış kayıtları kullanmak için bir plan yapmanız gerekir. Avantajınız için.

Seçeneklerden biri, bu kayıtların TAMAMEN sorgusuzca almak istemediğiniz benzersiz tanımlayıcılarını toplamak ve bunları muhtemelen bir NOT INveya a NOT EXISTS.

Ancak dikkatli olun, kullanmak NOT INveya NOT EXISTSucuz olmamak eğilimindedir ve kullandığınız veritabanı motoruna bağlı olarak sorgu performansınızı veya sorgu planınızı olumsuz yönde etkileyebilir. Etkilenen sütunlardaki tüm dizinlerin kullanıldığından emin olmak için son sorgunuzda bir açıklama planı kullanın.

Ayrıca hangisinin daha hızlı olduğunu görmek için iki yaklaşım arasında bir performans karşılaştırması yapmaktan zarar gelmez. Yerel bir önbelleği korumanın ve bunları sorgudan açıkça filtrelemenin, tüm kayıtları alan ince ayarlanmış bir sorgudan daha kötü bir performans gösterdiğini görünce şaşırabilirsiniz.

Sadece kaçırmış olmanız durumunda. Lucene'yi veritabanı içinde desteklenen metin arama yerine veritabanınız için kullanıyorsanız, veritabanınızda değişiklik yaparken çok dikkatli olmanız gerekir. Hem DB'de hem de harici kaynaklarda (Lucene) değişiklik yapmanız gerektiğinde, atomikliğe sahip olduğunuzdan nasıl emin olabilirsiniz? Evet yapılabilir, ancak çok fazla iş olacak.

Kısacası, Lucene'i veri şemanıza yerleştirirseniz, DB işlem desteğini kaybedersiniz.

Sfenks'i düşündün mü? http://sphinxsearch.com , bir üçüncü taraf aracını kullanabiliyorsanız, bu elde etmeye çalıştığınız şey için ideal olacaktır, tam metin aramada kişisel olarak kullandığım herhangi bir RDBMS'den çok daha verimlidir.

Apache Lucene ve diğerlerine benzer tüm çözümlerin altında yatan teknoloji olan cevapların hiçbirinin “ters endeks” terimini sunmaması biraz garip .

Tersine çevrilmiş dizin, kelimelerden belgelere ("kayıt düzeyinde ters çevrilmiş dizin") veya hatta belge içindeki kesin kelime konumlarına ("kelime düzeyinde ters çevrilmiş dizin") yapılan bir eşlemedir.

VE ve VEYA mantıksal işlemler gerçekleştirmek için çok önemlidir. Kesin kelime konumlarınız varsa, bitişik kelimeleri aramak mümkündür, böylece cümle aramalarını mümkün kılar.

Bu yüzden, (kelime, dosya, konum) dişleri içeren bir dizin düşünün. Örneğin ("ters", "foo.txt", 123) varsa, o zaman ("index", "foo.txt", 124) "tümceciği" için tüm dizini aramak üzere dizinin bir parçası olup olmadığını kontrol edin. .

Tam metinli bir arama motorunu sıfırdan yeniden biçimlendirmenizi tavsiye etmemekle birlikte, Apache Lucene gibi teknolojilerin nasıl çalıştığını bilmek faydalıdır.

Bu yüzden benim önerim ters indekslerin nasıl çalıştığını öğrenmek ve bunları Apache Lucene gibi bir teknolojiyi seçmek. Öyleyse, en azından ne yapılabileceğini ve ne yapılamayacağını anlamanız yeterli.