Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 12 13 [14] 15   вперед  Ctrl
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
sanyock2
Member

Откуда:
Сообщений: 3882
PgSQLAnonymous
Если для выполнения запроса клиента СУБД нужно прочитать 100000 страниц,
и в одном случае на это уходит 2 сек, а в другом 1, то похоже на то,
что во втором случае IOPS вдвое больше (что может быть просто эффектом кэширования). ;)


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

наглядно видно в db2top, есть physical reads и logical reads (из буферов), но writes ТОЛЬКО physical, потому что СУБД ожидает от файловой системы честные sync-и на каждый ее commit, хоть и страхуется через журнал, который желательно иметь в другой файловой системе

конечно, можно выкрутить в ZFS sync-и в disabled, когда она все, что пока еще влазит, пишет только в оперативу, почти с таким же камикадзовским успехом можно использовать обычный RAM drive без сверхнадежного питания под часть базы

кстати временное отключение sync ZFS почему-то мне не дало значительного прироста IOPS, может и потребности от приложения не было, поэтому?
15 май 15, 21:12    [17647519]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
sanyock2
Member

Откуда:
Сообщений: 3882
это все к тому, что IOPS увеличивается за счет количества шпинделей, а не за счет оперативки или сверхновых винтов с огромной скоростью последовательной записи, каждые несколько стареньких винтов в правильном массиве легко уделают каждый один новенький по IOPS
15 май 15, 21:16    [17647525]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
sanyock2
Member

Откуда:
Сообщений: 3882
sanyock2
кстати временное отключение sync ZFS почему-то мне не дало значительного прироста IOPS


вернее прироста количества записываемых записей (или страниц в чем он там считает) в единицу времени по db2top
15 май 15, 21:19    [17647532]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
sanyock2
PgSQLAnonymous
Если для выполнения запроса клиента СУБД нужно прочитать 100000 страниц,
и в одном случае на это уходит 2 сек, а в другом 1, то похоже на то,
что во втором случае IOPS вдвое больше (что может быть просто эффектом кэширования). ;)


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

Строго говоря — нипричём. Но упомянутому клиенту-то какая разница? ;)

sanyock2
кстати временное отключение sync ZFS почему-то мне не дало значительного прироста IOPS, может и потребности от приложения не было, поэтому?

А может быть, потому, что sync реально не выполнялся и до этого? Вы проверяли?

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

А на SSD как считать шпиндели?
15 май 15, 21:36    [17647568]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
sanyock2
Member

Откуда:
Сообщений: 3882
PgSQLAnonymous
sanyock2
кстати временное отключение sync ZFS почему-то мне не дало значительного прироста IOPS, может и потребности от приложения не было, поэтому?

А может быть, потому, что sync реально не выполнялся и до этого? Вы проверяли?

да куда бы он делся то в ZFS
и "zfs get all | grep sync" того же мнения

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

А на SSD как считать шпиндели?


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

в SSD физика другая, IOPS в зависимости от навороченности может быть в сотни и тысячи раз больше винтов
15 май 15, 21:55    [17647610]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Смешались в кучу кони, люди... ((с) Бородино) IOPsы, кэширование, SSD и т.п. в приложении к разным СУБД.
15 май 15, 22:32    [17647744]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov
Да нет проблем: две параллельные транзакции, впавшие в дэдлок, не могут быть закоммичены.
Следовательно, они не могут привести БД в состояние, в которое они привели бы её, если бы
выполнялись последовательно. Следовательно, такие транзакции - не serializable.

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

Т.е. ты опять всё поставил с ног на голову. Уровень изоляции не гарантирует обязательность выполнения (фиксации) транзакций. Он лишь определяет результат (состояние системы) после их фиксации.
15 май 15, 22:49    [17647800]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54849

pkarklin
Уровень изоляции не гарантирует обязательность выполнения (фиксации)
транзакций. Он лишь определяет результат (состояние системы) после их фиксации.

А в чём разница? Если одна из транзакций не смогла зафиксироваться, значит заданный
результат не достигнут и система не соответствует требованиям, предъявляемым к данному уровню.

Короче: параллельное выполнение => операции одной транзакции не выполнились,
последовательное выполнение => выполнились операции обоих транзакций. Разница налицо и,
следовательно, данный уровень не соответствует стандарту на serializable как его описывает
ПГанонимус.

Posted via ActualForum NNTP Server 1.5

15 май 15, 22:58    [17647825]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov,

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


Необходимые и достаточные условия - это фиксирование обеих транзакций. Если этого не произошло - не выполнены исходные требования к системе.
15 май 15, 23:10    [17647857]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54849

pkarklin
Необходимые и достаточные условия - это фиксирование обеих транзакций.

Необходимое - да. Достаточное - нет. Одна транзакция делает update set f=f+3, вторая -
update set f=f+4. Если обе транзакции закоммитились, а в результате поле увеличилось не на
7, то условие для serializable не выполнено.

pkarklin
Если этого не произошло - не выполнены исходные требования к системе.

И таки да, как я уже сказал два раза: раз одна из транзакций не смогла закоммититься,
значит система не выполняет условия для ношения гордого звания "поддерживает TIL
serializable".

Posted via ActualForum NNTP Server 1.5

15 май 15, 23:18    [17647885]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov,

автор
Необходимое - да. Достаточное - нет. Одна транзакция делает update set f=f+3, вторая -
update set f=f+4. Если обе транзакции закоммитились, а в результате поле увеличилось не на
7, то условие для serializable не выполнено.

Нет, Дима, условия не такие...
автор
И таки да, как я уже сказал два раза: раз одна из транзакций не смогла закоммититься,
значит система не выполняет условия для ношения гордого звания "поддерживает TIL
serializable".


Ой, а тынц на стандарт ANSI можно?
15 май 15, 23:59    [17647947]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
sanyock2
Member

Откуда:
Сообщений: 3882
PgSQLAnonymous
sanyock2
кстати временное отключение sync ZFS почему-то мне не дало значительного прироста IOPS, может и потребности от приложения не было, поэтому?

А может быть, потому, что sync реально не выполнялся и до этого? Вы проверяли?


скорее всего потому что ZFS пишет sync-и сначала в ZIL (Intent Log) ПОСЛЕДОВАТЕЛЬНО,
а у HDD при последовательном доступе пропускная способность по IOPS в сотни раз выше, чем при случайном
http://storageioblog.com/part-ii-iops-hdd-hhdd-ssd/
нагрузка в десятки тысяч IOPs у меня очень редко бывает, поэтому наверно и разницы не было при "записи" sync-ов в RAM

только странно то, что ZIL тогда был еще на общих винтах а не на отдельном SLOG device, в пуле ведь еще и случайные чтения точно были, хотя возможно спасал RAM cache для чтения
16 май 15, 10:51    [17648374]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
sanyock2
PgSQLAnonymous
пропущено...

А может быть, потому, что sync реально не выполнялся и до этого? Вы проверяли?

да куда бы он делся то в ZFS
и "zfs get all | grep sync" того же мнения

А Вы джентельменам верите на слово? ;) Не имеет значения, что он там выдаёт. Вы тестировали, что Ваша дисковая система "на всём протяжении" (ФС, драйвер, RAID, диски) действительно делает fsync? Если частота fsync-ов при тестировнании превышает те IOPS-ы, которые у Вас должны быть, то, возможно, у меня для Вас плохие новости. ;)

sanyock2
скорее всего потому что ZFS пишет sync-и сначала в ZIL (Intent Log) ПОСЛЕДОВАТЕЛЬНО,

Подождите, а что это значит? Она гарантирует, что при исчезновении питания все эти fsync-и будут выполнены при его восстановлении?

Вот ссылка в тему: http://brad.livejournal.com/2116715.html
16 май 15, 13:47    [17648772]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
pkarklin
Нет, Дима, условия не такие...

По-моему, ему это всё равно. ;)

pkarklin
Ой, а тынц на стандарт ANSI можно?

Вряд ли он там это найдёт, потому что там написано следующее (подчёркивания мои):

An SQL-transaction is terminated by a <commit statement> or a <rollback statement>.
If an SQL-transaction is terminated by successful execution of a <commit statement>,
then all changes made to SQL-data or schemas by that SQL-transaction are made
persistent and accessible to all concurrent and subsequent SQL-transactions.

If an SQL-transaction is terminated by a <rollback statement> or unsuccessful execution of a <commit statement>,
then all changes made to SQL-data or schemas by that SQL-transaction are canceled.

The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable.

A serializable execution is defined to be an execution of the operations of concurrently executing
SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions.

A serial execution is one in which each SQL-transaction executes to completion before the next SQL-transaction begins.

The execution of a <rollback statement> may be initiated implicitly by an SQL-implementation
when it detects the inability to guarantee the serializability of two or more concurrent SQL-transactions.
When this error occurs, an exception condition is raised: transaction rollback — serialization failure.


Так вот ROLLBACK-и и DEADLOCK-и и есть "implicit rollback".
Вот, кстати, соотвествующие стандарту SQLSTATE-ы PostgreSQL в этих случаях:


Class 40 — Transaction Rollback
40000 transaction_rollback
40002 transaction_integrity_constraint_violation
40001 serialization_failure
40003 statement_completion_unknown
40P01 deadlock_detected
16 май 15, 14:04    [17648829]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54849

PgSQLAnonymous
The execution of concurrent SQL-transactions at isolation level
SERIALIZABLE is guaranteed to be serializable.

PgSQLAnonymous
The execution of a <rollback statement> may be initiated implicitly
by an SQL-implementation when it detects the inability to guarantee the
serializability of two or more concurrent SQL-transactions.
When this error occurs, an exception condition is raised: transaction rollback —
serialization failure.

Ты сам-то видишь противоречие этих двух заявлений? Или слова "уровень изоляции
SERIALIZABLE гарантирует сериализацию" - пустой звук?..

Posted via ActualForum NNTP Server 1.5

16 май 15, 14:13    [17648853]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
sanyock2
Member

Откуда:
Сообщений: 3882
PgSQLAnonymous
sanyock2
пропущено...

да куда бы он делся то в ZFS
и "zfs get all | grep sync" того же мнения

А Вы джентельменам верите на слово? ;) Не имеет значения, что он там выдаёт. Вы тестировали, что Ваша дисковая система "на всём протяжении" (ФС, драйвер, RAID, диски) действительно делает fsync? Если частота fsync-ов при тестировнании превышает те IOPS-ы, которые у Вас должны быть, то, возможно, у меня для Вас плохие новости. ;)


у меня не тестовая лаборатория и я не тестер, чтобы тестировать commodity железки и софтины

разве fsync не возвращает результат: успешно или нет, да и просто может находиться в состоянии ожидания? СУБД может сделать вывод о дальнейших действиях?

кэш записи в контроллере отключен, диски проброшены как JBOD, ZFS - транзакционная файловая система, хорошо переживает hard reset, на старте обрабатывает журнал аналогично СУБД

dstat показывает постоянную ежесекундную активность на запись - коммиты DB2, а не раз в 5 секунд как sync по умолчанию, даже и потеря транзакций за последние 5 секунд не так уже страшна в моем случае
16 май 15, 14:15    [17648866]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
Dimitry Sibiryakov
PgSQLAnonymous
The execution of concurrent SQL-transactions at isolation level
SERIALIZABLE is guaranteed to be serializable.

PgSQLAnonymous
The execution of a <rollback statement> may be initiated implicitly
by an SQL-implementation when it detects the inability to guarantee the
serializability of two or more concurrent SQL-transactions.
When this error occurs, an exception condition is raised: transaction rollback —
serialization failure.

Ты сам-то видишь противоречие этих двух заявлений? Или слова "уровень изоляции
SERIALIZABLE гарантирует сериализацию" - пустой звук?..


Нет, не вижу. И стандарт не видит. И разработчики большинства СУБД (я уже не уверен насчёт InterBase ;)) не видят. Как же так?!

И вообще, как я уже говорил:
PgSQLAnonymous
По-моему, ему это всё равно. ;)
16 май 15, 14:29    [17648902]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54849

PgSQLAnonymous
И разработчики большинства СУБД (я уже не уверен насчёт InterBase ;))
не видят. Как же так?!

А так, что разработчики СУБД под названием "serializable" делают обычный "snapshot".
Поскольку выполнить требование гарантировать сериализуемость не в силах.

Posted via ActualForum NNTP Server 1.5

16 май 15, 15:02    [17648978]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
Dimitry Sibiryakov
Ещё раз: что в данном случае для Вас означает "блокируют"?

Значит запрет на совершение определенного действия.
Бывают блокировки на чтение,изменение,создание новых элементов, и т.д.
Т.е. в случае версионника - может быть блокировка на создание новой версии, чтение промежуточного результата незафиксированной транзакции и т.д.
18 май 15, 12:48    [17654903]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
Dimitry Sibiryakov
Поскольку выполнить требование гарантировать сериализуемость не в силах.

Да хватит уже спорить о том, что реальный мир отличается от идеального.
Да в общем случае не всегда возможно найти ту последовательность действий, которая эквивалентна одновременному выполнению этих действий.
Все что в этом случае может сделать реальная система - сказать: "упс! не могу". Как и в случае если у нее вдруг пропал доступ к подсистеме хранения, и по другим причинам.
Но мы все понимаем, что реально последовательные системы доступа к данным можно сделать из любой БД с мало мальскими блокировками - только это нафиг никому не сдалось.
18 май 15, 13:06    [17655034]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30290
Сергей Арсеньев
блокировка ... чтение промежуточного результата незафиксированной транзакции и т.д.

нету у версионника такой блокировки. иначе нафиг он нужен.
20 май 15, 10:40    [17665270]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
kdv,

Как бы пользуются люди Oracle, несмотря на то, что в нем очень затруднен режим dirty read.
20 май 15, 13:37    [17666295]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30290
Сергей Арсеньев
Как бы пользуются люди Oracle, несмотря на то, что в нем очень затруднен режим dirty read.

в InterBase и Firebird режима dirty read нет в принципе. Хотя, теоретически, его можно реализовать. Но в здравом уме разработчики это делать не собираются.
23 май 15, 00:03    [17679432]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
[quot kdv]
Сергей Арсеньев
Но в здравом уме разработчики это делать не собираются.


Напомнило: "Если в Oracle этого нет - значит это никому не нужно!"
23 май 15, 00:57    [17679568]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
pkarklin
Напомнило: "Если в Oracle этого нет - значит это никому не нужно!"

Те кому нужен dirty reads, тому не нужны ни версионники ни блокировочники.
25 май 15, 11:41    [17684591]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 12 13 [14] 15   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить