Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
кириллk Member Откуда: Сообщений: 1058 |
1 таблица с 3 полями и 1 лярд записей или 1 таблица 100 полей и 10 миллионов записей Спвсибо |
7 мар 19, 15:40 [21827472] Ответить | Цитировать Сообщить модератору |
L_argo Member Откуда: Сообщений: 1406 |
Но второй вариант ковырять может быть проще. |
||
7 мар 19, 15:57 [21827494] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37155 |
Очевидно, та, которая позволит меньше тратить ресурсов и выполнять запросы быстрее. |
7 мар 19, 15:58 [21827500] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
зависит от типа нагрузки, логики/сложности расчётов и размеров выборок, кардинальности, конфигураций сервера и тд. у обоих подходов в некоторых сценариях будут преимущества над другим методом например у второго варианта будет явное преимущество в скорости навигации между элементами / комбинацией ключей |
7 мар 19, 16:02 [21827508] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
Что быстрее - зависит от запросов, но чаще всего быстрее будет 2-й вариант. |
||
7 мар 19, 17:20 [21827592] Ответить | Цитировать Сообщить модератору |
Mind Member Откуда: Лучший город на Земле Сообщений: 2322 |
|
||
7 мар 19, 22:50 [21827784] Ответить | Цитировать Сообщить модератору |
tarrus Member Откуда: Bergen Сообщений: 831 |
Это как так? Количество информации не меняется. |
||||
8 мар 19, 12:29 [21827900] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
допустим два ключа (bigint + int , 8+4=12 byte) и какой-нибудь факт (decimal/numeric/money) на скажем 13 байтов итого 25 байтов с вертикальным хранением фактов на миллиард строк (в результате 25 * 1 Млрд = 25 Млрд байтов или 23Gb) то-же самое с горизонтальным хранением (т.е. композитный ключ уникален): с 98 полей 13-байтных фактов и 2 ключа = 1286 байтов, но количество строк в 98 раз меньше т.е. 1286 * 1 миллиард / 98 = 12Gb итого хранение: вертикально - 23Гб горизонтально - 12Гб экономия за счёт ключей в два раза (в данном случае: 12 байтов на ключи и 13 на факты) |
||
8 мар 19, 13:50 [21827955] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
В первом варианте получаем 1Г * 3 * 4 = 12 Гб Во втором варианте получаем 10М * 100 * 4 = 4 Гб То есть, на первый взгляд разница в 3 раза. Но на самом деле, для хранения строки нужно ещё 8 байт. То есть, по размеру, это ещё как 2 невидимых целых числа на строку. Тогда в первом варианте получаем 1Г * ( 3 * 4 + 8 ) = 20 Гб, уже в 5 раз больше Это я ещё не считаю верхний уровень индекса, ну да ладно, можно пренебречь. |
||||
8 мар 19, 14:37 [21827968] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
Если используется малая часть (или даже одно значение), то "узкий". Это, в общем, классический DWH. Есть время измерения, счётчик, значение. Можно так и хранить, как "узкую" таблицу. А можно сделать таблицу с временем как ПК, и колонками-счётчиками. У нас сначала хранились широкие таблицы, но это было несколько неудобно, потому что разные группы счётчиков мерялись в разное время, + их было долстаточно много (десятки тысяч), так что одну широкую таблицу было сделать невозможно. Поэтому было много "широких" таблиц, по группам счётчиков. Но для расчётов и прочего это было неудобно, поэтому потом перешли на одну узкую таблицу (занявшую все террабайты дисковой подсистемы). Хотя для места, и для скорости, это неэффективно. |
||
8 мар 19, 14:53 [21827980] Ответить | Цитировать Сообщить модератору |
Alexander Us Member Откуда: Сообщений: 1153 |
кириллk, Не для Qlikview случайно? |
8 мар 19, 18:44 [21828078] Ответить | Цитировать Сообщить модератору |
PizzaPizza Member Откуда: Сообщений: 417 |
Если уже считать по объёму данных (что конечно коррелирует со скоростью выборок), то я лично не понимаю, как можно сравнивать разные данные. Таблица с тремя полями и миллиардом записей != таблице с 100 полями и 10 миллионами записей. Чисто математически. 3 000 000 000 != 1 000 000 000 |
||
8 мар 19, 19:12 [21828086] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
PizzaPizza, 1Млрд = 1'000 миллионов 3 поля из которых два ключа и один факт в горизонтальное (или широкое как указали выше) хранение 100 полей (2 ключа и 98 фактов) это 1'000 Млн. / 98 ~ 10.2 Млн т.е. в данном случае миллиард вполне пропорционален 10 млн. |
8 мар 19, 19:59 [21828105] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
|
||||
8 мар 19, 21:25 [21828142] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
Итого 101 поле, а до 100 автор просто округлил :-) |
||
8 мар 19, 21:28 [21828144] Ответить | Цитировать Сообщить модератору |
PizzaPizza Member Откуда: Сообщений: 417 |
Не получается у меня никак. Автор пишет про три поля - 1 000 000 000 000 (спасибо за поправку про миллиарды) записей 100 полей - 10 000 000 000 записей Допустим на каждую запись служебной информации надо добавить (хотя мне кажется, что служебная информация для записи из 100 полей побольше будет, чем для записи в 3 поля и то на то и получится, но допустим), это +1 поле каждой записи. Получаем 4 * 1 000 000 000 000 полей 101 * 10 000 000 000 записей Получаем 4 000 000 000 000 != (совсем никак) 1 010 000 000 000. Кстати хорошо бьется с вашими 2-3-5 разами разницы. Имхо автор говорит о совершенно разном наборе данных, а все остальное, все допуски на 2 ключа (почему в первой таблице три ключа, а во второй не пять?) это уже чистая спекуляция без понимания реальной структуры и типа данных. |
||
8 мар 19, 21:50 [21828161] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
PizzaPizza, при чём здесь триллионы? |
8 мар 19, 21:59 [21828166] Ответить | Цитировать Сообщить модератору |
PizzaPizza Member Откуда: Сообщений: 417 |
alexeyvg, Я имею ввиду, что простое допущение про два ключа в первой таблице сразу дает большую разницу между таблицами. Поэтому сравнивать таблицу с одним ключом и двумя для меня странно - они не транслируются друг в друга, либо же во второй таблице из 100 полей есть больше одного ключа. Иначе это не сравнение горизонтальная vs вертикальная таблица и/или разный набор данных, который соответственно может различаться в разы по количеству полей и данных. |
8 мар 19, 22:04 [21828168] Ответить | Цитировать Сообщить модератору |
PizzaPizza Member Откуда: Сообщений: 417 |
Боже боже, теперь лишние нули накопировал. Ну главное, что соотношение не меняется. |
||
8 мар 19, 22:09 [21828173] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
В этом и вопрос автора. Он выбирает, как хранить одни и те же данные - в 10 млн строк широкой таблицы, или в миллиарде строк узкой, что бы быстрее двыполнялись аналитическмие запросы. Во второй таблице в принципе должен быть один ключ, но даже если (как в моём примере выше) там будет 2 ключа - это неважно, потому что добавление одного ключа в "широкую" таблицу не даёт какого либо изменения объёмов хранения. Какая разница, на 100 полезных полей будет одно бесполезное поле, или два? Как они транслируются - я уже 2 раза написал выше. Это типичный выбор для задач DWH, и именно так транслируются эти узкая и широкая таболицы в друг друга, я даже вам поля перечислил. |
||
8 мар 19, 22:14 [21828174] Ответить | Цитировать Сообщить модератору |
PizzaPizza Member Откуда: Сообщений: 417 |
Ага, спасибо. Время измерения это естественный ключ для горизонтальных таблиц, это для меня идея для подумать. Это конечно же экономит атрибут для широкой таблицы и добавляет для узкой. Никогда не имел задач с выборкой по времени как сущности поэтому мне была не очевидна проблема. |
||
8 мар 19, 22:36 [21828180] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
Полюс ещё 8 невидимых байт (внутренних для SQL Server) на каждую строку, то есть на каждое значение - это тоже очень много. |
||||
8 мар 19, 23:12 [21828193] Ответить | Цитировать Сообщить модератору |
.Евгений Member Откуда: Сообщений: 654 |
Отмечу, что не пока раскрыты влияние глубины индекса и степень сжатия. Серьезно к теме не отношусь, согласен с отсутствием универсального ответа. |
8 мар 19, 23:44 [21828200] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |