Size: a a a

2019 November 14

К

Какой-то Хмырь in sql_ninja
Vladimir
А что предметная область?
50тб это за какое время данные?
Какой типичный запрос на данные? Отчеты за последний месяц? Или нужно делать всякие условные анализы, при которых каждый день весь объем данных собираются пересчитывать?
Теперь я знаю, какие входные данные требовать))
источник

T

Timus in sql_ninja
Kostya
Не индексы фуфельные, а фуфил они по сравнению с найтив колоночным хранением :)))
Но вот коллеги поправляют про 2019-й меня. тут я пас, не пользовал.
И не могу ничего сказать про загон этих индексов, ну то бишь таблиц на них в память, в ин-мемори, какие там ограничениЯ тоже не в курсе.
на сколько я слышу от коллег (пока еще не добрался) то дело не только в хранении данных в колоночных, но и в добавлении/обнолении/удалении записей. тут свой гемморой. особенный
источник

K

Kostya in sql_ninja
Yukari I
Экза
Работал только с х7-2 1/4
Не могу сказать за петабайты, пару десятков терабайт ворочат только в путь
источник

K

Kostya in sql_ninja
Timus
на сколько я слышу от коллег (пока еще не добрался) то дело не только в хранении данных в колоночных, но и в добавлении/обнолении/удалении записей. тут свой гемморой. особенный
О да, если это делать с колоночными данными, это жесть.
источник

K

Kostya in sql_ninja
Какой-то Хмырь
Теперь я знаю, какие входные данные требовать))
Если ты сходу мелкомягким заявишь про свои терабайты, их манагеры уже себе отдых на канарах рисовать начнут :)))
источник

K

Kostya in sql_ninja
Постепенно надо присовывать :)))
источник

V

Vladimir in sql_ninja
Timus
на сколько я слышу от коллег (пока еще не добрался) то дело не только в хранении данных в колоночных, но и в добавлении/обнолении/удалении записей. тут свой гемморой. особенный
Ну естественно тут там есть нюансы, но это именно особенность коло ночного индекса, который дает тебе сжатие и колон очный доступ.
Если ты часто меняешь данные в колоночном индексе - скорее всего ты делаешь что то не так.
Они нужны обычно для истории аналитики - разбиваешь все на секции и при изменении перегружатель секцию
источник

К

Какой-то Хмырь in sql_ninja
Kostya
Если ты сходу мелкомягким заявишь про свои терабайты, их манагеры уже себе отдых на канарах рисовать начнут :)))
Подозреваю, что поэтому они так и засуетились)
источник

YI

Yukari I in sql_ninja
Kostya
Работал только с х7-2 1/4
Не могу сказать за петабайты, пару десятков терабайт ворочат только в путь
Так пб ворочать и не надо, они ж архивные. Раз  в год на них отчетик построить и все
источник

V

Vladimir in sql_ninja
Какой-то Хмырь
Теперь я знаю, какие входные данные требовать))
Сделай призыв через @ как будет инфа, пжлста)
источник

K

Kostya in sql_ninja
Yukari I
Так пб ворочать и не надо, они ж архивные. Раз  в год на них отчетик построить и все
Тогда экза - лучшее решение, но там жеж оракл или похрен ?
источник

К

Какой-то Хмырь in sql_ninja
Vladimir
Сделай призыв через @ как будет инфа, пжлста)
Конечно, с радостью)
источник

T

Timus in sql_ninja
Vladimir
Ну естественно тут там есть нюансы, но это именно особенность коло ночного индекса, который дает тебе сжатие и колон очный доступ.
Если ты часто меняешь данные в колоночном индексе - скорее всего ты делаешь что то не так.
Они нужны обычно для истории аналитики - разбиваешь все на секции и при изменении перегружатель секцию
они везде есть. но что делать, когда надо туда смерджить данные за месяц?) я не работал с ними и холиварить не буду.
источник

YI

Yukari I in sql_ninja
Kostya
Тогда экза - лучшее решение, но там жеж оракл или похрен ?
Оракл прекрасен. Поюзал его, теперь не хочу обратно на мс, если честно. Хотя своих проблем хватает, да.
источник

V

Vladimir in sql_ninja
Timus
они везде есть. но что делать, когда надо туда смерджить данные за месяц?) я не работал с ними и холиварить не буду.
Есть подход.
Секциями, итерационно. Размер секции должен быть адекватным.
Выгружаешь новые и старые в etl и в памяти мержишь. Вгружаешь в тмп таблицу и свитчишь ее в основную таблицу
источник

K

Kostya in sql_ninja
Vladimir
Есть подход.
Секциями, итерационно. Размер секции должен быть адекватным.
Выгружаешь новые и старые в etl и в памяти мержишь. Вгружаешь в тмп таблицу и свитчишь ее в основную таблицу
Да, годный подход.
Но лучше не мержить :)))
источник

K

Kostya in sql_ninja
Yukari I
Оракл прекрасен. Поюзал его, теперь не хочу обратно на мс, если честно. Хотя своих проблем хватает, да.
Ну ... экза так же точно вне конкуренции как программно аппаратный комплекс по цена-производительность
Но там саппорт отдельная тама
источник

T

Timus in sql_ninja
@yoycheg то есть у меня есть 10млн записей, которые я хочу смерджить. то надо выгрузить что есть в КолумнСторе, смерждить с тем что хочу залить, выкинуть это в темповую таблицу и потом сделать свитч партиции?
источник

T

Timus in sql_ninja
повторюсь, я не работал с этой технологией
источник

K

Kostya in sql_ninja
Timus
@yoycheg то есть у меня есть 10млн записей, которые я хочу смерджить. то надо выгрузить что есть в КолумнСторе, смерждить с тем что хочу залить, выкинуть это в темповую таблицу и потом сделать свитч партиции?
угу
источник