- gt оверквотинг удален Все сущности которые вы назвали в контексте задачи- пред, ыы (?), 20:22 , 04-Дек-19 (1)
>[оверквотинг удален] > 1 Возможность запустить это всё на как можно более дешёвом и досутпном > железе - это критично т.к. бюджет на инфраструктуту ограничен > 2 Скорость поиска > 3 Надёжность и отказоустойчивость > 4 Лёгкость масштабирования > Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше > запутался. > Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи > каких технологий это можно было бы реализовать. > Спасибо заранее всем откликнувшимся Все сущности которые вы назвали в контексте задачи- предполагают что вы планируете заниматься велосипедостроением. Потому что если готовы заплатить за решение - ваш вопрос вообще не имеет смысла.
- gt оверквотинг удален Если и планировал то лишь от недостатка опыта Заплатить , datahub.1 (ok), 20:29 , 04-Дек-19 (2)
>[оверквотинг удален] >> 4 Лёгкость масштабирования >> Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше >> запутался. >> Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи >> каких технологий это можно было бы реализовать. >> Спасибо заранее всем откликнувшимся > Все сущности которые вы назвали в контексте задачи- предполагают что вы планируете > заниматься велосипедостроением. > Потому что если готовы заплатить за решение - ваш вопрос вообще > не имеет смысла.Если и планировал то лишь от недостатка опыта. Заплатить кому-то чтобы установил и настроил необходимый софт, запустил индексацию и сделал апи для вызова поиска у меня к сожалению возможности нету. Есть лишь спонсор на железо. Я был бы Вам очень признателен за более детальный ответ.
- Попробуйте перевести базу документов всю, или репрезентативную выборку в текст, Licha Morada (ok), 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.
- Полнотекстовый поиск - это Sphinx, Elastic, Solr Копайте в этих направлениях Н, Аноним (4), 10:35 , 05-Дек-19 (4) +1
Полнотекстовый поиск - это Sphinx, Elastic, Solr. Копайте в этих направлениях. На ютубе есть про них достаточно докладов в контексте большого кол-ва данных и высоких нагрузок.
- Полнотекстовый поиск это любая более-менее современная СУБД А то, что вы пер, Миха (??), 18:17 , 11-Дек-19 (23)
> Полнотекстовый поиск - это Sphinx, Elastic, Solr. Копайте в этих направлениях. На > ютубе есть про них достаточно докладов в контексте большого кол-ва данных > и высоких нагрузок.Полнотекстовый поиск это... любая более-менее современная СУБД. А то, что вы перечислили, это о том, как продать обёртку от конфет, которые кто-то уже съел.
- спасибо большое всем откликнувшимся, datahub.1 (ok), 02:14 , 06-Дек-19 (5)
спасибо большое всем откликнувшимся
- 50Т это много для начинающего Купи https ru wikipedia org wiki Google_Search_A, ACCA (ok), 04:02 , 06-Дек-19 (7)
- Ммм а история задачи какая Откуда столько файлов и зачем такой объем в pdf , Pahanivo (ok), 11:14 , 06-Дек-19 (8)
Ммм а история задачи какая? Откуда столько файлов и зачем такой объем в pdf?
- gt оверквотинг удален Ну вот вам как вариант идеи https www tsgrp com 2015 0, 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-х проблем: Либо для быстрого поиска потребуется дополнительно куча места для индексов и дополнительных данных ..... Либо поиск будет мало, что медленным, так еще и малопредсказуемым по времени ожидания результатов.
- gt оверквотинг удален 10 шт вот таких 8тб интелов, которочку к ним соотв и, 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...
- прямым поиском скриптами Даже если эти диски дадут реальные 3200mb s последова, Pahanivo (ok), 13:29 , 06-Дек-19 (11)
> 10 шт. вот таких 8тб интелов, + которочку к ним соотв. и > вполне может получиться чуть-ли не shell скриптами, самое узкое место в > таких поисках -> ввод/вывод с диска данных, прямым поиском скриптами??? Даже если эти диски дадут реальные 3200mb/s последовательного чтения, даже если предположить что страйп из десятка дисков даст кратное увеличение скорость до 32gb/s последовательнго чтения - то 50tb будут читаться прямым поиском минимум полчаса. Те в реальности один запрос в час.
- Посоветуйте решение для поиска по большому объёму данных, Pahanivo (ok), 13:30 , 06-Дек-19 (12)
- Так я и не спорю, для такого поиска на дешевом железе аналогичным подходом жда, fantom (??), 14:15 , 06-Дек-19 (13)
>> 10 шт. вот таких 8тб интелов, + которочку к ним соотв. и >> вполне может получиться чуть-ли не shell скриптами, самое узкое место в >> таких поисках -> ввод/вывод с диска данных, > прямым поиском скриптами??? > Даже если эти диски дадут реальные 3200mb/s последовательного чтения, даже если предположить > что страйп > из десятка дисков даст кратное увеличение скорость до 32gb/s последовательнго чтения - > то 50tb будут читаться прямым поиском минимум полчаса. Те в реальности > один запрос в час.Так я и не спорю, для такого поиска на "дешевом железе" аналогичным подходом ждать результата неделю придется :)
- gt оверквотинг удален 1 штампуем 50000 баз 50 000 1 000 000 записей 102, 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%.
- Не сработает ни разу 1 PDF могут быть в CP1251, UTF-8, UTF-16, а могут исп, ACCA (ok), 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.
- gt оверквотинг удален ну сказано же 95 содержимого документов текст Кодировк, cool29 (?), 23:51 , 10-Дек-19 (19) +1
>[оверквотинг удален] > 1. PDF могут быть в CP1251, UTF-8, UTF-16, а могут использовать внутреннюю > кодировку. > И это если среди них нет сканов. > 2. В них могут быть опечатки, орфографические ошибки, а то и просто > намешаны разные > алфавиты в одном слове. > 3. Что ты собираешься делать с синонимами? > В одно лицо такой проект не поднять, даже если купить Google Appliance. > Только на ввод данных нужно будет написать кучу уникального софта, разбираясь > с помойкой из кодировок и вариантов формата PDF.ну сказано же 95% содержимого документов текст. Кодировка разумеется 1251. Так как такие проблемы могут быть только в государственном учреждении, где пользуются winXP. По видимому накопили документов, теперь не знают что с ними делать. Вообще не надо ничего перекодировать, все просто загнать в базы с индексом и распаралелить поиск по базам как я описал. Для разработки несколько баз с общим объемом документов до 1 gb. Если технология себя оправдает, то можно будет пробовать загонять туда все документы. Опять же, я предлагал загонять в базу данные автоматическим модулем без использования ручного труда. Про синонимы не понял. Поиск по синонимам вполне возможен при наличии словаря, но здесь не является первостепенной задачей. Главное это вообще хоть какой-нибудь поиск. А дополнительную фичу можно воткнуть и потом.
- вот кстати и как конвертер для извлечения текста из pdfhttps habr com en post , cool29 (?), 00:00 , 11-Дек-19 (20)
вот кстати и как конвертер для извлечения текста из pdfhttps://habr.com/en/post/225647/ Можно и на других языках поискать, в google все есть. Вообще главная задача нам найти документ где есть строка поиска, и потом его номер выдать пользователю, вот и все. Т.е. мы по сути делаем такой огромный текстовый автокэш, поиск по которому и дает нам ссылку на нужные документы.
- Ну и как совсем тупой вариант аннотация Для каждого документа пишется аннотация, cool29 (?), 00:12 , 11-Дек-19 (21)
Ну и как совсем тупой вариант: аннотация. Для каждого документа пишется аннотация(ну т.е. о чем идет речь в документе) на пару абзацев. Поиск осуществляем по аннотации, т.е. где то 1000 байт на 1 документ. Ну и раз придется перебрать все документы, то заодно сделать каталогизацию(сложить документы по каким нибудь критериям: документы бухгалтерии, документы отдела кадров, судебные решения и.т.д). Здесь уже просто поиск по базе данных и интерфейсы для операторов, которые будут заниматься вводом данных.
- Хорошая идея Если ты сможешь за 5 минут прочитать документ и написать аннотацию, ACCA (ok), 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 лет поработать даже бесплатно.)))
- структура разных версий pdf известна Задача определить кодировку документа трев, Миха (??), 18:27 , 11-Дек-19 (25)
структура разных версий pdf известна. Задача определить кодировку документа тревиальна. Как и язык символов тоже.
- Структура известна - каждый вендор реализовал PDF по-своему, со своими глюками , ACCA (ok), 06:47 , 17-Дек-19 (27)
> структура разных версий pdf известна. Задача определить кодировку документа тревиальна. > Как и язык символов тоже.Структура известна - каждый вендор реализовал PDF по-своему, со своими глюками. Теперь ты должен определить, где именно он накосячил. "Язык символов" в некоторых документах - глифы. То есть каждая буква - это некоторая последовательность закорючек, уникальная для данного документа. Они это специально сделали, чтобы ты за**лся расшифровывать. Тебе ещё объяснять, или ты уже понял?
- Нет какого-то волшебного средства для полнотекстового поиска Есть много шумих, Миха (??), 18:24 , 11-Дек-19 (24)
Нет какого-то волшебного средства для "полнотекстового поиска". Есть много шумихи вокруг этой темы, но как и любая прочая шумиха, шумиха эта не про решение проблемы, а про продвижение личностей тех, кто шумит. Все "серебряные пули" (всякие там эластики с ходупами) сводятся к кэшированию наиболее востребоанных путей. Тоже самое делают просто любые современные традиционные реляционные СУБД. И делают, в общем, чаще всего банально быстрее (не медленней точно). В общем, полнотекстовый поиск это всегда про скорость ввода/вывода. И всё. Каких-то особенно полезных программных уловок тут нет.
|