Comments 10
В стародавние времена, когда я был маленьким и глупым десятиклассником, лучшим в классе «по компьютерам», я очень негодовал четверке на экзамене по информатике, полученной из-за вопроса про «дурацкие и никому не нужные базы данных».
Через несколько лет, на очередной сисадминской посиделке, убеленный сединами начальник отдела поучал меня «изучай базы данных! Это будущее!», а я ему не особо верил.
А пару лет спустя сам стал администратором БД в bloody enterprise.
Извините, навеяло воспоминаний. Спасибо за доклад. :)
Через несколько лет, на очередной сисадминской посиделке, убеленный сединами начальник отдела поучал меня «изучай базы данных! Это будущее!», а я ему не особо верил.
А пару лет спустя сам стал администратором БД в bloody enterprise.
Извините, навеяло воспоминаний. Спасибо за доклад. :)
А вы уверены, что с MVCC все правильно? А то фраза
И в вашем примере на картинке 17 вторая и первая транзакция отлично выполнятся. А вот на картинке 18 вторая откатится на update conflict'е при w2(x2) (так как t2 началась до коммита t1, а t1 изменил x) и ее надо будет переповторить разработчику. Во всяком случае так работает Postgres последних версий и Oracle ЕМНИП, причем в любом уровне изоляции (хотя конечно с уровнем SERIALIZABLE там есть неочевидные некоторые вещи, но они касаются специфических операций с чтениями по диапазону).
что операция r1(y) вызовет конфликт, возможно, даже дедлокменя немного смущает. Насколько я помню, чтения в mvcc никак не могут привести ни к блокировке (тем более к дедлоку) ни к конфликту (он собственно и называется update conflict), все это в mvcc есть только на уровне записи.
И в вашем примере на картинке 17 вторая и первая транзакция отлично выполнятся. А вот на картинке 18 вторая откатится на update conflict'е при w2(x2) (так как t2 началась до коммита t1, а t1 изменил x) и ее надо будет переповторить разработчику. Во всяком случае так работает Postgres последних версий и Oracle ЕМНИП, причем в любом уровне изоляции (хотя конечно с уровнем SERIALIZABLE там есть неочевидные некоторые вещи, но они касаются специфических операций с чтениями по диапазону).
все везде более-менее одинаково…
Все базы данных внутри похожи
Тезисы как минимум спорные. По факту это ложь.
Пара цитат из книги «Oracle для профессионалов» за авторством Томаса Кайта и Куна Дарла.
В разных базах данных задачи решаются по-разному (то, что хорошо работает
в SQL Server, может не так хорошо работать в Oracle и наоборот), и понимание особенностей
реализации блокировки и управления параллелизмом в КОНКРЕТНОЙ БД абсолютно необходимо для успешного построения приложений.
…
Если вы считаете, что раз уж ваше приложение нормально работает в среде SQ L Server,
то оно обязательно будет успешно функционировать в среде Oracle, то это приложение, скорее всего, потерпит неудачу. Разумеется, корректно также и обратное утверждение: вовсе не обязательно, что масштабируемое, аккуратно разработанное приложение Oracle сможет работать в среде SQL Server без существенных архитектурных изменений. Подобно тому, как Windows и UNIX/Linux являются операционными системами, но фундаментально отличаются друг от друга, Oracle и SQL Server (здесь можно было бы упомянуть практически любую базу данных) представляют собой базы данных, существенно отличающиеся в архитектурном плане.
…
Посыл следующий: если работает с конкретной БД, изучите именно её.
WAL — штука важная, но, возможно, иногда избыточная.
Например, если база допускает только добавление данных и мы можем пожертвовать последней порцией записанных данных, то мы должны пожертвовать в пользу уменьшения количества операций записи на диск вдвое.
И тут, конечно, всё зависит от механизма хранения: позволит ли он сохранить корректность старых данных при авариях с потерей электропитания.
Например, есть СУДБ, где данные лежат на диске уже в структуре hash table. Это позволяет распрелять данные по нескольким нодам по крючу хеширования и получать прирост в операциях join, если он будет выполняться распределённо и локально. Но как тут обеспечивается Consistency и Durability? Можно ли для них отказаться от WAL?
Кто-то знает, как это работает, например, в Teradata или другой СУБД для аналитики?
Например, если база допускает только добавление данных и мы можем пожертвовать последней порцией записанных данных, то мы должны пожертвовать в пользу уменьшения количества операций записи на диск вдвое.
И тут, конечно, всё зависит от механизма хранения: позволит ли он сохранить корректность старых данных при авариях с потерей электропитания.
Например, есть СУДБ, где данные лежат на диске уже в структуре hash table. Это позволяет распрелять данные по нескольким нодам по крючу хеширования и получать прирост в операциях join, если он будет выполняться распределённо и локально. Но как тут обеспечивается Consistency и Durability? Можно ли для них отказаться от WAL?
Кто-то знает, как это работает, например, в Teradata или другой СУБД для аналитики?
БД для аналитики это частный случай, в teradata есть 2 режима чтения, блокирующее и грязное, т.е. с транзакциями там всё "не как обычно" и обновления очень дорогие, это как раз случай базы для специальных условий использования.
Как написано по ссылке, teradata использует wal. Интересно, существуют ли такие СУБД (предположительно, append-only), в которых вместо WAL используются другие способы обеспечения Durability и Consistency?
Насколько я помню firebird, по крайней мере до 3-й версии, не использовал wal как это делали oracle и postgre, но надо уточнить.
firebird версионник до сих пор не имеет лога. там при апдейте транзакция пишет прямо в датафайл новую версию строки, не трогая старую. по коммиту обновляет запись в заголовке, где указывает что новая версия закомичена. на IL snapshot транзакции стартовавшие после записи в заголовке видят уже новую версию, стартовавшие до старую версию. спустя какое-то время сборка мусора вычищает никому не нужные версии строк из файла данных.
не туда ответил
Sign up to leave a comment.
Как устроены базы данных