Сообщение Re[3]: Многопоточность в базах данных от 19.10.2017 12:54
Изменено 19.10.2017 12:56 Gt_
Re[3]: Многопоточность в базах данных
Здравствуйте, SL, Вы писали:
SL>Здравствуйте, Qulac, Вы писали:
Q>>Принципе нет ни какой разницы почему транзакция выполнилась медленнее: то ли от того, что она ожидала своей очереди, то ли от того, что в месте с ней параллельно выполнялась другая транзакция.Однако, некоторые транзакции могут выполняться быстрее именно в многопоточном режиме, например если считываются данные из разных таблиц. Короче всё это лучше проверять на практике.
SL>Если таблицы лежат в одном файле то чтение запись данных даже для разных таблиц упирается в один файл с необходимостью синхронизации доступа для разных транзакций в разных потоках, с одной стороны да нет блокировки на "высокоуровневых" объектах типа тех же таблиц, но I/O все еще остается узким местом и при высокой нагрузке транзакции из разных потоков для разных таблиц большую часть своей жизни борются за доступ к диску (в нашем случае), наверное можно переложить проблему на операционную систему если использовать разные файлы для таблиц, индексов может даже отдельных полей и пр, но подозреваю, что на HDD выигрыш будет не большой.
SL>Здравствуйте, Qulac, Вы писали:
Q>>Принципе нет ни какой разницы почему транзакция выполнилась медленнее: то ли от того, что она ожидала своей очереди, то ли от того, что в месте с ней параллельно выполнялась другая транзакция.Однако, некоторые транзакции могут выполняться быстрее именно в многопоточном режиме, например если считываются данные из разных таблиц. Короче всё это лучше проверять на практике.
SL>Если таблицы лежат в одном файле то чтение запись данных даже для разных таблиц упирается в один файл с необходимостью синхронизации доступа для разных транзакций в разных потоках, с одной стороны да нет блокировки на "высокоуровневых" объектах типа тех же таблиц, но I/O все еще остается узким местом и при высокой нагрузке транзакции из разных потоков для разных таблиц большую часть своей жизни борются за доступ к диску (в нашем случае), наверное можно переложить проблему на операционную систему если использовать разные файлы для таблиц, индексов может даже отдельных полей и пр, но подозреваю, что на HDD выигрыш будет не большой.
Re[3]: Многопоточность в базах данных
SL>Если таблицы лежат в одном файле то чтение запись данных даже для разных таблиц упирается в один файл с необходимостью синхронизации доступа для разных транзакций в разных потоках, с одной стороны да нет блокировки на "высокоуровневых" объектах типа тех же таблиц, но I/O все еще остается узким местом и при высокой нагрузке транзакции из разных потоков для разных таблиц большую часть своей жизни борются за доступ к диску (в нашем случае), наверное можно переложить проблему на операционную систему если использовать разные файлы для таблиц, индексов может даже отдельных полей и пр, но подозреваю, что на HDD выигрыш будет не большой.
нормальная субд кеширует таблицы в буферный пул и вся "писанина" происходит в памяти. по комиту пишется только дельты в транзакшен лог. лог хрень последовательная и ничего не ждет, просто последовательно пишет. как только в лог записалось — все, транзакция закомичена. в сами таблицы данные будут записаны когда нибудь потом. если субд упала до зщаписи, то при старте произойдет креш рекавери и в таблицы все что нужно будет записано из лога тразакций.
нормальная субд кеширует таблицы в буферный пул и вся "писанина" происходит в памяти. по комиту пишется только дельты в транзакшен лог. лог хрень последовательная и ничего не ждет, просто последовательно пишет. как только в лог записалось — все, транзакция закомичена. в сами таблицы данные будут записаны когда нибудь потом. если субд упала до зщаписи, то при старте произойдет креш рекавери и в таблицы все что нужно будет записано из лога тразакций.