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

Те кому нужен dirty reads, тому не нужны ни версионники ни блокировочники.
ну вот я могу придумать разумную задачу (вернее она у меня есть), где чтение заведомо [ONLY] dirty данных в версионнике мне бы сильно облегчила жизнь.

+ набросок постановки
примерно так -- реализовать асинхронную обработку вставки в таблицу вдоль её сиквенса, с минимум телодвижений и без пропусков. с одним простеньким журналом.

Зная, какие значения ещё болтаются в dirty -- я это сделаю без лишних телодвижений. Даже если какая-то падла редиска продержит очередное значение неделю, закоммитив сильно задним числом.

Иначе мне как-то придется либо организовывать очередь в порядке коммитов с лишними метками (всего закоммиченного) этой самой очередью, т.е. не вдоль сиквенса. Либо сигнализировать себе (изо всех других транзакций) через сомнительные механизмы типа автономий и т.п. -- о запаздывающих значениях
25 май 15, 12:43    [17684969]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

этта
вот я могу придумать

Фантазия у проктостоматологов как всегда буйная.

Posted via ActualForum NNTP Server 1.5

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

Откуда: Киев, Украина
Сообщений: 2897
Блог
этта
реализовать асинхронную обработку вставки в таблицу вдоль её сиквенса, с минимум телодвижений и без пропусков. с одним простеньким журналом.
...
Даже если какая-то падла редиска продержит очередное значение неделю, закоммитив сильно задним числом.
...

Если я правильно понимаю,
задача можно сформулировать: "реализовать асинхронный SEQUENCE/SERIAL с возможностью заполнения пропусков"?

Если да, то сценарий реализации в блокировочнике прост:

0. есть таблица с уникальным констрейнтом на id, и признаком "id_reserved bool "

1. сессия в dirty read резервирует себе id по алгоритму:
1) найди минимальный id, у которого id_reserved = false;
2) если нашёл, обнови ему id_reserved = true, при ошибке повтори 1)
3) иначе вставь (id, id_reserved) = (max(id)+1, true), при ошибке повтори 3).

Есть нюанс, таки есть периоды, когда пропуски существуют: между "rollback сесии не с последним id" и "ближайшей попыткой резервирования".
Больше волнует другой вопрос: что за прикладная задача-то такая?
25 май 15, 13:05    [17685070]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
АнатоЛой
этта
реализовать асинхронную обработку вставки в таблицу вдоль её сиквенса, с минимум телодвижений и без пропусков. с одним простеньким журналом.
...
Даже если какая-то падла редиска продержит очередное значение неделю, закоммитив сильно задним числом.
...

Если я правильно понимаю,
задача можно сформулировать: "реализовать асинхронный SEQUENCE/SERIAL с возможностью заполнения пропусков"?

неправильно понимаете.

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

или слайсать очередь сообщений по вставкам , без создание навороченного журналирования "порядка коммитов" или чего иного -- этакого
АнатоЛой
Если да, то сценарий реализации в блокировочнике прост:
<>
2) если нашёл, обнови ему id_reserved = true, при ошибке повтори 1)
<>
хоть задачу не ту решаете --

и на кой мне на лям вставок -- лям "дед ровсов" ещё ? я чо, похож на больного ?

а всего то ведь нужен журнал достигнутого, с одной записью-писью. и возможность only dirty read-а.

с COALESCE (dirty_min-1,commited_max) -- в журнале.
25 май 15, 13:41    [17685264]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
этта

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

"статистику по вставкам" - это сам факт вставки, не анализируя, что же там вставляется?
Т.е. всего-то видеть, что кто-то зарезервировал запись ("очень вероятно, что я закоммичу запись, и чуть менее вероятно, что её содержимое останется таким как сейчас").
Правильно?

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

значение "слайсать" в данном контексте не понял. "слайсать" для чего? прикладной пример можно?

этта
а всего то ведь нужен журнал достигнутого, с одной записью-писью. и возможность only dirty read-а.

с COALESCE (dirty_min-1,commited_max) -- в журнале.

Понял. У вас типа ТОЛЬКО вставка идёт. И хотелось бы не только получить закоммиченное, а ещё и получить данные о незакоммиченных.
Если некую статистику посчитать - (учитывая, что статистика сама по себе "больше чем наглая ложь"), куда ни шло.

А кой вам ещё прок от самих незакомиченных записей, о которых вы узнали в dirty read? Как их "слайсать"? :)
25 май 15, 14:21    [17685477]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
АнатоЛой
А кой вам ещё прок от самих незакомиченных записей, о которых вы узнали в dirty read? Как их "слайсать"? :)
-- вот под минимальный из них [-1] я очередью отработаю, его [-1] запишу в журнал джоба [как "достигнутого"], и эта единственная запись -- вместо "апдейтить, апдейтить и апдейтить", как вы пердлагаете -- все накладные расходы механизма.

а в следующий раз ломтик для обсчет джобом стартану от журнала, и до текущего "из них[-1]"


дёшево, это было бы, по сравнению с тем, что требуется сейчас.
25 май 15, 15:45    [17686095]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
mayton
Member

Откуда: loopback
Сообщений: 53391
Сергей Арсеньев
kdv,

Как бы пользуются люди Oracle, несмотря на то, что в нем очень затруднен режим dirty read.

Я как-то интересовался можно-ль "грязно-чтение" в Ораклах заюзать для сбора статики.
25 май 15, 18:50    [17687257]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
этта
АнатоЛой
А кой вам ещё прок от самих незакомиченных записей, о которых вы узнали в dirty read? Как их "слайсать"? :)
-- вот под минимальный из них [-1] я очередью отработаю, его [-1] запишу в журнал джоба [как "достигнутого"], и эта единственная запись -- вместо "апдейтить, апдейтить и апдейтить", как вы пердлагаете -- все накладные расходы механизма.

а в следующий раз ломтик для обсчет джобом стартану от журнала, и до текущего "из них[-1]"


дёшево, это было бы, по сравнению с тем, что требуется сейчас.

почему [-1]? У вас один писатель всего?
25 май 15, 20:39    [17687667]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Аравопулло
Guest
Alexander Ryndin
Простите, какой-то поток сознания про RAM и диски. Какие такие версионники хранят блокировки на диске? Про Oracle могу сказать, что информация о блокировках хранится в заголовке блока данных, который в свою очередь лежит в оперативке.


стыдоба, ты видимо не слыхала про select генерящий redo (щито?). почитай про т. н. чистку блоков.
26 май 15, 07:38    [17688869]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
АнатоЛой
этта
пропущено...
-- вот под минимальный из них [-1] я очередью отработаю<>.

почему [-1]? У вас один писатель всего?


автор
с COALESCE (dirty_min-1,commited_max) -- в журнале.

чо то оппонент совсем не всасывает
не всасывает, Карл
печалька
26 май 15, 08:07    [17688911]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
этта
АнатоЛой
пропущено...

почему [-1]? У вас один писатель всего?


автор
с COALESCE (dirty_min-1,commited_max) -- в журнале.

чо то оппонент совсем не всасывает
не всасывает, Карл
печалька

всасывает, Клара, но низко-низко.
теперь понял. :)

Как я ещё понял, ONLY DIRTY - это когда в запросе ТОЛЬКО данные незафиксированные транзакцией. така фича имеется в реализации какой-то СУБД? Или dirty_min будем получать как min(dirty_as_all union committed)?
26 май 15, 11:39    [17689852]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
исправился
АнатоЛой
Или dirty_min будем получать как min(dirty_as_all MINUS committed)?
26 май 15, 11:46    [17689906]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
АнатоЛой

Как я ещё понял, ONLY DIRTY - это когда в запросе ТОЛЬКО данные незафиксированные транзакцией. така фича имеется в реализации какой-то СУБД?
науке такая субд неизвестна

, но поиски ведутся

-- очевидно, что самой субд это знание более чем доступно
остаётся его опубликовать в виде разумного SQL --синтаксиса или ф-ии.
АнатоЛой
Или dirty_min будем получать как min(dirty_as_all EXCEPT committed)?

а вот это уже дорого, слишком дорого, Карл
26 май 15, 14:00    [17690762]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
этта
-- очевидно, что самой субд это знание более чем доступно
остаётся его опубликовать в виде разумного SQL --синтаксиса или ф-ии.
Вряд ли. Вот запускаю я full scan по таблице, который идет 2 часа. При прохождении блока данных N я понимаю, что он грязный. Ок. Идем дальше. Но в это время какое-то приложение меняет блоки N-100. Т.е. мой запрос не закончился, блок N-100 уже проверен - он был чистый, а значит я не увижу данные из этого блока и в будущем.
26 май 15, 14:18    [17690874]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
Alexander Ryndin
этта
-- очевидно, что самой субд это знание более чем доступно
остаётся его опубликовать в виде разумного SQL --синтаксиса или ф-ии.
Вряд ли. Вот запускаю я full scan по таблице, который идет 2 часа. При прохождении блока данных N я понимаю, что он грязный. Ок. Идем дальше. Но в это время какое-то приложение меняет блоки N-100. Т.е. мой запрос не закончился, блок N-100 уже проверен - он был чистый, а значит я не увижу данные из этого блока и в будущем.


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

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

думаю в блокировочнике увидеть одним стейтментом и то и другое -- тоже бы не составило труда. на "размазанный момент чтения записи" , который меня бы тоже устроил [просто по сути задачи], если я буду видеть статус [dirty|commited] каждой из.

другое дело -- выковырять в ноздре некую универсалию, сферически независимую от движка, и внести её в стандарт -- вот это, пожалуй, будет уже сложно и в постановке, и в реализации.
26 май 15, 14:35    [17690995]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

этта
на самом деле я интересуюсь не вообще dirty и вообще закоммиченными, а их
соотношением на некий момент

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

Нету там такого снапшота.

Posted via ActualForum NNTP Server 1.5

26 май 15, 16:29    [17691773]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
Dimitry Sibiryakov
этта
<>
но в версионнике есть снепшот, относительно которого я свою задачу порешаю.

Нету там такого снапшота.

снапшот -- взять всё живое, что есть, и отсеять то, что по id транзакции не входит в видимость сессии.

мне вот вместо вот этого: "отсеять всё то" -- нужно напротив -- взять всё [вернее -- кое что] живое, что есть, но не входит в видимость (и, отдельной строкой -- кое-что, что входит).

если в fb это не реализуемо (вам виднее) -- не очевидно, что не реализуемо на других движках.

-- кстати, можете рассказать, почему оно там не реализуемо
26 май 15, 18:08    [17692388]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

этта
можете рассказать, почему оно там не реализуемо

Потому что "взять всё живое на момент старта транзакции/запроса" и сделать неизменяемую
копию - чертовски дорогое занятие.

Posted via ActualForum NNTP Server 1.5

26 май 15, 18:19    [17692436]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
Dimitry Sibiryakov
этта
можете рассказать, почему оно там не реализуемо

Потому что "взять всё живое на момент старта транзакции/запроса" и сделать неизменяемую
копию - чертовски дорогое занятие.

в том то и мякотка, что мне в задачу не нужно неизменяемый снапшот по dirty.

мне нужно знать, что на момент принятия мной решения там кое чего не болтается.
точка.
если оно не болталось от и до -- то оно там и не появится, поскольку у меня строго монотонная последовательность туда всовывается [факт "предметной области", о которой субд не оповещён].


понятно, что задача сильно специальная. сцепить синхронную логику с асинхронной -- но она всюду, где мы что-то хотим делать не тотчас.
26 май 15, 19:09    [17692634]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
этта
...статус [dirty|commited] каждой из....

Хм... Ну, насколько я знаю, для блокировочного IBM Informix Dynamic Server, например, такая задача теоретически разрешима: в таблицах системного каталога сервера есть таблица с блокировками, поэтому INNER JOIN легко даст ONLY DIRTY, а LEFT OUTER + COALESCE() - [dirty|commited]... С производительностью только может не всё ладно случиться, но утверждать с ходу плохого не буду...
26 май 15, 19:32    [17692725]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 12 13 14 [15]
Все форумы / Сравнение СУБД Ответить