Если таблица совсем большая. Использование столбцовой СУБД (Yandex ClickHouse) для расширения возможностей 1С

В последнее время появилась хорошая тенденция использовать для решений 1С обширный стек смежных технологий. Это, несомненно, радует. В связи с этим я хочу рассказать про бесплатное OpenSource-решение от компании Яндекс – столбцовую базу данных ClickHouse, и то, как ее можно использовать совместно с 1С.
Для небольших 1С-систем ClickHouse, скорее всего, не пригодится. Но если мы говорим о HighLoad, тогда эта технология может оказаться очень полезной.

На 1С можно все, но зачем?

Начать свой доклад я хотел бы с моей любимой картинки. Она выражает ключевую мысль, которую я собираюсь до вас донести: «вот так, с помощью нехитрых приспособлений буханку белого (или черного) хлеба можно превратить в троллейбус».

Эта картинка выражает две проблемы:

  • Первая – это когда человека, который совсем не 1С-ник и терпеть 1С не может, заставили программировать на 1С. И вот он, пытаясь что-нибудь изобрести, прикручивает сюда различные инструменты, чтобы реализовать задачу, для которой в 1С и так все есть.
  • Или наоборот, когда человек слишком 1С-ник, и готов, не используя внешние средства, реализовать целиком на 1С поисковый движок или 3D-игру – мы все на Инфостарте такие примеры видели, там чего только ни делается. Это тоже крайность.

И дело здесь не в том, что 1С не потянет какую-то задачу. Она потянет всё, у нас замечательная платформа для быстрой разработки бизнес-ориентированных приложений. Но современные реалии таковы, что универсального средства на все случаи жизни не бывает.

  • Если у вас есть топор, то его нужно использовать для того, чтобы рубить лес. Вы, конечно, можете им побриться или хлеб нарезать, но это не очень удобно, тяжело и, в целом, неправильно.
  • Если у вас один разработчик, вам не нужен Agile или DevOps.
  • Если у вас три разработчика, которые разрабатывают три 1С-системы, вам не нужна совместная разработка.
  • Можно буханку хлеба превратить в троллейбус… но зачем? Для решения специализированных задач нужно использовать специализированные инструменты.

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

Теоретические основы

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

Первым делом вспомним, что такое OLAP и OLTP. Казалось бы, это – две избитых сущности, о которых все слышали:

  • OLAP – это On-Line Analytical Processing;
  • А OLTP – On-Line Transaction Processing.

 

OLAP – для чтения, OLTP – для записи данных.

Но фактически OLAP и OLTP – это всего лишь подходы к проектированию, причем, даже не СУБД, а конкретного прикладного решения. Более того, в рамках прикладного решения на одной платформе и одной СУБД может быть применён как OLAP, так и OLTP подход. В современном мире это происходит всё чаще. Далеко ходить не надо:

  • В 1С мы знаем, что у нас есть агрегаты по регистру продаж – это классический OLAP-инструмент.
  • Также к OLAP в 1С часто относят регистр бухгалтерии, т.к. его структура ориентирована по большей части на быстрое извлечение данных, а проведение, в основном, отложенное (в ERP, например).
  • Но в целом, 1С – это больше инструмент ввода данных. Все наши регистры, справочники, документы – это все OLTP.

При этом в современных условиях у нас все чаще возникают OLAP-задачи, на которые платформа 1С в базовом ее виде не рассчитана.

Итак, что же такое OLAP? Термин OLAP – это не всегда означает кубы, это просто специализированное хранение данных, поддерживающее агрегацию. OLAP – это когда нажали кнопку и появился отчет. Не так, что: нажали кнопку, увидели котиков, а потом появился отчет. А сразу – нажали кнопку, и появился отчет. Нажали еще три раза – провалились до проводки. И никто ничего не ждет. OLAP – это когда без котиков. ClickHouse – это OLAP решение.

Какую таблицу можно считать большой?

Я считаю, что ClickHouse нужен только для больших таблиц, когда у вас реально есть что-то большое.

Провокационный вопрос – какую таблицу можно считать большой? У кого есть большие таблицы? Как вы считаете:

  • Миллион записей – это большая таблица?
  • А десять миллионов?
  • А сто миллионов?

 

Вы все неправы. Большая таблица или нет – это определяется сугубо потребностями пользователя.

  • Для кого-то миллион записей – это очень большая таблица. Если по ней миллионы запросов в секунду и все реально жалуются, что работать невозможно, тогда это – действительно большая таблица. С такой таблицей надо работать по всей терминологии OLAP, по всей терминологии BigData.
  • А если в таблице 100 миллионов записей, но она никого особо не интересует, и по ней один запрос в год – это маленькая таблица. Вы можете сложить ее в csv-файлик и обращаться к ней только тогда, когда это вам действительно нужно.

Таблицу можно считать большой только тогда, когда к ней большое количество запросов и скорость обработки данных в ней не устраивает конечных пользователей. Универсальным способом определения больших таблиц является APDEX – независимо от того, BigData у нас или нет. Реальный размер никакого значения не имеет.

Когда ClickHouse не нужен

Сжатие таблиц СУБД

Разберем вырожденный пример: у вас есть большая таблица, у которой не выполняется APDEX. Пользователи жалуются, все недовольны, и бизнес говорит: «Что же вы за ИТ-шники, если ничего не можете сделать?». И вы пытаетесь что-то сделать.

Что имеет смысл попробовать в первую очередь?

ClickHouse? Нет. Основная суть моего доклада состоит в том, что нужно использовать средства, соответствующие конкретным задачам. Если бы я сразу начал рассказывать про ClickHouse, смысл был бы неполным. ClickHouse – это космос, который решит все. Но сразу в этот космос погружаться не стоит, есть вполне земные инструменты, которые можно использовать.

Вынужден предупредить, что то, о чем я буду рассказывать, приводится здесь исключительно ради академического интереса, в целях обучения. Ничего подобного с базой 1С, конечно же, делать нельзя, потому что есть лицензионное соглашение, которое мы этими действиями нарушаем.

Но, тем не менее, в первую очередь, когда у вас есть большая таблица, вам ее, конечно, нужно сжать.

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

И дело даже не в том, что места на диске мало. Просто в большинстве высоконагруженных систем дисковая подсистема остается узким «горлышком». Мы вынуждены с ней работать, и она нас пока что останавливает. Да, появились SSD, стало лучше, но запись на диск все равно еще не настолько быстро работает, как память и процессор.

Сжатие позволяет сократить операцию записи, расплатившись за это ресурсами процессора. А процессорное время – это сейчас как раз самый простой ресурс:

    • Процессор стоит дешево, он виртуализируется, его ядра можно докидывать и перераспределять – на скорость работы это влияет существенно.
    • А дисковая подсистема – это, как правило, просто большое хранилище. Добавили туда диски или убрали – на скорость работы не влияет.

На слайде приведен пример кода для сжатия таблицы SQL-сервера. Здесь в строке, где указано DATA_COMPRESSION=:

  • ROW – это не совсем сжатие.
  • PAGE – это сжатие более полноценное. Всем рекомендую второй способ.

Если у вас была большая таблица, которая «тупила», а процессор при этом был загружен на 15%, то после выполнения одной только этой инструкции есть шанс, что вы получите ускорение в производительности ваших запросов в 5-10 раз. Плюс – сэкономите место.

Одна важная деталь – такой подход требует лицензии SQL Server уровня Enterprise (если мы говорим про Microsoft SQL Server).

Секционирование таблиц

А что делать, если вы сжали таблицу, но быстрее не стало? Или стало быстрее, но ненамного?

Мы можем применить секционирование – разделить таблицу на секции и разложить их по разным дисковым подсистемам, чтобы после этого работать только с одной частью этой таблицы. Эта идея стара как мир – у вас была большая таблица, а стало 10 маленьких.

Как работает секционирование?

  • Определяется функция, в соответствии со значениями которой данные будут разделяться на секции. Например: эта секция – январь, эта – февраль, эта – март.
  • После применения этой функции разные секции таблицы можно разложить на разные файловые группы и даже на разные диски.
  • Логически с таблицей можно работать, как с единым целым.
  • Но при этом вы всегда работаете только с теми данными, которые вам нужны: если вся работа ведется в январе, соответственно, вы обращаетесь только к одной секции; если вам нужен март, то к другой.

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

Кубы, InMemory

Но что делать, если секционирование тоже не помогло, и пользователи все равно жалуются? Здесь, конечно, можно сразу перейти к ClickHouse, но это – тяжелая артиллерия, торопиться ее применять не стоит.

Прежде всего, имеет смысл рассмотреть традиционную технологию, тем более, если у вас уже используется MS SQL Analysis Services или какие-то BI-решения, или есть компетенции по OLAP. Вы можете взять кубы или воспользоваться InMemory технологиями различного рода – сейчас их, слава богу, много, можно найти даже OpenSource-решения.

  • С кубами есть несколько проблем:
    • Если у вас был один гигабайт данных, и вы их развернули в куб, то данных стало 10 Гб.
    • Работать стало быстрее, но вы эти кубы регулярно перестраиваете.
    • Вы добавляете туда новые измерения, а потом выясняется, что вы что-то спроектировали неправильно.
    • Соответственно, поскольку куб требует регулярного перестроения – это не совсем online.
  • Технология InMemory подразумевает, что:
    • Ваши данные изначально очень хорошо организованы с точки зрения структуры;
    • У вас есть много памяти;
    • И эта память кластеризуется (если одна нода упала, во второй все осталось).

При этом кубы и InMemory технологии – это не совсем простые и легкие решения, поэтому они не получили большого распространения и сейчас потихоньку отмирают.

В результате, как один из вариантов, появляется ClickHouse.

Когда нужен ClickHouse?

Итак, когда ClickHouse действительно нужен?

Когда вы уже достигли предела (SQL-таблички большие и с ними ничего сделать не получается, а кубы и InMemory вас не устраивают) – вот тогда вы действительно уже можете задуматься о специализированном продукте, позволяющем решить те проблемы, про которые вы раньше считали, что их решить невозможно. Возможно все. Слово «невозможно» в современном ИТ-мире для бизнеса произносить нежелательно. Можно «порыться» в Linux World, на GitHub, и вы найдете там множество технологий, о которых даже не задумывались.

Когда нужен ClickHouse:

  • Когда данных реально много, а штатные средства уже не помогают.
  • И самое главное – когда по этим данным нужна агрегированная информация.

Типичный пример – это журнал регистрации. Он у всех большой, по нему хочется хранить историю, хочется получать логи.

Ну, и загрузите их в ElasticSearch – это замечательная СУБД для того, чтобы закинуть туда кучу хлама и потом в этом хламе найти одну запись. Он стал уже стандартом де-факто для этого. Даже среди 1С-ников его, наверное, многие уже используют.

А о ClickHouse мы говорим тогда, когда нам нужна агрегация данных, когда вам нужно собирать кучу информации о каких-либо частых, но мелких событиях, и потом анализировать эту информацию статистическими методами.

Например, если вам по тому же журналу регистрации нужно построить статистику:

  • Сколько было ошибок на протяжении последних 5 лет;
  • Какова статистика этих ошибок;
  • Какие документы вводят пользователи;
  • Сколько времени в среднем проводится такой-то документ.

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

Столбцовые (колоночные) СУБД

Вот так работают обычные реляционные СУБД:

Мы привыкли, что в традиционных СУБД данные в таблицах хранятся по строкам. И чтение-запись также происходит по строкам. Конечно, мы не перебираем все строки подряд, а находим нужную строку по индексу, подтягиваем ее связи и т.д., но, тем не менее, мы работаем со строками.

За счет чего у ClickHouse получается такая скорость обработки?

А теперь давайте «перевернем сознание» и посмотрим на эту же табличку с другой стороны:

И дальше у вас и чтение, и запись будут производиться по колонкам. Вот и вся модификация. Ничего нового, ничего супер-мега-крутого больше не придумали.

Что достигается за счет такой модификации структуры?

  • Данные можно сжать.
  • Про нормализацию можно забыть. Зачем была нужна нормализация? Чтобы отделить колонки друг от друга, не хранить данные в пластах. Здесь эта проблема исчезает полностью.
  • При выборке данных с диска в память считывается сразу много данных, чтобы с этим работать. Это реально ускоряет запросы в десятки раз.

Столбец vs Строка

  • Если вы загрузили данные в столбцовую СУБД, считайте, что вы уже их уменьшили в среднем в 10 раз. В пике – в 20. Реально – то, что раньше весило 10 Гб, стало весить один гигабайт, может быть даже 500 Мб.
  • Плюс к этому таблицу можно сжать.
  • А также стало быстрее производиться чтение – поскольку это OLAP-решение, оно рассчитано на быстрое чтение.

Правда, с записью в ClickHouse проблематично.

«Яндекс» использует запись порциями (BULK INSERT), когда берем файл, закидываем его в СУБД, и она его успешно парсит. ClickHouse успешно парсит csv и другие форматы файлов.

Представители

В мире данная технология уже давно не новость. ClickHouse – это далеко не первый ее представитель. Весь мир уже давно использует столбцовые СУБД, успешно с ними живет, выпускает специализированные решения:

  • Самый известный представитель – это HP Vertica. Она появилась уже лет 15 назад и активно используется по всему миру, в том числе и в России. Стоит очень дорого, как и все с лейблом HP.
  • В рамках Facebook родились Cassandra и Hive:
    • Cassandra мы воспринимаем как что-то маленькое и очень быстрое;
    • Hive люди в основном ассоциируют с Hadoop, с каким-нибудь «монстром». Но тоже очень быстро работает.
  • Недавно к этой технологии присоединился Google со своим BigQuery.
  • И, неожиданно, компания SAP, которую я не очень люблю, тоже пошла в этом отношении технологически вперед. Теперь база SAP – это уже по большей части столбцовая СУБД. Кроме того, еще и с InMemory. Так что тут мы немного отстали.
  • Наш ClickHouse.
  • И еще я сюда включил Oracle и Microsoft, базы которых не относятся к столбцовым СУБД, но они эту тему также признали:
    • У Oracle недавно появилось Hybrid columnar compression –это позиционируется, как некое сжатие таблички.
    • А SQL Server поддерживает Columnstore index – это некое специализированное хранение.

Поэтому можно сказать, что и в SQL, и в Oracle также есть столбцовое хранение.

Быстрее некуда

Красивая картинка с сайта Яндекса – сравнение скорости работы HP Vertica и ClickHouse. Не всему здесь, конечно, можно верить, но я думаю, что больше, чем в 2 раза нас не обманывают.

Слева показатели ClickHouse, а справа – HP Vertica, самая скоростная, самая дорогая.

Я бы хотел акцентировать внимание на цифре, которая обведена на слайде. Один миллиард записей. Кто-нибудь делал запросы к таблице в один миллиард записей на SQL сервере? Кто-нибудь считал Count(*) по таблице из одного миллиарда записей?

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

А здесь – посмотрите внимательно – 0.1 секунда, 0.06 секунд. Здесь речь идет не о минутах и не о часах.

Я могу сказать, что у меня на MS SQL для таблицы в миллиард записей Count(*) выполнялось где-то около часа. А здесь оно выполняется в районе долей секунды. Поэтому ClickHouse и MS SQL – это в принципе несопоставимые решения по скорости. Это абсолютно разный класс СУБД, несмотря на то, что ClickHouse – это SQL-решение, и вы в нем можете использовать тот же синтаксис запросов.

Чудес не бывает!

Конечно, чудес не бывает. У ClickHouse много ограничений, которые делают его специализированным решением, а не «универсальной СУБД»:

  • Например, у ClickHouse нет операций Delete и Update. Главный разработчик сказал «а зачем?» ClickHouse изначально разрабатывался для проекта Яндекс.Метрика – там просто нужна статистика по операциям. Человек кликнул на сайте, это записалось в базу. Модифицировать и удалять этот клик бессмысленно, поэтому Delete и Update нет.
  • Дальше – драйвер ODBC появился недавно, и в нём много проблем. Появился совсем недавно. Сейчас он уже худо-бедно работает, его можно использовать, можно даже к Excel подключиться и что-то туда передать, но к 1С, как к внешнему источнику, пока еще не подключим.
  • Не особо быстрый INSERT – это общая проблема столбцовых СУБД. Данные в ClickHouse вообще лучше помещать пакетами (использовать BULK INSERT)
  • Как и во многих специализированных OpenSource решениях (в NoSQL, например), транзакций нет. Потому что транзакция и СУБД – это отдельная песня. В современном мире транзакции не очень любят.
  • А также множество других ограничений:
    • Не совсем стандартный SQL;
    • Разные движки таблиц;
    • Работает только под Linux.

Для чего можно использовать ClickHouse простому 1С-нику?

Лично мне ClickHouse нужен был всего в нескольких кейсах. Пока эта технология не появилась, я отвечал бизнесу: «Это невозможно». Мне всегда очень стыдно, когда я говорю «невозможно» или не могу этого сделать – для меня важно, что мы можем сделать все, даже если это не очень серьезные задачи.

Для чего можно было бы использовать ClickHouse:

  • Первое – это анализ логов, получение любых статистических показателей из журнала регистрации. Наверное, ни для кого не секрет, что журнал регистрации в 1С имеет много недостатков:
    • В новом формате из него можно успешно читать данные, но когда 1С в него пишет, пользователям приходится ждать из-за блокировок. Поэтому новый формат можно использовать, только если у вас небольшая база.
    • В реальном HighLoad выживает только старый формат журнала регистрации, но в этом виде получить из него какие-то данные, кроме последнего дня, вы не сможете.

ClickHouse – это реальный способ хоть как-то работать с данными журнала регистрации. Либо, если вам по нему нужен только поиск, используйте ElasticSearch.

  • Второе – это анализ любых операций.
  • Третье – это KPI, статистика работы пользователя. Никто никогда не пытался вести в 1С статистику работы пользователя просто потому, что для этого не было инструментов. Теперь такой инструмент есть – это ClickHouse.
  • И еще одна задача, более жизненный бизнес-кейс, это – динамика остатков. Дальше я про него детальнее расскажу.

Варианты использования с 1С

Анализ журнала регистрации

Итак, что мы делали с журналом регистрации:

  • Брали журнал регистрации из 1С;
  • Загружали его в ClickHouse;
  • И потом из 1С обращались уже к ClickHouse, и выводили его данные в отчеты.

У ClickHouse есть замечательный HTTP-интерфейс: вы пишете через него запросы, они обрабатываются, и никаких проблем это не вызывает.

Отчет «Динамика остатков»

Итак, наиболее жизненный вариант применения ClickHouse – отчет «Динамика остатков». Это достаточно традиционная задача, которую обычно никто не относит к вопросу «больших данных». В любой более-менее нормальной организации аналитики пытаются строить такие отчеты.

Но вы представьте:

  • У нас есть 60 000 позиций номенклатуры. Это немного – обычная торговая компания.
  • 200 складов – это тоже немного.
  • И мы хотим всего лишь проанализировать динамику остатков по каждой номенклатуре на каждом складе за каждый день в течение пяти лет.

Итого мы получаем 22 миллиарда записей.

В 1С построить такой отчет нереально, все представляют, что это такое. Если и получится это сделать, то только с учетом сторонних средств.

Рассмотрим два варианта – куб или ClickHouse.

  • Кто уже решал подобные задачи при помощи кубов знают традиционные проблемы:
    • Данных много, место на диске расходуется неоправданно быстро.
    • Типичный случай: вы проектируете куб, определили его измерения, а потом через день хотите добавить еще одно измерение. Приходится переделывать хранилище данных, чистить его, загружать заново. Не очень приятная операция – кто занимался, может быть, знает.
    • Регулярно требуется долгое перестроение.
    • Проходит оно не всегда удачно.
    • Конечные пользователи будут удивляться: «А почему у меня там данные за вчерашний день?», «А всегда нужно использовать два источника?», «Как только я хочу провалиться до товара – все начинает тупить». Неудивительно, что начинает тупить, потому что когда происходит Drill Down, идет обращение к исходной таблице, а в ней 22 млрд записей.
  • ClickHouse решает большую часть этих проблем:
    • Вы получаете остатки в режиме online. Можно видеть в базе как текущие остатки, которые туда регулярно подгружаются (мы настроили интервал обновления данных – 5 минут).Так и исторические данные за предыдущие 10-20 лет.
    • Весь этот объем ClickHouse вполне успешно обрабатывает за короткое время.
    • При этом самих данных становится меньше. Если при помещении в куб данных становится в 10 раз больше, то ClickHouse их, наоборот, сожмет.
    • И дальше вам не нужно будет больше ничего перестраивать.
    • И не нужно ничего проектировать.

Установка ClickHouse

Как видите, вся инструкция по установке влезла на один слайд. Сама по себе установка предельно проста:

  • Главное – не надо бояться Linux-а. Я тоже совсем не линуксоид, но это нестрашная система. Можно скачать готовый образ Linux и развернуть его на виртуалке. Все это делается за 5 минут.
  • С помощью трех волшебных строчек скачиваете установочный файл ClickHouse из репозитория и все обновляете.
  • Дальше стартуете сервис.
  • И проверяете его работу через HTTP-интерфейс.

Несмотря на то, что ClickHouse существует только под одну платформу (и это его минус), установка под Linux происходит быстрее, чем мы с вами привыкли под Windows. И уж тем более, ClickHouse поставить гораздо быстрее, чем MS SQL. Поверьте, это реально так, причем, то же самое можно сказать про любую «страшную» стороннюю СУБД.

Создание таблицы

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

  • Синтаксис команды стандартный, как и в нормальном SQL – CREATE TABLE.
  • Самое важное тут – ENGINE=MergeTree. Это так называемый «движок таблицы». Для Web-разработчиков указывать движок – дело привычное, но для нас с вами не особо.
    • MergeTree – это единственный нормальный движок ClickHouse. Как я понимаю, в «Яндексе» используют и развивают в основном его, и именно он работает быстро.
    • Другие движки могут использоваться для промежуточных данных. Например, в «Яндексе» при массовой загрузке рекомендуют грузить данные сначала в движок Log а потом уже внутри ClickHouse преобразовывать в MergeTree.
  • Параметры, указываемые при создании:
    • Первый параметр – столбец с датой. Он обязательно должен быть в создаваемой таблице.
    • Второй параметр – первичный ключ.
    • Третий параметр очень специфичен, нигде в документации по ClickHouse я не нашел, что он значит, и его лучше не менять.

Создать таблицу можно как программно, так и из командной строки.

Чтение и запись

Есть несколько вариантов взаимодействия с ClickHouse, но нас интересует всего три:

  • У ClickHouse есть ODBC-драйвер, про который я уже сказал.
    • Он активно развивается, каждую неделю выходит новый релиз, который исправляет одни баги и приносит другие. Он уже почти работает, им можно пользоваться, но для ограниченного круга задач.
    • Подключить его к 1С в качестве внешнего источника данных пока что вряд ли получится (у меня, во всяком случае, на момент подготовки к докладу не получалось), но интеграция с Excel вполне возможна.
  • Есть неплохая UI консоль с минималистичным интерфейсом, написанная на JavaScript. Просто открываете ссылку http://ui.tabix.io, вводите свои настройки подключения, подключаетесь и наслаждаетесь жизнью. Особенно, если, как и я, не любите командную строку.
  • Также у ClickHouse есть универсальный кроссплатформенный HTTP-интерфейс. Работать с ним просто:
    • Для операций SELECT используются элементарные GET-запросы.
    • Для операций INSERT – чуть более сложные POST-запросы. Это, наверное, стандартная типовая логика. Но вообще INSERT нужно делать через BULK INSERT.

Пример обращения к ClickHouse из 1С

Чтобы «грело душу», приведу пример кода на 1С. Тут нет ничего сложного – все, кто использовал HTTP-соединение из 1С, все знают, как это происходит:

  • GET-запрос для SELECT – это обычно Соединение.Получить().
  • И POST-запрос для INSERTСоединение.ОтправитьДляОбработки().

Еще раз повторюсь, для POST это всего лишь пример. В реальности если у вас скопился журнал регистрации на сотни гигабайт, так вы его не загрузите, нужно использовать BULK INSERT. Сама команда будет похожая, но вы сформируете CSV-файлик, который потом передадите в ClickHouse.

  • Сам парсинг журнала регистрации 1С у нас производится в стороннем приложении, оттуда и поступает команда BULK INSERT.
  • А потом в 1С мы только читаем данные из ClickHouse и строим отчеты.

 

*******************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 COMMUNITY. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.

24 Comments

  1. Идальго

    Хм, добавлю, что CH — уже давненько используется в качестве аналитического инструмента во многих крупных конторах. Вроде CH подходит для сравнительно малого числа, но очень больших запросов (т.е. не нужно частить с мелкими запросиками). Да, эта штука лучше всего подходит для OLAP и когда данные хорошо структурированы.

    Reply
  2. vitkhv

    Сжатие, вернее все же будет компрессия, таблиц с 2016 сервера доступно с редакции Standart MSSQL Server.

    Reply
  3. pbabincev

    Автор, спасибо, статья очень крутая!

    Reply
  4. Dzenn

    Это революция. Охрененно.

    Reply
  5. PerlAmutor

    (0)

    Сам парсинг журнала регистрации 1С у нас производится в стороннем приложении

    Как производится поиск данных по ссылкам? Часто нужно получить события именно в разрезе конкретного объекта БД. 1С с этим не справляется от слова совсем, поэтому ищу альтернативные возможности отбора по текстовому журналу.

    Reply
  6. comol

    (5) События в разрезе конкретного объекта — это всё-таки Elastic. Clickhouse — это когда «активность пользователя» «количество транзакций», «количество ошибок»… Ну и ЖР это больше как пример

    Reply
  7. Synoecium

    спасибо, ваша статья подтолкнуло начать разработку с использованием CH. Добавлю, что у CH есть большое и доброжелательное сообщество, которое помогало со всеми возникшими вопросами, что является весомым аргументом при выборе СУБД среди альтернатив.

    Reply
  8. Rustig

    (0) спасибо за доклад, за «знания — в массы!»

    полезно, интересно!

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

    Reply
  9. Synoecium

    (7) точнее не статья, а доклад на Infostart Event

    Reply
  10. 1c-intelligence

    Слушал доклад на конференции — интересно, полезно, со вкусом оформлено. Статья не передает впечатления полностью, но тут уж ничего не поделаешь.

    Reply
  11. rwf96

    А как данные из 1С попадают в CH для анализа?

    Reply
  12. rozer

    (12) картинку после «Чтение и запись» смотрели?

    Reply
  13. user828732

    Все таки не понял, за счет чего при переходе на колоночную СУБД объем данных уменьшился в 20 раз

    Reply
  14. LordKim

    (14)

    Насколько я понял, формат хранения это не плоская таблица, а дерево

    При простом развороте в сторону колонок чуда бы не произошло…

    Итого мы получаем 22 миллиарда записей.

    При развороте в колонке итого мы получаем 22 миллиарда колонок, давай, покажи мне запрос в MS SQL который это быстро обработает…) (это риторика, no offence)

    Скорее всего «ENGINE=MergeTree» при помещении данных сразу их агрегирует, типа если в строках было 10 значений Иванов, то в столбцовой будет 1 колонка Иванов и у нее 10 подчиненных колонок с ИД строки, наверное как-то так

    Для оперучета наф не надо, а вот для консолидированной отчетности должно быть очень годно

    Reply
  15. nicxxx

    Не совсем понятно насчет BULK INSERT. В документации такой команды нет, поэтому делаю вывод, что это описание процесса загрузки данных из CSV-файла, например. И работать с этими файлами можно только из командной строки, об этом говорится здесь: https://clickhouse.yandex/docs/ru/interfaces/cli/

    Но мы же все понимаем, что передача файла из 1С на linux-машину и запуск команды (однозначно через ssh) — это не самая простая задача. И вообще может быть нереализуемой, например, на сервер с 1С нельзя устанавливать ничего, в том числе ssh-клиент.

    Какие еще есть способы импортнуть в кликхаус CSV?

    Reply
  16. nicxxx

    Ок, интересно, полезно, но хотелось бы практических примеров. В частности, хочется понять, как закинуть файл на сервер с кликхаусом через http, если он будет весить 100-200 и более мегабайт.

    Reply
  17. trantor77

    Добрый день.

    А можете выложить обработки по выгрузке информации из 1С в ClickHouse и обработку по обращению из 1С в ClickHouse для вывода в отчет?

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

    —Брали журнал регистрации из 1С;Загружали его в ClickHouse;

    —И потом из 1С обращались уже к ClickHouse, и выводили его данные в отчеты.

    Reply
  18. Plastignac

    «Третий параметр очень специфичен, нигде в документации по ClickHouse я не нашел, что он значит, и его лучше не менять.»

    Знакомое число. Скорее всего — это размер блока данных для таблицы, как в БД Oracle, там данные читаются и записываются такими блоками.

    Reply
  19. yaxinr

    Выгрузил из таблицы ТоварыНаСкладах размером 2гб, в clickhouse, размер сократился до 100мб, т.е. в 20 раз сжалось. Также написал синхронизацию таблиц.

    Reply
  20. nvv1970

    (20) ну если бы просто компрессию включил (page), то раз в 5-10 тоже получил бы… Без синхронизации, в своей же базе… Но это конечно не колоночное хранение (

    Reply
  21. yaxinr

    (21) Я ошибся, в clickhouse данные 1с весят 40 мб, т.е. в 50 раз сжалось.

    я просто туда еще других складских систем данные загрузил и получилось 100 мб.

    Reply
  22. yaxinr

    Было бы круто если бы clickhouse хранил все в памяти, тогда колоночное хранение и скорость оперативки дали бы наверное супербыструю систему. Есть ли такие opensource решения?

    Reply
  23. nvv1970

    Статья впечатлила.

    А что же с колоночным хранением в других БД?

    Всем близкие MS или PG… Что с ними не так? Неужто вообще никакое решение по CCI ?

    Уж больно волшебные цифры на картинках у яндекса (((

    Reply
  24. Casey1984

    Плюсану и добавлю, что на текущий момент ClickHouse поддерживает пакетный UPDATE/DELETE.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *