|
Теоретический вопрос по скорости обработки данных
|
||
|---|---|---|
Участник
Откуда: Melbourne, Австралия
Сообщения: 5 148 |
||
| 18.11.2014, 19:27:50 |
|
|
|
|
|
Теоретический вопрос по скорости обработки данных
|
|||
|---|---|---|---|
|
#18+
Добрый день. Есть много (порядка нескольких сотен) условно-независимых запросов, модифицирующих данные (функции, добавление, удаление, обновление). Все это хозяйство должно идти в одной транзакции. Как я понимаю, лучше для быстродействия все это впихнуть в одну или несколько больших команд и отправить из прикладного софта в СУБД. Или лучше это сделать пакетами по маленьким командам, да еще и в разных потоках? Последовательность выполнения запросов не принципиальная (точнее, можно отделить те ,где нужна последовательность от тех, где не нужна). Все запросы работают с 2-3 мя общими большими (~10-20 млн записей) таблицами. Индексы задействованы. Интерсуют дальнейшие возможности по оптимизации. По моим представлениям разбивка обработки на несколько потоков выигрыша не даст, так как они все будут конкурировать за одну таблицу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 14:53:38 |
|
||
|
Теоретический вопрос по скорости обработки данных
|
|||
|---|---|---|---|
|
#18+
kamakama, объединение нескольких операций в одну транзакцию приводит к ускорению до некоторого предела, за которым расходы на изоляцию начинают расти нелинейно. В большинстве случаев оптимальный размер транзакции легко определить на практике http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=494338&msg=4914268 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 15:31:17 |
|
||
|
Теоретический вопрос по скорости обработки данных
|
|||
|---|---|---|---|
|
#18+
kamakamaони все будут конкурировать за одну таблицу Зависит от того, что вы делаете. Если таблицу никогда не блокируете целиком и не работаете по конкурентным выборкам, то параллельное обновление будет давать ускорение. Например, считаем баланс по заказам и обновляем баланс по клиентам. Если потоки 1,2,3,4 обновляют клиентов с clientID вида xxx0, xxx1, xxx1, xxx3, то никаких блокировок не будет. Если же вы между 4-мя потоками разделите заказы одного клиента, будут блокировки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 15:36:12 |
|
||
|
Теоретический вопрос по скорости обработки данных
|
|||
|---|---|---|---|
|
#18+
tadmin, А размер транзакции в чем? В командах, в суммарной длинне текста команды? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 15:53:20 |
|
||
|
Теоретический вопрос по скорости обработки данных
|
|||
|---|---|---|---|
|
#18+
Сейчас я ограничиваю размер отсылаемой на выполнение команды (не транзакции) в 65 Кб текста. Да, думаю, без детального описания операций не получится. Есть линейная таблица 1 (10-20 млн записей) типа "ключ-значение" с несколькими атрибутами. Сначала сносится содержимое по значению атрибута, потом идет серия оперция вставок в эту таблицу. Есть линейная таблица 2 (20-30 млн записей), где выполняется update по ключу. Есть линейная таблица 3 (20-30 млн записей), где так же все сносится по значению атрибута и серия вставок строк. В принципе, это можно распараллелить, но у меня одноворемнно идет обработка на 10 машинах. Боюсь, что упрусь в производительность дисков. Партицирование, полировка тонкими настройками ПГ - все это будет, но нужно выжать все соки из доступных решений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2014, 15:56:21 |
|
||
|
Теоретический вопрос по скорости обработки данных
|
|||
|---|---|---|---|
|
#18+
kamakamaА размер транзакции в чем? В командах, в суммарной длинне текста команды? Сейчас я ограничиваю размер отсылаемой на выполнение команды (не транзакции) в 65 Кб текста. В количестве обновленных (вставки, обновления, удаления) записей за одну транзакцию. Т.е. если вы вставили, а потом два раза обновили - на счетчике "3" Очень приблизительно, оптимальный размер транзакции - обновление до 5-10 тысяч за транзакцию. kamakamaДа, думаю, без детального описания операций не получится. Ваше описание не позволяет дать какой-то определенный совет. Вам стоит создать тестовые таблицы, наполнить их данными, показать DDL таблиц, запросы и планы исполнения. Когда в планах все будет ОК, можно экспериментировать с числом параллельных потоков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2014, 18:40:02 |
|
||
|
Теоретический вопрос по скорости обработки данных
|
|||
|---|---|---|---|
|
#18+
kamakamaДобрый день. Есть много (порядка нескольких сотен) условно-независимых запросов, модифицирующих данные (функции, добавление, удаление, обновление). Все это хозяйство должно идти в одной транзакции. Как я понимаю, лучше для быстродействия все это впихнуть в одну или несколько больших команд и отправить из прикладного софта в СУБД. Или лучше это сделать пакетами по маленьким командам, да еще и в разных потоках? Последовательность выполнения запросов не принципиальная (точнее, можно отделить те ,где нужна последовательность от тех, где не нужна). Все запросы работают с 2-3 мя общими большими (~10-20 млн записей) таблицами. Индексы задействованы. Интерсуют дальнейшие возможности по оптимизации. По моим представлениям разбивка обработки на несколько потоков выигрыша не даст, так как они все будут конкурировать за одну таблицу транзакции по смыслу раставляются не только и не столько для производительности сколько для обеспечения целостности (все или ничего) на основе этого и стоит размер транзакции определять ну и конечно не стоит делать транзакции на часы (это очень вредно для базы). Пока запросы не начинают менять одни и теже строки в таблицах - паралельное выполнение обычно задачу ускоряет (так как важна не конкуренция за таблицу а конкуренция за конкретные строки). PS: а как вы собираетесь соединить "должно идти в одной транзакции" и "пакетами по маленьким командам, да еще и в разных потоках" ? PPS: перед тем как что то вообще менять надо понять во что процесс упирается. Если в диск - паралельность не поможет. Если в процессор - поможет. И тд. Вариантов много бывает. --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2014, 19:27:50 |
|
||
|
Теоретический вопрос по скорости обработки данных
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, нет, объем транзакций - менее 1000 записей суммарно в среднем, выборок нет, только удаление и обновление по ключу + добавление записей. Время выполнения не более 5-7 секунд. Проблема в том, что однородные транзакции генерируют одновоременно примерно 20 потоков на разных вычислителях. И тут скорость обработки падает фатально. Подозрение на 2 места - или диски и тут ничего особо не сдалешь, или поиграться с настройками конфига (буферы запросов, буферы транзакций, кэш СУБД и т.п.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2014, 17:40:38 |
|
||
|
Теоретический вопрос по скорости обработки данных
|
|||
|---|---|---|---|
|
#18+
kamakamaMaxim Boguk, нет, объем транзакций - менее 1000 записей суммарно в среднем, выборок нет, только удаление и обновление по ключу + добавление записей. Время выполнения не более 5-7 секунд. Проблема в том, что однородные транзакции генерируют одновоременно примерно 20 потоков на разных вычислителях. И тут скорость обработки падает фатально. Подозрение на 2 места - или диски и тут ничего особо не сдалешь, или поиграться с настройками конфига (буферы запросов, буферы транзакций, кэш СУБД и т.п.) тут искать надо не под фонарем а где потеряли... т.е. сначала локализовать в чем проблема а потом уже думать как лечить. --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2014, 19:44:43 |
|
||
|
|
start [/forum/topic.php?fid=53&fpage=119&tid=1998340]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
68ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 200ms |
| total: | 365ms |
| 0 / 0 |
