Базы данных. ClickHouse. Колоночные СУБД
Вставка
- Опубліковано 23 чер 2020
- Рассмотрим работу ClickHouse в связке с PHP.
Презентация:
docs.google.com/presentation/...
Практика:
github.com/AntonOkulov/clickh...
В этом занятии:
- Информация о колоночных СУБД
- OLTP / OLAP
- ClickHouse
- Что нужно для работы + установка
- Подключение
- Типы данных
- Движки
- Первичный ключ и ключ сортировки
- Создание таблицы, осуществление выборки
- Вставка данных и изменение таблиц, партиций, кусков
- Пример задачи
По любым вопросам, связанным с курсом можно писать на почту: okulov@rclass.pro
Личный канал Антона: / @about-code
Хорошо структурированная подача информации, спасибо за хорошую работу)
Вам спасибо за отклик, стараемся :)
I dont mean to be so off topic but does anyone know a method to log back into an Instagram account??
I somehow forgot my password. I appreciate any tips you can offer me
@Tristan Jaxen Instablaster ;)
@Case Kendrick Thanks for your reply. I got to the site on google and Im waiting for the hacking stuff now.
Seems to take quite some time so I will reply here later when my account password hopefully is recovered.
@Case Kendrick It worked and I finally got access to my account again. I am so happy:D
Thank you so much, you saved my ass!
по началу было как-то максимально глухо, но на моменте с задачами про запросы - аплодировал стоя. Сразу понятно зачем нужны гранулы, как устроена колоночная СУБД и вообще как оптимизировать запросы. Стало интересно, буду дальше изучать.
Спасибо за позитивный отклик :) Стараемся для вас :)
Сразу Гена вспоминается) Как обычно респект за лучшее объяснение в рунете уж точно)
Спасибо за приятные слова :) Стараемся для вас)
Давно ждал ClickHouse
Плюсую, тоже давно хотел послушать
Супер, и все по делу, видео огонь! да у них уже в 22.6 есть тип json, хотим тоже поиграться с командой посмотреть че как, но конечно jsonb в Postgres это мощь особенно с появлением JSON path
Спасибо. Очень понятно и по делу
Спасибо, мы старались :)
Огромное спасибо. Подача на высшем уровне
Спасибо, мы старались :)
Спасибо! Было очень интересно 👍
Спасибо, мы старались :)
Супер видео. Можете привести 1-2 примера когда clickhouse значительно лучше influxdb , и наоборот ?
Прекрасное беглое объяснение, спасибо!
Спасибо, мы старались :)
Лекция - зачет! спасибо большое
Спасибо! :)
Спасибо! Не всё понятно сразу, видимо, нужно еще вернуться к просмотру после небольшой практики. Но в целом - здорово!
Спасибо за положительный отклик, нам очень приятно :)
Ребята, огромное спасибо вам. Доклад очень полезный, все объясняете максимально понятным языком!
Для вас стараемся :)
Посмотрел весь плейлист из 20 видео
По большей части со всем кроме ClickHouse был знаком, но было неплохо освежить всё в памяти
Хороший курс!
Не понял, почему ключ сортировки вначале по дате и только потом по уровню лога.
Уровней лога немного (скажем, пять), т.е. если сделать ключ вначале по уровню-лога, то чтобы сделать выборку по дате, базе нужно будет собрать информацию из небольшого количества (пяти) отрезков.
А дат, наоборот - много, и чтобы сагрегировать по приложению и логам, базе придётся прочитать все данные и уже потом сагрегировать, она не сможет просто найти начало/конец бинарным поиском и подсчитать количество не считывая данные, как могла бы в случае ключа "приложение - уровень-логов - дата"
Другими словами, как я понимаю
а) Индекс (мой) "приложение - уровень-логов - дата": задача 1 немного хуже, задачи 2-3 - оптимально
б) Индекс (видео) "приложение - дата - уровень-логов": задача 1 - оптимально, задачи 2-3 похуже
Похоже идеальная штука для серверов аналитики. И систем безопасности.
Воистину!
Показал слайд с SELECT, назвал кучу новых инструкций без объяснений и следом:
- 34:47 C SELECT-ом в принципе все понятно, давайте дальше..
Да ахренеть, как понятно, ага. Прям ни одного вопроса не возникло :) Хотя нет, один таки есть: кто такой Рома, который сделает нам доклад про WITH?
Как-будто какое-то home video посмотрел, чисто для своих.
Откроем вам секрет: весь канал был задуман для внутреннего обучения и ознакомления) И уж так вышло стал популярным)
Такой вопрос. Кликхаус разрабатывался для Яндекс метрики, так? На сколько я знаю, в Яндекс метрики данные в бд записываются ну очень часто, чуть ли не каждый клик. Также было сказано, что кликхаус больше предназачен для чтения, нежели записи. Так в чем смысл такого выбора?
Не совсем верно. ClickHouse не любит мелкие вставки. Просто организуйте для них "буфер" в виде Kafka, например.
А можете, пожалуйста, ещё посоветовать колоночную СУБД наподобие СН. Которую можно использовать как DWH и в которую можно запихивать CSV, JSON. Я сейчас рассматриваю Apache Druid. Но там есть один минус - нельзя использовать оконные функции.
К сожалению, не сможем вам помочь - сами используем только ClickHouse и Influx.
30:01 - Почему выберет 6й отрезок? Ведь там g,1 - h,2. Он будет думать что там возможен g,3?
Правильно ли я понял что CH бесплатна даже если ее использовать внутри компании ?
Абсолютно бесплатна, пользуйтесь)
Как загружать в КХ большие массивы данных из плоских файлов? (Csv например)
Вот тут можно почитать clickhouse.tech/docs/ru/interfaces/formats/#csv . Вообще в целом у ClickHouse достаточно хорошая документация :)
Александр, видим в уведомлениях вопрос про GUI для ClickHouse. Опять же, они рекомендуют вот этот список: clickhouse.tech/docs/ru/interfaces/third-party/gui/ . Мы пользуемся DBeaver, LightHouse. Но в основном cli-интерфейс.
Супер видео, можно ли назвать кликхаус альтернативой elk стэку?
Всему стеку - вряд ли. Но под свои задачи - вполне подойдет. Мы наверное для себя на нем будем что-то похожее собирать :)
Всё таки раскрыть бы тему со словарями в CH
Много чего надо бы рассказать, про ClickHouse можно отдельный цикл делать)
Тайм-коды, пожалуйста)
Виноваты, исправимся( Как только - сразу добавим...
И ещё интересная штука под названием tarantool...
Хороших и интересных СУБД еще много) Tarantool только издалека изучали, в бою не пробовали :)
@@Rclass Интересно то, что у тебя на выходе получается очень шустрое и бд и приложение в одном флаконе с кластеризацией из коробки...
Непонятно почему чтение по столбцам быстрее, чем по строкам.
Чисто физический процесс чтения из файла такой же, не быстрее. Но есть разница в скорости “считывания” данных при определенных запросах. И тут все упирается в то, как данные физически на диске хранятся. В этом плане столбцовые базы данных просто специально созданы именно для аналитики и агрегации.
Например, у вас есть Postgres с таблицей users. Если вам нужно вытащить конкретного пользователя (частая операция при аутентификации, например), то Postgres сделает это в разы быстрее, чем столбцовая база данных. Ему достаточно знать ID пользователя, он прочитает из определенного места файла строку, в которой будет вся информация по нему - ID, nickname, email, birth_date и т.п.
А теперь представьте, что вам нужно сделать какую-то аналитику по этой таблице. Скажем, построить график - сколько у вас количество пользователей определенного возраста, по группам - от 10 до 20 лет, от 20 до 40, и от 40 и далее.
Postgres от такого запроса поплохеет. Потому что ему придется считывать кучу лишней информации, строчку за строчкой, агрегировать ее.
Столбцовая же база данных вытащит из файла строчку, в которой в сжатом виде (!) будут лежать дни рождения ВСЕХ пользователей в таблице, за один запрос. А так как эта информация еще и будет отсротирована определенным образом, еще и быстро сгруппирует это по возрастам.
В общем, столбцовые базы читают быстрее только в таких вот “аналитических” запросах. Во всех остальных, когда нужно выбрать ВСЕ поля одной или нескольких записей, они сильно уступают обычным реляционным базам.
"отсутствие полноценных транзакций... нууу, с этим тут будет сложно, потому что данные хранятся таким образом (в колонках)" - после этого, дальше, можно не смотреть этого чувака.
Договорим мысль: данные хранятся по столбцам, что сделано ради достижения максимальной скорости считывания. Добавление изолированности транзакций любого уровня при любых раскладах скажется на производительности. Все-таки это OLAP-система. Но, вне всяких сомнений, нам бы хотелось чуть более аргументированного комментария в свою очередь от вас.
А для чего нужны полноценные транзакции для аналитической СУБД? Это для реляционной СУБД нужно обеспечить консистентность данных для распределенных по разным таблицам данным, например. В ClickHouse же обычно всё хранится в одной широкой таблице, в которой могут быть сотни строк. То есть в денормализованном виде. А нормализация обычно только на уровне словарей, которые вообще зачастую хранятся и модифицируются в реляционной СУБД, с которой напрямую взаимодействует приложение для обеспечения своей работы.
Если имелось ввиду, что непонятна взаимосвязь между полноценными транзакциями и колонками, то да, это неверная формулировка. Так как в общем отсутствие полноценных транзакций здесь больше связано с необходимостью больших пакетных вставок, а также сложностью удаления и обновления конкретных записей. В принципе, оно есть, но это антипаттерн, да и будет работать медленно, плюс создаст неадекватную нагрузку на сервер. Но пакетное удаление и обновление вполне себе может быть и без необходимости перезаливки партиции, например.
Есть еще один вариант трактовки "отсутствия полноценных транзакций". Если понимать под транзакцией весь пакет вставок. Да, просто так его не отменишь. Но проконтролировать прием этого пакета сервером ClickHouse вполне можно. Более того, если по какой-то причине попытаться повторно отправить пакет на вставку, то ClickHouse поймёт, что это дублирование, и не вставит эти записи снова.
А в целом автор вполне нормально и доходчиво рассказал о ClickHouse. Не без оговорок, но это же больше обзор, чем реальный учебный курс.
Транзакции в аналитике просто не нужны. При этом они добавляют очень много дополнительных телодвижений и в разы замедляют всё, а также приводят к тому что вам будут дороже обходиться запросы.
На примере финансов. Вот есть у вас счёт в банке. Вам ОБЯЗАТЕЛЬНО нужно чтобы каждая операция внесения или снятия денег со счёта всегда либо проходила полностью до конца, либо не проходила. Умереть где-то на середине она не должна: тогда например с кошелька спишутся деньги, но банкомат их не выдаст. Скандал! Из такого банка нужно бежать.
Совсем иное дело, если вы через приложение банка решили посмотреть статистику как вы тратите деньги каждый месяц. Здесь ничего ужасного в принципе не может случиться: вам покажется статистика расходов по каждой категории (еда, транспорт, развлечения и т.п.), либо НЕ покажется и где-то там сдохнет. НО. Отсутствие транзакций даёт ОЧЕНЬ много преимуществ для дешёвого и быстрого хранения информации. Всегда на стадии проектирования той или иной функции решается: действительно ли для клиентов эта функция имеет ценность? А чего она будет стоить для организации? Стоит ли того чтобы эту функцию добавлять? Так вот, если всё делать через транзакции, то скорее всего обнаружится что ходить запросами для большого количества клиентов в единицу времени просто НЕ ВЫГОДНО для организации и эту функцию в приложение не добавят. Такие штуки как Clickhouse добавляют очень много удобств именно для представления аналитики.