Комментарии 9
картинки будут? )
Картинки чего? Работников компании, презентаций, котиков? ;)
Презентации здесь: www.vertica.com/
Описание Vertica под проект здесь: ascrus.blogspot.ru/2013/02/hp-vertica.html
Повод для холиваров по выбору платформы здесь: ascrus.blogspot.ru/2013/01/vertica-vs.html
:)
Презентации здесь: www.vertica.com/
Описание Vertica под проект здесь: ascrus.blogspot.ru/2013/02/hp-vertica.html
Повод для холиваров по выбору платформы здесь: ascrus.blogspot.ru/2013/01/vertica-vs.html
:)
Молодцы. Я вчера опять делал доклад на HighLoad, и интерес к Вертике был больше, чем в прошлом году. Много вопросов, в том числе и от тех, кто уже ее использует.
И статья тоже хорошая и подробная. Пара незначительных комментариев.
1. Памяти много не бывает, но Вертика ее расходует достаточно экономно, по сути только на WOS, на hash joins и на hashed group by. Если удается тяжелые запросы «перевести» на piplined group by и merge join — то ура, память расходуется минимально. При использовании очень сложных запросов так, конечно, никогда не получится, но всякие BI-средства обычно генерируют довольно простые запросы на стар-схему.
2. Группировка колонок — это палка о двух концах. С одной стороны — да, колонки вместе читаются как фрагмент строки, а с другой — на группированных колонках не работают енкодинги. У нас получилось, что выгодней держать колонки все же отдельно, выигрыш за счет меньшего размера на диске перевешивает преимущество чтения нескольких колонок «разом».
И статья тоже хорошая и подробная. Пара незначительных комментариев.
1. Памяти много не бывает, но Вертика ее расходует достаточно экономно, по сути только на WOS, на hash joins и на hashed group by. Если удается тяжелые запросы «перевести» на piplined group by и merge join — то ура, память расходуется минимально. При использовании очень сложных запросов так, конечно, никогда не получится, но всякие BI-средства обычно генерируют довольно простые запросы на стар-схему.
2. Группировка колонок — это палка о двух концах. С одной стороны — да, колонки вместе читаются как фрагмент строки, а с другой — на группированных колонках не работают енкодинги. У нас получилось, что выгодней держать колонки все же отдельно, выигрыш за счет меньшего размера на диске перевешивает преимущество чтения нескольких колонок «разом».
Спасибо за оценку моей статьи :) Тоже очень интересно было почитать про Ваш доклад.
По поводу группировки колонок — имеет смысл ее делать для полей фактов, которые используются почти всегда вместе. На примере телекома — поля Download, Upload, Duration почти всегда тащатся в запросах вместе, для анализа и расчета объема и скорости трафика. Енкодинг на них не нужен, это чистые цифры, которые красиво не упаковать. А вот их чтение с одного места повышает эффективность запросов, так как вместо чтения и соединения трех колонок, считывается и далее рассчитывается сразу одним проходим все три колонки. Ну а поля измерения же конечно нельзя объединять в группы, получится деградация производительности :)
P.S. Давайте дружить на почве Вертики и не только :) Сейчас мы для расширения помощи экспертизы в России организовали компанию easydata.ru, специализирующуюся как раз по Большим Данным и Vertica. Скоро подключим экспертизу и по Cassandra. Занимаемся с вами фактически на одних и тех же технологиях, можем обмениваться опытом, удачным и не очень :)
По поводу группировки колонок — имеет смысл ее делать для полей фактов, которые используются почти всегда вместе. На примере телекома — поля Download, Upload, Duration почти всегда тащатся в запросах вместе, для анализа и расчета объема и скорости трафика. Енкодинг на них не нужен, это чистые цифры, которые красиво не упаковать. А вот их чтение с одного места повышает эффективность запросов, так как вместо чтения и соединения трех колонок, считывается и далее рассчитывается сразу одним проходим все три колонки. Ну а поля измерения же конечно нельзя объединять в группы, получится деградация производительности :)
P.S. Давайте дружить на почве Вертики и не только :) Сейчас мы для расширения помощи экспертизы в России организовали компанию easydata.ru, специализирующуюся как раз по Большим Данным и Vertica. Скоро подключим экспертизу и по Cassandra. Занимаемся с вами фактически на одних и тех же технологиях, можем обмениваться опытом, удачным и не очень :)
У нас много нулей, поэтому чистые цифры как правило, удавалось всегда упаковать, и выигрыша за счет использования группировок не было. Но если у Вас данные сильно вариативные — то да, наверное.
Давайте дружить, конечно. «Мы организовали» — это кто? У меня давно сидит в голове мысль, что у нас не хватает хорошего консалтинга по системам больших данных. Типа как Percona делает для MySQL.
Давайте дружить, конечно. «Мы организовали» — это кто? У меня давно сидит в голове мысль, что у нас не хватает хорошего консалтинга по системам больших данных. Типа как Percona делает для MySQL.
Мы, это разработчики проекта хранилища данных для Йота :) Решили выделится в отдельную единицу в России и заняться экспертизой по большим данным, в первую очередь занимаясь Vertica как партнеры HP и продуктами, которые с ней хорошо дружат. Не все кстати из последних представлены в России, вот потихоньку налаживаем контакты и дружеские отношения. Дальше если интересно, мое мыло ascrus@easydata.ru :)
>что BIGINT в каком-то случае это значение факта, а в каком-то идентификатор измерения,
Лучше написать так, что в одном случае это бизнес-атрибут, а в другом это суррогатный ключ
>колонко-ориентированные СУБД изначально ориентировались на то
спорное утверждение. Если соединяются 2 колонки из разных таблиц, то колоночное-ориентированная будет лучше.
Если же соединяются все строки со всеми, то строко-ориентированная будет лучше.
Лучше написать так, что в одном случае это бизнес-атрибут, а в другом это суррогатный ключ
>колонко-ориентированные СУБД изначально ориентировались на то
спорное утверждение. Если соединяются 2 колонки из разных таблиц, то колоночное-ориентированная будет лучше.
Если же соединяются все строки со всеми, то строко-ориентированная будет лучше.
>что BIGINT в каком-то случае это значение факта, а в каком-то идентификатор измерения,
Лучше написать так, что в одном случае это бизнес-атрибут, а в другом это суррогатный ключ
>колонко-ориентированные СУБД изначально ориентировались на то
спорное утверждение. Если соединяются 2 колонки из разных таблиц, то колоночное-ориентированная будет лучше.
Если же соединяются все строки со всеми, то строко-ориентированная будет лучше.
Я так и не понял, по какому признаку были распределены данные по нодам?
Лучше написать так, что в одном случае это бизнес-атрибут, а в другом это суррогатный ключ
>колонко-ориентированные СУБД изначально ориентировались на то
спорное утверждение. Если соединяются 2 колонки из разных таблиц, то колоночное-ориентированная будет лучше.
Если же соединяются все строки со всеми, то строко-ориентированная будет лучше.
Я так и не понял, по какому признаку были распределены данные по нодам?
Привет. Данные по нодам каждой таблицы изначально распределяются по уникальному набору полей (обычно это PK). Однако для detail таблиц, которые имеют FK к master таблице распределение стоит по ключу parent_id, то есть по PK мастер таблицы. Это убирает необходимость при джойне этих таблиц Вертике пересылать записи мастера и детальки между нодами, собирая их для соединения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HP Vertica, первый запущенный проект в РФ, опыт полтора года реальной эксплуатации