문자열 컬렉션에서 검색하는 가장 빠른 방법

문제:

컬렉션에 저장하고 나중에 해당 컬렉션에 대해 검색을 수행하려는 약 120,000 명의 사용자 (문자열) 의 텍스트 파일 이 있습니다.

검색 방법은 사용자가 a의 텍스트를 변경할 때마다 발생 TextBox하며 결과는 의 텍스트 를 포함 하는 문자열이어야합니다 TextBox.

목록을 변경할 필요가 없습니다. 결과를 가져 와서 ListBox.

지금까지 시도한 것 :

두 개의 다른 컬렉션 / 컨테이너로 시도했는데, 외부 텍스트 파일에서 문자열 항목을 덤프합니다 (물론 한 번).

1. List<string> allUsers;
2. HashSet<string> allUsers;

다음 LINQ 쿼리를 사용합니다 .

allUsers.Where(item => item.Contains(textBox_search.Text)).ToList();

내 검색 이벤트 (사용자가 검색 텍스트를 변경하면 실행 됨) :

private void textBox_search_TextChanged(object sender, EventArgs e)
{
    if (textBox_search.Text.Length > 2)
    {
        listBox_choices.DataSource = allUsers.Where(item => item.Contains(textBox_search.Text)).ToList();
    }
    else
    {
        listBox_choices.DataSource = null;
    }
}

결과 :

둘 다 저에게 응답 시간이 좋지 않았습니다 (각 키 누름 사이에 약 1-3 초).

질문:

내 병목이 어디에 있다고 생각하세요? 내가 사용한 컬렉션? 검색 방법? 양자 모두?

더 나은 성능과 더 유창한 기능을 얻으려면 어떻게해야합니까?

완료되면 콜백 메서드를 호출하는 백그라운드 스레드에서 필터링 작업을 수행하거나 입력이 변경된 경우 필터링을 다시 시작할 수 있습니다.

일반적인 아이디어는 다음과 같이 사용할 수 있다는 것입니다.

public partial class YourForm : Form
{
    private readonly BackgroundWordFilter _filter;

    public YourForm()
    {
        InitializeComponent();

        // setup the background worker to return no more than 10 items,
        // and to set ListBox.DataSource when results are ready

        _filter = new BackgroundWordFilter
        (
            items: GetDictionaryItems(),
            maxItemsToMatch: 10,
            callback: results => 
              this.Invoke(new Action(() => listBox_choices.DataSource = results))
        );
    }

    private void textBox_search_TextChanged(object sender, EventArgs e)
    {
        // this will update the background worker's "current entry"
        _filter.SetCurrentEntry(textBox_search.Text);
    }
}

대략적인 스케치는 다음과 같습니다.

public class BackgroundWordFilter : IDisposable
{
    private readonly List<string> _items;
    private readonly AutoResetEvent _signal = new AutoResetEvent(false);
    private readonly Thread _workerThread;
    private readonly int _maxItemsToMatch;
    private readonly Action<List<string>> _callback;

    private volatile bool _shouldRun = true;
    private volatile string _currentEntry = null;

    public BackgroundWordFilter(
        List<string> items,
        int maxItemsToMatch,
        Action<List<string>> callback)
    {
        _items = items;
        _callback = callback;
        _maxItemsToMatch = maxItemsToMatch;

        // start the long-lived backgroud thread
        _workerThread = new Thread(WorkerLoop)
        {
            IsBackground = true,
            Priority = ThreadPriority.BelowNormal
        };

        _workerThread.Start();
    }

    public void SetCurrentEntry(string currentEntry)
    {
        // set the current entry and signal the worker thread
        _currentEntry = currentEntry;
        _signal.Set();
    }

    void WorkerLoop()
    {
        while (_shouldRun)
        {
            // wait here until there is a new entry
            _signal.WaitOne();
            if (!_shouldRun)
                return;

            var entry = _currentEntry;
            var results = new List<string>();

            // if there is nothing to process,
            // return an empty list
            if (string.IsNullOrEmpty(entry))
            {
                _callback(results);
                continue;
            }

            // do the search in a for-loop to 
            // allow early termination when current entry
            // is changed on a different thread
            foreach (var i in _items)
            {
                // if matched, add to the list of results
                if (i.Contains(entry))
                    results.Add(i);

                // check if the current entry was updated in the meantime,
                // or we found enough items
                if (entry != _currentEntry || results.Count >= _maxItemsToMatch)
                    break;
            }

            if (entry == _currentEntry)
                _callback(results);
        }
    }

    public void Dispose()
    {
        // we are using AutoResetEvent and a background thread
        // and therefore must dispose it explicitly
        Dispose(true);
    }

    private void Dispose(bool disposing)
    {
        if (!disposing)
            return;

        // shutdown the thread
        if (_workerThread.IsAlive)
        {
            _shouldRun = false;
            _currentEntry = null;
            _signal.Set();
            _workerThread.Join();
        }

        // if targetting .NET 3.5 or older, we have to
        // use the explicit IDisposable implementation
        (_signal as IDisposable).Dispose();
    }
}

또한 _filter부모 Form가 삭제 될 때 실제로 인스턴스 를 삭제해야합니다 . 즉, Form의 Dispose메서드 ( YourForm.Designer.cs파일 내부 )를 열고 다음과 같이 편집해야합니다 .

// inside "xxxxxx.Designer.cs"
protected override void Dispose(bool disposing)
{
    if (disposing)
    {
        if (_filter != null)
            _filter.Dispose();

        // this part is added by Visual Studio designer
        if (components != null)
            components.Dispose();
    }

    base.Dispose(disposing);
}

내 컴퓨터에서는 매우 빠르게 작동하므로 더 복잡한 솔루션을 찾기 전에이를 테스트하고 프로파일 링해야합니다.

즉, "더 복잡한 솔루션"은 마지막 두 개의 결과를 사전에 저장 한 다음 새 항목이 마지막 문자의 첫 번째 문자 만 다른 것으로 밝혀진 경우에만 필터링하는 것입니다.

몇 가지 테스트를 수행했으며 120,000 개의 항목 목록을 검색하고 항목으로 새 목록을 채우는 데는 무시할 수있는 시간이 걸립니다 (모든 문자열이 일치하더라도 약 1/50 초).

따라서 현재보고있는 문제는 데이터 소스 채우기에서 발생해야합니다.

listBox_choices.DataSource = ...

목록 상자에 너무 많은 항목을 넣는 것 같습니다.

다음과 같이 처음 20 개 항목으로 제한해야합니다.

listBox_choices.DataSource = allUsers.Where(item => item.Contains(textBox_search.Text))
    .Take(20).ToList();

또한 다른 사람들이 지적했듯이의 TextBox.Text각 항목에 대한 속성에 액세스하고 있음을 유의하십시오 allUsers. 다음과 같이 쉽게 수정할 수 있습니다.

string target = textBox_search.Text;
listBox_choices.DataSource = allUsers.Where(item => item.Contains(target))
    .Take(20).ToList();

그러나 나는 TextBox.Text50 만 번 액세스하는 데 걸리는 시간을 측정 했으며 OP에 언급 된 1-3 초보다 훨씬 적은 0.7 초 밖에 걸리지 않았습니다. 그래도 이것은 가치있는 최적화입니다.

접미사 트리 사용 인덱스로. 또는 모든 이름의 모든 접미사를 해당 이름 목록과 연결하는 정렬 된 사전을 구축하십시오.

입력 :

Abraham
Barbara
Abram

구조는 다음과 같습니다.

a -> Barbara
ab -> Abram
abraham -> Abraham
abram -> Abram
am -> Abraham, Abram
aham -> Abraham
ara -> Barbara
arbara -> Barbara
bara -> Barbara
barbara -> Barbara
bram -> Abram
braham -> Abraham
ham -> Abraham
m -> Abraham, Abram
raham -> Abraham
ram -> Abram
rbara -> Barbara

검색 알고리즘

사용자 입력 "bra"를 가정합니다.

1. 사용자 입력에 대해 사전을 양분 하여 사용자 입력 또는 이동할 수있는 위치를 찾습니다. 이렇게하면 "barbara"- "bra"보다 낮은 마지막 키를 찾습니다. "브라"의 하한이라고합니다. 검색에는 로그 시간이 걸립니다.
2. 사용자 입력이 더 이상 일치하지 않을 때까지 찾은 키부터 계속 반복합니다. 이것은 "bram"-> Abram 및 "braham"-> Abraham을 줄 것입니다.
3. 반복 결과 (Abram, Abraham)를 연결하고 출력합니다.

이러한 트리는 하위 문자열을 빠르게 검색하도록 설계되었습니다. 성능은 O (log n)에 가깝습니다. 이 접근 방식은 GUI 스레드에서 직접 사용할 수있을만큼 빠르게 작동 할 것이라고 생각합니다. 또한 동기화 오버 헤드가 없기 때문에 스레드 솔루션보다 빠르게 작동합니다.

텍스트 검색 엔진 (예 : Lucene.Net ) 또는 데이터베이스 (예 : SQL CE , SQLite 등 의 임베디드 엔진을 고려할 수 있음 )가 필요합니다. 즉, 색인화 된 검색이 필요합니다. 해시 기반 검색은 하위 문자열을 검색하기 때문에 여기서 적용 할 수 없지만 해시 기반 검색은 정확한 값을 검색하는 데 적합합니다.

그렇지 않으면 컬렉션을 반복하는 반복 검색이됩니다.

"디 바운스"유형의 이벤트를 갖는 것도 유용 할 수 있습니다. 이벤트를 시작하기 전에 변경이 완료 될 때까지 일정 시간 (예 : 200ms)을 기다린다는 점에서 스로틀 링과 다릅니다.

참조 디 바운스 및 스로틀 : 시각적 설명 디 바운싱에 대한 자세한 정보를 얻을 수 있습니다. 이 기사는 C # 대신 JavaScript에 초점을 맞추고 있지만 원칙이 적용됩니다.

이것의 장점은 여전히 ​​쿼리를 입력 할 때 검색하지 않는다는 것입니다. 그런 다음 한 번에 두 개의 검색을 수행하려는 시도를 중지해야합니다.

다른 스레드에서 검색을 실행하고 해당 스레드가 실행되는 동안 로딩 애니메이션이나 진행률 표시 줄을 표시합니다.

LINQ 쿼리 를 병렬화 할 수도 있습니다.

var queryResults = strings.AsParallel().Where(item => item.Contains("1")).ToList();

다음은 AsParallel ()의 성능 이점을 보여주는 벤치 마크입니다.

{
    IEnumerable<string> queryResults;
    bool useParallel = true;

    var strings = new List<string>();

    for (int i = 0; i < 2500000; i++)
        strings.Add(i.ToString());

    var stp = new Stopwatch();

    stp.Start();

    if (useParallel)
        queryResults = strings.AsParallel().Where(item => item.Contains("1")).ToList();
    else
        queryResults = strings.Where(item => item.Contains("1")).ToList();

    stp.Stop();

    Console.WriteLine("useParallel: {0}\r\nTime Elapsed: {1}", useParallel, stp.ElapsedMilliseconds);
}

최신 정보:

프로파일 링을했습니다.

(업데이트 3)

• 목록 내용 : 0에서 2.499.999까지 생성 된 숫자
• 필터 텍스트 : 123 (결과 20.477 개)
• Core i5-2500, Win7 64 비트, 8GB RAM
• VS2012 + JetBrains dotTrace

2.500.000 레코드에 대한 초기 테스트 실행에는 20.000ms가 소요되었습니다.

가장 큰 범인은 textBox_search.Text내부에 대한 호출 Contains입니다. 이렇게하면 get_WindowText텍스트 상자 의 값 비싼 메서드에 대한 각 요소가 호출됩니다 . 코드를 다음과 같이 변경하기 만하면됩니다.

    var text = textBox_search.Text;
    listBox_choices.DataSource = allUsers.Where(item => item.Contains(text)).ToList();

실행 시간을 1.858ms 로 줄였습니다 .

업데이트 2 :

다른 두 가지 중요한 병목 현상은 이제 호출 string.Contains(실행 시간의 약 45 %)과 목록 상자 요소의 업데이트 set_Datasource(30 %)입니다.

Basilevs가 필요한 비교 횟수를 줄이고 키를 누른 후 검색에서 처리 시간을 파일에서 이름을로드 할 때까지 푸시하도록 제안했듯이 Suffix 트리를 생성하여 속도와 메모리 사용량 사이의 균형을 맞출 수 있습니다. 사용자에게 바람직 할 수 있습니다.

목록 상자에 요소를로드하는 성능을 높이려면 처음 몇 개의 요소 만로드하고 사용 가능한 추가 요소가 있음을 사용자에게 표시하는 것이 좋습니다. 이렇게하면 사용자에게 사용 가능한 결과가 있다는 피드백을 제공하여 더 많은 문자를 입력하여 검색을 구체화하거나 버튼을 눌러 전체 목록을로드 할 수 있습니다.

를 사용 BeginUpdate하고 EndUpdate의 실행 시간을 변경하지 않았습니다 set_Datasource.

다른 사람들이 여기에서 언급했듯이 LINQ 쿼리 자체는 매우 빠르게 실행됩니다. 병목 현상이 목록 상자 자체를 업데이트하는 것이라고 생각합니다. 다음과 같이 시도해 볼 수 있습니다.

if (textBox_search.Text.Length > 2)
{
    listBox_choices.BeginUpdate(); 
    listBox_choices.DataSource = allUsers.Where(item => item.Contains(textBox_search.Text)).ToList();
    listBox_choices.EndUpdate(); 
}

이게 도움이 되길 바란다.

접두사로만 일치한다고 가정하면 찾고있는 데이터 구조를 "접두사 트리"라고도 하는 trie 라고합니다 . 그만큼IEnumerable.Where지금 사용하고 있는지 방법은 각 액세스에 대한 당신의 사전에있는 모든 항목을 반복하는 것입니다.

이 스레드 는 C #에서 트라이를 만드는 방법을 보여줍니다.

WinForms ListBox 컨트롤은 실제로 여기에서 적입니다. 레코드를로드하는 속도가 느리며 ScrollBar는 120,000 개의 레코드를 모두 표시하기 위해 싸울 것입니다.

데이터를 보관하기 위해 단일 열 [UserName]이있는 DataTable에 데이터 소스가있는 구식 DataGridView를 사용해보십시오.

private DataTable dt;

public Form1() {
  InitializeComponent();

  dt = new DataTable();
  dt.Columns.Add("UserName");
  for (int i = 0; i < 120000; ++i){
    DataRow dr = dt.NewRow();
    dr[0] = "user" + i.ToString();
    dt.Rows.Add(dr);
  }
  dgv.AutoSizeColumnsMode = DataGridViewAutoSizeColumnsMode.Fill;
  dgv.AllowUserToAddRows = false;
  dgv.AllowUserToDeleteRows = false;
  dgv.RowHeadersVisible = false;
  dgv.DataSource = dt;
}

그런 다음 TextBox의 TextChanged 이벤트에서 DataView를 사용하여 데이터를 필터링합니다.

private void textBox1_TextChanged(object sender, EventArgs e) {
  DataView dv = new DataView(dt);
  dv.RowFilter = string.Format("[UserName] LIKE '%{0}%'", textBox1.Text);
  dgv.DataSource = dv;
}

먼저 ListControl데이터 소스를 보는 방법을 변경 하고 결과 IEnumerable<string>를 List<string>. 특히 몇 개의 문자를 입력 한 경우 비효율적 일 수 있습니다 (필요하지 않음). 데이터의 광범위한 사본을 만들지 마십시오 .

• .Where()결과를 IList(검색) 에서 필요한 것만 구현하는 컬렉션으로 래핑 합니다 . 이렇게하면 입력 된 각 문자에 대한 새로운 큰 목록을 만들 수 있습니다.
• 대안으로 LINQ를 피하고 더 구체적이고 최적화 된 것을 작성합니다. 목록을 메모리에 유지하고 일치하는 인덱스 배열을 만들고 배열을 재사용하여 각 검색에 대해 다시 할당 할 필요가 없습니다.

두 번째 단계는 작은 목록으로 충분할 때 큰 목록에서 검색하지 않는 것입니다. 사용자가 "ab"를 입력하기 시작하고 "c"를 추가하면 큰 목록에서 조사 할 필요가 없습니다. 필터링 된 목록에서 검색하면 충분합니다 (더 빠릅니다). 상세 검색매번 이 가능하며 매번 전체 검색을 수행하지 마십시오.

세 번째 단계는 더 어려울 수 있습니다 . 빠르게 검색 할 수 있도록 데이터를 정리하십시오 . 이제 데이터를 저장하는 데 사용하는 구조를 변경해야합니다. 다음과 같은 나무를 상상해보십시오.

알파벳
 더 나은 Ceil 추가
 뼈 윤곽 위

이것은 단순히 배열로 구현 될 수 있습니다 (ANSI 이름으로 작업하는 경우 그렇지 않으면 사전이 더 좋습니다). 다음과 같이 목록을 작성하십시오 (예시 목적으로 문자열의 시작과 일치 함).

var dictionary = new Dictionary<char, List<string>>();
foreach (var user in users)
{
    char letter = user[0];
    if (dictionary.Contains(letter))
        dictionary[letter].Add(user);
    else
    {
        var newList = new List<string>();
        newList.Add(user);
        dictionary.Add(letter, newList);
    }
}

그러면 첫 번째 문자를 사용하여 검색이 수행됩니다.

char letter = textBox_search.Text[0];
if (dictionary.Contains(letter))
{
    listBox_choices.DataSource =
        new MyListWrapper(dictionary[letter].Where(x => x.Contains(textBox_search.Text)));
}

MyListWrapper()첫 번째 단계에서 제안한대로 사용 했습니다 (하지만 간결성을 위해 두 번째 제안에서 생략했습니다. 사전 키에 맞는 크기를 선택하면 각 목록을 짧고 빠르게 유지하여 다른 것은 피할 수 있습니다). 또한 사전에 처음 두 문자를 사용하려고 할 수 있습니다 (목록이 많고 짧음). 이것을 확장하면 나무가 생깁니다 (하지만 그렇게 많은 수의 항목이 있다고 생각하지 않습니다).

문자열 검색을위한 다양한 알고리즘 이 있습니다 (관련 데이터 구조 포함).

• 유한 상태 오토 마톤 기반 검색 :이 접근 방식에서는 저장된 검색 문자열을 인식하는 결정 론적 유한 오토 마톤 (DFA)을 구성하여 역 추적을 방지합니다. 이들은 구성하는 데 비용이 많이 들지만 일반적으로 powerset 구성을 사용하여 생성되지만 사용이 매우 빠릅니다.
• 스텁 : Knuth–Morris–Pratt는 검색 할 문자열이있는 입력을 접미사로 인식하는 DFA를 계산합니다. Boyer–Moore는 바늘 끝부터 검색을 시작하므로 일반적으로 각 단계에서 전체 바늘 길이만큼 앞으로 이동할 수 있습니다. Baeza–Yates는 이전 j 문자가 검색 문자열의 접두사 였는지 여부를 추적하므로 퍼지 문자열 검색에 적용 할 수 있습니다. bitap 알고리즘은 Baeza–Yates의 접근 방식을 적용한 것입니다.
• 색인 방법 : 더 빠른 검색 알고리즘은 텍스트의 전처리를 기반으로합니다. 예를 들어 접미사 트리 또는 접미사 배열과 같은 하위 문자열 인덱스를 빌드 한 후 패턴 발생을 빠르게 찾을 수 있습니다.
• 기타 변형 : 트라이 그램 검색과 같은 일부 검색 방법은 "일치 / 불일치"보다는 검색 문자열과 텍스트 사이의 "가까움"점수를 찾기위한 것입니다. 이를 "퍼지"검색이라고도합니다.

병렬 검색에 대한 몇 마디. 가능하지만 병렬로 만들기위한 오버 헤드가 검색 자체보다 훨씬 높을 수 있기 때문에 사소한 일이 아닙니다. 검색 자체를 병렬로 수행하지는 않지만 (파티션 및 동기화가 곧 너무 확장되고 복잡해질 수 있음) 검색을 별도의 스레드로 이동합니다 . 주 스레드가 바쁘지 않으면 사용자가 입력하는 동안 지연을 느끼지 않을 것입니다 (200ms 후에 목록이 표시되는지 여부는 기록하지 않지만 입력 한 후 50ms를 기다려야하는 경우 불편 함을 느낄 것입니다) . 물론 검색 자체가 충분히 빨라야합니다.이 경우 검색 속도를 높이기 위해 스레드를 사용하지 않고 UI 응답 성 을 유지합니다 . 쿼리를 UI가 중단되지 않지만 쿼리가 느린 경우 별도의 스레드에서 여전히 느립니다 (또한 여러 개의 순차적 요청도 처리해야 함).

PLINQ (Parallel LINQ)를 사용해 볼 수 있습니다. 이것이 속도 향상을 보장하지는 않지만 시행 착오를 통해 알아 내야합니다.

더 빨리 만들 수 있을지 의심 스럽지만 다음을 수행해야합니다.

a) AsParallel LINQ 확장 방법 사용

a) 어떤 종류의 타이머를 사용하여 필터링 지연

b) 다른 스레드에 필터링 방법을 넣습니다.

string previousTextBoxValue어딘가에 보관하십시오 . 1000ms의 지연으로 타이머를 만드십시오 .이 값이 값 previousTextBoxValue과 같으면 틱에서 검색을 시작 textbox.Text합니다. 그렇지 않은 경우- previousTextBoxValue현재 값으로 다시 할당 하고 타이머를 재설정합니다. 타이머 시작을 텍스트 상자 변경 이벤트로 설정하면 응용 프로그램이 더 부드러워집니다. 1-3 초에 120,000 개의 레코드를 필터링하는 것은 괜찮지 만 UI는 응답 성을 유지해야합니다.

BindingSource.Filter 함수를 사용해 볼 수도 있습니다 . 나는 그것을 사용했고 그것은 검색되는 텍스트 로이 속성을 업데이트 할 때마다 많은 레코드에서 필터링하는 매력처럼 작동합니다. 또 다른 옵션은 TextBox 컨트롤에 AutoCompleteSource 를 사용하는 것 입니다.

도움이 되었기를 바랍니다.

컬렉션을 정렬하고 시작 부분 만 일치하도록 검색하고 일부 수로 검색을 제한하려고합니다.

그래서 초기화

allUsers.Sort();

및 검색

allUsers.Where(item => item.StartWith(textBox_search.Text))

캐시를 추가 할 수 있습니다.

병렬을 사용하십시오 LINQ. PLINQLINQ to Objects의 병렬 구현입니다. PLINQ는 T : System.Linq 네임 스페이스에 대한 확장 메서드로 LINQ 표준 쿼리 연산자의 전체 집합을 구현하고 병렬 작업을위한 추가 연산자를 가지고 있습니다. PLINQ는 LINQ 구문의 단순성과 가독성을 병렬 프로그래밍의 힘과 결합합니다. 작업 병렬 라이브러리를 대상으로하는 코드와 마찬가지로 PLINQ 쿼리는 호스트 컴퓨터의 기능에 따라 동시성 정도가 확장됩니다.

PLINQ 소개

PLINQ의 속도 향상 이해

또한 Lucene.Net 을 사용할 수 있습니다 .

Lucene.Net은 C #으로 작성되고 .NET 런타임 사용자를 대상으로하는 Lucene 검색 엔진 라이브러리의 포트입니다. Lucene 검색 라이브러리는 반전 된 색인을 기반으로합니다. Lucene.Net에는 세 가지 주요 목표가 있습니다.

내가 본 것에 따르면 나는 목록을 정렬한다는 사실에 동의합니다.

그러나 목록이 구조 일 때 정렬하는 것은 매우 느릴 것이며 빌드 할 때 정렬하면 더 나은 실행 시간을 갖게됩니다.

그렇지 않으면 목록을 표시하거나 순서를 유지할 필요가없는 경우 해시 맵을 사용하십시오.

해시 맵은 문자열을 해시하고 정확한 오프셋에서 검색합니다. 더 빨라야한다고 생각합니다.

BinarySearch 메서드를 사용하면 Contains 메서드보다 빠르게 작동합니다.

포함은 O (n)입니다. BinarySearch는 O (lg (n))입니다.

정렬 된 컬렉션은 검색에서 더 빨리 작동하고 새 요소를 추가 할 때는 더 느리게 작동해야한다고 생각하지만 검색 성능 문제 만 있다는 것을 이해했습니다.