|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Анонсируют SAP Sybase IQ 16. http://www.sap.com/news-reader/index.epx?category=ALL&articleID=20454&searchmode=C&page=1&pageSize=10 http://www.cmswire.com/cms/information-management/saps-sybase-iq-16-goes-extreme-delivering-data-driven-insights-in-record-time-019704.php ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2013, 02:07 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Эх, больше рекламных слоганов, чем усовершенствований. "Большее сжатие данных" это конечно круто звучит, но я бы предпочел увидеть в анонсе увидеть следующие пункты: 1. Убрали монопольную запись в таблицу одной сессией 2. Сделали партиционирование индексов 3. Изменили лицензирование с ядер на занимаемое БД пространство Ну а насчет преимуществ два-в-одном против MPP тоже как то натянуто звучит. У меня например, сейчас Вертика на трех простеньких серверах 6 тб сжатую базу крутит (это 12 тб исходной информации). В фактовых таблицах от 1 до 15 лярдов записей, к ним постоянно идут запросы разной сложности, плюс джобы в реалтайм постоянно грузят информацию и считают агрегаты. Все это живет, откликается и никого не заставляет долго ждать. До тучи в Вертику каждый день вливается поллярда записей, чтобы агрегировать и отдать MS AS для куба (чтобы он не думал по сто лет). Тяжеловато конечно уже серверам, будем расширять кластер - доставим сервера под Вертику, пропишем узлы, сервер не останавливаясь в фоне проведет ребалансировку данных на новые узлы и все станет еще быстрее работать, причем с точки зрения лицензирования мы никому ничего доплачивать не должны. Так что, распределенная обработка данных, зеркалирование и прочее что есть у MPP как то уж подозрительно в анонсе чуть ли не "недостатками" MPP обозвали маркетологи совсем зазря. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2013, 14:50 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
ASCRUS, если все так шоколадно, то не могли бы Вы озвучить ориетировочную стоимость HP Vertica c железяками в придачу!? Да и в обслуживании IQ c MPP архитектурой сравнивать не надо. Хотя, мне кажется, Вы сами об этом где то писали. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2013, 16:09 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
ASCRUS3. Изменили лицензирование с ядер на занимаемое БД пространство А это то зачем? Шило на мыло. Особенно если у клиента идет аналитика логов, что подразумевает сильное сжатие. Платить за терабайты, когда и так ясно, что процент сжатия будет только расти?.... ASCRUSНу а насчет преимуществ два-в-одном против MPP тоже как то натянуто звучит. У меня например, сейчас Вертика на трех простеньких серверах 6 тб сжатую базу крутит (это 12 тб исходной информации). В фактовых таблицах от 1 до 15 лярдов записей, к ним постоянно идут запросы разной сложности, плюс джобы в реалтайм постоянно грузят информацию и считают агрегаты. Все это живет, откликается и никого не заставляет долго ждать. До тучи в Вертику каждый день вливается поллярда записей, чтобы агрегировать и отдать MS AS для куба (чтобы он не думал по сто лет). Тяжеловато конечно уже серверам, будем расширять кластер - доставим сервера под Вертику, пропишем узлы, сервер не останавливаясь в фоне проведет ребалансировку данных на новые узлы и все станет еще быстрее работать, причем с точки зрения лицензирования мы никому ничего доплачивать не должны. Так что, распределенная обработка данных, зеркалирование и прочее что есть у MPP как то уж подозрительно в анонсе чуть ли не "недостатками" MPP обозвали маркетологи совсем зазря. Ну, никто из нас этого "два в одном" еще не пробовал, так что оценивать пока рано :) Хотя мне иногда так кажется, что пока у САП'а будет ХАНА, ничего серьезного у IQ не появится. Пока все фичи из времен 'до САПА' - все остальное - подтяжка под САП и багфиксинг. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2013, 17:55 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Костя_1, я согласен с ASCRUS. Если бы изменили лицензионную политику и убрали лицензирование ядер, то IQ имел бы неплохие шансы найти свою нишу на нашем рынке. Согласен и с Вами, что надо бы сначала посмотреть QPlex в деле, а уж потом делать выводы. Про SAP и HANA не понял, чем они мешают IQ. не так давно видел пресс-релиз Диасофта: Sybase IQ+HANA+Diasoft для BI. P.S. что Вы имеете ввиду под аналитикой логов? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2013, 18:05 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
ASCRUSЭх, больше рекламных слоганов, чем усовершенствований. "Большее сжатие данных" это конечно круто звучит, но я бы предпочел увидеть в анонсе увидеть следующие пункты: 1. Убрали монопольную запись в таблицу одной сессией 2. Сделали партиционирование индексов 3. Изменили лицензирование с ядер на занимаемое БД пространство Ну а насчет преимуществ два-в-одном против MPP тоже как то натянуто звучит. У меня например, сейчас Вертика на трех простеньких серверах 6 тб сжатую базу крутит (это 12 тб исходной информации). В фактовых таблицах от 1 до 15 лярдов записей, к ним постоянно идут запросы разной сложности, плюс джобы в реалтайм постоянно грузят информацию и считают агрегаты. Все это живет, откликается и никого не заставляет долго ждать. До тучи в Вертику каждый день вливается поллярда записей, чтобы агрегировать и отдать MS AS для куба (чтобы он не думал по сто лет). Тяжеловато конечно уже серверам, будем расширять кластер - доставим сервера под Вертику, пропишем узлы, сервер не останавливаясь в фоне проведет ребалансировку данных на новые узлы и все станет еще быстрее работать, причем с точки зрения лицензирования мы никому ничего доплачивать не должны. Так что, распределенная обработка данных, зеркалирование и прочее что есть у MPP как то уж подозрительно в анонсе чуть ли не "недостатками" MPP обозвали маркетологи совсем зазря. Еще вот подумалось - Вертика с MPP nо своими 'проекциями' против IQ с его SMP, партишингом (конечно, блин, за него платить надо), но без "проекций". Сомневаюсь, что на нормальном adhock'e ктоьто быдет явным лидером. У Вас же, как описано, это практически стейджинг какой-то :) а не ДВХ. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2013, 18:08 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
NashvilleКостя_1, Про SAP и HANA не понял, чем они мешают IQ. не так давно видел пресс-релиз Диасофта: Sybase IQ+HANA+Diasoft для BI. P.S. что Вы имеете ввиду под аналитикой логов? Мое личное мнение, ХАНА пережиток из времен, когда САП конкурировал с Сайбейсом и им было нужно что-то, чтобы BO могли работать. Повторюсь - мнение личное, но думаю, что IQ можно было развить и в связке с АSE (или без ASE) обойтись без ХАН. Но, конечно, продав ХАНУ можно много заработать. Аналитика логов - я так называю случаи, когда веблоги, чеки, биллинг, машинно генерированная информация грузится в DWH для анализа. Чем больше достаточно "простых" данных, тем более заметна компрессия. 100ГБ сожмется например в 50гб в базе, а 1ТБ уже может и до 300ГБ сжаться и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2013, 18:20 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
автор У Вас же, как описано, это практически стейджинг какой-то :) а не ДВХ. Прошу прощения, но у меня вообще ничего не описано. Просто приведен пример, что до тучи наше хранилище некоторыми подразделениями ИТ в том числе как стейджинг используется для ускорения загрузок кубов в МС и расчетов в Оракл. По цене лицензия Вертики на 30 тб исходных данных с любым количеством серверов в кластере будет ощутимо дешевле лицензии на 2 сервера IQ по 12 ядер с мультиплексом и прочими опциями. Причем стоит учесть, что чисто физически эти 2 сервера не протянут такой объем, если много сессий и кэширование с индексами и партициями не поможет, а значит придется на IQ еще сервера лицензии покупать, чтобы доставить сервера. Насчет партиций тоже не все так однозначно. С одной стороны они разделяют данные, ускоряя доступ, но если запрос должен охватить данные по измерениям без участия полей партиций, то толку от них ноль.здесь как раз помогает распределенное хранение данных. Что в том же Map Reduce используется — представляю себе, сколько бы пришлось ждать ответ от Гугла, если бы он все данные на одном дисковом хранилище хранил :) Ладно, извиняюсь за спам. Вертику не как рекламу,а больше как пример привел того, что будущее хранилищ данных IMHO все таки MPP, убедился на личном опыте. Если есть вопросы, можно задать их по почте или аське. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2013, 01:37 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
ASCRUSЭх, больше рекламных слоганов, чем усовершенствований. "Большее сжатие данных" это конечно круто звучит, но я бы предпочел увидеть в анонсе увидеть следующие пункты: 1. Убрали монопольную запись в таблицу одной сессией 2. Сделали партиционирование индексов 3. Изменили лицензирование с ядер на занимаемое БД пространство http://scn.sap.com/community/sybase-iq/blog/2013/03/01/i-have-one-word-for-you-young-benjamin-analytics 1. Видимо как-то да. 2. Пока не понятно. По 3 - нет. На мой взгляд лучше не менять, а дополнить. Хочешь по ядрам - хорошо, хочешь по данным - тоже не плохо. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2013, 00:24 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Костя_1Мое личное мнение, ХАНА пережиток из времен, когда САП конкурировал с Сайбейсом и им было нужно что-то, чтобы BO могли работать. Повторюсь - мнение личное, но думаю, что IQ можно было развить и в связке с АSE (или без ASE) обойтись без ХАН. Но, конечно, продав ХАНУ можно много заработать. Позвольте не согласиться. ХАНА не пережиток, а флагман сейчас, в SAPе (ERP, CRM, SRM) уже в рампапе. Обойтись без неё можно, но глупо. HANA это не только база. http://www.sapvirtualevents.com/teched/sessiondetails.aspx?sId=3357 P.S.> У нас есть и IQ и HANA - опыт накапливаем. IQ нравится за стабильность, HANA за быстроту и потенциал. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2013, 00:47 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Костя_1 Хотя мне иногда так кажется, что пока у САП'а будет ХАНА, ничего серьезного у IQ не появится. Пока все фичи из времен 'до САПА' - все остальное - подтяжка под САП и багфиксинг. А что хотите в IQ из серьезного ? Хранить в HANA бигдату - не вариант, дорого. А вот в IQ - самое то...)) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2013, 00:50 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
ASCRUSПо цене лицензия Вертики на 30 тб исходных данных с любым количеством серверов в кластере будет ощутимо дешевле лицензии на 2 сервера IQ по 12 ядер с мультиплексом и прочими опциями. Причем стоит учесть, что чисто физически эти 2 сервера не протянут такой объем, если много сессий и кэширование с индексами и партициями не поможет, а значит придется на IQ еще сервера лицензии покупать, чтобы доставить сервера. Ощутимо дешевле? Да лан.... Как то вы уж совсем IQ (вкл. мультиплекс) по производительности на фоне Вертики взад поставили. Хотя вроде как вы в сайбес снг работали. Удалось тогда IQ (с мульти или без) пощупать самому? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2013, 00:57 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
bmv_rusКостя_1Мое личное мнение, ХАНА пережиток из времен, когда САП конкурировал с Сайбейсом и им было нужно что-то, чтобы BO могли работать. Повторюсь - мнение личное, но думаю, что IQ можно было развить и в связке с АSE (или без ASE) обойтись без ХАН. Но, конечно, продав ХАНУ можно много заработать. Позвольте не согласиться. ХАНА не пережиток, а флагман сейчас, в SAPе (ERP, CRM, SRM) уже в рампапе. Обойтись без неё можно, но глупо. HANA это не только база. Конечно, "Флагман". Как минимум для маркетологов САП'а - они его анонсировали перед самой покупкой Сайбейс. Не могут же время повернуть обратно. Я не вижу, почему к IQ нельзя было добавить in-memory option (тем более на АSЕ теxнология уже испытывалась)+домаркетингировать replication server. Taже ХАНА получится. http://www.dbms2.com/2012/02/26/sap-hana-today/ . А теперь - 2 решения. Ясно, что одно из них со временем исчезнет либо будет как Информикс у IBM. А нравится чистый in-memory - по этой теме давно и думаь успешно работает Kognitio. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2013, 15:05 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
bmv_rusASCRUSПо цене лицензия Вертики на 30 тб исходных данных с любым количеством серверов в кластере будет ощутимо дешевле лицензии на 2 сервера IQ по 12 ядер с мультиплексом и прочими опциями. Причем стоит учесть, что чисто физически эти 2 сервера не протянут такой объем, если много сессий и кэширование с индексами и партициями не поможет, а значит придется на IQ еще сервера лицензии покупать, чтобы доставить сервера. Ощутимо дешевле? Да лан.... АСКРУС правильно сравнивает - 3 сервера Вертики против 2-х cерверов для IQ. Мне тоже кажется - с Вертикой будет дешевле. Причем еще будет существенной разница по цене storage. Будет ли быстрее - особенно с ростом числа юзеров - не знаю. Скорее всего еще один сервер потребуется ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2013, 15:15 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Костя_1Я не вижу, почему к IQ нельзя было добавить in-memory option А зафиг? Он же аналитический сервак для больших данных. Бери сервер с большим ОЗУ - выставляй кэши большие и получай псевдо-ин-мемори. Если не путаю в ASE in-memory тока на чтение(как кэш). Электричество мигнет и все. P.S.> Я не админ IQ могу ошибаться. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2013, 21:12 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Костя_1АСКРУС правильно сравнивает - 3 сервера Вертики против 2-х cерверов для IQ. Мне тоже кажется - с Вертикой будет дешевле. Причем еще будет существенной разница по цене storage. Будет ли быстрее - особенно с ростом числа юзеров - не знаю. Скорее всего еще один сервер потребуется Костя_1, АСКРУС. Давайте более предметно, а то иначе это выглядит как банальная реклама - сколько стоит Вертика на 30 тб исходных данных с любым количеством серверов в кластере по General Price от HP. Можно в личку. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2013, 21:16 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
bmv_rusКостя_1, АСКРУС. Давайте более предметно, а то иначе это выглядит как банальная реклама - сколько стоит Вертика на 30 тб исходных данных с любым количеством серверов в кластере по General Price от HP. Можно в личку. Извините, но я не собираюсь на форуме Sybase делать тему IQ vs Vertica, все что я в привел в пример с Вертики это перечисление недостатков IQ с концепцией "два в одном" на фоне MPP архитектуры. И Вам не советую начинать здесь сравнения проводить, для этого есть форум Сравнение СУБД. Ну а с учетом того, что Вертика в РФ и на Европейском континенте первый запущенный в продакшн проект имеет у нас, вообще и в сравнении тему заводить не стоит, так как опыт реальной эксплуатации на терабайтах данных на скуль.ру имеется только у меня и Vovaka. Хотите сравнить цены, обращайтесь в Sybase и HP, хотя подозреваю обе конторы на текущем этапе интеграции Sybase с SAP и Vertica с HP еще сто раз будут думать и переигрывать лицензионную политику. Ну а насчет лицензирования объемов я твердо уверен, что для BigData это верный путь. Сервера сейчас достаточно дешевые, обработка больших данных не должна зависеть от лицензии, в любой момент возрастают нагрузки и требуется нарастить кластер новыми серверами, чтобы не просела производительность. Почему я за это должен платить, не понимаю - если мне нужна скорость обработки и в я кластер ставлю сто 16 ядерных серверов, с текущей лицензионной политикой IQ легче будет Терадата купить и не парить мозг. А объем штука статичная - если хранилище прирастает из расчета 10 тб в год, можно спокойно прикупить 30 тб и к концу 3 года уже решить, сколько еще потребуется лицензии, что требуется хранить, а что можно и перевести из хранилища в архивы. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 19:28 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
ASCRUS, Извиняюсь, не вытерпел ... Ядра - динамические, а объём базы - статический ... Хи-хи. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2013, 12:08 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
А что хи—хи? Объем прироста данных спрогнозировать гораздо проще и надежнее, чем нагрузки потребления данных. Число источников данных растет медленно, а вот количество пользователей хранилища и тяжести аналитических запросов может критически измениться в любой момент. Сегодня с хранилищем работает через САП 50 пользователей, а завтра другое подразделение компании покупает Tableau и на хранилище начинают сыпаться новые тяжелые запросы. И если для любого бизнеса и так понятно, что нужно докупить железо, то вот им объяснить, зачем его еще надо лицензировать, будет сложно. Другое дело объем - тоже логично и понятно, база выросла за года, нужно принять решение, убрать информацию в архив или нужно расширить объем хранилища, старая информация нужна. Тоже самое касается и апгрейда серверов хранилища, решили поменять сервер на более современный, ядер естественно больше, руководство узнает что надо доплачивать лицензию и с большой вероятностью апгрейд накроется медным тазом. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2013, 18:03 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
bmv_rus Давайте более предметно, а то иначе это выглядит как банальная реклама - сколько стоит Вертика на 30 тб исходных данных с любым количеством серверов в кластере по General Price от HP Ту сумму, за которую мы покупали Вертику, некорректно будет приводить. Во-первых НР не смог нам ее продать в России т.к. не было еще партномеров, и мы покупали в Америке у самой Вертики, во вторых это была первая продажа на территории Центральной и Восточной Европы, в-третьих ни один человек из Вертики или НР и пальцем о палец не ударил во всем процессе покупки, в смысле маркетига и пресейлинга не было абсолютно. Поэтому ценник мы получили очень даже неплохой. ЕМС с их агрессивной маркетинговой политикой никак не могли понять как они проиграли тендер Вертике, которую тут никто даже и не продавал :) А IQ мы знаем с Ascrus и далеко не понаслышке, он тоже был в нашем списке претендентов, но отвалился первым. И цены я запрашивал на него и действительно могу подтвердить, что Вертика на 36 ядрах и 30 ТБ нам обошлась дешевле че IQ на этих же ядрах, даже учитывая его политику делить пополам кол-во ядер. А сейчас мы доставляем еще 3 сервера, + 48 ядер ничего не доплачивая НР, а IQ бы нам уже стал бы золотым просто. Ну и все это на фоне монопольной записи в таблицу и еле ворочающихся индексов на больших объемах. А есть и еще пример один из жизни. Была в свое время тестовая база на IQ, несколько ТБ, гоняли ее в хвост и гриву, чтобы понять, на что оно годится. Так вот неожиданно съехали мозги у первой головы высоконадежного сетевого хранилища high end уровня, да так что вторая голова в горячем резервировании этого даже не заметила и RnD вендора пришлось привлекать к восстановлению рассыпавшихся данных и спустя 3 недели все равно часть данных была безвозвратно утеряна. Ессно IQ после этого больше свою базу не признал таковой. А многие у нас бекапят террабайтные базы? Вот после этого sharing nothing у меня вбито в мозгу как аксиома. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2013, 11:11 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Vovaka А IQ мы знаем с Ascrus и далеко не понаслышке, он тоже был в нашем списке претендентов, но отвалился первым. И цены я запрашивал на него и действительно могу подтвердить, что Вертика на 36 ядрах и 30 ТБ нам обошлась дешевле че IQ на этих же ядрах, даже учитывая его политику делить пополам кол-во ядер. А сейчас мы доставляем еще 3 сервера, + 48 ядер ничего не доплачивая НР, а IQ бы нам уже стал бы золотым просто. Ну и все это на фоне монопольной записи в таблицу и еле ворочающихся индексов на больших объемах. Да, Вы замучили уже с этим "недостатком" IQ как монопольная запись в таблицу. IQ - это хранилище, а не OLTP база. В хранилище в 99% организациях запись осуществляется по регламенту, большими порциями, а не постоянно по несколько строк от большого кол-ва сессий. Скорость заливки в IQ - очень хорошая - может доходить до 1 млн. строк в сек. при этом обычно load распараллеливается и утилизирует все ядра на хосте под 100%. Ну даже сделали бы и разработчики IQ не монопольную запись в таблицу, и чтобы это дало, когда все ресурсы и так заняты на 100%?? Касательно "еле ворочающихся индексов", то тут наверное автор имел ввиду HG индексы, т.к. все остальные индексы имееют битовую структуру, и их точно не назовешь "еле ворочающавшимися" . HG индексы имеющие b-tree структуру действительно растут значительно при росте БД, и время их перестройки во время загрузки действительно увеличивалось по мере роста размера БД. Однако в IQ16 это проблема уже решена, с появлением Tiered High Group индексов. New Tiered High Group (THG) indexes decouple load performance from HG index size. In IQ 15, load throughput could degrade as the amount of data increases in an High Group (HG) index. As the index grew, loading the same amount of data could take more time. New Tiered High Group (THG) indexes decouple load performance from the HG index size to increase throughput. VovakaА есть и еще пример один из жизни. Была в свое время тестовая база на IQ, несколько ТБ, гоняли ее в хвост и гриву, чтобы понять, на что оно годится. Так вот неожиданно съехали мозги у первой головы высоконадежного сетевого хранилища high end уровня, да так что вторая голова в горячем резервировании этого даже не заметила и RnD вендора пришлось привлекать к восстановлению рассыпавшихся данных и спустя 3 недели все равно часть данных была безвозвратно утеряна. Ессно IQ после этого больше свою базу не признал таковой. А многие у нас бекапят террабайтные базы? Вот после этого sharing nothing у меня вбито в мозгу как аксиома. Клиенты IQ имееют многотеррабайтные базы и успешно бекапят их . В частности на территории СНГ один из клиентов имеет БД более 45 Тb, которая постоянно растет. В мире базы в IQ есть гораздо большего размера. В зависимости от размера БД применяются разные стратегии резервного копирования, отличные от традиционного бекапа, а именно используется вирутальный бекап, технология NonStop IQ и т.д. и т.п. Так что никто без резервной копии не обходится.. Касательно Вертики ничего особо плохого про нее сказать не могу, так как однажды более года назад встречались с ней в рамках одного тендера для одного большого ритейла. Вместе с IQ тогда она вышла в финал оставив позади все Oracle, DB2 и еще кого-то. Но в финале, Sybase IQ эту Вертику очень красиво обошла на реальных сложных аналитических бизнес запросах. И вообще, не могу понять, что делает такое длительное обсуждение Вертики в ветке форума по Sybase? Для подобных обсуждений лучше открыть тему в разделе "Сравнение СУБД" ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 16:53 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Для тех, кому хочется в одну таблицу из многих сессий (как в OLTP) в IQ 16 добавили: Use the new RLV data store in your simplex database to perform row-level updates, inserts, and deletes, in real-time. When a table is registered for storage in the RLV data store, multiple users can write to different rows of the table concurrently. RLV Store – The in-memory data store optimized for high-performance row-level updates. The RLV store acts as a staging area for write events. If a table is enabled for the RLV store, then all LOAD TABLE, INSERT, UPDATE, and DELETE events write directly to the RLV store. In-memory data in the RLV store is automatically (and periodically) merged into the IQ main store. You can set parameters for automatic merges, and you can merge on-demand. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 17:43 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Рад, что 16-ый IQ развивается с оглядкой на конкурентов. Ждем MPP в 17-ой версии! ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 19:24 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Vovaka, Уже 15 версии в IQ появился PlexQ - говорят MPP. Но не слышал ничего реального о его использовании/скорости/пользе ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 19:41 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Vovaka, Massive Parallel Processing появилось ещё в 15.3, называется Distributed Query Processing (DQP) или PlexQ - распределённое выполнение запроса многими узлами в кластере. Кратко: https://sybasetechwave2011.sapevents.com/index.cfm?fuseaction=agenda.SessionDetails&sid=220 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 19:46 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
забыл дописать sharing-nothing :) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2013, 21:50 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Vovaka, Интересно от Вас услышать практический опыт по такому вопросу. Вот у Вас работает > 3-х серверов в архитектуре shared-nothing. Вы как к каждому серверу отдельную дисковую стойку покупали (не лежит же у Вас база на обычных внутренних винтах) или на одной стойке нарезали LUNы? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 12:20 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Юр, стоек нет, есть локальные диски, на которых и лежит база. На каждом сервере лежит его часть базы + зеркало соседнего сервера. Можно включить режим двойного зеркалирования, когда каждый сервер еще хранит зеркало предыдущего и следующего сервера кластера по цепочке, но мы решили, что это уже избыточно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 17:22 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
ASCRUSНа каждом сервере лежит его часть базы + зеркало соседнего сервера Хмм.. Что ж это за кластер получается, когда на каждой ноде лежит только часть базы. Что пользователи должны знать к какому серверу подключаться, чтобы выполнить тот или иной запрос?? Или сама СУБД переадресует их на нужную ноду?? И как в таком случае выполняются запросы с join, затрагивающие данные, хранящиеся на разные нодах кластера??? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2013, 17:54 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
moris, в MPP СУБД изначально база равномерно распределяется между всеми серверами кластера, это называется сегментацией данных. Естественно это все происходит на физическом уровне, для клиентской сессии это одна БД и она просто посылает к ней запрос. Далее СУБД самостоятельно запускает параллельное выполнение запроса на всех серверах кластера, которые над своей частью данных выполняют работы по фильтрации, объединению, группировки и сортировке данных, обмениваясь при этом порциями промежуточных данных по сети, далее результаты собираются на сервере, с которого сессия вызвала запрос, допиливаются до окончательного вида и отдаются сессии. С джойнами все тоже самое - или если данные присоединяемых таблиц лежат по ключам рядом с основными данными, они сцепливаются локально на всех серверах или же происходит обмен данными по ним между серверами для проведения присоединения. Если СУБД видит выгоду, то он может нужные колонки мелких присоединяемых таблиц просто реплицировать по всем узлам, чтобы потом по хешу быстро их сцепить. Так же можно самостоятельно управлять сегментацией данных, указывая перечисления полей через хеширование, по которому можно определить распределение данных между серверами. Для мелких таблиц можно явно указать отключить сегментирование и их копия будет хранится на каждом из узлов кластера. В общем там все не так примитивно, как ты думаешь, оптимизатор показывает высший пилотаж, рассчитывая план запроса так, чтобы ноды кластера как можно больше работ выполнили локально, минимизировав их общение по сети. В принципе в современных MPP это все успешно решено и такие операции, как джойны, группировки и union на больших таблицах шустро работают. Понятное дело, что с непривычки после классических СУБД можно наломать не мало дров, даже партиционирование вообще имеет другой смысл и другое назначение, чем в привычном понимании. Даже колоночное хранение сжатых данных казалось бы принципы те же, а вот реализация разная, в итоге и работа оптимизатора здорово отличается и при проектировании структур это учитывать стоит. На самом деле с MPP выжать очень много можно, если понимать и уметь. Распределенное хранение и обработка данных гарантируют равномерные нагрузки на все сервера кластера, всегда работают все, простоев нет. Это дает горизонтальную масштабируемость - добавляем новый сервер в кластер, данные кластера ребалансируются равномерно на новое кол-во серверов, а значит на один сервер его объем локальных данных уменьшается, а ядер и памяти для параллельной обработки запроса увеличивается. Ну и дискового пространства для хранения данных прирастает. Локальные диски очень быстры, нодам не требуется сетевой доступ для чтения и записи данных, данные хранятся в виде блоков в сжатом поколоночном отсортированном виде, каждый блок содержит свою информацию о том, что лежит внутри него. В итоге не требуются и индексы как дополнительные структуры для повышения скорости доступа к данным. Они насколько я знаю есть только у GreenPlum, но и то оставлены как пережиток прошлого, при проектировании ими никто не пользуется. Ну и если уж говорить о PlexQ, то с одной стороны оно конечно здорово, что я могу определить группы серверов, занимающихся различной нагрузкой и разными задачами. С другой стороны, получается, что все это дело надо реконфигурировать в случае изменения задач, нагрузок или изменения технической части. В MPP все просто - всегда работают все, поэтому если нагрузки повышаются, они равномерно повышаются на все сервера кластера. Если добавляем новые сервера в кластер, повышается производительность работы всего кластера. Если вдруг один сервер стал недоступен для кластера, общая производительность кластера падает, так как один из его серверов начинает выполнять работу за двоих, но это не так значительно, чтобы все стало тормозить. Еще такой момент я обратил внимание, что например в Vertica оптимизатор никогда не использует зеркало соседнего сервера, хотя вот оно, казалось бы, лежит рядом, бери и пользуйся для ускорения. В PlexQ же получается так как физически база лежит в одном месте и все сервера ее читают, то это же какие затраты и издержки на то, чтобы одновременно всем серверам лезть к стойке за информацией и при этом синхронизировать свои действия, чтобы каждый четко прочитал только нужный кусок и не было дублирования обработки информации между серверами. Фактически это получается этакий виртуальный MPP, где все делают вид, что владеют своей частью данных и в масс параллельной обработке ее используют. Получается, что при использовании PlexQ теряется одно из главных преимуществ IQ - простота администрирования. За группами серверов надо следить, продумывать какие нагрузки как лучше распределять, если прибавилось подключений или потяжелели запросы, нужно переконфигурировать группы серверов, добиваясь лучшей производительности ... то есть появляется понятие тюнинга, что совсем не было в старом добром IQ. Ну и вот тоже мне не понятна фраза из статьи про IQ: Используя MPP-архитектуру с полным разделением ресурсов, платформа распределенной обработки запросов PlexQ в составе Sybase IQ 15.3 превосходит традиционные MPP-архитектуры без разделения ресурсов в части параллелизма, качества обработки произвольных запросов самообслуживания и независимого горизонтального масштабирования вычислительных мощностей и мощностей хранения. Не могу понять, почему здесь говорится, что у MPP нет разделения ресурсов. У MPP есть понятие workload, можно замечательно по пулам ресурсов провести разделение по приоритетам по использованию процессорного времени и памяти, раскидав на эти пулы пользователей. Описанный пул ресурсов работает для всех серверов кластера, но это и понятно - в коллективной работе серверов совсем не желательно, чтобы кто то тормозил, а кто то работал быстрее. Иначе кто отработал быстрее будет ждать остальных, кто работает дольше. Кстати поэтому и предъявляются требования, чтобы данные равномерно хранились на серверах без перекосов по объемам и чтобы сессии работали через балансировщик подключений и к серверам кластера так же равномерно разбрасывались пользовательские сессии. В общем по мне, так PlexQ что то смахивает на этакую многовекторность - мы типа и в одном месте данные храним, но и обрабатываем их частями отдельно. Сложновато по архитектуре получается организовать такую синхронизацию работы серверов, а я сторонник принципа чем проще тем лучше. Как минимум управлять проще и багов обычно меньше ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.03.2013, 01:34 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
ASCRUSВ итоге не требуются и индексы как дополнительные структуры для повышения скорости доступа к данным. В IQ в отличие от других СУБД - индексы это не только оптимальный способ доступа к данным, но и уже готовый результат, т.е. операции, которая может над данными выполняться. Например - FP индекс - готовый результат - distinct , Datetime - готовые результаты конверсии даты/времени во все возможные datepart-ы, CMP индекс - готовый результат сравнения величин колонок. WD индекс - индексация составляющих text данных и т.д. Как следствие - индексы в IQ очень часто используются, без необходимости доступа к низлежащим данным. ASCRUSВ PlexQ же получается так как физически база лежит в одном месте и все сервера ее читают, то это же какие затраты и издержки на то, чтобы одновременно всем серверам лезть к стойке за информацией и при этом синхронизировать свои действия, чтобы каждый четко прочитал только нужный кусок и не было дублирования обработки информации между серверами. Фактически это получается этакий виртуальный MPP, где все делают вид, что владеют своей частью данных и в масс параллельной обработке ее используют. Получается, что при использовании PlexQ теряется одно из главных преимуществ IQ - простота администрирования. За группами серверов надо следить, продумывать какие нагрузки как лучше распределять, если прибавилось подключений или потяжелели запросы, нужно переконфигурировать группы серверов, добиваясь лучшей производительности ... то есть появляется понятие тюнинга, что совсем не было в старом добром IQ. Вы неправильно понимаете, как работает IQ и что делает PlexQ. IQ это версионник, синхронизация нужна только в один момент времени выполнения запроса - во время его начала, получая актуальную версию данных на тот момент. Далее IQ строит "конвейерный" план, максимально разбивая каждый этап выполнения на части , исходя из доступных ресурсов, тем самым задействую все доступные ядра на хосте/ах кластера. В случае Plex- IQ распределяет выполнение одного запроса - на все доступные ноды кластера, и на каждой ноде кластера разбивая его еще над подчасти, для задействования всех ядер на конкретной ноде. По мере выполнения запроса - никто никого не ждет. В момент выполнения такой подчасти, обработанные данные не ожидая конца выполнения всего этапа переходят на следующий этап выполнения, где продолжат свою параллельную обработку. Только на некоторых этапах выполнения может потребоваться синхронизация или серийный обработка. Но таких этапов достаточно мало. Администрирования IQ Plex ничем не отличается от администрирования обычного IQ. Если используются логические сервера - группы физических нод, то реконфигурация серверов это 2 кликание мышкой в визарде, или одна команда. Не так то уж и тяжело. Тем более, что такую работу может потребоваться сделать раз (ну или несколько раз) в год. Кстати, многие клиенты IQ вообще не связываются с группами серверов - добавляя все ноды в один общий DQP логический сервер и используют все ресурсы кластера, для выполнения одного или множества запросов. -+ ... |
|||
:
Нравится:
Не нравится:
|
|||
16.03.2013, 15:17 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
moris Ну вот, у ASCRUS такая складная история получалась, уэе начали уверовать, а ты возьми да развей )) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.03.2013, 19:18 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
bmv_rusmoris Ну вот, у ASCRUS такая складная история получалась, уэе начали уверовать, а ты возьми да развей )) Вы кому то что то хотите доказать или утверждаете что я хочу кому то что то доказать? moris, спасибо за ликбез. То, что Вы написали, чистой воды MPP, плюс минус особенности реализации. Не очень тогда понятно, почему Sybase считает, что их решение эффективнее прочих реализаций. Я еще раз повторюсь для bmv_rus - я не считаю, что IQ уступает остальным, мне кажется не удобной политика лицензирования. А все остальное познается только на практическом опыте, у меня нет такого опыта в IQ, чтобы сравнить с тем решением, с которым я сейчас работаю. У нас в силу требований проекта первым в списке шла способность многопоточной записи множества сессий в реалтайме (сбор статистики с множества устройств), поэтому IQ не рассматривался. Все просто. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.03.2013, 23:23 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
ASCRUS moris, спасибо за ликбез. То, что Вы написали, чистой воды MPP, плюс минус особенности реализации. Не очень тогда понятно, почему Sybase считает, что их решение эффективнее прочих реализаций. Улыбнуло.. А почему Oracle считает, что у них все решения самые эффективные?? Маркетинг .. Кто то когда то видел, чтобы какой то вендор сказал, что их решение не самое самое??? Отсюда вывод - хочешь реально узнать кто круче - заказывай полноценное тестирование с обязательным привлечением специалистов, от каждого вендора, чтобы они смогли эффективно установить/настроить ту или иную СУБД -- выжать из нее все, что она может. А потом по результатам тестирования конкретной вашей задачи - делай выводы, кто быстрее, кто эффективней использует ресурсы, сколько времени заняла подготовка, простота администрирования и т.п. Конкретно для вашего случая, учитывая ваше "понимание" основных принципов работы IQ и то что специалисты Sybase не были привлечены к тестированию - почти уверен, что ваше тестирование IQ vs Vertica - было (как бы помягче сказать) - просто не корректным, чтобы на его результатах делать какие либо выводы, в частности что Vertica - впереди планеты всей, а вот Sybase IQ надо догонять ее... P.S. Больше в этой дискуссии не участвую. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2013, 14:03 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
VovakaА IQ мы знаем с Ascrus и далеко не понаслышке, он тоже был в нашем списке претендентов, но отвалился первым. И цены я запрашивал на него и действительно могу подтвердить, что Вертика на 36 ядрах и 30 ТБ нам обошлась дешевле че IQ на этих же ядрах, даже учитывая его политику делить пополам кол-во ядер. А сейчас мы доставляем еще 3 сервера, + 48 ядер ничего не доплачивая НР, а IQ бы нам уже стал бы золотым просто. Ядра пополам? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2013, 14:32 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
ASCRUS, Перечитал ваш ответ. Так вы вообще IQ получается толком не тестировали, если она у вас сразу отпала. Понятно.. По ценам, думаю так, пока Sybase может с успехом продавать IQ, то вряд-ли что то будет меняться. Хотя с другой стороны SAP, что то может и изменить.. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2013, 00:00 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
bmv_rusVovaka... нам обошлась дешевле че IQ на этих же ядрах, даже учитывая его политику делить пополам кол-во ядер. А сейчас мы доставляем еще 3 сервера, + 48 ядер ничего не доплачивая ... Ядра пополам? Это называлось скидкой 50% за мультиядерность. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2013, 09:43 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
morisASCRUS, Перечитал ваш ответ. Так вы вообще IQ получается толком не тестировали, если она у вас сразу отпала. Понятно.. По ценам, думаю так, пока Sybase может с успехом продавать IQ, то вряд-ли что то будет меняться. Хотя с другой стороны SAP, что то может и изменить.. IQ при стоимости 40 килобаксов за ядро с учетом скидки нам ну никак не подошел, у нас сейчас 84 ядра, и стоимость лицензий IQ более чем на порядок превышает стоимость лицензий остальных наших претендентов. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2013, 09:50 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Описание PlexQ и DQP с результатами тестов (если кому интересно) http://www.sybase.ru/system/files/pdf/sybase_iq_scaling_wp_ru_lo.pdf ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2013, 13:37 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
Спасибо, конечно интересно. Многое схожее по решениям с тем, что есть у MPP, но есть много и разного. Под разные задачи это выливается и в плюсы и в минусы тоже (это конечно если не учитывать еще квалификацию разработчиков и считать, что они хранилище строят максимально оптимально). Насчет опасности неравномерного распределения данных у MPP соглашусь на все 100. Реально, когда запускаешь на проектирование хранилища разработчиков, привыкших к классическим реализациям сервера, они много чего наворотят такого, что потом их хочется пристрелить. Это самая ахилесова пята MPP, причем самое печальное, что из за таких перекосов в одной таблице фактов просядет производительность всего кластера. Здесь IQ вне конкуренции по простоте проектирования эффективных хранилищ. Остальные перечисленные недостатки отлично демонстрируют конкуренты Vertica (GP и Netezza), но не она ;) Все таки «папа» Стоунбрейкер человек с большом опытом создания СУБД и он максимально учел все достоинства и недостатки существующих решений. Смотрю есть и моменты заимствования решений от IQ, есть и наоборот недавно появившиеся в IQ фичи, которые были ноу хау в Vertica с момента создания. Это хорошая тенденция, если конечно обойдется без патентных войн. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2013, 22:03 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
ASCRUS, Ценник только запредельный огорчает когда смотришь на диаграмму Скорость распределенной обработки в конце обзора и дорисовываешь на ней еще кривую стоимости этой самой распределенной обработки... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2013, 09:24 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
VovakaASCRUS, Ценник только запредельный огорчает когда смотришь на диаграмму Скорость распределенной обработки в конце обзора и дорисовываешь на ней еще кривую стоимости этой самой распределенной обработки... Не вижу ничего запредельного если сравнивать с конкурентами (незнаю насчет оракла). Так как лицензионная стоимость зависит от процессорной мощности, которая (по рекомендациям Sybase) связана с объемами данных, то думаю несложно будет произвести сравнение стоимости лицензий конкурентов, которые зависят от объема данных. Не имею достаточной информации по стоимости озвученных конкурентов, но по моему мнению, стоимость будет сопоставима. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2013, 10:55 |
|
Sybase IQ 16.0
|
|||
---|---|---|---|
#18+
GA в апреле но доки уже доступны http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.help.iq.16.0/doc/html/title.html ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2013, 11:44 |
|
|
start [/forum/topic.php?all=1&fid=55&tid=2009990]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
213ms |
get topic data: |
14ms |
get forum data: |
2ms |
get page messages: |
79ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 355ms |
0 / 0 |