колонки для сортировки и соответственно улучшения перфоманса? Или в этом нет смысла?
РК таблицы id, но допустим есть поля которые я хотел бы добавить в order by для skip index тк например есть типы транзакций
так вы ж тогда логику удаления строк сломаете, если к ключу еще добавите полей
ну вот в этом и вопрос, допустим id+type+method все еще уникальная строка из-за id. Хочется понять есть ли способ как то replacing ускорить аналогично обычному merge tree
тогда нет смысла у вас на первом месте уникальное поле, все последующие поля можно считать рандомно распределенными, скипать будет нечего
если, конечно, у вас нет какой-то зависимости, что только у определенного интервала подмножества id есть определенный type
неа нету, но таблица хорошо делится на type и method допустим, что в обычном merge tree очень бы все ускорило( id = Uint64
а чем replacing отличается от обычного mergetree? скорость будет одинаковая при одинаковом ORDER BY(вернее сказать PRIMARY KEY). Возможно имеет смысл сделать type, method, id => по увеличению кардинальности
я понимаю про order by, но тогда же поменяется ключ для удаления новых строк
так вы же сказали что > id+type+method все еще уникальная строка
тогда ключ надо делать (type, method, id) — от большего к меньшему
вот в этом и был вопрос, значит смысл есть Мерси Иван и Константин)
вообще высококардинальное поле на первом месте индекса, это не для olap, это для всяких баз, где надо по айди достать одну строчку или один документ а olap запросы — это традиционно агрегаты по большим срезам данных, так что надо "вкладывать" меньшие срезы в бОльшие
нене, я знаю принципы построения индекса в клике, возможно не так сформулировал первичный вопрос сейчас только по id индекс вопрос был в том что есть ли смысл в целом добавлять type и method в order by и будет ли он работать в replacing то что type, method, id для меня само собой))
в принципе ответы на вопросы легко найти тестами если вы делаете выборки и группировки по другим полям, то, скорее всего, смысл есть как правильно выше ответили, нужно при этом понимать про гранулярности и, вероятно, уносить ID с первого места но если вы делаете связи по ID, то, может, унасть его в глубь и не надо тут нет универсального ответа так же от добавления полей в ключ меняется и поведение мерджа
Обсуждают сегодня