LINUX.ORG.RU

Реактивный поиск

 , fgrep,


4

6

Есть данные - миллиард строк в utf-8, для начала. Потенциально - 5-10 миллиардов. Простые строки.
Есть задача - быстро выбирать по этим данным. Желательно с любыми условиями, вплоть до регулярок.

grep/fgrep не подошли из-за скорости.
Начал пробовать elasticsearch, который на лоре как раз используют. Сначала радовал шустростью, но на импорте где-то 150кк записи начал адово тормозить. Но на тех данных, что он смог импортировать - скорость радует.

Может я куда-то не туда копаю и есть более очевидное решение этой задачи?

Вопрос 2 (очень важный): если я в elasticsearch залью все подряд данные с автогенерируемым _id, как я могу потом почистить базу от неуникальных значений?

P.S. Бонус - если рекомендуемое вами решение позволит контролировать уникальность строк (мне это крайне необходимо), то будет вобще супер. Сейчас приходится кормить elasticsearch данные в виде _id = string, видимо поэтому он так сильно тормозит.

★★☆☆

Последнее исправление: xtraeft (всего исправлений: 4)

Тормозит же при добавлении. Разве нельзя зафигачить их в базу, а es понемногу бы их индексировал?

anonymous
()
Ответ на: комментарий от anonymous

Разве нельзя зафигачить их в базу, а es понемногу бы их индексировал?

Честно говоря, мне не хочется плодить лишние сущности. Хочется взять свои данные и залить их в эластик, а потом по ним искать. Это сильно неправильно?

xtraeft ★★☆☆
() автор топика
Ответ на: комментарий от umren

Делаешь подсказку для поисковика или что то аналогичное?
подсказку для поисковика

Не понял. Нет, делаю поиск по своим данным для внутренних задач. grep перестал устраивать.

xtraeft ★★☆☆
() автор топика
Ответ на: комментарий от xtraeft

По такому количеству строк, мало что может нормально работать мне кажется, особенно если часто искать, надо к проблеме с другого угла подходить как минимум разбить все строки на группы/корни/начало строки, это сильно ускорит процесс, как часто данные обновляются?

umren ★★★★★
()
Ответ на: комментарий от umren

По такому количеству строк, мало что может нормально работать мне кажется

Спасибо за мнение, к сожалению оно тут мимо абсолютно

xtraeft ★★☆☆
() автор топика
Ответ на: комментарий от anonymous

Какой? 400кк строк - около 25Гб.
В эластик лью по 300к строк - эти чанки весят ну, до 100 мегабайт каждый.

Утром потестил - ура, 300кк чанк льется за 5-10 сек ( _id = string). Обрадовался, воткнул цикл и пошел пить водку. Вернулся - с ~700 куска (может и раньше) оно начало тормозить. Подозреваю, что тормозить оно будет в геометричской прогрессии, или еще того хуже. Есть вариант переделать архитектуру импорта, но вот на какую? И нужен ли тогда тут вобще эластик?

xtraeft ★★☆☆
() автор топика
Последнее исправление: xtraeft (всего исправлений: 1)
Ответ на: комментарий от anonymous

кастуй программеров, а не быдлоадминов

Попытка не пытка. Честно говоря, не очень надеюсь получить ответ на лоре (или хотя бы пинок-намек в сторону решения), но опять же - попытка не пытка.

xtraeft ★★☆☆
() автор топика

засунь в хадуп или а спарк, если есть мощностя

anonymous
()

Может, это тормозит дельта-импорт. Можно попробовать сперва залить данные, а потом построить индекс. Как понимаю, elasticsearch должен это уметь, https://github.com/jprante/elasticsearch-river-jdbc/issues/29 .

Я для (гораздо меньшего) поиска использовал Sphinx Search, он был быстрее, чем Lucene, но это сам поиск, не импорт. Но если данные меняются, то он не подойдет: инкрементально он работать не умеет.

anonymous
()

Кто-то тут подкинул линк http://habrahabr.ru/post/224877/
Почитаю на днях и поковыряю конфиг. Но тред все равно интересен, может и правда есть что то более подходящее?

xtraeft ★★☆☆
() автор топика
Ответ на: комментарий от anonymous

Можно попробовать сперва залить данные, а потом построить индекс

Как тогда быть с импортом неуникальных строк? Их не надо импортировать.

Ну хотя можно их импортировать, а потом каким то костылем искать по всей базе дубли и удалять их, но это помоему очень криво.

xtraeft ★★☆☆
() автор топика
Последнее исправление: xtraeft (всего исправлений: 1)
Ответ на: комментарий от xtraeft

Можно данные сперва упорядочить linux-овым sort-ом (который sort -u), он же и большие файлы умеет обрабатывать.

anonymous
()

Я бы залил в постгрес с unique индексом по строке - так отсечем неуникальные строки. Памяти надо будет дофига и заливаться будет долго.

А для поиска sphinxsearch - по 10 миллиардам строк будет шустро искать. regexpы он не поддерживает, но есть вот что - http://sphinxsearch.com/docs/current.html#extended-syntax возможно покроет многие кейсы. regexpы поддерживает сам постгресс, хотя для таких объемов нужна куча памяти.

pi11 ★★★★★
()
Ответ на: комментарий от anonymous

Но если данные меняются, то он не подойдет: инкрементально он работать не умеет.

Если данные добавляются - то можно дельта индексы использовать. Если изменяются, то да - нужно все переиндексировать. Но кстати на переиндексации sphinx быстрее всего, что я пробовал.

pi11 ★★★★★
()
Ответ на: комментарий от bj

С хрена? У него уникальный индекс при вставке.

Потому что вероятно такие проблемы начинаются из за особенностей работы файловой системы и метода взаимодействия с ней программы.

rezedent12 ☆☆☆
()
Ответ на: комментарий от pi11

Так эластик и по базе может искать, нафиг тут сфинкс? Но хотелось бы без бд решить задачу, если это возможно.

xtraeft ★★☆☆
() автор топика
Ответ на: комментарий от bj

Потому что:
1. Незачем их хранить.
2. Лишние проблемы при выборках (придется при каждой выборке чекать результат еще и на неуник).

xtraeft ★★☆☆
() автор топика
Ответ на: комментарий от rezedent12

Какой файл? Уходи, если нечего сказать по теме.

xtraeft ★★☆☆
() автор топика
Ответ на: комментарий от anonymous

Каждый раз перед импортом? И хранить данные от каждого обновления и еще по ним sort делать?

xtraeft ★★☆☆
() автор топика
Ответ на: комментарий от xtraeft

Так эластик и по базе может искать, нафиг тут сфинкс?

Я тебе просто предлагаю альтернативное решение без эластика (я с ним не работал ни разу). Сфинкс очень быстрый и объемы большие ворочает. При этом к ресурсам не требователен.

Если не хочешь БД, то файлы можно например в xml перегнать и тоже скормить сфинксу. Но тут без решения вопроса об уникальности строк.

pi11 ★★★★★
()
Ответ на: комментарий от pi11

Сфинкс очень быстрый и объемы большие ворочает. При этом к ресурсам не требователен.

elasticsearch не менее быстрый, вопрос не стоит в скорости его работы.

Если не хочешь БД, то файлы можно например в xml перегнать и тоже скормить сфинксу. Но тут без решения вопроса об уникальности строк.

Если б не этот вопрос, я бы не создавал тред.

xtraeft ★★☆☆
() автор топика

не велосипедируй - твоя задача решается заливкой данных в нормальную БД, она за тебя проконтролирует и уникальность данных, и быстрый поиск выполнит

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

EugeneBas ★★
()
Ответ на: комментарий от xtraeft

ГЫГЫГЫГЫГЫ

Ты бы попробовал сначала, а потом уже ГЫГЫГЫГЫГЫ.

MySQL уже посоветовали, у PostgreSQL тоже есть full-text search

grep перестал устраивать.

Или купи памяти побольше

anonymous
()
Ответ на: комментарий от xtraeft

может тогда лучше ортопедом заделаешься, раз уж так костыли любишь? в матерых СУБД уже все, что можно, оптимизировали до тебя

EugeneBas ★★
()
Последнее исправление: EugeneBas (всего исправлений: 1)
Ответ на: комментарий от EugeneBas

Поиск текста везде очень медленный по сравнению с поисковыми движками, такими как сфинкс, лучен и тд. А на таких объемах поиск с помощью средств субд будет тормозить просто адово.

pi11 ★★★★★
()
Ответ на: комментарий от EugeneBas

Ты писал, что субд поиск выполнит. А я тебе сказал, что на таких объемах субд будет тормозить. Вот в чем проблема. Про Сфинкс я сам и писал, зачем ты мне этот пруф привел вообще не понятно.

pi11 ★★★★★
()
Ответ на: комментарий от pi11

субд выполнит его и не поперхнется, возможно ее скорости не хватит, значит нужно будет прикрутить сфинкс, но это не повод для ТСа хранить данные в текстовом файле\файлах и грепать, в этом суть

EugeneBas ★★
()
Ответ на: комментарий от EugeneBas

На миллиарде строк mysql/postgres будет искать в строках минуты. А сфинкс можно и к текстовым файлам прикрутить (надо только в xml конвертнуть их).

возможно ее скорости не хватит

Я тебе точно скажу, что не хватит. СУБД я бы здесь использовал из-за того, что с данными удобнее работать будет.

pi11 ★★★★★
()
Последнее исправление: pi11 (всего исправлений: 1)
Ответ на: комментарий от xtraeft

Ты же должен понимать, что с таким индексом дальше будет только хуже.

Если выгрузка одноразовая, то можно и потерпеть. Если каждый день такие объемы, то тут или привинчивать дедупликацию при выборке, или препроцессить на хадуп кластере.

bj
()
Ответ на: комментарий от EugeneBas

Давай, загони 15 млрд. записей в свой ненаглядный мускуль и проверь. Он даже в процессе записи раком встанет.

bj
()
Ответ на: комментарий от bj

не встанет, да и на сколько я понял задачу, ТСу нужно один раз залить и часто искать, поэтому не особо важно сколько будет идти наливка данных

EugeneBas ★★
()
Ответ на: комментарий от bj

Он даже в процессе записи раком встанет.

Да ладно.

Я вот не поленился и загнал в PostgreSQL миллиард записей с id и текстом. В партиционированную таблицу (1000 подтаблиц по 10**6 записей), без индексов

 bigt_fill 
-----------
 
(1 запись)

Время: 2239313,792 мс

Меньше 40 минут. Заполнение выглядит вполне линейно, я на глаз разницу во времени между заполнением первых таблиц и последних не заметил. Да, конфиг PostgreSQL не трогал

Не думаю что MySQL будет сильно отличаться

То есть как это будет обрабатывать модуль полнотекстового поиска конечно непонятно, но хотя бы попробовать можно

Deleted
()
Ответ на: комментарий от bj

Ты задачу тс не понял.

ну тогда разъясни, может я действительно не от тех условий отталкиваюсь? а еще лучше будет, если автор xtraeft сам разъяснит этот вопрос

EugeneBas ★★
()
Ответ на: комментарий от EugeneBas

но это не повод для ТСа хранить данные в текстовом файле\файлах и грепать, в этом суть

Никто их и не грепает, иди почитай как поисковые движки типа эластика или сфинкса работают.

в матерых СУБД уже все, что можно, оптимизировали до тебя

Поиск средствами бд проигрывает в разы-порядки поиску сфинксом/эластиком и подобными.

xtraeft ★★☆☆
() автор топика
Ответ на: комментарий от EugeneBas

а еще лучше будет, если автор xtraeft сам разъяснит этот вопрос

Тут нечего разъяснять, те кто знает, все поняли сразу.

xtraeft ★★☆☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.