forum.opennet.ru - "Посоветуйте решение для поиска по большому объёму данных" (28)

"Посоветуйте решение для поиска по большому объёму данных"

Форум WEB технологии (Базы данных)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Посоветуйте решение для поиска по большому объёму данных"	+/–
Сообщение от datahub.1 (ok), 04-Дек-19, 20:06
Доброго дня Стоит такая амбициозная (для меня по крайней мере) задача Есть ~50M pdf документов, средний размер каждого ~1Mb, минимальный 10Kb, максимальный 50Mb. Суммарный объём выходит под 50Tb. 95% данных в документе это текст. Нужно обеспечить полнотекстовый поиск по всему объёму данных, тоесть есть фраза - надо показать документы где она встречается и (опционально) показать снипеты, тоесть текстовое окружение где в документе нашлась фраза. Добавление даных в базу происходит редко и оно некритично, тоесть его можно выполнять долго и с низким приоритетом. Удаление/изменение данных не случается вообще. Требования к системе в порядке приоритета. 1 Возможность запустить это всё на как можно более дешёвом и досутпном железе - это критично т.к. бюджет на инфраструктуту ограничен 2 Скорость поиска 3 Надёжность и отказоустойчивость 4 Лёгкость масштабирования Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше запутался. Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи каких технологий это можно было бы реализовать. Спасибо заранее всем откликнувшимся
Ответить \| Правка \| Cообщить модератору

Оглавление

gt оверквотинг удален Все сущности которые вы назвали в контексте задачи- пред, ыы (?), 20:22 , 04-Дек-19, (1)

gt оверквотинг удален Если и планировал то лишь от недостатка опыта Заплатить , datahub.1 (ok), 20:29 , 04-Дек-19, (2)

Попробуйте перевести базу документов всю, или репрезентативную выборку в текст, Licha Morada (ok), 23:31 , 04-Дек-19, (3)

Какой-нибудь cudagrep может помочь Чем не на халяву , Аноним (6), 02:53 , 06-Дек-19, (6)

В 50М искать легко и это можно решить мимоходом Поиск в 50Г решается уже не в ло, Licha Morada (ok), 05:21 , 08-Дек-19, (16)

Тут этим летом вроде обещают 128 GB s в обе стороны через 2 года в обычном p, Аноним (6), 14:29 , 10-Дек-19, (17)

Полнотекстовый поиск - это Sphinx, Elastic, Solr Копайте в этих направлениях Н, Аноним (4), 10:35 , 05-Дек-19, (4) +1

Полнотекстовый поиск это любая более-менее современная СУБД А то, что вы пер, Миха (??), 18:17 , 11-Дек-19, (23)

спасибо большое всем откликнувшимся, 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)
gt оверквотинг удален Ну вот вам как вариант идеи https www tsgrp com 2015 0, fantom (??), 12:20 , 06-Дек-19, (9)

gt оверквотинг удален 10 шт вот таких 8тб интелов, которочку к ним соотв и, fantom (??), 12:36 , 06-Дек-19, (10)

прямым поиском скриптами Даже если эти диски дадут реальные 3200mb s последова, Pahanivo (ok), 13:29 , 06-Дек-19, (11)

Посоветуйте решение для поиска по большому объёму данных, Pahanivo (ok), 13:30 , 06-Дек-19, (12)
Так я и не спорю, для такого поиска на дешевом железе аналогичным подходом жда, fantom (??), 14:15 , 06-Дек-19, (13)

тут индексы надо , Pahanivo (ok), 00:01 , 07-Дек-19, (14)

gt оверквотинг удален 1 штампуем 50000 баз 50 000 1 000 000 записей 102, cool29 (?), 02:22 , 07-Дек-19, (15)

Не сработает ни разу 1 PDF могут быть в CP1251, UTF-8, UTF-16, а могут исп, ACCA (ok), 22:48 , 10-Дек-19, (18)

gt оверквотинг удален ну сказано же 95 содержимого документов текст Кодировк, cool29 (?), 23:51 , 10-Дек-19, (19) +1

вот кстати и как конвертер для извлечения текста из pdfhttps habr com en post , cool29 (?), 00:00 , 11-Дек-19, (20)

Ну и как совсем тупой вариант аннотация Для каждого документа пишется аннотация, cool29 (?), 00:12 , 11-Дек-19, (21)

Хорошая идея Если ты сможешь за 5 минут прочитать документ и написать аннотацию, ACCA (ok), 13:39 , 11-Дек-19, (22)

Ну тут конечно я чет не посмотрел на кол-во документов Мдам Чем такой фигней, cool29 (?), 22:06 , 11-Дек-19, (26)

структура разных версий pdf известна Задача определить кодировку документа трев, Миха (??), 18:27 , 11-Дек-19, (25)

Структура известна - каждый вендор реализовал PDF по-своему, со своими глюками , ACCA (ok), 06:47 , 17-Дек-19, (27)

Нет какого-то волшебного средства для полнотекстового поиска Есть много шумих, Миха (??), 18:24 , 11-Дек-19, (24)

Тебя обманули Полнотекстовый поиск существует, и его можно гонять на хадупе Но , ACCA (ok), 06:52 , 17-Дек-19, (28)

Сообщения [Сортировка по ответам | RSS]

1. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от ыы (?), 04-Дек-19, 20:22

>[оверквотинг удален]
> 1 Возможность запустить это всё на как можно более дешёвом и досутпном
> железе - это критично т.к. бюджет на инфраструктуту ограничен
> 2 Скорость поиска
> 3 Надёжность и отказоустойчивость
> 4 Лёгкость масштабирования
> Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше
> запутался.
> Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи
> каких технологий это можно было бы реализовать.
> Спасибо заранее всем откликнувшимся
Все сущности которые вы назвали в контексте задачи- предполагают что вы планируете заниматься велосипедостроением.
Потому что если готовы заплатить за решение - ваш вопрос вообще  не имеет смысла.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от datahub.1 (ok), 04-Дек-19, 20:29

>[оверквотинг удален]
>> 4 Лёгкость масштабирования
>> Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше
>> запутался.
>> Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи
>> каких технологий это можно было бы реализовать.
>> Спасибо заранее всем откликнувшимся
> Все сущности которые вы назвали в контексте задачи- предполагают что вы планируете
> заниматься велосипедостроением.
> Потому что если готовы заплатить за решение - ваш вопрос вообще
> не имеет смысла.
Если и планировал то лишь от недостатка опыта.
Заплатить кому-то чтобы установил и настроил необходимый софт, запустил индексацию и сделал апи для вызова поиска у меня к сожалению возможности нету. Есть лишь спонсор на железо.
Я был бы Вам очень признателен за более детальный ответ.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от Licha Morada (ok), 04-Дек-19, 23:31

> Есть ~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.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Посоветуйте решение для поиска по большому объёму данных" +1 +/–

Сообщение от Аноним (4), 05-Дек-19, 10:35

Полнотекстовый поиск - это Sphinx, Elastic, Solr. Копайте в этих направлениях. На ютубе есть про них достаточно докладов в контексте большого кол-ва данных и высоких нагрузок.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от datahub.1 (ok), 06-Дек-19, 02:14

спасибо большое всем откликнувшимся

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от Аноним (6), 06-Дек-19, 02:53

Какой-нибудь cudagrep может помочь. Чем не на халяву?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от ACCA (ok), 06-Дек-19, 04:02

50Т это много для начинающего.
Купи https://ru.wikipedia.org/wiki/Google_Search_Appliance и настрой по инструкции либо три штуки G100, либо одну G500.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от Pahanivo (ok), 06-Дек-19, 11:14

Ммм а история задачи какая? Откуда столько файлов и зачем такой объем в pdf?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от fantom (??), 06-Дек-19, 12:20

>[оверквотинг удален]
> 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-х проблем:
Либо для быстрого поиска потребуется дополнительно куча места для индексов и дополнительных данных
.....
Либо поиск будет мало, что медленным, так еще и малопредсказуемым по времени ожидания результатов.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от fantom (??), 06-Дек-19, 12:36

>[оверквотинг удален]
> Hadoop - как масштабируемое распределенное хранилище,
>  Solr/Lucene to allow for full text and attribute searching
> как поиск,
> НО!!!
> при любом подходе у вас минимум 1 из 2-х проблем:
> Либо для быстрого поиска потребуется дополнительно куча места для индексов и дополнительных
> данных
> .....
> Либо поиск будет мало, что медленным, так еще и малопредсказуемым по времени
> ожидания результатов.
10 шт. вот таких 8тб интелов, + которочку к ним соотв. и вполне может получиться чуть-ли не shell скриптами, самое узкое место в таких поисках -> ввод/вывод с диска данных,
Вполне может оказаться, что решение из горы дешевых железяк может вылиться даже дороже.

https://www.amazon.com/dp/B0782Q4CV9?ascsubtag=s157562429393...

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от Pahanivo (ok), 06-Дек-19, 13:29

> 10 шт. вот таких 8тб интелов, + которочку к ним соотв. и
> вполне может получиться чуть-ли не shell скриптами, самое узкое место в
> таких поисках -> ввод/вывод с диска данных,
прямым поиском скриптами???
Даже если эти диски дадут реальные 3200mb/s последовательного чтения, даже если предположить что страйп
из десятка дисков даст кратное увеличение скорость до 32gb/s последовательнго чтения - то 50tb будут читаться прямым поиском минимум полчаса. Те в реальности один запрос в час.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от Pahanivo (ok), 06-Дек-19, 13:30

>

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от fantom (??), 06-Дек-19, 14:15

>> 10 шт. вот таких 8тб интелов, + которочку к ним соотв. и
>> вполне может получиться чуть-ли не shell скриптами, самое узкое место в
>> таких поисках -> ввод/вывод с диска данных,
> прямым поиском скриптами???
> Даже если эти диски дадут реальные 3200mb/s последовательного чтения, даже если предположить
> что страйп
> из десятка дисков даст кратное увеличение скорость до 32gb/s последовательнго чтения -
> то 50tb будут читаться прямым поиском минимум полчаса. Те в реальности
> один запрос в час.
Так я и не спорю, для такого поиска на "дешевом железе" аналогичным подходом ждать результата неделю придется :)

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от Pahanivo (ok), 07-Дек-19, 00:01

тут индексы надо ...

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от cool29 (?), 07-Дек-19, 02:22

>[оверквотинг удален]
> 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%.




Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от Licha Morada (ok), 08-Дек-19, 05:21

> Какой-нибудь cudagrep может помочь. Чем не на халяву?
В 50М искать легко и это можно решить мимоходом.
Поиск в 50Г решается уже не в лоб, но если железо есть, то можно условно считать что халява.
С 50Т это уже не проходит. Наверное, можно решить задачу не потратив ни цента на лицензии, но потребуется время, скиллы и опять же железо.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

17. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от Аноним (6), 10-Дек-19, 14:29

>> Какой-нибудь cudagrep может помочь. Чем не на халяву?
> железо.
Тут (этим летом) вроде обещают 128 GB/s (в обе стороны) через 2 года в обычном pcie, так что скоро в каждой семье будет такое железо. Можно собрать 40 штук обычных ссд (3 GB/s) и вот уже 50 терабайт не проблема.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от ACCA (ok), 10-Дек-19, 22:48

> 1. штампуем 50000 баз. (50 000 * 1 000 000 записей *
> 1024 байта = 50 Tb)
[...]
Не сработает ни разу.
1. PDF могут быть в CP1251, UTF-8, UTF-16, а могут использовать внутреннюю кодировку.
   И это если среди них нет сканов.
2. В них могут быть опечатки, орфографические ошибки, а то и просто намешаны разные
   алфавиты в одном слове.
3. Что ты собираешься делать с синонимами?
В одно лицо такой проект не поднять, даже если купить Google Appliance. Только на ввод данных нужно будет написать кучу уникального софта, разбираясь с помойкой из кодировок и вариантов формата PDF.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

19. "Посоветуйте решение для поиска по большому объёму данных" +1 +/–

Сообщение от cool29 (?), 10-Дек-19, 23:51

>[оверквотинг удален]
> 1. PDF могут быть в CP1251, UTF-8, UTF-16, а могут использовать внутреннюю
> кодировку.
>    И это если среди них нет сканов.
> 2. В них могут быть опечатки, орфографические ошибки, а то и просто
> намешаны разные
>    алфавиты в одном слове.
> 3. Что ты собираешься делать с синонимами?
> В одно лицо такой проект не поднять, даже если купить Google Appliance.
> Только на ввод данных нужно будет написать кучу уникального софта, разбираясь
> с помойкой из кодировок и вариантов формата PDF.
ну сказано же 95% содержимого документов текст. Кодировка разумеется 1251. Так как такие проблемы могут быть только в государственном учреждении, где пользуются winXP.
По видимому накопили документов, теперь не знают что с ними делать.
Вообще не надо ничего перекодировать, все просто загнать в базы с индексом и распаралелить поиск по базам как я описал. Для разработки несколько баз с общим объемом документов до 1 gb.
Если технология себя оправдает, то можно будет пробовать загонять туда все документы.
Опять же, я предлагал загонять в базу данные автоматическим модулем без использования ручного труда.
Про синонимы не понял. Поиск по синонимам вполне возможен при наличии словаря, но здесь не является первостепенной задачей. Главное это вообще хоть какой-нибудь поиск. А дополнительную фичу можно воткнуть и потом.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от cool29 (?), 11-Дек-19, 00:00

вот кстати и как конвертер для извлечения текста из pdf
https://habr.com/en/post/225647/
Можно и на других языках поискать, в google все есть.
Вообще главная задача нам найти документ где есть строка поиска, и потом его номер выдать пользователю, вот и все. Т.е. мы по сути делаем такой огромный текстовый автокэш, поиск по которому и дает нам ссылку на нужные документы.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

21. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от cool29 (?), 11-Дек-19, 00:12

Ну и как совсем тупой вариант: аннотация.
Для каждого документа пишется аннотация(ну т.е. о чем идет речь в документе) на пару абзацев. Поиск осуществляем по аннотации, т.е. где то 1000 байт на 1 документ.
Ну и раз придется перебрать все документы, то заодно сделать каталогизацию(сложить документы по каким нибудь критериям: документы бухгалтерии, документы отдела кадров, судебные решения и.т.д).
Здесь уже просто поиск по базе данных и интерфейсы для операторов, которые будут заниматься вводом данных.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

22. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от ACCA (ok), 11-Дек-19, 13:39

> Ну и как совсем тупой вариант: аннотация.
> Для каждого документа пишется аннотация(ну т.е. о чем идет речь в документе)
Хорошая идея. Если ты сможешь за 5 минут прочитать документ и написать аннотацию, то на 50М документов тебе понадобится всего 4363 человеко-лет.
А ещё 50М документов гарантируют, что далеко не все будут в 1251, так что и левая шняга на жабе не поможет. С ETL придётся разбираться всерьёз и надолго.
Там ещё одни грабли поджидают - исходных документов окажется не 50М, а ближе к 300М. Про дубли и разные версии тебе просто забыли сказать - тыжепрограммист.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

23. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от Миха (??), 11-Дек-19, 18:17

> Полнотекстовый поиск - это Sphinx, Elastic, Solr. Копайте в этих направлениях. На
> ютубе есть про них достаточно докладов в контексте большого кол-ва данных
> и высоких нагрузок.
Полнотекстовый поиск это... любая более-менее современная СУБД. А то, что вы перечислили, это о том, как продать обёртку от конфет, которые кто-то уже съел.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

24. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от Миха (??), 11-Дек-19, 18:24

Нет какого-то волшебного средства для "полнотекстового поиска". Есть много шумихи вокруг этой темы, но как и любая прочая шумиха, шумиха эта не про решение проблемы, а про продвижение личностей тех, кто шумит.
Все "серебряные пули" (всякие там эластики с ходупами) сводятся к кэшированию наиболее востребоанных путей. Тоже самое делают просто любые современные традиционные реляционные СУБД. И делают, в общем, чаще всего банально быстрее (не медленней точно).
В общем, полнотекстовый поиск это всегда про скорость ввода/вывода. И всё. Каких-то особенно полезных программных уловок тут нет.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от Миха (??), 11-Дек-19, 18:27

структура разных версий pdf известна. Задача определить кодировку документа тревиальна. Как и язык символов тоже.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

26. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от cool29 (?), 11-Дек-19, 22:06

>> Ну и как совсем тупой вариант: аннотация.
>> Для каждого документа пишется аннотация(ну т.е. о чем идет речь в документе)
> Хорошая идея. Если ты сможешь за 5 минут прочитать документ и написать
> аннотацию, то на 50М документов тебе понадобится всего 4363 человеко-лет.
> А ещё 50М документов гарантируют, что далеко не все будут в 1251,
> так что и левая шняга на жабе не поможет. С ETL
> придётся разбираться всерьёз и надолго.
> Там ещё одни грабли поджидают - исходных документов окажется не 50М, а
> ближе к 300М. Про дубли и разные версии тебе просто забыли
> сказать - тыжепрограммист.
Ну тут конечно я чет не посмотрел на кол-во документов. Мдам....
Чем такой фигней страдать, я бы уволился. Хотя в обмен на безсмертие, можно 4363 лет поработать даже бесплатно.)))

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

27. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от ACCA (ok), 17-Дек-19, 06:47

> структура разных версий pdf известна. Задача определить кодировку документа тревиальна.
> Как и язык символов тоже.
Структура известна - каждый вендор реализовал PDF по-своему, со своими глюками. Теперь ты должен определить, где именно он накосячил.
"Язык символов" в некоторых документах - глифы. То есть каждая буква - это некоторая последовательность закорючек, уникальная для данного документа. Они это специально сделали, чтобы ты за**лся расшифровывать. Тебе ещё объяснять, или ты уже понял?

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

28. "Посоветуйте решение для поиска по большому объёму данных" +/–

Сообщение от ACCA (ok), 17-Дек-19, 06:52

Тебя обманули.
Полнотекстовый поиск существует, и его можно гонять на хадупе. Но это сложная проблема, которую в одно рыло не делают. Бюджеты на освоение легко пробивают потолок в пару ярдов баксов. Попытки влезть в сотню лямов есть, но пока безуспешны.
Тяжёлое это дело.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	1. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от ыы (?), 04-Дек-19, 20:22
	>[оверквотинг удален] > 1 Возможность запустить это всё на как можно более дешёвом и досутпном > железе - это критично т.к. бюджет на инфраструктуту ограничен > 2 Скорость поиска > 3 Надёжность и отказоустойчивость > 4 Лёгкость масштабирования > Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше > запутался. > Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи > каких технологий это можно было бы реализовать. > Спасибо заранее всем откликнувшимся Все сущности которые вы назвали в контексте задачи- предполагают что вы планируете заниматься велосипедостроением. Потому что если готовы заплатить за решение - ваш вопрос вообще не имеет смысла.
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от datahub.1 (ok), 04-Дек-19, 20:29
	>[оверквотинг удален] >> 4 Лёгкость масштабирования >> Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше >> запутался. >> Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи >> каких технологий это можно было бы реализовать. >> Спасибо заранее всем откликнувшимся > Все сущности которые вы назвали в контексте задачи- предполагают что вы планируете > заниматься велосипедостроением. > Потому что если готовы заплатить за решение - ваш вопрос вообще > не имеет смысла. Если и планировал то лишь от недостатка опыта. Заплатить кому-то чтобы установил и настроил необходимый софт, запустил индексацию и сделал апи для вызова поиска у меня к сожалению возможности нету. Есть лишь спонсор на железо. Я был бы Вам очень признателен за более детальный ответ.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от Licha Morada (ok), 04-Дек-19, 23:31
	> Есть ~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.
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	4. "Посоветуйте решение для поиска по большому объёму данных"	+1 +/–
	Сообщение от Аноним (4), 05-Дек-19, 10:35
	Полнотекстовый поиск - это Sphinx, Elastic, Solr. Копайте в этих направлениях. На ютубе есть про них достаточно докладов в контексте большого кол-ва данных и высоких нагрузок.
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	5. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от datahub.1 (ok), 06-Дек-19, 02:14
	спасибо большое всем откликнувшимся
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	6. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от Аноним (6), 06-Дек-19, 02:53
	Какой-нибудь cudagrep может помочь. Чем не на халяву?
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	7. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от ACCA (ok), 06-Дек-19, 04:02
	50Т это много для начинающего. Купи https://ru.wikipedia.org/wiki/Google_Search_Appliance и настрой по инструкции либо три штуки G100, либо одну G500.
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	8. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от Pahanivo (ok), 06-Дек-19, 11:14
	Ммм а история задачи какая? Откуда столько файлов и зачем такой объем в pdf?
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	9. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от fantom (??), 06-Дек-19, 12:20
	>[оверквотинг удален] > 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-х проблем: Либо для быстрого поиска потребуется дополнительно куча места для индексов и дополнительных данных ..... Либо поиск будет мало, что медленным, так еще и малопредсказуемым по времени ожидания результатов.
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	10. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от fantom (??), 06-Дек-19, 12:36
	>[оверквотинг удален] > Hadoop - как масштабируемое распределенное хранилище, > Solr/Lucene to allow for full text and attribute searching > как поиск, > НО!!! > при любом подходе у вас минимум 1 из 2-х проблем: > Либо для быстрого поиска потребуется дополнительно куча места для индексов и дополнительных > данных > ..... > Либо поиск будет мало, что медленным, так еще и малопредсказуемым по времени > ожидания результатов. 10 шт. вот таких 8тб интелов, + которочку к ним соотв. и вполне может получиться чуть-ли не shell скриптами, самое узкое место в таких поисках -> ввод/вывод с диска данных, Вполне может оказаться, что решение из горы дешевых железяк может вылиться даже дороже. https://www.amazon.com/dp/B0782Q4CV9?ascsubtag=s157562429393...
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	11. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от Pahanivo (ok), 06-Дек-19, 13:29
	> 10 шт. вот таких 8тб интелов, + которочку к ним соотв. и > вполне может получиться чуть-ли не shell скриптами, самое узкое место в > таких поисках -> ввод/вывод с диска данных, прямым поиском скриптами??? Даже если эти диски дадут реальные 3200mb/s последовательного чтения, даже если предположить что страйп из десятка дисков даст кратное увеличение скорость до 32gb/s последовательнго чтения - то 50tb будут читаться прямым поиском минимум полчаса. Те в реальности один запрос в час.
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	12. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от Pahanivo (ok), 06-Дек-19, 13:30
	>
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	13. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от fantom (??), 06-Дек-19, 14:15
	>> 10 шт. вот таких 8тб интелов, + которочку к ним соотв. и >> вполне может получиться чуть-ли не shell скриптами, самое узкое место в >> таких поисках -> ввод/вывод с диска данных, > прямым поиском скриптами??? > Даже если эти диски дадут реальные 3200mb/s последовательного чтения, даже если предположить > что страйп > из десятка дисков даст кратное увеличение скорость до 32gb/s последовательнго чтения - > то 50tb будут читаться прямым поиском минимум полчаса. Те в реальности > один запрос в час. Так я и не спорю, для такого поиска на "дешевом железе" аналогичным подходом ждать результата неделю придется :)
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	14. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от Pahanivo (ok), 07-Дек-19, 00:01
	тут индексы надо ...
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	15. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от cool29 (?), 07-Дек-19, 02:22
	>[оверквотинг удален] > 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%.
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	16. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от Licha Morada (ok), 08-Дек-19, 05:21
	> Какой-нибудь cudagrep может помочь. Чем не на халяву? В 50М искать легко и это можно решить мимоходом. Поиск в 50Г решается уже не в лоб, но если железо есть, то можно условно считать что халява. С 50Т это уже не проходит. Наверное, можно решить задачу не потратив ни цента на лицензии, но потребуется время, скиллы и опять же железо.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	17. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от Аноним (6), 10-Дек-19, 14:29
	>> Какой-нибудь cudagrep может помочь. Чем не на халяву? > железо. Тут (этим летом) вроде обещают 128 GB/s (в обе стороны) через 2 года в обычном pcie, так что скоро в каждой семье будет такое железо. Можно собрать 40 штук обычных ссд (3 GB/s) и вот уже 50 терабайт не проблема.
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	18. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от ACCA (ok), 10-Дек-19, 22:48
	> 1. штампуем 50000 баз. (50 000 * 1 000 000 записей * > 1024 байта = 50 Tb) [...] Не сработает ни разу. 1. PDF могут быть в CP1251, UTF-8, UTF-16, а могут использовать внутреннюю кодировку. И это если среди них нет сканов. 2. В них могут быть опечатки, орфографические ошибки, а то и просто намешаны разные алфавиты в одном слове. 3. Что ты собираешься делать с синонимами? В одно лицо такой проект не поднять, даже если купить Google Appliance. Только на ввод данных нужно будет написать кучу уникального софта, разбираясь с помойкой из кодировок и вариантов формата PDF.
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	19. "Посоветуйте решение для поиска по большому объёму данных"	+1 +/–
	Сообщение от cool29 (?), 10-Дек-19, 23:51
	>[оверквотинг удален] > 1. PDF могут быть в CP1251, UTF-8, UTF-16, а могут использовать внутреннюю > кодировку. > И это если среди них нет сканов. > 2. В них могут быть опечатки, орфографические ошибки, а то и просто > намешаны разные > алфавиты в одном слове. > 3. Что ты собираешься делать с синонимами? > В одно лицо такой проект не поднять, даже если купить Google Appliance. > Только на ввод данных нужно будет написать кучу уникального софта, разбираясь > с помойкой из кодировок и вариантов формата PDF. ну сказано же 95% содержимого документов текст. Кодировка разумеется 1251. Так как такие проблемы могут быть только в государственном учреждении, где пользуются winXP. По видимому накопили документов, теперь не знают что с ними делать. Вообще не надо ничего перекодировать, все просто загнать в базы с индексом и распаралелить поиск по базам как я описал. Для разработки несколько баз с общим объемом документов до 1 gb. Если технология себя оправдает, то можно будет пробовать загонять туда все документы. Опять же, я предлагал загонять в базу данные автоматическим модулем без использования ручного труда. Про синонимы не понял. Поиск по синонимам вполне возможен при наличии словаря, но здесь не является первостепенной задачей. Главное это вообще хоть какой-нибудь поиск. А дополнительную фичу можно воткнуть и потом.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	20. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от cool29 (?), 11-Дек-19, 00:00
	вот кстати и как конвертер для извлечения текста из pdf https://habr.com/en/post/225647/ Можно и на других языках поискать, в google все есть. Вообще главная задача нам найти документ где есть строка поиска, и потом его номер выдать пользователю, вот и все. Т.е. мы по сути делаем такой огромный текстовый автокэш, поиск по которому и дает нам ссылку на нужные документы.
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	21. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от cool29 (?), 11-Дек-19, 00:12
	Ну и как совсем тупой вариант: аннотация. Для каждого документа пишется аннотация(ну т.е. о чем идет речь в документе) на пару абзацев. Поиск осуществляем по аннотации, т.е. где то 1000 байт на 1 документ. Ну и раз придется перебрать все документы, то заодно сделать каталогизацию(сложить документы по каким нибудь критериям: документы бухгалтерии, документы отдела кадров, судебные решения и.т.д). Здесь уже просто поиск по базе данных и интерфейсы для операторов, которые будут заниматься вводом данных.
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	22. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от ACCA (ok), 11-Дек-19, 13:39
	> Ну и как совсем тупой вариант: аннотация. > Для каждого документа пишется аннотация(ну т.е. о чем идет речь в документе) Хорошая идея. Если ты сможешь за 5 минут прочитать документ и написать аннотацию, то на 50М документов тебе понадобится всего 4363 человеко-лет. А ещё 50М документов гарантируют, что далеко не все будут в 1251, так что и левая шняга на жабе не поможет. С ETL придётся разбираться всерьёз и надолго. Там ещё одни грабли поджидают - исходных документов окажется не 50М, а ближе к 300М. Про дубли и разные версии тебе просто забыли сказать - тыжепрограммист.
	Ответить \| Правка \| ^ к родителю #21 \| Наверх \| Cообщить модератору


	23. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от Миха (??), 11-Дек-19, 18:17
	> Полнотекстовый поиск - это Sphinx, Elastic, Solr. Копайте в этих направлениях. На > ютубе есть про них достаточно докладов в контексте большого кол-ва данных > и высоких нагрузок. Полнотекстовый поиск это... любая более-менее современная СУБД. А то, что вы перечислили, это о том, как продать обёртку от конфет, которые кто-то уже съел.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	24. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от Миха (??), 11-Дек-19, 18:24
	Нет какого-то волшебного средства для "полнотекстового поиска". Есть много шумихи вокруг этой темы, но как и любая прочая шумиха, шумиха эта не про решение проблемы, а про продвижение личностей тех, кто шумит. Все "серебряные пули" (всякие там эластики с ходупами) сводятся к кэшированию наиболее востребоанных путей. Тоже самое делают просто любые современные традиционные реляционные СУБД. И делают, в общем, чаще всего банально быстрее (не медленней точно). В общем, полнотекстовый поиск это всегда про скорость ввода/вывода. И всё. Каких-то особенно полезных программных уловок тут нет.
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	25. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от Миха (??), 11-Дек-19, 18:27
	структура разных версий pdf известна. Задача определить кодировку документа тревиальна. Как и язык символов тоже.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	26. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от cool29 (?), 11-Дек-19, 22:06
	>> Ну и как совсем тупой вариант: аннотация. >> Для каждого документа пишется аннотация(ну т.е. о чем идет речь в документе) > Хорошая идея. Если ты сможешь за 5 минут прочитать документ и написать > аннотацию, то на 50М документов тебе понадобится всего 4363 человеко-лет. > А ещё 50М документов гарантируют, что далеко не все будут в 1251, > так что и левая шняга на жабе не поможет. С ETL > придётся разбираться всерьёз и надолго. > Там ещё одни грабли поджидают - исходных документов окажется не 50М, а > ближе к 300М. Про дубли и разные версии тебе просто забыли > сказать - тыжепрограммист. Ну тут конечно я чет не посмотрел на кол-во документов. Мдам.... Чем такой фигней страдать, я бы уволился. Хотя в обмен на безсмертие, можно 4363 лет поработать даже бесплатно.)))
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	27. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от ACCA (ok), 17-Дек-19, 06:47
	> структура разных версий pdf известна. Задача определить кодировку документа тревиальна. > Как и язык символов тоже. Структура известна - каждый вендор реализовал PDF по-своему, со своими глюками. Теперь ты должен определить, где именно он накосячил. "Язык символов" в некоторых документах - глифы. То есть каждая буква - это некоторая последовательность закорючек, уникальная для данного документа. Они это специально сделали, чтобы ты за**лся расшифровывать. Тебе ещё объяснять, или ты уже понял?
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	28. "Посоветуйте решение для поиска по большому объёму данных"	+/–
	Сообщение от ACCA (ok), 17-Дек-19, 06:52
	Тебя обманули. Полнотекстовый поиск существует, и его можно гонять на хадупе. Но это сложная проблема, которую в одно рыло не делают. Бюджеты на освоение легко пробивают потолок в пару ярдов баксов. Попытки влезть в сотню лямов есть, но пока безуспешны. Тяжёлое это дело.
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору

Архив \| Удалить	Рекомендовать для помещения в FAQ \| Индекс форумов \| Темы \| Пред. тема \| След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 \| 2 \| 3 \| 4 \| 5 ] [Рекомендовать для помещения в FAQ]