Если говорить про удобные и эффективные форматы, то у Druid'а есть WOW-фича — указываешь ему класс со структурой Protobuf, и он читает данные через неё. Сложно ли будет вкрутить подобную функциональность в clickhouse-client?
С помощью dynamic templates можно отключить индексацию для всех не заданных полей или по шаблону — https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic-templates.html.
Но какой смысл в эластике, если не индексировать поля? Как хранилище он не эффективен, проще монгу взять.
Было бы интересно почему ты пришел к выводу, что я быдло, но не вижу смысла продолжать дискуссию, потому что ты ещё в предыдущих сообщениях успел доказать то что твое слово ничего не стоит, а мнение подкрепляется личными эмоциональными фантазиями.
Не нужно использовать Elasticsearch как замену RDBMS, join'ы через parent-child там сделаны весьма спорно — весь словарь связей parent-child всегда хранится в памяти, целиком. Плюс с шардированием есть ньюансы.
Если говорить про аналитику, то в OLAP-топологии звезда Elasticsearch применим. Но в общем случае, хотите реляционку — возьмите реляционку.
А я не заметил ни одного повода общаться с тобой на вы. Твое предложение мне не интересно — моя оценка это то что у меня реально на серверах происходит, а твоя оценка полностью описывается твоей фразой:
> У меня нет ни лишнего времени, ни лишней сотни гигабайт на SSD, чтобы провести описанный эксперимент с ES. Буду рад, если вы это сделаете хотя бы с той парой запросов, что я написал. Ставлю 10 к 1, что ES будет быстрее раз в 5.
Не видел предмет разговора в жизни, а лезешь к взрослым дядькам с советами. Фу таким быть.
Выбрали эластик многим причинам (низкий порог вхождения, функциональность, автогенерация схемы, и т.п.), druid пока только тестим, для своих задач он хорош.
Пока нужные для запросов индексы в эластике влезают в оперативку — скорость выполнения аггрегаций в ES сравнима с выполнением запросов в Druid (где-то может быть хуже на порядок, а где-то даже лучше, зависит от данных и от запросов). Если данные не входят в оперативку, но лежат на SSD — у ES всё становится на порядок медленнее, как деградирует Druid мы пока не тестили, но есть подозрение что у него дела будут лучше.
Druid хорош тем, что он хранит собственно только данные необходимые для построения аггрегаций по заранее заданным измерениям и метрикам, и делает это эффективно. Собственно он создан для OLAP, ничего большего чем эффективно строить агрегации с его помощью не сделать, да и не нужно. У ES гораздо больше оверхед на размер индексов, следовательно большой объем данных потребует большего количества железа.
В нашем кейс — есть возможность снизить объем данных в ES с 2-3Тб в месяц до 100Гб в месяц. А по тем данным, которые в ES заливать не будем — достаточно Druid.
Эластик нам скорее всего будет нужен даже если основной объем данных перельем в clickhouse, так как пока не совсем понятно сможем ли на clickhouse'е реализовать некоторые свои потребности. Основное — span-запросы, мы через них делаем behaviour-matching. Ну и в паре мест fulltext-индексы нам тоже нужны. Но как хранилище и возможность исполнять sql-like запросы над полными данными clickhouse для нас может стать панацеей :-).
То есть ты не из практического опыта исходишь, а из бенчмарков версий которые даже не RC?) По бенчмаркам стабильных версий моя оценка справедлива. n-граммы добавят процентов 10-15% времени, но на этих данных они не нужны :-).
В чем загнул? Пара гигабайт против 60 гб тут. На вышеприведенном конфиге можно примерно на 15к/с рассчитывать. 150кк документов — 10000 секунд, почти 3 часа.
Будет 3-4 часа на загрузку (на 2×E5-2630v3, 64Gb RAM, 2xSSD), но на запросы он должен по-шустрее clickhouse'а отвечать. Надо тестить… Но мы скорее будем на своих Едадиловских данных тестить clickhouse, потом с текущим эластиком сравнивать. Эластик на наши запросы, если данные на SSD или в оперативке, отвечает сравнимо с Druid'ом по скорости, не знаю как они это делают, ну не хранят агрегаты же? :-)
Вау было когда появился docker-образ для Omnibus Gitlab.
Вау было когда они интегрировали Gitlab CI прямо в Gitlab.
В этом релизе куча вкусных плюшек, но главное вау имхо — интегрированный docker registry. Контроль доступа к docker registry через группы в gitlab это просто мечта :-). Пробовал portus от команды SUSE — сырая недоделка. Пришлось вернуться управление htpasswd вручную. Вышел Gitlab 8.8 и через день мы перенесли registry туда, класс.
Кажется вы переизобретаете graylog. Но в нем тоже не хватает части, которая будет следить за типами полей.
когда у вас относительно много данных (скажем, 500G), то ваш Elasticsearch после запуска будет еще около получаса просасывать эти данные
320Гб, 1 минута 13 секунд:
[ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
→ du -sh /var/lib/elasticsearch
320G /var/lib/elasticsearch
[ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
→ docker kill compose_elasticsearch_1
compose_elasticsearch_1
[ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
→ docker start compose_elasticsearch_1
compose_elasticsearch_1
[ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
→ time (while [ `http :9200/_cluster/health | jq .status` != '"green"' ]; do sleep 1; done)
( while [ `http :9200/_cluster/health | jq .status` != '"green"' ]; do; sleep) 12,67s user 0,94s system 18% cpu 1:12,43 total
Это с дефолтным "cluster.routing.allocation.node_initial_primaries_recoveries: 4". Если у вас SSD — можно увеличить хоть до 1000. Но лучше уменьшить количество индексов и шардов.
Вот геокодер на ElasticSearch, написанный на коленке для одного из проектов: github.com/ei-grad/geocoder. В итоге используем что-то другое, но этот вроде неплохо работал.
Но какой смысл в эластике, если не индексировать поля? Как хранилище он не эффективен, проще монгу взять.
Будут ли пакеты для xenial?
Если говорить про аналитику, то в OLAP-топологии звезда Elasticsearch применим. Но в общем случае, хотите реляционку — возьмите реляционку.
> У меня нет ни лишнего времени, ни лишней сотни гигабайт на SSD, чтобы провести описанный эксперимент с ES. Буду рад, если вы это сделаете хотя бы с той парой запросов, что я написал. Ставлю 10 к 1, что ES будет быстрее раз в 5.
Не видел предмет разговора в жизни, а лезешь к взрослым дядькам с советами. Фу таким быть.
Пока нужные для запросов индексы в эластике влезают в оперативку — скорость выполнения аггрегаций в ES сравнима с выполнением запросов в Druid (где-то может быть хуже на порядок, а где-то даже лучше, зависит от данных и от запросов). Если данные не входят в оперативку, но лежат на SSD — у ES всё становится на порядок медленнее, как деградирует Druid мы пока не тестили, но есть подозрение что у него дела будут лучше.
Druid хорош тем, что он хранит собственно только данные необходимые для построения аггрегаций по заранее заданным измерениям и метрикам, и делает это эффективно. Собственно он создан для OLAP, ничего большего чем эффективно строить агрегации с его помощью не сделать, да и не нужно. У ES гораздо больше оверхед на размер индексов, следовательно большой объем данных потребует большего количества железа.
В нашем кейс — есть возможность снизить объем данных в ES с 2-3Тб в месяц до 100Гб в месяц. А по тем данным, которые в ES заливать не будем — достаточно Druid.
Эластик нам скорее всего будет нужен даже если основной объем данных перельем в clickhouse, так как пока не совсем понятно сможем ли на clickhouse'е реализовать некоторые свои потребности. Основное — span-запросы, мы через них делаем behaviour-matching. Ну и в паре мест fulltext-индексы нам тоже нужны. Но как хранилище и возможность исполнять sql-like запросы над полными данными clickhouse для нас может стать панацеей :-).
Вау было когда появился docker-образ для Omnibus Gitlab.
Вау было когда они интегрировали Gitlab CI прямо в Gitlab.
В этом релизе куча вкусных плюшек, но главное вау имхо — интегрированный docker registry. Контроль доступа к docker registry через группы в gitlab это просто мечта :-). Пробовал portus от команды SUSE — сырая недоделка. Пришлось вернуться управление htpasswd вручную. Вышел Gitlab 8.8 и через день мы перенесли registry туда, класс.
320Гб, 1 минута 13 секунд:
Это с дефолтным "cluster.routing.allocation.node_initial_primaries_recoveries: 4". Если у вас SSD — можно увеличить хоть до 1000. Но лучше уменьшить количество индексов и шардов.
Feedback welcome.
откуда бы ей тут взяться))