в одной таблице ReplacingMergeTree. Ключей сортировки 30 колонок из 150 по которым будет дедублицироваться данные в таблице, если все эти 30 колонок имеют одинаковое значение в двух строках то происходит дедубликация. В этих 150 колонок каждая строка будет полезной инфы иметь колонок 20-30, все остальные колонки в строке будут пустые. Так сделал чтобы не разбивать инфу на 10 таблиц, а хранить всё в одной таблице для последующего упрощения SQL запросов без джойнов и подзапросов для селектов инфы. Но здесь встаёт вопрос о производительности т.к 30+ колонок под ключём сортировки. Не лучше ли будет сделать ключ сортировки по одной отдельной колонке в которой будет храниться хеш значений из этих 30 колонок с помощью к примеру функции sipHash64? Или есть какие то лучшие решения в контексте моего случая?
всё-таки непонятно зачем нужны пустые колонки и что это может упрощать. может просто вьюху поверх сделать в которой будет select '' as bullshit_empty_column_number_75, ...
К примеру есть 10 разных таблиц с разными данными, но все они связаны по id. Таблица №1 имеет колонки id,a1,a2,a3...a10 Таблица #2 имеет колонки id,b1,b2,b3....b10 и т.д в 10 разных таблицах В каждой таблице есть 10 колонок, я хочу сделать одну таблицу. В итоге большая таблица будет со списком колонок типо такого: id, a1,a2,a3..a10, b1,b2,b3...b10 и тд (это названия колонок в таблице. Но при этом инсерты в эту большую таблицу если говорить деклоративно будут "создай строку с таким то id и такими то значениями a1,a2,a3...,a10" все остальные колонки (b1...b10) проставятся пустые значения (через DEFAULT). Ключи сортировки будут по колонкам id, a1, b1, c1, d1 и т.п (около 30 колонок) И таким образом если во всех 30 колонках данные совпадают то дублирующие строки будут убираться. Т.к. в моём случае из 10 текущих таблиц приходится писать громадные и не удобные селекты т.к. почти все запросы селектят сразу из 5-10 таблиц по несколько колонок что выливается в простыню джойнов, подзапросов или intersect'ов. При хранении всех данных в одной таблице я вижу сильное упрощение SQL запросов для селектов. Но при этом нужно реплейсить дубликаты. Поэтому думаю как лучше сделать, 30 колонок с ключём сортировки по которым будет проходить реплейс данных или одну колонку с ключём сортировки которая будет содержать в себе только уникальный хеш от значений в этих 30 колонках? Не знаю смог ли объяснить что имею в виду. Вижу в подходе с хешем лучшее решение в данной ситуации, но возможно упускаю какие то серьёзные проблемы который этот подход может породить...
если я верно всё понял что 10 таблиц с ReplacingMergeTree над которыми сделан март в виде вьюхи с джоинами будет работать быстрее и на вставки и на селекты. ну стаднартное решение и не противоречит вашему тз
Попробуйте не JOIN, а Union ALL и просуммируйте через материализованную view
обратите внимание, что существование такой таблицы на сервере может потребовать значительного объема оперативной памяти, CH держит primary key таблиц в оперативке
Обсуждают сегодня