×Закрыть
TechLead в MGID
  • Наш опыт внедрения ClickHouse — аналитической CУБД

    tabix.io/doc/Install

    этот

    tabix.io/doc/Server/Install

    возможно или прошлая версия, или что-то еще, уже и реп таких не вижу

  • Наш опыт внедрения ClickHouse — аналитической CУБД

    не вижу данного текста здесь tabix.io/doc/Install , давно используем, все ок

  • Наш опыт внедрения ClickHouse — аналитической CУБД

    Точно не скажу, тестировал таки не я.
    После внедрения CH, ребята также провели тесты для сравнения, и на сколько я знаю то основные минусы были:

    • на конкретном тестируемом примере получалось медленнее чем в CH;
    • стоимость превышала аренду серверов для CH.

    При наличники, к тому времени, готовых наработок по CH, которые решают наши проблемы, сильно копать в сторону BQ уже не стали.

  • Наш опыт внедрения ClickHouse — аналитической CУБД

    запущен, но «на все 100» не используем

  • Наш опыт внедрения ClickHouse — аналитической CУБД

    В таком направлении не думали. Бегло просмотрел сайт, стоящая штука?

  • Наш опыт внедрения ClickHouse — аналитической CУБД

    На том этапе были проблемы как с «естественными» ключами, так и с «суррогатными», в нашем случае автоинкремент.

    Был, например, кейс с таблицей, которая хранит лог неких событий клиента, которые могут потом дополнятся информацией. Записей не предполагалось очень много, был выбран автоинкрементный PK.
    Спустя некоторое время, сегмент бизнеса сильно вырос, и мы внезапно уперлись в максимальное значение PK. Таблица к тому времени была довольно большая, и у DBA как раз таки были проблемы с переводом ее на «естественный» ключ.

    Правда в достижении лимита PK также сыграл метод обновления записей:
    INSERT ON DUPLICATE KEY UPDATE
    Попытка INSERT выполняется раньше, чем UPDATE. Потому MySQL увеличивал счетчик автоинкремента, хоть потом и обновлял существующую запись.

  • Наш опыт внедрения ClickHouse — аналитической CУБД

    Спасибо за комментарий.

    В нашем случае небольшая потеря данных не критична. C использованием NullEngine, таки нет с чем сравнить данные в MV.

    Еще не использовали MV в продакшин фичах, где можно четко проверить консистентность их работы на долгом временном отрезке. Для локальных потребностей что-то собрать — все было хорошо.

    Из последнего, что слышал о MV: поменяли pre-insert на post-insert при вставке в MV.

  • Наш опыт внедрения ClickHouse — аналитической CУБД

    Спасибо за коммент и вопросы.

    По бэкапам: пока только снапшоты, данные которые были добавлены после снапшота можно оперативно долить c тех же источников. Если будет все совсем плохо — всегда есть HDFS. Но честно сказать, кейса с корраптом данных, чтобы их нужно было восстанавливать из снапшота у нас еще не было. Если же даунтайм ClickHouse — консьюмеры kafka просто ждут пока он вернется к жизни.

    Пользователя никак не ограничиваем, любые комбинации разрезов и метрик не вызывают проблем с производительностью.

    По обновлению данных: я упомянул новую фичу в разделе «Редактирование данных», в самом конце. Пока не использовали, отпугивает слово beta.

  • Наш опыт внедрения ClickHouse — аналитической CУБД

    Можно. Работы больше о том, что мы попутно хотим выполнить/потестировать некоторые улучшения нашей структуры таблиц.

  • Наш опыт внедрения ClickHouse — аналитической CУБД

    Спасибо за коммент.

    По метрикам использования ресурсов в масштабах системы сказать сложно. В ClickHouse мы храним сильно больше данных, и в более сыром виде. С появлением ClickHouse аппетиты по хранению данных сильно выросли.

    Сейчас в ClickHouse храним ~4TB + ведутся работы по увеличению доступного места.

    Но, касательно места, как раз на этой неделе выполнял перенос небольшой таблицы из MySQL в ClickHouse.

    Занимаемое место в MySQL: 11.3GB
    В ClickHouse с аналогичной структурой: 1.12GB
    Если навесить дополнительный MATERIALIZED View для сбора агрегатов, по интересующему разрезу и метрикам, с временной засечкой к часу: 19MB