Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 ElasticSearch и реляционная СУБД  [new]
Щиче
Member

Откуда: Чебоксары
Сообщений: 750
Доброго дня.

Моя контора хочет взять на вооружение ElasticSearch. В официальной доке по нему написано: "Хранение данных бизнес-процессов".

Вопрос встает, а чем он, собственно, лучше реляционной БД? Полнотекстовый поиск здесь плохо пригоден, поиск по релевантности вообще никак не связан.

Поясните, пожалуйста, место ElasticSearch и прочих подобных движков в бизнесе.
22 авг 19, 11:40    [21955236]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Shtock
Member

Откуда: СПб
Сообщений: 3048
потому что все полнотекстовые поиски притянутые за уши в обычные бд как то оракл, постгресс и прочее медленны что пипец. если грамотно настроить эластик, то поиск по джейсонам, тексту в разы быстрее. Мы, например, весь профиль пользователя держим в джейсоне, индексируем в эластике и абсолютно произвольные поиски по какому угодно where работают быстрее чем в реляционке, которая заточена под то, чтобы мизер полей в таблице был под индексом.
22 авг 19, 21:21    [21956012]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Щиче
Member

Откуда: Чебоксары
Сообщений: 750
Shtock, благодарю
23 авг 19, 12:18    [21956368]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 32252
Блог
Щиче,

Используется, чтобы хранить портянки данных, например, кредитные заявки.
Вам нужно решать исходя из того, для чего вы его хотите применить.
24 авг 19, 04:41    [21956865]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
Щиче, elastic search хранит документы вида set of key-values.

Например:
eventDate = "2018-01-02"
documentBody = "Заявка №134...."
owner="mayton"

Обычно ElasticSearch не покупают отдельно. А покупают целый стек ELK куда входит Kibana как средство
визуализации и построения графиков и всякие служебные штуки типа LogStash которые просто по плану
индексируют содержимое файловой системы например. На нем-же делают индексаторы текстовых
лог-файлов. Причем достаточно успешные. Где каждая строчка-лог файла - это мини-документ
в эластике.

К реляционкам Эластик никакого отношения не имеет по определению. Т.к его модель данных не предполагает вообще
никаких нормализаций.
26 авг 19, 23:11    [21957973]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Щиче
Member

Откуда: Чебоксары
Сообщений: 750
mayton
К реляционкам Эластик никакого отношения не имеет по определению. Т.к его модель данных не предполагает вообще
никаких нормализаций.


Это я знаю. Поставил, поигрался с ним, составил конспект. Мне непонятна его роль в бизнес задачах. Ведь, если все можно индексировать, то будут дикие тормоза при обновлении. Если бы были столь суперэффективные индексы, то по идее, они должны были давно появиться в реляционках.
Мне интересны типовые бизнес примеры, где Elastic четко превосходит реляционку. С полнотекстовым понятно, а ещё?
27 авг 19, 09:21    [21958068]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
Я не знаю таких кейсов.

Спросите у того кто вам сказал такую идею.
27 авг 19, 10:10    [21958107]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2340
Щиче,

Почему Elasticsearch - хороший выбор для сбора и анализа данных среднего объёма
29 авг 19, 22:36    [21960176]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 3062
Shtock
потому что все полнотекстовые поиски притянутые за уши в обычные бд как то оракл, постгресс и прочее медленны что пипец. если грамотно настроить эластик, то поиск по джейсонам, тексту в разы быстрее. Мы, например, весь профиль пользователя держим в джейсоне, индексируем в эластике и абсолютно произвольные поиски по какому угодно where работают быстрее чем в реляционке, которая заточена под то, чтобы мизер полей в таблице был под индексом.


Имхую: Это не так, если родной полнотекстовый поиск в базе медленный - значит неправильно надевелопили.
ElasticSearch вообще-то не заменяет собой родные полнотекстовые поиски, скорее - дает возможность накопления, поиска и визализации в данных, часто не структурированных, типа логов, телеметрии всякой и т.д.
2 сен 19, 10:39    [21961675]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2340
Ролг Хупин
ElasticSearch вообще-то не заменяет собой родные полнотекстовые поиски

Вполне себе заменяет.

Lucene - свободная библиотека для высокопроизводительного полнотекстового поиска фонда Apache, используемая в качестве основы в двух самых популярных тиражируемых поисковых системах - Elasticsearch и Solr.
2 сен 19, 11:30    [21961728]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
На ниве java разработки, единственный самодостаточный и бесплатный движок текстового поиска это Apache lucene. И программные продукты которые мы здесь обсуждали содержат зависимости от Lucene.

Прочие postgres gin, oracle text , являются частью DBMS и технологически неотделимы от нее. В отличие от Elastic/Lucene который существует вне DBMS.
2 сен 19, 12:16    [21961763]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 861
чё-то у фонда Apache сам Apache такой себе получился...

mayton
Прочие postgres gin, oracle text , являются частью DBMS и технологически неотделимы от нее. В отличие от Elastic/Lucene который существует вне DBMS.

это также подразумевает, что надо ставить вторую БД, помимо основной + раздваивать данные
2 сен 19, 15:31    [21961965]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
Да. Самые эффективные техники текстового поиска строятся во вне реляционных DBMS.
2 сен 19, 15:48    [21961985]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 861
Я знаю Avito кажется юзает ES в кач-ве отдельного поиска в дополнение к своей БД
или какой-то другой крупняк
НО также я знаю, что:
Использовать встроенный в PG FTS вместо связки из PG и специализированного ПО для FTS, такого, как Sphinx, ES или Solr, интересно по следующим причинам:
1. данные НЕ приходится хранить в двух экземплярах. То есть, если у вас 500 Гб данных, НЕ приходится использовать 1 Тб места на диске, что есть удобно.
2. данные всегда консистентны. Скажем, если у вас связка из PG и ES, и синхронизация документов работает с запаздыванием или ломается, в поиске вы можете увидеть ерунду.
Например, уже удаленные документы.
3. не приходится устанавливать и поддерживать какого-либо дополнительного ПО — обновлять его, бэкапить, мониторить, писать какие-то скрипты синхронизации, и так далее.
Если у вас уже есть PG, все просто работает.
2 сен 19, 16:55    [21962048]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
Там не будет соотношения 1:1.

Текстовые данные - денормализуются.

И самое главное - прогоняются через стемминг или лемматизацию. Вобщем пропорции будут другие.
2 сен 19, 17:08    [21962059]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 3062
Дмитрий Мух
Ролг Хупин
ElasticSearch вообще-то не заменяет собой родные полнотекстовые поиски

Вполне себе заменяет.

Lucene - свободная библиотека для высокопроизводительного полнотекстового поиска фонда Apache, используемая в качестве основы в двух самых популярных тиражируемых поисковых системах - Elasticsearch и Solr.


тут все зависит от термина "заменяет".
Родной FTS в базе - лучше приделанного сбоку.
Но все зависит от задачи.
17 сен 19, 16:42    [21972695]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26739
Ролг Хупин
Дмитрий Мух
пропущено...

Вполне себе заменяет.

Lucene - свободная библиотека для высокопроизводительного полнотекстового поиска фонда Apache, используемая в качестве основы в двух самых популярных тиражируемых поисковых системах - Elasticsearch и Solr.


тут все зависит от термина "заменяет".
Родной FTS в базе - лучше приделанного сбоку.
Но все зависит от задачи.

Чем лучше? Вы пробовали сравнивать? По каким критериям?
17 сен 19, 19:21    [21972830]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 3062
skyANA
Ролг Хупин
пропущено...


тут все зависит от термина "заменяет".
Родной FTS в базе - лучше приделанного сбоку.
Но все зависит от задачи.

Чем лучше? Вы пробовали сравнивать? По каким критериям?


Я использовал когда-то Lucene, когда в постгресе не было FTS, и SQL Server Express был без него.
Лучше тем, что:
Например, в запросе (SQL Server или PostgreSQL ...) юзер может использовать FTS запросы.
Если это что-то прикрученное сбоку, то это не работает.
Кроме того - синхронизация данных проблематична, дублирование и т.д. На больших базах - совсем тяжело.
18 сен 19, 11:11    [21973075]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
Гугл весь работает на асинхронных репликациях текстовых индексов. И ничего.
18 сен 19, 11:27    [21973093]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 3062
mayton
Гугл весь работает на асинхронных репликациях текстовых индексов. И ничего.


Да никто не спорит. Все зависит от задачи, я писал выше.

У поиска гугла много преимущество и особенностей.
Результаты поиска очень приблизительны, могут выдаваться не существующие ссылки и т.д., синхронизация - что-то их внутреннее, когда и как делать - знают они.
Далее - огромные статические базы словоформ, слов, выражений и т.д. и т.п. Они могут себе это позволить.

Если юзер будет делать что-то такое - пусть делает.
Но, если в SQL Server или PostgreSQL есть свои родные FTS, то многих вопросов просто не существует. Все делает сервер или девелопер в триггерах, функциях, процедурах.
18 сен 19, 11:43    [21973102]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2340
Ролг Хупин
Например, в запросе (SQL Server или PostgreSQL ...) юзер может использовать FTS запросы.

А что за задача такая, когда юзер сам SQL запросы пишет?
18 сен 19, 11:56    [21973124]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 3062
Дмитрий Мух
Ролг Хупин
Например, в запросе (SQL Server или PostgreSQL ...) юзер может использовать FTS запросы.

А что за задача такая, когда юзер сам SQL запросы пишет?


Перестаньте

Клиентское приложение работает с базой клиент-сервер или через сервис, есть возможность поиска, юзер ищет.
18 сен 19, 15:02    [21973307]     Ответить | Цитировать Сообщить модератору
 Re: ElasticSearch и реляционная СУБД  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2340
Ролг Хупин
Дмитрий Мух
пропущено...

А что за задача такая, когда юзер сам SQL запросы пишет?


Перестаньте Картинка с другого сайта.

Клиентское приложение работает с базой клиент-сервер или через сервис, есть возможность поиска, юзер ищет.

Тогда "Лучше тем, что: Например, в запросе (SQL Server или PostgreSQL ...) юзер может использовать FTS запросы" - это не аргумент :)
18 сен 19, 22:00    [21973671]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить