Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
AR® Member Откуда: Подмосковье Сообщений: 334 |
Есть необходимость периодически переливать из таблиц в таблицы данные в общем объёме где-то до 100 млн. записей. В каком случае это будет работать быстрее: 1) таблицы источника и назначения в одной базе 2) таблицы источника и назначения в одной базе, но разнесены в разные файлы 3) таблицы источника и назначения в разных соседних базах Во всех случаях подразумевается, что всё происходит на одном и том же сервере. |
9 окт 19, 12:59 [21990316] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37155 |
Вопрос звучит примерно так: "В каком случае будет добраться на автобусе быстрее: 1. Если ехать на заднем сидении 2. Если ехать у окна 3. Если ехать стоя Во всех случаях подразумевается, что всё происходит в одном и том же автобусе." Сообщение было отредактировано: 9 окт 19, 13:03 |
9 окт 19, 13:02 [21990322] Ответить | Цитировать Сообщить модератору |
AR® Member Откуда: Подмосковье Сообщений: 334 |
Не согласен с предложенной Вами аналогией. Вы хотите сказать, что затраченное время не будет зависеть от выбранного 1 из 3 предложенных вариантов? Не поверю. |
9 окт 19, 13:18 [21990340] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8353 |
AR®, чтобы было быстрее - используйте физически разные диски и контроллеры источника и получателя. Проследите, чтобы на получателе были диски без "черепицы". |
9 окт 19, 13:20 [21990341] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37155 |
AR®, Будет зависеть от возможности утилизировать ресурсы, в том числе и дисковые. Если у вас базы все на одном физическом сервере да еще и на одном физическом дисковом массиве, то откуда должен появиться выигрыш? |
9 окт 19, 13:20 [21990342] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8353 |
На самом деле это все БАД и припарки. На хороших серверных хранилищах это что в бок, что сверху. Но на бюджетных разница может быть. |
9 окт 19, 13:21 [21990346] Ответить | Цитировать Сообщить модератору |
AR® Member Откуда: Подмосковье Сообщений: 334 |
Это именно наш случай. |
||
9 окт 19, 13:24 [21990350] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8353 |
AR®, если льется постоянно, то имеет смысл отдать процессорное ядро под IO через Affinity mask. Также, если есть возможность, секционируйте кластерный индекс таблиц и заливайте секции одновременно в несколько потоков. Потоки легко сделать при помощи Integration Services. Разместите секции на разные диски. Понятно, что если источник будет разбит на секции и также размещен на разных дисках, должен быть эффект. |
9 окт 19, 13:32 [21990359] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
4. partition switch https://sqlrus.com/2018/03/using-switch-on-a-single-partition/ |
||
9 окт 19, 13:33 [21990360] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
точнее 1 или 2 + partition switch |
||||
9 окт 19, 13:35 [21990362] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8353 |
komrad, они же, наверное, копируют, а не переносят? |
9 окт 19, 13:37 [21990370] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8730 |
и как же свич перенесет данные из одного файла в другой? |
||
9 окт 19, 13:38 [21990372] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
наверное или нет - автор не указал точно |
||
9 окт 19, 13:52 [21990397] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
да, верно, подразумевается другая ФГ (=другой файл) и тогда не получится switch |
||||
9 окт 19, 14:03 [21990419] Ответить | Цитировать Сообщить модератору |
AR® Member Откуда: Подмосковье Сообщений: 334 |
Копируем, а не переносим. Смысл в том, что к одним и тем же данным нужен доступ с разной нагрузкой и разными правами. |
9 окт 19, 16:29 [21990654] Ответить | Цитировать Сообщить модератору |
uaggster Member Откуда: Сообщений: 960 |
Не достаточно информации. Даже одна и та же таблица может быть размещена в нескольких разных файловых группах (например, если она секционирована, или индексы перенесены
Не в файлы, а файловые группы, в которые входят файлы (и не обязательно 1), которые см. выше.
См. предыдущие пункты. При этом еще не стоит забывать и о быстродействии диска, на котором расположен(ы) файл(ы) лога, т.к. быстродействие вставки, особенно если она не минимально протоколируемая - напрямую зависит от количество операций в секунду (iops), который у вас выдает диск, на котором расположены логи. Примеры: 1. Данные у вас располагаются на NL-SAS дисках, 7200, в RAID 6. Поверх единого виртуального тома контроллера нарезаны логические диски (созданные в виндовс), по которым вы разбросали файлы, содержащие данные и логи. В таком случае нет никакой разницы, где, конкретно, на логическом диске, будут лежать логи, данные, на какие файловые группы будет поделена база, будут ли логи лежать на том же диске, что и данные или нет. Быстродействие будет абсолютно одинаково, и определяться скоростью массива и количеством iops виртуального тома, созданного на контроллере. 2. Данные у вас расположены на логическом диске, расположенном на одном виртуальном томе контроллера, логи расположены на другом логическом диске, расположенном на другом виртуальном томе контроллера, либо на другом контроллере. Это - оптимальный вариант. Причем чем менее латентный том, на котором лежат логи - тем быстрее вставка, особенно если это конкурентная вставка в несколько потоков (и особенно - "по записи"). В бд, в которую интенсивно пишут (если нужно выбирать) данные нужно размешать на медленных шпиндельных дисках, а логи - на быстрых ssd, а не наоборот! Потому что быстродействие изменений в базе напрямую зависит от количества операций в секунду, которую могут выдать диски, на которых лежат логи. Т.е., прежде чем городить огород с файлами и т.д. - посмотрите на физику, которая под ними лежит. Например, если у вас подо всё - одна дисковая полка, которая размечена "одним листом", в одно виртуальное пространство, RAID6 или RAID60, а поверх нее вы уже создаете какие то тома, или хуже того, ваши диски - это файлы виртуальной машины на этом большом томе - куда вы не двигайте логи, данные и т.д., вместе или раздельно, боком или раком - разницы не будет ровно никакой. Разница может возникнуть только если вы получите в свое распоряжение физически разные каналы и физически разные тома (для данных, логов, баз источников, баз приемников). ... физика рулит безоговорочно. |
||||||
9 окт 19, 17:12 [21990697] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
Вы данные копируете из одних секторов диска в другие. Какая разница при этом, что у вас где то в блокнотике отмечено, что первые сектора относятся к накладным Ивана Ивановича, а вторые - к чёрной кассе Петра Петровича? "Базы" - это всего лишь метаданные, "отметка в блокнотике". А хранятся данные на диске, и неважно, как именно сектора диска описаны в метаданных. Разница в скорости может появиться, если нужно расширять файл базы, или если делается копирование с одного диска на другой (то есть "2) таблицы источника и назначения в одной базе, но разнесены в разные файлы", но при этом разные файлы размещены на разных дисках). В общем, если отличаются существенные условия. |
||
9 окт 19, 17:41 [21990731] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1957 |
например, базы могут быть в разных моделях восстановления |
||
9 окт 19, 17:51 [21990739] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
|
||
9 окт 19, 17:52 [21990742] Ответить | Цитировать Сообщить модератору |
AR® Member Откуда: Подмосковье Сообщений: 334 |
Спасибо всем откликнувшимся, но мне показалось, что никто не учёл, что это будет не копирование файлов средствами ОС, а именно переливка данных между таблицами командами T-SQL insert/select. |
9 окт 19, 17:54 [21990743] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
Но вообще нужно предполагать, что все остальные условия одинаковые. А то так можно дойти до того, что в одной базе таблица-куча без индексов, а в другой с ПК на 10 полей, и с 50 индексами. |
||||
9 окт 19, 17:54 [21990744] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
|
||
9 окт 19, 17:55 [21990745] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1957 |
как раз и учли. если бы копировалось средствами ОС, разница была бы, писать на медленный диск или на быстрый (если базы на разных дисках) но т.к. копирует именно сервер, то он тупо поднимает ваши данные с диска и в памяти же пишет на страницы (той или иной) базы. а в памяти пофиг, чьи это страницы. а сбросит он эти страницы на диск уже потом, и тоже пофиг, когда. о коммите вы получите известие, когда в лог все запишется. и вот тут и есть разница, в какой модели была база-приемник |
||
9 окт 19, 18:01 [21990749] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8353 |
Например, если сравнивать SAS и простое SATA решение. |
||||
9 окт 19, 18:23 [21990757] Ответить | Цитировать Сообщить модератору |
uaggster Member Откуда: Сообщений: 960 |
А какая разница? Симпл или фулл, транзакция всё равно вначале полностью будет отмечена в логе, а лог только потом будет усечен. Можно выиграть только на авторасширении файла, и то только если бэкап лога не делается вовремя. А минимально протоколируемые операции - минимально протоколируются что в полной модели, что в простой. |
||||
9 окт 19, 19:43 [21990800] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |