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

Откуда:
Сообщений: 9898
2 Gluk
Ну если требование согласованности выкинуть - то и в аксесе можно замутить горячий бекап
3 сен 04, 09:11    [931516]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Ув. "Лох позорный"

И в общем случае, есть некий ресурс и проблема читателей/писателей. И как вы с этим собираетесь предотвращать коррупцию в данных? Сериализовать доступ к ресурсу, либо блокировкой ресурса, либо постановкой процессов "в очередь". Результат "философски" такой - в один момент премени доступ к ресурсу имеет один процесс. Пока он ресурс не отпустил, остальные курят бамбук. Если он ресурс не отпустил а решил "заснуть" или грохнуться, то курить бамбук они будут долго. На мелкософтном сайте был совет как борться с проблемами когда аксес упал, а файл блокирвовк остался. Рекомендуют убивать файл блокировок нафиг.

И про конкурентное чтение X байт и записи Y байт поподробнее пожалуйста. Пришел клиент К1. Запросил часть некоторого файла, ничего не блокируя, получил ее по сети. Изменил ее. Пока он с ней возился успел прийти клиент К2 и шустренько так ее поменять и записать. Имеем классический lost update. И race condition задно, в зависимости от того кто первый успел записать, его данные и будут потеряны. Теперь представьте что в данных был счетчик чего-то. И оба процесса его пытались на единицу увеличить. Если бы все работало как положено, он бы увеличился на 2, а из-за lost update всего на 1. Так ведь? Атомарность всей операции-то нам не гарантирована. Можно, правда, обойтись одной атомарной операцией append, но тогда при чтении имеем "интересное кино" с выяснением какая же версия "крайняя". Да и файл, падла, растет не по дням а по часам. "Такой футбол нам не нужен". Возражения?

Не все файловые системы позволяют блокировку на уровне записи. И не все файл-серверные СУБД ей пользуются.

И еще, про чудесный файл-сервер. Как там считаются любые агрегатные функции, типа MAX/MIN/AVG и что при этом пересылается по сети? Сравните с системой типа клиент-сервер. Заодно подумайте как в ФС обеспечивается согласованное чтение. Один клиент считает "среднее за месяц" по полю "баланс" по 25 записям с 1й по 25ю. А второй в это время решил отнять 100 рублей от баланса в 3й записи и прибавить 100 рублей к балансу в 24й. Что будет?
3 сен 04, 09:16    [931530]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Злой
Рекомендуют убивать файл блокировок нафиг.

Который, по вашим же словам, заблокирован намертво. Отвалившимся клиентом.
Кста, мне ldb-файлы, оставшиеся от отвалившихся клиентов - жить не мешают. Мертвых блокировок не наблюдается. Разрешите попросить ссылку на мелкософтовский совет?

И про конкурентное чтение X байт и записи Y байт поподробнее пожалуйста.

Научитесь наконец читать!
А то это уже всякие границы разумного переходит.
Речь шла о том, что для чтения Х байт и записи Y байт не надо пересылать весь файл по сети как это утверждаете вы. Ни в случае совместного использования, ни в случае монопольного.

Возражения?

Сначала объясните - к чему вы это привели? Т.е. что хоть я защищать-то должен от вашим безумных предположений?

Не все файловые системы позволяют блокировку на уровне записи. И не все файл-серверные СУБД ей пользуются.

Ну слава яйцам, хоть какой-то прогресс. Раньше вы утверждали, что никакие файл-серверные СУБД не позволяют блокировок ни на уровне страниц, ни на уровне записей. Ни на каких файловых системах.

З.Ы. Вы меня своими агрегатами не пугайте :), я и так пуганный.
З.З.Ы. По поводу пересылок данных по сети - я уже ответил, что не надо тут америку открывать.
3 сен 04, 09:34    [931585]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
А как в Access дела обстоят с согласованным чтением? Оно там вообще есть? См. пример с балансом про 25 записей. Интересно было бы узнать про Файлмэйер, да рисователи форм такими вопросоами не заморачиваются. Кстати, про файлмэйкерный индекс, он многомерный, R-tree, B*tree, битмапный, основанны на значениях функции или какой? Че-то сомневаюсь я что они какой-то новый индекс придумали.
3 сен 04, 09:35    [931590]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Про "безумные предположения", так это не предположения, а именно так все и происходит при неблокирующем чтении и записи. Если не так - скажите как. А я вас в мануал ткну где это написано, и расписано как с этим бороться. Или хотя бы сюда
http://www.cim.mcgill.ca/%7Efranco/OpSys-304-427/lecture-notes/lecture-notes.html

А по файл-серверным СУБД я просто отстал навсегда. В те времена когда я с ними работал они действительно блокировали все на уровне файлов. Правда Windows тогда еще не было, по крайней мере 3.0 еще не вышел а более ранних я не видел. В общем и целом создается впечатление что кое-где кое-что подлатали, с появлением более тонких блокировок, но недостатки обусловленные уродством архитектуры остались. В мое время согласованного чтения в ФС СУБД еще не было, а есть ли оно сейчас?

Ссылку про аксес не приведу - поищите на мелкософтном саппортном сайте. Я сломался, спать пойду. У меня почти 11 ночи уже.
3 сен 04, 09:46    [931637]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Злой
А как в Access дела обстоят с согласованным чтением?

Фигово обстоят дела
Read Commited и никаких гвоздей
Что успело закоммититься на момент чтения - то и прочитаем. То, что мы что-то там прочитали - никак не помешает поверх этого закоммитить что-нибудь новое.
Правда можно интересующий набор самостоятельно заблокировать от изменений. То еще развлечение. Однако решаемо. Однако с гемором.
3 сен 04, 09:47    [931643]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
roman10
Member

Откуда:
Сообщений: 341
Зл0й
Могу, по доброте дущевной, подарить идею "поблатнее": каждый раз когда мы что-то блокируем создавать файл в директории /filemaker/locks с соответствующим именем, и блокировать этот файл, потом файл удаляем. Решение не шибко элегантное, но зато будет гарантировано работать на любой файловой системе, поддерживающей блокировку на уровне файлов


Не надо изобретать велосипед. Винда позволяет блокировать произвольные участки файла, с точностью до байта. Причем возможны как разделяемые, так и монопольные блокировки. Надо полагать, MacOS в этом смысле не хуже. А об остальных речи вроде не идет.
3 сен 04, 09:56    [931682]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
2Gluk (Kazan)

в пень отговорки. Даёш скриншоты, нефига сопли разводить.

Gluk (Kazan)
Я видите-ли биллинговые системы пишу. Под конкретного заказчика, так-что мне скриншоты без надобности.


назвался груздём - далее по тексту.
3 сен 04, 10:02    [931715]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
3 сен 04, 10:03    [931721]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 Килобит

В гости приезжай, все покажу :) Сравним с твоим "междумордием".
Впрочем, есть вероятность что в скором времени один из моих продуктов всплывет в Москве, тогда у Вас будет возможность его и посмотреть и приобрести.

Ломает меня скриншоты выкладывать. Было-бы ради чего :)
3 сен 04, 10:26    [931818]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
Gluk (Kazan)

просьба не называть меня килобитом.

Если вам нечего показать или вы чего-то стесняетесь то зачем же утверждать что у вас всё красиво? Но это так, скорей к культуре общения относится.
3 сен 04, 10:32    [931844]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
В отличие от Вас, я не занимаюсь рекламой своих продуктов на форуме. Мне это без надобности. Называть я могу как захочу и кого захочу (главное что мы друг друга поняли). Размазываю я обычно ЧУЖИЕ сопли. И стеснятся мне нечего.

Если Вы внимательно почитаете текст, то обратите внимание, что было высказано необоснованное утверждение о том, что я уделяю недостаточное внимание вопросу пользовательского интерфейса. Я заявил, что не согласен с этим утверждением, но не вижу необходимости тратить усилие для того чтобы кого-то в чем-то убедить/разубедить. Мне знаете ли глубоко наплевать на то, что Вы обо мне думаете.
3 сен 04, 10:37    [931874]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Лох Позорный

Что такое deadlock я не знаю (ну вот такая вот моя файл-серверная судьба )

Это ситуация которая благодаря применяемому протоколу блокирования позволяет предотвратить некорректное (или потенциально некорректное) изменение базы данных в результате воздействия нескольких конкурирующих транзакций (предотвращение тех самых "грязных" данных), но ни одна из этих транзакций не может продолжить работу поскольку ожидает освобождения ресурса другой транзакции.

Если Ваша файл-серверная судьба не сводила Вас с deadlock-ми, значит в Ваших системах присутствуют только элементарные транзакции или применяемый Вами протокол блокирования не позволяет выявить потенциально опасные ситуации, или применямый механизм блокирования позволяет предотвратить "явный deadlock" ( например попытка блокирования без ожидания, транзакция получает отлуп, ещё не успев вступить в deadlock).

Недостаток знаний, это не файл-серверная судьба, это лень.
Ознакомится с механизмами управления паралельными заданиями достаточно легко обратившись к литературе по этому вопросу, лучше к более специализированной, например Concurrency Control & Recovery in Database Systems, By Ph. Bernstein .
Или если совсем лениво, хотя бы популярной, типа введений в БД, например
неплохие главы по управлению паралельными заданиями (18,19) есть в
Г. Гарсия-Молина, Дж. Ульман, Дж. Уидом "Системы баз данных. полный курс". Вильямс, 2003.
На худой конец у Дейта, хотя у него это дело как то не очень описано.

Лох Позорный

Срубания транзакций по каким-то там таймаутам - я как-то тоже не наблюдал.
Может, вы что-то не то сказали? Или я что-то не так понял?

Судя по всему всё не так...
3 сен 04, 10:50    [931939]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Зл0й

Это мы рассмотрели только NFS. А теперь давайте до кучи сюда добавим SMB, который вроде-как поддерживает блокировку на уровне "записи", Netware с его NCP/NFSP. Представьте себе "простенькую задачу" по написанию софтины которая будет блокировать "некую индексную структуру". Ведь файлмэйкер-то позиционируется как многоплатформенная "якобы СУБД". По крайней мере на Mac OS X и виндах он обязан работать. Причем даже если две разные файловые системы и поддерживают блокировку на уровне блока или записи, то делают они это по разному. Сказать-то "давайте напишем..." гораздо проще чем сделать.

Те ФС системы которые мне приходилось наблюдать ( а они только ПиСюковые) не работают на прямую с сетевой файловой системой, они вообще не знают, что работают с сетевой системой, они просто выдают локальные вызовы которые редиреректор ОС транслирует в соответствующие вызовы сетевой файловой системы. И никаких проблем у их разработчиков с "многоплатформенностью", или сетевая файловая система позволяет транслировать соответствующие вызовы и всё, типа, тип топ или нет, и она не используется.
Поэтому если NFS нехороша для использования в среде ФС, стало быть, и не к чему её там использовать, пусть используют например RFS.

Просто критиковать некую технологию, как мне кажется, всё же следует не ставя её в ситуацию где, она вообще мало пригодна. Большинство ФС систем, сидит на клонах Виндов или на НетВарях и аргумент ,что а вот на NFS это дело плохо катит, врят ли в чем то может поколебать её сторонников, им просто пофиг как это дело происходит на NFS.
3 сен 04, 11:20    [932127]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Я и Ёжик
Ну уж совсем за д...оеба меня не надо держать
Не знаю что такое deadlock - значит не видел их в используемых мною системах, а не "поленился когда-то книжки прочитать"
Ну не видел. Ну не могу сказать, насколько верно утверждение, что "использование файла блокировки приводит к решению проблемы deadlock через упомянутые здесь таймауты".
Однако за этим следует утверждение, что использование файла блокировки вкупе с таймаутами "так же приводит к срубанию транзакций", чего я тоже не наблюдаю.

Если ваше утверждение верно - то я должен наблюдать срубающиеся транзакции, но не должен наблюдать дедлоки
Если ваше утверждение не верно - то я не должен наблюдать срубающиеся транзакции, однако должны всплыть дедлоки

Нет ни того, ни другого, из чего делаю вывод о том, что чего-то не так сказано или не так понято (кстати, до сих пор не понято :)).

По всей видимости в аксесе реализована схема, описанная словами "транзакция получает отлуп, ещё не успев вступить в deadlock", только все-таки с каким-то там ожиданием.

ушел читать
3 сен 04, 11:48    [932312]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
дедлоки, пересылка по сети...

какая ерунда

вот есть 1ц на дбф и на мс скл, работает одинаково. И при её обсуждении говорят о стоимости владения, настройки отчётности и т.п.

Изначально-то вопрос был о том что какой-то умелец впаривает нечто что неизвестно как написано на малораспространённой системе и спецов по поддержке по этому нечто найти трудно.
3 сен 04, 12:13    [932463]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
не, изначально стоял вопрос о переходе с одного ФС на другой ФС, что, как совершенно правильно заметил Злой, есть бред.
Тем более что со связки "аксес+аксес" гораздо легче перейти на "аксес+ms sql". А потом, если понадобится, на "чтоугодно+ms sql" и на "чтоугодно+чтоугодно"

однако было это настолько давно, что все про изначальный вопрос забыли.
3 сен 04, 12:18    [932497]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Лох Позорный
Ну не могу сказать, насколько верно утверждение, что "использование файла блокировки приводит к решению проблемы deadlock через упомянутые здесь таймауты".


Для разрешения deadlock применяются три основных методики:
1) Анализ графов ожиданий. Этот способ слабо подходит для ФС,
поскольку сессия знает кого она ждет, но не имеет информации кто ожидает её. Тут для ФС потребовалось бы хранить не только файл блокировок, но и что то типа файла "ожиданий", работу сессий с которым в свою очередь тоже надо синхронизировать (т.е. очередное узкое место).
2) Ожидание на блокировках с таймаутами. Способ для ФС вполне подходящий,
поскольку никакой информации о других транзакциях не требует.
3) Хронометраж транзакий. Алгоритм примерно такой если транзакция t1 имеет более раннюю отметку времени чем транзакция t2 то она спокойно ждет на блокировки, если t2 имеет более раннюю отметку времени, то t1 срубается ( в смысле получает некое сообщение об ошибке).
Проблемы с сиспользованием в ФС среде теже , что и дляп.1, необходимость информации о других сессиях.

Таким образом получаем , что для ФС есть только один подходящий способ разобраться с deadlock, способ 2. Тут я наверное действительно неправильно выразился "использование файла блокировок" не ведет к решению проблемы через ... , а не снимает ограничений на использование других способов.

Лох Позорный
Нет ни того, ни другого, из чего делаю вывод о том, что чего-то не так сказано или не так понято (кстати, до сих пор не понято :)).

По всей видимости в аксесе реализована схема, описанная словами "транзакция получает отлуп, ещё не успев вступить в deadlock", только все-таки с каким-то там ожиданием.

Если знаете, что есть "какое-то там ожидание",значит транзакции всё таки получают ошибку типа "истек таймаут ожидания ресурса" и вы эту ошибку обрабатываете? Вот это "истек таймаут ожидания ресурса" я и назвал "срубанием транзакции", поскольку транзакция вещь часто дорогая, то реально её не откатывают сразу, а перекладывают решение откатить её или всё таки попытаться продолжить на плечи программы выдавшей запрос о блокировке.
Т.е. возможена ситуация когда некая транзакция на самом деле находится не в клинче, она просто ждет пока ресурс освободит какая то длительная транзакция, но определить мы этого не можем поэтому приходится обрывать это ожидание и принимать дополнительные действия и решения для продолжения или отката транзакции, что не всегда эффективно.
3 сен 04, 12:41    [932624]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
zz
Member

Откуда: Колыбель космонавтики
Сообщений: 1796
ЛП
Тем более что со связки "аксес+аксес" гораздо легче перейти на "аксес+ms sql". А потом, если понадобится, на "чтоугодно+ms sql" и на "чтоугодно+чтоугодно"


О, полностью согласен. Так оно у меня и было :) Акс+Акс, затем Акс+МСДН, теперь дотнет+МСДН :) Естественная поступь эволюции :)
3 сен 04, 12:55    [932724]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Лох Позорный
изначально стоял вопрос о переходе с одного ФС на другой ФС.

Не, изначальный вопрос был: Как "опустить" ФМ по-полной? Кое-кто попытался сделать это на основании того, что ФМ - есть ФС. В процессе выяснилось что это уже не так. Тогда большенство народа забыло про ФМ, но не забыло про ФС, и начало "опускать" друг-друга.
3 сен 04, 12:59    [932757]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
zz, да ты уникум!!!
кто еще умудрится аксес (и дотнет) к справочной системе прицепить

блокировка страниц справки, многопользовательский доступ к справке, отсутствие грязного чтения справки... ляпота
3 сен 04, 13:00    [932768]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 Александр Зуев

Вас еще никто не "опускал". Постыдились бы употреблять такие выражения в приличном обществе.
3 сен 04, 13:05    [932803]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
про файлмэйкерный индекс, он многомерный, R-tree, B*tree, битмапный, основанны на значениях функции или какой?

У нас с Вам прослеживается явное расхождение терминологии. К примеру, я долго не мог понять что за зверь такой "вторичный ключ", пока мне не объяснили что это всего навсего RelatedKey. Тоже самое с Constraints - у нас это называется Validation. Поэтому, прежде чем я отвечу на Ваш вопрос, будьте любезны, объясните п-ста свое понимание этих терминов.
3 сен 04, 14:23    [933287]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
Запросил часть некоторого файла, ничего не блокируя, получил ее по сети. Изменил ее.

В ФМ это невозможно - ни в более ранних версиях (ФС), ни в последней (КС).


ФС vs. КС:

ФС родился и вырос вместе с первыми персоналками. Родился, ИМХО, потому, что производительность персоналок в те времена была очень низкой, а следовательно выполнять обработку данных на каждом клиенте по отдельности было гораздо выгоднее, чем проводить ту же обработку данных на столь же маломощном сервере для всех клиентов сразу. В последнии годы производительность персоналок резко возросла. Это сделало возможным применять в их сетях технологию КС. Тоесть, ИМХО, причиной перехода многих производителей СУБД с ФС на КС стало повышение производительности систем их использующих, а вовсе не какое-то несоразмеримое превосходство одной технологии над другой.


2 всем ненавистникам ФС:

Люди! Опомнитесь! Хватит воду в ступе толочь! Из некоторых постингов можно сделать вывод что ФС - это вообще daemon, который сидит и ждет случая сделать архивную копию, в то время как его "клиенты" раздирают БД в клочья по протоколам прямого файлового доступа своих ОС. Вы сдесь пытаетесь описать некий алгоритм работы, который гарантировано сделает невозможным самое существование ФС, в то время как различные реализации ФС существуют и служат людям уже много лет.


В общем, не надо напрягаться!
3 сен 04, 14:30    [933319]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
zz
Member

Откуда: Колыбель космонавтики
Сообщений: 1796
тьфу млин надо же так опечататься
Конечно МСДЕ а не МСДН :)
3 сен 04, 14:32    [933324]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 23   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить