го для грустных :(

ахаххахахаха

го для грустных :(

спешл фо ю

Ска квис вездесущий

?

могу себе позволить)

?

я старался))

Посмотрите на пример - https://play.golang.org/p/f_9E0egbI8 и скажите, если результат работы foo и baz одинаков, то не имеет разницы какой из них выбрать?

ну первое меня смущает

у тебя внутри уже по ссылке

и ты ссылку у ссылки берешь, это нужно?

или как правильно сказать )

2 это фича го и ее нужно использовать

то есть второй вариант предпочтительнее

понял, спасибо

и ты ссылку у ссылки берешь, это нужно?

я не беру ссылку, а обращаюсь к элементу

и ты ссылку у ссылки берешь, это нужно?

в сях это назвали бы разыменовыванием указателя

точно

я на сях со времен техникума не писал )

В статье про 50 оттенков дан пример - https://play.golang.org/p/lQRiRxRYx0 сейчас выводит 0, у автора статьи старая версия компилятора была?

немного офтопик, clickhouse.yandex ктонить пользовался? или может какой канальчик есть у них?

немного офтопик, clickhouse.yandex ктонить пользовался? или может какой канальчик есть у них?

пользовался, нравится

пользовался, нравится

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

Или в статье ошибка или поправили в компиляторе, вот небольшой пример https://play.golang.org/p/jLoQD4UXgW

В статье про 50 оттенков дан пример - https://play.golang.org/p/lQRiRxRYx0 сейчас выводит 0, у автора статьи старая версия компилятора была?

В статье про 50 оттенков дан пример - https://play.golang.org/p/lQRiRxRYx0 сейчас выводит 0, у автора статьи старая версия компилятора была?

интересно, да

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

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

у меня раз в 5 минут подготовка csv и заливка в БД, мне не нужен реалтайм

поищи доклад с хайлоада второй день, там про реалтайм были ответы

в целом возможно, но смысла мало

поищи доклад с хайлоада второй день, там про реалтайм были ответы

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

объем большой?

у них реалтайм можно, просто есть потолок

объем большой?

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

гиг в сутки потянет

гигабайт - это вообще ни о чем

там потолок на порядки выше )

на сколько порядков?

господа, меня смущает реалтайм. так-то я не боюсь

100GB - это все еще ни о чем

что такое realtime

давайте не про байты, а про строки

сколько строк в этом гигабайте?

Статья 2015-04-10, скорее в компиляторе изменили

это значит пользователЬ сделал действие нам приехала строка. об этом тут же видно в отчете, сразу.

так сколько строк в секунду?

и что за агрегация?

и сколько пользователей, кстати

не вспомню насколько, видео уже удалили, эх

агрегация - сводный отчет по некоторым параметрам этих действий, сервис будет воткнут как накладка на существующие сервисы с милионной проходимостью. статистику более детальную нам сейчас собирают РМ-ы по теоретической проходимости, мы подписались на то что гигабайт этих самых действий мы провернем, исходя из двух млн+ хитов в сутки, это порядка 25-30 запросов в секунду

https://www.youtube.com/watch?v=AXSQbV8Zhvg

спасибо Егор )

сейчас скажу время

https://www.youtube.com/watch?v=AXSQbV8Zhvg

спасибо

part2 надо

эх, нет его )

Я думаю в течении недели-двух выложат на просторах, около 1000 человек смотрело

немного офтопик, clickhouse.yandex ктонить пользовался? или может какой канальчик есть у них?

в церкви метрик (https://telegram.me/metrics_ru) есть разработчик (Alexey Milovidov)

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

База делалась под задачи Яндекс.Метрики - там сотни тысяч инсертов в секунду. И оптимизация под то что в одном инсерте будет много строк.

условно

ERROR: S client not available

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

поэтому если хочется писать сразу много - то имеет смысл агрегировать их

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

если инсертов в целом мало - то можно и по одной

агрегация - сводный отчет по некоторым параметрам этих действий, сервис будет воткнут как накладка на существующие сервисы с милионной проходимостью. статистику более детальную нам сейчас собирают РМ-ы по теоретической проходимости, мы подписались на то что гигабайт этих самых действий мы провернем, исходя из двух млн+ хитов в сутки, это порядка 25-30 запросов в секунду

Агрегируйте по какой-то малозаметной для вас (просматривающих отчет) пачке данных и все будет хорошо.

то есть если смотрит человек - то есть какой то предел реакции - делайте инсерты раз в 200-300 мс того что накопилось, будет незаметно на глаз и при этом не по одной записи

например

База делалась под задачи Яндекс.Метрики - там сотни тысяч инсертов в секунду. И оптимизация под то что в одном инсерте будет много строк.

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

также и для мониторинга - если будет polling то он будет раз в какое-то время - вот 0.5*время_поллинга и возьмите как период обновления.

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

зачем кидать куда-то?

200-300 мс не нужно наверное, как я понимаю. во-первых пока ориентир 30 запросов в секунду, а это больно дорого получится. два-три раза в минуту и норм я думаю. метрика же тоже не моментально отрабатывает и ничо, никто не помер от такой дельты.

в памяти держать

200-300 мс не нужно наверное, как я понимаю. во-первых пока ориентир 30 запросов в секунду, а это больно дорого получится. два-три раза в минуту и норм я думаю. метрика же тоже не моментально отрабатывает и ничо, никто не помер от такой дельты.

30 запросов в секунду это как-то не о чем кажется. У яндекс.метрики до показа данных пару лет назад задержка была поярдка 60-65 секунд и обуславливалась тем что логи чаще не доставлялись, а не базой или еще чем-то

30 запросов в секунду вам не напрягшись сагрегирует мускул

в памяти держать

я жмот, памяти жалко. хотя там вроде будут толстые сервера под это всё.

я из мускула до 100К ups получал

и вероятно это уже поправили

я из мускула до 100К ups получал

это да, но нет никакого настроения потом всё переделывать + есть желание погрейдиться. это можно?

я из мускула до 100К ups получал

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

на rdbms что угодно лучше реализовывать, если она тянет

на rdbms что угодно лучше реализовывать, если она тянет

почему? )

по опыту :)

на самом деле - реляционная модель показала себя наиболее гибкой

все остальные модели с легкостью в нее мапятся

на самом деле - реляционная модель показала себя наиболее гибкой

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

не очень я понимаю, о чем речь

group by реализует любой обвес, тащемта

group by реализует любой обвес, тащемта

О том что в БД под аналитику есть соотвествующая готовая математика.

зачастую еще оптимизированная

а