Стандартный способ показать, что новое в чем-то лучше старого – решение конкретной задачи.
Задача сначала решается старым способом. Показываются недостатки или неудобства решения по-старому, потом задача решается новым способом, в котором показанные недостатки отсутствуют.
Попытался найти на просторах интернета такую задачу, с которой прекрасно бы справлялся Эластик, и не так прекрасно движок какой-либо реляционной СУБД, и не нашел.
А Эластик уже популярен, и популярность набирает все большую.
Может кто-то знает, в чем Эластик сильнее реляционной СУБД, и сможет сформулировать свои знания на конкретном примере, или даже просто поделиться ссылкой?
Здравствуйте, s_aa, Вы писали:
B>>Т.е. сам ты ссылок никаких не нашёл, но с какого-то новогоднего перепоя решил, что "Эластик уже популярен"... может, сначала салатику, фантазёр?
_>В вакансиях часто встречается.
И это, кстати, тоже. Я даже участвовал как-то в проекте, в котором внедряли Эластик. Причем для задач, для которых, на мой взгляд, однозначно, больше бы подошла
реляционная СУБД. Происходило все это, как в анекдоте: "... плакали, кололись, но продолжали есть кактус".
И тогда, где-то в глубине души у меня закралась мысль: "а не основано ли довольно частое, чуть ли не повсеместное внедрение Эластика на политической воле, а не на рациональных доводах?"
Думаю, КЫФТ, конечно, уже не тот, но вдруг здесь найдется та все еще светлая голова, которая укажет на преимущества Эластика.
Вот и спросил.
Здравствуйте, Titus, Вы писали:
T>Думаю, КЫФТ, конечно, уже не тот, но вдруг здесь найдется та все еще светлая голова, которая укажет на преимущества Эластика.
ES имеет смысл использовать, там где нужен продвинутый полнотекстовый поиск (движок Apache Lucene), да в MSSQL 2005+ есть кое-какой FTS, но функционально слабоват, и по производительности уступает.
Кстати, на этом форуме его было-бы уместно использовать для поиска по статьям/постам.
T>Думаю, КЫФТ, конечно, уже не тот, но вдруг здесь найдется та все еще светлая голова, которая укажет на преимущества Эластика. T>Вот и спросил.
цена.
у нас оракл заместили для мелкой апликации, что матчит платежи. правда у нас solr, но на сколько я знаю это тот же эластик, только с java интерфейсом, вместо рест. на достаточно больших объемах ноль администрирования, реданденси из коробки и ничего не стоило канторе в плане лицензий. подозреваю оно и побыстрей записывает, всяких транзакций, лога транзакций там нет, все сильно проще, чем у среднестатистической субд. тем более той, где хоть какое-то реданденси есть.
Здравствуйте, Titus, Вы писали:
T>Может кто-то знает, в чем Эластик сильнее реляционной СУБД
Чтобы эластик был оправданнее FTS в базе данных надо чтобы у вас была одновременно большая нагрузка на базу (или мало мощностей под базу), и одновременно большая нагрузка на поиск.
РСУБД, в отличие от эластика, сложно масштабировать. Поэтому если ваши FTS запросы начнут съедать слишком много ресурсов в СУБД, то у вас начнутся проблемы. Эластик поможет вам разнести нагрузку на СУБД на несколько серверов, при этом существенно сэкономить на лицензиях СУБД и не переделывать архитектуру приложения.
Кроме того если вам нужны продвинутые возможности FTS, типа настройки релевантности, сложные полнотекстовые запросы, hit highlights, то эластик вам сможет помочь, а FTS в РСУБД — нет.
Здравствуйте, Titus, Вы писали:
T>Стандартный способ показать, что новое в чем-то лучше старого – решение конкретной задачи.
Например конкретная задача, решенная в Kibana — собирать терабайты логов с сотен сервисов в единое место и там быстро всё искать, строить дашборды, визуализацию, етс.
Или сайтики типа stackoverlow используют.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, gandjustas, Вы писали:
G>Чтобы эластик был оправданнее FTS в базе данных надо чтобы у вас была одновременно большая нагрузка на базу (или мало мощностей под базу), и одновременно большая нагрузка на поиск.
Получается оно для FTS-only и идёт как замена, а не как дополнение или надстройка к РСУБД? Мне просто казалось что это больше некоторая дополнительная сущность для спец. задач.
Здравствуйте, 4058, Вы писали:
4>Здравствуйте, Titus, Вы писали:
T>>Думаю, КЫФТ, конечно, уже не тот, но вдруг здесь найдется та все еще светлая голова, которая укажет на преимущества Эластика.
4>ES имеет смысл использовать, там где нужен продвинутый полнотекстовый поиск (движок Apache Lucene), да в MSSQL 2005+ есть кое-какой FTS, но функционально слабоват, и по производительности уступает.
Если под полнотекстовым поиском подразумевается лишь способность искать подстроку или комбинацию подстрок внутри документов, то с такой задачей прекрасно справляется и РСУБД.
Если же под продвинутым полнотекстовым поиском подразумевается изящный способ нахождения ответа, например, на вопрос: "Какая карта выпала Герману?", — которым в совершенстве владеют Яндекс и Гугл, то это уже интересно.
4>Кстати, на этом форуме его было-бы уместно использовать для поиска по статьям/постам.
Прекрасный кейс. Почти не сомневаюсь, что полнотекстовый поиск на rsdn.org выполняется в рамках РСУБД.
Было бы интересно посмотреть, как Эластик уделает старую, но все еще используемую технологию.
T>>Думаю, КЫФТ, конечно, уже не тот, но вдруг здесь найдется та все еще светлая голова, которая укажет на преимущества Эластика. T>>Вот и спросил.
Gt_>цена. Gt_>... и ничего не стоило канторе в плане лицензий.
Да, это аргумент. Хотя, проект, в котором участвовал я, использовал Эластик по платному тарифу. Но и там единственный понятный мне аргумент был таким же: цена лицензий. Если бы к цене лицензий добавили стоимость собственных программистов, ответ был бы уже не столь очевидным.
Здравствуйте, gandjustas, Вы писали:
G>РСУБД, в отличие от эластика, сложно масштабировать.
На самом деле, РСУБД масштабируется, но, действительно, масштабирование это нелинейно. На каком-то этапе возникают проблемы: добавление сервера не только не увеличивает производительность, но даже уменьшает ее.
Это, если действовать "в лоб".
Но, почти уверен, в большинстве случаев, когда используется Эластик, до проблем масштабирования РСУБД еще очень далеко.
Яндекс Метрика работает с петабайтами данных. И они были вынуждены сделать собственный ClickHouse. Но таких, как Яндекс по пальцам перечесть. И все они используют не Эластик (разве что для каких-то небольших проектов).
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Titus, Вы писали:
T>>Стандартный способ показать, что новое в чем-то лучше старого – решение конкретной задачи. ·>Например конкретная задача, решенная в Kibana — собирать терабайты логов с сотен сервисов в единое место и там быстро всё искать, строить дашборды, визуализацию, етс. ·>Или сайтики типа stackoverlow используют.
Задача подходящая. Еще бы ее решение на двух технологиях увидеть. То есть просто сообщения: "мы смогли это сделать на Эластике", — недостаточно.
Нужно еще: "Посмотрите, как криво все было на РСУБД".
Тут было бы место для анализа: действительно ли на РСУБД криво, или же ребята просто готовить не умеют.
Здравствуйте, Kernan, Вы писали:
K>Получается оно для FTS-only и идёт как замена, а не как дополнение или надстройка к РСУБД? Мне просто казалось что это больше некоторая дополнительная сущность для спец. задач.
Elastic исходно построен как система полнотекстового поиска. То что там можно сохранять документы и находить по прямому совпадению отдельных полей позволят использовать не только в таком подходе, но это все не совсем его назначение все же. Его главные сила и возможности — в полнотекстовом поиске.
Эластик можно использовать как самостоятельную основную базу, но "в общем случае", на мой взгляд его эффективнее использовать как дополнение к РСУБД для поиска по текстам. Т.е. РСУБД идет как основное хранилище, где транзационность, надежность хранения и прочее, а для полнотекстового поиска данные сливаются в эластик и поиск проводится в эластике. Данные в эластике при этом вторичны — их можно в любой момент все выкинуть и пересоздать заново из основной БД. Но они обеспечивают эффективный полнотекстовый поиск.
Здравствуйте, Titus, Вы писали:
T>Если под полнотекстовым поиском подразумевается лишь способность искать подстроку или комбинацию подстрок внутри документов, то с такой задачей прекрасно справляется и РСУБД.
Под полнотекстовым поиском обычно подразумевается возможность быстро находить фразу внутри большого объема текстов (возможно — больших текстов), с учетом морфологии. Т.е. чтобы по вопросу "должник Иванов" нашлись документы с фразами
— к должнику Иванову
— от должника Иванова
— должник Петр Иванов
— с должника П.С. Иванова
такого типа. Это не запрос классической реляционной алгебры, так что сами по себе реляционные СУБД тут плохо помогают (придется много лопатить вручную, чтобы сделать подходящее для быстрого поиска представление). Однако, большинство взрослых РСУБД имеют в комплекте расширение для полнотекстового поиска. Но это у них вторичные дополнения к основному функционалу, а эластик — это специализированная БД для полнотекстового поиска.
Здравствуйте, Titus, Вы писали:
T>Стандартный способ показать, что новое в чем-то лучше старого – решение конкретной задачи. T>Задача сначала решается старым способом. Показываются недостатки или неудобства решения по-старому, потом задача решается новым способом, в котором показанные недостатки отсутствуют. T>Попытался найти на просторах интернета такую задачу, с которой прекрасно бы справлялся Эластик, и не так прекрасно движок какой-либо реляционной СУБД, и не нашел. T>А Эластик уже популярен, и популярность набирает все большую. T>Может кто-то знает, в чем Эластик сильнее реляционной СУБД, и сможет сформулировать свои знания на конкретном примере, или даже просто поделиться ссылкой?
Опустим тот момент, что FTS — это не LIKE, а отдельные индексы, функции и движки, которые в реляционных базах побочная функциональность, а в эластике основная.
Если кратко и просто: масштабирование и репликация. Сделай кластер из 400 экземпляров MS SQL и MySQL, так, что бы данные дублировались сколько тебе надо, что бы чтение-запись распараллеливалось между узлами, чтобы можно было на лету добавлять и убирать сервера из кластера и т.д. Для эластика, когда тебе нахватает места или скорости (будто скорость чтения или записи) — ты просто докидываешь новых серверов к кластер и всё. Повторить такой фокус для реляционных СУБД — нереально.
Здравствуйте, Titus, Вы писали:
T>·>Например конкретная задача, решенная в Kibana — собирать терабайты логов с сотен сервисов в единое место и там быстро всё искать, строить дашборды, визуализацию, етс. T>·>Или сайтики типа stackoverlow используют. T>Задача подходящая. Еще бы ее решение на двух технологиях увидеть. То есть просто сообщения: "мы смогли это сделать на Эластике", — недостаточно.
Можешь покопать интернет если интересует историю развития SO. Начинали они классически. Потом прикрутили elastic, redis, haproxy и прочее. Подробности по ссылке выше. Можно найти и ещё инфы, но мне лень.
T>Нужно еще: "Посмотрите, как криво все было на РСУБД". T>Тут было бы место для анализа: действительно ли на РСУБД криво, или же ребята просто готовить не умеют.
Дело не в кривизне, дело в том, что рсубд не масштабируется.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, gandjustas, Вы писали:
G>>Чтобы эластик был оправданнее FTS в базе данных надо чтобы у вас была одновременно большая нагрузка на базу (или мало мощностей под базу), и одновременно большая нагрузка на поиск. K>Получается оно для FTS-only и идёт как замена, а не как дополнение или надстройка к РСУБД? Мне просто казалось что это больше некоторая дополнительная сущность для спец. задач.
Каких таких "спец" задач, кроме FTS?
Если посмотреть язык запросов, то кроме fulltext все делается в РСУБД с гораздо меньшим расходом ресурсов
Здравствуйте, gandjustas, Вы писали:
G>Если посмотреть язык запросов, то кроме fulltext все делается в РСУБД с гораздо меньшим расходом ресурсов
Это если всё влазит в рсубд. Если кол-во процов, оперативы или дисков становится слишком большим, то приходится масштабировать горизонтально. Иными словами, иметь 10тб оперативы на одном девайсе не выйдет. Гораздо проще иметь 50тб оперативы в кластере. Да, расход выше, но зато работает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, gandjustas, Вы писали:
G>>Если посмотреть язык запросов, то кроме fulltext все делается в РСУБД с гораздо меньшим расходом ресурсов ·>Это если всё влазит в рсубд.
РСУБД умеет работать когда объем данных значительно превышает объемы памяти.
