Об эффективности однопоточных и многопоточных баз данных

H2 - это однопоточная база данных с хорошей репутацией в отношении производительности. Другие базы данных многопоточные.

Мой вопрос: когда многопоточная база данных становится более интересной, чем одна база данных потоков? Сколько пользователей? Сколько процессов? Что такое триггер? У кого-нибудь есть опыт для обмена?

Резюме

  • Обычным узким местом является доступ к диску.
  • SSD являются быстрыми, но хрупкими (процедура сбоя является обязательной)
  • Один длинный запрос в одной системе потоков будет блокировать все остальные
  • Настройка многопоточной системы может быть сложной
  • Многопоточные базы данных полезны даже для одноядерных систем.
52 голоса | спросил Jérôme Verstrynge 24 Mayam11 2011, 05:09:51

6 ответов


29

Вот мое мнение:

Обычно узким местом (или самой медленной частью) системы БД является диск. ЦПУ только всплескивает во время арифметических операций, обработки или любой другой задачи, выполняемой ЦП. Благодаря надлежащей архитектуре многопоточность может помочь компенсировать нагрузку запроса на процессор вместо того, чтобы делать медленные чтения /записи на диске. Бывают случаи, когда быстрее вычислять значение с использованием циклов ЦП, а не создавать вычисленный столбец (который ранее был сохранен на диск) и читать этот столбец с диска.

В некоторых СУБД существует временная БД (tempdb), которая используется всеми БД в этом экземпляре для сортировки, хэширования, временных переменных и т. д. Многопоточность и разделение этих файлов tempdb можно использовать для повышения пропускной способности от tempdb, тем самым улучшая общую производительность сервера.

Используя многопоточность (параллелизм), набор результатов запроса можно разделить на обработку на разных ядрах сервера, вместо того, чтобы использовать только одно ядро. Эта функция не всегда повышает производительность, но есть случаи, когда она работает, и, следовательно, функция доступна.

Потоки, доступные для БД, используются для многих целей: чтение /запись на диск, пользовательские подключения, фоновые задания, блокировка /фиксация, сетевое IO и т. д. В зависимости от архитектуры ОС потоки предварительно передаются в CPU и управляются с помощью ожиданий и очередей. Если процессор может быстро сократить эти потоки, время ожидания будет низким. Многопоточная БД будет быстрее, чем однопоточная БД, так как в однопоточном БД будут накладные расходы на переработку только одного потока, а не на наличие других протекторов.

Масштабируемость также становится проблемой, так как потребуется больше потоков для управления и выполнения масштабированной системы БД.

ответил StanleyJohns 26 Maypm11 2011, 19:41:23
41

Если есть одна вещь, которую я могу сказать о MySQL, это то, что InnoDB, его транзакционный (ACID-совместимый) механизм хранения, действительно многопоточен. Тем не менее, это так же многопоточно, как и вы КОНФИГУРИРОВАТЬ ЭТО !!! Даже прямо «из коробки», InnoDB отлично справляется с одной средой процессора, учитывая ее настройки по умолчанию. Чтобы использовать возможности многопоточности InnoDB, вы должны помнить, что активируете множество опций.

innodb_thread_concurrency устанавливает верхнюю границу на количество одновременных потоков, которые InnoDB может держать открытым. Наилучший круглый номер для установки (2 X Количество процессоров) + Количество дисков. ОБНОВЛЕНИЕ . Поскольку я узнал из первых рук на конференции Percona NYC, вы должны установить это значение 0, чтобы предупредить InnoDB Storage Engine, чтобы найти наилучшее количество потоков для среды, в которой он работает.

innodb_concurrency_tickets устанавливает количество потоков которые могут безнаказанно обойти проверку параллелизма. После достижения этого предела проверка параллельности потоков снова становится нормой.

innodb_commit_concurrency устанавливает количество одновременных транзакции, которые могут быть совершены. Поскольку значение по умолчанию равно 0, это не позволяет делать любое количество транзакций одновременно.

innodb_thread_sleep_delay устанавливает количество миллисекунд поток InnoDB может быть бездействующим до повторного входа в очередь InnoDB. Значение по умолчанию - 10000 (10 секунд).

innodb_read_io_threads и innodb_write_io_threads (оба с MySQL 5.1.38) выделяют указанное число потоков для чтения и записи. Значение по умолчанию - 4, а максимальное - 64.

innodb_replication_delay накладывает задержку потока на slave - это innodb_thread_concurrency.

innodb_read_ahead_threshold позволяет получать линейные показания установите количество экстентов (64 страницы [page = 16K]) перед переключением на асинхронное чтение.

Время сбежало бы меня, если бы я назвал больше вариантов. Вы можете прочитать о них в документации MySQL .

Большинство людей не знают об этих функциях и вполне удовлетворены тем, что InnoDB просто выполняет транзакции, совместимые с ACID. Если вы подберете любой из этих вариантов, вы сделаете это на свой страх и риск.

Я играл с MySQL 5.5 Multiple Buffer Pool Instances (162 ГБ в 9 экземплярах пулов буферов) и пытался таким образом автоматически дешифровать данные в памяти. Некоторые эксперты говорят, что это должно дать вам 50% улучшение производительности. То, что я получил, было тонкой блокировки потоков, которая фактически сделала сканирование InnoDB. Я переключился на 1 буфер (162 ГБ), и все было хорошо снова в мире. Наверное, вам нужны специалисты Percona, чтобы это установить. Завтра я буду на конференции Percona MySQL в Нью-Йорке и спрошу об этом, если предоставит возможность.

В заключение, InnoDB ведет себя хорошо сейчас на сервере с несколькими процессорами, учитывая его настройки по умолчанию для многопоточных операций. Тонкая настройка их требует большой осторожности, большого терпения, отличной документации и отличного кофе (или Red Bull, Jolt и т. Д.).

Доброе утро, добрый вечер и спокойная ночь!

ОБНОВЛЕНИЕ 2011-05-27 20:11

Вернулся из Percona MySQL Conference в Нью-Йорке в четверг. Какая конференция. Многому научился, но я получил ответ, который я рассмотрю в отношении InnoDB. Я был проинформирован Рональдом Брэдфордом , что установка innodb_thread_concurrency на 0 позволит InnoDB решить наилучший курс действий внутри страны параллелизм потоков. Я буду экспериментировать с этим далее в MySQL 5.5.

ОБНОВЛЕНИЕ 2011-06-01 11:20

Что касается одного длинного запроса, InnoDB ACID-совместимый и работает очень хорошо, используя MultiVersion Concurrency Control . Транзакции должны быть способны нести уровни изоляции (повторяемостьпо умолчанию), что предотвращает доступ других пользователей к данным.

Что касается многоядерных систем, InnoDB прошел долгий путь. В прошлом InnoDB не мог хорошо работать в многоядерной среде. Я помню, что мне приходилось запускать несколько экземпляров mysql на одном сервере, чтобы получить несколько ядер для распределения нескольких процессов mysqld в процессорах. Это больше не нужно, благодаря Percona, а затем и MySQL (ах, Oracle, говоря, что все еще делает меня gag), поскольку они разработали InnoDB в более зрелый механизм хранения, который может легко получить доступ к ядрам без большой настройки. Текущий экземпляр InnoDB сегодня может хорошо работать на одном основном сервере.

ответил RolandoMySQLDBA 26 Mayam11 2011, 07:47:03
10

Как только у вас будет несколько одновременных пользователей или процессов или даже один процесс с многопоточным доступом к базе данных, наличие базы данных, поддерживающей потоки, станет потенциально интересным.

H2 является потокобезопасным, но сериализует все запросы в базу данных, что может стать потенциальной проблемой производительности в сценарии с большой нагрузкой. Независимо от того, действительно ли это относится к конкретному проекту, зависит от сочетания ваших требований к производительности, количества потоков /пользователей /процессов, обращающихся к базе данных, частоты запросов, выполняемых этими потоками, а также средней и наихудшей производительности вашего проекта запросы.

Например, если ваши требования к производительности должны иметь ответ в течение секунды, у вас будет не более 10 одновременных пользователей, выполняющих один запрос, который занимает 0,05 секунды для выполнения, однопоточная база данных все равно позволит вам достичь этих целей (хотя многопоточность, вероятно, уже обеспечит заметное повышение производительности). Учитывая тот же сценарий с одним потенциальным запросом с наихудшей производительностью полсекунды, однако, сериализация доступа к базе данных не позволит вам больше соответствовать вашим целям производительности.

Если вы в настоящее время используете H2 в своем проекте, я бы посоветовал вам запустить профилировщик против вашей кодовой базы в сценарии загрузки (просто запустите x количество потоков, попадающих в ваш код одновременно, используя некоторые типичные usecases). Это даст вам фактические показатели производительности и узких мест в вашей кодовой базе, а не просто теоретизацию. Если это показывает, что ваши запросы тратят большой процент своего времени, просто ожидая доступа к базе данных, пришло время перейти к многопоточной базе данных.

ответил Luke Hutteman 24 Maypm11 2011, 20:55:52
7

Из того, что я могу сказать, «однопоточность» является немного неправильным для H2. Дело в том, что сериализует все транзакции (т. Е. Делает их по одному) ,

Важнейший вопрос о том, является ли это «нормально» или нет для вашего приложения, не «Сколько пользователей?» или даже «Сколько процессов?», но «Как долго мои транзакции будут приняты?»

Если все ваши транзакции являются второстепенными, это может быть хорошо, если некоторые из них занимают несколько часов, это может быть неудобно, поскольку все остальные ожидающие транзакции будут ждать их завершения. Решение о том, является ли это «прекрасным» или нет, будет зависеть от ваших собственных требований к производительности - то есть, сколько времени является приемлемым ожиданием для моих пользователей, ударяющих базу данных с транзакциями.

- EDIT

Кажется, что H2 действительно не сериализует транзакции - просто DML. Другими словами, короткие короткие обновления в рамках одной длинной транзакции не будут блокировать другие обновления . Однако, если вы не используете экспериментальную функцию MVCC , блокировка таблицы означает, что это имеет аналогичную эффект на практике. Существует также экспериментальная функция "multi_threaded" , но она не может использоваться одновременно с MVCC

ответил Jack Douglas 26 Maypm11 2011, 23:17:39
4

Вычисление битов и частей с сайта PostgreSQL ... Обратите внимание, что я абсолютно не знаю о достоинствах этих аргументов - они просто не вписывались в комментарий.

Из FAQ для разработчиков («Почему нити не используются ...»):

http://wiki.postgresql.org/wiki/Developer_FAQ#Why_don.27t_you_use_threads.2C_raw_devices.2C_async-I.2FO.2C_.3Cinsert_your_favorite_wizz-bang_feature_here.3E.3F

  

В настоящее время потоки не используются вместо нескольких процессов для бэкэнд, потому что:   (...)

     
  • Ошибка в одном бэкэнд может повредить другие серверы, если они являются потоками   в рамках одного процесса
  •   
  • Усовершенствования скорости с использованием потоков малы по сравнению с остальными   время запуска бэкэнда.
  •   
  • Обмен доступными только для чтения сопоставлениями и использование shared_buffers   означает, что процессы, такие как потоки, очень эффективны с точки зрения памяти.
  •   
  • Регулярное создание и уничтожение процессов помогает защитить память   фрагментация, которой трудно управлять в длительных процессах.
  •   

Из списка Todo («Функции, которые нам не нужны»):

http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want

  

Все серверы, работающие как потоки в одном процессе (не нужны)

     
    

Это устраняет защиту процесса, которую мы получаем от текущей настройки. Создание потоков, как правило, является одним и тем же накладным расходами, чем создание процессов в современных системах, поэтому представляется неразумным использовать чистую поточную модель, а MySQL и DB2 продемонстрировали, что потоки представляют как можно больше проблем. (...)

  

Итак, опять ... Я совершенно не знаю о достоинствах выше. Это было слишком долго, чтобы вписаться в комментарий.

ответил Denis de Bernardy 28 Maypm11 2011, 19:12:16
-3

Многопоточная база данных принесет вам пользу только в том случае, если в базе данных имеется более одного параллельного запроса. Это зависит от количества пользователей. Если в приложении одновременно работает более десяти пользователей, скорее всего, они будут создавать одновременно несколько запросов в базе данных.

Кроме того, многопоточная база данных может пригодиться только при наличии многоядерного процессора. Если есть одно ядро, многопоточная база данных должна ставить в очередь задание и последовательно выполнять их на одном ядре. Когда есть многоядерные ядра, каждое ядро ​​может параллельно запускать один поток. Таким образом, улучшенная производительность.

Отвечает ли это на ваш запрос?

ответил 24 Maypm11 2011, 20:14:06

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132