Такой вопрос. Допустим вам нужен полнотекстовый поиск по некому списку сообщений. Если этих сообщений, к примеру, 150 тыс. и общий их объем данных около 150 Мб — то это говно-вопрос, по сути, можно просто тупо искать без всякой индексации, загрузив единожды все это дело в ОЗУ. Будет быстро.
Скрытый текст
using System;
using System.Diagnostics;
using System.Text;
namespace ConsoleApp24
{
class Program
{
static void Main(string[] args)
{
var sb = new StringBuilder();
for (int i = 0; i < 150_000; i++)
{
if (i == 75_000)
sb.Append("иголка");
sb.Append(GetRandom1024bString());
}
string s = sb.ToString();
Stopwatch sw = new Stopwatch();
sw.Reset();
sw.Start();
int index = s.IndexOf("иголка", StringComparison.Ordinal);
sw.Stop();
Console.WriteLine(index);
Console.WriteLine(sw.ElapsedMilliseconds);
Console.WriteLine("Hello World!");
}
private static Random _random = new Random();
public static string GetRandom1024bString()
{
StringBuilder sb = new StringBuilder(1024);
for (int i = 0; i < 1024; i++)
{
sb.Append((char) _random.Next(32, 122));
}
return sb.ToString();
}
}
}
Вывод:
76800000
17
Просто тупой поиск на моем старом ноуте — 17 миллисекунд. А что такое 150 МБ памяти по нашим временам? Да это пустое место, которым можно пренебречь.
Ок. Как сделать дешевле? Или если данных мало, несколько сотен мегабайт — то самое тупое решение будет ничем не хуже промышленного?
Берем СУБД бесплатную и популярную. Номер 1 сейчас — это postgre (ранее была MySQL) — кто мы такие, чтобы противиться сообществу. Там есть полнотекстовый поиск из коробки. Загружаем эти же 150 Мб. текста, разбив на порции. Но почему-то получилось медленее, видимо связано с тем, что хранится на диске все это дело и пока данных мало, то смысла в СУБД нет (или типа выбрать опцию, чтобы не загружала на диск а держала в памяти данные этой таблицы).
Далее, еще все юзают Elastic Search. Тоже нужно ставить и проверять как поведет себя именно с твоим количеством данных.
Ну и вопрос. Можно ли как-то сделать выбор не проверяя все самому? То есть какая-то сводная таблица с результатами тестов и пр. — есть где-нибудь?
S>Берем СУБД бесплатную и популярную. Номер 1 сейчас — это postgre (ранее была MySQL) — кто мы такие, чтобы противиться сообществу. Там есть полнотекстовый поиск из коробки. Загружаем эти же 150 Мб. текста, разбив на порции. Но почему-то получилось медленее, видимо связано с тем, что хранится на диске все это дело и пока данных мало, то смысла в СУБД нет (или типа выбрать опцию, чтобы не загружала на диск а держала в памяти данные этой таблицы).
насколько медленнее? в конфиге буфер достаточный?
Re[2]: Полнотекстовый поиск - как выбрать, не проверяя?
Здравствуйте, Je suis Mamut, Вы писали:
JSM>насколько медленнее? в конфиге буфер достаточный?
Детально не разбирался, может и не достаточный буфер, не настраивал ничего. Просто понять в том ли направлении иду. Увидеть бы сводную таблицу с тестовыми результатами для разных объемов данных...
Re: Полнотекстовый поиск - как выбрать, не проверяя?
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос. Допустим вам нужен полнотекстовый поиск по некому списку сообщений. Если этих сообщений, к примеру, 150 тыс. и общий их объем данных около 150 Мб — то это говно-вопрос, по сути, можно просто тупо искать без всякой индексации, загрузив единожды все это дело в ОЗУ. Будет быстро.
Ты серьезно сравниваешь indexof по 150 мб строке и полнотекстовый поиск в базе?
Re[2]: Полнотекстовый поиск - как выбрать, не проверяя?
G>> Ты серьезно сравниваешь indexof по 150 мб строке и полнотекстовый поиск в базе? S> Почему нет? Если я эту строку разобью на список из 150 тыс. строк и буду искать в цикле — вам станет легче?
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос. Допустим вам нужен полнотекстовый поиск по некому списку сообщений. Если этих сообщений, к примеру, 150 тыс. и общий их объем данных около 150 Мб — то это говно-вопрос, по сути, можно просто тупо искать без всякой индексации, загрузив единожды все это дело в ОЗУ. Будет быстро.
S>Ок. Как сделать дешевле? Или если данных мало, несколько сотен мегабайт — то самое тупое решение будет ничем не хуже промышленного?
Можно построить суффиксное дерево, можно тупо искать в лоб по строке и т.п. — главный вопрос "что оптимизируем".
S>Берем СУБД бесплатную и популярную. Номер 1 сейчас — это postgre (ранее была MySQL) — кто мы такие, чтобы противиться сообществу. Там есть полнотекстовый поиск из коробки. Загружаем эти же 150 Мб. текста, разбив на порции. Но почему-то получилось медленее, видимо связано с тем, что хранится на диске все это дело и пока данных мало, то смысла в СУБД нет (или типа выбрать опцию, чтобы не загружала на диск а держала в памяти данные этой таблицы).
Перебор. Забиваем гвозди кувалдой.
S>Далее, еще все юзают Elastic Search. Тоже нужно ставить и проверять как поведет себя именно с твоим количеством данных.
Перебор. Строим металлургическое предприятие полного цикла, чтобы забить всего один сапожный гвоздик.
S>Ну и вопрос. Можно ли как-то сделать выбор не проверяя все самому? То есть какая-то сводная таблица с результатами тестов и пр. — есть где-нибудь?
Гуглить, сравнивать, думать. Гвоздь сам себя не звбьёт, всё как обычно.
