LINUX.ORG.RU

Oracle анонсирует выход версии MySQL 5.5

 ,


0

2

Oracle представила версию MySQL 5.5, самой известной СУБД с открытым исходным кодом, распространяемой на условиях лицензии GPL.

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

Увеличение производительности и масштабируемости:

  • Усовершенствованные сервер баз данных MySQL Server и система управления базой данных InnoDB обеспечивают необходимую производительность и масштабируемость при работе с новейшими многопроцессорными и многоядерными платформами и операционными системами.
  • InnoDB теперь является системой хранения данных для сервера MySQL по умолчанию и предоставляет ACID-транзакции, ссылочную целостность и восстановление после сбоя.
  • Поддержка полусинхронного механизма репликации повышает отказоустойчивость за счет того, что мастер-сервер продолжает работу, не дожидаясь подтверждений от каждого из подчиненных узлов. При получении подтверждения выполнения команды хотя бы от одного подчиненного узла транзакция может быть завершена. Такой подход также помогает сохранить целостность данных.
  • Функция Replication Heart Beat ускоряет обнаружение, диагностику и устранение проблем при синхронизации работ мастер-сервера и подчиненного узла, что позволяет повысить надежность и готовность данных, а также снизить уровень риска.
  • Усовершенствованный механизм секционирования индексов и таблиц позволяет задавать разделы RANGE и LIST по столбцам с типами данных «date», «datetime», «varchar» и «char», что упрощает работу с MySQL, расширяет возможности СУБД, а также повышает гибкость индексации баз данных и настройки запросов.
  • Администраторы и разработчики баз данных могут экономить время: чтобы реализовать механизм обработки ошибок в своих приложениях, внутри хранимых процедур и триггеров, они могут использовать синтаксис инструкций SIGNAL/RESIGNAL, отвечающий стандарту ANSI/ISO.
  • Расширенные средства диагностики, включая новую функцию PERFORMANCE_SCHEMA, обеспечивают низкоуровневую диагностику на основе статистических данных производительности сервера MySQL, позволяя администраторам баз данных идентифицировать ресурсоемкие процессы и события, оптимизировать трудозатраты и повысить их продуктивность.

Существенный рост производительности при тестировании:

  • Для Windows прирост производительности при выполнении операций чтения/записи составил до 1500%, а в режиме «только чтение» – до 500%(1).
  • Для Linux прирост производительности при выполнении операций чтения/записи составил до 360%, а в режиме «только чтение» – до 200%(2).

-------------

(1) Сравнительный тест SysBench MySQL 5.5.6 и MySQL 5.1.50, работают на четырехпроцессорных системах на базе двухъядерных процессоров с архитектурой Intel x86_64; тактовая частота 3,166 ГГц, 8 ГБ оперативной памяти; Windows Server 2008

(2) Сравнительный тест SysBench MySQL 5.5.6 и MySQL 5.1.50, работают на четырехпроцессорных системах на базе шестиядерных процессоров Intel Xeon X7460 с архитектурой Intel x86_64; тактовая частота 2,66 ГГц, 32 ГБ оперативной памяти; Fedora 10

>>> Подробности



Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 3)
Ответ на: комментарий от k0valenk0_igor

> В PostgreSQL реализован (Multiversion Concurrency Control, MVCC) InnoDB is a multi-versioned storage engine: it keeps information about old versions of changed rows, to support transactional features such as concurrency and rollback

http://dev.mysql.com/doc/refman/5.5/en/innodb-multi-versioning.html

И я ничего не путаю: для того что бы избежать «грязного чтения» в мускуле многие руководства рекомендуют блокировать всю таблицу, дабы избежать мертвых блокировок.

Все напутали, что неудивительно. Четыре уровня изоляции транзакций, как по стандарту. http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html

У mysql была и будет своя ниша, даже если кто-то привык делать из любой субд «маленький оракл» со сложной логикой в базе, триггерам и т.д.

netwind
()
Ответ на: комментарий от Korwin

нет. Все верно. Oracle делает vacuum. И для этого даже есть отдельные команды.


ну это вы бредятину несете. в оракле версии строк храняться в отдельной от датафайлов структуре UNDO. когда место в UNDO заканчивается оракл начинает писать в начало этой структуры, тем самым затирая старые версии. поэтому делать vacuum там совершенно бессмыслено. в innodb ровно та же концепция.

2k0valenk0_igor

вы похоже до сих пор так и не поняли, что все трое Oracle, Postgres и mysql/innodb все трое версионники и имеют одинаковые стратегии в плане блокирования. т.е. mysql/inndob тоже не блокирует при чтении.

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


зато я спец и могу показать все алгоритмы сборки статистики в оракле. они все известны. а мусора в оракле с роду не было и собирать физически нечего.

anonymous
()
Ответ на: комментарий от valich

Это они на что намякивают? Win-серверу 8 Гб хватило, а Федорке и 32 только-только?


Намекают на то что масштабирование вверх уместно на платформе linux а винда - ниша low end %)

anonizmus
()
Ответ на: комментарий от netwind

InnoDB is a multi-versioned storage engine: it keeps information about old versions of changed rows, to support transactional features such as concurrency and rollback

http://dev.mysql.com/doc/refman/5.5/en/innodb-multi-versioning.html

Это даже не половина правды. Советую почитать внимательно «Transaction Locking and Scalability»

http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL_2009

Там вы найдете куда более объективный обзор. Вот цитата от туда:

PostgreSQL uses multi-version timestamp ordering (MVTO) while InnoDB and Oracle use multi-version read consistency (MVRC). The main difference is that PostgreSQL is with-REDO/no-UNDO because it stores every row version in the main table, while Oracle/InnoDB implements with-REDO/with-UNDO where they reconstruct a block and/or row image from the log to provide read consistency

Ощущаете разницу? То есть postgre вообще на целостность по чтению не проверяют, ибо нужды нет - он хранит все версии строк. А вот InnoDB «реконструирует блок и/или строку образа из лога для обеспечения целостности по чтению» Так что, строго говоря, Multiversion Concurrency Control в мускуле - фикция.

Четыре уровня изоляции транзакций, как по стандарту

Забавно: postgresql сколько мне помнится заявляет, что обеспечивает первые два. Вы меня крепко заинтересовали, - я проверю. Но, как бы не получилось с предыдущим примером )))

k0valenk0_igor ★★★
()
Ответ на: комментарий от k0valenk0_igor

Ощущаете разницу? То есть postgre вообще на целостность по чтению не проверяют, ибо нужды нет - он хранит все версии строк. А вот InnoDB «реконструирует блок и/или строку образа из лога для обеспечения целостности по чтению» Так что, строго говоря, Multiversion Concurrency Control в мускуле - фикция.



не понимаю в чем смысл нести такую пургу. ну реконструирует оракл, ты теперь оракл объявляешь фиктивным в план MVCC :) ? это просто глупо.
если тебе не понятно, что такое реконструкция блока и когда такое происходит я могу разжувать, хотя в доке оракла и так все расжевано.

anonymous
()
Ответ на: комментарий от valich

> Это они на что намякивают? Win-серверу 8 Гб хватило, а Федорке и 32 только-только?

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

INFOMAN ★★★★★
()
Ответ на: комментарий от impr

Во-первых, н Oracle, а из PR-агенство, во-вторых вас таких тысячи ;-)

Sanitar
()
Ответ на: комментарий от maximnik0

> Они что гестапо там у себя устроили ?Тогда видно почему так много разработчиков с бывшего сана убежало ,они что программистов заставили все переписывать в машинные коды -откуда такие проценты роста - в 15 раз ....

наверно переписали часть кода на Java ... ведь — Ява она же быстрее ассемблера ~__^

mkfifo
()
Ответ на: комментарий от k0valenk0_igor

http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL_2009

Там вы найдете куда более объективный обзор. Вот цитата от туда: Цитата

PostgreSQL uses multi-version timestamp ordering (MVTO) while InnoDB and Oracle use multi-version read consistency (MVRC). The main difference is that PostgreSQL is with-REDO/no-UNDO because it stores every row version in the main table, while Oracle/InnoDB implements with-REDO/with-UNDO where they reconstruct a block and/or row image from the log to provide read consistency

Ощущаете разницу? То есть postgre вообще на целостность по чтению не проверяют, ибо нужды нет - он хранит все версии строк. А вот InnoDB «реконструирует блок и/или строку образа из лога для обеспечения целостности по чтению» Так что, строго говоря, Multiversion Concurrency Control в мускуле - фикция.

похоже вам следует подтянуть английский, вы явно чего-то не того перевели во фразе «they reconstruct a block and/or row image from the log to provide read consistency»

anonymous
()
Ответ на: комментарий от INFOMAN

школота такая

>На то что в венде можно использовать не всю память, которая есть у тебя в системе, а только такое количество, которое разрешено лицензией.

Лицензия сама по себе не ограничивает возможности винды, учи матчасть

anonymous
()
Ответ на: комментарий от k0valenk0_igor

Непонятно как вы из факта использования лога вывели отсутствие MVCC.

Вообще, странный обзор со ссылками на тесты 5.0.20 (!?) Вообще, основная причина развития «субд-многоверсионников», в том чтобы уменьшить необходимость блокировок. Было бы странно, если mysql их делал.

netwind
()
Ответ на: комментарий от anonymous

> там где сейчас постгрес и мсскл воркгруп. innodb при всех косяках имеет более прямую архитектуру. там по сути как в оракле UNDO отделен от данных и циклически затирается. если допилят будет значительно лучше масштабироваться чем постгрес.

да не понятно где прямее, UNDO из лога то далеко не бесплантый, как масштабироватся будет скорее зависит от вида транзакционной нагрузки конкретного приложения, причем чем сложнее тем ближе к постгри, и дальше от innodb.

постгрес версии строк пихает прямо в файлы данных, которые пухнут и которым приходится делать вакум.


там уже давно все не так в лоб, есть новые FSM и visibility maps

ed ★★
()
Ответ на: комментарий от ed

да не понятно где прямее, UNDO из лога то далеко не бесплантый, как масштабироватся будет скорее зависит от вида транзакционной нагрузки конкретного приложения, причем чем сложнее тем ближе к постгри, и дальше от innodb.



не бесплатный но близко к этому. как и на каких нагрузках маcштабируется можно поглядеть на примере оракла и его UNDO, благо нагрузок и проведенных тестов вагон.

там уже давно все не так в лоб, есть новые FSM и visibility maps


урл можно ? а то я наблюдаю 1с, где файлы постгрес пухнут.

anonymous
()
Ответ на: комментарий от anonymous

> а то я наблюдаю 1с, где файлы постгрес пухнут.

На любом языке можно написать кривой код. А уж 1С — типичный пример, как нельзя писать базы. К тому же тупой перенос с блокировщика на версионник и патчами в СУБД, добавляющими эмуляцию поведения этого блокировщика — ещё то уродство.

PS. Ручной вакуум спасае?

baka-kun ★★★★★
()
Ответ на: комментарий от anonymous

> не бесплатный но близко к этому.
ну тогда что там такое дорогое постгри делает ?

как и на каких нагрузках маcштабируется можно поглядеть на примере оракла и его UNDO, благо нагрузок и проведенных тестов вагон.


не корректное сравнение, пока в вылизование постгри не ввалят хотя бы /10 бабла на разработку оркала

урл можно ? а то я наблюдаю 1с, где файлы постгрес пухнут.

pg >= 8.4 ?

http://wiki.postgresql.org/wiki/Image:FSM_and_Visibility_Map.pdf

ed ★★
()
Ответ на: комментарий от HighwayStar

>> а MySQL все еще нужен? есть же не огороженная ораклом MariaDB а про PostgreSql все забыли?

elnair
()
Ответ на: комментарий от mkfifo

Инфа 100%

>>наверно переписали часть кода на Java ... ведь — Ява она же быстрее ассемблера ~__^

Это был PHP

elnair
()
Ответ на: комментарий от baka-kun

На любом языке можно написать кривой код. А уж 1С — типичный пример, как нельзя писать базы. К тому же тупой перенос с блокировщика на версионник и патчами в СУБД, добавляющими эмуляцию поведения этого блокировщика — ещё то уродство.

PS. Ручной вакуум спасае?
----------
кривизна 1с собственно в том что блокируется целая таблица, но это не должно влиять на размер датафайлов.
ручной не пробывал, я туда не суюсь. просто вижу 2.5гб датафайлы и 200мб бэкап с них.

anonymous
()
Ответ на: комментарий от ed

ну тогда что там такое дорогое постгри делает ?


у во первых вакум, который для циклического UNDO не требуется, а во вторых постгресу придется делать лишнее и/о. например в оракле если нужно проделать фулскан таблицы будет читаться только данные таблицы и пару нужных блоков из UNDO, а в посгресе придется фулсканить таблицу+все версии, даже если они не нужны тому кто читает.

не корректное сравнение, пока в вылизование постгри не ввалят хотя бы /10 бабла на разработку оркала


ну с mysql/innodb там вполне паритет, скоро думаю можно будет сравнивать.

http://wiki.postgresql.org/wiki/Image:FSM_and_Visibility_Map.pdf


спасибо, поглядим.

anonymous
()
Ответ на: комментарий от anonymous

> у во первых вакум, который для циклического UNDO не требуется
все постепенно идет к (auto)vacuum (не full) только изменений - это не сильно большой оверхед, тем более отложенный

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


если учесть что постгри например может (не знаю как сейчас) не читать страницы в FSM при seq scan, тогда данные только активных/недавних транзакции будут считаны которые вероятно и так уже где то рядом с его shared buffer cache-ем, то не вижу особых проблем, тем более что UNDO так же еще и проиграть надо (CPU+MEM)

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

ну с mysql/innodb там вполне паритет, скоро думаю можно будет сравнивать.


я не думаю что теперь в mysql когда либо будет хороший оптимизатор запросов, хотя бы потому что на пятки кому не надо может наступить

ed ★★
()
Ответ на: комментарий от ed

если учесть что постгри например может (не знаю как сейчас) не читать страницы в FSM при seq scan


sqe scan выйдет на минимум на порядок медленее последовательного чтения таблицы+версий

данные только активных/недавних транзакции будут считаны которые вероятно и так уже где то рядом с его shared buffer cache-ем


опять же тогда последовательного чтения не получиться

тем более что UNDO так же еще и проиграть надо (CPU+MEM)


там нет проигрывания, только в случае реконструкции, а это событие не слишком частое.

например в подзапросе многократно используемый большой промежуточный результат от UNDO может потребоватся сохранить временно даже на диск


UNDO по любому пишется на диск, а кешеруется в буферном пуле на общих основаниях. т.е. многократно используемые блоки UNDO как раз закрепятся в буферном пуле. это в оракле, хз как там в mysql.

я не думаю что теперь в mysql когда либо будет хороший оптимизатор запросов, хотя бы потому что на пятки кому не надо может наступить


главный враг оракла - mssql. оракл имеет доходы по субд в 2-3 раза больше, а инсталяций раза в 2 меньше. т.е. оракл это большие инсталяции, мсскл небольшие. с помощью mysql он теоритически может выжечь чувствительный кусок майкрософтских доходов. сверху с итаниумом уже рассправился.

но согласен, пилить в mysql/innodb еще годами придется.

anonymous
()
Ответ на: комментарий от ed

> я не думаю что теперь в mysql когда либо будет хороший оптимизатор запросов

О, да. Я и раньше в него не верил, а после покупки Ораклом просто убеждён в этом ;)

Casus ★★★★★
()
Ответ на: комментарий от anonymous

> главный враг оракла - mssql. оракл имеет доходы по субд в 2-3 раза больше, а инсталяций раза в 2 меньше. т.е. оракл это большие инсталяции, мсскл небольшие. с помощью mysql он теоритически может выжечь чувствительный кусок майкрософтских доходов.

Если довести MySQL до состояния, что на нём можно будет запускать 1С, то в России резко упадут продажи MSSQL :) Впрочем, народ научился спасаться с DB2 EE, так что уже процесс пошёл...

Casus ★★★★★
()
Ответ на: комментарий от Casus

> Если довести MySQL до состояния, что на нём можно будет запускать 1С, то в России резко упадут продажи MSSQL :) Впрочем, народ научился спасаться с DB2 EE, так что уже процесс пошёл...

Етервайн же какую-то колбасу для посгрея предлагает, чтобы 1с на нем гонять.

Vit ★★★★★
()
Ответ на: комментарий от anonymous

> кривизна 1с собственно в том что блокируется целая таблица

Кривизна 1С в том, что вообще хоть что-то блокируется вручную.

просто вижу 2.5гб датафайлы и 200мб бэкап с них

Какая-то мизерная база… Тебя смущает отношение в 12.5 раз? А ты видел как и на что строятся индексы в таблицах 1С? Всё ещё удивляешься?

baka-kun ★★★★★
()
Ответ на: комментарий от ed

> я не думаю что теперь в mysql когда либо будет хороший оптимизатор запросов, хотя бы потому что на пятки кому не надо может наступить

Похоже на то. Версия 6.0 похоронена и ее теперь нельзя скачать. Не нам судить почему это произошло, но очень многие оптимизации оптимизатора ожидались именно в 6.0.

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

netwind
()

Товарищи, а кто мне подскажет - будет ли в новом мускуле 5.5 такая вещь как USER STATISTICS? Т.е какой юзер сколько конектов делает, какую нагрузку создает, к какой таблице больше всего обращений ну и тому подобные вещи, которые для мускуля 5.0 реализовал гугль в своих патчах?

Komintern ★★★★★
()
Ответ на: комментарий от anonymous

> seq scan выйдет на минимум на порядок медленее последовательного чтения таблицы+версий

можно тут подробней, похоже мы о каких то разных seq scan говорим

опять же тогда последовательного чтения не получиться


смотря что выгодней в зависимости от размеров таблицы и свободных обласетей, у постгри и сейчас seq-scan хитрый в будещем хуже не будет

там нет проигрывания, только в случае реконструкции, а это событие не слишком частое.


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

UNDO по любому пишется на диск, а кешеруется в буферном пуле на общих основаниях. т.е. многократно используемые блоки UNDO как раз закрепятся в буферном пуле. это в оракле, хз как там в mysql.


я имел в виду затраты на возможную необходимость материализации результатов UNDO, в которой в постгри нет необходимости, кстати эффективное планирование UNDO тоже доп. нагрузка на оптимизатор

с помощью mysql он теоритически может выжечь чувствительный кусок майкрософтских доходов.


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

ed ★★
()
Ответ на: комментарий от ed

можно тут подробней, похоже мы о каких то разных seq scan говорим


это чтение в разнобой, при фулскане оракл применяет последовательное мультиблочное чтение scattered read. т.е. одной и/о операцией выдерается в плоть до 128 блоков разом, под виндой это функция readfilescatter
такое чтение на порядок быстрее считает таблицу чем seq-scan по одному блоку.
постгрес многоблочно еще читать не умеет, но думаю научиться, во всяком случае mysql6 для какого read ahead будет уже readfilescatter применять.

смотря что выгодней в зависимости от размеров таблицы и свободных обласетей, у постгри и сейчас seq-scan хитрый в будещем хуже не будет


в оракле fast full scan индекса врубается если нужно прочитать более 25% например индекса. т.е. все хитрости применяются до 25%, дальше дешевле качать все многоблочно.

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



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

я имел в виду затраты на возможную необходимость материализации результатов UNDO


тут не понял, что и имелось ввиду.

кстати эффективное планирование UNDO тоже доп. нагрузка на оптимизатор


оптимизатор там никаким боком, там все примитивно, раньше просто выставлялось в байтах размер UNDO. вот и все планирование. сейчас в минутах UNDO_RETENTION_TIME, какие-то вычисления наверно делает чтоб выставить в байтах.

после этого они могут получить обострение конкуренции в больших инсталяциях


МС там уже проиграла отказавшись от итаника

anonymous
()
Ответ на: комментарий от anonymous

> такое чтение на порядок быстрее считает таблицу чем seq-scan по одному блоку.

постгри последовательно читает по 8k при seq-scan, seek почти не делает, можно strace-ом посмотреть, а так рекомендую провести эксперемент с dd if=big_file of=/dev/null bs={8k,64k,2048k,...} в линуксе с нормальной fs

scan индекса врубается если нужно прочитать более 25% например индекса. т.е. все хитрости применяются до 25%, дальше дешевле качать все многоблочно.

постгри тоже так умеет и даже synchrnoized scan есть )

все таки стратегия UNDO менее затратна.

далеко не всегда, но похоже мы друг друга не убедим, надеюсь хорошие тесты потом рассудят

тут не понял, что и имелось ввиду.

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

ps
кому интересно статейка в тему
http://it.toolbox.com/blogs/confessions/how-oracle-works-13-rollbackundo-10490



ed ★★
()
Ответ на: комментарий от ed

постгри последовательно читает по 8k при seq-scan, seek почти не делает, можно strace-ом посмотреть, а так рекомендую провести эксперемент с dd if=big_file of=/dev/null bs={8k,64k,2048k,...} в линуксе с нормальной fs



об том и речь. 8к это размер блока (обычно), при seq-scan оракл и вычитывает один блок по 8к за одну и/о операцию, а при многоблочном N блоков по 8к за одну операцию.

постгри тоже так умеет


применять readfilescatter из виндовс апи ? я когда-то сканировал исходники не нашел.

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


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

anonymous
()
Ответ на: комментарий от anonymous

> об том и речь. 8к это размер блока (обычно), при seq-scan оракл и вычитывает один блок по 8к за одну и/о операцию, а при многоблочном N блоков по 8к за одну операцию

я говорю про то что разницы в скорости почти нет, а тем более на порядок - в линуксе adaptive file readahead делает система + fs, поэтому в постгри на такую простую вещь даже еще и не заморочились


применять readfilescatter из виндовс апи ? я когда-то сканировал исходники не нашел.


нет про винду я не говорил, мы же в контексте максимальной производительности и масштабируемости говорим )

вы похоже как-то странно представляете. блок который достанут из UNDO кешируется в буферном пуле


чтоб достать «сложный» блок нужно еще получить ссылку, а в память даже UNDO не влазит т.е. двойное i/o * кол-во использований

ed ★★
()
Ответ на: комментарий от ed

я говорю про то что разницы в скорости почти нет, а тем более на порядок - в линуксе adaptive file readahead делает система + fs, поэтому в постгри на такую простую вещь даже еще и не заморочились



попробуйте в оракле выставить DB_MULTIBLOCK_READ_COUNT=1 и увидите разницу

нет про винду я не говорил, мы же в контексте максимальной производительности и масштабируемости говорим )


ну в линуксе это readv(), просто не столь очевидные параметры. в винде просто было бы легче убедиться, что юзает то о чем я говорю.

anonymous
()
Ответ на: комментарий от ed

чтоб достать «сложный» блок нужно еще получить ссылку, а в память даже UNDO не влазит т.е. двойное i/o * кол-во использований


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

anonymous
()
Ответ на: комментарий от anonymous

> попробуйте в оракле выставить DB_MULTIBLOCK_READ_COUNT=1 и увидите разницу

оркал вероятно просто O_DIRECT на датафайлах использует, тогда не будет read ahead и много чего и именно тогда явный readv скорее критичен, но это не более чем его особенность, они любят собой ос подменять

что такое сложный блок ? еще раз, чтение из таблицы и UNDO совершенно идентичны


а откуда известно где в UNDO нужный блок и что его вообще нужно взять из UNDO ?

ed ★★
()
Ответ на: комментарий от ed

оркал вероятно просто O_DIRECT на датафайлах использует, тогда не будет read ahead и много чего и именно тогда явный readv скорее критичен, но это не более чем его особенность, они любят собой ос подменять


хорошо, допустим оракл не показатель, но полагаться на ФС оси опять же тупиковый путь. если мы забираем всю доступную память под кеш субд мы можем точно сказать, что у нас в кеше 90% блоков таблицы, соответственно оптимизатор может точно рассчитать стоимость фулскана против гуляния по индексам. а если у нас кеш в файловой системе мы понятия не имеем, что там. соответственно и оптимизатор не может принять верное решение.

а откуда известно где в UNDO нужный блок и что его вообще нужно взять из UNDO ?


известно по SCN, ссылка на блок UNDO в заголовке блока прописывается (роллбэку же нужно знать который блок вернуть если транзакция обломается)

anonymous
()
Ответ на: комментарий от anonymous

> но полагаться на ФС оси опять же тупиковый путь. если мы забираем всю доступную память под кеш субд мы можем точно сказать ......

спорный вопрос, подменять собой ос - было актуально в прошлом веке, к тому же полностью на кэш/фс никто не пологается, еще собственые shared buffers есть, сложно сходу сказать - получается что fast-full-scan уже есть и даже fast-index-scan :), но насколько эффективен этот гибрид на самом деле - это скорее вопрос тестов, и не забываем что развитие ядра/fs в будущем будет давать значительно больший бенифит постгри, чем оркалу


известно по SCN, ссылка на блок UNDO в заголовке блока прописывается (роллбэку же нужно знать который блок вернуть если транзакция обломается)


ну вот мы место одного блока, должны два считать - тот где мы найдем ссылку и сам UNDO, причем из разных мест

ed ★★
()
Ответ на: комментарий от ed

>спорный вопрос, подменять собой ос - было актуально в прошлом веке, к тому же полностью на кэш/фс никто не пологается

полагаются. вся тройка лидеров не использует кеш фс, подменяя его своим буферным пулом. как я понял постгрес свой буферный пул скорее для хранения «грязных» блоков держит (пока они не сбросилиь на диск). интересено как в этом плане mysql.

сложно сходу сказать - получается что fast-full-scan уже есть и даже fast-index-scan :),

так без собственного буферного пула не отгадать, что дешевле fast-full-scan или index scan. завит от кол-ва блоков в кеше ...

кстати, почитал про Adaptive Readahead, это не совсем fast-full-scan имхо http://kerneltrap.org/node/6642

ну вот мы место одного блока, должны два считать - тот где мы найдем ссылку и сам UNDO, причем из разных мест

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

anonymous
()
Ответ на: комментарий от anonymous

> полагаются. вся тройка лидеров не использует кеш фс
они это реализовали в прошлом веке ) к тому же наверно на винде и сечас сложно по другому

подменяя его своим буферным пулом. как я понял постгрес свой буферный пул скорее для хранения «грязных» блоков держит (пока они не сбросилиь на диск).


почему вполне себе хитроватый LRU с защитой от промывки большими сканами

так без собственного буферного пула не отгадать, что дешевле fast-full-scan или index scan. завит от кол-ва блоков в кеше ..


при определенных стратегиях использования системный кэш не так уж и не предсказуем, оптимизатор планирует его использование через effective_cache_size, это опция существенно влияет какой будет scan, к тому системный кэш не черный ящик - http://villemain.org/projects/pgfincore , думаю это засунут в оптимизатор рано или поздно

кстати, почитал про Adaptive Readahead, это не совсем fast-full-scan имхо http://kerneltrap.org/node/6642

главное результат, постгри на xfs с on-demand readahead (упрощенный adaptive) делает большой seq-scan близко к скорости блочного устройства

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


ждем тестов )

ed ★★
()
Ответ на: комментарий от ed

они это реализовали в прошлом веке ) к тому же наверно на винде и сечас сложно по другому


нет, они реализовали потому что
1. двойная буферизация теряет время на копирование в кеш ОС, а потом из кеша ОС в субд. DMA в буферный пул просто быстрее, несколько блоков разом быстрее на порядок
2. кеш ОС вымывается фулсканами и с этим ничего не сделать (только мимо кеша читать)
3. кеш ОС лишает оптимизатор важнейшей информации

почему вполне себе хитроватый LRU с защитой от промывки большими сканами


разве нет традиции делать буферный пул PG размером в пару десятков мб, остальное надеятся на кеш ОСи (effective_cache_size)?

делает большой seq-scan близко к скорости блочного устройства


да, но разве блочное устройство применяет scattered read ?


http://www.pgcon.org/2010/schedule/attachments/148_pgfincore_pgcon10.pdf


текста нет, ничего не понять. я не увидел чтоб это дало инфо оптимизатору о содержании кеша ОС и понял что идей по борьбе с вымыванием кеша фулсканами у них нет.

anonymous
()
Ответ на: комментарий от ed

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

ed ★★
()
Ответ на: комментарий от ed

я не потрудился прочесть документацию по тому как документация отсутствует
http://villemain.org/projects/pgfincore

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

в принципе даже если вы расскажет больше об этом модуле врядле это кардинально изменит моего мнения о недостатках полагаться на кеш ФС не заточенного под задачи субд.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.