Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / редбуки по нетиззе / 18 сообщений из 18, страница 1 из 1
23.07.2013, 12:33
    #38340290
Shtock
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
Народ, надо почитать что-то про netezza, особенно про подходы к её оптимизации, про её sql. редбуков аналогично datastage нет, что немного расстраивает. есть какая-либо целостная документация о ней типа concepts, optimization technique?
...
Рейтинг: 0 / 0
23.07.2013, 13:27
    #38340413
Mark Barinstein
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
Shtock,

Netazza Fundamentals

Ну и спросите у гугла про:

Netezza System Administration Guide
Netezza User Guide
Netezza Advance Security Administration Guide
Netezza Data Loading Guide
Netezza Stored Procedures Guide
...
Рейтинг: 0 / 0
23.07.2013, 13:32
    #38340427
Shtock
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
Спасибо, но странно, что на официальном сайте с доками вообще грустно....
...
Рейтинг: 0 / 0
23.07.2013, 14:51
    #38340623
Mark Barinstein
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
Shtock,

Официальная позиция такая:
How to Obtain the IBM Netezza Product Documentation :
You must have an IBM Web Identity linked to an IBM Customer Number (ICN) to access the Netezza software releases and documentation.

Но добрые люди выкладывают файлы типа nz-npsdoc-v7.0.tar.gz
...
Рейтинг: 0 / 0
23.07.2013, 15:52
    #38340767
Shtock
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
Ясно, сча нарою номерок. спасибо.
...
Рейтинг: 0 / 0
19.09.2013, 00:30
    #38400914
редбуки по нетиззе
Документация появилась в открытом доступе в виде information center, как и по всем остальным продуктам IBM

http://pic.dhe.ibm.com/infocenter/ntz/v7r0m3/index.jsp
...
Рейтинг: 0 / 0
22.11.2013, 21:42
    #38474995
Роман Дынник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
concepts
говорят нетиззззза ящиками не умеет размножаться, это правда? )
...
Рейтинг: 0 / 0
22.11.2013, 21:54
    #38475000
Hunterik
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
- Доктор, а вот то, что я с женой за ночь тринадцать раз - это много или мало?
- Это п...ж.
=)
...
Рейтинг: 0 / 0
22.11.2013, 23:42
    #38475049
Роман Дынник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
Hunterik,

а если по существу?
...
Рейтинг: 0 / 0
23.11.2013, 01:18
    #38475076
Hunterik
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
На примере N2001:
"The IBM PureData System for Analytics starts with a data capacity of 96 TB for a half-rack system and can grow to well over 700 TB for a four-rack system"
N2001.PDF
Плюс, есть вот такая брошюрка по старым моделям, внизу несколько конфигураций, в том числе многорековые:
TwinFin.PDF
Или я не так что понимаю...
Вопрос детализируйте - в чём сомнение, может есть какие-то условия дополнительные?
...
Рейтинг: 0 / 0
23.11.2013, 12:47
    #38475182
Роман Дынник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
HunterikИли я не так что понимаю...
Вопрос детализируйте - в чём сомнение, может есть какие-то условия дополнительные?
Все очень просто - покупаю одну штуку Pure Dara System, со временем набиваю ее до предела, включая добавленные блейды и т п.
Покупаю вторую штуку (шкаф) Pure Data System и хочу поставить рядом с первой, об'единив в единую систему. А нннн не тут то было...
Т.е. горизонтальное масштабирование _шкафами_ невозможно по имеющейся у меня информации.
...
Рейтинг: 0 / 0
23.11.2013, 18:08
    #38475329
редбуки по нетиззе
Добрый день,

по вопросу масштабируемости
Netezza всегда масштабируется заменой системы на систему. При этом масштабируемость все равно линейная - например при одном объеме данных производительность ~2x при увеличении системы в 2 раза.
Этот подход применяется с основания Netezza. Амортизированная стоимость старой может быть вычтена из стоимости новой системы либо старая система остается заказчику, например для девелопмента. Условия замены имеет смысл оговорить с продавцами при покупке.
Переезд со старой на новую систему выглядит так - новую восстанавливаем из бэкапа, в последний момент закрываем старую от изменений, накатываем инкрементальный бэкап, меняем системы местами.
В новых системах (N2001-*) есть т.н. Growth on Demand (GoD). Т.е., мы даем вам больше железа, чем вам нужно, вы платите только за часть capacity. По превышению capacity вы доплачиваете.

В общем - утверждение "Нетизза не масштабируется" не верно.

Андрей
...
Рейтинг: 0 / 0
23.11.2013, 21:01
    #38475381
Роман Дынник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
Андрей ВыходцевВ общем - утверждение "Нетизза не масштабируется" не верно.

Андрей, спасибо за подробный ответ, но я этого не утверждал, а говорил ровно о следующем (на мой взгляд недостатке):
Netezza всегда масштабируется заменой системы на систему
Именно это подтверждение я и хотел услышать.
Это здорово что при замене доплачивается только разница, но сущуществует ряд задач и индустрий, в которых такой подход с заменой не приемлем по SLA. Он дольше по времени, больше телодвижений, возможно менее надежен. Особенно такой способ с заменой вызывает озабоченность в условиях непредсказуемого роста объема данных.
По этим причинам некоторые компании вместо netezza делают выбор в пользу, например, vertica, хотя функциональные возможности и производительность у них схожие.
...
Рейтинг: 0 / 0
23.11.2013, 22:30
    #38475421
Hunterik
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
Роман,
а примеры можете привести по ряду задач и индустрий, где процесс перехода, описанный Андреем не подходит?

По-моему, наоборот, симпатичный подход - поставить вторую систему, вывести её на уровень с промом, а потом сделать переключение. Ведь исходная система в этом случае не страдает.

А если просто добавить ящик к существующему, наверняка пойдут какие-то внутренние процессы ребалансировки данных внутри системы в новой конфигурации, насколько эти процессы могут повлиять на бизнес и производительность системы в целом? Подход-то вроде проще, а на практике сталкивались?

Без обид, я просто интересуюсь. Заранее спасибо.
...
Рейтинг: 0 / 0
23.11.2013, 23:58
    #38475466
Роман Дынник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
HunterikРоман,
а примеры можете привести по ряду задач и индустрий, где процесс перехода, описанный Андреем не подходит?

Например, телеком: анализ gsm трафика; финансы: stock exchange - анализ движения денежных потоков, теханализ.
По-моему, наоборот, симпатичный подход - поставить вторую систему, вывести её на уровень с промом, а потом сделать переключение. Ведь исходная система в этом случае не страдает.

Надо исходить из максимально допустимого времени простоя, для кого то этот механизм может оказаться симпатичным, для кого то наоборот. Какое оно(время простоя) будет для netezza в данном случае - я не знаю.
Для меня такой подход скорее навевает что то про disaster recovery, чем про горячее масштабирование.
А если просто добавить ящик к существующему, наверняка пойдут какие-то внутренние процессы ребалансировки данных внутри системы в новой конфигурации, насколько эти процессы могут повлиять на бизнес и производительность системы в целом? Подход-то вроде проще, а на практике сталкивались?
I'm new in netezza и поэтому не знаю как бы оно могло быть, но, например, при использовании hadoop-based решений не встречал никакого негативного влиянии при добавлении новых узлов, да и в данном случае чисто теоретически не представляю откуда ему взяться, ведь данные дублируются на нескольких data node, узлы связаны высокоскоростным каналом, и добавление новых узлов не влечет за собой перераспределение уже существующих данных.

p/s/
мне нетизза в принципе нравится, так что я просто интересуюсь, а не пытаюсь кого то убедить что это не очень хорошее решение.
...
Рейтинг: 0 / 0
24.11.2013, 00:03
    #38475469
Роман Дынник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
еще пример из индустрий и задач - непрерывное производство + SCADA + MES-системы
...
Рейтинг: 0 / 0
24.11.2013, 01:22
    #38475536
Hunterik
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
редбуки по нетиззе
Если системы настолько критичны, то, по идее, должно быть резервирование, а значит можно перевести на новые рельсы сначала одну, затем другую. Если нет резервирования - то зачем обманывать себя. что система mission-critical и down-time не допускает?

Теперь по добавлению ящика (не про NZ, в общем). Добавляем к набитому данными ящику пустой ящик и хотим, чтобы они работали вместе, если архитектура shared nothing, то есть у каждого свой набор данных, то данные нужно перераспределить, иначе, зачем мы добавляли новый ящик? Согласны? И дальше встаёт вопрос - а насколько затратен процесс перераспределения и что можно делать в этот момент с данными. Если система допускает рапределение по подмножеству узлов, то можно постепенно перераспределять различные объекты, растягивая удовольствие во времени, с возможными потерями в производительности за счёт временного перекоса (кого-то перераспределили, а кого-то ещё нет, а запросы с join делать уже надо).

В NZ, как я понимаю, народ решил пойти по пути наименьшего сопротивления - пока дорабатывает старый, переносят на новый и осуществляют переключение после докатки до последнего состояния. Зато данные уже будут лежать так, что система сразу начнёт выдавать ожидаемый результат по производительности...

P.S. Может я в чём не прав - всё бежит, всё меняется...

P.P.S. Hadoop - другая тема, может, откроете ветку? Народ по BigInsights подтянется.
Если не секрет - много данных было в hadoop-решениях, с которыми вы работали, и какое количество узлов там было?
...
Рейтинг: 0 / 0
30.11.2013, 14:42
    #38484423
редбуки по нетиззе
Добрый день,

Я, если честно - не понимаю, каким образом подход, применяемый в Netezza противоречит каким то SLA, или каким-то упомянутым уважаемым Shtock сценариям.
Как раз при таком подходе старая система работает себе на полную мощность, пока новая восстанавливается из бэкапа, в последний момент происходит досинхронизация старой про помощи инкрементального бэкапа, и происходит переключение между системами.
Пользователи могут даже и не заметить переключения.
Подход с добавлением нод "на живую" всегда требует ребалансировки системы. Каким бы волшебным образом не была реализована процедура ребалансировки, она все равно нагружает систему. Как раз в этом случае нужно будет поступиться какими-то SLA. К Hadoop-based решениям это относится в еще большей степени, так как там реализовать эффективное управление нагрузкой и добиться соблюдения SLA гораздо сложнее.

Я ни в коем случае не агитирую за какой-либо из подходов, оба по моему мнению имеют право на жизнь. Почему в Netezza не реализовали оба - не знаю, наверное запросов от заказчиков было мало :)
...
Рейтинг: 0 / 0
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / редбуки по нетиззе / 18 сообщений из 18, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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