- gt оверквотинг удален Все сущности которые вы назвали в контексте задачи- пред, ыы (?), 20:22 , 04-Дек-19 (1)
>[оверквотинг удален] > 1 Возможность запустить это всё на как можно более дешёвом и досутпном > железе - это критично т.к. бюджет на инфраструктуту ограничен > 2 Скорость поиска > 3 Надёжность и отказоустойчивость > 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. Копайте в этих направлениях. На ютубе есть про них достаточно докладов в контексте большого кол-ва данных и высоких нагрузок.
- спасибо большое всем откликнувшимся, 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 оверквотинг удален 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%.
- Нет какого-то волшебного средства для полнотекстового поиска Есть много шумих, Миха (??), 18:24 , 11-Дек-19 (24)
Нет какого-то волшебного средства для "полнотекстового поиска". Есть много шумихи вокруг этой темы, но как и любая прочая шумиха, шумиха эта не про решение проблемы, а про продвижение личностей тех, кто шумит. Все "серебряные пули" (всякие там эластики с ходупами) сводятся к кэшированию наиболее востребоанных путей. Тоже самое делают просто любые современные традиционные реляционные СУБД. И делают, в общем, чаще всего банально быстрее (не медленней точно). В общем, полнотекстовый поиск это всегда про скорость ввода/вывода. И всё. Каких-то особенно полезных программных уловок тут нет.
|