Спасибо за статью. Подскажите пожалуйста, по какому принципу Вы расставляли биконы? Около каждого "интересного места" только один бекон, или несколько рядом стоящих, чтобы улучшить fingerprinting?
Подскажите пожалуйста по Вашему опыту, как монетизируются браузерные игры? Расходы понятны, а доходы?
Понимаю что это, возможно, тема отдельной статьи, но хотя бы пару слов.
Реальные тесты производительности как правило делаются для конкретных Заказчиков, поскольку результаты очень сильно зависят от конкретной структуры таблиц и SQL-запросов к ним.
Другой вариант — использовать виртуальные машины Teradata Express под VMWare, которые можно скачать в свободном доступе. Там вполне можно протестировать, насколько сильно сожмутся данные, если одну и ту же таблицу создать в двух вариантах — обычном и колоночном. А также можно посмотреть трудоемкость выполнения запросов к этим таблицам — правда не с точки зрения времени выполнения (на виртуальной машине оно будет заведомо не показательным), а с точки зрения потребления CPU и I/O каждым отдельным запросом (эта информация пишется в специальный журнал DBQL).
По индексированным полям собирается статистика. Это гистограммы, показывающие распределение количества строчек по диапазонам значений. Для каждого диапазона фиксируются его границы, общее количество строчек в диапазоне, модальное значение, количество строк на модальное значение, и т.д. Далее для конкретного условия where Оптимизатор смотрит нужный диапазон значений для той константы, которая указана в условии where, и делает оценку количества значений.
В Вашем примере среднее количество строчек на значение равно 500 тыс. (миллиард записей разделить на пару тысяч уникальных значений). Если есть какие-то пиковые значения, то они попадут в модальные значения, и Оптимизатор будет знать об них точную информацию. В остальных случаях, делаются оценки. Понятно, что сильно неравномерное распределение по количеству влияет на точность оценок.
Отсутствие хинтов — это когда пользователи пишут только SQL-запрос. Хинты — это когда пользователи пишут как SQL-запрос, так и план выполнения для него. Как правило, для большинства пользователей первый случай удобнее.
Если какой-то план неоптимален и «хочется написать хинты» — то, как правило, это либо отсутствует статистика, либо устаревшая статистика.
Для указанного выше примера, я бы предложил уточнить постановку задачи — какая таблица рассматривается (проводки, CDRы, ...), есть ли партиционирование (по времени), какая колонка имеет сильно неравномерное распределение по количеству строчек. Для конкретной задачи всегда удобнее найти нужное решение.
Понимаю что это, возможно, тема отдельной статьи, но хотя бы пару слов.
Другой вариант — использовать виртуальные машины Teradata Express под VMWare, которые можно скачать в свободном доступе. Там вполне можно протестировать, насколько сильно сожмутся данные, если одну и ту же таблицу создать в двух вариантах — обычном и колоночном. А также можно посмотреть трудоемкость выполнения запросов к этим таблицам — правда не с точки зрения времени выполнения (на виртуальной машине оно будет заведомо не показательным), а с точки зрения потребления CPU и I/O каждым отдельным запросом (эта информация пишется в специальный журнал DBQL).
В Вашем примере среднее количество строчек на значение равно 500 тыс. (миллиард записей разделить на пару тысяч уникальных значений). Если есть какие-то пиковые значения, то они попадут в модальные значения, и Оптимизатор будет знать об них точную информацию. В остальных случаях, делаются оценки. Понятно, что сильно неравномерное распределение по количеству влияет на точность оценок.
Отсутствие хинтов — это когда пользователи пишут только SQL-запрос. Хинты — это когда пользователи пишут как SQL-запрос, так и план выполнения для него. Как правило, для большинства пользователей первый случай удобнее.
Если какой-то план неоптимален и «хочется написать хинты» — то, как правило, это либо отсутствует статистика, либо устаревшая статистика.
Для указанного выше примера, я бы предложил уточнить постановку задачи — какая таблица рассматривается (проводки, CDRы, ...), есть ли партиционирование (по времени), какая колонка имеет сильно неравномерное распределение по количеству строчек. Для конкретной задачи всегда удобнее найти нужное решение.