Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Как будет работать быстрее?  [new]
AR®
Member

Откуда: Подмосковье
Сообщений: 326
Есть необходимость периодически переливать из таблиц в таблицы данные в общем объёме где-то до 100 млн. записей.

В каком случае это будет работать быстрее:
1) таблицы источника и назначения в одной базе
2) таблицы источника и назначения в одной базе, но разнесены в разные файлы
3) таблицы источника и назначения в разных соседних базах

Во всех случаях подразумевается, что всё происходит на одном и том же сервере.
9 окт 19, 12:59    [21990316]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36450
Вопрос звучит примерно так:

"В каком случае будет добраться на автобусе быстрее:

1. Если ехать на заднем сидении
2. Если ехать у окна
3. Если ехать стоя

Во всех случаях подразумевается, что всё происходит в одном и том же автобусе."
9 окт 19, 13:02    [21990322]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
AR®
Member

Откуда: Подмосковье
Сообщений: 326
Не согласен с предложенной Вами аналогией.
Вы хотите сказать, что затраченное время не будет зависеть от выбранного 1 из 3 предложенных вариантов? Не поверю.
9 окт 19, 13:18    [21990340]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6788
AR®,

чтобы было быстрее - используйте физически разные диски и контроллеры источника и получателя. Проследите, чтобы на получателе были диски без "черепицы".
9 окт 19, 13:20    [21990341]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36450
AR®,

Будет зависеть от возможности утилизировать ресурсы, в том числе и дисковые. Если у вас базы все на одном физическом сервере да еще и на одном физическом дисковом массиве, то откуда должен появиться выигрыш?
9 окт 19, 13:20    [21990342]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6788
На самом деле это все БАД и припарки. На хороших серверных хранилищах это что в бок, что сверху. Но на бюджетных разница может быть.
9 окт 19, 13:21    [21990346]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
AR®
Member

Откуда: Подмосковье
Сообщений: 326
Владислав Колосов
Но на бюджетных разница может быть.

Это именно наш случай.
9 окт 19, 13:24    [21990350]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6788
AR®,

если льется постоянно, то имеет смысл отдать процессорное ядро под IO через Affinity mask. Также, если есть возможность, секционируйте кластерный индекс таблиц и заливайте секции одновременно в несколько потоков. Потоки легко сделать при помощи Integration Services. Разместите секции на разные диски. Понятно, что если источник будет разбит на секции и также размещен на разных дисках, должен быть эффект.
9 окт 19, 13:32    [21990359]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4987
AR®
Есть необходимость периодически переливать из таблиц в таблицы данные в общем объёме где-то до 100 млн. записей.

В каком случае это будет работать быстрее:

4. partition switch

https://sqlrus.com/2018/03/using-switch-on-a-single-partition/
9 окт 19, 13:33    [21990360]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4987
komrad
AR®
Есть необходимость периодически переливать из таблиц в таблицы данные в общем объёме где-то до 100 млн. записей.

В каком случае это будет работать быстрее:

4. partition switch

https://sqlrus.com/2018/03/using-switch-on-a-single-partition/

точнее 1 или 2 + partition switch
9 окт 19, 13:35    [21990362]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6788
komrad,

они же, наверное, копируют, а не переносят?
9 окт 19, 13:37    [21990370]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
msLex
Member

Откуда:
Сообщений: 6674
komrad
2 + partition switch

и как же свич перенесет данные из одного файла в другой?
9 окт 19, 13:38    [21990372]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4987
Владислав Колосов
komrad,
они же, наверное, копируют, а не переносят?

наверное или нет - автор не указал точно
9 окт 19, 13:52    [21990397]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4987
msLex
komrad
2 + partition switch

и как же свич перенесет данные из одного файла в другой?

да, верно, подразумевается другая ФГ (=другой файл) и тогда не получится switch
9 окт 19, 14:03    [21990419]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
AR®
Member

Откуда: Подмосковье
Сообщений: 326
Копируем, а не переносим. Смысл в том, что к одним и тем же данным нужен доступ с разной нагрузкой и разными правами.
9 окт 19, 16:29    [21990654]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
uaggster
Member

Откуда:
Сообщений: 715
AR®
Есть необходимость периодически переливать из таблиц в таблицы данные в общем объёме где-то до 100 млн. записей.

В каком случае это будет работать быстрее:
1) таблицы источника и назначения в одной базе

Не достаточно информации. Даже одна и та же таблица может быть размещена в нескольких разных файловых группах (например, если она секционирована, или индексы перенесены на быстрые диски в быстрые файловые группы), которые могут размещаться в разных файлах (а файлы - соответственно на разных дисках, разных контроллерах и т.д.)
AR®
2) таблицы источника и назначения в одной базе, но разнесены в разные файлы

Не в файлы, а файловые группы, в которые входят файлы (и не обязательно 1), которые см. выше.
AR®
3) таблицы источника и назначения в разных соседних базах

Во всех случаях подразумевается, что всё происходит на одном и том же сервере.

См. предыдущие пункты.

При этом еще не стоит забывать и о быстродействии диска, на котором расположен(ы) файл(ы) лога, т.к. быстродействие вставки, особенно если она не минимально протоколируемая - напрямую зависит от количество операций в секунду (iops), который у вас выдает диск, на котором расположены логи.

Примеры:
1. Данные у вас располагаются на NL-SAS дисках, 7200, в RAID 6. Поверх единого виртуального тома контроллера нарезаны логические диски (созданные в виндовс), по которым вы разбросали файлы, содержащие данные и логи.
В таком случае нет никакой разницы, где, конкретно, на логическом диске, будут лежать логи, данные, на какие файловые группы будет поделена база, будут ли логи лежать на том же диске, что и данные или нет.
Быстродействие будет абсолютно одинаково, и определяться скоростью массива и количеством iops виртуального тома, созданного на контроллере.
2. Данные у вас расположены на логическом диске, расположенном на одном виртуальном томе контроллера, логи расположены на другом логическом диске, расположенном на другом виртуальном томе контроллера, либо на другом контроллере.
Это - оптимальный вариант.
Причем чем менее латентный том, на котором лежат логи - тем быстрее вставка, особенно если это конкурентная вставка в несколько потоков (и особенно - "по записи").
В бд, в которую интенсивно пишут (если нужно выбирать) данные нужно размешать на медленных шпиндельных дисках, а логи - на быстрых ssd, а не наоборот!
Потому что быстродействие изменений в базе напрямую зависит от количества операций в секунду, которую могут выдать диски, на которых лежат логи.

Т.е., прежде чем городить огород с файлами и т.д. - посмотрите на физику, которая под ними лежит.
Например, если у вас подо всё - одна дисковая полка, которая размечена "одним листом", в одно виртуальное пространство, RAID6 или RAID60, а поверх нее вы уже создаете какие то тома, или хуже того, ваши диски - это файлы виртуальной машины на этом большом томе - куда вы не двигайте логи, данные и т.д., вместе или раздельно, боком или раком - разницы не будет ровно никакой.
Разница может возникнуть только если вы получите в свое распоряжение физически разные каналы и физически разные тома (для данных, логов, баз источников, баз приемников).

... физика рулит безоговорочно.
9 окт 19, 17:12    [21990697]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29246
AR®
Вы хотите сказать, что затраченное время не будет зависеть от выбранного 1 из 3 предложенных вариантов? Не поверю.
Как может быть по другому?

Вы данные копируете из одних секторов диска в другие. Какая разница при этом, что у вас где то в блокнотике отмечено, что первые сектора относятся к накладным Ивана Ивановича, а вторые - к чёрной кассе Петра Петровича?
"Базы" - это всего лишь метаданные, "отметка в блокнотике". А хранятся данные на диске, и неважно, как именно сектора диска описаны в метаданных.

Разница в скорости может появиться, если нужно расширять файл базы, или если делается копирование с одного диска на другой (то есть "2) таблицы источника и назначения в одной базе, но разнесены в разные файлы", но при этом разные файлы размещены на разных дисках).
В общем, если отличаются существенные условия.
9 окт 19, 17:41    [21990731]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Yasha123
Member

Откуда:
Сообщений: 1553
alexeyvg
Как может быть по другому?

например, базы могут быть в разных моделях восстановления
9 окт 19, 17:51    [21990739]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29246
Владислав Колосов
На хороших серверных хранилищах это что в бок, что сверху. Но на бюджетных разница может быть.
Как это, разве разница не одинаковая, не зависящая от стоимости?
9 окт 19, 17:52    [21990742]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
AR®
Member

Откуда: Подмосковье
Сообщений: 326
Спасибо всем откликнувшимся, но мне показалось, что никто не учёл, что это будет не копирование файлов средствами ОС, а именно переливка данных между таблицами командами T-SQL insert/select.
9 окт 19, 17:54    [21990743]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29246
Yasha123
alexeyvg
Как может быть по другому?

например, базы могут быть в разных моделях восстановления
Да, есть такое, упустил. :-)

Но вообще нужно предполагать, что все остальные условия одинаковые.
А то так можно дойти до того, что в одной базе таблица-куча без индексов, а в другой с ПК на 10 полей, и с 50 индексами.
9 окт 19, 17:54    [21990744]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29246
AR®
Спасибо всем откликнувшимся, но мне показалось, что никто не учёл, что это будет не копирование файлов средствами ОС, а именно переливка данных между таблицами командами T-SQL insert/select.
Учли-учли.
9 окт 19, 17:55    [21990745]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Yasha123
Member

Откуда:
Сообщений: 1553
AR®
Спасибо всем откликнувшимся, но мне показалось, что никто не учёл, что это будет не копирование файлов средствами ОС, а именно переливка данных между таблицами командами T-SQL insert/select.

как раз и учли.
если бы копировалось средствами ОС,
разница была бы, писать на медленный диск или на быстрый
(если базы на разных дисках)
но т.к. копирует именно сервер, то он тупо поднимает ваши данные с диска
и в памяти же пишет на страницы (той или иной) базы.
а в памяти пофиг, чьи это страницы.
а сбросит он эти страницы на диск уже потом, и тоже пофиг, когда.
о коммите вы получите известие, когда в лог все запишется.
и вот тут и есть разница, в какой модели была база-приемник
9 окт 19, 18:01    [21990749]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6788
alexeyvg
Владислав Колосов
На хороших серверных хранилищах это что в бок, что сверху. Но на бюджетных разница может быть.
Как это, разве разница не одинаковая, не зависящая от стоимости?


Например, если сравнивать SAS и простое SATA решение.
9 окт 19, 18:23    [21990757]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
uaggster
Member

Откуда:
Сообщений: 715
Yasha123
alexeyvg
Как может быть по другому?

например, базы могут быть в разных моделях восстановления

А какая разница?
Симпл или фулл, транзакция всё равно вначале полностью будет отмечена в логе, а лог только потом будет усечен. Можно выиграть только на авторасширении файла, и то только если бэкап лога не делается вовремя.
А минимально протоколируемые операции - минимально протоколируются что в полной модели, что в простой.
9 окт 19, 19:43    [21990800]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
msLex
Member

Откуда:
Сообщений: 6674
uaggster
А минимально протоколируемые операции - минимально протоколируются что в полной модели, что в простой.

нет
9 окт 19, 19:46    [21990805]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Yasha123
Member

Откуда:
Сообщений: 1553
uaggster
А минимально протоколируемые операции - минимально протоколируются что в полной модели, что в простой.

очень интересное представление о полной модели,
этакая "не совсем полная модель"
9 окт 19, 20:21    [21990834]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29246
Владислав Колосов
alexeyvg
пропущено...
Как это, разве разница не одинаковая, не зависящая от стоимости?

Например, если сравнивать SAS и простое SATA решение.
В смысле, если у вас SAS диск, то разнесение источника и приёмника на разные шпиндели не повлияет на скорость?
9 окт 19, 21:13    [21990856]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6788
alexeyvg,

Я понял. Во втором случае даже при разнесении ситуация будет хуже, т.к. SATA плохо справляется с одновременной обработкой обращений к хранилищу. Разве что удастся изолировать как-то поток данных. Хотя сомнительно, т.к. сервер будет не только писать, но и читать на получателе. SAS интерфейс, емнип, обладает пропускной способностью, намного превышающей возможности дисков.
Но я полностью не уверен. Просто мнение :)
10 окт 19, 11:33    [21991125]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
Glebanski
Member

Откуда: Msk ->NL
Сообщений: 294
Возможно позже стоит подумать о смене концепции "big bang copy 100500K rows" На более хайповую репликацию в фоновом режиме. Помониторьте сервер, может у вас ещё полно ресурсов для подобного процесса.
10 окт 19, 21:18    [21991720]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
982183
Member

Откуда: VL
Сообщений: 3122
AR®
Есть необходимость периодически переливать из таблиц в таблицы данные в общем объёме где-то до 100 млн. записей.
В каком случае это будет работать быстрее:
1) таблицы источника и назначения в одной базе
2) таблицы источника и назначения в одной базе, но разнесены в разные файлы
3) таблицы источника и назначения в разных соседних базах
Во всех случаях подразумевается, что всё происходит на одном и том же сервере.


Практика 10-15-и летней давности говорила о том, что скорость сильно возрастает,
если источник и приёмник находятся на отдельных физических носителях (в разных базах).
(были базы до 500Gb)
Но с того времени много чего поменялось в железе.
Надо экспериментировать - Попробуйте - поделитесь результатами.
12 окт 19, 07:10    [21992647]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
982183
Member

Откуда: VL
Сообщений: 3122
Другое дело, что делать что-то в одной базе с эталонной таблицей я бы не стал...
12 окт 19, 07:56    [21992649]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
AR®
Member

Откуда: Подмосковье
Сообщений: 326
Я тоже склонился к двум разным базам, хотя и, скорее, по административно-правовым причинам. :)
вчера, 15:10    [21993809]     Ответить | Цитировать Сообщить модератору
 Re: Как будет работать быстрее?  [new]
982183
Member

Откуда: VL
Сообщений: 3122
Две базы на двух разных физических носителях на одном сервере.
вчера, 15:19    [21993824]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Microsoft SQL Server Ответить