Мы еще пару индексов стандартных сделали clustering=yes.
Но есть маленький затык, сейчас будем обновляться до 2.4, а там сервер сам создает временные таблицы и вот как то пока не уверены как пройдет :)
Вы мне весь мир DWH сломали со своим локом.
Был на highload, Николай Голов из Avito. И я спросил, откуда у вам могли взяться локи таблиц, и он сказал, что нужно смотреть в сторону Transaction Isolation Level потому, что есть глюк у JDBC драйвера выставлять не READ COMMITED
Надеюсь ничего не переврал. :)
Мне почему кажется, что да, если у вас есть постоянные запросы с не меняющейся функцией агрегации, то наверно есть смысл превратить его pre-join projection, и это проекция будет пересчитываться, про обновление таблицы фактов vertica.tips/2014/03/05/pre-join-projections-overview/
Я вот тоже не понял где у них LOCK то возникает, если у них это COPY то по дефолту он в WOS загружает. И не должно быть никакого лока.
А у вас 25 млн строк это в мегах сколько?
А все увидел у вас метод DIRECT, да он сразу в ROS грузит, и рекомендуется при загрузке файлов более 100 мегов.
есть встроенная функция json_encode()
в конфиг сервера.
Мы еще пару индексов стандартных сделали clustering=yes.
Но есть маленький затык, сейчас будем обновляться до 2.4, а там сервер сам создает временные таблицы и вот как то пока не уверены как пройдет :)
Был на highload, Николай Голов из Avito. И я спросил, откуда у вам могли взяться локи таблиц, и он сказал, что нужно смотреть в сторону Transaction Isolation Level потому, что есть глюк у JDBC драйвера выставлять не READ COMMITED
Надеюсь ничего не переврал. :)
Мне прям кажется это под ваши задачи.
Работаете на бесплатном комьюните терабайте? :)
vertica.tips/2014/03/05/pre-join-projections-overview/
А у вас 25 млн строк это в мегах сколько?
А все увидел у вас метод DIRECT, да он сразу в ROS грузит, и рекомендуется при загрузке файлов более 100 мегов.
вы, что данные INSERT вставляете?
стопяти лет…