Comments 21
Было бы интересно взглянуть на реальные тесты производительности.
При крайних и средних значениях — выбираем все столбцы, выбираем 1 столбец.
На чтение, запись, удаление, обновление.
И сравнить это с MS SQL 2008 R2, например.
То что это быстрее теоретически — это да, но от реализации тоже многое зависит.
При крайних и средних значениях — выбираем все столбцы, выбираем 1 столбец.
На чтение, запись, удаление, обновление.
И сравнить это с MS SQL 2008 R2, например.
То что это быстрее теоретически — это да, но от реализации тоже многое зависит.
Реальные тесты производительности как правило делаются для конкретных Заказчиков, поскольку результаты очень сильно зависят от конкретной структуры таблиц и SQL-запросов к ним.
Другой вариант — использовать виртуальные машины Teradata Express под VMWare, которые можно скачать в свободном доступе. Там вполне можно протестировать, насколько сильно сожмутся данные, если одну и ту же таблицу создать в двух вариантах — обычном и колоночном. А также можно посмотреть трудоемкость выполнения запросов к этим таблицам — правда не с точки зрения времени выполнения (на виртуальной машине оно будет заведомо не показательным), а с точки зрения потребления CPU и I/O каждым отдельным запросом (эта информация пишется в специальный журнал DBQL).
Другой вариант — использовать виртуальные машины Teradata Express под VMWare, которые можно скачать в свободном доступе. Там вполне можно протестировать, насколько сильно сожмутся данные, если одну и ту же таблицу создать в двух вариантах — обычном и колоночном. А также можно посмотреть трудоемкость выполнения запросов к этим таблицам — правда не с точки зрения времени выполнения (на виртуальной машине оно будет заведомо не показательным), а с точки зрения потребления CPU и I/O каждым отдельным запросом (эта информация пишется в специальный журнал DBQL).
Структуру таблиц можно принять одинаковой для обеих испытуемых и все остальное тоже — SQL запросы, выделенной памяти etc.
На одном сервере сначала производим тестирование MSSQL, а потом Teradata и смотрим есть выигрыш или нет и в каких тестах.
Если Teradata в каких-то тестах обойдет MSSQL, это уже будет повод задуматься о её внедрении. Сам я конечно тоже могу провести эти тесты, но времени не хватает на все. Может быть Teradata так крута, что стоит прямо сейчас начать мигрировать не неё, но мы этого не узнаем :)
На одном сервере сначала производим тестирование MSSQL, а потом Teradata и смотрим есть выигрыш или нет и в каких тестах.
Если Teradata в каких-то тестах обойдет MSSQL, это уже будет повод задуматься о её внедрении. Сам я конечно тоже могу провести эти тесты, но времени не хватает на все. Может быть Teradata так крута, что стоит прямо сейчас начать мигрировать не неё, но мы этого не узнаем :)
При выборе платформы для автоматизации чего-нибудь на крупном предприятии (а на мелких Teradata не нужна) критерий наличия экспертизы, т.е. программистов, администраторов и т. д. гораздо важнее скорости в каких бы то ни было тестах. А вот по этому показателю Teradata сливает буквально всем. Так что если у вас кругом MS SQL, и вам понадобилось хранилище, которое в обычный MS SQL не влезает, смело берите Parallel DWH. И, разумеется, не dell'овскую стойку, а только HP.
А почему не деловскую?
Статистика — упрямая вещь. Та же терадата собрана на делловских серверах, и, по отзывам, сыпется с грохотом.
Я не очень люблю HP, но x86 сервера у них, надо отдать должное, хорошие :)
Я не очень люблю HP, но x86 сервера у них, надо отдать должное, хорошие :)
А можно поточнее где Терадата сыпется и что?
От человека, занимающегося администрированием серверов, слышал, что среднее время жизни терадатовского сервера во вверенных ему ЦОДах — около 2 лет.
То, что при закупке терадаты резервных серверов (HSN) закупается столько же, сколько рабочих (т. е. закупается, скажем, 10 серверов, из которых 5 работает, а 5 тупо ждут, когда один из этих пяти сгорит) косвенно подтверждает слова товарища.
То, что при закупке терадаты резервных серверов (HSN) закупается столько же, сколько рабочих (т. е. закупается, скажем, 10 серверов, из которых 5 работает, а 5 тупо ждут, когда один из этих пяти сгорит) косвенно подтверждает слова товарища.
На самом деле конфигурации бывают разные. Есть конфигурации, когда количество резервных серверов равно количеству рабочих, это правда. Но делается это не по тому, что сервера плохие, а по тому, что сервера иногда умирают. Это факт. Как в старой шутке, что есть 3 вида людей по отношению к бэкапам: люди которые не делают бэкапы, которые делают, и те, которые уже даже восстанавливались.
RAID-1, например, придумали тоже не из-за того что диски плохие, а из-за того, что какими бы они ни были — они умирают. И если наш клиент понимает, что для него система критична настолько, что недопустимы ситуации деградирования производительности даже в случае невероятных аппаратных сбоев (а надо понимать, что если поставить 1 резервный узел на 2 рабочих, то всё плохо будет если выпадет оба резервируемых рабочих узла (как дисковая пара в RAID-1)), то он предпочитает конфигурацию где число HSN (Hot Stand-by Node) равно числу рабочих. А можно поставить и 1 резервный на 2 рабочих. Можно и без резервных.
Касательно 2-х лет жизни сервера, то пока нет возможности подтвердить описаную вами информацию. Скиньте название клиента в личку, я спрошу наш «железный» саппорт о реальной статистике проблем с железом в этом клиенте. Заодно узнаете насколько можно доверять своему знакомому :)
RAID-1, например, придумали тоже не из-за того что диски плохие, а из-за того, что какими бы они ни были — они умирают. И если наш клиент понимает, что для него система критична настолько, что недопустимы ситуации деградирования производительности даже в случае невероятных аппаратных сбоев (а надо понимать, что если поставить 1 резервный узел на 2 рабочих, то всё плохо будет если выпадет оба резервируемых рабочих узла (как дисковая пара в RAID-1)), то он предпочитает конфигурацию где число HSN (Hot Stand-by Node) равно числу рабочих. А можно поставить и 1 резервный на 2 рабочих. Можно и без резервных.
Касательно 2-х лет жизни сервера, то пока нет возможности подтвердить описаную вами информацию. Скиньте название клиента в личку, я спрошу наш «железный» саппорт о реальной статистике проблем с железом в этом клиенте. Заодно узнаете насколько можно доверять своему знакомому :)
Квестую сравнение с Amazon RedShift. Какова цена хранения 1 ТБ на год, с учётом нужного железа и производительности?
Сравнение не валидно. RedShift это облачное решение, а Терадата в 99% случаев это on-premises для корпоративного сегмента. Т.е. под определенные задачи собирается конфигурация, настраивается софт, ставится к заказчику и проводятся любые другие необходимые работы.
P.S. No offense, но меня лично всегда удивлял способ сравнения чего либо ценой за 1ТБ. Это все равно что выбирать машину по принципу цены за лошадиную силу, или за литр багажника :)
P.S. No offense, но меня лично всегда удивлял способ сравнения чего либо ценой за 1ТБ. Это все равно что выбирать машину по принципу цены за лошадиную силу, или за литр багажника :)
On-premis с облачными решениями часто конкурируют и их можно и нужно сравнивать по цене.
В моей картинке мира выходит, что облачное решение распределяет все расходы на инфраструктурные компоненты (питание, координационные механизмы, системы мониторинга и пр.) между потребителями решения. Таким образом, каждый потребитель платит бесконечно маленькую толику за это всё (при количестве потребителей стремящемся к +бесконечности). Таким образом стоимость 1 ТБ равна примерно чистой стоимости 1 ТБ (если убрать маржу). А в on-premis решениях все расходы падают на одного покупателя. Таким образом на стоимость 1 ТБ (а количество ТБ далеко не +бесконечность) падает ненулевая дополнительная стоимость инфраструктурных компонентов. Таким образом грамотно спроектированное облачное решение за единицу объема в пределе будет дешевле для конечного потребителя (я не говорю что лучше, говорю про дешевле). Нет?
Нет, там много факторов надо учитывать. Если это лично ваше облачное решение, то да.
Но поскольку вам его продают — все давно просчитано, так чтобы не было слишком и дешево, даже если обходится в копейки — все это делается для извлечения максимальной прибыли.
При сравнении цен нужно учитывать много факторов — стоимость ПО, поддержку, хостинг, аммортизацию и прочее.
В итоге будет неоднозначная картина — в зависимоти от длительности использования облачных решений. Например первые 20 месяцев это дешевле, но на 21 месяц будет дешевле on-premis решение, потому как оно уже окупиться за это время, а в облаке будете продолжать платить.
В облаке часто взымают плату за трафик, транзакции — чего нет в вашем премисе.
Рассчитайте реально несколько решений в перспективе и увидите разницу.
Но поскольку вам его продают — все давно просчитано, так чтобы не было слишком и дешево, даже если обходится в копейки — все это делается для извлечения максимальной прибыли.
При сравнении цен нужно учитывать много факторов — стоимость ПО, поддержку, хостинг, аммортизацию и прочее.
В итоге будет неоднозначная картина — в зависимоти от длительности использования облачных решений. Например первые 20 месяцев это дешевле, но на 21 месяц будет дешевле on-premis решение, потому как оно уже окупиться за это время, а в облаке будете продолжать платить.
В облаке часто взымают плату за трафик, транзакции — чего нет в вашем премисе.
Рассчитайте реально несколько решений в перспективе и увидите разницу.
Мы изначально говорили про цену за 1 ТБ для потребителя, а вы уже говорите про Total Cost of Ownership, что немного другое ;) но идея понятна, что ценообразование для облака многофакторное.
Но это не отменяет тезиса, что сравнивать машины по стоимости за 1 лошадиную силу как-то странно. Надо же чтобы они хотя бы одного класса были. Там, круиз контроль, подушки безопасности и все такое
Но это не отменяет тезиса, что сравнивать машины по стоимости за 1 лошадиную силу как-то странно. Надо же чтобы они хотя бы одного класса были. Там, круиз контроль, подушки безопасности и все такое
Вы конкурируете за тех же клиентов что и RedShift. В чём ваше преимущество. Знаю клиентов которые отказались от решений Vertica и перешли на RedShift потому что намного выгоднее. Если у вас нет серёзных преимуществ, то решения похожие на ваши вымрут как динозавры.
Очевидно что для вашего решения нужно покупать очень недешовые устройства хранения, нанимать людей которые всё это железо настроят и будут поддерживать. Открыв первый попавшийся на глаза case study «Case Study ROI for a Customer Relationship Management Initiative at GST » от вашей компании вижу железо 1'500'000$ софт 2'500'000$, консалтинг 1'000'000$ + ежегодно за консалтинг 200'000$, за железо 180'000$, софт 450'000$. Если ваше решение при этом обрабатывает менее 1ПТ данных, то Amazon RedShift чистый победитель(примерно 1'000'000$ за 1 ПБ в год при аренде на 3 года), и за разницу можно нанять хорошую команду которая будет писать аналитику и ещё на несколько Бентли для CEO останется, а учитывая что цены на Амазоновские сервиса посточнно снижаются, то нужны очень серёзные причины чтобы выбрать ваше решение.
З другой стороны, очевидно что решение Amazon RedShift не сможет покрыть все нужды и ParAccel продаёт более серьёзное решение за другие деньги, но я пока не вижу что вы можете лучше предложить.
Очевидно что для вашего решения нужно покупать очень недешовые устройства хранения, нанимать людей которые всё это железо настроят и будут поддерживать. Открыв первый попавшийся на глаза case study «Case Study ROI for a Customer Relationship Management Initiative at GST » от вашей компании вижу железо 1'500'000$ софт 2'500'000$, консалтинг 1'000'000$ + ежегодно за консалтинг 200'000$, за железо 180'000$, софт 450'000$. Если ваше решение при этом обрабатывает менее 1ПТ данных, то Amazon RedShift чистый победитель(примерно 1'000'000$ за 1 ПБ в год при аренде на 3 года), и за разницу можно нанять хорошую команду которая будет писать аналитику и ещё на несколько Бентли для CEO останется, а учитывая что цены на Амазоновские сервиса посточнно снижаются, то нужны очень серёзные причины чтобы выбрать ваше решение.
З другой стороны, очевидно что решение Amazon RedShift не сможет покрыть все нужды и ParAccel продаёт более серьёзное решение за другие деньги, но я пока не вижу что вы можете лучше предложить.
На самом деле преимуществ множество, и мы пытаемся потихоньку рассказывать о имеющихся возможностях в постах, публикуемых тут. Вы правильно сказали, что не всякое решение покроет все нужды, поэтому и существует выбор платформ. Может быть ваши вопросы как раз из-за того, что мы не так много успели рассказать :)
Но первое что пришло в голову сейчас просто для примера — в Терадате, как мы описали в посте, возможно гибридное хранение данных, где по колонкам, а где по строкам. Так что на вскидку для запросов, которые выбирают много данных из «широких» таблиц гибридные функции дадут лучшее время отклика, чем чисто на колоночном хранении. Так что если специфика ваших процессов такова, что требуются как точечные запросы, которые должны быстро вернуть малое количество колонок, так и большие аналитические запросы по большому количеству столбцов (кто собирал, например, банковскую аналитику, тот поймет), то гибридное хранение может дать очень серьезные преимущества. А если к этому добавить десятки тысяч конкурентных сессий…
Но первое что пришло в голову сейчас просто для примера — в Терадате, как мы описали в посте, возможно гибридное хранение данных, где по колонкам, а где по строкам. Так что на вскидку для запросов, которые выбирают много данных из «широких» таблиц гибридные функции дадут лучшее время отклика, чем чисто на колоночном хранении. Так что если специфика ваших процессов такова, что требуются как точечные запросы, которые должны быстро вернуть малое количество колонок, так и большие аналитические запросы по большому количеству столбцов (кто собирал, например, банковскую аналитику, тот поймет), то гибридное хранение может дать очень серьезные преимущества. А если к этому добавить десятки тысяч конкурентных сессий…
У вас при покупки машины нет ТЗ.
В коммерческом проекте нам не нужен круиз контроль — мы делаем только то что надо.
Онпремис и облако предлагает data warehouse. Определяем что нам нужно и если оба подходят можем сравнивать по деньгам.
В коммерческом проекте нам не нужен круиз контроль — мы делаем только то что надо.
Онпремис и облако предлагает data warehouse. Определяем что нам нужно и если оба подходят можем сравнивать по деньгам.
Sign up to leave a comment.
Поколоночное и гибридное хранение записей в СУБД Teradata