Комментарии 7
Если создавать NoPI Table, то вместо Primary Index строкам будет присваиваться какой-то другой уникальный идентификатор, я правильно понимаю? Какой тип данных будет у этого идентификатора?
Я хочу в таблице создать столбец ID BIGINT NOT NULL с уникальными значениями в качестве Primary Index. Можно ли тогда вместо этого вообще не указывать PI и чтобы он сам создался?
Я хочу в таблице создать столбец ID BIGINT NOT NULL с уникальными значениями в качестве Primary Index. Можно ли тогда вместо этого вообще не указывать PI и чтобы он сам создался?
При создании NoPI таблицы каждая строка тоже получает уникальный идентификатор размером 64 бита, состоящий из hash bucket (16 или 20 бит) и uniqueness value (остальные биты), размерность которого увеличена, так как большое количество строк на одном AMPе будет иметь одинаковое значение hash bucket.
Если я правильно понял смысл второго вопроса, то он следующий: «будет ли создан PI для таблицы, DDL команда создания которой не содержит явного указания на создание первичного индекса –… PRIMARY INDEX …».
Ответ такой:
Если в команде создания таблицы указан PRIMARY KEY, то по его колонкам создается UPI (Unique Primary Index)
иначе
если указаны колоночные ограничения UNIQUE, то по колонке ПЕРВОГО ограничения UNIQUE создается UPI (Unique Primary Index)
иначе
если указаны табличные ограничения UNIQUE, то по колонкам ПЕРВОГО табличного ограничения UNIQUE создается UPI (Unique Primary Index)
иначе
по первой колонке таблицы создается неуникальный первичный индекс (NUPI)*.
* зависит от настроек системы. При значении параметра «Primary Index Default» равном “N”, отсутствии явного определения PI и уникальных ограничений уровня колонки или таблицы в команде создания таблицы, Teradata создаст NoPI таблицу.
Если я правильно понял смысл второго вопроса, то он следующий: «будет ли создан PI для таблицы, DDL команда создания которой не содержит явного указания на создание первичного индекса –… PRIMARY INDEX …».
Ответ такой:
Если в команде создания таблицы указан PRIMARY KEY, то по его колонкам создается UPI (Unique Primary Index)
иначе
если указаны колоночные ограничения UNIQUE, то по колонке ПЕРВОГО ограничения UNIQUE создается UPI (Unique Primary Index)
иначе
если указаны табличные ограничения UNIQUE, то по колонкам ПЕРВОГО табличного ограничения UNIQUE создается UPI (Unique Primary Index)
иначе
по первой колонке таблицы создается неуникальный первичный индекс (NUPI)*.
* зависит от настроек системы. При значении параметра «Primary Index Default» равном “N”, отсутствии явного определения PI и уникальных ограничений уровня колонки или таблицы в команде создания таблицы, Teradata создаст NoPI таблицу.
Напомним, что данные в СУБД Teradata распределяются с использованием результата хеширования значения колонки первичного индекса. Строки с одинаковыми значениями колонки первичного индекса ВСЕГДА попадают на один и тот же AMP.
Можно ли добавлять AMP к уже существующей БД? Будет ли при этом происходить полное перестроение БД?
Наверно хороший продукт, о котором я бы хотел узнать побольше. Но первые 6 абзацев, которые осилил (а подозреваю и весь остальной текст) описывает то, что я бы лучше прочитал в документации системы.
Если я не знал до этого о том, зачем нужна Teradata (а я не знал), то в этой статье и не узнаю. А если знал, то содержание статьи ожидаю найти в мануалах.
Надеюсь, статья найдет своих читателей, но, имхо, в статье, имеет смыл писать о важных отличиях, проводить сравнения, рассказывать о киллер-фичах и т.д.
Если я не знал до этого о том, зачем нужна Teradata (а я не знал), то в этой статье и не узнаю. А если знал, то содержание статьи ожидаю найти в мануалах.
Надеюсь, статья найдет своих читателей, но, имхо, в статье, имеет смыл писать о важных отличиях, проводить сравнения, рассказывать о киллер-фичах и т.д.
Когда мы готовили статьи, то тоже думали в какую сторону лучше их развернуть. Решили остановиться на обучающем материале, который хоть и берет информацию из документации, но рассматривает ее через призму примеров, рекомендаций, выводов. Просто переводить документацию и правда дело не особо полезное, поэтому мы стараемся писать статьи больше в образовательном смысле и на основе личного опыта реального использования системы.
Киллер-фичи проскальзывают в разных статьях в зависимости от темы, но такого сжатого их сборника и правда, нет. Спасибо за идею, надо подумать как их объединить, чтобы концентрированно и понятно. Только, ох, чую, будет холливор в комментах :) но это даже интересно.
P.S. А принципиальные архитектурные отличия и то, откуда у всего ноги растут, мы постарались в нашей первой статье описать: habrahabr.ru/company/teradata/blog/160821/
Киллер-фичи проскальзывают в разных статьях в зависимости от темы, но такого сжатого их сборника и правда, нет. Спасибо за идею, надо подумать как их объединить, чтобы концентрированно и понятно. Только, ох, чую, будет холливор в комментах :) но это даже интересно.
P.S. А принципиальные архитектурные отличия и то, откуда у всего ноги растут, мы постарались в нашей первой статье описать: habrahabr.ru/company/teradata/blog/160821/
Не бросайте писать такого рода статьи, пожалуйста! Они нам очень нужны и помогают разобраться в деталях.
Многие из ваших читателей не имеют возможности писать комментарии и подкидывать идеи для новых статей. Я, например, начала писать про Терадату ради инвайта и чтобы записывать то, что поняла или перевела сама.
Спасибо, что продолжили писать статьи!
Многие из ваших читателей не имеют возможности писать комментарии и подкидывать идеи для новых статей. Я, например, начала писать про Терадату ради инвайта и чтобы записывать то, что поняла или перевела сама.
Спасибо, что продолжили писать статьи!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Физический дизайн структур хранения в СУБД Teradata