Pull to refresh
28
0
А чем DbFit не подошел?
Скажем так: отличаться будет. Первое что приходит в голову — оптимизатор принимает те или иные решения в т.ч. основываясь на статистике по количествую записей и их объему. Поэтому при тех же параметрах физ. модели (PI, SI, партиции и пр.) но при совершенно другом объеме данных и решения оптимизатора могут быть другими. Плюс на Express Edition не будет учтено влияние таких вещей как Teradata Intelligent Memory, Teradata Virtual Storage, которые есть на аппартно-программной версии Teradata.
Так что в принципе отличия будут, но на мой взгляд не критичные в рамках дипломной работы.
Всё верно. В SMP редакции СУБД как правило не стоит вопрос обеспечения максимальной производительности. И в версиях для виртуальных машин (Teradata Virtual Machine Edition) так же физический слой не нужен, реализация исключительно на уровне ПО.
Главное что бы не забывали накладывать условия для отсечения «не ответственный» во всех вариациях, а то я не удивлюсь…
Наоборот — подцепиться к ней и отлично изучить привычки хозяев, время прихода и ухода. А дальше вырубить ее и грабь не хочу.
Любители заговоров обязательно увидят след руки АНБ в разработке и распространении такой системы «безопасности»
Когда мы готовили статьи, то тоже думали в какую сторону лучше их развернуть. Решили остановиться на обучающем материале, который хоть и берет информацию из документации, но рассматривает ее через призму примеров, рекомендаций, выводов. Просто переводить документацию и правда дело не особо полезное, поэтому мы стараемся писать статьи больше в образовательном смысле и на основе личного опыта реального использования системы.
Киллер-фичи проскальзывают в разных статьях в зависимости от темы, но такого сжатого их сборника и правда, нет. Спасибо за идею, надо подумать как их объединить, чтобы концентрированно и понятно. Только, ох, чую, будет холливор в комментах :) но это даже интересно.

P.S. А принципиальные архитектурные отличия и то, откуда у всего ноги растут, мы постарались в нашей первой статье описать: habrahabr.ru/company/teradata/blog/160821/
Было бы интересно узнать что с проектом на данный момент. Твиттер замер, оба домена не отвечают (questli.com, quest.li).
Справедливости ради надо отметить, что команды и пакеты приведены для x64 инсталяции. Так же в команде по установке множества полезных вещей у вас 2 install, что немного портит картину.

Модифицированные команды установки пакетов для x86:
sudo add-apt-repository ppa:xorg-edgers/ppa
sudo apt-get update
sudo apt-get install fglrx

и

sudo apt-get install build-essential cdbs fakeroot dh-make debhelper debconf libstdc++6 dkms libqtgui4 wget execstack libelfg0 dh-modaliases ia32-libs-multiarch i386 libgcc1 libc6 linux-headers-generic libcurl4-openssl-dev libncurses5-dev pkg-config automake yasm screen

авось кому пригодится.
За статью спасибо в карму ;)
Ого! Спасибо, не знал. Видео прям цепляет, такое ощущение что в IMAX сидишь :) правда снова бета («PUBLIC BETA SIGN-UP»), но любопытно что изменилось с прошлой версии
После смерти релизной Vox это самое близкое к тому, что мне хочется! Добавьте, пожалуйста, поддержку FLAC и возможность накидывать плейлисты — будет вообще «пэрсык» ©
Чуть-чуть подправил заголовок и первое предложение вступления. Это правда даст чуть больше информации о том, что же такое AR.Drone если кто-то не знает. Спасибо.
На самом деле конфигурации бывают разные. Есть конфигурации, когда количество резервных серверов равно количеству рабочих, это правда. Но делается это не по тому, что сервера плохие, а по тому, что сервера иногда умирают. Это факт. Как в старой шутке, что есть 3 вида людей по отношению к бэкапам: люди которые не делают бэкапы, которые делают, и те, которые уже даже восстанавливались.
RAID-1, например, придумали тоже не из-за того что диски плохие, а из-за того, что какими бы они ни были — они умирают. И если наш клиент понимает, что для него система критична настолько, что недопустимы ситуации деградирования производительности даже в случае невероятных аппаратных сбоев (а надо понимать, что если поставить 1 резервный узел на 2 рабочих, то всё плохо будет если выпадет оба резервируемых рабочих узла (как дисковая пара в RAID-1)), то он предпочитает конфигурацию где число HSN (Hot Stand-by Node) равно числу рабочих. А можно поставить и 1 резервный на 2 рабочих. Можно и без резервных.
Касательно 2-х лет жизни сервера, то пока нет возможности подтвердить описаную вами информацию. Скиньте название клиента в личку, я спрошу наш «железный» саппорт о реальной статистике проблем с железом в этом клиенте. Заодно узнаете насколько можно доверять своему знакомому :)
А можно поточнее где Терадата сыпется и что?
На самом деле преимуществ множество, и мы пытаемся потихоньку рассказывать о имеющихся возможностях в постах, публикуемых тут. Вы правильно сказали, что не всякое решение покроет все нужды, поэтому и существует выбор платформ. Может быть ваши вопросы как раз из-за того, что мы не так много успели рассказать :)
Но первое что пришло в голову сейчас просто для примера — в Терадате, как мы описали в посте, возможно гибридное хранение данных, где по колонкам, а где по строкам. Так что на вскидку для запросов, которые выбирают много данных из «широких» таблиц гибридные функции дадут лучшее время отклика, чем чисто на колоночном хранении. Так что если специфика ваших процессов такова, что требуются как точечные запросы, которые должны быстро вернуть малое количество колонок, так и большие аналитические запросы по большому количеству столбцов (кто собирал, например, банковскую аналитику, тот поймет), то гибридное хранение может дать очень серьезные преимущества. А если к этому добавить десятки тысяч конкурентных сессий…
точно, и я об этом же. сначала надо понять что всё подходит
Мы изначально говорили про цену за 1 ТБ для потребителя, а вы уже говорите про Total Cost of Ownership, что немного другое ;) но идея понятна, что ценообразование для облака многофакторное.

Но это не отменяет тезиса, что сравнивать машины по стоимости за 1 лошадиную силу как-то странно. Надо же чтобы они хотя бы одного класса были. Там, круиз контроль, подушки безопасности и все такое
В моей картинке мира выходит, что облачное решение распределяет все расходы на инфраструктурные компоненты (питание, координационные механизмы, системы мониторинга и пр.) между потребителями решения. Таким образом, каждый потребитель платит бесконечно маленькую толику за это всё (при количестве потребителей стремящемся к +бесконечности). Таким образом стоимость 1 ТБ равна примерно чистой стоимости 1 ТБ (если убрать маржу). А в on-premis решениях все расходы падают на одного покупателя. Таким образом на стоимость 1 ТБ (а количество ТБ далеко не +бесконечность) падает ненулевая дополнительная стоимость инфраструктурных компонентов. Таким образом грамотно спроектированное облачное решение за единицу объема в пределе будет дешевле для конечного потребителя (я не говорю что лучше, говорю про дешевле). Нет?
Сравнение не валидно. RedShift это облачное решение, а Терадата в 99% случаев это on-premises для корпоративного сегмента. Т.е. под определенные задачи собирается конфигурация, настраивается софт, ставится к заказчику и проводятся любые другие необходимые работы.

P.S. No offense, но меня лично всегда удивлял способ сравнения чего либо ценой за 1ТБ. Это все равно что выбирать машину по принципу цены за лошадиную силу, или за литр багажника :)
Идея с автосбором статистик по мелким таблицам в песочницах бизнес-пользователей интересная. При таком подходе, правда, придется заставить пользователя запускать запросы через специальную процедурину (или хотя бы перед запуском самого запроса прогонять текст запроса через ту самую процедурину). Но возникает другой вопрос — какие статистики собирать, а какие нет. Diagnostic helpstats безусловно полезная штука, но ее тоже надо уметь готовить. Сбор всех под ряд рекомендованых статистик штука опасная. CPU время на сбор статистики и правда может быть мало, другой вопрос с IO. Потому что при сборе статистики происходит полное сканирование таблицы.
Я это к чему — автопомогалку по сбору статистики для песочниц бизнес-пользователей прикрутить можно, и это хорошая идея «на подумать». Но все равно потребуется вовлечение мозга, чтобы прикинуть сколько займет сам сбор статистики и насколько это поможет запросу. Можно встроить оценки по количеству строк в таблице и какие-то другие объективные критерии. В общем, есть над чем подумать)
P.S. Мы еще часто используем продукт TASM (Teradata Active System Management) для обнаружения «на лету» плохих пользовательских запросов, и, либо их остановки, либо выделения им отдельных ресурсов, чтобы они не мешали другим, или побыстрее выполнились и «вышли вон» из системы.
Нас покритиковали, что предыдущая была поверхностная. Мы услышали. Так что эта подробная :)

Information

Rating
Does not participate
Registered
Activity