кириллk1 таблица с 3 полями и 1 лярд записей

или

1 таблица 100 полей и 10 миллионов записейВ первом варианте таблица будет больше в 6 раз

Что быстрее - зависит от запросов, но чаще всего быстрее будет 2-й вариант.

tarrusalexeyvgпропущено...
В первом варианте таблица будет больше в 6 раз

Что быстрее - зависит от запросов, но чаще всего быстрее будет 2-й вариант.

Это как так? Количество информации не меняется.Возмём для примера целые поля.

В первом варианте получаем 1Г * 3 * 4 = 12 Гб
Во втором варианте получаем 10М * 100 * 4 = 4 Гб

То есть, на первый взгляд разница в 3 раза.

Но на самом деле, для хранения строки нужно ещё 8 байт. То есть, по размеру, это ещё как 2 невидимых целых числа на строку.

Тогда в первом варианте получаем 1Г * ( 3 * 4 + 8 ) = 20 Гб, уже в 5 раз больше

Это я ещё не считаю верхний уровень индекса, ну да ладно, можно пренебречь.

alexeyvgВозмём для примера целые поля.
...
в 5 раз большеДа, и если вернуться к собственно "аналтитческим запросам", то тут зависит от запросов - если в запросе одновременно используется вся длинная строка, или её бОльшая часть, то быстрее будет "широкий" вариант.
Если используется малая часть (или даже одно значение), то "узкий".

Это, в общем, классический DWH.

Есть время измерения, счётчик, значение.
Можно так и хранить, как "узкую" таблицу. А можно сделать таблицу с временем как ПК, и колонками-счётчиками.

У нас сначала хранились широкие таблицы, но это было несколько неудобно, потому что разные группы счётчиков мерялись в разное время, + их было долстаточно много (десятки тысяч), так что одну широкую таблицу было сделать невозможно.
Поэтому было много "широких" таблиц, по группам счётчиков.

Но для расчётов и прочего это было неудобно, поэтому потом перешли на одну узкую таблицу (занявшую все террабайты дисковой подсистемы). Хотя для места, и для скорости, это неэффективно.

PizzaPizzaЕсли уже считать по объёму данных (что конечно коррелирует со скоростью выборок), то я лично не понимаю, как можно сравнивать разные данные. Таблица с тремя полями и миллиардом записей != таблице с 100 полями и 10 миллионами записей. Чисто математически.

3 000 000 000 != 1 000 000 000Я же написал:
alexeyvgЭто, в общем, классический DWH.

Есть время измерения, счётчик, значение.
Можно так и хранить, как "узкую" таблицу. А можно сделать таблицу с временем как ПК, и колонками-счётчиками.В обоих случаях хранится один миллиард значений, но в первом случае он хранится в трёх миллиардах полей (то есть в одном миллиарде записей, по одной записи на каждое значение, в записи 3 поля - значение, + 2 ключа ), во втором случае в одном миллиарде полей - 10 миллионов записей по 100 значений.

vikkivв горизонтальное (или широкое как указали выше)
хранение 100 полей (2 ключа и 98 фактов)Скорее, там 1 поле ключ, и 100 полей - факты.
Итого 101 поле, а до 100 автор просто округлил :-)

PizzaPizzaalexeyvg,

Я имею ввиду, что простое допущение про два ключа в первой таблице сразу дает большую разницу между таблицами. Поэтому сравнивать таблицу с одним ключом и двумя для меня странно - они не транслируются друг в друга, либо же во второй таблице из 100 полей есть больше одного ключа. Иначе это не сравнение горизонтальная vs вертикальная таблица и/или разный набор данных, который соответственно может различаться в разы по количеству полей и данных.Это сравнение двух реализаций одной и той же задачи - "хранение миллиарда значений и аналитичечские запросы к этим данным"
В этом и вопрос автора.
Он выбирает, как хранить одни и те же данные - в 10 млн строк широкой таблицы, или в миллиарде строк узкой, что бы быстрее двыполнялись аналитическмие запросы.

Во второй таблице в принципе должен быть один ключ, но даже если (как в моём примере выше) там будет 2 ключа - это неважно, потому что добавление одного ключа в "широкую" таблицу не даёт какого либо изменения объёмов хранения. Какая разница, на 100 полезных полей будет одно бесполезное поле, или два?

Как они транслируются - я уже 2 раза написал выше.
Это типичный выбор для задач DWH, и именно так транслируются эти узкая и широкая таболицы в друг друга, я даже вам поля перечислил.

PizzaPizzaalexeyvgКак они транслируются - я уже 2 раза написал выше.
Это типичный выбор для задач DWH, и именно так транслируются эти узкая и широкая таболицы в друг друга, я даже вам поля перечислил.

Ага, спасибо. Время измерения это естественный ключ для горизонтальных таблиц, это для меня идея для подумать. Это конечно же экономит атрибут для широкой таблицы и добавляет для узкой.
Никогда не имел задач с выборкой по времени как сущности поэтому мне была не очевидна проблема.Даже если не только время измения, тут важно, что ключи дают незначительный оверхед к данным. Пуксть даже ещё 10 полей в ключах, что это по сравнению с 100 полями данных? А вот для записи с одним полем данных даже один ключ - это много.
Полюс ещё 8 невидимых байт (внутренних для SQL Server) на каждую строку, то есть на каждое значение - это тоже очень много.