MasterZivVovaka,

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

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

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

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

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 сильно просаживается, ему их клеить нужно и чем больше тем лучше, что не всегда уже реализуемо малой кровью

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

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

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

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

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

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


Ну это исключение конечно, там несколько колонок всего, да и жмется отлично

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

С этим проблем как раз совсем нет в подавляющем большинстве случаев, machine generated - все чисто.

Забыл пароль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 всех своих спецов давно профукал и продолжает это с завидным постоянством делать. Майкл в своем репертуаре. В общем ну их в сад :)

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

Завтра кстати все выступают на Big Data, послушаем, может чего интересного расскажут :)

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

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

Лаг допустим конечно, в разных типах данных разный, но допустим

ApexСпрошу чисто для "проформу": Teradata уже рассматривли?

Рассматривали, в короткий список не вошла.

Сегодня состоялся форум Bg Data, было довольно интересно. Удалось даже пообщаться с CTO и сооснователем Greenplum, Люком Лонерганом. Молодцы EMC, что пригласили такого человека. Сильный ход. У них несколько коммерческих инсталляций в России, у IBM и HP пока нет ни одной, но с ними тоже интересно было познакомиться. В голове каша, ну в общем примерно паритет. Вертика правда со своей лицензионной политикой конечно шокирует, но в итоге обещают быть не дороже конкурентов. Терадаты кстати почему-то не было, остальные были все.
Sybase порадовал особенно, в конце был розыгрыш призов, так вот от Сайбейза была клава беспроводная с мышкой от Логитека, так хотелось выиграть такой подарок, на всю жизнь память бы осталась, это вот Приз настоящий, не то что другие, всякая фигня, электронные книги и Айпад :)

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

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

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

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

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

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

VerticaThe 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.

bmv_rusVovakaExadata дороговата зараза.
а можно поподробнее ?
От 2х MUSD или более?

Ну подробно я знаю, но если рассматривать 16ТБ хранилище, то примерно так и будет