Очередной алгоритм поиска - помогите кто-нибудь, пожалуйста

Любые обсуждения, не нарушающие правил форума.

Модератор: Модераторы

Очередной алгоритм поиска - помогите кто-нибудь, пожалуйста

Сообщение azsx » 28.09.2016 17:55:18

Вкратце, я качаю сайты с интернета, чтобы искать по html коду. То есть в итоге, могу найти все сайты с заполненым description или подгружающие определенный js файл. Мне надо сделать на этих данных поиск, который выводил бы первые 1000 результатов "внезапно" и сразу в несколько потоков. Я уже попробовал поиск по триграммам в 1 таблице постгрес, всё плохо, скорость ужасная.
Сейчас я хочу сделать поиск по триграммам разделенным на файлы, хочу посоветоваться. Допустим есть файлы (название по сути триграмма, данные в файле).
ааа.txt:1,2,3,4,12;
ббб.txt:2,3,4,5,13;
ввв.txt:3,4,5,6,14;
ддд:1,3,5,7,15
Отмечу, очень часто номера действительно будут идти последовательно для популярных триграмм. Но не всегда.
Мне получить первую тысячу номеров, которые отвечают условию: есть (ааа и ббб) нет (ввв).То есть запрос должен вернуть только номера 1, 2, 12, 13. На сегодня у меня около 200 гб полусжатых html кодов уникальных страниц и миллионов 15 сайтов. Ну и куча ссылок в очереди. Какие у меня вопросы.
1. Есть три варианта сохранения триграмм (количество, чего там): 3511808 штук - почти весь ascii диапазон; 681472 штук - всё кроме ру букв; 238328 штук - всё, кроме ру букв и верхнего енгл регистра. С одной стороны хочется искать ру символы (анкор листы и ссылочное), но скорее всего работать будет всё это только под енгл и изначально ориентировано на поиск кода. К тому же, парсится весь интернет, а исключение я сделаю только для ру букв. Какой вариант выбрали бы Вы?
2. Я работал и с 60 миллионов файлов, меня не пугает разница в 600 тысяч и 200 тысяч. Какие минусы, кроме более активного юзанья диска есть у большого числа файлов?
3. Фишка файлов, по моему мнению, что я получу колоночную БД в том виде как я её понимаю. То есть у меня будет:
ааа.txt:1:4\n12;
ббб.txt:2:5\n13;
ввв.txt:3:6\n14;
ддд:1:7\n15
Так как речь идет о миллионах записей, то экономия места будет приличная. Выборку мне номеров надо будет писать самостоятельно, то есть алгоритма ещё нет.
Не слишком ли сложно я задумал? Как можно сделать намного проще? Или как бы сделали Вы?
4. Точно ли делать на файлах? Может многие нормальные БД спокойно переварят 600 тысяч таблиц? Какую БД посоветуете?
зы
Sphinx установить не предлагайте. Первое, я хочу сам написать алгоритм, я программист на пхп и паскале или где? Второе, Всё таки он заточен под поиск по словам, а мне надо чтобы вырванные из контекста теги искало. Например, <h1 style="color:blue;">This is a Blue Heading</h1>
azsx
энтузиаст
 
Сообщения: 959
Зарегистрирован: 16.11.2015 06:38:32

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение gvido » 28.09.2016 18:08:38

Добрый день. Возможно я глупость предложу, но все таки - индексировать таблицы по полям поиска, не?
gvido
постоялец
 
Сообщения: 188
Зарегистрирован: 28.03.2012 11:35:31

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение azsx » 28.09.2016 18:23:29

индексировать таблицы по полям поиска, не?

Допустим, у меня таблица: счетчик, триграмма, мд5 (уникальный текст, его я номером заменю). Индекс по триграмме, все триграммы в 1 таблице. При 91 миллионе строк, таблица занимает 6,5 гб, а индекс 10 гб. Поиск выборка - ниочём. Крайне долго. А сайтов там мало, может несколько десятков тысяч. То есть будет всё намного хуже.
Я живу в нищите, так что надо ориентироваться на 32 гб оперативной памяти - под всё.
зы
или что индексировать - напишите прямо.
azsx
энтузиаст
 
Сообщения: 959
Зарегистрирован: 16.11.2015 06:38:32

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение gvido » 29.09.2016 11:44:33

Опишите структуру таблиц и типов данных поподробнее, критерии поиска с привязкой к полям. Первичный индекс, как и дополнительные, настраивается один при создании таблицы и записи, при добавлении, индексируются. По моему, получить топ 100 или более в индексированной таблице проще и быстрее. Если индекс отсутствует то, времени на поиск, сортировку тратится в разы больше. Вы вынуждены, в данном случае, в цикле пролопатить все записи таблицы.
У меня были случаи, когда возникала необходимость поиска, сортировки или группировки "чужих" сырых данных и с объемами в разы меньшими, но и там я старался приводить их к какой то упорядоченности.
Возможно кто-то из коллег откликнется на ваш запрос и предложит другой вариант.
gvido
постоялец
 
Сообщения: 188
Зарегистрирован: 28.03.2012 11:35:31

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение azsx » 29.09.2016 12:41:40

Возможно кто-то из коллег откликнется на ваш запрос и предложит другой вариант.

Кроме вас не откликается никто :)
Опишите структуру таблиц и типов данных поподробнее

---
Таблица shingl3
id_shingl3 bigint NOT NULL DEFAULT nextval('shingl3_id_shingl3_seq1'::regclass),
text_shingl3 character(3),
md5_ind character(32)
---
Размер таблицы 7 гб, индексы 12 гб. Строк 9 190 985. Когда я буду переделывать, я заменю мд5 (32 байта) на номер (8 байт).
Запрос ищу bbb
SELECT md5_ind, COUNT(md5_ind) FROM public.shingl3 WHERE text_shingl3 IN ('bbb') GROUP BY md5_ind HAVING COUNT(md5_ind) = 1 limit 100;
ps
и это всего 33 606 сайтов. Всего!!!
azsx
энтузиаст
 
Сообщения: 959
Зарегистрирован: 16.11.2015 06:38:32

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение gvido » 29.09.2016 13:57:52

Так...
SELECT md5_ind, COUNT(md5_ind) FROM public.shingl3 WHERE text_shingl3 IN ('bbb') GROUP BY md5_ind HAVING COUNT(md5_ind) = 1 limit 100;

Если я правильно понимаю суть вашего запроса:
text_shingl3 IN ('bbb')
- это результат вложенного запроса или подкинутый список значений, по которому выбираются данные из тыблицы public.shingl3, группируются по полю md5_ind с ограничением повторов.
Смысл то глобальный в чем? Избавиться от дубликатов и получить набор уникальных данных?

В любом случае при поиске, для себя решил, необходимо максимально сокращать получаемый набор данных.
Если у вас нет возможности искать конкретное значение, то нужно составить запрос который вернет минимальное количество записей отвечающих вашим условиям выборки.
gvido
постоялец
 
Сообщения: 188
Зарегистрирован: 28.03.2012 11:35:31

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение azsx » 29.09.2016 17:36:08

Смысл то глобальный в чем?

Главный смысл искать по коду достаточно быстро. То есть найти, например, все сайты у которых есть теги <h1> <h3> <h4> и нет тега <h2>
я вижу, что вы меня не понимаете, но как объяснить вам не знаю. Например, я ищу фразу
mama abama
такая фраза именно сокращается моим запросом
Код: Выделить всё
SELECT md5_ind, COUNT(md5_ind) FROM public.shingl3 WHERE text_shingl3 IN ('mam', 'ama', 'aba', 'bam') GROUP BY md5_ind HAVING COUNT(md5_ind) = 4 limit 100;

Вы это имеете в виду под сокращением?
---
Или такой пример
palala malala talala lalala palala
Код: Выделить всё
SELECT md5_ind, COUNT(md5_ind) FROM public.shingl3 WHERE text_shingl3 IN ('pal', 'ala', 'lal', 'mal', 'tal') GROUP BY md5_ind HAVING COUNT(md5_ind) = 5 limit 100;
azsx
энтузиаст
 
Сообщения: 959
Зарегистрирован: 16.11.2015 06:38:32

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение gvido » 03.10.2016 12:03:00

Я действительно не совсем понимаю Вас. Поле text_shingl3 ограничено 3 символами и по тексту запроса Вы отбираете записи по точному совпадению значений в списке. Этот подстановочный список можно формировать вложенным запросом. То есть модифицировать запрос примерно так
Код: Выделить всё
SELECT md5_ind, COUNT(md5_ind) FROM public.shingl3 WHERE text_shingl3 IN (select seek_field from needtable Where (seek_field  Like '%pal%' or seek_field  Like '%ala%') and (seek_field Not Like '%tol%' ) GROUP BY Seek_field ) GROUP BY md5_ind HAVING COUNT(md5_ind) = 5 limit 100;
gvido
постоялец
 
Сообщения: 188
Зарегистрирован: 28.03.2012 11:35:31

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение azsx » 03.10.2016 12:31:40

Слишком долгий запрос будет, мне кажется.
зы
давайте поставим ограничение, поиск по всей бд в минуту.
azsx
энтузиаст
 
Сообщения: 959
Зарегистрирован: 16.11.2015 06:38:32

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение gvido » 03.10.2016 15:35:33

Смысл во вложенном запросе основной - Можно получить текущий список возможных вхождений и по этому списку дополнительно ограничить выборку основным запросом. Скорость будет гораздо выше чем лопатить блок записей из приложения.
gvido
постоялец
 
Сообщения: 188
Зарегистрирован: 28.03.2012 11:35:31

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение azsx » 03.10.2016 16:23:26

Логично, подумаю.
azsx
энтузиаст
 
Сообщения: 959
Зарегистрирован: 16.11.2015 06:38:32

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение Ism » 07.10.2016 02:32:06

Mysql может загружать индексы в оперативу http://sqlinfo.ru/articles/info/3.html
Ism
энтузиаст
 
Сообщения: 908
Зарегистрирован: 06.04.2007 17:36:08

Re: Очередной алгоритм поиска - помогите кто-нибудь, пожалуй

Сообщение serbod » 07.10.2016 17:16:26

В винде нежелательно иметь больше 2000 файлов в одной папке. Может случиться внезапная деградация производительности. Насчет линухов и разных файловых систем не знаю.
В случае триграмм было бы удобно сделать иерархию папок 1-2-3-я буква, получится всего по 2-4 десятка файлов в папке.
Аватара пользователя
serbod
постоялец
 
Сообщения: 449
Зарегистрирован: 16.09.2016 11:03:02
Откуда: Минск


Вернуться в Потрепаться

Кто сейчас на конференции

Сейчас этот форум просматривают: Yandex [Bot] и гости: 16

Рейтинг@Mail.ru