D
ещё можно вставлять в новый и все старые месяцы с минусом в Collapsing
Size: a a a
2020 May 30
D
т.е. select before insert
D
можно и по расписанию
D
не знаю, кажется зла в большом месте намного меньше зла чем в мутациях по гигантским партам
DT
не знаю, кажется зла в большом месте намного меньше зла чем в мутациях по гигантским партам
Ну если мы ручками раскидаем айдшки по этим же 10-12 партициям, то тут особой разницы в плане размера быть не должно
DT
разве, что не получиться дропать по TTL парты
D
все равно мутация будет по всему парту на каждый устаревший IDшник.
AT
узбагойтезь - все будет хорошо, так или иначе :)
DT
все равно мутация будет по всему парту на каждый устаревший IDшник.
но кстати, допустим что у нас есть 100e9 записей
и есть N уникальных id, примерно 90% N есть в каждом месяце
и возможны две ситуации:
при мерже парта с месячным партицированием
у клика в парте будет 0.9N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
при мерже парта с партицированием по допустим intDiv
у клика в парте будет 0.1N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
и есть N уникальных id, примерно 90% N есть в каждом месяце
и возможны две ситуации:
при мерже парта с месячным партицированием
у клика в парте будет 0.9N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
при мерже парта с партицированием по допустим intDiv
у клика в парте будет 0.1N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
D
Al T
узбагойтезь - все будет хорошо, так или иначе :)
хорошо уже ничего не будет =) все будет плохо, но насколько плохо - ещё только предстоит понять...
DT
но кстати, допустим что у нас есть 100e9 записей
и есть N уникальных id, примерно 90% N есть в каждом месяце
и возможны две ситуации:
при мерже парта с месячным партицированием
у клика в парте будет 0.9N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
при мерже парта с партицированием по допустим intDiv
у клика в парте будет 0.1N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
и есть N уникальных id, примерно 90% N есть в каждом месяце
и возможны две ситуации:
при мерже парта с месячным партицированием
у клика в парте будет 0.9N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
при мерже парта с партицированием по допустим intDiv
у клика в парте будет 0.1N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
Но тут нужно углублятся в алгоритм мержа Replacing, на каком этапе он схлопывает ненужные более записи
D
но кстати, допустим что у нас есть 100e9 записей
и есть N уникальных id, примерно 90% N есть в каждом месяце
и возможны две ситуации:
при мерже парта с месячным партицированием
у клика в парте будет 0.9N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
при мерже парта с партицированием по допустим intDiv
у клика в парте будет 0.1N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
и есть N уникальных id, примерно 90% N есть в каждом месяце
и возможны две ситуации:
при мерже парта с месячным партицированием
у клика в парте будет 0.9N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
при мерже парта с партицированием по допустим intDiv
у клика в парте будет 0.1N уникальных айдшников и их нужно хранить в оперативной памяти во время мержа и тд
поэтому говорю и то и то.
т.е. toYYYYMM(dt), <partitionID/intDiv.N/substr>
т.е. toYYYYMM(dt), <partitionID/intDiv.N/substr>
DT
поэтому говорю и то и то.
т.е. toYYYYMM(dt), <partitionID/intDiv.N/substr>
т.е. toYYYYMM(dt), <partitionID/intDiv.N/substr>
Ну тогда это все упирается в вопрос, насколько они готовы пожертвовать местом, да
D
ладно, ОП все равно ушел в закат =)
DT
@souz9 тут вашу ситуацию еще разок обсудили, и меня справедливо поправили на счет ключа партицирования.
Либо ключ выносить в отдельный столбик, что бы min_max работал(будет всего 1 значение в нем), тогда можно любую функцию натравливать
Либо использовать только такие функции. что не испортят min_max
Либо ключ выносить в отдельный столбик, что бы min_max работал(будет всего 1 значение в нем), тогда можно любую функцию натравливать
Либо использовать только такие функции. что не испортят min_max
DT
ладно, ОП все равно ушел в закат =)
мы можем еще разок призвать :)
mc
Привет, из логов метрики поля parsedParamsKeyN прилетают в виде строки
примерно, вот такие строки
Можно как то их сразу сложить в КХ в виде массива, не обрабатывая скаченные файлы?
примерно, вот такие строки
"[""text"",""text""]"Можно как то их сразу сложить в КХ в виде массива, не обрабатывая скаченные файлы?
DT
Привет, из логов метрики поля parsedParamsKeyN прилетают в виде строки
примерно, вот такие строки
Можно как то их сразу сложить в КХ в виде массива, не обрабатывая скаченные файлы?
примерно, вот такие строки
"[""text"",""text""]"Можно как то их сразу сложить в КХ в виде массива, не обрабатывая скаченные файлы?
сделать таблицу с движком Null на нее повесить Mat View с нужным тебе преобразованием
mc
сделать таблицу с движком Null на нее повесить Mat View с нужным тебе преобразованием
Спасибо!
mc
сделать таблицу с движком Null на нее повесить Mat View с нужным тебе преобразованием
В массив преобразовывать придется реплейсами или как-то умнее можно?