Здравствуйте, Merle, Вы писали:

ГВ>>Да, это не совсем полновесный durability, конечно. Откладывать запись можно, как минимум, обеспечивая надёжность питания системы. Но если эта "дырка" прикрыта, то никаких принципиальных препятствий для обеспечения durability, вобщем-то, нет... за исключением возможной ненадёжности и нестабильности модулей памяти App-сервера.
M>Ну, понимаешь, нельзя быть чуть-чуть беременным... ACID'ity либо есть, либо ее нет.

Нет, она есть с той или иной вероятностью. Конкретные вероятности реальной durability конкретного SQL-сервера нужно считать исходя, как минимум, из MBTF винтов. Оценки из серии "либо есть, либо ее нет" оставим для максималистов. Просто, если гарантия "доезжания" транзакции до долговременого хранилища полностью ложится на прикладника — то да, опасность получить в целом ненадёжную систему здесь в принципе намного выше, чем когда такая операция обрабатывалается один раз написанным и отлаженным "куском кода", размещённым в App-ядре.

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

Это справедливо для любой программы на любом компьютере. Особенно — про космические частицы. Да, и ещё, "такая вот транзакция" с точки зрения прикладника ничем не отличается от "не такой". Разруливанием занимается системный код.

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

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

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

При том подходе, о котором я говорил, задерживаемая запись — одна из допустимых фич, и никто не заставляет обязательно задерживать запись всех транзакций. Просто, больно уж естественно она встраивается. Да, кстати, Yukon тоже чем-то аналогичным собирается баловаться — In Memory Transactions, кажется. Но это я не в "оправдание" вспоминаю, а к тому, что нет ничего абсолютного, всегда есть те или иные допуски. "В любой мышеловке есть дырочки". (c)

Здравствуйте, AndrewVK, Вы писали:

AVK>Но точно так же могут вылезти ошибки в firmware винта, что бывало уже не раз. Нет никакой абсолютной durability, есть только верояность приключения неприятностей, большая или меньшая.
Да, но при использовании БД, она гораздо более меньшая, по причине того, что там и алгоритмы, и код вылизывали годами,
а данные дублируются.
Чтобы добиться такой надежности в рукопашную, надо много усилий положить, при этом выигрыш копеечный.

Здравствуйте, AndrewVK, Вы писали:

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

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

Здравствуйте, Merle, Вы писали:

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

Да никто и не спорит. Но вот говорить "Ну, понимаешь, нельзя быть чуть-чуть беременным... ACID'ity либо есть, либо ее нет.
" не стоит.

IT>Ага, на пару фарад
И не надо прикалыватся. Это абсолютно точное требование какого то там стандарта к современным винтам. Если уж очень интересно могу поискать попытаться.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ> Нет, она есть с той или иной вероятностью.
Ну тут я утрировал конечно..

ГВ>Да, и ещё, "такая вот транзакция" с точки зрения прикладника ничем не отличается от "не такой". Разруливанием занимается системный код.
Но системный код — тоже не боги пишут, в БД все формализовано и алгоритмы стандартные, плюс все отлаживали десятилетиями. А в App надо написать в достаточно короткие сроки, код сильно зависимый от предметной области.
Поэтому тут с durability лучше не играться, это лишняя головная боль ради копеечного выиграша.

ГВ>При том подходе, о котором я говорил, задерживаемая запись — одна из допустимых фич, и никто не заставляет обязательно задерживать запись всех транзакций.
Да вот такая ли уж она допустимая? И кто будет разруливать, в каком случае допустимая, а в каком нет?
Наверняка этого сказать нельзя.

Здравствуйте, AndrewVK, Вы писали:

AVK>Да никто и не спорит. Но вот говорить "Ну, понимаешь, нельзя быть чуть-чуть беременным... ACID'ity либо есть, либо ее нет.
AVK>" не стоит.
Да ладно, а то ты для пущего эффекта никогда не утрируешь...

Здравствуйте, Merle, Вы писали:

ГВ>>Да, и ещё, "такая вот транзакция" с точки зрения прикладника ничем не отличается от "не такой". Разруливанием занимается системный код.
M>Но системный код — тоже не боги пишут, в БД все формализовано и алгоритмы стандартные, плюс все отлаживали десятилетиями. А в App надо написать в достаточно короткие сроки, код сильно зависимый от предметной области.

Ну, вот это — непонятно: "в достаточно короткие сроки, код сильно зависимый от предметной области" Если ты думаешь, что такая дура, как App-сервер пишется на коленках студентами-двоечниками, то... кхм. Тут только теорий и анализов больше чем на полгода возни. Было...

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

Спасибо, конечно, за совет, но, ИМХО, тебе бы не стоило обобщать, или уж тогда конкретизировать: "я не буду играться с...".

ГВ>>При том подходе, о котором я говорил, задерживаемая запись — одна из допустимых фич, и никто не заставляет обязательно задерживать запись всех транзакций.
M>Да вот такая ли уж она допустимая? И кто будет разруливать, в каком случае допустимая, а в каком нет?
M>Наверняка этого сказать нельзя.

Нахрапом — нет, нельзя. Если подумать что да как — то можно.

Здравствуйте, Merle, Вы писали:

ГВ>>Да, и ещё, "такая вот транзакция" с точки зрения прикладника ничем не отличается от "не такой". Разруливанием занимается системный код.
M>Но системный код — тоже не боги пишут, в БД все формализовано и алгоритмы стандартные, плюс все отлаживали десятилетиями.
Ну, SQL тоже не боги писали... да и пишут
M>А в App надо написать в достаточно короткие сроки, код сильно зависимый от предметной области.
Ну... на самом деле — код App Server'а вообще должен мало перекликаться с предметной облаастью... вот BL — таки да

ГВ>>При том подходе, о котором я говорил, задерживаемая запись — одна из допустимых фич, и никто не заставляет обязательно задерживать запись всех транзакций.
M>Да вот такая ли уж она допустимая? И кто будет разруливать, в каком случае допустимая, а в каком нет?
А можно атрибут разрешить повесить.. типа "вот эти объекты могут зависать с отложением записи до 0.5 уе"... а в конфигах сервера пишется: "В силу того, что у нас UPS обеспечивает питание всего здания в течение 20 часов — уе = 10 часов".
M>Наверняка этого сказать нельзя.
Всяко

ГВ>Да, кстати, Yukon тоже чем-то аналогичным собирается баловаться — In Memory Transactions, кажется.

Я Indigo имел ввиду.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Да, кстати, Yukon тоже чем-то аналогичным собирается баловаться — In Memory Transactions, кажется.
ГВ>Я Indigo имел ввиду.
Во-во, а то я уж испугался...

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Спасибо, конечно, за совет, но, ИМХО, тебе бы не стоило обобщать, или уж тогда конкретизировать: "я не буду играться с...".
"... и другим не советую"

ГВ>Нахрапом — нет, нельзя. Если подумать что да как — то можно.
А если еще подумать, то мало того, что даже если все транзакции таким образом обслуживать, то выишгыш все равно получится мизерный, так еще отсюда надо убрать те транзакции, с которыми так поступать в принципе нельзя.
А если еще вспомнить, что есть транзакции с которыми в принципе так можно поступать, но на их данных могут работать транзакции с которыми так поступать нельзя, а значит надо и первые сохранять по человечески, то картина становится совсем грустной.
В итоге и получаем, что преимуществ почти нет, написано куча кода, а надежность низкая.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Alexey Shirshov, Вы писали:

хъ

AVK>Во-первых насчет нескольких раз ты перебрал, а во-вторых по твоему сложные проверки легче писать не на шарпе, а на tsql, так что ли?

Конечно, нет. Я лишь говорю, что все проверки ограничений целостности, уникальности и другие обязаны присутствовать в sql-сервере, даже если они дублируются на коде бизнес-логики и на клиенте.

Здравствуйте, Merle, Вы писали:

ГВ>>Спасибо, конечно, за совет, но, ИМХО, тебе бы не стоило обобщать, или уж тогда конкретизировать: "я не буду играться с...".
M>"... и другим не советую"

Ну... э... спасибо за совет.

ГВ>>Нахрапом — нет, нельзя. Если подумать что да как — то можно.
M>А если еще подумать, то мало того, что даже если все транзакции таким образом обслуживать, то выишгыш все равно получится мизерный, так еще отсюда надо убрать те транзакции, с которыми так поступать в принципе нельзя.

Вот любишь же ты это "в принципе нельзя". Нет никакой ложки, всё — обман. (c) The Matrix

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

Да, безрадостная картина, однако.

M>В итоге и получаем, что преимуществ почти нет, написано куча кода, а надежность низкая.

А "низкая", это какая?

Здравствуйте, Геннадий Васильев, Вы писали:

хъ

ГВ>Хм... а передать SQL-серверу задачи поиска уже нельзя?

Изначально речь вообще шла о std::map!

Здравствуйте, AndrewVK, Вы писали:

Ок, давайте про durability и fault tolerance поподробнее поговорим.
Я это все понимаю так: у нас есть некое изменение состояния, и есть некоторые точки во времени, в которых нам чего-то говорят. Типа того, что "мы обеспечиваем сохранность этого состояния на время T с вероятностью (1-P(T)), где P(T) — что-то типа (1-exp(-T/t0)), а t0 — период полураспада соответствующего носителя.
Для обычного простого коммита этот t0 суть то самое MTBF винта, на который скидывается transaction log. Этот MTBF обеспечивается винтом вместе с кэшем, инженерными дорожками и прочими сложными материями — поскольку мы не контролируем детали этого сложного механизма, нам достаточно представлять его как черный ящик с известным MTBF. Включение/отключение аппаратного кэширования всего лишь влияет на этот MTBF, точно так же, как стабилизатор питания или RAID.
Тем не менее, MTBF этого замечательного устройства у нас ограничен сверху MTBF того, в чем он стоит. Если уборщица проливает ведро на сервер в среднем раз в месяц, то никакой суперстабильный винт не спасет.
Для защиты от таких ситуаций у нас есть более мощные средства, чем commit. Например, backup. Успешное выполнение backup означает, что мы гарантируем возврат к забэкапленному состоянию с вероятностью (1-P(T)*P2(T)), где P2 определяется MTBF хранилища backup. Произведение возникает потому, что нам надо убить оба устройства одновременно для потери и данных и бэкапа.
Таким образом, мы получаем сколь угодно близкую к 1 вероятность сохранения состояния через произвольно заданное время T. Вот это вроде как и есть durability.
Для оценки "качества durability", реализованной нестандартным способом, надо понять, какие failures ей угрожают, и какой между ними mean time. И если у нас не дай бог окажется, что MTBF значительно меньше, чем MTBF системы OS+FS Driver+HDD, то нужно отдавать себе отчет в последствиях. Еще хуже, если MTBF начинает зависеть от прикладного разработчика — прелесть RDBMS в том, что результаты коммита непреднамеренно убить невозможно. И как бы криво ни был написан прикладной код (TSQL), MTBF остается одним и тем же.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну... э... спасибо за совет.
Да пожалуйста, заходите ишшо.

ГВ>Вот любишь же ты это "в принципе нельзя". Нет никакой ложки, всё — обман. (c) The Matrix
Каюсь, грешен. ж) — Это внутренний констрэйнт, низя, значит низя, потому, что если чуть-чуть можно, то границы этого чуть-чуть определить очень сложно, а разгребать потом накладно. Проще сразу, низя и все..

M>>В итоге и получаем, что преимуществ почти нет, написано куча кода, а надежность низкая.
ГВ>А "низкая", это какая?
Ну просто таки "никакая"
В каких попугаях не меряй она будет в разы ниже чем при корректном сбросе данных на диск, с журналированием.

Здравствуйте, Alexey Shirshov, Вы писали:

ГВ>>Хм... а передать SQL-серверу задачи поиска уже нельзя?
AS>Изначально речь вообще шла о std::map!

Я и сейчас от std::map отказываюсь — но не для абсолютно же всех случаев поиска. По-моему, там пример был a'la накладная и товарные позиции в ней.

Здравствуйте, Tom, Вы писали:

Tom>И не надо прикалыватся. Это абсолютно точное требование какого то там стандарта к современным винтам. Если уж очень интересно могу поискать попытаться.

Да нет, IT прав, чтобы обеспечить нормальное питание винта несколько миллисекунд нужны конденсаторы размером с этот винт. На самом деле все проще — конденсаторы обеспечивают только питание электроники головки и буферной памяти. Вся остальная электроника вырубается, а вращение пластин обеспечивается за счет инерции.

Здравствуйте, Sinclair, Вы писали:

S>Включение/отключение аппаратного кэширования всего лишь влияет на этот MTBF,

MTBF — среднее время наработки на отказ. Обычно 20-50 тыс. часов. Включение/отключение аппаратного кеша на MTBF не влияет, оно увеличивает вероятность аппаратного сбоя из-за глюков фирмваре, электроники, космических лучей. MTBF у электроники по сравнению с винтом огромен и составляет десятки лет, следовательно на MTBF системы в целом практически не влияет.

S>Тем не менее, MTBF этого замечательного устройства у нас ограничен сверху MTBF того, в чем он стоит. Если уборщица проливает ведро на сервер в среднем раз в месяц, то никакой суперстабильный винт не спасет.

По моему у тебя неверное понимание термина MTBF.