Андрей Григорьев eigrad

С помощью dynamic templates можно отключить индексацию для всех не заданных полей или по шаблону — https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic-templates.html.

Но какой смысл в эластике, если не индексировать поля? Как хранилище он не эффективен, проще монгу взять.

Было бы интересно почему ты пришел к выводу, что я быдло, но не вижу смысла продолжать дискуссию, потому что ты ещё в предыдущих сообщениях успел доказать то что твое слово ничего не стоит, а мнение подкрепляется личными эмоциональными фантазиями.

Как вам идея написать небольшой пост по выбору и настройке железа/ОС для систем аналитики?) Эти советы не только для ClickHouse актуальны :-).

Сколько места для сборки release нужно?) Случайно забил все 10G в /home совмещенном с / :-).

Будут ли пакеты для xenial?

Не нужно использовать 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'ом по скорости, не знаю как они это делают, ну не хранят агрегаты же? :-)

Gitlab — просто вау, уважуха.

Вау было когда появился docker-образ для Omnibus Gitlab.

Вау было когда они интегрировали Gitlab CI прямо в Gitlab.

В этом релизе куча вкусных плюшек, но главное вау имхо — интегрированный docker registry. Контроль доступа к docker registry через группы в gitlab это просто мечта :-). Пробовал portus от команды SUSE — сырая недоделка. Пришлось вернуться управление htpasswd вручную. Вышел Gitlab 8.8 и через день мы перенесли registry туда, класс.

Просто ад, писать «Контейнер реестра GitLab» про интегрированный Docker Registry. Я за бан.

Google Translate??? Ужас какой.

Кажется вы переизобретаете 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. В итоге используем что-то другое, но этот вроде неплохо работал.

Feedback welcome.

Ничего ведь не мешает вынести postgres в отдельный контейнер?..

> толпа «олимпиадников»

откуда бы ей тут взяться))

И это, не юзайте костыль с подключением нескольких дисков в один PV. Или включайте NOOP scheduler хотя бы тогда…

Ничего не хочу сказать про VMware, кроме того что у них хороший гуй. И производительность на уровне VirtualBox.

> Хотя при работе с highload-проектами адреналина всё равно выделяется достаточно, чтобы 10 раз подумать, перед тем, как что-либо делать.

Чо там думать — отключил сервак от балансера, поресайзил что надо, включил обратно. Не можешь отключить — к тебе по любому придет северный пушной зверек, можешь одевать белые тапочки и топать куда-нибудь, ресайз раздела тут не поможет.

Можно линк на баг?..

Чот вы прям меня даже в сомнения вогнали. Уже два года как увеличение томов в KVM работает онлайн без регистрации и СМС^W в смысле без перезагрузки и даже без LVM :-). Только что проверил, все работает ок.

На хосте — virsh vol-resize, virsh blockresize, на виртуалке — fdisk, resize2fs.

Вот, например, мануал — website-humblec.rhcloud.com/is-it-possible-to-do-online-resizing-of-guest-block-devices-or-without-shutdown/.

Комменты можно перефразировать так: «в моей системе раздачи контента AMQP не нужен».

Ну да. Если задача стоит в пересылке данных, то пересылать данные дополнительно через AMQP смысла нет. Но статья же не про это.

Хотя оверхед на AMQP вообще-то меньше чем на HTTP.

ps. 10гбит трафика — «распределенка и highload»?.. Ребята из Netflix на YaC'е рассказывали что у них по 40гбит с ноды отдается… :-)

Ты б хоть пост прочитал. Куда надо уже обратились, но нужны были добровольцы в помощь.

Занятно что на хабре даже в технических постах находится куча народу, кто читает только заголовок статьи и сразу идет выражать в комментарии свое мнение. Фу таким быть.

Блог на Хабре — самый эффективный ресурс Яндекса в плане обращения к IT-сообществу. То что этот топик тут разместили говорит о многом.

А если кому-то эта тема кажется к IT-сообществу не относящейся, то имхо скорее этот кто-то сам к IT-сообществу не относится.

Если есть расширение, то зачем отдельный сайт?.. Было бы удобнее, если бы оно само встраивалось в плееры других сайтов.

Но статья в целом отличная.

задать таблице FORWARD действие REJECT по умолчанию

REJECT — расширение, его нельзя задать по-умолчанию, только DROP, ну или как ты написал — последним правилом в таблице

Думаю на Mac он перешел именно с него.

Ха! Game Maker! А я всю игру гадал на чем визуализатор сделали :-). Класс!

В статье не хватает только ссылки на исходники сайта и призыва слать pull-request'ы на Github.

Это просто мега-круто что у нас наконец есть свой PyCon :-). И то что Екатеринбург в очередной раз на острие экшна.

А фотки во ВКонтакте и Facebook выложите?