LINUX.ORG.RU

Elasticsearch 1.5

 ,


1

3

Выпущена новая версия Elasticsearch — современного распределенного движка полнотекстового поиска и выполнения аналитических запросов реального времени.

Основные изменения этой версии:

  • Добавлена экспериментальная функция доступа к данным дочерних документов при выполнении запросов по parent/child отношениям и при работе с nested-объектами. Поддерживается извлечение произвольного количества дочерних документов с поддержкой постраничной выдачи, сортировки по релевантности и подсветки найденных фрагментов текста.
  • Shadow-реплики — возможность запуска нескольких узлов кластера Elasticsearch над одной (сторонней) распределенной файловой системой. Фактическая репликация и надежность хранения данных в этом случае обеспечивается файловой системой, а Elasticsearch обеспечивает отказоустойчивое распределение функций master/slave по узлам кластера.
  • Улучшены алгоритмы управления кластером, благодаря чему функции распределения шардов, создания, восстановления и удаления индексов стали работать более надежно и предсказуемо.
  • Были доработаны функции проверки контрольных сумм данных, добавленные в прошлой версии Elasticsearch 1.4.

>>> Подробности

★★★★★

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

Можно ли на нем сделать аналог грепа для большого количества строк или это будет огромным костылем? Если второе, то что лучше взять?

xtraeft ★★☆☆
()

функции распределения шардов, создания, восстановления и удаления индексов стали работать более надежно и предсказуемо.

Вот это хорошая новость.

sT331h0rs3 ★★★★★
()

Русский там как обычно через ж.. ?

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

sphinx ( особенно последний релиз ) стал завязан на mysql. + через жопное разделение на индекс + основные данные всегда добивало.

Jopich
()

Модная стартапная поделка для рубистов. Компенсирует неумение пользоваться БД, прибавляет 200 очков к разгребанию устаревшего кода.

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

через жопное

слитно же, как можно с таким ником так ошибаться.

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

Если нужны regexp и всякие wildcard в общем виде, то наверное нет. А если индексированных поиск по токенезированному тексту то да.

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

большого количества

зависимо от того, что понимать «большого» есть 2 варианта:
1) varchar и индекс в mysql
2) ack-grep и всякие там parallel

полагаю, что тебе подойдет 1-й

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

Зависит от нагрузки, объема данных и типа grepов, которые хочешь делать.

Если сранивать с грепаньем 15-30ГБ лога grepом и с помощью Elasticsearch то эластик это делает почти мгновенно, а grep не скоро очухается.

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

Если сранивать с грепаньем 15-30ГБ лога grepом и с помощью Elasticsearch то эластик это делает почти мгновенно, а grep не скоро очухается.

Это понятно, поэтому и ищу замену grep. Всякие вилдкарды и регекспы нужны.

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

Да что-то там тестил, но опыта особого нет и со временем желание пропало, отложил до лучших времен. Ну и те грабли с уникальностью не придумал как обойти.

Не хочешь заняться?:)

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

Не хочешь заняться?:)

Задача на самом деле мне интересна, только я сейчас в фазе «ничего не делания». А когда она закончится - не знаю. Если бы ты еще джаббер не дропнул я бы стукнул через X дней.

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

хваленый ack

я-то его не использую, просто знаю что такой есть и что его «советуют». Вот и вспомнился он.

миллиард строк

ну тогда sql решение будет в самый раз

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

Да, regexpы там есть. У себя на работе юзаю, где то 20 ГБ логов в сутки. Особенно приятно искать в Kibana с графиками и termsами.

Но для этих фишек уже надо парсить логи logstasheм.

Theif
()

GitHub на нём работает, кстати.

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

ack давно не используют уже, на замену пришел ag (aka the_silver_searcher), интересно на том файле затестить, не поделишься файликом-то?

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

Слышишь! Я Си только сегодня начал учить, полегче тут!

Ага и видимо сразу начал юзать libastral для трансляции голоса и мыслей на расстоянии.

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

через жопное разделение на индекс + основные данные всегда добивало

А что, ES при каждом запросе data source парсит?

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

ag

Спасибо, попробую.

не поделишься файликом-то?

Нет, не могу.

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

Я знаю что есть, просто не осилил соорудить нормальную архитектуру и наткнулся ряд проблем, вот и подумал - вдруг инструмент совсем не подходит?

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

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

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

ag:
real 16m3.919s
user 4m10.480s
sys 1m11.456s

fgrep:
real 6m6.231s
user 0m23.142s
sys 0m20.458s

Я что-то даже и не сомневался. Это на простом ag 'линукс' / fgrep 'линукс'. В любом случае меня выполнение даже за минуту не очень устроит, желательно уложиться в несколько секунд. На эластике вроде такое можно.

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

надпись крупными буквами читал в файле sphinxapi ?

WARNING # We strongly recommend you to use SphinxQL instead of the API

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

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

Файл дашь? Давай сравним вместе какой-то любой файл, потому что с той стороны интернета можно вбрасывать всё, что хочешь, совершая хуление лучших инструментов.

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

Я же сказал, что не могу дать исходный файл. Там ничего загадочного: utf-8, 848057459 строк.

потому что с той стороны интернета можно вбрасывать всё, что хочешь

Зачем мне врать? Если бы оно работало быстрее грепа, я бы очень рад был.

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

Всякие вилдкарды и регекспы нужны.

Вилдкарды, кроме *слово и слово* не индексируются. Регекспы не индексируются. По-моему в этом случае Elasticsearch не нужен.

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

надпись крупными буквами читал в файле sphinxapi ?

WARNING # We strongly recommend you to use SphinxQL instead of the API

И причем тут MySQL? Ты эту надпись прочитал но не понял что-ли?

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

вот результаты грепа 'линукс' дампа, если интересно, 5997074 строк с кириллицей/латиницей, весом 788 мегабайт:

→ fgrep  

real	0m0.307s
user	0m0.146s
sys	0m0.159s

→ ag 

real	0m0.386s
user	0m0.322s
sys	0m0.061s


→ pt 

real	0m4.902s
user	0m5.330s
sys	0m0.645s

→ ack 

real	0m6.926s
user	0m6.709s
sys	0m0.205s
pt — это the_platinum_searcher на Go.

Да, странно, я ранее замерял, и ag был более самый быстрый на мультибайтовых кодировках.

Кстати он не сильно от fgrep отстает на моём тесте, в отличие от твоего, где в 2 раза.

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

Кстати он не сильно от fgrep отстает на моём тесте, в отличие от твоего, где в 2 раза.

Но у тебя и количество строк почти в 150 раз меньше :)
В любом случае эластик делал все это довольно быстро даже из коробки без настройки с архитектурой наугад. Почему то подумалось, что можно двигаться в этом направлении, тем более результаты надо веб интерфейс отдавать, а с этим у эластика все хорошо.

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

функции распределения шардов, создания, восстановления и удаления индексов стали работать более надежно и предсказуемо.

Вот это хорошая новость.

«Мы стали более лучше удалять индексы» (ц)

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

Раньше создание индексов на разваленном кластере с некоторой вероятностью приводило к тому, что индекс создавался как-то не до конца и застревал в таком состоянии. Надеюсь это они и починили.

maxcom ★★★★★
() автор топика

Баран key GNU

Алгоритм поиска методом ластика, при сравнении стираются оба операнда!

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

Часто склоняют применить ELK в проектах больших данных (1ТБ+ входящих в сутки, 200+ТБ сжатого хранилища). Но с такой неопределённостью в поведении, настораживают затраты на эксплуатацию. Вспоминается анекдот про ультрасовременный самолёт («а сейчас попробуем с этим всем г**м взлететь»).

Будем подождать и использовать энтерпрайз. Этому проекту явно нужно дать годик-другой на дозревание, IMO.

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