Это принципиально разные системы.
Используйте ClickHouse для аналитики, а Tarantool как Key-Value базу.
В том числе, можно использовать и то, и другое.
На примере рекламной сети:
В Tarantool кладёте:
— данные для короткой персонализации;
— данные для таргетинга;
— счётчики для антифрода.
И используете его для запросов непосредственно из крутилки.
В ClickHouse кладёте:
— логи показов рекламы, вместе со всеми данными, свойствами посетителя, факторами;
— логи торгов, аукциона;
— логи кликов;
— постклик данные.
И используете его для построения отчётов:
— для внутреннего использования, для исследований, для оптимизации;
— в сервисе отчётов для клиентов.
Какую СУБД лучше использовать для хранения показаний датчиков и построения графиков по этим данным?
Это зависит от того, что нужно делать с этими датчиками.
Два варианта:
— по определённой логике принимать решение на каждый сигнал или на основе данных за короткое окно времени;
— эффективно хранить все данные и строить графики за любое время.
Пока не знаю. Само наличие IPv6 связности не требуется, система нормально работает по IPv4.
У вас IPv6 где-то явно выключен? (ядро собрано без IPv6, или какие-то настройки) Если да, то где?
Непонятно, зачем отключать IPv6.
Может быть, поможет убрать все адреса вида :: из config.xml, users.xml, но скорее всего, не поможет.
И тогда помогла бы перекомпиляция, чтобы явно убрать IPv6 из DNS-запросов.
EAI_ADDRFAMILY -9 /* Address family for NAME not supported. */
Посмотрите вывод ifconfig.
Возможно, на сервере нет поддержки IPv6 (в принципе, даже link-local адреса), а для чего-то IPv6 нужен (в конфиге используется IPv6).
Может быть, стоит разобраться подробнее.
будет ли работать вставка данных, если структура таблицы с Nested-полями и во входящем JSON совпадает? Или на вход поддерживается только JSON с плоской структурой?
Nested будет представлен в виде отдельных массивов (одинаковых длин) для каждого элемента вложенной структуры.
Таким образом, прямое соответствие между иерархией в JSON и Nested типами не поддерживается.
Эта задача имеет среднюю сложность, если рассматривать только один из сценариев работы.
Можно сделать поддержку protobuf-формата так, что можно будет читать данные из таблицы в некотором protobuf-е, который однозначно ей соответствует, и записывать данные в таблицу, но только в этой, конкретной структуре protobuf-а.
Но здесь не рассматривается другой сценарий работы — сгенерировать структуру таблицы по уже существующему protobuf-у. Будет сложность с protobuf-ами, имеющими более один уровень вложенности.
У нас есть в продакшене программа, которая перекладывает данные из сложного protobuf-а в ClickHouse, но она ещё при этом делает денормализацию: исходный protobuf содержит сессию, которая состоит из множества событий; и на один такой protobuf, в таблицу вставляется много строчек-событий.
В связи с этим, этот, более сложный сценарий, лучше вообще не рассматривать.
Сервер без изменений работать не будет — есть Linux-специфичная функциональность. Но немного, и её можно сделать отключаемой.
Я сам не смогу это сделать, так как у меня нет Mac.
И ещё: мы наблюдали, что на некоторых Openstack машинах, /proc/cpuinfo выдаёт неправильную информацию, хотя по факту, процессор выполняет нужные инструкции.
Можно завести (по факту, запускали даже на AArch64 серверах). Для этого нужно найти все места в коде, где оно используется.
Найти их можно поиском по коду фрагмента _mm_ или __x86_64__.
Из SSE 4.2 используется совсем немного: crc32, строковые функции (в паре мест).
Это можно легко закрыть ifdef-ами.
Типы данных String, FixedString позволяют хранить произвольный набор байт, включая нулевые байты.
То есть, они заменяют CHAR, BINARY, VARCHAR, VARBINARY, TEXT, BLOB.
Вставлять varbinary через TabSeparated формат довольно неудобно — надо будет эскейпить \t, \n, \\, что весьма неестественно для бинарных данных.
Можно рассмотреть формат RowBinary. Вкратце, он такой:
— числа пишутся в бинарном виде в little endian;
— String пишется в виде: длина в формате varint, затем байты строки;
— FixedString пишется просто как байты;
— Date пишется как UInt16 — число дней с unix эпохи, а DateTime как UInt32 — unix timestamp.
— все данные пишутся подряд, в порядке строк.
TabSeparated формат как правило является приемлимым по эффективности, если только вы умеете эффективно эскейпить значения типа String. Иногда с этим бывают проблемы. CSV будет тоже нормальным или чуть хуже.
Форматы Native и RowBinary эффективнее, но они не описаны подробно в документации.
При записи в таблицу семейства MergeTree, узким местом является скорее не парсинг формата, а сортировка данных, которую сервер производит при записи. Если отправлять уже отсортированные по первичному ключу данные, то сервер это поймёт, и загрузка будет идти быстрее. (Но если данные изначально не отсортированы, то вряд ли их удастся отсортировать эффективнее, чем это делает сервер).
При записи в простые таблицы Log/TinyLog, узким местом по CPU будет именно формат данных.
Лучше сначала попробовать загружать, как удобно. Например, формат JSONEachRow, конечно, менее эффективен, но если он оказался удобен для вас, то лучше начать с него.
Ещё замечу, что если данные постоянно загружаются на кластер (в реальном времени) и никогда не удаляются, то постоянный throughput по записи в расчёте на один сервер будет совсем небольшим (так как иначе вы просто за несколько дней заполнили бы все серверы). И при этом, запись не будет упираться в CPU и диски.
Пакеты для Xenial, наверное, будут.
По крайней мере, поставлена задача.
Для запуска из корня ./release --standalone, вроде бы, 10 GB должно впритык хватить.
А если собираются все таргеты, которые есть в репозитории, то около 30 GB.
Например, DROP TABLE удаляет только локальную таблицу. Если написал DROP TABLE для Distributed-таблицы — удалится только сама Distributed-таблица («вид» на данные), а все данные останутся на месте.
Аналогично для Replicated-таблиц. Если сделал DROP TABLE — удалится одна реплика, и у таблицы станет на одну реплику меньше.
У нас есть задача «распределённые DDL», чтобы можно было одной командой манипулировать со всеми составляющими Distributed-таблиц. Но пока не очень спешим делать. К тому же, она, на всякий случай, будет работать только при каком-либо «снятом предохранителе».
Используйте ClickHouse для аналитики, а Tarantool как Key-Value базу.
В том числе, можно использовать и то, и другое.
На примере рекламной сети:
В Tarantool кладёте:
— данные для короткой персонализации;
— данные для таргетинга;
— счётчики для антифрода.
И используете его для запросов непосредственно из крутилки.
В ClickHouse кладёте:
— логи показов рекламы, вместе со всеми данными, свойствами посетителя, факторами;
— логи торгов, аукциона;
— логи кликов;
— постклик данные.
И используете его для построения отчётов:
— для внутреннего использования, для исследований, для оптимизации;
— в сервисе отчётов для клиентов.
Это зависит от того, что нужно делать с этими датчиками.
Два варианта:
— по определённой логике принимать решение на каждый сигнал или на основе данных за короткое окно времени;
— эффективно хранить все данные и строить графики за любое время.
Нам надо бы серьёзно обновить бенчмарк.
— сделать его на основе открытых данных;
— сделать запросы более разнообразными.
В этой директории есть заготовки: инструкции, как загрузить некоторые открытые данные и выполнить некоторые запросы.
В частности, есть заготовка для AMPLab Big Data Benchmark. Правда там всего три запроса, так что он тоже не особо интересен.
У вас IPv6 где-то явно выключен? (ядро собрано без IPv6, или какие-то настройки) Если да, то где?
Непонятно, зачем отключать IPv6.
Может быть, поможет убрать все адреса вида
::из config.xml, users.xml, но скорее всего, не поможет.И тогда помогла бы перекомпиляция, чтобы явно убрать IPv6 из DNS-запросов.
Посмотрите вывод ifconfig.
Возможно, на сервере нет поддержки IPv6 (в принципе, даже link-local адреса), а для чего-то IPv6 нужен (в конфиге используется IPv6).
Может быть, стоит разобраться подробнее.
Nested будет представлен в виде отдельных массивов (одинаковых длин) для каждого элемента вложенной структуры.
Таким образом, прямое соответствие между иерархией в JSON и Nested типами не поддерживается.
Можно сделать поддержку protobuf-формата так, что можно будет читать данные из таблицы в некотором protobuf-е, который однозначно ей соответствует, и записывать данные в таблицу, но только в этой, конкретной структуре protobuf-а.
Но здесь не рассматривается другой сценарий работы — сгенерировать структуру таблицы по уже существующему protobuf-у. Будет сложность с protobuf-ами, имеющими более один уровень вложенности.
У нас есть в продакшене программа, которая перекладывает данные из сложного protobuf-а в ClickHouse, но она ещё при этом делает денормализацию: исходный protobuf содержит сессию, которая состоит из множества событий; и на один такой protobuf, в таблицу вставляется много строчек-событий.
В связи с этим, этот, более сложный сценарий, лучше вообще не рассматривать.
Я сам не смогу это сделать, так как у меня нет Mac.
Найти их можно поиском по коду фрагмента _mm_ или __x86_64__.
Из SSE 4.2 используется совсем немного: crc32, строковые функции (в паре мест).
Это можно легко закрыть ifdef-ами.
То есть, они заменяют CHAR, BINARY, VARCHAR, VARBINARY, TEXT, BLOB.
Вставлять varbinary через TabSeparated формат довольно неудобно — надо будет эскейпить \t, \n, \\, что весьма неестественно для бинарных данных.
Можно рассмотреть формат RowBinary. Вкратце, он такой:
— числа пишутся в бинарном виде в little endian;
— String пишется в виде: длина в формате varint, затем байты строки;
— FixedString пишется просто как байты;
— Date пишется как UInt16 — число дней с unix эпохи, а DateTime как UInt32 — unix timestamp.
— все данные пишутся подряд, в порядке строк.
Форматы Native и RowBinary эффективнее, но они не описаны подробно в документации.
При записи в таблицу семейства MergeTree, узким местом является скорее не парсинг формата, а сортировка данных, которую сервер производит при записи. Если отправлять уже отсортированные по первичному ключу данные, то сервер это поймёт, и загрузка будет идти быстрее. (Но если данные изначально не отсортированы, то вряд ли их удастся отсортировать эффективнее, чем это делает сервер).
При записи в простые таблицы Log/TinyLog, узким местом по CPU будет именно формат данных.
Лучше сначала попробовать загружать, как удобно. Например, формат JSONEachRow, конечно, менее эффективен, но если он оказался удобен для вас, то лучше начать с него.
Ещё замечу, что если данные постоянно загружаются на кластер (в реальном времени) и никогда не удаляются, то постоянный throughput по записи в расчёте на один сервер будет совсем небольшим (так как иначе вы просто за несколько дней заполнили бы все серверы). И при этом, запись не будет упираться в CPU и диски.
По крайней мере, поставлена задача.
Для запуска из корня
./release --standalone, вроде бы, 10 GB должно впритык хватить.А если собираются все таргеты, которые есть в репозитории, то около 30 GB.
Например, DROP TABLE удаляет только локальную таблицу. Если написал DROP TABLE для Distributed-таблицы — удалится только сама Distributed-таблица («вид» на данные), а все данные останутся на месте.
Аналогично для Replicated-таблиц. Если сделал DROP TABLE — удалится одна реплика, и у таблицы станет на одну реплику меньше.
У нас есть задача «распределённые DDL», чтобы можно было одной командой манипулировать со всеми составляющими Distributed-таблиц. Но пока не очень спешим делать. К тому же, она, на всякий случай, будет работать только при каком-либо «снятом предохранителе».