- Посоветуйте решение для поиска по большому объёму данных,
 ыы, 20:22 , 04-Дек-19 (1)>[оверквотинг удален]
> 1 Возможность запустить это всё на как можно более дешёвом и досутпном
> железе - это критично т.к. бюджет на инфраструктуту ограничен
> 2 Скорость поиска
> 3 Надёжность и отказоустойчивость
> 4 Лёгкость масштабирования
> Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше
> запутался.
> Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи
> каких технологий это можно было бы реализовать.
> Спасибо заранее всем откликнувшимся Все сущности которые вы назвали в контексте задачи- предполагают что вы планируете заниматься велосипедостроением. Потому что если готовы заплатить за решение - ваш вопрос вообще не имеет смысла.
- Посоветуйте решение для поиска по большому объёму данных, datahub.1, 20:29 , 04-Дек-19 (2)
>[оверквотинг удален]
>> 4 Лёгкость масштабирования
>> Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше
>> запутался.
>> Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи
>> каких технологий это можно было бы реализовать.
>> Спасибо заранее всем откликнувшимся
> Все сущности которые вы назвали в контексте задачи- предполагают что вы планируете
> заниматься велосипедостроением.
> Потому что если готовы заплатить за решение - ваш вопрос вообще
> не имеет смысла.Если и планировал то лишь от недостатка опыта.
Заплатить кому-то чтобы установил и настроил необходимый софт, запустил индексацию и сделал апи для вызова поиска у меня к сожалению возможности нету. Есть лишь спонсор на железо.
Я был бы Вам очень признателен за более детальный ответ.
- Посоветуйте решение для поиска по большому объёму данных, Licha Morada, 23:31 , 04-Дек-19 (3)
> Есть ~50M pdf документов, средний размер каждого ~1Mb, минимальный 10Kb, максимальный 50Mb.
> Суммарный объём выходит под 50Tb.
> 95% данных в документе это текст.
> Нужно обеспечить полнотекстовый поиск по всему объёму данных, тоесть есть фраза -
> надо показать документы где она встречается и (опционально) показать снипеты, тоесть
> текстовое окружение где в документе нашлась фраза.Попробуйте перевести базу документов (всю, или репрезентативную выборку) в текст, например с помощью pdftotext, чтобы оценить масштаб бедствия:
1. Насколько дорого (по вычислительным ресурсам) будет перевести документы в текст.
2. Сколько оно будет весить в тексте. Возможно удасться свести задачу к "поиску по большому количеству текстов", вместо "поиска по большому количеству PDF файлов". В теории, у вас будет репозиторий оригинальных PDF, соответсвующий ему репозиторий в TXT и база данных с индексом для поиска. На предмет решения из коробки, можно посмотреть на https://nextcloud.com/blog/nextcloud-11-introduces-full-text.../ и подобные. 50Т это вриад ли потянет, но имеет смысл попробовать, чтобы "пощупать" практические пределы. Сосвем нахаляву поиск по 50Т, боюсь, не получится. Может, лет через 20.
- Посоветуйте решение для поиска по большому объёму данных, Аноним, 02:53 , 06-Дек-19 (6)
Какой-нибудь cudagrep может помочь. Чем не на халяву?
- Посоветуйте решение для поиска по большому объёму данных, Licha Morada, 05:21 , 08-Дек-19 (16)
> Какой-нибудь cudagrep может помочь. Чем не на халяву?В 50М искать легко и это можно решить мимоходом.
Поиск в 50Г решается уже не в лоб, но если железо есть, то можно условно считать что халява.
С 50Т это уже не проходит. Наверное, можно решить задачу не потратив ни цента на лицензии, но потребуется время, скиллы и опять же железо.
- Посоветуйте решение для поиска по большому объёму данных, Аноним, 14:29 , 10-Дек-19 (17)
>> Какой-нибудь cudagrep может помочь. Чем не на халяву?
> железо.Тут (этим летом) вроде обещают 128 GB/s (в обе стороны) через 2 года в обычном pcie, так что скоро в каждой семье будет такое железо. Можно собрать 40 штук обычных ссд (3 GB/s) и вот уже 50 терабайт не проблема.
- Посоветуйте решение для поиска по большому объёму данных, Аноним, 10:35 , 05-Дек-19 (4) +1
Полнотекстовый поиск - это Sphinx, Elastic, Solr. Копайте в этих направлениях. На ютубе есть про них достаточно докладов в контексте большого кол-ва данных и высоких нагрузок.
- Посоветуйте решение для поиска по большому объёму данных, Миха, 18:17 , 11-Дек-19 (23)
> Полнотекстовый поиск - это Sphinx, Elastic, Solr. Копайте в этих направлениях. На
> ютубе есть про них достаточно докладов в контексте большого кол-ва данных
> и высоких нагрузок.Полнотекстовый поиск это... любая более-менее современная СУБД. А то, что вы перечислили, это о том, как продать обёртку от конфет, которые кто-то уже съел.
- Посоветуйте решение для поиска по большому объёму данных, datahub.1, 02:14 , 06-Дек-19 (5)
спасибо большое всем откликнувшимся
- Посоветуйте решение для поиска по большому объёму данных, ACCA, 04:02 , 06-Дек-19 (7)
- Посоветуйте решение для поиска по большому объёму данных, Pahanivo, 11:14 , 06-Дек-19 (8)
Ммм а история задачи какая? Откуда столько файлов и зачем такой объем в pdf?
- Посоветуйте решение для поиска по большому объёму данных, fantom, 12:20 , 06-Дек-19 (9)
>[оверквотинг удален]
> 1 Возможность запустить это всё на как можно более дешёвом и досутпном
> железе - это критично т.к. бюджет на инфраструктуту ограничен
> 2 Скорость поиска
> 3 Надёжность и отказоустойчивость
> 4 Лёгкость масштабирования
> Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше
> запутался.
> Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи
> каких технологий это можно было бы реализовать.
> Спасибо заранее всем откликнувшимся Ну вот вам как вариант идеи:
https://www.tsgrp.com/2015/03/10/hadoop-for-enterprise-conte.../ Hadoop - как масштабируемое распределенное хранилище,
Solr/Lucene to allow for full text and attribute searching
как поиск,
НО!!!
при любом подходе у вас минимум 1 из 2-х проблем:
Либо для быстрого поиска потребуется дополнительно куча места для индексов и дополнительных данных
.....
Либо поиск будет мало, что медленным, так еще и малопредсказуемым по времени ожидания результатов.
- Посоветуйте решение для поиска по большому объёму данных, fantom, 12:36 , 06-Дек-19 (10)
>[оверквотинг удален]
> Hadoop - как масштабируемое распределенное хранилище,
> Solr/Lucene to allow for full text and attribute searching
> как поиск,
> НО!!!
> при любом подходе у вас минимум 1 из 2-х проблем:
> Либо для быстрого поиска потребуется дополнительно куча места для индексов и дополнительных
> данных
> .....
> Либо поиск будет мало, что медленным, так еще и малопредсказуемым по времени
> ожидания результатов.10 шт. вот таких 8тб интелов, + которочку к ним соотв. и вполне может получиться чуть-ли не shell скриптами, самое узкое место в таких поисках -> ввод/вывод с диска данных, Вполне может оказаться, что решение из горы дешевых железяк может вылиться даже дороже.
https://www.amazon.com/dp/B0782Q4CV9?ascsubtag=s157562429393...
- Посоветуйте решение для поиска по большому объёму данных, Pahanivo, 13:29 , 06-Дек-19 (11)
> 10 шт. вот таких 8тб интелов, + которочку к ним соотв. и
> вполне может получиться чуть-ли не shell скриптами, самое узкое место в
> таких поисках -> ввод/вывод с диска данных, прямым поиском скриптами???
Даже если эти диски дадут реальные 3200mb/s последовательного чтения, даже если предположить что страйп
из десятка дисков даст кратное увеличение скорость до 32gb/s последовательнго чтения - то 50tb будут читаться прямым поиском минимум полчаса. Те в реальности один запрос в час.
- Посоветуйте решение для поиска по большому объёму данных, Pahanivo, 13:30 , 06-Дек-19 (12)
- Посоветуйте решение для поиска по большому объёму данных, fantom, 14:15 , 06-Дек-19 (13)
>> 10 шт. вот таких 8тб интелов, + которочку к ним соотв. и
>> вполне может получиться чуть-ли не shell скриптами, самое узкое место в
>> таких поисках -> ввод/вывод с диска данных,
> прямым поиском скриптами???
> Даже если эти диски дадут реальные 3200mb/s последовательного чтения, даже если предположить
> что страйп
> из десятка дисков даст кратное увеличение скорость до 32gb/s последовательнго чтения -
> то 50tb будут читаться прямым поиском минимум полчаса. Те в реальности
> один запрос в час.Так я и не спорю, для такого поиска на "дешевом железе" аналогичным подходом ждать результата неделю придется :)
- Посоветуйте решение для поиска по большому объёму данных, cool29, 02:22 , 07-Дек-19 (15)
>[оверквотинг удален]
> 1 Возможность запустить это всё на как можно более дешёвом и досутпном
> железе - это критично т.к. бюджет на инфраструктуту ограничен
> 2 Скорость поиска
> 3 Надёжность и отказоустойчивость
> 4 Лёгкость масштабирования
> Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше
> запутался.
> Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи
> каких технологий это можно было бы реализовать.
> Спасибо заранее всем откликнувшимся 1. штампуем 50000 баз. (50 000 * 1 000 000 записей * 1024 байта = 50 Tb)
2. каждой pdf присваиваем уникальный ид. Храним в 1 отдельной базе (можно с описанием)
3. Данные записываем в базу записями: КАЖДАЯ БАЗА СОДЕРЖИТ 1 000 000 записей.
data: блок в 1024 байта (ИНДЕКС ПО ЭТОМУ ПОЛЮ!!!!!)
seek: смещение блока от начала файла (т.е. pdf делим на куски по 1024 байта, а здесь номер куска)
id_pdf: собственно уникальный ид pdf.
Далее определяемся с размером строки поиска (например до 128 байт)
после этого в каждой базе создаем еще 1 000 000 вспомогательных записей(в отдельной таблице) содержащих последовательности:
Последние 128 байт n записи + Первые 128 байт n+1 записи, если n < (кол-ва записей в базе)
Собственно структура вспомогательных записей, такая же, но поле data(обязательный индекс) 256 символов.
4. поиск осуществляем в каждой базе, сначала по вспомогательной таблице (Важно!!!) и только потом по основной. 5. в зависимости от доступных ресурсов, поиск осуществляем одновременно на нескольких базах. Идея в собственно его распараллеливании и использовании индексов на небольших блоках. Например если у вашего хранилища 8 дисков, можно запустить одновременно 8 потоков поиска по 100 баз (кол-во баз вычисляется экспериментально, в зависимости от максимальной скорости считывания). 6. Тестирование в процессе разработки осуществлять можно на гораздо меньшем кол-ве данных, главное это правильно определиться с дальнейшим масштабированием. 7. преимущество: sql для поиска. Неограниченные возможности для масштабирования. Если решить проблему с шифрованием и резервным копированием можно получить фактически второй google, используя для хранения и поиска системные блоки сотрудников организации. (много слабых серверов вместо 1 большого). 8. недостатки: строка для поиска не более 128 байт. Размер хранилища при размере блока в 1024 байта и ограничении строки поиска до 128 байт возрастет на 25%.
- Посоветуйте решение для поиска по большому объёму данных, ACCA, 22:48 , 10-Дек-19 (18)
> 1. штампуем 50000 баз. (50 000 * 1 000 000 записей *
> 1024 байта = 50 Tb) [...] Не сработает ни разу. 1. PDF могут быть в CP1251, UTF-8, UTF-16, а могут использовать внутреннюю кодировку.
И это если среди них нет сканов.
2. В них могут быть опечатки, орфографические ошибки, а то и просто намешаны разные
алфавиты в одном слове.
3. Что ты собираешься делать с синонимами? В одно лицо такой проект не поднять, даже если купить Google Appliance. Только на ввод данных нужно будет написать кучу уникального софта, разбираясь с помойкой из кодировок и вариантов формата PDF.
- Посоветуйте решение для поиска по большому объёму данных, cool29, 23:51 , 10-Дек-19 (19) +1
>[оверквотинг удален]
> 1. PDF могут быть в CP1251, UTF-8, UTF-16, а могут использовать внутреннюю
> кодировку.
> И это если среди них нет сканов.
> 2. В них могут быть опечатки, орфографические ошибки, а то и просто
> намешаны разные
> алфавиты в одном слове.
> 3. Что ты собираешься делать с синонимами?
> В одно лицо такой проект не поднять, даже если купить Google Appliance.
> Только на ввод данных нужно будет написать кучу уникального софта, разбираясь
> с помойкой из кодировок и вариантов формата PDF.ну сказано же 95% содержимого документов текст. Кодировка разумеется 1251. Так как такие проблемы могут быть только в государственном учреждении, где пользуются winXP.
По видимому накопили документов, теперь не знают что с ними делать. Вообще не надо ничего перекодировать, все просто загнать в базы с индексом и распаралелить поиск по базам как я описал. Для разработки несколько баз с общим объемом документов до 1 gb.
Если технология себя оправдает, то можно будет пробовать загонять туда все документы. Опять же, я предлагал загонять в базу данные автоматическим модулем без использования ручного труда. Про синонимы не понял. Поиск по синонимам вполне возможен при наличии словаря, но здесь не является первостепенной задачей. Главное это вообще хоть какой-нибудь поиск. А дополнительную фичу можно воткнуть и потом.
- Посоветуйте решение для поиска по большому объёму данных, cool29, 00:00 , 11-Дек-19 (20)
вот кстати и как конвертер для извлечения текста из pdfhttps://habr.com/en/post/225647/ Можно и на других языках поискать, в google все есть. Вообще главная задача нам найти документ где есть строка поиска, и потом его номер выдать пользователю, вот и все. Т.е. мы по сути делаем такой огромный текстовый автокэш, поиск по которому и дает нам ссылку на нужные документы.
- Посоветуйте решение для поиска по большому объёму данных, cool29, 00:12 , 11-Дек-19 (21)
Ну и как совсем тупой вариант: аннотация.
Для каждого документа пишется аннотация(ну т.е. о чем идет речь в документе) на пару абзацев. Поиск осуществляем по аннотации, т.е. где то 1000 байт на 1 документ.
Ну и раз придется перебрать все документы, то заодно сделать каталогизацию(сложить документы по каким нибудь критериям: документы бухгалтерии, документы отдела кадров, судебные решения и.т.д).
Здесь уже просто поиск по базе данных и интерфейсы для операторов, которые будут заниматься вводом данных.
- Посоветуйте решение для поиска по большому объёму данных, ACCA, 13:39 , 11-Дек-19 (22)
> Ну и как совсем тупой вариант: аннотация.
> Для каждого документа пишется аннотация(ну т.е. о чем идет речь в документе)Хорошая идея. Если ты сможешь за 5 минут прочитать документ и написать аннотацию, то на 50М документов тебе понадобится всего 4363 человеко-лет. А ещё 50М документов гарантируют, что далеко не все будут в 1251, так что и левая шняга на жабе не поможет. С ETL придётся разбираться всерьёз и надолго. Там ещё одни грабли поджидают - исходных документов окажется не 50М, а ближе к 300М. Про дубли и разные версии тебе просто забыли сказать - тыжепрограммист.
- Посоветуйте решение для поиска по большому объёму данных, cool29, 22:06 , 11-Дек-19 (26)
>> Ну и как совсем тупой вариант: аннотация.
>> Для каждого документа пишется аннотация(ну т.е. о чем идет речь в документе)
> Хорошая идея. Если ты сможешь за 5 минут прочитать документ и написать
> аннотацию, то на 50М документов тебе понадобится всего 4363 человеко-лет.
> А ещё 50М документов гарантируют, что далеко не все будут в 1251,
> так что и левая шняга на жабе не поможет. С ETL
> придётся разбираться всерьёз и надолго.
> Там ещё одни грабли поджидают - исходных документов окажется не 50М, а
> ближе к 300М. Про дубли и разные версии тебе просто забыли
> сказать - тыжепрограммист.Ну тут конечно я чет не посмотрел на кол-во документов. Мдам....
Чем такой фигней страдать, я бы уволился. Хотя в обмен на безсмертие, можно 4363 лет поработать даже бесплатно.)))
- Посоветуйте решение для поиска по большому объёму данных, Миха, 18:27 , 11-Дек-19 (25)
структура разных версий pdf известна. Задача определить кодировку документа тревиальна. Как и язык символов тоже.
- Посоветуйте решение для поиска по большому объёму данных, ACCA, 06:47 , 17-Дек-19 (27)
> структура разных версий pdf известна. Задача определить кодировку документа тревиальна.
> Как и язык символов тоже.Структура известна - каждый вендор реализовал PDF по-своему, со своими глюками. Теперь ты должен определить, где именно он накосячил. "Язык символов" в некоторых документах - глифы. То есть каждая буква - это некоторая последовательность закорючек, уникальная для данного документа. Они это специально сделали, чтобы ты за**лся расшифровывать. Тебе ещё объяснять, или ты уже понял?
- Посоветуйте решение для поиска по большому объёму данных, Миха, 18:24 , 11-Дек-19 (24)
Нет какого-то волшебного средства для "полнотекстового поиска". Есть много шумихи вокруг этой темы, но как и любая прочая шумиха, шумиха эта не про решение проблемы, а про продвижение личностей тех, кто шумит.
Все "серебряные пули" (всякие там эластики с ходупами) сводятся к кэшированию наиболее востребоанных путей. Тоже самое делают просто любые современные традиционные реляционные СУБД. И делают, в общем, чаще всего банально быстрее (не медленней точно).
В общем, полнотекстовый поиск это всегда про скорость ввода/вывода. И всё. Каких-то особенно полезных программных уловок тут нет.
- Посоветуйте решение для поиска по большому объёму данных, ACCA, 06:52 , 17-Дек-19 (28)
Тебя обманули.Полнотекстовый поиск существует, и его можно гонять на хадупе. Но это сложная проблема, которую в одно рыло не делают. Бюджеты на освоение легко пробивают потолок в пару ярдов баксов. Попытки влезть в сотню лямов есть, но пока безуспешны. Тяжёлое это дело.
|
Версия для распечатки
Посоветуйте решение для поиска по большому объёму данных, 
