Стандартный способ показать, что новое в чем-то лучше старого – решение конкретной задачи.
Задача сначала решается старым способом. Показываются недостатки или неудобства решения по-старому, потом задача решается новым способом, в котором показанные недостатки отсутствуют.
Попытался найти на просторах интернета такую задачу, с которой прекрасно бы справлялся Эластик, и не так прекрасно движок какой-либо реляционной СУБД, и не нашел.
А Эластик уже популярен, и популярность набирает все большую.
Может кто-то знает, в чем Эластик сильнее реляционной СУБД, и сможет сформулировать свои знания на конкретном примере, или даже просто поделиться ссылкой?
Здравствуйте, 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 все делается в РСУБД с гораздо меньшим расходом ресурсов ·>Это если всё влазит в рсубд.
РСУБД умеет работать когда объем данных значительно превышает объемы памяти.
Я может что не понял, но ES это для поиска, а СУБД для хранения данных. Как их можно сравнивать? Или ты сравниваешь их типа в БД мы заюзаем FTS вместо ES? Ну так FTS убогий и его ни для чего полезного не хватит. Чисто для галочки сделать поиск, которым никто потом пользоваться не будет, ибо он что надо не находит, а что не надо — находит в изобилии. Этим страдают всякие интернет магазины, уже привычка искать сразу через гугл, а не через встроенный поиск.
Здравствуйте, gandjustas, Вы писали:
G>>>Если посмотреть язык запросов, то кроме fulltext все делается в РСУБД с гораздо меньшим расходом ресурсов G>·>Это если всё влазит в рсубд. G>РСУБД умеет работать
Ага. Но только мееедленно.
G> когда объем данных значительно превышает объемы памяти.
elastic тоже. У меня совсем другой поинт был. Ну пусть диск. Объём диска на кластере всё равно может быть на много порядков больше, чем на сервере рсубд.
Вспомни на чём выехал гугл — вместо супер-пупер дорогих серверов собирал кластеры на бросовом железе — кпд меньше, но мощность выше — тем самым обогнав по многим характеристикам существующие решения.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, gandjustas, Вы писали:
G>>>>Если посмотреть язык запросов, то кроме fulltext все делается в РСУБД с гораздо меньшим расходом ресурсов G>>·>Это если всё влазит в рсубд. G>>РСУБД умеет работать ·>Ага. Но только мееедленно.
Тот же эластик не заработает вообще никак на 50ТБ данных, имея только 100гб ОП.
G>> когда объем данных значительно превышает объемы памяти. ·>elastic тоже.
Ему нужно будет в разы больше памяти. Рекомендуется 1:30 хранимых данных.
·>У меня совсем другой поинт был. Ну пусть диск. Объём диска на кластере всё равно может быть на много порядков больше, чем на сервере рсубд.
И?
Для СУБД нет разницы какой объем диска у тебя. Диск масштабируется значительно проще, чем проц и память.
·>Вспомни на чём выехал гугл — вместо супер-пупер дорогих серверов собирал кластеры на бросовом железе — кпд меньше, но мощность выше — тем самым обогнав по многим характеристикам существующие решения.
Я эту байку слышу постоянно, но чето все время вижу, как один тослтый сервак оказывается в разы дешевле, чем 3-4 сервера поменьше с такими же суммарными ресурсами.
Возможно раньше толстые серваки стоили настолько дороже серверов поменьше, что было реально выгоднее заниматься горизонтальным масштабированием.
Но сейчас, если ты не гугл или яндекс, ты вполне можешь для своих задач купить парочку толстых серваков, которые будут тебе все обрабатывать.
При грамотном использовании СУБД, возможно, и не очень толстые понадобятся.
Здравствуйте, gandjustas, Вы писали:
G>>>РСУБД умеет работать G>·>Ага. Но только мееедленно. G>Тот же эластик не заработает вообще никак на 50ТБ данных, имея только 100гб ОП.
Честно говоря не понимаю почему ты так решил? Думаю, заработает, только медленно.
G>>> когда объем данных значительно превышает объемы памяти. G>·>elastic тоже. G>Ему нужно будет в разы больше памяти. Рекомендуется 1:30 хранимых данных.
А рсубд вообще никак не заработает, т.к. столько памяти некуда в сервер воткнуть.
G>·>У меня совсем другой поинт был. Ну пусть диск. Объём диска на кластере всё равно может быть на много порядков больше, чем на сервере рсубд. G>И? G>Для СУБД нет разницы какой объем диска у тебя. Диск масштабируется значительно проще, чем проц и память.
Но тоже есть потолок, хоть и повыше.
G>·>Вспомни на чём выехал гугл — вместо супер-пупер дорогих серверов собирал кластеры на бросовом железе — кпд меньше, но мощность выше — тем самым обогнав по многим характеристикам существующие решения. G>Я эту байку слышу постоянно, но чето все время вижу, как один тослтый сервак оказывается в разы дешевле, чем
А что откажется дешевле 300-400 серверов?
G>3-4 сервера поменьше с такими же суммарными ресурсами.
И, кстати, ещё один важный момент — когда один из этих 4х серверов сломается, ты можешь неспешно его заменить и никто ничего не заметит. Когда сломается этот твой единственный сервер — сломается всё и надолго.
G>Возможно раньше толстые серваки стоили настолько дороже серверов поменьше, что было реально выгоднее заниматься горизонтальным масштабированием. G>Но сейчас, если ты не гугл или яндекс, ты вполне можешь для своих задач купить парочку толстых серваков, которые будут тебе все обрабатывать. G>При грамотном использовании СУБД, возможно, и не очень толстые понадобятся.
Ты так говоришь, будто эти все расходы тупо засовывают чтобы нарочно всё замедлить. Нет, эти расходы берутся из меж-серверного взаимодействия, а это меж-серверное взаимодействие позволяет повысить надёжность и на порядки улучшить мастшабируемость.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, gandjustas, Вы писали:
G>·>elastic тоже. G>Ему нужно будет в разы больше памяти. Рекомендуется 1:30 хранимых данных.
Да, кстати, это отношение рекомендуют для _горячих_ данных. Elastic может хранить какую-нибудь редкоиспользуемую байду и на диске.
Для рсубд это отношение будет ничем не лучше. А если ещё и FTS заюзать — то не удивлюсь если там 1:1 окажется внезапно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, fmiracle, Вы писали:
T>>Если под полнотекстовым поиском подразумевается лишь способность искать подстроку или комбинацию подстрок внутри документов, то с такой задачей прекрасно справляется и РСУБД. F>Под полнотекстовым поиском обычно подразумевается возможность быстро находить фразу внутри большого объема текстов (возможно — больших текстов), с учетом морфологии. Т.е. чтобы по вопросу "должник Иванов" нашлись документы с фразами F>- к должнику Иванову F>- от должника Иванова F>- должник Петр Иванов F>- с должника П.С. Иванова
Такая задача легко реализуется и в РСУБД. Сложнее, но тоже реализуется выдача на упомянутый запрос "должник Иванов" документа, в котором написано "... Иванова Ивана Ивановича, паспорт...., далее Заемщик...."
F>такого типа. Это не запрос классической реляционной алгебры
Что дает основание для столь смелого утверждения? Такой запрос как раз решается комбинацией из двух-трех операций реляционной алгебры.
F> а эластик — это специализированная БД для полнотекстового поиска.
Можно все-таки пример в студию запроса, который, в идеале, на Эластике решается, а в РСУБД — нет? Или хотя бы на Эластике решается измеримо эффективнее.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Titus, Вы писали:
T>>Может кто-то знает, в чем Эластик сильнее реляционной СУБД
G>Кроме того если вам нужны продвинутые возможности FTS, типа настройки релевантности, сложные полнотекстовые запросы, hit highlights, то эластик вам сможет помочь, а FTS в РСУБД — нет.
Здравствуйте, vsb, Вы писали: vsb>Я может что не понял, но ES это для поиска, а СУБД для хранения данных. Как их можно сравнивать? Или ты сравниваешь их типа в БД мы заюзаем FTS вместо ES? Ну так FTS убогий и его ни для чего полезного не хватит. Чисто для галочки сделать поиск, которым никто потом пользоваться не будет, ибо он что надо не находит, а что не надо — находит в изобилии. Этим страдают всякие интернет магазины, уже привычка искать сразу через гугл, а не через встроенный поиск.
Ну, давай РСДН возьмем. В чем кривизна его поиска, и как с этим лучше и прямее бы справился Эластик?
Здравствуйте, m2l, Вы писали:
m2l>Вот тебе ссылка:
я бы сказал спасибо за ссылку, если бы там хоть как то была упомянута РСУБД. Но о РСУБД не сказано ни слова.
m2l>Опустим тот момент, что FTS — это не LIKE, а ...
Давай не путать вопрос: "Что это?", и вопрос: "как, на твой взгляд, это реализуется?".
m2l> ...отдельные индексы, функции ... которые в реляционных базах побочная функциональность, а в эластике основная.
Э-э-э... отдельные индексы — побочная функциональность РСУБД? Смелое утверждение.
m2l> Если кратко и просто: масштабирование и репликация.
Не хочу вдаваться в споры о масштабировании. Меня интересует бизнес задача.
Можно конкретно: даст ли положительный эффект применение эластика вместо РСУБД на РСДН (здесь, я так понимаю, собрано несколько миллионов документов)? Если да, то почему и в чем это можно измерить?
Здравствуйте, vsb, Вы писали:
vsb> ...уже привычка искать сразу через гугл, а не через встроенный поиск.
Гугл с Яндексом однозначно выигрывают у РСУБД, и уверен на 99%, у Эластика тоже, в поисковых задачах. Фишка в том, что они не используют Эластик. Они используют свой AI & ML и свои закрытые базы знаний.
F>> а эластик — это специализированная БД для полнотекстового поиска.
T>Можно все-таки пример в студию запроса, который, в идеале, на Эластике решается, а в РСУБД — нет? Или хотя бы на Эластике решается измеримо эффективнее.
pivot faceting, давно не смотрел как они реализовали это в эластике — в SOLR работало здорово
То, что SOLR & Elastic умеют агрегировать из xml/json файла, предствалющего собой по сути таблицу, а не текст свободного формата — я знаю.
РСУБД такие операцию делают тоже и давно. Нет никаких оснований считать, что Эластик агрегирует лучше.
Из того что хуже. По опыту проекта, который меня коснулся: строили отчетность в Кибане, так вот объем занятого дискового пространства был в 10 раз больше, чем исходный объем на MySQL.
Здравствуйте, Titus, Вы писали:
T>То, что SOLR & Elastic умеют агрегировать из xml/json файла, предствалющего собой по сути таблицу, а не текст свободного формата — я знаю.
T>РСУБД такие операцию делают тоже и давно. Нет никаких оснований считать, что Эластик агрегирует лучше.
ХЗ, в свое время я не смог сделать в SQL аналога чтобы оно работало похоже и/или адекватно по скорости( лет 7 назад ), тогда выбрали SOLR как раз за возможности агрегирования
T>Из того что хуже. По опыту проекта, который меня коснулся: строили отчетность в Кибане, так вот объем занятого дискового пространства был в 10 раз больше, чем исходный объем на MySQL.
а почему в Кибане? почему не сразу из MySql если он имеет теже возможности?
а про объем — в MySQL у вас явно не было индексов по всем возможным полям
Здравствуйте, mogadanez, Вы писали:
M>Здравствуйте, Titus, Вы писали:
T>>То, что SOLR & Elastic умеют агрегировать из xml/json файла, предствалющего собой по сути таблицу, а не текст свободного формата — я знаю.
T>>РСУБД такие операцию делают тоже и давно. Нет никаких оснований считать, что Эластик агрегирует лучше. M>ХЗ, в свое время я не смог сделать в SQL аналога чтобы оно работало похоже и/или адекватно по скорости( лет 7 назад ), тогда выбрали SOLR как раз за возможности агрегирования
Так вот же он, тот долгожданный кейс, когда SOLR/Elastic круче РСУБД!!!
А можно поподробнее? Хотя бы структуры таблиц, которые участвовали в агрегации?
T>>Из того что хуже. По опыту проекта, который меня коснулся: строили отчетность в Кибане, так вот объем занятого дискового пространства был в 10 раз больше, чем исходный объем на MySQL. M>а почему в Кибане? почему не сразу из MySql если он имеет теже возможности?
Выбор не мой, но, у тех, кто выбирал, есть ответ на твой вопрос, всего одно слово: визуализация.
M>а про объем — в MySQL у вас явно не было индексов по всем возможным полям
Ну да, индексы — удовольствие дорогое. Их ставят только на нужные поля или их комбинации.
Здравствуйте, Titus, Вы писали:
T>я бы сказал спасибо за ссылку, если бы там хоть как то была упомянута РСУБД. Но о РСУБД не сказано ни слова.
Ну просто была надежда, что ты мог что-то знать про РСУБД.
T>Давай не путать вопрос: "Что это?", и вопрос: "как, на твой взгляд, это реализуется?".
Ок, FTS от MS SQL и MySQL по твоему эквивалентны по функциональности?
m2l>> ...отдельные индексы, функции ... которые в реляционных базах побочная функциональность, а в эластике основная.
T>Э-э-э... отдельные индексы — побочная функциональность РСУБД? Смелое утверждение.
Ок, ты не знаешь что такое FTS, а пытаешься набросить.
m2l>> Если кратко и просто: масштабирование и репликация.
T>Не хочу вдаваться в споры о масштабировании. Меня интересует бизнес задача.
T>Можно конкретно: даст ли положительный эффект применение эластика вместо РСУБД на РСДН (здесь, я так понимаю, собрано несколько миллионов документов)? Если да, то почему и в чем это можно измерить?
Свои "несколько миллионов документов" ты можешь просто в файловой системе хранить или в sqlite-е.
Вот, когда у тебя несколько триллионов документов, и они на один сервер не влезут — вот тут и будет положительный эффект. Измеряется он просто: с эластиком просто работает.
Понятно дело, что в священных войнах найдется индивид, имеющий склонность к тому, чтобы
m2l>Ну просто была надежда, что ты мог что-то знать про РСУБД. m2l>Ок, ты не знаешь что такое FTS, а пытаешься набросить.
оскорбить
m2l>Вот, когда у тебя несколько триллионов документов, и они на один сервер не влезут — вот тут и будет положительный эффект. Измеряется он просто: с эластиком просто работает.
и набздеть.
На конкретные вопросы отвечать, увы, не способный.
Здравствуйте, mogadanez, Вы писали:
M>>а про объем — в MySQL у вас явно не было индексов по всем возможным полям T>Ну да, индексы — удовольствие дорогое. Их ставят только на нужные поля или их комбинации.
Добавлю еще про объем.
Проект меня лишь касался, так что подробностей не знаю, но полагаю, что причина десятикратного увеличения занимаемого дискового пространства лежит в этом:
SQL-style joins are not supported in Elasticsearch as first-class citizens.
Because Elasticsearch is not a relational database, joins do not exist as a native functionality like in an SQL database. It focuses more on search efficiency as opposed to storage efficiency. The stored data is practically flattened out or denormalized to drive fast search use cases.
Здравствуйте, gandjustas, Вы писали:
G>·>Ага. Но только мееедленно. G>Тот же эластик не заработает вообще никак на 50ТБ данных, имея только 100гб ОП.
G>>> когда объем данных значительно превышает объемы памяти. G>·>elastic тоже. G>Ему нужно будет в разы больше памяти. Рекомендуется 1:30 хранимых данных.
