подскажите, есть int64 в нем timestamp с точностью до миллисекунд, надо экспортить в CSV, как сконвертить timestamp в ISO 8601 с точностью до миллисекунды?

подскажите, есть int64 в нем timestamp с точностью до миллисекунд, надо экспортить в CSV, как сконвертить timestamp в ISO 8601 с точностью до миллисекунды?

ребят, вопрос не по теме, слышал что Яндекс балуется с ClickHouse в porto, есть какой то чатик про porto или можно кого то попинать, есть пару вопросов

В порту - это в Португалии?

https://github.com/yandex/porto

Благодарю

lxc еще тот лисапед

У нас lxd неплохо себя в проде чувствует

В чём профиты?

Уж больно похоже на lxc/lxd

У нас lxd неплохо себя в проде чувствует

смотря с чем сравнивать

Фряшные джейлы не умеют oracle java в первую очередь, ну и до кучи ещё много чего. Корректней рассматривать linux-окружение

Докер, например. Или я совсем мимо?

У нас lxd неплохо себя в проде чувствует

почему не lxc? объем багов lxd пугает, issue с гитхаба

lxc пока что самое дно из всех существующих контейнеризаций хотя порто не трогал

системных то всего 3 )

почему не lxc? объем багов lxd пугает, issue с гитхаба

что вам дает oracle java ?

issue - не показатель. lxd оказался удобней в обращении

требуется софту, на openjdk не запускается

lxc пока что самое дно из всех существующих контейнеризаций хотя порто не трогал

ок, а что не дно ?

в каком смысле "системных" ?

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

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

1.8 всё ещё не запускается на openjdk-8

во первых есть разные сторейджы во вторых есть тесты в третьих всмысле отвалился? migrate не вызвали? или что?

не определялся как существующий, zfs

пробывали хоть ?

У нас lxd неплохо себя в проде чувствует

мб всеже при обновлении забыли сделать migrate? и стоит разбираться с пулом что там пошло не так при откате должно было все вернуться

у нас тоже lxd в проде неплохо летает)

я только процитировал пачку ишью у людей)

openvz

openvz

тот который 7й?)

сомнительно как-то

да я не видел пока версий чтобы не уделывало lxc 7 в том числе

ничего сомнительного те фишки что есть в openvz очень как-то долго идут до lxc

ничего сомнительного те фишки что есть в openvz очень как-то долго идут до lxc

приведете пример ?

попробуйте ограничить контейнер по памяти, и запустить ресурсоемкое приложение, которое ее сьест в lxc

без всего

как можно то, смысл то какой тогда

попробуйте ограничить контейнер по памяти, и запустить ресурсоемкое приложение, которое ее сьест в lxc

второе, без всяких lxcfs поддерживает неймспейсинг RAM, CPU, SWAP

ну так там патчи на ядро для этого, не особо аргумент

что делаете ? по памяти пытаетесь выйти за пределы ?

в lxc докер пробывали запускать?)

в lxc докер пробывали запускать?)

Нужно потыкать nested - и вперед

ну так там патчи на ядро для этого, не особо аргумент

А какой смысл ограничивать ресурсы контейнеру КХ? Типа запустить на тачке КХ и еще что-то?

изолировать нескольно инстансов к примеру

типа два КХ на одной железке? Нафига?

Всем привет. Помогите, пожалуста. Имеются таблицы вида: CREATE TABLE data.user_contacts ( date UInt32, user_id UInt32, site_id UInt32, timespan_start UInt32, timespan_end UInt32, timestamp_start DateTime, timestamp_end DateTime, date_day Date MATERIALIZED toDate(concat(substring(toString(date), 1, 4), '-', substring(toString(date), 5, 2), '-', substring(toString(date), 7, 2)))) ENGINE = MergeTree PARTITION BY (date_day, site_id) ORDER BY (date_day, site_id, timespan_start, timespan_end) SETTINGS index_granularity = 8192 CREATE TABLE data.events ( event_id String, site_id UInt32, date UInt32, timestamp_start DateTime, timestamp_end DateTime, quantity UInt32, total_event_id_duration UInt32, event_duration Int32 MATERIALIZED timestamp_end - timestamp_start, date_day Date MATERIALIZED toDate(concat(substring(toString(date), 1, 4), '-', substring(toString(date), 5, 2), '-', substring(toString(date), 7, 2)))) ENGINE = MergeTree PARTITION BY date_day ORDER BY (date_day, site_id, timestamp_start, timestamp_end, event_id) SETTINGS index_granularity = 8192 И запрос: SELECT event_id, user_id, date_day, event_duration, least( timestamp_end, timestamp_end_event )- greatest( timestamp_start, timestamp_start_event ) AS intersected_duration, total_event_id_duration FROM data.user_contacts ALL INNER JOIN( SELECT events.event_id, events.site_id, events.date_day, events.quantity, events.timestamp_start AS timestamp_start_event, events.timestamp_end AS timestamp_end_event, event_duration, total_event_id_duration FROM data.events ) events USING( date_day, site_id ) WHERE date_day BETWEEN '2017-01-01' AND '2017-01-31' AND timestamp_start < timestamp_end_event AND timestamp_start_event < timestamp_end Проблема заключается в большом потреблении оперативной памяти Для справки: 1) ClickHouse server version 1.1.54380. 2) Данных в таблице data.user_contacts намного больше, чем информации в data.events 3) Индексы по непонятной причине используются только для ограничения data.user_contacts по датам и не участвуют в join 4) Пробовал создавать и такой индекс: (date_day, site_id) - результат не отличается от п.3 Подскажите, пожалуйста, как максимально эффективно соединить 2 таблицы по пересекающимся временным интервалам?

Мускуль легко масштабируется на чтение. Добавьте n слейвов