powered by simpleCommunicator - 2.0.31     © 2024 Programmizd 02
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / ElasticSearch и реляционная СУБД
23 сообщений из 23, страница 1 из 1
ElasticSearch и реляционная СУБД
    #39852586
Фотография Щиче
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Доброго дня.

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

Перестаньте

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

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

Перестаньте


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


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