Здравствуйте, Cyberax, Вы писали:
C>Почему же, вот SVK вполне атомарен.
Т.е. если я в процессе апдейта выключу питание, у меня локальная реплика останется в исходной ревизии? И никаких Clean Up делать не потребуется?
C>Просто в обычном клиенте SVN
C>атомарность нафиг не сдалась.
Совершенно верно. Считается, что проще сделать clean up или вообще повторный чекаут.

C>В SVN используются эффективные алгоритмы дельтификации и разруливания
C>конфликтов. Они и занимают большую часть кода, а простейший движок для
C>статической структуры и без разруливания конфликтов — это совсем несложно.
Разруливание конфликтов никакого отношения к стораджу не имеет. Хранилище всего лишь умеет выполнять модификации атомарно.
>> Мораль: если вы храните именованные блобы, и у вас не бывает транзакций,
>> затрагивающих больше одного блоба, то FS — самое то.
C>Скорее не "затрагивающих больше одного блоба", а "использующих простую
C>модель доступа".
"Простая модель доступа" не годится в качестве формального определения. Потому что иная простота хуже воровства.

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

V>>Описанный тобой сценарий достигается даже если мы все храним в БД:

AVK>Нет, если уровень изоляции соотв. выставлен. В этом случае блокировочник тормознет удалятора и он будет ждать, пока первый клиент закроет транзакцию, а версионник удалятора пустит, зато первому клиенту выкинет snapshot too old.

Во первых, на сервере приложений иногда самостоятельно разруливают блокировки, особенно это удобно именно в документообороте — надо, например, заблокировать документ, но следить затем, чтобы блокировка не была "вечной", в случае отвала клиента. И если система построена именно так, то нам абсолютно все-равно, где мы храним документ — в БД и на диске.

V>>А твой "Упс" надо разруливать примерно так:
V>>- выдать серверу приложений уникальный аккаунт на доступ к репозиторию (т.е. исключить правку содержимого каталога вне системы)
V>>- когда удаляется документ, то, разумеется, сначала удаляется запись из базы
V>>- когда создается, то наоборот — сначала записывается и проверяется файл, только потом вноситься запись в БД.

AVK>Что и требовалось доказать

Да, только сложностей не вижу. Не знаю как сейчас, но еще буквально на Пентиумах-2 800 МГЦ хранить большие блобы в БД было банально тормознуто, помимо всех прочих прелестей, о которых говорил. При активной нагрузке БД сливает файловой системе на таких сценариях.

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

C>vdimas wrote:
>> C>Ну и с большими данными у меня более резво работает (позволяет делать
>> C>memory mapping через специальный интерфейс).
>> Хм... уже хочу такой же
C>К сожалению, copyright на него у заказчика. Но я уже пишу аналог для
C>другого своего проекта — хотя там еще не все готово.

C>Так что если интересно, то welcome в почту.

Стандартный MS Word и прочие документы в него пишутся/восстанавливаются без проблем?

vdimas wrote:
> C>К сожалению, copyright на него у заказчика. Но я уже пишу аналог для
> C>другого своего проекта — хотя там еще не все готово.
> C>Так что если интересно, то welcome в почту.
> Стандартный MS Word и прочие документы в него пишутся/восстанавливаются
> без проблем?
Word читается/пишется без проблем, Excel падает.

Где-то есть какая-то мелкая несовместимость со спецификацией — не было
времени (и необходимости) разбираться подробно.

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

>> Стандартный MS Word и прочие документы в него пишутся/восстанавливаются
>> без проблем?
C>Word читается/пишется без проблем, Excel падает.

C>Где-то есть какая-то мелкая несовместимость со спецификацией — не было
C>времени (и необходимости) разбираться подробно.

На самом деле меня исходники интересуют как макет, жаль что пока падает... Я, в общем, OLE2 либу в свободное время ваяю для дотнета (тоже самое, кое-какие сервера пашут, а кое-какие почему-то не выгружаются, но это дело времени...). Хотелось бы поиметь исходники, чтобы в дотнетный стрим структурированное хранилище сымплементить, а потом его же, но в XML-хранилище...

А потом так вот взять аккуратненько, скопировать в отдельную папку, немножечко прорефакторить и получить что-то вроде OLE.Net, которое будет иметь удобный интерфейс для дотнетного исполнения, и "не очень удобный", вернее — какой получится — для интероперабельного...

Sinclair wrote:
> C>Почему же, вот SVK вполне атомарен.
> Т.е. если я в процессе апдейта выключу питание, у меня локальная реплика
> останется в исходной ревизии? И никаких Clean Up делать не потребуется?
При синхронизации offline-ветки — да. Для рабочей копии придется
запустить cleanup, после этого получим исходное состояние до апдейта.

В SVN мы в этом случае получаем рабочую копию со смешанными ревизиями.

> C>В SVN используются эффективные алгоритмы дельтификации и разруливания
> C>конфликтов. Они и занимают большую часть кода, а простейший движок для
> C>статической структуры и без разруливания конфликтов — это совсем несложно.
> Разруливание конфликтов никакого отношения к стораджу не имеет.
> Хранилище всего лишь умеет выполнять модификации атомарно.
Ну fsfs (делающая намного больше) занимает в SVN примерно 400Кб кода на
С. Моя версия заняла 35Кб кода на С++.

> C>Скорее не "затрагивающих больше одного блоба", а "использующих простую
> C>модель доступа".
> "Простая модель доступа" не годится в качестве формального определения.
> Потому что иная простота хуже воровства.
А иногда ничего кроме простой схемы и не нужно.

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

V>Во первых, на сервере приложений иногда самостоятельно разруливают блокировки, особенно это удобно именно в документообороте — надо, например, заблокировать документ, но следить затем, чтобы блокировка не была "вечной", в случае отвала клиента. И если система построена именно так, то нам абсолютно все-равно, где мы храним документ — в БД и на диске.
Ага. Особенно в условиях offline клиента. В различных решениях по разному.

Здравствуйте, Cyberax, Вы писали:
C>С. Моя версия заняла 35Кб кода на С++.
Твоя версия чего?
>> C>Скорее не "затрагивающих больше одного блоба", а "использующих простую
>> C>модель доступа".
>> "Простая модель доступа" не годится в качестве формального определения.
>> Потому что иная простота хуже воровства.
C>А иногда ничего кроме простой схемы и не нужно.
Еще раз: словосочетание "простая схема" не несет никакой семантической нагрузки. Его каждый волен трактовать как ему угодно. Поэтому обсуждать преимущества и недостатки "простой схемы", равно как и ее необходимость и достаточность, бессмысленно. До тех пор, пока этому словосочетанию не будет сопоставлено достаточно формальное для однозначного понимания определение. Компрене ву?

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Если у кого-то есть свои мысли поделиться — тоже интересно; но в первую очередь — "уже готовое".

Есть такая мысль, что на базе данных можно имитировать древовидную файловую систему, а вот обратно — никак.

И ещё я думаю, что MS всётаки сделает БД на кластерах основой своей очередной ОС. И пойдут тогда все ораклы в отпуск. Или нет. ещё круче. Произойдёт слияние МС и Оракла. но это уже другая тема.

Здравствуйте, WoldemaR, Вы писали:
WR>Есть такая мысль, что на базе данных можно имитировать древовидную файловую систему, а вот обратно — никак.
Можно и обратно. Вопрос в том, что имитация не будет эквивалентной оригиналу.
Вот, можно изобразить связный список на массиве. Только вставка будет дороже.
Можно изобразить и массив на списке. Только индексация будет дороже.
WR>И ещё я думаю, что MS всётаки сделает БД на кластерах основой своей очередной ОС.
Интересно, что же такое БД на кластерах?
WR>И пойдут тогда все ораклы в отпуск. Или нет. ещё круче. Произойдёт слияние МС и Оракла. но это уже другая тема.
Ораклы в отпуск скорее всего не пойдут вообще никогда. В пределах срока жизни одного поколения. Дальше — непонятно. Возможны любые вариации, вплоть до того, что их просто выкупит какая-нибудь компания, занимающаяся чем-то совсем другим, нам пока неизвестным. Куда вот, к примеру, делись ведущие поставщики пеньки и ворвани образца 18 века? А ведь такие стабильные компании были...

всем привет!

как проходящий мимо, не прочел всю ветку — прошу прощения, если уже без меня о том высказались — я зацепил лишь 3й лист из 7 согласно веб-морде — тот на котором живет сообщение Антона чуть выше

S>Нет! Вот так делать нельзя. Точнее, не стоит. Потому что никаких гарантий целостности для такого хранилища дать невозможно.
+1

V>>Более того, файлы зачастую можно хоть как-то восстановить,
S>Это как это ты собрался восстанавливать файл без копии? Или ты имеешь в виду перенабить с клавиатуры?


V>>а БД — только из резервной копии. А в случае документооборота требования к надежности способа хранения содержимого документов гораздо более высоки, чем требования к надежности хранения связей/аттрибутов.
S>Очень интересно. Мне кажется, что у тебя не вполне корректные представления о надежности СУБД по сравнению с надежностью ФС.

так вот по поводу надежности ходовых FS можно отметить что самые продвинутые из них (NTFS) гарантируют только целостность метаданных, но ни в коем случае не данных пользователя. отсюда справедливо вытекает задорный смех Антона чуть выше.

однако в Висте и выше ребята встроили в ядро транзакции для реестра, файловой системы и теоретически для-чего-угодно — Руссинович не поленился написать консольную программку и потратить (именно что потратить — в зале мне показалось процентов 5 ну 10 лишь поняло о чем вообще речь и насколько интересную штуку демонстрируют. вот что значит когда нет GUI? ) на демонстрацию этой фичи на WinHEC в LA в прошлом году ажно 5 минут из примерно 45 ушедших на осн. часть, да и Билл чего-то пролопотал между делом в своей главной презентации сезона для разрабов — это показатель.

Windows Vista is the first general purpose consumer-grade OS that provides transactional support (ACID) for file IO and Windows Registry modification operations (these are only two of the consumers of KTM — point is, you are enabled to write your own).

Ключевые слова для поиска тут Vista+KTM. Даю пару ссылок по теме сходу

старенькие channel 9:
Kernel Transaction Manager and friends (TxF, TxR) и там рядом
и пример на code project: Vista KTM: Transaction Management in Vista and Beyond ... и там дальше по ссылкам

PS кстати механизм Windows Updates уже вовсю это дело использует для откатов неудачных апдейтов и т.п.

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>так вот по поводу надежности ходовых FS можно отметить что самые продвинутые из них (NTFS) гарантируют только целостность метаданных, но ни в коем случае не данных пользователя. отсюда справедливо вытекает задорный смех Антона чуть выше.
Ну, на самом деле с тех пор, как в этой ветке была активность, я таки понял, что имелось в виду.
Надежность MS SQL Server, к примеру, сильно зависит от надежности нижележащего storage. При типичных сбоях всей системы база останется в согласованном состоянии, но такая вещь, как, к примеру, внезапное пропадание одной страницы, база не переживает. И восстановить ее можно только из бэкапа (либо путем крайне мучительных процедур частичного экспорта, пробуя обойти поврежденные места). В этом смысле повреждения ФС носят более локальный характер, и, хотя с точки зрения математики, шансы получить побитые данные остаются ровно такими же, с точки зрения пользователя такая локализованность несколько удобнее.

Преимуществом СУБД, конечно же, по прежнему является возможность согласованного восстановления данных. Как известно, все админы делятся на две группы: те, кто делает бэкапы, и те, кто будет их делать.

VAB>однако в Висте и выше ребята встроили в ядро транзакции для реестра, файловой системы и теоретически для-чего-угодно — Руссинович не поленился написать консольную программку и потратить (именно что потратить — в зале мне показалось процентов 5 ну 10 лишь поняло о чем вообще речь и насколько интересную штуку демонстрируют. вот что значит когда нет GUI? ) на демонстрацию этой фичи на WinHEC в LA в прошлом году ажно 5 минут из примерно 45 ушедших на осн. часть, да и Билл чего-то пролопотал между делом в своей главной презентации сезона для разрабов — это показатель.
VAB>

Windows Vista is the first general purpose consumer-grade OS that provides transactional support (ACID) for file IO and Windows Registry modification operations (these are only two of the consumers of KTM — point is, you are enabled to write your own).

Ага. Недавно читал чей-то блог на тему "Куда делась WinFS". Я так понял, что парни всё-таки соединили СУБД и ФС, получив, с одной стороны, хранение Blob в базе с производительностью, неотличимой от файлухи, а с другой стороны — файлуху с ACID и умением участвовать в распределенной транзакции.
Теперь с точки зрения теории кристалла оба подхода получают одинаковые характеристики, и основные отличия лежат в поле управляемости и легкости в разработке.
Начиная с MS SQL Server 2008 нет пенальти за хранение блобов в базе, и начиная с Висты нет причин отказываться от кислотности операций, включающих в себя файлуху. Это может быть оправдано для сценариев, где участие файлов по прежнему необходимо — например, если один из интерфейсов доступа к данным предполагается через FTP.

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

V> RSDN — не клиент-сервер, а N-tier ), так вот, в случае подвисших транзакций на основном серваке банально начинало заканчиваться свободное место на дисках с устрашающей скоростью, надо срочно было делать полный бэкап и сброс логов. Поборол все, конечно... с тех пор от клиент-сервера держусь подальше

Держись-держись, они без тебя будут работать лучше.
Твоя задача автоматизируется в течение минуты штатными средствами — создание алерта на условие "Percent log used > 70%" (например, можно другую цифру поставить) и как реакция на наступление события либо бакап лога, либо шринк либо что угодно другое, возможно с извещением администратора о нештатной ситуации.

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

_>Твоя задача автоматизируется в течение минуты штатными средствами — создание алерта на условие "Percent log used > 70%" (например, можно другую цифру поставить) и как реакция на наступление события либо бакап лога, либо шринк либо что угодно другое, возможно с извещением администратора о нештатной ситуации.

Ты зачем труп раскопал? На даты смотрел? Да и вообще, не было в 7-ке такой фичи. А если не знаешь подробности — то бэкапить лог при наличии мёртвых транзакций — бесполезно, он не сбросится потом в 0. В 2000-м кое-как это дело побороли по таймауту (очень большому), в 7-ке же надо было отключать юзверей и пристреливать такие транзакции вручную, ибо если ничего не делать, сами по себе они оставались _навечно_, такие были реалии. Пару раз в особо злостных случаях не удавалось даже пристрелить транзакции, я бэкапил базу, удалял её и затем полностью восстанавливал из бэкапа уже без всяких подвисших транзакций. Да и вообще, к современным версиям обсуждаемых серваков и железу та тема имеет слабое отношение.

ЗХ>Если у кого-то есть свои мысли поделиться — тоже интересно; но в первую очередь — "уже готовое".

С готовым — плохо. На форумах общение часто возникает, но вот разумное — редко.
По результатам общения на sql.ru я осознал большой (с моей точки зрения — единственный) плюс хранения больших файлов в ФС:

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

Это очень существенно для всяческих фото-видео-порно сайтов.

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

Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>Связка современного веб-сервера с операционной системой гораздо эффективнее работает на отдачу контента наружу при работе с файлом в ФС.
ДФ>Выражается это в возможности отдавать клиенту файлик по мере чтения с ФС с минимальными затратами ресурсов.
ДФ>Увы, решения через БД обычно требуют чтения данных полностью в какой-нибудь application layer, а уже потом (да и то не просто) позволяют потихоньку отдавать его дальше.
Не знаком с такими решениями. Обычно драйвер БД предоставляет возможность доступа к blob как к стриму.
Потому, что к примеру "чтение данных полностью" для блоба размером в пару гигабайт вообще нереально.

Далее, типичная причина для мнения "ФС отдает данные в веб быстрее" — это то, что стандартные веб-сервера хорошо кэшируют статический контент. Для тех, кто знаком с протоколом HTTP, реализовать те же возможности поверх БД — не проблема.

ДФ>Для Oracle (и, думаю, не только) есть какие-то особо хитрые (и дорогие) решения, позволяющие при чтении блобов делать вид, что это просто файлы — вплоть до генерации нормального имени файла, который ссылается (на самом деле) на блоб.
ДФ>Думаю, что потихоньку аналогичные решения появятся в более-менее стандартных и доступных расширениях — так как эта функциональность изрядно востребована, а реализуется сравнительно легко на уровне БД.
Думаю, что нет. Не вижу никакого смысла.
После того, как побеждены результаты некомпетентности, основные отличия между ФС и СУБД останутся в производительности линейного чтения. Именование — дело десятое.
Вроде того, что каждый коннект к MS SQL отжирает мегабайт памяти в адресном пространстве сервера, и вроде того, что драйвер ФС работает в кернел-моде, что в сочетании с кернел-модным драйвером HTTP позволяет добиться трудновоспроизводимх вручную результатов.
Именно поэтому в MS SQL Server 2008 сделали такой специальный тип данных, который позволяет получить скорость чтения, близкую к ФС.

Hello, Дельгядо Филипп!
You wrote on Wed, 27 Aug 2008 22:02:09 GMT:

ДФ> Для Oracle (и, думаю, не только) есть какие-то особо хитрые (и
ДФ> дорогие) решения, позволяющие при чтении блобов делать вид, что
ДФ> это просто файлы — вплоть до генерации нормального имени файла,
ДФ> который ссылается (на самом деле) на блоб.
ДФ> Думаю, что потихоньку аналогичные решения появятся в более-менее
ДФ> стандартных и доступных расширениях — так как эта
ДФ> функциональность изрядно востребована, а реализуется сравнительно
ДФ> легко на уровне БД.

Особо хитрые решения существуют уже добрый десяток лет и называются content management systems (не те, которые на PHP). Их непосредственной задачей является обеспечение эффективного доступа к неструктурированой информации, которая может в том числе храниться и в файловой системе. Разработчик попросту освобожден от необходимости думать о том, где физически хранятся данные.

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

ДФ>>Увы, решения через БД обычно требуют чтения данных полностью в какой-нибудь application layer, а уже потом (да и то не просто) позволяют потихоньку отдавать его дальше.
S>Не знаком с такими решениями. Обычно драйвер БД предоставляет возможность доступа к blob как к стриму.

А какая разница, все равно это нестандартный вариант получения данных для веб-сервера.
Довольно сложно научить nginx работать с потоком от сервера приложений с той же эффективностью, что и с файловой системой.
Например, поддерживать одновременно десятки тысячи соединений (т.е., увы, столько же соединений к БД и, может быть, тредов для applayer).
Можно, наверно. Но во многих практических случаях проще оказывается хранить часть данных в ФС (со всеми сопутствующими проблемами).

S>Далее, типичная причина для мнения "ФС отдает данные в веб быстрее" — это то, что стандартные веб-сервера хорошо кэшируют статический контент. Для тех, кто знаком с протоколом HTTP, реализовать те же возможности поверх БД — не проблема.
Можно. Но с файлами это проще. По крайней мере, я еще не слышал о реализации какого-нибудь видеохостинга только на БД, без файлов — с реализацией указанных доработок и прибамбасов. Если будут примеры — с удовольствием услышу.

Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>А какая разница, все равно это нестандартный вариант получения данных для веб-сервера.
"Стандартность" не является определяющей характеристикой для производительности.
ДФ>Довольно сложно научить nginx работать с потоком от сервера приложений с той же эффективностью, что и с файловой системой.
С учетом того, что nginx разрабатывался как reverse proxy, то "сложность" этого не выглядит удивительной.

ДФ>Например, поддерживать одновременно десятки тысячи соединений (т.е., увы, столько же соединений к БД и, может быть, тредов для applayer).
Да, именно про это я и писал на два абзаца ниже.
ДФ>Можно, наверно. Но во многих практических случаях проще оказывается хранить часть данных в ФС (со всеми сопутствующими проблемами).
Мы каким-то волшебным образом перешли от производительности к затратам на разработку. Я что-то упустил?
S>>Далее, типичная причина для мнения "ФС отдает данные в веб быстрее" — это то, что стандартные веб-сервера хорошо кэшируют статический контент. Для тех, кто знаком с протоколом HTTP, реализовать те же возможности поверх БД — не проблема.
ДФ>Можно. Но с файлами это проще.
Почему? Можно как-то поподробнее развернуть тезис о простоте реализации HTTP кэширования поверх ФС по сравнению с СУБД?
Наличие встроенной в веб-сервера поддержки не предлагать — это не rocket science.
ДФ>По крайней мере, я еще не слышал о реализации какого-нибудь видеохостинга только на БД, без файлов — с реализацией указанных доработок и прибамбасов. Если будут примеры — с удовольствием услышу.
Я тоже с удовольствием услышу. Но мой опыт показывает, что многие решения не применяются не потому, что они хуже, а потому, что их просто не знают и не пробуют. К примеру, я вот не нашел ни одной реализации "линеечек", которая бы 100% грамотно подходила к вопросу кэширования.