Спасибо, тогда везде буду uint

Может нам собраться , посидеть где нить? )

пиво, девочки)

Может быть можно будет сделать митап + afterparty. Не знаю, входит ли это в программу наших мероприятий.

Кстати, может сделать хакатончик?

Тоже вариант. Какие темы?

что нибудь прогрессивное ) чтобы на хабре потом написать ))

перенос кх в аркадию отличная тема для хакатона

Есть минимум 2 пути: 1. запилить какую-нибудь крутую feature для CH 2. сделать классный сервис over CH (например, что-нибудь аналитическое на базе данных Метрики или AppMetrica)

не... надо что поинтереснее )

Кстати, а GraphiteMergeTree может быть ReplicatedGraphiteMergeTree?

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

перенос кх в аркадию отличная тема для хакатона

Что такое аркадия?

исходники поискового движка

яндекса )

Кстати, а GraphiteMergeTree может быть ReplicatedGraphiteMergeTree?

Да.

А как пользоваться секцией macros?

Ребята, а когда будет митап в Украине?)

А как пользоваться секцией macros?

<macros> <layer>stat</layer> <shard>01</shard> <replica>example01-1.yandex.ru</replica> </macros> ... CREATE TABLE ... ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/visits', '{replica}', ...

Ребята, а когда будет митап в Украине?)

Скорее всего, в начале лета.

<macros> <layer>stat</layer> <shard>01</shard> <replica>example01-1.yandex.ru</replica> </macros> ... CREATE TABLE ... ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/visits', '{replica}', ...

я скорее не понимаю в каком месте его пихать?

У нас используются для аргументов Replicated таблиц - чтобы выбрать путь в ZK.

<remote_servers> <something> <shard> <macros> ?

В конфиге написано: <macros incl="macros" optional="true" /> Значит либо в /etc/metrika.xml в элемент macros на верхнем уровне, либо прямо в config.xml на это место.

Для каждого сервера свой /etc/metrika.xml и там свои значения macros.

ок... и нумерация шардов будет сделана автоматом в порядке как они в конфиге?

Что значит нумерация шардов?

OPTIMIZE OPTIMIZE TABLE [db.]name [PARTITION partition] [FINAL] Просит движок таблицы сделать что-нибудь, что может привести к более оптимальной работе

Это шикарная дока.

Что значит нумерация шардов?

да мне объяснили что макрос нужен на каждом сервере свой

Алексей добрый день. Хотел у вас поинтерисоваться если это не секрет. Как в UI так быстро в режиме реал тайм отображаете данные? Например у нас до кх вся статистка лежала в mysql. Мы сделали консольную команду которую повесили на cron она делает ряд запросов на агрегированние подсчет данных из статистики и кладет в оперативную память. а мы на ui видим сразу, но памяти жрет много. Тут вариантов пару либо отказаться от кеша и делать запросы на прямую к кх. либо в кеш писать только по запросу - пользователь авторизовался получил свою пачку данных (срок жизни кеша ограничен - при неактивности больше n часов кеш очищается). В идеале хотелось бы реал тайм. Может какие нибудь рекомендации дадите?

Отвечу в основном чате.

В Метрике кэш для отчётов не используется, запросы идут считать всё заново из неагрегированных данных.

Работает хорошо почти во всех случаях. Но для крупных счётчиков приходится включать сэмплирование по-умолчанию. Пользователь может изменить сэмплирование (например, выключить) - тогда отчёт грузится дольше.

Есть другие проекты, где кэш используется.

В Метрике кэш для отчётов не используется, запросы идут считать всё заново из неагрегированных данных.

то есть в метрике результат получается на запрос к кх напрямую? у нас ситуация следующая - на главной странице есть около 5 графиков - для получение данных для них посылается 5 разных запросов в одну таблицу (например нужно узнать сколько кликов суммарно осуществилось для определенной сущности - например в рамках страны или городов). Если брать небольшой диапазаон в рамках одного пользователя и недельные данные то эти 5 запросов вложаться (я думаю) в секунду. если пользователь выберет весь период - например за год результат может быть получен и за секунд 5-10. соответственно это уже задержка. или это норма?

поэтому мы и прикрутили кеш в памяти. и получаем результаты данных моментально. но он конечно затратные на его заполнение и жрет памяти

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

И скорее всего, не только кэшировать, но и обновлять асинхронно.

нет. графики только в рамках аудентификации. в рамках юзера

ну тогда можно попробовать прикрутить праймери кей на user_id и по нему выбирать точечно по запросу

потому как сейчас мы не по user_id выбираем а по всем запускам показов

и получаем данные всех пользователей

Да. Подумайте, поэкспериментируйте.

мне понравилась таблица memory. жалко нельзя установить срок жизни данных

можно было бы как-то переливать туда данные и брать с неё

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

и я так понял вылазит киллер и начинает килять что попало вот и расыпается

Всё верно. По-умолчанию лимит оперативки - 10 GB на каждый запрос.

понял спасибо алексей вы как всегда выручаете )

Я тоже ронял запросами CH, хотелось бы чтобы умирал не сервер, а запрос

Тоже вариант. Какие темы?

Я бы предложил что-нибудь не смежное с кликстрим. Я не теряю надежду использовать КХ в других вариантах ?

в admin tips-ах есть такая фраза "Use Linux software RAID (mdadm). Better to not use LVM." Кто-то знает, почему LVM не люб и на сколько это критично?

в admin tips-ах есть такая фраза "Use Linux software RAID (mdadm). Better to not use LVM." Кто-то знает, почему LVM не люб и на сколько это критично?

Я предполагаю, что это чтобы не было соблазна использовать Snapshot'ы которые в LVM сделаны отвратительно и очень сильно просаживают скорость работы

А без snapshot'ов смысл в LVM околонулевой

ну... спорное утверждение

я вот давно и успешно его использую начиная еще с Unix-ов (HP-UX, Solaris) и пока не довелось пользоваться снапшетами

и пользу в нем вижу

но сейчас вопрос не о том немного

если использовать LVM для создания RAID-10 без всяких снапшетов, это все еще "лучше не надо" для CH?

я вот давно и успешно его использую начиная еще с Unix-ов (HP-UX, Solaris) и пока не довелось пользоваться снапшетами

Snapshot'ы там просаживают скорость записи и чтения до печальных значений чуть чаще чем всегда

не планирую я испоьзовать эту фичу

raid на базе LVM в Linux'ах реализован странно и как бы при наличии в ядре mdadm в нем нет никакого смысла

просто для гибкой организации и управления пространстовм

да, все это про Linux, на Солярке может все отлично

просто для гибкой организации и управления пространстовм

обычно 1 сервер под 1 задачу, там в таком смысла мало )

обычно да

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

но даже одна задача (продукт) может состоять не нескольких потребителей

Разносить их по разным разделам?

Точно в этом есть смысл?

когда БД поддерживает разные базы и права доступа к ним

Опять же проще по серверам делить, если все так критично

иметь возможность гибко выделять дисковое пространство по мере роста, иметь возможность разедилить (перераспределить) в дальнейшем по шпинделям и т.п.

да меня не надо убеждать, что лучше выделенные сервера иметь

я все сам понимаю

но есть теория и проекты в которых есть возможность это сделать, а есть другие варианты

иметь возможность гибко выделять дисковое пространство по мере роста, иметь возможность разедилить (перераспределить) в дальнейшем по шпинделям и т.п.

КХ на сложные запросы в том числе может и ЦПУ и Оперативку подъесть немного, поэтому обычно мало смысла ставить больше 6-и дисков (можно конечно, особенно если диски небольшие, но под нагрузкой может уже захотеться больше цпу), а КХ умеет права доступа сам, поэтому под него в этом смысл примерно нулевой

ладно, в общем спасибо за ваше мнение

@lexa_work если что, мое мнение составлено по моим наблюдениям, а не официальное ) может товарищи яндексоиды что-то еще скажут

если появится кто-то, кто знает точно зачем и почему фраза эта появилась в типасх, то буду рад услашать пояснения

но как по мне просто чтоб не повадно было снэпшотить, проще сказать что не используйте LVM чем отвечать на вопросы "почему у меня все тормозит?"

ну тогда нужно было еще добавлять подобные фразы про NFS-ы и т.д и т.п.

Оффтоп. Сейчас на митапе Заббикса Владышев сказал, что общался с командой CH на конфе Перконы ~1 год назад. И сказал, что отказался от интереса в эту сторону после озвученных концептуальных проблем. Возможно сейчас всё изменилось (с)

А что за проблемы там?

Менеджерский аргумент

ну тогда нужно было еще добавлять подобные фразы про NFS-ы и т.д и т.п.

swraid я думаю это предполагает ;)

swraid я думаю это предполагает ;)

не понял мысль

не понял мысль

отсутствие NFS'ов всяких )

не понял мысль

mdadm и вообще swaid немного проблематично сделать без блочного устройства

то есть "мы рекомендуем swraid" означает по сути локальные диски или iscsi

ну я это понял как: "не обязательно использовать дорогие аппаратные RAID контроллеры"

ну и эта фраза как бы подтверждает "Prefer more servers with inplace storage to less servers with huge disk shelves."

это подход типичный для BigData решений

JBOD и/или софтовый RAID + репкликация прикладного уровня

да, именно так

Оффтоп. Сейчас на митапе Заббикса Владышев сказал, что общался с командой CH на конфе Перконы ~1 год назад. И сказал, что отказался от интереса в эту сторону после озвученных концептуальных проблем. Возможно сейчас всё изменилось (с)

Ну если будет летом обещанный рест, то можно начать складывать холодные данные в CH