Oberon space
General Category => Общий раздел => Тема начата: Valery Solovey от Апрель 13, 2012, 09:30:08 am
-
MS SQL неоптимально хранит данные, это тоже одна из причин большого объёма БД.
А какие СУБД хранят данные оптимальнее?
-
И какие критерии оптимальности? ::)
-
MS SQL неоптимально хранит данные, это тоже одна из причин большого объёма БД.
А какие СУБД хранят данные оптимальнее?
Мне доводилось несколько раз портировать одни и те же данные под разные СУБД. С точки зрения хранения данных... БД под MS SQL или ASE (Adaptive Server Enterprise (Sybase)) объём БД был существенно больше (в разы), чем, например, под Firebird или SQL Anywhere (Sybase) или DB2 (IBM). Поэтому получить БД размером в несколько гигабайт на MS SQL проще, чем на многих других СУБД. При этом реакция на запросы у MS SQL не всегда лучшая (крайне не любит вложенные JOIN, например), хотя, в целом, по сравнению с бесплатными СУБД (Firebird, Postgress) и недорогими (Anyware) производительность MS SQL выше. В проприетарных СУБД от известных производителей картина с производительностью крайне неоднозначна и стандартное тестирование не делает картину более понятной, поскольку СУБД "заточены" на стандартные тестовые пакеты (TPC (см., например, http://www.tpc.org (http://www.tpc.org))). Ещё более трудной для понимания выглядит ситуация с Oracle, там избыточно (на мой взгляд) много оптимизационных настроек, поэтому понять и объяснить те или иные результаты тестирования производительности может только опытный орклоид (админ), коим я не являюсь.
-
А чем плох большой объем базы?
Ну т.е. будет 15 гигов на MS против 10 на Firebird. Что изменится, если MS работает все равно быстрее?
Почему вы считаете, что это неоптимально? Может они в другом выиграли, за счет избыточности хранения.
Если беспокоиться о месте на жестком диске, то там все равно еще транзакционный лог учитывать нужно, который при высокой нагрузке растет как на дрожжах)
-
А DB2 сопоставима с MS SQL в производительности? На винде.
-
А DB2 сопоставима с MS SQL в производительности? На винде.
На этот вопрос невозможно ответить, т.к. очень много критериев оценки.
Это лучше на SQL форумах посмотреть. Там много информации на эту тему.
Если вы ищете СУБД под конкретную задачу, то составьте список критериев важных для вас и гуглИте ;)
Могу сказать только, что у MS администрирование много приятнее, чем у Oracle или DB2. Плюс соотношение цена/качество очень хорошее.
И производительность кстати сильно от железа зависит. Т.е. если жесткий диск медленный, то нужно его менять, а не СУБД :)
-
А чем плох большой объем базы?
Есть такая категория вопросов, которые легко задать, но на которые... неудобно отвечать. Ваш вопрос из этой категории. Попробую ответить просто: мне не нравятся большие объёмы БД.
Позвольте и мне задать встречный вопрос из той же категории... А чем плоха низкая скорость выполнения запроса?...
Ну т.е. будет 15 гигов на MS против 10 на Firebird. Что изменится, если MS работает все равно быстрее?
Почему вы считаете, что это неоптимально? Может они в другом выиграли, за счет избыточности хранения.
А зачем мне быстрее?.. Моим пользователям и без того ждать приходится очень редко... Хотя сервера, как правило, старенькие и диски на них небольшие...
Если беспокоиться о месте на жестком диске, то там все равно еще транзакционный лог учитывать нужно, который при высокой нагрузке растет как на дрожжах)
Это Вам придётся учитывать (я с MS SQL не работаю), на Firebird, к примеру, никакого журнала транзакций нет.
-
А DB2 сопоставима с MS SQL в производительности? На винде.
Не знаю, не мерил... Есть "независимые" организации, которые занимаются измерениями производительности, это к ним вопрос.
-
Позвольте и мне задать встречный вопрос из той же категории... А чем плоха низкая скорость выполнения запроса?...
Ну например тем, что время реакции системы на действия пользователя зависит от скорости выполнения запроса.
Это Вам придётся учитывать (я с MS SQL не работаю), на Firebird, к примеру, никакого журнала транзакций нет.
Неужели? А как он транзакции выполняет?
-
Позвольте и мне задать встречный вопрос из той же категории... А чем плоха низкая скорость выполнения запроса?...
Ну например тем, что время реакции системы на действия пользователя зависит от скорости выполнения запроса.
Ну, и... чем же плохо большое время реакции системы?..
Это Вам придётся учитывать (я с MS SQL не работаю), на Firebird, к примеру, никакого журнала транзакций нет.
Неужели? А как он транзакции выполняет?
То есть?.. Вы думаете, что журнал нужен для выполнения транзакции?.. Нет, он нужен для восстановления БД после аварийных ситуаций. БД восстанавливается после резервного копирования (backup), а остальное (то, что было после последнего backup) накатывается по журналу транзакций.
-
1. Тем что работать с такой системой не комфортно
p.s. Больше на эту цепочку не буду отвечать. ОК?
2. Мягко говоря это не совсем так.
-
1. Тем что работать с такой системой не комфортно
p.s. Больше на эту цепочку не буду отвечать. ОК?
Если не будете подобные вопросы задавать, то, конечно, ОК!
2. Мягко говоря это не совсем так.
Ну, так расскажите... Как будет совсем так...
-
Ну, так расскажите... Как будет совсем так...
Вам рассказать как выполняются транзакции?
Вот тут есть ответы и по поводу журнала, и по поводу firebird:
http://www.sql.ru/forum/actualthread.aspx?tid=924197 (http://www.sql.ru/forum/actualthread.aspx?tid=924197)
-
Есть какой-то тонкий негатив с вашей стороны... Или мне мерещится?
Может не будем в шахматы играть?
-
Ну, так расскажите... Как будет совсем так...
Вам рассказать как выполняются транзакции?
Да, пожалуйста, если Вас не затруднит... (а вдруг!) ;D
Вот тут есть ответы и по поводу журнала, и по поводу firebird:
http://www.sql.ru/forum/actualthread.aspx?tid=924197 (http://www.sql.ru/forum/actualthread.aspx?tid=924197)
Можно, получить от Вас полезную выжимку из этого трёпа?..
Другими словами, если Вам есть что сказать, то скажите, а если сказать нечего... тогда не надо...
-
Есть какой-то тонкий негатив с вашей стороны... Или мне мерещится?
Может не будем в шахматы играть?
Это не негатив... это противоположность взглядов, подходов к решению...
-
Вещи то вроде очевидные. Но я все равно погуглил для вас.
Даю ссылки, т.к. лень много писать:
http://www.sql.ru/articles/mssql/03090102transactionlogguidelines.shtml (http://www.sql.ru/articles/mssql/03090102transactionlogguidelines.shtml)
http://bourabai.kz/dbt/dbms/1102.htm (http://bourabai.kz/dbt/dbms/1102.htm)
http://www.sql.ru/forum/actualthread.aspx?tid=458042&pg=1&mid=4465931#4465931 (http://www.sql.ru/forum/actualthread.aspx?tid=458042&pg=1&mid=4465931#4465931)
2. в ms sql нет "нежурналируемых" операций, есть минимально журналируемые, так что совсем отключить не удастся ни в 2000-м, ни в 2005-м, бо это приведет к нарушению правил ACID и вероятному разрушению БД.
-
Вот тут есть ответы и по поводу журнала, и по поводу firebird:
http://www.sql.ru/forum/actualthread.aspx?tid=924197 (http://www.sql.ru/forum/actualthread.aspx?tid=924197)
Можно, получить от Вас полезную выжимку из этого трёпа?..
Другими словами, если Вам есть что сказать, то скажите, а если сказать нечего... тогда не надо...
я ж говорю: у него этот журнал запрятан внутрь самой базы.
И транзакцию можно откатить как полностью так и частично:
-
Вердикт такой:
СУБД либо ведет журнал транзакций, либо не отвечает требованиям ACID.
-
Вердикт такой:
СУБД либо ведет журнал транзакций, либо не отвечает требованиям ACID.
Причём здесь требования ACID? Мы говорили:
Это Вам придётся учитывать (я с MS SQL не работаю), на Firebird, к примеру, никакого журнала транзакций нет.
Неужели? А как он транзакции выполняет?
То есть, с Вашей точки зрения без журнала транзакций выполнить транзакцию невозможно. На это я и возражал. Теперь Вы переводите разговор на ACID... Не спортивно.
Теперь в двух словах я Вам расскажу о том, как работают блокировочные и версионные СУБД, и почему для работы (не для восстановления!) версионным СУБД не нужен журнал транзакций.
Блокировочная СУБД меняет данные по месту их хранения, затирая старые данные новыми значениями. Но в момент изменения данных никто не знает того, как завершится транзакция (да, и завершится ли она вообще). Поэтому, на случай отката (rollback) или сбоя, старые данные из записи переносятся в журнал транзакций. К новым данным другие (читающие и пишущие) транзакции доступа не имеют (поскольку эти данные ещё могут "откатить"). Доступ к новым/обновлённым данным открывают только после фиксации (commit) транзакции. Это создаёт большое количество проблем...
Версионная СУБД для меняемых данных создаёт новую версию (в случае добавления записи новая запись первоначально пуста; при изменении старой записи, она копируется в новую область), и в этой новой области происходит редактирование записи. Старая запись не меняется никогда! Поэтому переносить её в журнал для возможного отката нет никакой необходимости, а значит и нет никакого журнала транзакций (для целей отката). Каждая запись имеет маркер той транзакции, которая её создала/изменила. Если меняющая транзакция завершается фиксацией, то актуальна новая запись, если завершается откатом, то актуальной остаётся старая запись. Старая запись не удаляется даже после того, как изменившая её транзакция была зафиксирована, поскольку могут быть транзакции, которые в ней заинтересованы (это те транзакции, которые стартовали раньше, чем меняющая транзакция и имеющие высокие уровни изолированности repeatable read и выше (хотя у версионных СУБД иные уровни изолированности, отличные от блокировочных)). Удаление старых записей возможно только тогда, когда не существует заинтересованных в них транзакций. Такая (версионная) форма изоляции транзакций позволяет пишущей/меняющей транзакции не блокировать данные от читающих транзакций. В существующих версионных СУБД, куда теперь относится и MS SQL пишущие/меняющие одну и ту же запись транзакции блокируются. Но возможен вариант полноверсионной СУБД, когда даже пишущие одну и ту же запись транзакции не блокируют друг друга. Это открывает интересные возможности, прежде всего... в системах принятия решений... Но это уже совсем другая тема.
Что же касается ACID (речь про D - durability), то надо либо поддерживать журнал, либо сохранять БД после каждого COMMIT пишущих транзакций. Firebird не имеет журнала транзакций и поэтому эта СУБД не в полной мере соответствует требованиям ACID. С другой стороны, поддержка журнала для версионных СУБД не такое трудное дело (в отличие от блокировочных), и почему команда Firebird до сих пор этого не сделала, для меня остаётся загадкой.
-
И в чем разница?
Записи в журнале или версии... Суть механизма транзакций то не меняется.
Грань между блокировочными и версионными СУБД сегодня довольно размытая ИМХО
Вы переводите разговор на ACID... Не спортивно.
Транзакции - это вроде как фундамент ACID.
А ACID - это вроде как фундамент СУБД.
Поправьте, если ошибаюсь.
Firebird не имеет журнала транзакций и поэтому эта СУБД не в полной мере соответствует требованиям ACID.
Откуда такая информация? (правда интересно :))
-
И в чем разница?
Записи в журнале или версии... Суть механизма транзакций то не меняется.
А что такое "механизм транзакций"? Я знаю два механизма изоляции транзакций, они принципиально разные, каждый имеет свою историю развития (то есть, они менялись и меняются).
Грань между блокировочными и версионными СУБД сегодня довольно размытая ИМХО
И кто же и как же её размыл?.. Можно попросить поподробнее?..
Вы переводите разговор на ACID... Не спортивно.
Транзакции - это вроде как фундамент ACID.
А ACID - это вроде как фундамент СУБД.
Многие СУБД вообще не поддерживают транзакций. Не все транзакционные системы соответствуют ACID. Они, что "воздушные замки"?
Поправьте, если ошибаюсь.
Вы судите очень... поверхностно.
Firebird не имеет журнала транзакций и поэтому эта СУБД не в полной мере соответствует требованиям ACID.
Откуда такая информация? (правда интересно :))
Из головы... а голове эта информация складывалась долго (порядка 20 лет)... из практики, литературы, исходных текстов... собственных размышлений.
-
А что такое "механизм транзакций"? Я знаю два механизма изоляции транзакций, они принципиально разные, каждый имеет свою историю развития (то есть, они менялись и меняются).
Если выделить самую суть:
До момента фиксации транзакции на жестком диске обязательно присутствуют и новые и старые данные.
Подробнее написано в книгах и ссылках, что я приводил.
И кто же и как же её размыл?.. Можно попросить поподробнее?..
Все большее число СУБД поддерживает версионность в том или ином виде.
Многие СУБД вообще не поддерживают транзакций. Не все транзакционные системы соответствуют ACID. Они, что "воздушные замки"?
Можно примеры?
Если СУБД не поддерживает ACID на 100% - это не значит, что она не поддерживает ACID
Вы судите очень... поверхностно.
Как вы такой вывод сделали?
Из головы... а голове эта информация складывалась долго (порядка 20 лет)... из практики, литературы, исходных текстов... собственных размышлений.
Т.е. это ваше личное мнение.
http://ru.wikipedia.org/wiki/Firebird (http://ru.wikipedia.org/wiki/Firebird)
Соответствие требованиям ACID: Firebird сделан специально, чтобы удовлетворять требованиям «атомарности, целостности, изоляции и надёжности» транзакций («Atomicity, Consistency, Isolation and Durability»)[1].
-
Вот еще по поводу сути транзакции:
http://www.sql.ru/forum/actualthread.aspx?tid=924197 (http://www.sql.ru/forum/actualthread.aspx?tid=924197)
Для обеспечения Durability достаточно, чтобы commit не вернул "ok" пока данные не попали
на диск. Точка. В какое место диска эти данные попали - пох, детали реализации.
-
А что такое "механизм транзакций"? Я знаю два механизма изоляции транзакций, они принципиально разные, каждый имеет свою историю развития (то есть, они менялись и меняются).
Если выделить самую суть:
До момента фиксации транзакции на жестком диске обязательно присутствуют и новые и старые данные.
Присутствуют. Но какое это имеет отношению к журналу транзакций?..
Подробнее написано в книгах и ссылках, что я приводил.
Ну, так и читайте их, а лучше почитайте классиков...
И кто же и как же её размыл?.. Можно попросить поподробнее?..
Все большее число СУБД поддерживает версионность в том или ином виде.
И что из этого следует?.. Блокировка и версионность - два принципиально разных механизма. И даже, если СУБД поддерживает оба из них, то это не означает, что она их поддерживает одновременно! "Размыть" и/или "смешать" эти механизмы невозможно в принципе. Я же Вам подробно описал суть того и другого механизма... Ну, начните же думать, наконец.
Многие СУБД вообще не поддерживают транзакций. Не все транзакционные системы соответствуют ACID. Они, что "воздушные замки"?
Можно примеры?
Примеры чего СУБД?.. Да, пожалуйста, те кто не поддерживал/не поддерживает транзакций MySQL, FoxPro, Access, большинство "объектных" СУБД и пр. Они же не соответствуют и требованиям ACID... естественно.
Если СУБД не поддерживает ACID на 100% - это не значит, что она не поддерживает ACID
А что же это значит?.. Это значит, что она не соответствует требованиям ACID. Или теперь уже можно быть "немножко беременной"?
Вы судите очень... поверхностно.
Как вы такой вывод сделали?
Путём размышления...
Из головы... а голове эта информация складывалась долго (порядка 20 лет)... из практики, литературы, исходных текстов... собственных размышлений.
Т.е. это ваше личное мнение.
Да, конечно.
http://ru.wikipedia.org/wiki/Firebird (http://ru.wikipedia.org/wiki/Firebird)
Соответствие требованиям ACID: Firebird сделан специально, чтобы удовлетворять требованиям «атомарности, целостности, изоляции и надёжности» транзакций («Atomicity, Consistency, Isolation and Durability»)[1].
"Сделан специально" - ещё не факт, что соответствует. У пингвина и страуса тоже крылья сделаны... специально, чтобы птицам соответствовать... но не летают... как птицы.
Тема исчерпана... "бодаться" неинтересно.
-
Тема исчерпана... "бодаться" неинтересно.
Но почему же, по поводу "яблока раздора" ;)
- "Firebird не имеет журнала транзакций и поэтому эта СУБД не в полной мере соответствует требованиям ACID. " - можно с уверенностью сказать, что наличие оного не будет гарантировать выполнения полного соответствия ACID(хотя бы просто по тому, что его возможной целью может быть не обеспечение D = а многоуровневого отката в "регулярных" случаях).
-
Тема исчерпана... "бодаться" неинтересно.
Но почему же, по поводу "яблока раздора" ;)
- "Firebird не имеет журнала транзакций и поэтому эта СУБД не в полной мере соответствует требованиям ACID. " - можно с уверенностью сказать, что наличие оного не будет гарантировать выполнения полного соответствия ACID(хотя бы просто по тому, что его возможной целью может быть не обеспечение D = а многоуровневого отката в "регулярных" случаях).
Не важно, для каких целей используется журнал транзакций помимо обеспечения D[urability]. Важно то, что обеспечение D без журнала... нетривиальная задача. Потенциально, можно хранить версии записей до очередного резервного копирования (backup)... Но как это поможет при восстановлении? Поэтому, сбрасывать куда-то и сохранять отдельно от БД меняющие запросы необходимо. Это (сохранение и передача запросов меняющих транзакций) полезно и для построения распределённых систем, в случаях полного или частичного дублирования информации в узлах системы.
-
Другими словами, наличие журнала - необходимое, но недостаточное условие для обеспечения долговечности (durabilty).
-
Другими словами, наличие журнала - необходимое, но недостаточное условие для обеспечения долговечности (durabilty).
Да ну ;) а что вы скажете по поводу использования "теневых(shadow)" копий (коль скоро упомянули firebird)?
-
Другими словами, наличие журнала - необходимое, но недостаточное условие для обеспечения долговечности (durabilty).
Да ну ;) а что вы скажете по поводу использования "теневых(shadow)" копий (коль скоро упомянули firebird)?
Shadows повышают живучесть системы, но к её восстановлению они отношения не имеют. Давайте посмотрим определение:
Durability — Долговечность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.
Firebird не поддерживает работу с БД на сетевых устройствах, то есть, и основная, и shadow БД расположены на одном и том же компьютере. А, значит при общем сбое (отключения от питания, например) информация в shadow БД ничем не будет отличаться от информации в основной БД.
Shadows БД выносятся на другой носитель, и полезны только тогда, когда происходит повреждения носителя (жёсткого диска) с основной БД. Как я понимаю, дублирование информации было одним из требований военных, при выборе Interbase, как встраиваемой СУБД на абрамсах. Выживаемость и долговечность не одно и то же... Тот, кто способен выживать в критических ситуациях, не всегда долгожитель, но и долгожитель не всегда может выжить в критической ситуации.
-
Как весело, а вы мне покажите логгированную базу данных которая "выдержала" скажем... ядерный удар (пример утрированный ;D) это я к тому , до чего можно с дуру дойти используя понятие дюрабельность.. исходя из семантики ;D
-
Как весело, а вы мне покажите логгированную базу данных которая "выдержала" скажем... ядерный удар (пример утрированный ;D) это я к тому , до чего можно с дуру дойти используя понятие дюрабельность.. исходя из семантики ;D
Понятно...
-
Если выделить самую суть:
До момента фиксации транзакции на жестком диске обязательно присутствуют и новые и старые данные.
Присутствуют. Но какое это имеет отношению к журналу транзакций?..
То, что вы не знаете зачем нужен журнал транзакций, я еще в начале ветки понял.
http://oberspace.dyndns.org/index.php/topic,220.msg4916.html#msg4916 (http://oberspace.dyndns.org/index.php/topic,220.msg4916.html#msg4916)
-
И что из этого следует?.. Блокировка и версионность - два принципиально разных механизма. И даже, если СУБД поддерживает оба из них, то это не означает, что она их поддерживает одновременно! "Размыть" и/или "смешать" эти механизмы невозможно в принципе. Я же Вам подробно описал суть того и другого механизма...
Бан на гугле? Почитайте про MS SQL 2005
Ну, начните же думать, наконец.
Я не переставал, чтобы начинать....
-
Примеры чего СУБД?.. Да, пожалуйста, те кто не поддерживал/не поддерживает транзакций MySQL, FoxPro, Access, большинство "объектных" СУБД и пр. Они же не соответствуют и требованиям ACID... естественно.
FoxPro, Access - кто бы сомневался. Файловая система NTFS больше на СУБД похожа, чем эти изделия.
Школьные поделки - это тоже СУБД?
Если так, то я пас обсуждать это.
1С в файловом режиме также работает, но ее никто СУБД не называет.
MySQL вроде поддерживает транзакции. Может быть внешними средствами. Не знаю. Искать лень.
-
alexus, у меня есть подозрение, что вы не по теме ветки пишете.
Вы контекст не потеряли?
Еще раз:
До момента фиксации транзакции на жестком диске обязательно присутствуют и новые и старые данные.
Не важно версионник или блокировочник.
Не важно внешний там журнал или внутри базы (или сама база выступает в качестве журнала). Называется оно журналом или нет.
Не важно пишутся в журнал дополнительные данные или нет.
Не важно обеспечивает ли журнал что-то еще помимо транзакций или нет.
Место на жестком диске при выполнении транзакций все равно нужно выделять.
Это очевидно.
Может вам схему нарисовать?
Вы помните тему и о чем мы говорим?
Это Вам придётся учитывать (я с MS SQL не работаю), на Firebird, к примеру, никакого журнала транзакций нет.
-
Если выделить самую суть:
До момента фиксации транзакции на жестком диске обязательно присутствуют и новые и старые данные.
Присутствуют. Но какое это имеет отношению к журналу транзакций?..
То, что вы не знаете зачем нужен журнал транзакций, я еще в начале ветки понял.
Ну-ну... :)
-
Спасибо господа, :) мне определенно нравится этот форум....
-
С другой стороны, поддержка журнала для версионных СУБД не такое трудное дело (в отличие от блокировочных), и почему команда Firebird до сих пор этого не сделала, для меня остаётся загадкой.
Ответ на это вопрос достаточно прост (с моей точки зрения) - в идейном плане Птица полагается на подлежащую ОС - и по этому надежность хранения данных во многом определяется ОС, с другой стороны- дурабильность имеет смысл только для тех случаев когда внештатные ситуации НЕ ВЕДУТ к порче самой БД. А проблемы о которых вы говорите ведут в 90 процентах к тому , что базу нужно будет восстанавливать из бэкапа... но тогда извините какой смысл заниматься логгированием ради Д. То есть, причина в том что Птичка СПРОЕКТИРОВАНА недостаточно надежной для подобных ситуаций - и никаким логом это дело не выправишь...
-
С другой стороны, поддержка журнала для версионных СУБД не такое трудное дело (в отличие от блокировочных), и почему команда Firebird до сих пор этого не сделала, для меня остаётся загадкой.
Ответ на это вопрос достаточно прост (с моей точки зрения) - в идейном плане Птица полагается на подлежащую ОС - и по этому надежность хранения данных во многом определяется ОС, с другой стороны- дурабильность имеет смысл только для тех случаев когда внештатные ситуации НЕ ВЕДУТ к порче самой БД. А проблемы о которых вы говорите ведут в 90 процентах к тому , что базу нужно будет восстанавливать из бэкапа... но тогда извините какой смысл заниматься логгированием ради Д. То есть, причина в том что Птичка СПРОЕКТИРОВАНА недостаточно надежной для подобных ситуаций - и никаким логом это дело не выправишь...
Что значит не выправишь?.. Есть последний backup, есть журнал зафиксированных изменений. Восстанавливаем БД из backup и накатываем все изменения по журналу. Всё. Теперь БД в актуальном состоянии (в том состоянии, после которого произошло обрушение). И при чём здесь ОС?.. А Firebird очень надёжная система, у меня есть заказчик (промышленное предприятие), где система работает с 2001 года... без администрирования. Backup делается по расписанию. Два-три раза в год мы ставим обновления и проверяем работоспособность системы (восстанавливаем из backup, прогоняем тесты). Да, и от других заказчиков нареканий на работу СУБД не поступало ни разу, хотя условия работы СУБД бывают весьма экзотические.
-
С другой стороны, поддержка журнала для версионных СУБД не такое трудное дело (в отличие от блокировочных), и почему команда Firebird до сих пор этого не сделала, для меня остаётся загадкой.
Ответ на это вопрос достаточно прост (с моей точки зрения) - в идейном плане Птица полагается на подлежащую ОС - и по этому надежность хранения данных во многом определяется ОС, с другой стороны- дурабильность имеет смысл только для тех случаев когда внештатные ситуации НЕ ВЕДУТ к порче самой БД. А проблемы о которых вы говорите ведут в 90 процентах к тому , что базу нужно будет восстанавливать из бэкапа... но тогда извините какой смысл заниматься логгированием ради Д. То есть, причина в том что Птичка СПРОЕКТИРОВАНА недостаточно надежной для подобных ситуаций - и никаким логом это дело не выправишь...
Что значит не выправишь?.. Есть последний backup, есть журнал зафиксированных изменений. Восстанавливаем БД из backup и накатываем все изменения по журналу. Всё. Теперь БД в актуальном состоянии (в том состоянии, после которого произошло обрушение). И при чём здесь ОС?.. А Firebird очень надёжная система, у меня есть заказчик (промышленное предприятие), где система работает с 2001 года... без администрирования. Backup делается по расписанию. Два-три раза в год мы ставим обновления и проверяем работоспособность системы (восстанавливаем из backup, прогоняем тесты). Да, и от других заказчиков нареканий на работу СУБД не поступало ни разу, хотя условия работы СУБД бывают весьма экзотические.
1. Вопрос в том, где этот журнал будет хранится - если следовать традиции - в том же файле gdb - то журнал может попортиться с большей вероятностью.
2. При том, что используются системные функции работы с диском (не может оптимизировано работать с голым железом)
3. Да , надежная (падать сервер может часто, но к порче данных это не приводит) - и это показывает, что для типичных областей использования Птицы заложенного запаса прочности хватает без логгирования, а следовательно усилия разработчиков вполне можно направить в другое русло.
-
1. Вопрос в том, где этот журнал будет хранится - если следовать традиции - в том же файле gdb - то журнал может попортиться с большей вероятностью.
"Традиционно" журнал должен хранится отдельно от БД, желательно иметь более одного журнала на разных носителях.
2. При том, что используются системные функции работы с диском (не может оптимизировано работать с голым железом)
А это и не нужно, как правило. По-хорошему, под сервер БД нужно выделять отдельный компьютер, на котором и "железо", и ОС и вспомогательные программы подчинены работе СУБД.
3. Да , надежная (падать сервер может часто, но к порче данных это не приводит) - и это показывает, что для типичных областей использования Птицы заложенного запаса прочности хватает без логгирования, а следовательно усилия разработчиков вполне можно направить в другое русло.
Ну, хорошо. Работаю люди с системой целый день, по ночам делается backup. Сервер жёстко "упал" в конце рабочего дня, похоронив БД... Что будем людям говорить?.. Может быть backup делать через каждые пять минут (при продолжительности выполнения backup - 30-40 мин.)?..
-
1. традиционно - в стиле Птицы - все хранится одном файле
2. И почему тогда Оракл, DB2 - это делать могут... наверно оттого что разработчикам делать нечего... :D
-
1. традиционно - в стиле Птицы - все хранится одном файле
А как же security2.fdb? Да, он один на сервер, но всё же... не всё хранится в одном файле. Сортировка записей происходит во внешнем [временном] файле. Внешние (external) таблицы хранятся во внешних файлах. Библиотеки udf тоже внешние файлы...
Да, и надо ли стремиться к тому, чтобы всё хранить в одном файле?..
-
3. Частично от таких бед помогает теневое копирование (вот его и можно развивать как альтернативу логгированию).
-
3. Частично от таких бед помогает теневое копирование (вот его и можно развивать как альтернативу логгированию).
Да, согласен, что помогает... если авария не связана с внутренней логикой, например, какая-то пользовательская функция... "взбрыкнула"... Или нечто подобное. В любом случае журнал бы не был лишним...
-
1. традиционно - в стиле Птицы - все хранится одном файле
А как же security2.fdb? Да, он один на сервер, но всё же... не всё хранится в одном файле. Сортировка записей происходит во внешнем [временном] файле. Внешние (external) таблицы хранятся во внешних файлах. Библиотеки udf тоже внешние файлы...
Да, и надо ли стремиться к тому, чтобы всё хранить в одном файле?..
1. Вы сами ответили на вопрос , кстати, секьюрити также не самая сильная черта Птицы (концепция такова , что безопасность должна обеспечиваться OC).
2. По этому я и использовал слово "традиция"
-
Вообще говоря Птица развивается сообществом в условиях ограниченного финансирования и людских ресурсов согласно приоритетам - которые как считается могут более раскрыть существующий потенциал.. но не забывают и о пользователях... поддерживают аж 2 форка
-
Вообще говоря Птица развивается сообществом в условиях ограниченного финансирования и людских ресурсов согласно приоритетам - которые как считается могут более раскрыть существующий потенциал.. но не забывают и о пользователях... поддерживают аж 2 форка
Да, я знаю.
-
Возможно по тому, что уперлись в границы.. и не хотят рисковать нажитым...
Другого обьяснения для поддержания форков в таких условиях у меня нет
-
Возможно по тому, что уперлись в границы.. и не хотят рисковать нажитым...
Ну, нет... Каждая новая версия - это сильно переработанное ядро СУБД. И новшеств довольно много. Вон, третья версия будет поддерживать параллельную обработку, а это значит, что всё ядро перетряхнут. Журнал - это мелочь, по сравнению с такими объёмами работ.
-
Вот вот, а если учесть что опыт показывает что он не так уж и много решает в областях применения... вот вам и причины того, почему его нет.