Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 Re: Vertica vs Netezza vs Grennplum  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Alexander Ryndin
ASCRUS
пропущено...

кстати коммерческий Talend замечательно CDC поддерживает для всех основных вендоров.
Ну для СУБД Oracle Talend использует LogMiner, либо триггеры, что, как бы, не очень хорошо - тормоза еще те.
MSSQL 2005 я не понимаю, как они могут поддерживать, кроме как с помощью триггеров.
Ну и давайте ссылку про "замечательно", а то как-то оно голословно ;)

Не дам. Тема не про это. Что умеет субд по cdc, то и поддерживается. Если ничего не умеет, разруливается дедовским timestamp и триггерами. А в mssql штатно cdc через триггера сделано. Я плотно работаю с Talend, будет время, потом как нибудь расскажу.
21 мар 12, 07:01    [12285337]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
MasterZiv
Vovaka,

а что за проект?
какие данные?

и 100 терабайт — это сколько в записях?


100ТБ - это оценочная прикидка года через 3.

Телеком. Ну вот типичный пример одной из многих сущностей: сейчас порядка 100 млн записей в сутки, далее будет только расти, сырые данные нужны как минимум месяца 3, далее можно слегка агрегировать + нужно еще сразу несколько агрегатов держать. Есть еще нетипичные примеры, когда записей в секунду сейчас порядка 200 тысяч. Т.е. порядка 17 млрд записей в сутки :) Тут не нужно ничего агрегировать, нужен просто быстрый поиск.
21 мар 12, 10:21    [12285858]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
mijatovic
Member

Откуда:
Сообщений: 31
Интересная задача и OLTP и DWH в одном.
В случае GreenPlum и Netezza будут проблемы с загрузкой одиночных записей. ETL процесс на этих системах отдельная задача(про Sybase ничего сказать не могу). Для этого больше подходит Oracle или MS SQL SERVER. Если рассматривать ExaData - то хранить 100 Тб на ней действительно дороговато(кстати, учтен ли рост притока данных с течением времени?). Тут надо думать над 2 уровнем хранилища. Если по историческим данным надо проводить аналитику - можно задуматься над hadoop. Если нужны select only операции (применимо к историческим данным), то это какая-нибудь NoSQL база. В ExaData,кстати, есть гибридная компрессия, которая на некотором пофиле данных весьма не плохо жмет (во что превратятся 100 Тб - это еще вопрос). Тут надо говорить к контектсте того сколько стоит хранить 1 Тб "сырых" данных
Вот пакетик, которым можно оценить сжатие, попробуйте:
http://uhesse.com/2011/09/12/dbms_compression-example
http://www.morganslibrary.com/reference/pkgs/dbms_compression.html
21 мар 12, 11:36    [12286473]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 03/21/2012 11:21 AM, Vovaka wrote:

> Телеком. Ну вот типичный пример одной из многих сущностей: сейчас порядка 100
> млн записей в сутки, далее будет только расти, сырые данные нужны как минимум
> месяца 3, далее можно слегка агрегировать + нужно еще сразу несколько агрегатов

3 миллиарда в месяц.

> держать. Есть еще нетипичные примеры, когда записей *в секунду *сейчас порядка
> *200 тысяч*. Т.е. порядка 17 млрд записей в сутки :) Тут не нужно ничего
> агрегировать, нужен просто быстрый поиск.

17 млрд записей в сутки -- это интересно. Это сколько же в месяц ? 510
миллиардов. Солидно.

Надо оборудование хорошее для этого, кластерок этак машин на ... --
блин, 80 получается. Это уже не шутки, это много.

Posted via ActualForum NNTP Server 1.5

21 мар 12, 11:43    [12286538]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
mijatovic
Интересная задача и OLTP и DWH в одном.
В случае GreenPlum и Netezza будут проблемы с загрузкой одиночных записей. ETL процесс на этих системах отдельная задача(про Sybase ничего сказать не могу). Для этого больше подходит Oracle или MS SQL SERVER. Если рассматривать ExaData - то хранить 100 Тб на ней действительно дороговато(кстати, учтен ли рост притока данных с течением времени?). Тут надо думать над 2 уровнем хранилища. Если по историческим данным надо проводить аналитику - можно задуматься над hadoop. Если нужны select only операции (применимо к историческим данным), то это какая-нибудь NoSQL база. В ExaData,кстати, есть гибридная компрессия, которая на некотором пофиле данных весьма не плохо жмет (во что превратятся 100 Тб - это еще вопрос). Тут надо говорить к контектсте того сколько стоит хранить 1 Тб "сырых" данных
Вот пакетик, которым можно оценить сжатие, попробуйте:
http://uhesse.com/2011/09/12/dbms_compression-example
http://www.morganslibrary.com/reference/pkgs/dbms_compression.html


Ну в общем 2 уровня скорее всего и будет, а то еще и третий, под холодные данные
Одиночных инсертов конечно же не будет все таки, все равно порциями, другой вопрос, что их может быть много маленьких и постоянным потоком, и тут если их так и грузить, то IQ сильно просаживается, ему их клеить нужно и чем больше тем лучше, что не всегда уже реализуемо малой кровью
21 мар 12, 11:51    [12286609]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
MasterZiv
On 03/21/2012 11:21 AM, Vovaka wrote:

> Телеком. Ну вот типичный пример одной из многих сущностей: сейчас порядка 100
> млн записей в сутки, далее будет только расти, сырые данные нужны как минимум
> месяца 3, далее можно слегка агрегировать + нужно еще сразу несколько агрегатов

3 миллиарда в месяц.

> держать. Есть еще нетипичные примеры, когда записей *в секунду *сейчас порядка
> *200 тысяч*. Т.е. порядка 17 млрд записей в сутки :) Тут не нужно ничего
> агрегировать, нужен просто быстрый поиск.

17 млрд записей в сутки -- это интересно. Это сколько же в месяц ? 510
миллиардов. Солидно.

Надо оборудование хорошее для этого, кластерок этак машин на ... --
блин, 80 получается. Это уже не шутки, это много.


Ну это исключение конечно, там несколько колонок всего, да и жмется отлично
21 мар 12, 11:57    [12286667]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
mijatovic
Member

Откуда:
Сообщений: 31
автор
Одиночных инсертов конечно же не будет все таки, все равно порциями, другой вопрос, что их может быть много маленьких и постоянным потоком

Вот с этим Oracle замечательно справляется.
Кстати, а данные приходят чистые?
Не думали над тем, что бы создать Stage area перед загрузкой данных, которая будет чистить, конкатенировать данные, и только потом грузить оптимальным для базы способом?
21 мар 12, 12:07    [12286749]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
mijatovic
автор
Одиночных инсертов конечно же не будет все таки, все равно порциями, другой вопрос, что их может быть много маленьких и постоянным потоком

Вот с этим Oracle замечательно справляется.
Кстати, а данные приходят чистые?
Не думали над тем, что бы создать Stage area перед загрузкой данных, которая будет чистить, конкатенировать данные, и только потом грузить оптимальным для базы способом?


С этим проблем как раз совсем нет в подавляющем большинстве случаев, machine generated - все чисто.
21 мар 12, 12:09    [12286769]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709


> Для этого больше подходит Oracle или MS SQL SERVER.

Вот уж что меньше всего подходит, так эти два.

Posted via ActualForum NNTP Server 1.5

21 мар 12, 12:18    [12286848]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
mijatovic
Member

Откуда:
Сообщений: 31
автор
Вот уж что меньше всего подходит, так эти два.

Я имел ввиду загрузку множества одиночных записей, возможно был не правильно понят.
21 мар 12, 12:25    [12286908]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Забыл пароль
Guest
Vovaka

Ну в общем 2 уровня скорее всего и будет, а то еще и третий, под холодные данные
Одиночных инсертов конечно же не будет все таки, все равно порциями, другой вопрос, что их может быть много маленьких и постоянным потоком, и тут если их так и грузить, то IQ сильно просаживается, ему их клеить нужно и чем больше тем лучше, что не всегда уже реализуемо малой кровью


1. Смотрели IQ 12.7? 15-ка быстрее грузит.
2. Грузили из файлов LOADом? Файлы "fully delimited" (в параллели всё вгружалось)? 200k записей /сек для IQ на нормальной машине - это совсем не много.
3. Если файлов много, то скорость снижается тогда, когда на таблице много индексов HG, Unique HG, PK. Но тогда одни LOADом можно сразу несколько файлов грузить за раз. Или уменьшить кол-во индексов с типом HG - скорость вырастёт прилично. Можно использовать промежуточный Staging, например, в котором минимум индексов с типом HG, а потом всё сбрасывать в нормальные таблички.
4. Файлы формата binary вгружаются намного быстрее чем ASCII. Откуда файлы приходят - можно форматом управлять?
5. Можно побить на партиции (отдельная опция), а можно "бесплатно" сделать отдельные таблички и потом "create view ... select union all". Такая вьюха отрабатывается IQ как "partitioned table" и работает ещё быстрее, чем штатные партиции.
6. Minimize_Storage или IQ UNIQUE стоял везде или выборочно? Тоже влияет на скорость загрузки - сколько колонок в процессе загрузки дополнительно оптимизируется + к компрессии.
7. Полючить представительство Sybase - для такой интересной задачки они не откажут в помощи :)

Короче - поля для деятельности достаточно ...
21 мар 12, 13:34    [12287675]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Забыл пароль
Vovaka
Ну в общем 2 уровня скорее всего и будет, а то еще и третий, под холодные данные
Одиночных инсертов конечно же не будет все таки, все равно порциями, другой вопрос, что их может быть много маленьких и постоянным потоком, и тут если их так и грузить, то IQ сильно просаживается, ему их клеить нужно и чем больше тем лучше, что не всегда уже реализуемо малой кровью


1. Смотрели IQ 12.7? 15-ка быстрее грузит.
2. Грузили из файлов LOADом? Файлы "fully delimited" (в параллели всё вгружалось)? 200k записей /сек для IQ на нормальной машине - это совсем не много.
3. Если файлов много, то скорость снижается тогда, когда на таблице много индексов HG, Unique HG, PK. Но тогда одни LOADом можно сразу несколько файлов грузить за раз. Или уменьшить кол-во индексов с типом HG - скорость вырастёт прилично. Можно использовать промежуточный Staging, например, в котором минимум индексов с типом HG, а потом всё сбрасывать в нормальные таблички.
4. Файлы формата binary вгружаются намного быстрее чем ASCII. Откуда файлы приходят - можно форматом управлять?
5. Можно побить на партиции (отдельная опция), а можно "бесплатно" сделать отдельные таблички и потом "create view ... select union all". Такая вьюха отрабатывается IQ как "partitioned table" и работает ещё быстрее, чем штатные партиции.
6. Minimize_Storage или IQ UNIQUE стоял везде или выборочно? Тоже влияет на скорость загрузки - сколько колонок в процессе загрузки дополнительно оптимизируется + к компрессии.
7. Полючить представительство Sybase - для такой интересной задачки они не откажут в помощи :)

Короче - поля для деятельности достаточно ...


да, 12.7
На все не буду отвечать, понятно, что можно оптимизировать еще, но лицензии ...

мультиплекс из трех серверов, каждый 2 проца х 6 ядер, считаем 36 ядер, из них каждое второе стоит 40 тыщ + 50 тыщ х 2 для мультиплекса итого 820 тыщ + 20% ТП, итого лям. Для сравнения Netezza примерно в той же конфигурации почти в 3 раза дешевле, причем уже с железом. Ну и Sybase CIS всех своих спецов давно профукал и продолжает это с завидным постоянством делать. Майкл в своем репертуаре. В общем ну их в сад :)
21 мар 12, 14:47    [12288482]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Все таки хочется узнать побольше именно про 3 озвученные платформы. Остальное уже за рамками топика.

Завтра кстати все выступают на Big Data, послушаем, может чего интересного расскажут :)
21 мар 12, 15:06    [12288699]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Данные точно необходимо загружать именно в реальном времени или небольшой временной lag допустим? Я очень сомневаюсь, что данные и правда нужны пользователям в ту же секунду, в которую они поступили для загрузки.
Если lag допустим, то писать можно куда угодно, хоть в плоский файл, который после достижения оптимального размера (объем\кол-во строк) скармливается загрузчику и тогда никаких проблем не будет, никакой Оракл, Экзадат тут не нужны.

На счет IQ соглашусь, не стоит оно тех денег, которые за нее просят.
21 мар 12, 19:48    [12291038]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Спрошу чисто для "проформу": Teradata уже рассматривли?
21 мар 12, 19:57    [12291093]     Ответить | Цитировать Сообщить модератору
 Re: Sybase IQ 15.4 Express Edition  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Apex
Данные точно необходимо загружать именно в реальном времени или небольшой временной lag допустим? Я очень сомневаюсь, что данные и правда нужны пользователям в ту же секунду, в которую они поступили для загрузки.
Если lag допустим, то писать можно куда угодно, хоть в плоский файл, который после достижения оптимального размера (объем\кол-во строк) скармливается загрузчику и тогда никаких проблем не будет, никакой Оракл, Экзадат тут не нужны.

согласен. При использовании etl этот вопрос решается без проблем. на самом деле данные с аппаратуры идут пакетами в разных форматах. В пакете может быть и 1 тысяча и 100 тысяч записей. пакет с помощью etl преобразовывается в плоский файл и загружается с использованием пакетной загрузки субд. Netezza и Vertica позволяют грузить эти пакеты параллельно с множества устройств, в IQ придется результат парсинга склеивать перед загрузкой, что означает узкое место и дополнительные телодвижения на etl, чтобы оптимизировать это. Проблема здесь в том, что например если одно устройство генерирует данных в разы больше других, то равномерность поступления данных в ХД от устройств может нарушаться, где по одному устройству данные за последние 5 мин уже доступны, а по другому нет. Но естественно все решаемо ;)
21 мар 12, 20:13    [12291177]     Ответить | Цитировать Сообщить модератору
 Re: Sybase IQ 15.4 Express Edition  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Apex
Спрошу чисто для "проформу": Teradata уже рассматривли?

Для задач хранения и анализа machine generate данных imho терадата жирно выходит. Тем более по условиям задачи топика данные будут хранится за определенный период и потом выносится с ХД. Так что думаю аналог терадаты должен справится за более разумную стоимость.

P.M. А все таки кроме меня кто нибудь на форуме работал с субд такого класса? очень бы хотелось провести обмен опытом.
21 мар 12, 20:21    [12291204]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
ASCRUS
Apex
Спрошу чисто для "проформу": Teradata уже рассматривли?

Для задач хранения и анализа machine generate данных imho терадата жирно выходит.

Ну, Терадата тоже разная бывает, хотя в целом соглашусь.
22 мар 12, 18:52    [12297796]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Apex
Данные точно необходимо загружать именно в реальном времени или небольшой временной lag допустим? Я очень сомневаюсь, что данные и правда нужны пользователям в ту же секунду, в которую они поступили для загрузки.
Если lag допустим, то писать можно куда угодно, хоть в плоский файл, который после достижения оптимального размера (объем\кол-во строк) скармливается загрузчику и тогда никаких проблем не будет, никакой Оракл, Экзадат тут не нужны.

На счет IQ соглашусь, не стоит оно тех денег, которые за нее просят.


Лаг допустим конечно, в разных типах данных разный, но допустим
22 мар 12, 22:45    [12298666]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Apex
Спрошу чисто для "проформу": Teradata уже рассматривли?


Рассматривали, в короткий список не вошла.
22 мар 12, 22:46    [12298668]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Сегодня состоялся форум Bg Data, было довольно интересно. Удалось даже пообщаться с CTO и сооснователем Greenplum, Люком Лонерганом. Молодцы EMC, что пригласили такого человека. Сильный ход. У них несколько коммерческих инсталляций в России, у IBM и HP пока нет ни одной, но с ними тоже интересно было познакомиться. В голове каша, ну в общем примерно паритет. Вертика правда со своей лицензионной политикой конечно шокирует, но в итоге обещают быть не дороже конкурентов. Терадаты кстати почему-то не было, остальные были все.
Sybase порадовал особенно, в конце был розыгрыш призов, так вот от Сайбейза была клава беспроводная с мышкой от Логитека, так хотелось выиграть такой подарок, на всю жизнь память бы осталась, это вот Приз настоящий, не то что другие, всякая фигня, электронные книги и Айпад :)
22 мар 12, 22:57    [12298709]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
bmv_rus
Member

Откуда:
Сообщений: 253
Vovaka
Ну и конечно стоимость лицензий, 40 тыщ баксов каждое второе ядро + 50 за каждый сервер в мультиплексе, начиная со второго.


Это где такие цены ?

Мне показывали офиц. саповский прайс, там за CPU раза в 4 дороже, причем в евро.
И за мультиплексы, за партицирование, за шифрование данных и т.п. дополнительно.

Хотя думаю Vertica vs Netezza vs Grennplum это решения тоже крайне недешевые.
25 мар 12, 13:27    [12309678]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
bmv_rus
Member

Откуда:
Сообщений: 253
Vovaka
Exadata дороговата зараза.

а можно поподробнее ?
От 2х MUSD или более?
25 мар 12, 13:30    [12309689]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
bmv_rus
Vovaka
Ну и конечно стоимость лицензий, 40 тыщ баксов каждое второе ядро + 50 за каждый сервер в мультиплексе, начиная со второго.


Это где такие цены ?

Мне показывали офиц. саповский прайс, там за CPU раза в 4 дороже, причем в евро.
И за мультиплексы, за партицирование, за шифрование данных и т.п. дополнительно.

Хотя думаю Vertica vs Netezza vs Grennplum это решения тоже крайне недешевые.


А может и в Евро. Они считют по ядрам, а не по процам, причем по дефолту 50% скидка на интеловских процах., так что за CPU видимо и выходило дороже. Но в любом случае ценних там негуманный.

Greenplum и Netezza в лоб значительно дешевле, вот Vertica учудила конечно, если первые 2 лицензируют ТБ в сжатом виде, то Vertica сырой, да к тому же в виде текста. Это жесть. Вот выдержка из их доки:

Vertica
The data sampled for the estimate is treated as if it had been exported from the database in text format (such as printed from vsql). This means that Vertica evaluates the data type footprint sizes as follows:

vsql is a character-based, interactive, front-end utility that lets you type SQL statements and see the results. It also provides a number of meta-commands and various shell-like features that facilitate writing scripts and automating a variety of tasks.

•Strings and binary types (CHAR, VARCHAR, BINARY, VARBINARY) are counted as their actual size in bytes using UTF-8 encoding.
•Numeric data types are counted as if they had been printed. Each digit counts as a byte, as does any decimal point, sign, or scientific notation. For example, -123.456 counts as eight bytes (six digits plus the decimal point and minus sign).
•Date/time data types are counted as if they had been converted to text, including any hyphens or other separators. For example, a timestamp column containing the value for noon on July 4th, 2011 would be 19 bytes. As text, vsql would print the value as 2011-07-04 12:00:00, which is 19 characters, including the space between the date and the time.
NOTE: Each column has an additional byte for the column delimiter.
26 мар 12, 10:32    [12312667]     Ответить | Цитировать Сообщить модератору
 Re: Vertica vs Netezza vs Grennplum  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
bmv_rus
Vovaka
Exadata дороговата зараза.

а можно поподробнее ?
От 2х MUSD или более?


Ну подробно я знаю, но если рассматривать 16ТБ хранилище, то примерно так и будет
26 мар 12, 10:33    [12312677]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить