Гость
Map
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / ElasticSearch и реляционная СУБД / 23 сообщений из 23, страница 1 из 1
22.08.2019, 11:40
    #39852586
Щиче
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Доброго дня.

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

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

Поясните, пожалуйста, место ElasticSearch и прочих подобных движков в бизнесе.
...
Рейтинг: 0 / 0
22.08.2019, 21:21
    #39853009
Shtock
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
потому что все полнотекстовые поиски притянутые за уши в обычные бд как то оракл, постгресс и прочее медленны что пипец. если грамотно настроить эластик, то поиск по джейсонам, тексту в разы быстрее. Мы, например, весь профиль пользователя держим в джейсоне, индексируем в эластике и абсолютно произвольные поиски по какому угодно where работают быстрее чем в реляционке, которая заточена под то, чтобы мизер полей в таблице был под индексом.
...
Рейтинг: 0 / 0
23.08.2019, 12:18
    #39853201
Щиче
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Shtock, благодарю
...
Рейтинг: 0 / 0
24.08.2019, 04:41
    #39853455
Критик
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Щиче,

Используется, чтобы хранить портянки данных, например, кредитные заявки.
Вам нужно решать исходя из того, для чего вы его хотите применить.
...
Рейтинг: 0 / 0
26.08.2019, 23:11
    #39853948
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Щиче, elastic search хранит документы вида set of key-values.

Например:
Код: sql
1.
2.
3.
eventDate = "2018-01-02"
documentBody = "Заявка №134...."
owner="mayton"


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

К реляционкам Эластик никакого отношения не имеет по определению. Т.к его модель данных не предполагает вообще
никаких нормализаций.
...
Рейтинг: 0 / 0
27.08.2019, 09:21
    #39854014
Щиче
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
maytonК реляционкам Эластик никакого отношения не имеет по определению. Т.к его модель данных не предполагает вообще
никаких нормализаций.

Это я знаю. Поставил, поигрался с ним, составил конспект. Мне непонятна его роль в бизнес задачах. Ведь, если все можно индексировать, то будут дикие тормоза при обновлении. Если бы были столь суперэффективные индексы, то по идее, они должны были давно появиться в реляционках.
Мне интересны типовые бизнес примеры, где Elastic четко превосходит реляционку. С полнотекстовым понятно, а ещё?
...
Рейтинг: 0 / 0
27.08.2019, 10:10
    #39854043
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Я не знаю таких кейсов.

Спросите у того кто вам сказал такую идею.
...
Рейтинг: 0 / 0
29.08.2019, 22:36
    #39855388
Дмитрий Мух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
...
Рейтинг: 0 / 0
02.09.2019, 10:39
    #39856201
Ролг Хупин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Shtockпотому что все полнотекстовые поиски притянутые за уши в обычные бд как то оракл, постгресс и прочее медленны что пипец. если грамотно настроить эластик, то поиск по джейсонам, тексту в разы быстрее. Мы, например, весь профиль пользователя держим в джейсоне, индексируем в эластике и абсолютно произвольные поиски по какому угодно where работают быстрее чем в реляционке, которая заточена под то, чтобы мизер полей в таблице был под индексом.

Имхую: Это не так, если родной полнотекстовый поиск в базе медленный - значит неправильно надевелопили.
ElasticSearch вообще-то не заменяет собой родные полнотекстовые поиски, скорее - дает возможность накопления, поиска и визализации в данных, часто не структурированных, типа логов, телеметрии всякой и т.д.
...
Рейтинг: 0 / 0
02.09.2019, 11:30
    #39856215
Дмитрий Мух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Ролг ХупинElasticSearch вообще-то не заменяет собой родные полнотекстовые поиски
Вполне себе заменяет.

Lucene - свободная библиотека для высокопроизводительного полнотекстового поиска фонда Apache, используемая в качестве основы в двух самых популярных тиражируемых поисковых системах - Elasticsearch и Solr.
...
Рейтинг: 0 / 0
02.09.2019, 12:16
    #39856236
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
На ниве java разработки, единственный самодостаточный и бесплатный движок текстового поиска это Apache lucene. И программные продукты которые мы здесь обсуждали содержат зависимости от Lucene.

Прочие postgres gin, oracle text , являются частью DBMS и технологически неотделимы от нее. В отличие от Elastic/Lucene который существует вне DBMS.
...
Рейтинг: 0 / 0
02.09.2019, 15:31
    #39856339
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
чё-то у фонда Apache сам Apache такой себе получился...

maytonПрочие postgres gin, oracle text , являются частью DBMS и технологически неотделимы от нее. В отличие от Elastic/Lucene который существует вне DBMS.
это также подразумевает, что надо ставить вторую БД, помимо основной + раздваивать данные
...
Рейтинг: 0 / 0
02.09.2019, 15:48
    #39856346
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Да. Самые эффективные техники текстового поиска строятся во вне реляционных DBMS.
...
Рейтинг: 0 / 0
02.09.2019, 16:55
    #39856382
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Я знаю Avito кажется юзает ES в кач-ве отдельного поиска в дополнение к своей БД
или какой-то другой крупняк
НО также я знаю, что:
Использовать встроенный в PG FTS вместо связки из PG и специализированного ПО для FTS, такого, как Sphinx, ES или Solr, интересно по следующим причинам:
1. данные НЕ приходится хранить в двух экземплярах. То есть, если у вас 500 Гб данных, НЕ приходится использовать 1 Тб места на диске, что есть удобно.
2. данные всегда консистентны. Скажем, если у вас связка из PG и ES, и синхронизация документов работает с запаздыванием или ломается, в поиске вы можете увидеть ерунду.
Например, уже удаленные документы.
3. не приходится устанавливать и поддерживать какого-либо дополнительного ПО — обновлять его, бэкапить, мониторить, писать какие-то скрипты синхронизации, и так далее.
Если у вас уже есть PG, все просто работает.
...
Рейтинг: 0 / 0
02.09.2019, 17:08
    #39856390
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Там не будет соотношения 1:1.

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

И самое главное - прогоняются через стемминг или лемматизацию. Вобщем пропорции будут другие.
...
Рейтинг: 0 / 0
17.09.2019, 16:42
    #39862960
Ролг Хупин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Дмитрий МухРолг ХупинElasticSearch вообще-то не заменяет собой родные полнотекстовые поиски
Вполне себе заменяет.

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

тут все зависит от термина "заменяет".
Родной FTS в базе - лучше приделанного сбоку.
Но все зависит от задачи.
...
Рейтинг: 0 / 0
17.09.2019, 19:21
    #39863053
skyANA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Ролг ХупинДмитрий Мухпропущено...

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

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

тут все зависит от термина "заменяет".
Родной FTS в базе - лучше приделанного сбоку.
Но все зависит от задачи.
Чем лучше? Вы пробовали сравнивать? По каким критериям?
...
Рейтинг: 0 / 0
18.09.2019, 11:11
    #39863207
Ролг Хупин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
skyANAРолг Хупинпропущено...


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

Я использовал когда-то Lucene, когда в постгресе не было FTS, и SQL Server Express был без него.
Лучше тем, что:
Например, в запросе (SQL Server или PostgreSQL ...) юзер может использовать FTS запросы.
Если это что-то прикрученное сбоку, то это не работает.
Кроме того - синхронизация данных проблематична, дублирование и т.д. На больших базах - совсем тяжело.
...
Рейтинг: 0 / 0
18.09.2019, 11:27
    #39863222
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Гугл весь работает на асинхронных репликациях текстовых индексов. И ничего.
...
Рейтинг: 0 / 0
18.09.2019, 11:43
    #39863230
Ролг Хупин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
maytonГугл весь работает на асинхронных репликациях текстовых индексов. И ничего.

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

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

Если юзер будет делать что-то такое - пусть делает.
Но, если в SQL Server или PostgreSQL есть свои родные FTS, то многих вопросов просто не существует. Все делает сервер или девелопер в триггерах, функциях, процедурах.
...
Рейтинг: 0 / 0
18.09.2019, 11:56
    #39863246
Дмитрий Мух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Ролг ХупинНапример, в запросе (SQL Server или PostgreSQL ...) юзер может использовать FTS запросы.
А что за задача такая, когда юзер сам SQL запросы пишет?
...
Рейтинг: 0 / 0
18.09.2019, 15:02
    #39863360
Ролг Хупин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Дмитрий МухРолг ХупинНапример, в запросе (SQL Server или PostgreSQL ...) юзер может использовать FTS запросы.
А что за задача такая, когда юзер сам SQL запросы пишет?

Перестаньте

Клиентское приложение работает с базой клиент-сервер или через сервис, есть возможность поиска, юзер ищет.
...
Рейтинг: 0 / 0
18.09.2019, 22:00
    #39863607
Дмитрий Мух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ElasticSearch и реляционная СУБД
Ролг ХупинДмитрий Мухпропущено...

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

Перестаньте


Клиентское приложение работает с базой клиент-сервер или через сервис, есть возможность поиска, юзер ищет.
Тогда "Лучше тем, что: Например, в запросе (SQL Server или PostgreSQL ...) юзер может использовать FTS запросы" - это не аргумент :)
...
Рейтинг: 0 / 0
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / ElasticSearch и реляционная СУБД / 23 сообщений из 23, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]