ReSQL.ru
     
powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / NoSQL, Big Data [игнор отключен] [закрыт для гостей] / vertica тестирование
5 сообщений из 5, страница 1 из 1
vertica тестирование
    #38797338
вертика_нуб
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вертика_нуб
Гость
Добрый день.

Дошли наконец руки попробовать вертику.

На виртуалку SLES11 SP1 (8VCPU/12GB RAM) поставлена vertica 6.1.3 community edition, создана тестовая база, создана и залита табличка LINEITEM из TPC-H на 300M записей.

Гоняю (через vsql) q1.sql из TPC-H (фуллскан без предиката по l_shipdate) :
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
SELECT
        L_RETURNFLAG,
        L_LINESTATUS,
        SUM(L_QUANTITY) AS SUM_QTY,
        SUM(L_EXTENDEDPRICE) AS SUM_BASE_PRICE,
        SUM(L_EXTENDEDPRICE * (1 - L_DISCOUNT)) AS SUM_DISC_PRICE,
        SUM(L_EXTENDEDPRICE * (1 - L_DISCOUNT) * (1 + L_TAX)) AS SUM_CHARGE,
        AVG(L_QUANTITY) AS AVG_QTY,
        AVG(L_EXTENDEDPRICE) AS AVG_PRICE,
        AVG(L_DISCOUNT) AS AVG_DISC,
        COUNT(*) AS COUNT_ORDER
FROM
   LINEITEM

GROUP BY
        L_RETURNFLAG,
        L_LINESTATUS
ORDER BY
        L_RETURNFLAG,
        L_LINESTATUS;



При первом запуске и чтении с диска (150-160 MB/sec) выполняется за 35-36 сек.
При последующих запусках и чтении из кэша (disk i/o нет совсем) выполняется за 21-22 сек.
При этом утилизируется CPU порядка 450-500% (из 800% доступных), в nmon'е видно, что работают 5-6 VCPU.

Решил посмотреть, что будет с проекциями.
Прогнал q1.sql через Database Designer, он создал проекцию :
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
CREATE PROJECTION LINEITEM_DBD_1_rep_q2_test /*+createtype(D)*/
(
 l_quantity ENCODING RLE,
 l_extendedprice ENCODING AUTO,
 l_discount ENCODING RLE,
 l_tax ENCODING RLE,
 l_returnflag ENCODING RLE,
 l_linestatus ENCODING RLE
)
AS
 SELECT l_quantity,
        l_extendedprice,
        l_discount,
        l_tax,
        l_returnflag,
        l_linestatus
 FROM public.LINEITEM
 ORDER BY l_returnflag,
          l_linestatus,
          l_tax,
          l_discount,
          l_quantity,
          l_extendedprice
UNSEGMENTED ALL NODES;

select refresh('public.LINEITEM');



Теперь она используется в плане :
Код: sql
1.
2.
3.
4.
5.
6.
7.
 Access Path:
 +-GROUPBY PIPELINED [Cost: 2M, Rows: 3] (PATH ID: 2)
 |  Aggregates: sum(LINEITEM.l_quantity), sum(LINEITEM.l_extendedprice), sum((LINEITEM.l_extendedprice * (1 - LINEITEM.l_discount))), sum(((LINEITEM.l_extendedprice * (1 - LINEITEM.l_discount)) * (1 + LINEITEM.l_tax))), sum_float(LINEITEM.l_quantity), count(LINEITEM.l_quantity), sum_float(LINEITEM.l_extendedprice), count(LINEITEM.l_extendedprice), sum_float(LINEITEM.l_discount), count(LINEITEM.l_discount), count(*)
 |  Group By: LINEITEM.l_returnflag, LINEITEM.l_linestatus
 | +---> STORAGE ACCESS for LINEITEM [Cost: 2M, Rows: 300M] (PATH ID: 3)
 | |      Projection: public.LINEITEM_DBD_1_rep_q2_test_node0001
 | |      Materialize: LINEITEM.l_returnflag, LINEITEM.l_linestatus, LINEITEM.l_tax, LINEITEM.l_discount, LINEITEM.l_quantity, LINEITEM.l_extendedprice



....но время выполнения из кэша стало 65-70 сек. :((
и при этом как-будто отключился параллелизм (работает только один VCPU)

Сделал
Код: sql
1.
2.
3.
select analyze_statistics('LINEITEM');

SELECT ANALYZE_HISTOGRAM('LINEITEM',100);



и рестартил базу, но все равно тоже самое.

Если дропнуть проекцию, то рантайм возвращается на 21-22 сек.

Подскажите, плз, что делаю не так. Может какие параметры базы/ресурс-пула'ов/etc подкрутить надо ?
...
Рейтинг: 0 / 0
06.11.2014, 14:33
| Ответить | Цитировать | Написать  
vertica тестирование
    #38797927
BoobenCom2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
BoobenCom2
Гость
150 МБ/сек ?
Что за железо ?
...
Рейтинг: 0 / 0
07.11.2014, 00:24
| Ответить | Цитировать | Написать  
vertica тестирование
    #38801347
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Привет. А DDL таблички то какой? И как часто данные повторяются в столбцах, которые не участвуют в группировках? А то дизайнер так проекцию сделал, как будто там одни дубли значений полей.
...
Рейтинг: 0 / 0
10.11.2014, 21:50
| Ответить | Цитировать | Написать  
vertica тестирование
    #38802489
вертика_нуб
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вертика_нуб
Гость
ASCRUSПривет. А DDL таблички то какой? И как часто данные повторяются в столбцах, которые не участвуют в группировках?
DDL вот такой :
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
CREATE TABLE public.LINEITEM
(
    l_orderkey int NOT NULL,
    l_partkey int NOT NULL,
    l_suppkey int NOT NULL,
    l_lineBIGINT int NOT NULL,
    l_quantity int NOT NULL,
    l_extendedprice numeric(37,15) NOT NULL,
    l_discount numeric(37,15) NOT NULL,
    l_tax numeric(37,15) NOT NULL,
    l_returnflag char(1) NOT NULL,
    l_linestatus char(1) NOT NULL,
    l_shipdate date NOT NULL,
    l_commitdate date NOT NULL,
    l_receiptdate date NOT NULL,
    l_shipinstruct varchar(25) NOT NULL,
    l_shipmode varchar(10) NOT NULL,
    l_comment varchar(44) NOT NULL
);



По распределению других колонок примерно как-то так :
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
TESTVERT=> select count(distinct(l_shipdate)) from lineitem;
 count
-------
  2526
(1 row)

TESTVERT=> select count(distinct(l_orderkey)) from lineitem;
  count
----------
 75000000
(1 row)

TESTVERT=> select count(distinct(l_suppkey)) from lineitem;
 count
--------
 500000
(1 row)

TESTVERT=> select count(distinct(l_partkey)) from lineitem;
  count
----------
 10000000
(1 row)

TESTVERT=> select distinct(count(l_lineBIGINT)) from lineitem;
   count
-----------
 300005811
(1 row)




Еще заметил, что если добавить к верхнему запросу простой предикат а-ля

Код: sql
1.
WHERE L_SHIPDATE BETWEEN '1995-01-01' AND '1995-12-31'



То время выполнения одинаковое с фулсканом, а вот если на этот запрос с предикатом сделать DBD-ом проекцию, то отлетает за 3 сек. Но ведь на каждый фильтр проекций-то не наделаешься....


А 6.1.3 CE можно как-то проапгрейдить на 7.1.1 CE ?
...
Рейтинг: 0 / 0
11.11.2014, 17:28
| Ответить | Цитировать | Написать  
vertica тестирование
    #38806295
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Проапгрейтить можно. Лучше сделать апдейт пошагово сначала на 7-ку, потом 7.1. В доке описано как запустить не инсталл, а апдейт, база нормально переведется. Если в базе уже что то ценное, то лучше сделать бакуп перед апдейтами. Если места для бакупа особо нет, то можно сделать hard-link бакуп прямо на самом кластере, потом если все будет нормально, папку с ним удалить на всех нодах.

По поводу запроса: а по колонкам l_tax, l_discount, l_quantity, l_extendedprice каково распределение ? Сама проекция вполне верна и план запроса нормальный (GROUPBY PIPELINED гораздо шустрее и менее ресурсоемкий, чем GROUPBY HASH), Но смущает сортировка по этим фактовым полям и тип кодировки RLE. Попробуйте убрать их из сортировки проекции, переделав ее:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
CREATE PROJECTION LINEITEM_DBD_1_rep_q2_test /*+createtype(D)*/
(
 l_quantity ENCODING DELTAVAL,
 l_extendedprice ENCODING GCDDELTA,
 l_discount ENCODING GCDDELTA,
 l_tax ENCODING GCDDELTA,
 l_returnflag ENCODING RLE,
 l_linestatus ENCODING RLE
)
AS
 SELECT l_quantity,
        l_extendedprice,
        l_discount,
        l_tax,
        l_returnflag,
        l_linestatus
 FROM public.LINEITEM
 ORDER BY l_returnflag,
          l_linestatus
UNSEGMENTED ALL NODES;

select refresh('public.LINEITEM');


Еще такой момент - сколько серверов в кластере 1, 3 или больше ? Если серверов от 3, то надо сделать не "UNSEGMENTED ALL NODES", а "SEGMENTED BY HASH(ПоляОпределяющиеУникальностьЗаписи) ALL NODES KSAFE 1".

P.S. На каждый запрос проекцию создавать не надо. Если например по этой табличке часто идет серия запросов с фильтрацией по L_SHIPDATE, то значит создаем проекцию с сортировкой по этому полю (или же вообще супер проекцию сразу с такой сортировкой и создаем), дальше все запросы, которые режут выборку по этой дате уходят на такую проекцию и выполняются моментально, если выбирается небольшой интервал. Вертика по проекции сразу же ограничивает круг записей, дальше уже на малом объеме записей для MPP и оптимизация дальнейшая особо не нужна, все и так выполняется влет.
...
Рейтинг: 0 / 0
14.11.2014, 13:42
| Ответить | Цитировать | Написать  
5 сообщений из 5, страница 1 из 1
Форумы / NoSQL, Big Data [игнор отключен] [закрыт для гостей] / vertica тестирование
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=48&msg=38806295&tid=1856867]:
 0ms
get settings:
 12ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 45ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 52ms
get tp. blocked users:
 2ms
others: 254ms
total:  402ms
созд. / загр.: 402ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]