Добрый день, вопрос скорее дискуссионный
Есть у нас есть некое подобие СУБД по сути набор B+-деревьев, хешей и пр, к которым идет обращение по сети и тоже давно обратили внимание, что при высокой нагрузке большую часть времени транзакции чего то ждут. И стали анализировать что именно они ждут то выяснилось, что основной затык был естественно диск, транзакция на изменения данных лочит высокоуровневые объекты которые она меняет (таблицы, поля) , потом происходит работа с диском и что читается, что то пишется, может повести конечно и все окажется в кэше, но для обеспечения ACID все ровно приходиться в конечном итоге работать с диском в рамках выполнения транзакции. Решили диск "проэмулировтаь" неким абстрактным устройством с быстрым чтением и записью данных (ну по сути просто заменили диск 10ГБ оперативной памяти). Ожидаемо, что "чудо" произошло скорость увеличилась, может даже на два порядка и уже время которое тратилось на межпоточное взаимодействие, в общем, состояло из механизм многопоточного доступа к “диску” (поскольку в конечном итоге БД это несколько файлов , лог транзакций, файл БД и т.д.) и каким то другим ресурсам (как аллокатор например) но уже было не так критично. И ради эксперимента сделали однопоточный последовательный режим работы транзакций и при высокой загрузки общая скорость в целом получилась как минимум не медленнее чем при многопоточном режиме.
Однозначно у нас не самая оптимальная реализация и использование велосипеда имеет свои исторические причины, но недавно смотрел выступление Константина Осипова (главный в разработчик проекте NoSQL Tarantol)
он приводит ссылку на исследование чем в основном занимаются СУБД под нагрузкой, и получается такая картина
что большее время СУБД при выполнении транзакций ждет другие транзакции, и они в Tarantol-e отказались от многопоточности при выполнении транзакций, транзакции выполняются последовательно. И стало интересно, как обстоят дела в серьезных СУБД и возможно были подобные публикации про параллельное выполнение транзакций и сколько времени транзакция находиться в режиме ожидания.
Исходя из моего опыта люди просто стараются избегать всяческих центральных блокировок. Если таблицы друг с другом не соотносятся, они прекрасно работают параллельно. Также надо учитывать, что современные SSD максимальную скорость набирают именно при параллельной работе многих потоков, если вы будете работать с диском в 1 поток, вы сильно потеряете в производительности. Это если вам нужен диск, конечно.
Здравствуйте, SL, Вы писали:
SL>Добрый день, вопрос скорее дискуссионный SL>Есть у нас есть некое подобие СУБД по сути набор B+-деревьев, хешей и пр, к которым идет обращение по сети и тоже давно обратили внимание, что при высокой нагрузке большую часть времени транзакции чего то ждут. И стали анализировать что именно они ждут то выяснилось, что основной затык был естественно диск, транзакция на изменения данных лочит высокоуровневые объекты которые она меняет (таблицы, поля) , потом происходит работа с диском и что читается, что то пишется, может повести конечно и все окажется в кэше, но для обеспечения ACID все ровно приходиться в конечном итоге работать с диском в рамках выполнения транзакции. Решили диск "проэмулировтаь" неким абстрактным устройством с быстрым чтением и записью данных (ну по сути просто заменили диск 10ГБ оперативной памяти). Ожидаемо, что "чудо" произошло скорость увеличилась, может даже на два порядка и уже время которое тратилось на межпоточное взаимодействие, в общем, состояло из механизм многопоточного доступа к “диску” (поскольку в конечном итоге БД это несколько файлов , лог транзакций, файл БД и т.д.) и каким то другим ресурсам (как аллокатор например) но уже было не так критично. И ради эксперимента сделали однопоточный последовательный режим работы транзакций и при высокой загрузки общая скорость в целом получилась как минимум не медленнее чем при многопоточном режиме. SL>Однозначно у нас не самая оптимальная реализация и использование велосипеда имеет свои исторические причины, но недавно смотрел выступление Константина Осипова (главный в разработчик проекте NoSQL Tarantol)
SL>https://www.youtube.com/watch?v=yrTF3qH8ey8
SL>он приводит ссылку на исследование чем в основном занимаются СУБД под нагрузкой, и получается такая картина SL>Image: RDMS_Profile.jpg
SL> что большее время СУБД при выполнении транзакций ждет другие транзакции, и они в Tarantol-e отказались от многопоточности при выполнении транзакций, транзакции выполняются последовательно. И стало интересно, как обстоят дела в серьезных СУБД и возможно были подобные публикации про параллельное выполнение транзакций и сколько времени транзакция находиться в режиме ожидания.
Принципе нет ни какой разницы почему транзакция выполнилась медленнее: то ли от того, что она ожидала своей очереди, то ли от того, что в месте с ней параллельно выполнялась другая транзакция.Однако, некоторые транзакции могут выполняться быстрее именно в многопоточном режиме, например если считываются данные из разных таблиц. Короче всё это лучше проверять на практике.
Здравствуйте, Qulac, Вы писали:
Q>Принципе нет ни какой разницы почему транзакция выполнилась медленнее: то ли от того, что она ожидала своей очереди, то ли от того, что в месте с ней параллельно выполнялась другая транзакция.Однако, некоторые транзакции могут выполняться быстрее именно в многопоточном режиме, например если считываются данные из разных таблиц. Короче всё это лучше проверять на практике.
Если таблицы лежат в одном файле то чтение запись данных даже для разных таблиц упирается в один файл с необходимостью синхронизации доступа для разных транзакций в разных потоках, с одной стороны да нет блокировки на "высокоуровневых" объектах типа тех же таблиц, но I/O все еще остается узким местом и при высокой нагрузке транзакции из разных потоков для разных таблиц большую часть своей жизни борются за доступ к диску (в нашем случае), наверное можно переложить проблему на операционную систему если использовать разные файлы для таблиц, индексов может даже отдельных полей и пр, но подозреваю, что на HDD выигрыш будет не большой.
Здравствуйте, SL, Вы писали:
SL>Здравствуйте, Qulac, Вы писали:
Q>>Принципе нет ни какой разницы почему транзакция выполнилась медленнее: то ли от того, что она ожидала своей очереди, то ли от того, что в месте с ней параллельно выполнялась другая транзакция.Однако, некоторые транзакции могут выполняться быстрее именно в многопоточном режиме, например если считываются данные из разных таблиц. Короче всё это лучше проверять на практике.
SL>Если таблицы лежат в одном файле то чтение запись данных даже для разных таблиц упирается в один файл с необходимостью синхронизации доступа для разных транзакций в разных потоках, с одной стороны да нет блокировки на "высокоуровневых" объектах типа тех же таблиц, но I/O все еще остается узким местом и при высокой нагрузке транзакции из разных потоков для разных таблиц большую часть своей жизни борются за доступ к диску (в нашем случае), наверное можно переложить проблему на операционную систему если использовать разные файлы для таблиц, индексов может даже отдельных полей и пр, но подозреваю, что на HDD выигрыш будет не большой.
Система может еще кешировать данные с диска, именно поэтому я написал, что могут выполнятся быстрее. Всё это зависит от конкретной суб и сравнение лучше производить практически. А вообще последовательный доступ не всегда допустим, например если у нас есть долго выполняющиеся транзакции, тогда другим транзакциям придется долго ждать их завершения и было бы лучше их запустить параллельно
SL>Если таблицы лежат в одном файле то чтение запись данных даже для разных таблиц упирается в один файл с необходимостью синхронизации доступа для разных транзакций в разных потоках, с одной стороны да нет блокировки на "высокоуровневых" объектах типа тех же таблиц, но I/O все еще остается узким местом и при высокой нагрузке транзакции из разных потоков для разных таблиц большую часть своей жизни борются за доступ к диску (в нашем случае), наверное можно переложить проблему на операционную систему если использовать разные файлы для таблиц, индексов может даже отдельных полей и пр, но подозреваю, что на HDD выигрыш будет не большой.
нормальная субд кеширует таблицы в буферный пул и вся "писанина" происходит в памяти. по комиту пишется только дельты в транзакшен лог. лог хрень последовательная и ничего не ждет, просто последовательно пишет. как только в лог записалось — все, транзакция закомичена. в сами таблицы данные будут записаны когда нибудь потом. если субд упала до зщаписи, то при старте произойдет креш рекавери и в таблицы все что нужно будет записано из лога тразакций.
Здравствуйте, SL, Вы писали:
SL> что большее время СУБД при выполнении транзакций ждет другие транзакции, и они в Tarantol-e отказались от многопоточности при выполнении транзакций, транзакции выполняются последовательно. И стало интересно, как обстоят дела в серьезных СУБД и возможно были подобные публикации про параллельное выполнение транзакций и сколько времени транзакция находиться в режиме ожидания.
Во всех серьезных СУБД (я сейчас только про реляционные) грамотная система блокировок — одна из основных составляющих и конкурентное преимущество.
Если говорить о проблеме ожидания в целом, то упрощенно это выглядит так. Если параллельные транзакции меняют одни и те же данные, то они должны ждать друг друга, без вариантов, чтобы обеспечить ACID. Их можно смело сериализовать, это снизит накладные расходы. Если они меняют разные данные (хотя бы отчасти), то есть смысл выполнять их параллельно. При грамотном дизайне базы и блокировок выигрыш превысит накладные расходы. Если же они меняют разные данные, но при этом блокируют одни и те же объекты (высокоуровневые или низкоуровневые — без разницы), то это говорит о плохом дизайне базы либо системы блокировок.
При этом узким местом не всегда является ввод-вывод. Это могут быть какие-то внутренние структуры в памяти или высокоуровневые объекты БД.
Здравствуйте, SL, Вы писали: SL>Если таблицы лежат в одном файле то чтение запись данных даже для разных таблиц упирается в один файл с необходимостью синхронизации доступа для разных транзакций в разных потоках,
Нет. С точки зрения диска, никаких файлов нет. Взрослые СУБД не используют транзакционные механизмы и кэширование из нижележащей ОС, потому что лучше неё знают, что и как надо делать. SL>с одной стороны да нет блокировки на "высокоуровневых" объектах типа тех же таблиц, но I/O все еще остается узким местом и при высокой нагрузке транзакции из разных потоков для разных таблиц большую часть своей жизни борются за доступ к диску (в нашем случае), наверное можно переложить проблему на операционную систему если использовать разные файлы для таблиц, индексов может даже отдельных полей и пр, но подозреваю, что на HDD выигрыш будет не большой.
Единственное, чем потенциально могут помочь раздельные файлы — это разнесение их на разные физические устройства, чтобы по честному параллелить запись.
Нужно понимать, что I/O нагрузка — это запись блоков. Если надо записать 10 блоков, то это 10 операций ввода-вывода. Неважно, в одном файле эти блоки или нет. Да, при прочих равных запись близких блоков в "удобном" порядке быстрее, чем запись блоков, разбросанных по диску. Ровно потому, что файловая система и логика дисковых контроллеров оптимизирована под сценарий линейной записи.
Разработчики промышленных СУБД об этом в курсе, поэтому
а) страницы данных и индексов внутри файла данных расположены так, чтобы в типичных операциях затрагивались "близкие" блоки.
б) основной bottleneck — это коммит транзакции. При нём флашится только лог, а он пишется последовательно. Даже если транзакция трогает много-много данных, разбросанных по всей базе, в рамках коммита пишется группа линейно расположенных блоков.
в) сами данные сбрасываются на диск lazy writer-ом, который упорядочивает операции записи по номерам блоков, а не по порядку их поступления из транзакций. Таким образом, он старается держаться как можно ближе к линейной записи.
г) чтение — менее важно в обшем случае, т.к. его можно сильно улучшить кэшированием. Тем не менее, операции чтения тоже упорядочиваются так, чтобы как можно меньше дёргать головкой диска. Предиктивное чтение хорошо дополняет толковое расположение страниц индексов и данных, которое было упомянуто в п.а).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Нет. С точки зрения диска, никаких файлов нет. Взрослые СУБД не используют транзакционные механизмы и кэширование из нижележащей ОС, потому что лучше неё знают, что и как надо делать.
Взрослые не совсем удачный термин, ибо sqlite вполне себе взрослая бд. Лучше сказать типа промышеленная серверная бд или как-то так.
Здравствуйте, Alex.Che, Вы писали:
AC>23.10.2017 16:06, Sharov пишет: >> зрослая -- это скажем так, проверенная временем промышленная бд. sqlite как раз из таких.
AC>осталось только сформулировать критерии "промышленной БД".
Десяток лет в эксплуатации. Сотни, тысячи и т.д. пользователей.
Здравствуйте, Sinclair, Вы писали:
S>Взрослые СУБД не используют транзакционные механизмы и кэширование из нижележащей ОС, потому что лучше неё знают, что и как надо делать.
А постгря взрослая?
fsync (boolean)
If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods (see wal_sync_method). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали: Ops>А постгря взрослая? Ops>
Ops>fsync (boolean)
Ops> If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods (see wal_sync_method). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash.
Ну, для линейной записи-то можно и так.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
нет. там как раз двойная буферизация, отсутсвует многоблочное чтение, нет параллельного чтения и прочая, прочая. до взрослой там еще нужно потрудиться.
