Filesystem vs. Database - Философия программирования

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

ЗХ>Большая просьба накидать ссылок на всевозможные обсуждения-выводы-исследования по сабжевому вопросу (в смысле какой способ хранения информации в каких случаях более подходит, за-против и т.п.).

ЗХ>Database имеется в виду в первую очередь традиционный реляционный; но и про всякие объектно-ориентированные тоже интересно.

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

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

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

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

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

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

V>рекомендую sql.ru

Надеюсь, хоть не форум сравнения СУБД?

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

Ничего личного, мне просто sql.ru не нравится..

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

Тут важн не сколько характер данных, сколько методы работы с этими данными. Скажем, реализовывать самому эффективный параллельный доступ — вспотеешь, да еще пол-москвы в лютый мороз обогревать сможешь, если возьмешся за это в серьез, а в БД всё это уже реализовали неглупые дядьки на протяжении десятка лет. И это если не вспоминать про оптимизацию запросов и все остальное.
А больше в отрыве от задачи и не скажешь.

... << RSDN@Home 1.2.0 alpha rev. 0>>

Merle wrote:
> Тут важн не сколько характер данных, сколько методы работы с этими
> данными. Скажем, реализовывать самому эффективный параллельный доступ —
> вспотеешь, да еще пол-москвы в лютый мороз обогревать сможешь, если
> возьмешся за это в серьез, а в БД всё это уже реализовали неглупые
> дядьки на протяжении десятка лет. И это если не вспоминать про
> оптимизацию запросов и все остальное.
С другой стороны, организовать в БД доступ к нструктурированым (с точки
зрения БД) бинарным данным — получается плохо. Блобы работают в разы
медленнее файлов в FS и не поддерживают MM.

Posted via RSDN NNTP Server 2.0

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

E>Хотя, если для какого-то обзора это нужно, то можно взять какую-нибудь книгу по СУБД, посмотреть во введение. Все качества, которые обеспечивают СУБД (транзакционность, восстанавливаемость, многопользовательность, поддержка ad-hoc запросов, администрирование, распределенность и т.д.) можно
заносить в актив СУБД в большинстве случаев. В остальных случаях -- в пассив

Это и ФС умеют, хотя сочетания всех этих качеств сейчас, может, и не найти, такая ФС не за горами.

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

M>Тут важн не сколько характер данных, сколько методы работы с этими данными. Скажем, реализовывать самому эффективный параллельный доступ — вспотеешь, да еще пол-москвы в лютый мороз обогревать сможешь, если возьмешся за это в серьез, а в БД всё это уже реализовали неглупые дядьки на протяжении десятка лет. И это если не вспоминать про оптимизацию запросов и все остальное.
M>А больше в отрыве от задачи и не скажешь.

Паралелльный доступ в ФС реализован по определению + эффективное кеширование данных и ограничение доступа к объектам ФС. Вообще, различие между ФС и БД постепенно стирается. В ReiserFS уже можно легко хранить кучи мелких объектов, доступ к которым будет быстрым.

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

ЗХ>Большая просьба накидать ссылок на всевозможные обсуждения-выводы-исследования по сабжевому вопросу (в смысле какой способ хранения информации в каких случаях более подходит, за-против и т.п.).

Дык зависит от задачи. И терминалогии. Напиример, исходники в БД хранить явно неразумно. Тут лучше подойдут файлы и сорс-контрол. А финансовую информацию логично хранить в БД, так как ее при этом проще анализировать.

Общее правилао будет наверно таким:

Если данные целиком загружаются в память или читаются только последовательно, то БД не нужна. В обратном случае БД предпочтительна.

Хотя опять же под словом БД можно понимать много чего. Например, тот же сорс-контрол или какой-нибудь DataSet, так как он позволяет индексировать данные и делать запросы. В этом случае получить однозначный овтет на вопрос вообще не представляется возможным.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Q>Паралелльный доступ в ФС реализован по определению
С разруливанием конфликтов доступа и изоляции транзакций? Ага... (здесь я имею ввиду не транзакции ФС, а прикладные транзакции)

Q>+ эффективное кеширование данных и ограничение доступа к объектам ФС.
В БД кеширование существенно эффективнее, потому как ближе к контексту, то же самое и с ограничением доступа.

Q> Вообще, различие между ФС и БД постепенно стирается.
Стирается конечно. И ее стирают изовсех сил, достаточно WinFS вспомнить, которая уже больше БД, чем ФС, но за счет того, что ФС приближается к БД, а не наоборот. Проблема в том, что при текущем положении дел ФС гораздо более низкоуровневая конструкция, чем БД.
БД — это компромис, между совсем абстрактными данными, не поддающимися никакому формализму, и совершенно конкретными данными, которыми можно оперировать только зная предметную область к которой относятся эти данные.
Иными словами, БД говорит, что если ваши данные удовлетворяют таким-то требованиям (e.g. реляционны), то у этих данных для нас реализована: атомарность, согласованность, изолированность, сохраняемость, эффективный доступ по предикату, ect... И для того чтобы грамотно реализовать для конкретного приложания в рамках ФС, все что предоставляет БД надо угрохать кучу сил с вполне предсказуемым эффектом. Так что когда стоит вопрос выбора между ФС и БД, то это, на самом деле, вопрос — нужно ли для данного приложения всё то богатство возможностей, что предоставляет БД, или нет. И если нужно, то ответ очевиден.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

Q>Это и ФС умеют, хотя сочетания всех этих качеств сейчас, может, и не найти, такая ФС не за горами.
Ты забываешь тот факт, что ФС работает на гораздо более низком уровне и не предоставляет прикладному коду подходящих абстракций, для того чтобы тот мог пользоваться этим в своих, сугубо утилитарных целях.
Что толку от того, что NTFS уже с десяток лет удовлетворяет требованиям ACID, когда для того чтобы ACID-ной была бизнес-транзакция поверх NTFS, все равно все приходится разруливать самому.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

C>С другой стороны, организовать в БД доступ к нструктурированым (с точки
C>зрения БД) бинарным данным — получается плохо.
Или получается плохо объяснить БД, что эти данные на самом деле структурированы...

C>Блобы работают в разы медленнее файлов в FS
Смотря что с этими блобами делать, чтобы в разу получить, надо очень напрячься, лучше с помощником.

C> и не поддерживают MM.
Вот дались тебе эти ММ, тебеже уже дважды сказали, что ММ это конкретный способ работы с ФС, у БД есть свои конкретные способы для своих конкретных задач. Дело в задаче, а не в том как ты ее будешь решать.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

M>По теме работы с ФС и сравнения этого дела с БД? Это вряд ли. Ну ладно, я пожалуй соглашусь, что там можно найти несколько человек хорошо разбирающихся в конкретной БД, но откопать их среди орды горлопанов — задача не тривиальная..

M>Ничего личного, мне просто sql.ru не нравится..

Не зазнавайся.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Если речь не идёт о паре небольших конфигурационных XML файлов, то подобный вопрос вообще не должне стоять. Можно ещё было бы говорить о Database+Filesystem vs. Database, но сабж, для приложений интенсивно работающих с данными вряд ли имеент смысл. Всё равно придёшь к файлам, которые будут выполнять роль и функции БД, только значительно хуже.

К тому же файловая система имеет весьма существенное ограничение по количеству файлов в одном каталоге. Помнится даже пару лет назад RSDN фактически был выведен из строя на неделю из-за подобной проблемы.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

или про что? Что конкретно имеется ввиду?

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

База данных это такой файл (или группа файлов).
А файл это множество секторов на диске.
А множество файлов это файловая система.
А фаловая система это такая база данных.
А база данных это такой файл...

Господа, всем высказавшимся спасибо огромное, вроде бы поумнел немножко (личное спасибо IT и Владу, поскольку это ближе всего к тому что хотел услышать)

Теперь немножко законкретизируем это дело. Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные. Мое чувство прекрасного почему-то

подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле". Честно говоря, логично обосновать такую схему мне тяжело (кроме как уже упомянутым "чувством прекрасного" и некоторым соображениями о независимости сущностей-сообщений друг от друга и от базы: типа, даже если БД удалить или программу снести, информация останется доступна). Очень ли это глупо?

Одно из двух: либо очень глупо, либо ты чего-то недоговариваешь о требованиях.

Здравствуйте, Quintanar, Вы писали:
Q>Это и ФС умеют, хотя сочетания всех этих качеств сейчас, может, и не найти, такая ФС не за горами.
Гм. А можно мне показать FS, в которой я могу атомарно изменить несколько файлов? А то у меня вечная с этим проблема — всякие частичные аплоады и прочая муть. Ну или хотя бы изменить один файл, но атомарно — то есть чтобы я начал запись, изменил произвольный объем, а потом у меня exception вылетел и я сделал rollback. Который бы изменил состояние обратно на то, которое было перед транзакцией.

1.1.4 stable rev. 510

Sinclair,

S>Гм. А можно мне показать FS, в которой я могу атомарно изменить несколько файлов?

Удивительная вещь: на ext3 я разархивировал большой архив, затем этот процесс был убит во время разархивации. После этого посмотрел содержимое диска — как будто ничего не разархивировал.

Эксперимент повторил несколько раз — результат стабильный.

Это то, о чём ты говоришь?

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

C>AndrewVK wrote:
>> C>Еще FS очень хорошо работает с кусками бинарных данных. Покажите мне как
>> C>сделать memory mapped file в БД.
>> А зачем? MMF это уже конкретное решение, а не задача.
C>Тем не менее, это один из самых быстрых и удобных методов работы с
C>файлами. С БД такое уже не проходит.
Смотря какая БД. Если говорить о встроенных БД то никаких ограничений нет. ООБД, навигационный доступ итд.
Все зависит от величины абстракции и применяемых подходов для более оптимального хранения информации и более быстрого доступа , SQL для большинства задач просто неподходит,

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

LCR>Это то, о чём ты говоришь?
Да-да. Именно оно. Очень надо. А это работает правильно даже при переписывании файлов? Ну то есть был у меня каталог версии 1.0, я поверх него начал накатывать версию 1.2 (кто-то добавился, кто-то изменился), а потом раз — и прибил процесс посередине. К версии 1.0 откатит?

1.1.4 stable rev. 510

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

ЗХ>Господа, всем высказавшимся спасибо огромное, вроде бы поумнел немножко (личное спасибо IT и Владу, поскольку это ближе всего к тому что хотел услышать)

ЗХ>Теперь немножко законкретизируем это дело. Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные. Мое чувство прекрасного почему-то

1.1.4 stable rev. 510

Sinclair,

S>Да-да. Именно оно. Очень надо. А это работает правильно даже при переписывании файлов?

Проверю ближе к вечеру. Сейчас нужно поработать под виндой.

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

LCR>Удивительная вещь: на ext3 я разархивировал большой архив, затем этот процесс был убит во время разархивации. После этого посмотрел содержимое диска — как будто ничего не разархивировал.

LCR>Эксперимент повторил несколько раз — результат стабильный.

Какой был архив (tar.gz (tar.bz2))? На какой стадии произошло убийство?

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

CS>Ага, теперь можно законкретизировать ответ...

CS>"почтовики" хранят свою информацию в последовательных файлах
CS>например в unix это mbox.

Но и Maildir имеет место быть. Говорят, второй по распространенности на nix-системах.

CS>Отдельно (в отдельных файлах) хранятся индексы. И в этом есть великий смысл.

Ну, это-то понятно.

eao197,

LCR>>Эксперимент повторил несколько раз — результат стабильный.

E>Какой был архив (tar.gz (tar.bz2))? На какой стадии произошло убийство?

Думаешь, система меня обвела вокруг пальца? Делала вид, что разворачивала архив, а сама в это время ничего не делала?

Хм. Возможно я каждый раз совершал одну и ту же ошибку — убивал процесс, когда система шуршала файлом подкачки, а не писала файлы на диск.

Всё возможно.

подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле". Честно говоря, логично обосновать такую схему мне тяжело (кроме как уже упомянутым "чувством прекрасного" и некоторым соображениями о независимости сущностей-сообщений друг от друга и от базы: типа, даже если БД удалить или программу снести, информация останется доступна). Очень ли это глупо?

Опять же, все зависит от множества факторов.

Сколько будет файлов? Если тысячи, то особых проблем нет. Их даже в один каталог раскидать можно. Если десятки тысяч, то на уровне файловой системы придется выстраивать иерархию каталогов. В противном случае операции доступа к файлу будут притормаживать. Если сотни тысяч или миллионы, то не каждая файловая система обеспечит приемлимое быстродействие с такими объемом собственной метаинформации. Да и здесь могут сказываться накладные расходы самой OC на каждый файл. При дейсвительно маленьких файлах (намного меньше, чем одна логическая единица аллокации в файловой системе (сектор)) проигрыш может быть очень значительным, т.к. файловая система для файла выделяет одну запись в оглавлении директория и еще один сектор для самого файла. Так что при большом количестве мальньких файлов СУБД может оказаться выгоднее.

Как часто будут происходить обращения к файлам и каков порядок обращения к ним? Если для обращения к файлу потребуется открывать файл, считывать его, затем закрывать. Затем открывать следующий, считывать его и закрывать, и т.д., то СУБД может показывать гораздо большую производительность. Поскольку БД не так часто открывает/закрывает собственные файлы. Хотя, если обращения к файлам будут осуществляться изредка (запросы инициируются пользователем из интерактивного приложения), то такие расходы на открытие/закрытие файла могут быть совершенно не существенными.

Будут ли обращения к файлам идти из одного приложения (даже если это приложение будет обслуживать нескольких пользователей) или из разных приложений? Если обращения делает только одно приложение, тогда не так уж и сложно отслеживать конфликты чтения/записи при обращении разных пользователей к одному файлу. Если же несколько приложений одновременно обращаются к одному файлу, то разруливание таких конфликтов нужно делать с помощью каких-то вспомогательных инструментов (семафоров, блокировок и пр.). Более-менее продвинутые СУБД в этом случае так же предоставляют уже готовый инструмент.

Потребуется полнотекстовый поиск в файлах? Если вся информация хранится в текстовых файлах, то эффективный поиск по ним можно организовать даже подручными средствами (простейший (f)grep или системы ht://Dig). В случае СУБД потребуется связываться с действительно серьезными СУБД, предоставляющими возможности полнотекстового поиска (в PostgreSQL, насколько помню, есть что-то подобное). И еще вопрос, будет ли полученное решение переносимо между СУБД от различных производителей.

Какие требования к развертыванию/администрированию/сопровождению? Если задумывается продукт a-la почтового клиента или персональной настольной wiki системы, то использование полноценной тяжеловесной СУБД (типа MSSQL или PostgreSQL) может стать серьезным препятствием (хотя бы из-за размера дистрибутива). В этом случае решение на базе файловой системы может оказаться гораздо привлекательнее (и примеры таких решений можно по(д)смотреть в открытых почтовиках KMail, Sylpheed или Thunderbird, а так же в DBMS-less Wiki системах, вроде MoinMoin или Instiki). Если же планируется server-side продукт, то преимущества тяжеловесных СУБД могут значительно перевешивать их недостатки (см. выше). Хотя тогда могут возникать вопросы с переносимости решения (как на разные платформы, так и на разные СУБД).

Какой характер (мета)информации предполагается хранить и какие способы обработки? Если планируются частые операции выборки/поиска по разным критериям, тогда РСУБД будут вне конкуренции (это их вотчина). С другой стороны, если речь идет о чем-то вроде Wiki, с иерархической структурой информации, то можно вообще обходиться без СУБД и даже метаинформацию хранить в самих файлах (по аналогии с заголовками http-запросов). С иерархической информацией связан еще один вопрос: нужно будет перепривязывать узлы? Например, был projects/super/puper/cool.txt, а потребовалось puper/cool.txt переместить в soap_bubble/bums/puper/cool.txt. В некоторых случаях решение на файлах может быть проще, а может и сложнее. И здесь еще один вопрос -- ссылочная целостность. Но это вообще отдельная песня.

Это только то, что с ходу вспомнилось. Если приступить к реализации, то вылезет еще в N раз больше вопросов

Не об очередой ли Wiki системе идет речь?

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

ЗХ> Мое чувство прекрасного почему-то

подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле".
Ну, вообщем-то все уже описал Синклер, но в качестве проверки предлагаю задать своему чувству прекрасного следующие вопросы:
— Каким образом будет происходить бакап файлов и восстановление их после какого-нибудь сбоя так, чтобы это не разъехалось с БД?
— Каким образом будет обеспечиваться согласованность при работе с файлами и согласованность файлов и метаданных в БД?
Если чувство прекрасного даст четкий и внятный ответ на эти вопросы, то можешь смело приступать к реализации..

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

LCR>Думаешь, система меня обвела вокруг пальца? Делала вид, что разворачивала архив, а сама в это время ничего не делала?

LCR>Хм. Возможно я каждый раз совершал одну и ту же ошибку — убивал процесс, когда система шуршала файлом подкачки, а не писала файлы на диск.

Нет, просто tar.gz (tar.bz2) -- это реально два архива. Сжатый файловый архив. Сначала идет распаковка tar-файла, а затем извлечение из tar-а самих файлов. Могло быть так, что tar не разворачивал свой архив до тех пор, пока не распаковался gz(bz2) образ.

Ты для эксперимента попробуй сначала отдельно распаковать gz (bz2) в tar, а затем уже прерывай работу tar-а.

eao197, Синклер, и остальные.

Прошу прощения за дезу. Только что проверил на rar-е, фича не воспроизводится. (*здесь должна быть иконка харакири*)

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

LCR>Прошу прощения за дезу. Только что проверил на rar-е, фича не воспроизводится. (*здесь должна быть иконка харакири*)

Можешь на tar-е через конвейер проверить, что-то вроде (с опциями команд могу ошибаться):

gunzip some_archive.tar.gz | tar x

По идее, tar будет распаковывать файлы сразу, как только они окажутся полностью распакованны gunzip-ом.

Зверёк Харьковский wrote:

> CS>"почтовики" хранят свою информацию в последовательных файлах
> CS>например в unix это mbox <http://en.wikipedia.org/wiki/Mbox>.
>
> Но и Maildir <http://en.wikipedia.org/wiki/Maildir> имеет место быть.
> Говорят, второй по распространенности на nix-системах.

И притом рекомендуется использовать именно Maildir, т.к. он более устойчив к сбоям.
mbox — deprecated.

Posted via RSDN NNTP Server 2.0

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

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

Я как раз сейчас занимаюсь этой темой. В системе, которую я обслуживаю, документы MS Office (в основном) хранятся в БД MSSQL-Server. Месяц назад обнаружилась проблема: при достижении 12000 документов начал проявляться эффект "кто-первый-встал-того-и-тапки" — первый процесс, сохранивший документ, блокирует ряд ресурсов, в связи с чем следующие пользователи при попытке сохранения документа вылетают по тайм-ауту. Кроме этого из-за возросшего объема БД ухудшились некоторые ее эксплуатационные характеристики.
Поскольку:
1) мне идея хранить файлы в БД с самого начала не нравилась (был опыт эксплуатации системы с подобным подходом),
2) начальник уклончиво-против перейти на хранение файлов в файловой системе;
я пришел к "оригинальному" решению: хранить и там и там. Так сказать, использовать преимущество обоих подходов. Основное хранение файлов — в FS, в БД хранятся их зазипованные версии.
Ссылок дать не могу по причине их отсутствия, однако можно посотрудничать на взаимовыгодной основе, учитывая мой опыт эротических взаимоотношений с этим хозяйством. Я, например, в текущий момент подбираю алгоритм сжатия: с одной стороны чтоб хорошо сжимал документы Office, а с другой, чтоб декомпрессор можно было бы полегче переписывать в среде VBA.

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

CS>например в unix это mbox.

В унихах это так вследствии тяжелого наследия UUCP.

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

E>При дейсвительно маленьких файлах (намного меньше, чем одна логическая единица аллокации в файловой системе (сектор))

Сектор это единица аллокации на физическом диске (поэтому, собственно, и сектор). Единица аллокации ФС называется кластер, и обычно состоит из нескольких секторов (потому, собственно, и кластер).

E>Потребуется полнотекстовый поиск в файлах? Если вся информация хранится в текстовых файлах, то эффективный поиск по ним можно организовать даже подручными средствами (простейший (f)grep или системы ht://Dig). В случае СУБД потребуется связываться с действительно серьезными СУБД, предоставляющими возможности полнотекстового поиска (в PostgreSQL, насколько помню, есть что-то подобное).

Либо прикручивать готовый движек.

E>Какие требования к развертыванию/администрированию/сопровождению? Если задумывается продукт a-la почтового клиента или персональной настольной wiki системы, то использование полноценной тяжеловесной СУБД (типа MSSQL или PostgreSQL) может стать серьезным препятствием (хотя бы из-за размера дистрибутива). В этом случае решение на базе файловой системы может оказаться гораздо привлекательнее

Если забыть про embedded-версии СУБД.

... << RSDN@Home 1.2.0 alpha rev. 642>>

Здравствуйте, eao197, Вы писали:
E>По идее, tar будет распаковывать файлы сразу, как только они окажутся полностью распакованны gunzip-ом.
Не, ребята, tar меня не интересует. Меня интересует ФС с поддержкой ACID.

1.1.4 stable rev. 510

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

S>Не, ребята, tar меня не интересует. Меня интересует ФС с поддержкой ACID.

Я такой не знаю (чтобы в ACID входила модификация нескольких файлов или даже несколько отдельных модификаций одного файла).

Sinclair wrote:
> E>По идее, tar будет распаковывать файлы сразу, как только они окажутся
> полностью распакованны gunzip-ом.
> Не, ребята, tar меня не интересует. Меня интересует ФС с поддержкой ACID.
Reiser4FS — http://www.namesys.com/v4/v4.html

Reiser4 is an atomic filesystem, which means that your filesystem
operations either entirely occur, or they entirely don't, and they don't
corrupt due to half occuring. We do this without significant performance
losses, because we invented algorithms to do it without copying the data
twice.

Это буква "A", "C" обеспечивается журналированием, про "D" все понятно,
"I" — есть, но неполный.

Posted via RSDN NNTP Server 2.0

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

E>Сколько будет файлов? Если тысячи, то особых проблем нет. Их даже в один каталог раскидать можно. Если десятки тысяч, то на уровне файловой системы придется выстраивать иерархию каталогов. В противном случае операции доступа к файлу будут притормаживать. Если сотни тысяч или миллионы, то не каждая файловая система обеспечит приемлимое быстродействие с такими объемом собственной метаинформации. Да и здесь могут сказываться накладные расходы самой OC на каждый файл. При дейсвительно маленьких файлах (намного меньше, чем одна логическая единица аллокации в файловой системе (сектор)) проигрыш может быть очень значительным, т.к. файловая система для файла выделяет одну запись в оглавлении директория и еще один сектор для самого файла. Так что при большом количестве мальньких файлов СУБД может оказаться выгоднее.

Ну что за дремучие представления о ФС. Не судите все их по уродцам типа ФАТ, да и NTFS не далеко ушла. Представьте себе, некоторые ФС могут и миллионы файлов в каталоге позволять иметь и хранить мелкие файлы по юолее эффективным схемам.

E>Будут ли обращения к файлам идти из одного приложения (даже если это приложение будет обслуживать нескольких пользователей) или из разных приложений? Если обращения делает только одно приложение, тогда не так уж и сложно отслеживать конфликты чтения/записи при обращении разных пользователей к одному файлу. Если же несколько приложений одновременно обращаются к одному файлу, то разруливание таких конфликтов нужно делать с помощью каких-то вспомогательных инструментов (семафоров, блокировок и пр.). Более-менее продвинутые СУБД в этом случае так же предоставляют уже готовый инструмент.

ФС как будто не представляют

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

Q>Ну что за дремучие представления о ФС. Не судите все их по уродцам типа ФАТ, да и NTFS не далеко ушла. Представьте себе, некоторые ФС могут и миллионы файлов в каталоге позволять иметь и хранить мелкие файлы по юолее эффективным схемам.

Могут. Только я сильно удивлюсь, если производительность по доступу к файлам в каталоге с 1M файлов будет такой же, как и в каталоге с 1000 файлов.

E>>Будут ли обращения к файлам идти из одного приложения (даже если это приложение будет обслуживать нескольких пользователей) или из разных приложений?

Q>ФС как будто не представляют

Это вроде ручных блокировок (всего файла или его региона)?

eao197 wrote:
> Q>Ну что за дремучие представления о ФС. Не судите все их по уродцам
> типа ФАТ, да и NTFS не далеко ушла. Представьте себе, некоторые ФС могут
> и миллионы файлов в каталоге позволять иметь и хранить мелкие файлы по
> юолее эффективным схемам.
> Могут. Только я сильно удивлюсь, если производительность по доступу к
> файлам в каталоге с 1M файлов будет такой же, как и в каталоге с 1000
> файлов.
Удивляйся

Тестировал Reiser4 — работает _очень_ быстро. Время
обращения к файлу по имени в каталоге на 200000 элементов и 1000 — не
отличается заметно. Поиск тоже очень шустро работает.

> E>>Будут ли обращения к файлам идти из одного приложения (даже если это
> приложение будет обслуживать нескольких пользователей) или из разных
> приложений?
> Q>ФС как будто не представляют
> Это вроде ручных блокировок (всего файла или его региона)?
Да.

Posted via RSDN NNTP Server 2.0

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

C>Удивляйся

Тестировал Reiser4 — работает _очень_ быстро. Время
C>обращения к файлу по имени в каталоге на 200000 элементов и 1000 — не
C>отличается заметно. Поиск тоже очень шустро работает.

Точные бенчмарки можно в студию?

>> Это вроде ручных блокировок (всего файла или его региона)?
C>Да.

Этот механизм еще вручную придется докручивать под свои нужды.
Особенно, если возиться придется с регионами.

Здравствуйте, Cyberax, Вы писали:
>> Не, ребята, tar меня не интересует. Меня интересует ФС с поддержкой ACID.
C>Reiser4FS — http://www.namesys.com/v4/v4.html
А, отлично. Вот вам и ответ — если вы выбираете между файлухой и RDBMS, то выбирайте между RDBMS и ReiserFS v4. Все остальное будет плохо работать для всех случаев, кроме работы на уровне отдельных несвязанных файлов.

1.1.4 stable rev. 510

eao197 wrote:
> C>Удивляйся Тестировал Reiser4 — работает _очень_ быстро. Время
> C>обращения к файлу по имени в каталоге на 200000 элементов и 1000 — не
> C>отличается заметно. Поиск тоже очень шустро работает.
> Точные бенчмарки можно в студию?
Точные замеры делать лень

Вот есть на их сайте:
http://www.namesys.com/benchmarks.html

В качестве примера реальной работы — поиск несуществующего файла в нашей
файлопомойке занимает 30 секунд в первый раз и 1.2 секунды во второй раз
(из кэша). В файлопомойке 522326 файлов и 14213 каталогов.

>> > Это вроде ручных блокировок (всего файла или его региона)?
> C>Да.
> Этот механизм еще вручную придется докручивать под свои нужды.
> Особенно, если возиться придется с регионами.
Согласен. Обычно нет смысла возиться с файлами, однако файлы — это самый
хороший способ работы с большими неструктурироваными (с точки зрения БД)
объемами информации.

Posted via RSDN NNTP Server 2.0

Здравствуйте, kryl, Вы писали:
K>Я как раз сейчас занимаюсь этой темой. В системе, которую я обслуживаю, документы MS Office (в основном) хранятся в БД MSSQL-Server. Месяц назад обнаружилась проблема: при достижении 12000 документов начал проявляться эффект "кто-первый-встал-того-и-тапки" — первый процесс, сохранивший документ, блокирует ряд ресурсов, в связи с чем следующие пользователи при попытке сохранения документа вылетают по тайм-ауту. Кроме этого из-за возросшего объема БД ухудшились некоторые ее эксплуатационные характеристики.
Очень интересно. А тюнить БД и исправлять баги не пробовали?
Я кстати не имею опыта с хранением больших количеств больших документов в MS SQL. Хранение миллионов документов размером около 10K — легко. Никаких спецэффектов помимо совершенно привычных блокировок различных уровней гранулярности обнаружено не было, тем более блокирования ряда ресурсов при записи.

1.1.4 stable rev. 510

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

C>Точные замеры делать лень

Вот есть на их сайте:
C>http://www.namesys.com/benchmarks.html

Ты говорил про замер доступа к файлу в каталоге с 200000 файлов и в каталоге с 1000 файлов. В этой каше бенчмарков я с ходу такого теста не увидел.

C>В качестве примера реальной работы — поиск несуществующего файла в нашей
C>файлопомойке занимает 30 секунд в первый раз и 1.2 секунды во второй раз
C>(из кэша). В файлопомойке 522326 файлов и 14213 каталогов.

Это получается ~38 файлов на каталог. Совсем не много.

Кроме того, почему-то не принимается во внимание, что ReiserFS v4 может быть и не доступна (если продукт под Windows или BSD разрабатывается, да и не все Linux-оиды ReiserFS уважают).

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

Это уже другой вопрос.

Merle wrote:
> C>С другой стороны, организовать в БД доступ к нструктурированым (с точки
> C>зрения БД) бинарным данным — получается плохо.
> Или получается плохо объяснить БД, что эти данные на самом деле
> структурированы...
Ну это я и имею в виду в словах "с точки зрения БД".

> C>Блобы работают в разы медленнее файлов в FS
> Смотря что с этими блобами делать, чтобы в разу получить, надо очень
> напрячься, лучше с помощником.
Да элементарно. Например, на записи большого объема данных это заметно.
Или на многочисленных seek'ах.

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

Реальные БД все же вносят значительный оверхед.

Posted via RSDN NNTP Server 2.0

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

ЗХ>Теперь немножко законкретизируем это дело. Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные.

Все известные мне почтовые клиенты используют в качестве хранилища базы собственного формата. Т.е. не стандартные БД, а что-то своё, оптимизированное под задачу. The Bat! позволяет отдельно хранить аттачменты, что довольно удобно. Хранить каждое сообщение в отдельном файле в данном случае мне не кажется разумным по причине возможного количества сообщений. Я, например, свою почту никогде не удаляю (кроме спама, конечно). Если я на что-то подписан или участвую в какой-нибудь группе, то количество сообщений может запросто достигать нескольких десятков тысяч. Могут начаться тормоза, да и бэкапить это всё не фонтан.

Если речь идёт о почтовом сервере, то здесь по разному. В идеале сервер не хранит долго сообщения и работает в режиме постоянного добавления удаления данных. Если всё хранить в одном файле собственного формата, то очень быстро встанет проблема дефрагментации. Хранить в отдельных файлах, полагаясь на идеальный случай, когда пользователь всё прилежно выкачивает, тоже не надёжно. Проблема на RSDN, о которой я говорил, как раз и была связана с тем, что в ящике forum_сабака_rsdn.ru скопилось больше 100к писем с уведомлениями о проблемах e-mail'ов подписчиков форумов.

С другой стороны, на самом RSDN количество сообщений в БД превышает полтора миллиона, размер БД несколько гигабайт (точно не помню, около пяти), сообщения занимают больше 90% места в БД и вроде проблем больших именно с текстом нет.

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

E>Ты говорил про замер доступа к файлу в каталоге с 200000 файлов и в каталоге с 1000 файлов. В этой каше бенчмарков я с ходу такого теста не увидел.

Там используется стандартная схема с Б-деревьями и хешем по имени. Это означает, что время поиска есть логарифм (причем с большим основанием) от числа файлов. 1.000.000 файлов в этом случае — это всего-то 5-6 чтений блока с диска в худшем случае. Только совсем уж древние ФС не используют эту схему, а используют линейный поиск.

Serginio1 wrote:

> Q>Там используется стандартная схема с Б-деревьями и хешем по имени. Это
> означает, что время поиска есть логарифм (причем с большим основанием)
> от числа файлов. 1.000.000 файлов в этом случае — это всего-то 5-6
> чтений блока с диска в худшем случае. Только совсем уж древние ФС не
> используют эту схему, а используют линейный поиск.
> А по маске типа с ведущим * ???
А что? СУБД будет себя лучше вести?
Говорилось же об обращении по точному имени. В FAT поиск линейный будет в любом случае, в отличие от.

Posted via RSDN NNTP Server 2.0

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

ЗХ>>Теперь немножко законкретизируем это дело. Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные.

IT>Все известные мне почтовые клиенты используют в качестве хранилища базы собственного формата. Т.е. не стандартные БД, а что-то своё, оптимизированное под задачу.

Ммммм...

А так, вот так, и вот так? Ну и вот так еще, до кучи.

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

IT>>Все известные мне почтовые клиенты используют в качестве хранилища базы собственного формата. Т.е. не стандартные БД, а что-то своё, оптимизированное под задачу.

ЗХ>Ммммм...

ЗХ>А так, вот так, и вот так? Ну и вот так еще, до кучи.

Ну так и я о том же. Свой формат хранения, один или несколько файлов. Можно как The Bat! иметь пару файлов на каждую папку, файлы с сообщениями и индексами.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

Не собираясь участвовать в дискуссии по существу (все уже сказали, что стоит), хочу лишь одно отметить — ИМХО высказанные мнения вполне подтверждают правильность идеи MS об интеграции FS и DB.

Один только вопрос — что из этой интеграции получится ? Будем надеяться, что не гибрид ужа с ежом.

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

S>Очень интересно. А тюнить БД и исправлять баги не пробовали?

Все возможные трассировки и просмотр блокировок средствами Enterprise Manager и Profiler мы есстественно проводили.

Собственно, вполне состоятельная версия возникновения блокировок у меня имеется. Блокировки возникают нестабильно, от случая к случаю. К таким ситуациям, IMHO, приводит следующее стечение обстоятельств:

1. В клиентских соединениях кусор используется как UseClient
2. Приложения сохраняют документы не в таблицу постоянного хранения (>12000 записей), а в промежуточную, количество записей в которой поддерживается минимальным (не более 1 записи на одно соединение)
3. 10% клиентов используют медленные соединения
4. Запись BLOB производится не через параметры хранимых процедур, а через наборы записей, открытых как adOpenDynamic

Я конечно не великий спец по сиквелу, но мне кажется что п.1 и п.4 приводят к блокированию целой страницы таблицы. П.2 увеличивает вероятность того, что два соединения будут пытаться одновременно писать в одну страницу, а п.3 "отдает тапки" медленному соединению.

Таким образом, чтобы пофиксить баг надо что-нибудь изменить из перечисленного. К великому сожалению написано 8 клиентских приложений, распространенных по 300 клиентам, а система обновления версий, которую кстати писал я, сбоит (но не по моей вине!). Так что радикально сменить механизм сохранения документов приведет к сбою в работе системы, что недопустимо на текущий момент. Так, кропаю потихоньку.

Применительно к сабжу флейма хочется повториться: чтоб не мучиться надо хранить и там и там. Например, готовясь к смене способа сохранения документов я написал следующие Extended Procedures:

1. Принимает из клиенсткого запроса @IMAGE, сохраняет его в файл, возвращает @FILE_PATH
2. Принимает @FILE_PATH и переменные метаданных — сохраняет BLOB в базе, возвращает @NEW_DOCUMENT_ID
3. Принимает переменные метаданных и @DOCUMENT_ID, проверяет наличие файла на диске, если нет — создает из БД, открывает в MMF — выкидывает в клиентский выходной поток набор записей с метаданными и MMF

К чему вся эта бодяга приведет? В одном из топиков отмечалось, что операции с файлами много быстрее, чем с BLOB, тем паче, имеется возможность поработать с их содержимым, особенно если их формат сложен (в моем случае — файлы Excel). Поэтому пользователи работают с файлами, а не с BLOB-ами. Если файлы пропадут (разрушатся из-за отката транзакции и т.д.) — для пользователей системы это прозрачно, в связи с алгоритмом п.3. Это же справедливо при переносах БД с место на место — про файлы можно просто забыть.

Чего не хватает? Хорошего алгоритма сжатия для фактического хранения в БД и пересылке сжатого файла "медленному" клиенту. Причем такого, чтобы в клиентских приложениях, написанных в на VBA, нетрудно было бы написать декомпрессор. Сжал по Хофману (декомпрессор легкий) — когда рядом WinRAR сжимает документ до 10% — "маловато будет!". Вот, пишу собственный "велосипед", кто бы оторвал от этой фигни, ведь эти компрессоры-насосы-велосипедные-качки спать по ночам не дают...

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

Q>Там используется стандартная схема с Б-деревьями и хешем по имени. Это означает, что время поиска есть логарифм (причем с большим основанием) от числа файлов. 1.000.000 файлов в этом случае — это всего-то 5-6 чтений блока с диска в худшем случае. Только совсем уж древние ФС не используют эту схему, а используют линейный поиск.

Это справедливо только для одной операции -- открытия файла по точно известному имени. Но ведь это не единственная операция. Файлы создаются и удаляются. Причем создаваться и удаляться они могут пачками. А модификация большого индекса (даже в случае с B+ деревьями) может быть не такой уж и дешовой операцией. Особенно при некоторых стечениях обстоятельств (например, если имена файлов будут образовывать монотонно возрастающию ключи).

И еще файловая система не будет работать сама по себе. Работать с файлами будет конкретное приложение и на его работу общее количество файлов в одном каталоге так же может оказывать существенное влияние. Например, не так уж редко выполняется операция glob по какой-то маске, а затем результат сортируется. Например, я собираю все файлы по маске *.processed, сортирую их по времени модификации и удаляю 10% самых старых. Такая операция на каталоге с 1M файлов будет выполняться гораздо медленее, чем на каталоге с 1K файлов. Особенно, если приложение будет написано на Python-е или Ruby.

Я не хочу переводить спор в сторону обсуждения достоинств отдельных файловых систем (мне самому нравится производительность тех же ext3 и reiserfs3 под Linux-ом по сравнению с ntfs5). Это здорово, что reiserfs является надежной и быстрой FS. Но если речь идет о каком-то прикладном софте, то не очень здорово закладываться на то, что он будет хорошо работать на reiserfs4, но будет безбожно тормозить на ntfs, ext2, ufs или где-то еще. Если уж выбирать решение на файлах, то такое, чтобы приемлимая производительность обеспечивалась на любых FS. Тогда и на быстрых FS оно не проиграет.

Зверёк Харьковский,

> Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные. Мое чувство прекрасного почему-то

подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле". <...> Очень ли это глупо?

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

Основные плюсы:

система заведомо более устойчива к разнообразным нарушениям целостности данных

в частности, антивирусы будут "сносить" отдельные сообщения, а не всю базу

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

в частности, desktop search systems будут корректно работать out of the box, безо всякой "умной" с ними интеграции

и т.п.

Основные минусы:

"жрет" больше дискового пространства (кластеры-шмастеры, чтоб им...)

медленнее обрабатывается (например, backup)

и т.п.

Posted via RSDN NNTP Server 2.0

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

PD>Не собираясь участвовать в дискуссии по существу (все уже сказали, что стоит), хочу лишь одно отметить — ИМХО высказанные мнения вполне подтверждают правильность идеи MS об интеграции FS и DB.

PD>Один только вопрос — что из этой интеграции получится ? Будем надеяться, что не гибрид ужа с ежом.

Уже именно это и получилось. Они же за основу взяли реляционку. А хотелось бы некое более объектное хранилище.

ЗЫ. Файлы маст дай.

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

_>Serginio1 wrote:

>> Q>Там используется стандартная схема с Б-деревьями и хешем по имени. Это
>> означает, что время поиска есть логарифм (причем с большим основанием)
>> от числа файлов. 1.000.000 файлов в этом случае — это всего-то 5-6
>> чтений блока с диска в худшем случае. Только совсем уж древние ФС не
>> используют эту схему, а используют линейный поиск.
>> А по маске типа с ведущим * ???
_>А что? СУБД будет себя лучше вести?
_>Говорилось же об обращении по точному имени. В FAT поиск линейный будет в любом случае, в отличие от.
Я не о СУБД. При определенном хранении поиск по маске будет незаметенн в отличие от.
и определяется только скоростью поточного чтения с диска

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

IT>>>Все известные мне почтовые клиенты используют в качестве хранилища базы собственного формата. Т.е. не стандартные БД, а что-то своё, оптимизированное под задачу.

ЗХ>>Ммммм...

ЗХ>>А так, вот так, и вот так? Ну и вот так еще, до кучи.

IT>Ну так и я о том же. Свой формат хранения, один или несколько файлов. Можно как The Bat! иметь пару файлов на каждую папку, файлы с сообщениями и индексами.

Я, собственно, этими ссылками пытался показать, что в *nix-овом окружении, во-первых, форматы стандартны (т.е. не каждый клиент свой формат выдумывает, а есть 2-3 стандарта, а все клиенты их используют); а во-вторых, наиболее распространенный формат — Maildir, который как раз 1 сообщение/файл.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS> А хотелось бы некое более объектное хранилище.
В лес объектные хранилища.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

M>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>> А хотелось бы некое более объектное хранилище.
M>В лес объектные хранилища.
Ну это "Каждому Своё". Опять же как эти объекты интерпритировать. Долой плоское представление, даешь объектное отображение

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

ANS>> А хотелось бы некое более объектное хранилище.
M>В лес объектные хранилища.

Объектные хранилища? В лес?!

Да я! Да за объектные хранилища!! Да ПАВБЫВАВБЫ!!! ObjectStorage Forever

На самом деле при правильном приготовлении очень даже ничего штучка.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Нет, более того, более-менее так устроена "база" сообщений новой, девятой, Оперы.
А Омеа наоборот... Индексы отдельно, вся база в нескольких файлах, работает довольно шусто и стабильно.

ПК>

система заведомо более устойчива к разнообразным нарушениям целостности данных
Вот это непонятно. Как раз тут основные пролемы:
— Запись не атомарна, можно добавить метаданные, а запись конкретного файла с сообщением по каким-то причинам не пройдет.
— Конкретное сообщение грохнется, а метаданные останутся.
Так что с целостностью очевидные проблемы...

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

ANS>> А хотелось бы некое более объектное хранилище.
M>В лес объектные хранилища.

В лес должно уйти наследие 30-летней давности под названием файл, и любые попытки скрестить реляционку с файлами.
О, а что там про Ораклиную InternetFS слышно?

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

eao197 wrote:
> Это справедливо только для одной операции -- открытия файла по точно
> известному имени. Но ведь это не единственная операция. Файлы создаются
> и удаляются. Причем создаваться и удаляться они могут пачками. А
> модификация большого индекса (даже в случае с B+ деревьями) может быть
> не такой уж и дешовой операцией. Особенно при некоторых стечениях
> обстоятельств (например, если имена файлов будут образовывать монотонно
> возрастающию ключи).
Именно для этого в Reiser4 придумали специальную модификацию алгоритма с
B-деревьями — они назвали его "Dancing Trees". По описанию он
откладывает баллансировку дерева до момента когда это необходимо.

По benchmark'ам у них на сайте — вроде совсем неплохо получилось
(массовое создание/удаление у них как раз там есть).

Сегодня потестирую доступ к большому числу файлов

Posted via RSDN NNTP Server 2.0

Merle wrote:
> # ПК> система заведомо более устойчива к разнообразным нарушениям
> целостности данных
> Вот это непонятно. Как раз тут основные пролемы:
> — Запись не атомарна, можно добавить метаданные, а запись конкретного
> файла с сообщением по каким-то причинам не пройдет.
> — Конкретное сообщение грохнется, а метаданные останутся.
> Так что с целостностью очевидные проблемы...
Вы все еще считаете, что все файловые системы заканчиваются FAT и NTFS?

Давным-давно есть атомарные FS с гарантированой целостностью, а в
Reiser4 атомарность умудрились сделать еще и без потери скорости.

Posted via RSDN NNTP Server 2.0

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

E>На самом деле при правильном приготовлении очень даже ничего штучка.
Я просто к тому, что совершенно непонятны страдания Andrei N.Sobchuck по этому поводу..

Очевидно, что объектный API там будет, а что там внизу лежит — дело десятое.

Вот, кстати, по поводу "А они за основу взяли реляционку

" мой любимый пример. В 2005м сиквеле ребята решили реализовать поддержку XML и XQuery. Запарились они в серьез, структура иерархическая (к слову, как и объекты) значит, наверное, хранить их надо как-то по другому? Они угрохали несколько лет на исследования как же лучше с этим делом работать, R-tree, Quadtree и прочая экзотика рассматривалась со всей тщательностью... В итоге угадайте к чему они пришли? Правильно, xml преобразуется в реляционную таблицу с помощю Ordpath (что-то вроде Nested sets, но не обладающее фатальным недостатком), индексируется B+ Tree и запросы по этому делу гоняет реляционный движек.. Так оказалось лучше всего, и это при том, что Storage Engine-ам современных БД абсолютно пофигу что хранить, им не важно реляционные данныые там или нет.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

C>Вы все еще считаете, что все файловые системы заканчиваются FAT и NTFS?
Вы уже считаете, что с NTFS никто не работает?
И вообще, Вы все еще не научились читать сообщения полностью? Здесь никакая, даже самая замечательная ФС не спасет. Принципиально предполагается запись в два разных источника данных и надо как-то согласовывать их между собой. И каким бы замечательным один источник данных не был, e. g. зашибенская ФС, которая умеет кофе по утрам готовить, все равно есть вероятность, что другий источник в тапочки написает.

C>Давным-давно есть атомарные FS с гарантированой целостностью, а в
C>Reiser4 атомарность умудрились сделать еще и без потери скорости.
Еще раз. Эти замечательные FS скопируют мне атомарно два разных файла? Они обеспечат мне атомарность записи и в файл, и в БД? И все конфликты при этой записи разрулят?
Чудес не бывает. Даже между двумя БД грамотно разрулить распределенную транзакцию — проблема, а тут транзакцию между БД и ФС, а у ФС заведомо меньше информации о структуре данных.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

C>Давным-давно есть атомарные FS с гарантированой целостностью, а в
C>Reiser4 атомарность умудрились сделать еще и без потери скорости.

Кстати, ты можешь показать в описании Reiser4, где говорится, что Reiser4 поддерживает атомарность для нескольких изменений нескольких файлов сразу (т.е. чтобы изменение нескольких файлов составляло одну транзакцию)?

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

E>>Это справедливо только для одной операции -- открытия файла по точно известному имени. Но ведь это не единственная операция. Файлы создаются и удаляются. Причем создаваться и удаляться они могут пачками. А модификация большого индекса (даже в случае с B+ деревьями) может быть не такой уж и дешовой операцией. Особенно при некоторых стечениях обстоятельств (например, если имена файлов будут образовывать монотонно возрастающию ключи).

S>Это почему???

Что именно "почему"?

Частые ребалансировки B+ дерева, имхо, это не дешевая операция (расчепления и объединения страниц).

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

C>eao197 wrote:
>> Это справедливо только для одной операции -- открытия файла по точно
>> известному имени. Но ведь это не единственная операция. Файлы создаются
>> и удаляются. Причем создаваться и удаляться они могут пачками. А
>> модификация большого индекса (даже в случае с B+ деревьями) может быть
>> не такой уж и дешовой операцией. Особенно при некоторых стечениях
>> обстоятельств (например, если имена файлов будут образовывать монотонно
>> возрастающию ключи).
C>Именно для этого в Reiser4 придумали специальную модификацию алгоритма с
C>B-деревьями — они назвали его "Dancing Trees". По описанию он
C>откладывает баллансировку дерева до момента когда это необходимо.

C>По benchmark'ам у них на сайте — вроде совсем неплохо получилось
C>(массовое создание/удаление у них как раз там есть).

C>Сегодня потестирую доступ к большому числу файлов

Так или иначе это танцы вокруг БД. Оптимизация хранения , транзакции, откаты, версионность, блокировочники ...
А как это уже называть

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

E>Это справедливо только для одной операции -- открытия файла по точно известному имени. Но ведь это не единственная операция. Файлы создаются и удаляются. Причем создаваться и удаляться они могут пачками. А модификация большого индекса (даже в случае с B+ деревьями) может быть не такой уж и дешовой операцией. Особенно при некоторых стечениях обстоятельств (например, если имена файлов будут образовывать монотонно возрастающию ключи).

Я не пойму, вы что пытаетесь доказать? Что создатели ФС идиоты, неспособные догадаться о таких элементарных вещах?

E>И еще файловая система не будет работать сама по себе. Работать с файлами будет конкретное приложение и на его работу общее количество файлов в одном каталоге так же может оказывать существенное влияние. Например, не так уж редко выполняется операция glob по какой-то маске, а затем результат сортируется. Например, я собираю все файлы по маске *.processed, сортирую их по времени модификации и удаляю 10% самых старых. Такая операция на каталоге с 1M файлов будет выполняться гораздо медленее, чем на каталоге с 1K файлов. Особенно, если приложение будет написано на Python-е или Ruby.

Опять же, объясните пожалуйста, с чего поиск по произвольной маске должен работать одинаково быстро на любом количестве файлов. Приведите алгоритм, который позволял бы такое делать и при этом давал бы не более O(log N) на добавление и удаление.

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

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

E>>>Это справедливо только для одной операции -- открытия файла по точно известному имени. Но ведь это не единственная операция. Файлы создаются и удаляются. Причем создаваться и удаляться они могут пачками. А модификация большого индекса (даже в случае с B+ деревьями) может быть не такой уж и дешовой операцией. Особенно при некоторых стечениях обстоятельств (например, если имена файлов будут образовывать монотонно возрастающию ключи).

S>>Это почему???

E>Что именно "почему"?

E>Частые ребалансировки B+ дерева, имхо, это не дешевая операция (расчепления и объединения страниц).
Как на это влияет (монотонно возрастающию ключи) ????
Все зависит от средней наполняемости выставленной разработчиком. Чем она выше тем выше скорость поиска, и ниже вставки (удаления). Монотонно возрастающие не влияют на количество балансировок.

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

Q>Я не пойму, вы что пытаетесь доказать? Что создатели ФС идиоты, неспособные догадаться о таких элементарных вещах?

Я ничего не доказываю. Я просто сомневаюсь в том, что работа в каталоге с сотнями тысяч (миллионами) файлов будет столь же быстрой, как в каталоге с тысячами (не более 10 тысяч). Причем не на единичной операции, а на сериях операций (создание файла, чтение, перезапись, удаление файла).

Q>Опять же, объясните пожалуйста, с чего поиск по произвольной маске должен работать одинаково быстро на любом количестве файлов. Приведите алгоритм, который позволял бы такое делать и при этом давал бы не более O(log N) на добавление и удаление.

Я думаю, здесь случилось недопонимание. Я не говорил о скорости выборки файлов по маске на уровне файловой системы. Я говорил о том, что если какой-нибудь Ruby скрипт будет загружать в память и сортировать имена 10000 файлов, то это будет гораздо быстрее, чем загружать в память и сортировать имена 1M файлов. Хотя бы просто из-за количества объектов, которые придется создать в Ruby скрипте.

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

E>>Частые ребалансировки B+ дерева, имхо, это не дешевая операция (расчепления и объединения страниц).
S>Как на это влияет (монотонно возрастающию ключи) ????
S> Все зависит от средней наполняемости выставленной разработчиком. Чем она выше тем выше скорость поиска, и ниже вставки (удаления). Монотонно возрастающие не влияют на количество балансировок.

Разве?
Я думал, что для деревьев самым плохим сценарием является постоянный рост в одну сторону. Ведь тогда нужно постоянно делать перебалансировку дерева, чтобы дерево оставалось сбалансированным.
В случае B+ деревьев, как мне кажется, монотонно возрастающие ключи будут приводить к тому, что последняя листовая страница будет быстро заполняться, что потребует заполнять ее родительскую страницу и т.д. В результате дерево будет постоянно увеличиваться в своей глубине при том, что ранее выделенные листовые страницы не изменяются. Хотя количество перебалансировок будет гораздо меньше, чем с бинарными деревьями (за счет большего количества ключей на странице), но все равно перебалансировки будут.

Но вполне могу и заблуждаться. Настаивать не буду.

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

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

E>>>Частые ребалансировки B+ дерева, имхо, это не дешевая операция (расчепления и объединения страниц).
S>>Как на это влияет (монотонно возрастающию ключи) ????
S>> Все зависит от средней наполняемости выставленной разработчиком. Чем она выше тем выше скорость поиска, и ниже вставки (удаления). Монотонно возрастающие не влияют на количество балансировок.

E>Разве?
E>Я думал, что для деревьев самым плохим сценарием является постоянный рост в одну сторону. Ведь тогда нужно постоянно делать перебалансировку дерева, чтобы дерево оставалось сбалансированным.
E>В случае B+ деревьев, как мне кажется, монотонно возрастающие ключи будут приводить к тому, что последняя листовая страница будет быстро заполняться, что потребует заполнять ее родительскую страницу и т.д. В результате дерево будет постоянно увеличиваться в своей глубине при том, что ранее выделенные листовые страницы не изменяются. Хотя количество перебалансировок будет гораздо меньше, чем с бинарными деревьями (за счет большего количества ключей на странице), но все равно перебалансировки будут.

На количество перебалансировок это влиять не будет (их будет даже меньше в зависимости от тактики хранения), да не забудем о кэшировании страниц, что для ФС лимитирующей стадией

E>Но вполне могу и заблуждаться. Настаивать не буду.

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

M>Я просто к тому, что совершенно непонятны страдания Andrei N.Sobchuck по этому поводу..

M>Очевидно, что объектный API там будет, а что там внизу лежит — дело десятое.

Так если б так было, а то ж "уши" торчат с низу на верх.

M>Вот, кстати, по поводу "А они за основу взяли реляционку

" мой любимый пример. В 2005м сиквеле ребята решили реализовать поддержку XML и XQuery.

XML вроде ж дерево, значения — строки. Имхо, это не катит на "хранилище объектов". Возможно это и объясняет тот факт, что каждый производитель БД, делает поддержку XML просто пользуясь своим хранилищем. От Berkley DB до всяких SQL серверов. Кроме того, у них наверняка стоял вопрос интеграции со всем остальным хозяйством, например оптимизатором.

Кстати, от ссылочки на детали я бы не отказался, а то инфа с 2004 года наверняка устарела:

Хранение XML-типа

Мне было очень интересно узнать, каким образом SQL Server хранит XML-тип. К сожалению, в документации об этом нет ни слова, и вряд ли положение изменится к публичной бете. Вот что я выяснил из собственных экспериментов и общения с разработчиками.

XML-тип сохраняется как большой объект (lob — large object) в бинарном формате, структура которого неизвестна, но точно можно сказать, что она линейна. Т.е. сохраняется относительный порядок узлов в документе – атрибуты следуют после элемента, к которому они принадлежат, дочерние элементы следуют после атрибутов, и последующие элементы (элементы того же уровня) – после дочерних элементов.

Для осуществления запроса XQuery SQL Server каждый раз выполняет преобразование этой линейной структуры в реляционную – в таблицу узлов (node table). Таблица узлов более формализована и понятна, однако занимает в несколько раз (даже на порядки) больше места. Любой запрос XQuery трансформируется в SQL запрос к этой таблице.

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

eao197 wrote:
> C>Давным-давно есть атомарные FS с гарантированой целостностью, а в
> C>Reiser4 атомарность умудрились сделать еще и без потери скорости.
> Кстати, ты можешь показать в описании Reiser4, где говорится, что
> Reiser4 поддерживает атомарность для нескольких изменений нескольких
> файлов сразу (т.е. чтобы изменение нескольких файлов составляло одну
> транзакцию)?
Где-то видел пост в список рассылки, где об этом говорилось, но найти не
могу. Там создавался временный namespace, в который помещались файлы,
при коммите этот неймспейс удалялся, так что все записывалось атомарно.

Более точно сейчас не вспомню.

Posted via RSDN NNTP Server 2.0

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

ЗХ>Я, собственно, этими ссылками пытался показать, что в *nix-овом окружении, во-первых, форматы стандартны (т.е. не каждый клиент свой формат выдумывает, а есть 2-3 стандарта, а все клиенты их используют); а во-вторых, наиболее распространенный формат — Maildir, который как раз 1 сообщение/файл.

Я в юниксах не силён. Может там файловая система другая. С большим количеством файлов в одном каталоге в винде похоже проблема связана с процессом обновления времени последнего доступа к файлам. Т.е. каким-то образом, может быть из-за криво написанного софта, система обновляла время последнего доступа у всех 100к файлов при любом изменении в каталоге. Сервер от этого умирал. Вроде это можно как-то отключить на уровне операционки, но это не твой случай. В общем, с вариантом одно сообщение — один файл я бы сначала поэкспериментировал прежде чем его принимать.

... << RSDN@Home 1.2.0 alpha rev. 0>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Так если б так было, а то ж "уши" торчат с низу на верх.
Откуда они там торчат?

ANS>XML вроде ж дерево, значения — строки. Имхо, это не катит на "хранилище объектов".
А что катит? Просто объекты тоже дерево, поэтому с xml-ем у них много общего, больше чем с реляционными данными.
И данный пример как раз показывает, что у реляционки с просто хранением и выборкой иерархических данных проблем нет. А большего от данного движка и не требуется. Так что поводов огорчаться из-за наличия внизу реляционного движка нету, скорее радоваться надо, что стоит отлаженный и проверенный временем механизм...

ANS> Возможно это и объясняет тот факт, что каждый производитель БД, делает поддержку XML просто пользуясь своим хранилищем.
Ресурсы MS вполне позволили бы создать совершенно самостоятельный движек для работы с XML-ем если бы это оказалось заметно эффективнее, сначала они так и собирались делать иначе бы не копали в сторону иерархических хранилищ...

ANS>Кстати, от ссылочки на детали я бы не отказался
ORDPATHs: Insert-Friendly XML Node Labels

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

E>Я думал, что для деревьев самым плохим сценарием является постоянный рост в одну сторону.
Не для всех..

E>Ведь тогда нужно постоянно делать перебалансировку дерева, чтобы дерево оставалось сбалансированным.
B+ всегда сбалансировано, у них проблема с расщеплением страниц при росте, но тут есть алгоритмы наработанные десятилетиями.

E>В случае B+ деревьев, как мне кажется, монотонно возрастающие ключи будут приводить к тому, что последняя листовая страница будет быстро заполняться, что потребует заполнять ее родительскую страницу и т.д.
Ни к чему страшному это не приведет, B+ растет не вниз, а вверх, поэтому перебалансировки не происходит. Более того, если дерево "знает", что вставка монотонна, то и расщепления страниц можно избежать, так что в некоторых случаях рост в одну сторону выгоднее.
Иными словами, сама по себе монотонная вставка B+ не страшна, но тут есть другая проблема, если вставка происходит из нескольких параллельных потоков, то последняя страница оказывается перманентно заблокированной и возникает очередь на вставку. И вот это уже может серьезно повлиять на эффективность вставки, если критична именно вставка из параллельных потоков.
Но это все высокие материи, не думаю что ФС столкнется с подобными сценариями, все-таки на данный момент СУБД и ФС решают несколько разные задачи.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>Т.е. каким-то образом, может быть из-за криво написанного софта, система обновляла время последнего доступа у всех 100к файлов при любом изменении в каталоге. Сервер от этого умирал.

??? Почему должно минятся время доступа у файлов при изменении в каталоге (создание, удаление файлов?)?

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Конечно всегда сбалансированно, ведь это достигается путем расщепления и слияния страниц в нужные моменты времени. Об этом я и говорил.

E> но тут есть алгоритмы наработанные десятилетиями.

Какие? (Не сарказм, действительно интересно).

E>>В случае B+ деревьев, как мне кажется, монотонно возрастающие ключи будут приводить к тому, что последняя листовая страница будет быстро заполняться, что потребует заполнять ее родительскую страницу и т.д.
M>Ни к чему страшному это не приведет, B+ растет не вниз, а вверх, поэтому перебалансировки не происходит. Более того, если дерево "знает", что вставка монотонна, то и расщепления страниц можно избежать, так что в некоторых случаях рост в одну сторону выгоднее.

Можно ли на эту тему подробнее?

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

E>Какие? (Не сарказм, действительно интересно).
В данном случае предельно простые..

Страница при переполнении разбивается примерно на 2/3 и треть переносится на новую.
Просто поинт в том, что содной стороны расщепление страниц в B+ это действительно одно из самых узких мест, но с другой это узкое место вылизывали десятилетиями, потому как в реляционках это основной механизм.

E>Можно ли на эту тему подробнее?
При переполнении страница расщепляется на две неравные части, при этом меньшая часть переносится на вновь созданную страницу. Таким образом на старой странице создается некоторый запас свободного места для последующих вставок, чтобы небыло необходимости расщиплять страницу при каждой вставке в середину.
Но, если, например, поле в БД автоинкрементное, то можно гарантировать, что каждое следующее значение будет больше/меньше предыдущего, а значит вставки в середину страницы не будет, а значит и разбивать страницу не надо, нет необходимости резервировать пустое место для вставки в середину, так как вероятность этого крайне мала. При переполнении просто создается новая страница и данные пишутся туда, а старая страница остается заполненой на 100% (к слову это еще и эффективность выборки увеличивает).
При этом если все-таки происходит вставка в середину, ничто не мешает таки расщепить страницу по стандартным правилам, так что тут все упирается в способность пишущего движка распознать инкрементную вставку.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

M>Просто поинт в том, что содной стороны расщепление страниц в B+ это действительно одно из самых узких мест

По-моему, сщепление на порядок уже

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>??? Почему должно минятся время доступа у файлов при изменении в каталоге (создание, удаление файлов?)?

Я не знаю

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

IT>По-моему, сщепление на порядок уже

В смысле дефрагментация? Ну она зато существенно реже и не так актуально делать ее прям щас.

... << RSDN@Home 1.2.0 alpha rev. 0>>

Merle,

> ПК> система заведомо более устойчива к разнообразным нарушениям целостности данных

> Вот это непонятно. Как раз тут основные пролемы:
> — Запись не атомарна, можно добавить метаданные, а запись конкретного файла с сообщением по каким-то причинам не пройдет.

Если критичные для работы метаданные (индексы и т.п.) могут быть восстановлены из самих файлов (что по большей части имеет место быть в случае e-mail), то эта проблема не существенна. Я говорил немного о других проблемах, когда нарушается целостность файлов с данными: вирусы/антивирусы, аппаратные и программные сбои и т.п. Последнее на практике имеет заметно большее значение.

> — Конкретное сообщение грохнется, а метаданные останутся.

Это легко диагностируемые и поправимые нарушения, в отличие от "битых" файлов баз данных.

Posted via RSDN NNTP Server 2.0

VD>Дык зависит от задачи. И терминалогии. Напиример, исходники в БД хранить явно неразумно. Тут лучше подойдут файлы и сорс-контрол. А финансовую информацию логично хранить в БД, так как ее при этом проще анализировать.

Насколько я понимаю VSS для 2005 студии хранит исходники как раз в SQL Server

IT,

> С большим количеством файлов в одном каталоге в винде похоже проблема связана с процессом обновления времени последнего доступа к файлам.

Один файл на каждое собщение вовсе не означает, что все файлы будут "свалены" в одном каталоге. Скажем, та же Опера хранит сообщения в следующей иерархии: account/year/month/day/messageid.mbs Раньше было так: account/year-month.mbs

Posted via RSDN NNTP Server 2.0

Здравствуйте, Павел Кузнецов, Вы писали:

ПК> Я говорил немного о других проблемах, когда нарушается целостность файлов с данными: вирусы/антивирусы, аппаратные и программные сбои и т.п. Последнее на практике имеет заметно большее значение.
Ну, вот как раз практика борьбы с такими проблемами, в БД вырабатывалась годами... Online бакапы, стандартные процедуры восстановления, определение сбоя, контроль целостности. Все это уже написано и работает, а на ФС придется либо писать самому, либо забить и тогда есть вероятность потерять файл.

ПК>Это легко диагностируемые и поправимые нарушения, в отличие от "битых" файлов баз данных.
Хм. Как раз битый файл в БД и диагностируется и восстанавливается, причем процедура совершенно стандартная, а вот битый файл просто в ФС скорее всего окажется утерянным навсегда. Другое дело, если по условиям задачи его не жалко и все навороты БД не нужны... Но если надежность все же необходима, то БД тут заведомо надежнее.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

ANS>>Так если б так было, а то ж "уши" торчат с низу на верх.
M>Откуда они там торчат?

Торчат из "реляционки", а проявляется это в модели данных WinFS, а именно ScalarType, NestedType, Relationship. Думаю всё это до боли знакомо людям использовавшим ORM.
Может его уже как-то и причесали, потому что старые примеры удручают:

  // Add first person to the household
  HouseholdMemberData hhmd = new HouseholdMemberData (ctx);
  hhmd.Name = p1.DisplayName;
  hhmd.Target_Key = p1.ItemID_Key;
  h.HouseholdMembers.Add (hhmd);

  // Add second person to the household
  hhmd = new HouseholdMemberData (ctx);
  hhmd.Name = p2.DisplayName;
  hhmd.Target_Key = p2.ItemID_Key;
  h.HouseholdMembers.Add (hhmd);

Тьфу.

ANS>>XML вроде ж дерево, значения — строки. Имхо, это не катит на "хранилище объектов".
M>А что катит? Просто объекты тоже дерево, поэтому с xml-ем у них много общего, больше чем с реляционными данными.

Ну, всё же не дерево, а граф с циклами. Второй момент — в "объектах" значениями м.б. не только строки.

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

Если представить, что значениями м.б. не только строки, но еще и числа, это уже потребует либо усложнения схемы хранения, либо доработок движка.

ANS>> Возможно это и объясняет тот факт, что каждый производитель БД, делает поддержку XML просто пользуясь своим хранилищем.
M>Ресурсы MS вполне позволили бы создать совершенно самостоятельный движек для работы с XML-ем если бы это оказалось заметно эффективнее, сначала они так и собирались делать иначе бы не копали в сторону иерархических хранилищ...

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

, а вот прозрачно и с минимальным оверхедом интегрировать его... Так что далеко не факт, что такое решение приняли из-за его идеальности.

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Merle,

> ПК> Я говорил немного о других проблемах, когда нарушается целостность файлов с данными: вирусы/антивирусы, аппаратные и программные сбои и т.п. Последнее на практике имеет заметно большее значение.

> Ну, вот как раз практика борьбы с такими проблемами, в БД вырабатывалась годами... Online бакапы <...>

Backups и журналирование в данной задаче можно не рассматривать: очевидно, что простой пользователь почтовой программы не будет ее администрировать с тем же тщанием, что администратор БД.

> ПК> Это легко диагностируемые и поправимые нарушения, в отличие от "битых" файлов баз данных.

> Хм. Как раз битый файл в БД и диагностируется и восстанавливается <...>

И тем не менее, периодически базы "умирают насмерть", и тогда приходится восстанавливать их из backup.

> битый файл просто в ФС скорее всего окажется утерянным навсегда. Другое дело, если по условиям задачи его не жалко

Его меньше жалко, чем всю базу.

> если надежность все же необходима, то БД тут заведомо надежнее.

Один контрпример: антивирус, удаляющий файл с вирусом. В случае БД он "снесет" всю базу.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Backups и журналирование в данной задаче можно не рассматривать: очевидно, что простой пользователь почтовой программы не будет ее администрировать с тем же тщанием, что администратор БД.
Ну вот тут как раз неясность в задаче, так и не понятно что же Зверек пишет, то ли клиента то ли сервер..

В случае клиента и файл потерять не жалко и навороты БД не нужны, а в случае сервера, как раз наоборот.

ПК>И тем не менее, периодически базы "умирают насмерть", и тогда приходится восстанавливать их из backup.
Но в случае БД есть готовый механизм который этим занимается и стандартные процедуры... А вслучае файла — он оказывается безвовратно утерян.

ПК>Его меньше жалко, чем всю базу.
Вся база восстанавливается, а файл нет. Другое дело, что для восстановления надо ручками шевелить, но это уже другой вопрос.

ПК>Один контрпример: антивирус, удаляющий файл с вирусом. В случае БД он "снесет" всю базу.
В случае БД он просто доступа к базе не получит. А если получит и снесет, то базу можно восстановить.

... [RSDN@Home 1.2.0 alpha rev. 619]

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Торчат из "реляционки", а проявляется это в модели данных WinFS, а именно ScalarType, NestedType, Relationship. Думаю всё это до боли знакомо людям использовавшим ORM.
Да вот как-то не очень это похоже на реляционку. Для реляционки достаточно потребовать реализации определенного интерфейса, сериализации, атрибута или, в крайнем случае, наследования от какого-нибудь базового объекта, что и наблюдается в большинстве существующих ORM.
А тут какие-то нарошные контейнеры...
Впрочем, они одно время пытались ObjectSpaces вкрячить, но потом вроде передумали, так что в каком виде это сейчас — можно только гадать.

ANS>Тьфу.
А как бы это сделал ты? Подвох в том, что для широого класса задач ни одна из существующих ООБД как-то не катит. А тут класс задач сверхширокий, ФС при работе должна нагибаться по всякому, желательно одинаково эффективно, ну покрайней мере с разбросом в разумных пределах, а вот у ООБД с этим бедулька.

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

ANS>Второй момент — в "объектах" значениями м.б. не только строки.
И что? Тоже не бином ньютона.

ANS>Если представить, что значениями м.б. не только строки, но еще и числа, это уже потребует либо усложнения схемы хранения, либо доработок движка.
Какого усложнения? Там все просто как рельс, и на тип хранимых данных не завязано вообще.

ANS>Во-первых, тут уже приводились аргументы за то, что у МС не хватает ресурсов на исполнение всех данных обещаний.
Они ничего не обещали, они делали. По слухам, около восьми лет, но это по слухам, так что могу и наврать... И по честному искали разные способы.

ANS> Во-вторых, написать самостоятельный движок и я могу

,
Ну, за язык тебя никто не тянул..

Сможешь написать такой самостоятельный движек, чтобы он был эффективнее MS-овского?

ANS> а вот прозрачно и с минимальным оверхедом интегрировать его...
Они там много чего совсем не реляционного довольно прозрачно интегрировали, включая поддержку .Net. К тому же еще раз повторюсь, собственно самой подсистеме хранения практически все равно что хранить. Аналогичная подсистема хранения используется в NTFS, Lotus и еще куче других конструкций, в том числе и объектных, и особых проблем не испытывает...

... [RSDN@Home 1.2.0 alpha rev. 619]

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

VD>Дык зависит от задачи. И терминалогии. Напиример, исходники в БД хранить явно неразумно. Тут лучше подойдут файлы и сорс-контрол.

При этом существует не так уж и много сурс-контролов которые действительно хранят данные в файловой системе.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Один файл на каждое собщение вовсе не означает, что все файлы будут "свалены" в одном каталоге. Скажем, та же Опера хранит сообщения в следующей иерархии: account/year/month/day/messageid.mbs Раньше было так: account/year-month.mbs

Тоже вариант.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>>По-моему, сщепление на порядок уже

M>В смысле дефрагментация? Ну она зато существенно реже и не так актуально делать ее прям щас.

Нет. Расщепление страниц по сравнению с удалением записи и последующей балансировкой страниц — это детский сад.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

M>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>Торчат из "реляционки", а проявляется это в модели данных WinFS, а именно ScalarType, NestedType, Relationship. Думаю всё это до боли знакомо людям использовавшим ORM.
M>Да вот как-то не очень это похоже на реляционку. Для реляционки достаточно потребовать реализации определенного интерфейса, сериализации, атрибута или, в крайнем случае, наследования от какого-нибудь базового объекта, что и наблюдается в большинстве существующих ORM.

Как по мне, то всё это вытекает из особенностей РСУБД.

ANS>>Тьфу.
M>А как бы это сделал ты?

Как минимум убрал бы явную(!) работу с ключом. Там есть и еще один интересный момент:

hhmd.Name = p1.DisplayName;
hhmd.Target_Key = p1.ItemID_Key;

Первое, что произойдёт при изменении p1.DisplayName? Второе, если даже оно там само будет обновлятся, всё равно ad-hoc поиск идёт лесом.

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

Пример можно? С учетом того, что задача не сохранять, а выполнять ad-hoc поиск.

ANS>>Второй момент — в "объектах" значениями м.б. не только строки.
M>И что? Тоже не бином ньютона.

Пример можно? С учетом того, что задача не сохранять, а выполнять ad-hoc поиск.

ANS>>Если представить, что значениями м.б. не только строки, но еще и числа, это уже потребует либо усложнения схемы хранения, либо доработок движка.
M>Какого усложнения? Там все просто как рельс, и на тип хранимых данных не завязано вообще.

Не буду повторятся. См.выше

ANS>>Во-первых, тут уже приводились аргументы за то, что у МС не хватает ресурсов на исполнение всех данных обещаний.
M>Они ничего не обещали, они делали. По слухам, около восьми лет, но это по слухам, так что могу и наврать... И по честному искали разные способы.

Хмм. В куче статей люди пишут, что некую ООФС анонсировали еще для NT. Но даже если это не считать за обещание, то на в msdn куча дописок:

UPDATE: In spite of what may be stated in this content, "WinFS" is not a feature that will come with the Longhorn Operating System. However, "WinFS" will be available on the Windows platform at some future date, which is why this article continues to be provided for your information.

Таки что-то кому-то обещали.

ANS>> Во-вторых, написать самостоятельный движок и я могу

,
M>Ну, за язык тебя никто не тянул..

Сможешь написать такой самостоятельный движек, чтобы он был эффективнее MS-овского?

Ай. Да, кому нужна эта эффективность? Павлу Дворкину?

Совместимость!

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Как по мне, то всё это вытекает из особенностей РСУБД.
А вот по мне так не очень, особенно с оглядкой на существующие ORM.

ANS>Как минимум убрал бы явную(!) работу с ключом.
А как ты еще объект идентифицировать будешь? Я так понимаю что это не сколько ключ, сколько ID объекта, самый что ни на есть объектный подход.

ANS> Второе, если даже оно там само будет обновлятся, всё равно ad-hoc поиск идёт лесом.
Почему? И зачем там чему-то самому обновляться?

ANS>Пример можно?
Пример чего? Сериализации? А как по твоему хранятся .Net типы в SQL? И ищутся, кстати, тоже.

ANS> С учетом того, что задача не сохранять, а выполнять ad-hoc поиск.
И какая проблема с поиском? И заодно покажи мне существующую объектную систему, которая умеет делать то что ты хочешь.

ANS>Пример можно?
Пример чего?

ANS> С учетом того, что задача не сохранять, а выполнять ad-hoc поиск.
Почитай описание алгоритма, я уже писал, он не зависит от типа хранимых данных, вообще. Ну нету там этой зависимости.

ANS>Не буду повторятся. См.выше

Сам смотри..

ANS>Хмм. В куче статей люди пишут, что некую ООФС анонсировали еще для NT.
...
ANS>Таки что-то кому-то обещали.
Я не про ООФС, я про движек хранения XML, там никому ничего не обещали, просто делали.

ANS>Ай. Да, кому нужна эта эффективность?
Ага, сломался.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

Т.е. дерево не сбалансированное?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

M>>Более того, если в транзакции произошла вставка приведшая к расщеплению страниц, но транзакция до коммита не дожила и была отменена, то страница так и останется расщепленой после rollback-а, никто это дело в исходное состояние приводить не будет.
IT>Т.е. дерево не сбалансированное?
А ему и не надо быть идеально сбалансированным. Дереву достоточно иметь состояние близкое к сбалансированному ибо на производительность это практически не влияет.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

IT>Т.е. дерево не сбалансированное?
Обычно под балансировкой понимается разность в высоте веток дерева. В этом смысле B+ сбалансировано всегда, так как оно растет вверх и разности в высоте веток просто не возникает. И наличие пустого места на страницах или даже пустых страниц на балансировку не влияет, при поиске любой конкретной записи, будет поднято всегда одинаковое количество страниц равное высоте дерева (здесь я не рассматриваю случай Range Scan).
А вот "в ширь", на одном уровне, оно может быть фрагментированным, то есть иметь не до конца заполненные страницы или вообще пустые.
При этом есть ситуации, когда дефрагментация здорово повышает производительность, но они очень редки и поэтому непосредственно во время модификации данных об этом, как правило, не заботятся, а просто дают возможность провизвести эту процедуру по запросу или по расписанию.
При этом, как правило, фрагментация критичнее всего на листьевом уровне, и вот его дефрагментация как раз обходится довольно дешево. Помнится еще Тенгиз рассказывал, что когда они запускали дефрагментацию во время выполнения tpc-c теста, то она отожрала всего 5% производительности.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

ANS>>Как по мне, то всё это вытекает из особенностей РСУБД.
M>А вот по мне так не очень, особенно с оглядкой на существующие ORM.

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

ANS>>Пример можно?
M>Пример чего? Сериализации? А как по твоему хранятся .Net типы в SQL? И ищутся, кстати, тоже.

Пойдём по шагам. Начнём с простейшего: пример хранения графа с циклами при помощи ordpath.

M>Я не про ООФС, я про движек хранения XML, там никому ничего не обещали, просто делали.

Попробовали б они не сделать, когда маркетологи говорят "надо".

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>При этом, как правило, фрагментация критичнее всего на листьевом уровне,

А данные хранятся только на листьевом уровне?

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

M>>При этом, как правило, фрагментация критичнее всего на листьевом уровне,

IT>А данные хранятся только на листьевом уровне?

В B+ деревьях только на листьевом уровне.
Причем применительно к БД на листьевом уровне размещают не сами данные, а указатели на расположение данных (т.е. листья хранят пары <ключ, указатель>).

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

_>Насколько я понимаю VSS для 2005 студии хранит исходники как раз в SQL Server

Нет. VSS остался тем же самым. Появилась Team System, но это килобаксы.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

ВВ>При этом существует не так уж и много сурс-контролов которые действительно хранят данные в файловой системе.

И все в основном из серии CVS/SVN. Так что сдается мне что по большому счету совершенно фиолетово где исходники хранить, если работа с ними идет не напрямую, а посредством некоторого "тула".

Как раз наоборот. Хотя тут можно пофилосовствовать, что сорсконтролы создают свою БД (т.е. велосипедствуют).

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

IT>А данные хранятся только на листьевом уровне?
Да. Данные или ссылки на данные хранятся только на листьевом уровне.

... [RSDN@Home 1.2.0 alpha rev. 619]

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Ээ. ScalarType — тип поддерживаемый нижележащей СУБД. NestedType — один-ко-многим. Relations — таблица требуемая для многих-ко-многим.
Это только напоминает реляционку. Как видно на примере ORM для реляционки таких приседаний не надо.
А вот если бы пришлось придумывать систему умеющую хранить произвольные наборы объектов, то боюсь получилось бы нечто похожее.
Вообще, главное чтобы был SQL-ный доступ ко всему этому хозяйству, а уж правильную работу с этим как с объектами, под конкретную задачу можно и самому написать.

ANS>Пойдём по шагам. Начнём с простейшего: пример хранения графа с циклами при помощи ordpath.
Потребую от графа умения сериализоваться и десериализоваться в xml, сведя тем самым задачу к известной.

ANS>Попробовали б они не сделать, когда маркетологи говорят "надо".

Уж посылать в лес маркетологов они умеют изумительно.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

IT>>А данные хранятся только на листьевом уровне?
M>Да. Данные или ссылки на данные хранятся только на листьевом уровне.

А каков глубокий смысл?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>А каков глубокий смысл?
Совсем глубокого смысла не знаю, надо в Кнута заглинуть или хотя бы в Ульмана...
Но помнится смысл в том, что это дает возможность связать все эелементы на листьевом уровне друг с другом в список (собственно по этому они и B+, + как раз означает что все элементы на листьях образуют направленый список), что позволяет:
1. Эффективно работать с групповыми выборками и различными Range Scan-ами, типа "верни мне все записи с 5-ой по 25-ю". Не надо проходить дерево сверху вниз за каждой записью, достаточно найти 5-ю и просканировать подряд, по ссылочкам все записи до 25-й.
2. Реализовать эффективный механизм предикатных блокировок.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

M>Совсем глубокого смысла не знаю, надо в Кнута заглинуть или хотя бы в Ульмана...
+1

M>Но помнится смысл в том, что это дает возможность связать все эелементы на листьевом уровне друг с другом в список (собственно по этому они и B+, + как раз означает что все элементы на листьях образуют направленый список), что позволяет:
M>1. Эффективно работать с групповыми выборками и различными Range Scan-ами, типа "верни мне все записи с 5-ой по 25-ю". Не надо проходить дерево сверху вниз за каждой записью, достаточно найти 5-ю и просканировать подряд, по ссылочкам все записи до 25-й.

+1
Здесь еще нужно добавить, что в B+ деревьях листовые страницы могут провязываться в двухсвязный список (т.е. у каждой листовой страницы есть ссылки на левую и правую соседние листовые страницы). Это позволяет при выборке по условию (a < x < b) перебирать все x на нескольких листовых страницах не поднимаясь вверх.

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

И еще родительские страницы можно хранить отдельно от листовых страниц. Т.е., теоритически, родительские страницы могут располагаться в одном хранилище (индексныз файлах), а листовые страницы в друго (в файлах с данными).

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

E>И еще родительские страницы можно хранить отдельно от листовых страниц. Т.е., теоритически, родительские страницы могут располагаться в одном хранилище (индексныз файлах), а листовые страницы в друго (в файлах с данными).
А ещё размер родительских страниц может быть больше например раза в 4 для эффективности поиска, т.к. вставки в них меньше, а поиск в большем массиве более эфективен, то высоту дерева можно уменьшить, со всеми вытекающими

Здравствуйте, eao197, Вы писали:
E>Кстати, ты можешь показать в описании Reiser4, где говорится, что Reiser4 поддерживает атомарность для нескольких изменений нескольких файлов сразу (т.е. чтобы изменение нескольких файлов составляло одну транзакцию)?
У них написано, что все их операции атомарны, и есть механизмы для введения своих атомов. Т.е. там не так просто, но все же возможно получить нормальную атомарность групп операций.

1.1.4 stable rev. 510

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

S>У них написано, что все их операции атомарны, и есть механизмы для введения своих атомов. Т.е. там не так просто, но все же возможно получить нормальную атомарность групп операций.

Как я понимаю, обеспечивается атомарность таких операций, как creat, write и unlink. Только вот если в моей программе идет серия таких операций, по какому принципу ReiserFS поймет, что все они относятся к одной транзакции? А если реально они относятся к двум последовательно идущим транзакциям?
Я бы понял, если бы были предоставлены соответствующие системные вызовы (open_trx и close_trx) и соответственно модифицированы вызовы creat, write, unlink (чтобы можно было идентификатор транзакции указать). Но тогда не будет переносимости программы на другие FS.

eao197 wrote:
> Как я понимаю, обеспечивается атомарность таких операций, как creat,
> write и unlink. Только вот если в моей программе идет серия таких
> операций, по какому принципу ReiserFS поймет, что все они относятся к
> одной транзакции? А если реально они относятся к двум последовательно
> идущим транзакциям?
В Reiser есть понятие пространств имен — файлы могут находятся в одном
или нескольких неймспейсах.

Стандартный неймспейс — обычная FS. Может быть неймспейс для ID3-тэгов в
MP3-файлах или метаинформации об изображениях и т.п.

Для транзакции можно создать свой временный неймспейс и запихать туда
файлы. Причем если мы делаем копию, то получаем аналог snapshot'ов в БД.

Когда транзакция завершается — мы просто объединяем временный неймспейс
с целевым. Это можно сделать атомарно, причем можно даже политики
разрешения конфликтов прикрутить через механизм плугинов Reiser4.

Более того, неймспейсы могут еще и индексироваться для ускорения поиска.

Вообще, такой подход мне нравится — с одной стороны получаем много
полезных возможностей баз данных, с другой стороны, оставляем обычный
интерфейс FS.

Posted via RSDN NNTP Server 2.0

Здравствуйте, eao197, Вы писали:
E>Как я понимаю, обеспечивается атомарность таких операций, как creat, write и unlink. Только вот если в моей программе идет серия таких операций, по какому принципу ReiserFS поймет, что все они относятся к одной транзакции?
Как я понимаю, для этого есть специальный API.
E>А если реально они относятся к двум последовательно идущим транзакциям?
E>Я бы понял, если бы были предоставлены соответствующие системные вызовы (open_trx и close_trx) и соответственно модифицированы вызовы creat, write, unlink (чтобы можно было идентификатор транзакции указать). Но тогда не будет переносимости программы на другие FS.
А ее и так не будет. Или ты ожидал, что как только ты напишешь нормальную программу с поддержкой ACID на ReiserFS4, то она автоматически за-ACIDит и на всех остальных системах?

1.1.4 stable rev. 510

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

S>А ее и так не будет. Или ты ожидал, что как только ты напишешь нормальную программу с поддержкой ACID на ReiserFS4, то она автоматически за-ACIDит и на всех остальных системах?

Я ожидал, что я напишу нормальную программу, которая будет поддерживать ACID на любой FS, если только FS поддерживает атомарность операции write (а это не только ReiserFS, насколько я знаю). А затачивать программу специально под особенности ReiserFS4 можно только, если эта программа под заказ разрабатывается, и заказчика такие условия устраивают.

eao197 wrote:
> Я ожидал, что я напишу нормальную программу, которая будет поддерживать
> ACID на любой FS, если только FS поддерживает атомарность операции write
> (а это не только ReiserFS, насколько я знаю).
Еще нужны блокировки и т.п. Это возможно, именно так и работают обычные
БД, вообще-то.

Posted via RSDN NNTP Server 2.0

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

E>Я ожидал, что я напишу нормальную программу, которая будет поддерживать ACID на любой FS, если только FS поддерживает атомарность операции write.
Увы. Увы и ах. Мягко говоря, устанешь ты писать такую программу. И совершенно неясно, получишь ли ты при этом производительность лучше, чем у РДБМС.

1.1.4 stable rev. 510

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

S>Увы. Увы и ах. Мягко говоря, устанешь ты писать такую программу.

Да ничего, как нибудь осилю.

Sinclair wrote:
> Увы. Увы и ах. Мягко говоря, устанешь ты писать такую программу. И
> совершенно неясно, получишь ли ты при этом производительность лучше, чем
> у РДБМС.
Скорее тут будет другой вопрос: а чем это будет отличаться от Yet
Another DB?

Posted via RSDN NNTP Server 2.0

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

C>Скорее тут будет другой вопрос: а чем это будет отличаться от Yet
C>Another DB?

Некоторая ирония чувствуется. Хочется спросить, а чем плоха YetAnotherDB, если она будет хорошо решать свою задачу?

eao197 wrote:
> C>Скорее тут будет другой вопрос: а чем это будет отличаться от Yet
> C>Another DB?
> Некоторая ирония чувствуется. Хочется спросить, а чем плоха
> YetAnotherDB, если она будет хорошо решать свою задачу?
Главный вопрос: а зачем?

Я встречал ровно одну задачу, в которой своя база данных была
эффективнее какой-нибудь SQLite/BDB. Этой задачей было создание
иерархического хранилища внутри файла

Posted via RSDN NNTP Server 2.0

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

C>Главный вопрос: а зачем?

А шоб было

C>Я встречал ровно одну задачу, в которой своя база данных была
C>эффективнее какой-нибудь SQLite/BDB. Этой задачей было создание
C>иерархического хранилища внутри файла

Хороший пример, кстати.
Еще векторные изображения удобно в объектных базах хранить, к примеру.

Да и у BDB есть большой недостаток -- значения в ней -- это непрозрачные блоки фиксированной длины. Да еще и сама база платформо-зависимая.

Здравствуйте, eao197, Вы писали:
E>Да ничего, как нибудь осилю.
А как насчет второго утверждения?

1.1.4 stable rev. 510

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

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

IT>>А каков глубокий смысл?
M>Совсем глубокого смысла не знаю, надо в Кнута заглинуть или хотя бы в Ульмана...
M>Но помнится смысл в том, что это дает возможность связать все эелементы на листьевом уровне друг с другом в список (собственно по этому они и B+, + как раз означает что все элементы на листьях образуют направленый список), что позволяет:

Вернее Двухнаправленный Список (В пику Sinclair про однонаправленные итераторы)
M>1. Эффективно работать с групповыми выборками и различными Range Scan-ами, типа "верни мне все записи с 5-ой по 25-ю". Не надо проходить дерево сверху вниз за каждой записью, достаточно найти 5-ю и просканировать подряд, по ссылочкам все записи до 25-й.

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

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

M>БД — это компромис, между совсем абстрактными данными, не поддающимися никакому формализму, и совершенно конкретными данными, которыми можно оперировать только зная предметную область к которой относятся эти данные.
M>Иными словами, БД говорит, что если ваши данные удовлетворяют таким-то требованиям (e.g. реляционны), то у этих данных для нас реализована: атомарность, согласованность, изолированность, сохраняемость, эффективный доступ по предикату, ect... И для того чтобы грамотно реализовать для конкретного приложания в рамках ФС, все что предоставляет БД надо угрохать кучу сил с вполне предсказуемым эффектом. Так что когда стоит вопрос выбора между ФС и БД, то это, на самом деле, вопрос — нужно ли для данного приложения всё то богатство возможностей, что предоставляет БД, или нет. И если нужно, то ответ очевиден.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Если рассматривать содержимое файла как набор множества строк данных — то да. А если рассматривать содержимое файла как единую "строку данных", где имя файла является ключем, то ФС замечательно предоставляет все то богатство возможностей, о которых ты упомянул.
Да, совершенно верно. И это неслучайно — ФС собственно и делались с расчетом именно на такое использование.
V>Например, если мы храним документы, то ФС очень даже себя оправдывает, ибо используется в последнем качестве. Если надо прикрутить развитый документооборот, то БД может хранить всякие доп. признаки и связь документов с другими объектами БД, а сам файл может спокойно себе лежать в ФС
Нет! Вот так делать нельзя. Точнее, не стоит. Потому что никаких гарантий целостности для такого хранилища дать невозможно.
V>. Причем, ФС можно настроить так, чтобы избежать несанкционированного доступа вне рассматриваемой системы путем раздачи всяких прав.
Это не решает проблемы. Минимальный сбой в программе — и пошло рассогласование. ACID рулит! Для файлопомойки это не очень страшно. Для системы документооборота — кошмар. Я могу годами думать, что у меня важный договор лежит в папке Х. А он уже давно убит, и вместо него лежит письмо от спамера. Вот она радость-то!
V>Более того, потери базы, как видно из форумов, случаются пока гораздо чаще, чем потери файлов.
Интересный такой взгляд. Я вот не уверен. Хотя, если читать форумы по СУБД, то вряд ли там будут сильно жаловаться на битые файлы (хотя repair офиса народ делает регулярно).
Просто важные данные как правило хранят именно в СУБД, а неважные вопросов "как восстановить" не вызывают.
V>Более того, файлы зачастую можно хоть как-то восстановить,
Это как это ты собрался восстанавливать файл без копии? Или ты имеешь в виду перенабить с клавиатуры?

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

1.1.4 stable rev. 510

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

S> Вернее Двухнаправленный Список (В пику Sinclair про однонаправленные итераторы)
Элементы, как правило, все-таки в направленый, но это уже вопрос реализации...

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

S> Но при этом ненужно хранить состояние, если оно меняется то при переходах нужно его востанавливать.
Состояние чего? Тут я не успеваю за полетом твоей мысли...

S>Хотя версионность и здесь поможет
Версионность-то здесь причем? Это уже совсем из другой оперы.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

V> А если рассматривать содержимое файла как единую "строку данных", где имя файла является ключем, то ФС замечательно предоставляет все то богатство возможностей, о которых ты упомянул.
Так как она предоставит мне возможность записи двух "строк данных" в одной ACID транзакции, и разрулит мне при этом возможные конфликты при записи этих двух "строк данных" из параллельных потоков?

V> Например, если мы храним документы, то ФС очень даже себя оправдывает, ибо используется в последнем качестве.
Только в том случае, если мы можем без проблем пожертвовать парой документов в любой момент, да и то...

V>Если надо прикрутить развитый документооборот, то БД может хранить всякие доп. признаки и связь документов с другими объектами БД, а сам файл может спокойно себе лежать в ФС.
Я уже в этом топике объяснял проблемы такого решения. В этом случае нам необходимо писать в два принципиально разных источника данных, БД и файл. На данном этапе развития научно-технического прогресса проблематично организовать распределенную транзакцию даже между двумя БД, которые знают друг о друге, а ты предлагаешь сделать то же самое с ФС, которая о БД ничего не знает.
Как БД узнает, что файл на самом деле поврежден? Кто будет бакапить файлы и обеспечивать их согласованность с БД при восстановлении? Что делать с файлом, если навернется транзакция в БД при записи информации об этом файле?

V> Причем, ФС можно настроить так, чтобы избежать несанкционированного доступа вне рассматриваемой системы путем раздачи всяких прав.
А что делать с правами в БД? Ты предлагаешь ввести две системы авторизации? Тоже отличная идея..

V>Более того, потери базы, как видно из форумов, случаются пока гораздо чаще, чем потери файлов.
Это я даже комментировтаь не буду...

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

V> А в случае документооборота требования к надежности способа хранения содержимого документов гораздо более высоки, чем требования к надежности хранения связей/аттрибутов.
Помоему ты довольно плохо себе представляешь требования к надежности современных БД и их возможности по обеспечению оной надежности..

... [RSDN@Home 1.2.0 alpha rev. 619]

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

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

Ну как тебе сказать... Мне приходилось терять базы на MS Access (чаще всего), несколько раз на MS SQL (реже) и один раз даже оракловую. (Понятное дело, что всегда были копии, но для операционного дня одной из фирм, где я работал, вчерашняя копия — это безнадежно старая копия...)

И вот в чем основная жопа, так это в случае, если потеряли базу — то потеряли вообще все. А в случае с битым файлом документа мы потеряем только один этот документ.

Только, плиз, не надо меня просвящать насчет журналов транзакций (коих могут быть даже 2 очереди у Sybase), и прочей хренотени. На моей памяти за 5 лет базы "высоконадежного" MS SQL грохались чаще, чем раз в год (по моим наблюдениям за 3-мя фирмами оптово-розничной торговли).

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

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

Вот примерно как можно работать с документами:
— на хранилище документов администратор устанавливает спец.-разрешения, такие, что остальные юзеры и даже админы не могут ничего там изменять, (для админов — до тех пор пока сами явно не перезапишут разрешения на хранилище)
— файлы на диске можно хранить не под своим оригинальным именем, а под составным. В начале имени идет некий префикс, в котором зашифрована версия документа, например: $12$ПамяткаТорговымПредставителям.DOC
— файл отсылается юзверю целиком, после возврата — целиком сохраняется, но, ессно, уже под другим именем c обновленной версией. После успешного сохранения в базу заносится референс на новую версию файла и контрольная сумма по нему.
— для конкретных документов (или классов документов) можно выставлять опции хранения предыдущих версий, например: не хранить, хранить все, хранить последние N, хранить старые копии не старше N дней/месяцев/лет.
— можно указать конкретную версию документа как "нестираемую".
— для документов повышенной важности запись контроллируется последующим чтением.
— для важных документов создаются копии в репозитории-зеркале. Обычно это как минимум другой винчестер (но лучше — другой хост).
— регулярно в фоновом режиме производится сканирование и проверка контрольных сумм файлов в хранилище (хранилищах). В случае наличия правильного файла в одном из зеркал, все восстанавливается. Если нет, то в базу заносится соотв. запись и посылаются оповещения админам.

ИМХО, простейшими ср-вами достигается надежность, гораздо выше, чем надежность СУБД. Ибо для СУБД, повторюсь, аналогичная надежность достигается в случае, если вероятность сбоя = P_fs / K, где P_fs — вероятность сбоя файловой системы, K — кол-во документов в системе. Если документов много, то по этой формуле СУБД сильно проигрывают, даже с самым журналированным в 2 очереди своим транзакционным хранилищем.

И еще. Вы пробовали когда-нибудь сжимать (shrink) многогигабайтные (десятки гиг) файлы данных MS SQL? А когда там хранились блобы по 1-10 метра? В общем, это такая жопа, по сравнению с которой стандартная дефрагментация диска выглядит наивной забавой (и к тому же может вестись в фоновом режиме).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>> А если рассматривать содержимое файла как единую "строку данных", где имя файла является ключем, то ФС замечательно предоставляет все то богатство возможностей, о которых ты упомянул.
M>Так как она предоставит мне возможность записи двух "строк данных" в одной ACID транзакции, и разрулит мне при этом возможные конфликты при записи этих двух "строк данных" из параллельных потоков?

1. Ты не сможешь открыть на запись в эксклюзивном режиме один и тот же файл с двух потоков одновременно.
2. В рассматриваемой системе (см. мой соседний ответ Синклеру), твоя операционная система может транзакционно генерить уникальные версии для каждого файла, и тогда даже разруливать ничего не надо.
3. Блокировки файлов для использования можно вести на уровне БД.

V>> Например, если мы храним документы, то ФС очень даже себя оправдывает, ибо используется в последнем качестве.
M>Только в том случае, если мы можем без проблем пожертвовать парой документов в любой момент, да и то...

Можем. Это лучше, чем пожертвовать базой.

К тому же... читаем мой ответ Синклеру, все-таки.

M>Я уже в этом топике объяснял проблемы такого решения. В этом случае нам необходимо писать в два принципиально разных источника данных, БД и файл. На данном этапе развития научно-технического прогресса проблематично организовать распределенную транзакцию даже между двумя БД, которые знают друг о друге, а ты предлагаешь сделать то же самое с ФС, которая о БД ничего не знает.
M>Как БД узнает, что файл на самом деле поврежден? Кто будет бакапить файлы и обеспечивать их согласованность с БД при восстановлении? Что делать с файлом, если навернется транзакция в БД при записи информации об этом файле?

Все доходчиво объяснил там же.

V>> Причем, ФС можно настроить так, чтобы избежать несанкционированного доступа вне рассматриваемой системы путем раздачи всяких прав.
M>А что делать с правами в БД? Ты предлагаешь ввести две системы авторизации?

Нет, разумеется. Для хранилища нужен только один уникальный аккаунт, которым пользуется только приложение и никто больше.

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

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

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

Так и знал, что не удержишься от этого...

можно пример современной надежной СУБД? А то может я просто "не правильным" MS SQL 2000 несколько лет пользусь (а до этого 7-кой несколько лет). А ты помнишь, кстати, что случалось с журналами транзакций на подвисших транзакциях в 7-ке? Особенно когда в базе активно изменялись блобы по нескольку мег? (в 2000-м с этим полегче, но тоже иногда случалось)

И как же это так получалось, что я почти регулярно минимум раз в год наблюдал падения MS SQL всех мастей (на разных фирмах, за которыми наблюдал)?

Блин, периодически обязательно кто-нибудь найдется на форумах указать мне на "надежность" этой СУБД, хотя я на восстановлении данных для нее собаку съел. А по какой причине, интересно?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>А как насчет второго утверждения?

А второе утверждение, имхо, слишком расплывчато. Есть разные задачи. На которых из них (например, соответствие между IP и именем хоста) РСУБД могут сливать системам вроде BerkeleyDB. Или, например, вставка большого количества данных в несколько таблиц с большим количеством индексов на каждой таблице. Ведь для таких вещей не зря рекомендуют отключать индексы и пользоваться специализированными командами массовой загрузки данных в СУБД. А если большинство индексов созданы только для того, чтобы эффективно поднимать из РСУБД один сложный объект, разобранный по разным таблицам, то ООСУБД даже с меньшей скоростью работы все равно может показать большую производительность на некоторых задачах. Просто за счет того, что операции insert/read/update/delete для сложного объекта будут обрабатываться за один раз.

Сейчас у меня получаются такие результаты на тестах.

Тест на 10000 объектов, размер которых варьируется от одного байта до N (N задается во время компиляции). Объекты создаются в пустой БД; загружаются в случайном и последовательном порядке, перезаписываются (с изменением значения) в последовательном и случайном порядке с изменением размера объекта и без; половина объектов удаляется, а затем вновть создается; все объекты удаляются по очереди; создаются заново, но уже в БД, в которой есть достаточно места для их размещения; все объекты удаляются одной операцией.

Для объектов размером до 32-х байт с использованием write ahead log (фиксация только последней транзакции):

default storage object creation: 5.391
default storage all object loading (random order): 0.312
default storage all object loading (sequential order): 0.188
default storage all object updating (sequential order, no resize, no_preload): 3.094
default storage all object updating (random order): 4.734
default storage all object updating (random order, no resize): 3.672
default storage all object updating (sequential order, no resize): 3.422
default storage half object destroying: 2.422
default storage half object creation: 3.094
default storage all object destroying: 4.984
default storage object creation 2: 5.047
default storage all object at once destroying: 0.406
default storage: 36.828

Для объектов размером до 2048 байт с использованием write ahead log (фиксация только последней транзакции):

default storage object creation: 5.891
default storage all object loading (random order): 1.265
default storage all object loading (sequential order): 0.453
default storage all object updating (sequential order, no resize, no_preload): 3.578
default storage all object updating (random order): 9.391
default storage all object updating (random order, no resize): 6.563
default storage all object updating (sequential order, no resize): 6.5
default storage half object destroying: 3.875
default storage half object creation: 3.203
default storage all object destroying: 6.906
default storage object creation 2: 6.719
default storage all object at once destroying: 0.89
default storage: 55.312

Тесты на ноутбуке с Pentium-M 1.5GHz, 512Mb, 60GB HDD.
Привел значение для WinXP Pro и NTFS (для Slackware Linux (ядро 2.6.13) и ReiserFS v3 получается процентов на 10% быстрее на той же машине).

Не BerkeleyDB, конечно. Хотя даже такая производительность позволяет фиксировать по 1000 транзакций в секунду (причем нет сильной зависимости от сложности и объема описания одной транзакции).

Если же write ahead log отключить, то картина меняется.
Для объектов до 32-х байт:

default storage object creation: 1.219
default storage all object loading (random order): 0.312
default storage all object loading (sequential order): 0.188
default storage all object updating (sequential order, no resize, no_preload): 0.453
default storage all object updating (random order): 0.688
default storage all object updating (random order, no resize): 0.828
default storage all object updating (sequential order, no resize): 0.64
default storage half object destroying: 0.672
default storage half object creation: 0.61
default storage all object destroying: 1.093
default storage object creation 2: 1.188
default storage all object at once destroying: 0.391
default storage: 8.36

Для объектов до 2048-ми байт:

default storage object creation: 1.64
default storage all object loading (random order): 1.25
default storage all object loading (sequential order): 0.422
default storage all object updating (sequential order, no resize, no_preload): 0.734
default storage all object updating (random order): 2.797
default storage all object updating (random order, no resize): 2.11
default storage all object updating (sequential order, no resize): 1.968
default storage half object destroying: 1.641
default storage half object creation: 0.937
default storage all object destroying: 1.828
default storage object creation 2: 1.656
default storage all object at once destroying: 0.61
default storage: 17.656

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

Пока же повышать производительность не устал

Только времени на это нет.

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

V>Ну как тебе сказать... Мне приходилось терять базы на MS Access (чаще всего), несколько раз на MS SQL (реже) и один раз даже оракловую. (Понятное дело, что всегда были копии, но для операционного дня одной из фирм, где я работал, вчерашняя копия — это безнадежно старая копия...)

если была потеряна оракловая или MSSQL БД то ДБА нужно просто увольнять без выходного пособия за то что небыло включено онлайн архивирование — проще говоря перманентный runtime backup. любая нормальная БД это поддерживает и если все правильно организовано то ничего потеряно не будет даже если контроллер будет глючить или весь RAID массив навернется.

V>Только, плиз, не надо меня просвящать насчет журналов транзакций (коих могут быть даже 2 очереди у Sybase), и прочей хренотени. На моей памяти за 5 лет базы "высоконадежного" MS SQL грохались чаще, чем раз в год (по моим наблюдениям за 3-мя фирмами оптово-розничной торговли).

скорее всего это были аппаратные сбои, хотя от MSSQL можно ждать чего угодно. нормальный бэкап все эти проблемы решает раз и навсегда.

V>Вот примерно как можно работать с документами:
[skipped...]

все это автоматически и без всякого гемороя делает БД. описаное решение на самом деле ничего не гарантирует.

V>ИМХО, простейшими ср-вами достигается надежность, гораздо выше, чем надежность СУБД. Ибо для СУБД, повторюсь, аналогичная надежность достигается в случае, если вероятность сбоя = P_fs / K, где P_fs — вероятность сбоя файловой системы, K — кол-во документов в системе. Если документов много, то по этой формуле СУБД сильно проигрывают, даже с самым журналированным в 2 очереди своим транзакционным хранилищем.

с нормальным инкрементальным онлайн бэкапом вероятность потери данных в БД равна нулю.

V>И еще. Вы пробовали когда-нибудь сжимать (shrink) многогигабайтные (десятки гиг) файлы данных MS SQL? А когда там хранились блобы по 1-10 метра? В общем, это такая жопа, по сравнению с которой стандартная дефрагментация диска выглядит наивной забавой (и к тому же может вестись в фоновом режиме).

это проблемы MSSQL, оракл умеет перестраивать данные в онлайне и в принципе может даже хранить блобы в отдельных файлах.

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

V>1. Ты не сможешь открыть на запись в эксклюзивном режиме один и тот же файл с двух потоков одновременно.
Читай внимательно моё сообщение, там надо разрулить 2 файла.

V>2. В рассматриваемой системе (см. мой соседний ответ Синклеру), твоя операционная система может транзакционно генерить уникальные версии для каждого файла, и тогда даже разруливать ничего не надо.
Классно, какую версию файла потом использовать из двух сгенеренных? Кто будет разруливать согласованность записи в два разных файла?

V>3. Блокировки файлов для использования можно вести на уровне БД.
Если у нас есть БД, зачем же ее не использовать целиком? Она в конце-концов для этого предназначена.

V>Можем. Это лучше, чем пожертвовать базой.

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

V> К тому же... читаем мой ответ Синклеру, все-таки.
Твой ответ Синклеру, это вообще что-то...

Аксес — это не БД, а потерять базу Сиквела или Оракла можно только очень этого захотев. И тут я тебе буду рассказывать именно про логи и бакапы, и умение с ними работать.

V>Все доходчиво объяснил там же.
Там ты подробно рассказал как написать свою БД, извиняюсь, ректально, подручными средствами. Зачем, если есть готовая БД?

V>Нет, разумеется. Для хранилища нужен только один уникальный аккаунт, которым пользуется только приложение и никто больше.
Аккаунт-то может и один, а вот механизмы работы с ним разные в БД и в ФС.

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

V>Так и знал, что не удержишься от этого...

А ты как думал? А я вот, например, так и знал, что ты будешь рассказывать какой у тебя падучий сиквел, и рассказывать как много ты с ним провозился..

Я, пожалуй, не буду, неудобно как-то..

V> можно пример современной надежной СУБД?
Да легко, сиквел, DB2, оракл... Надежности на десяток ФС хватит.

V>А то может я просто "не правильным" MS SQL 2000 несколько лет пользусь (а до этого 7-кой несколько лет).
Может быть, я-то откуда знаю?

V>И как же это так получалось, что я почти регулярно минимум раз в год наблюдал падения MS SQL всех мастей (на разных фирмах, за которыми наблюдал)?
Руки? Извини, но других идей нет, потому как за последние пять лет я не наблюдал ни одной транзакции потеряной по вине падения БД.

V>Блин, периодически обязательно кто-нибудь найдется на форумах указать мне на "надежность" этой СУБД, хотя я на восстановлении данных для нее собаку съел. А по какой причине, интересно?

Может не тех собак ел? Или на форумах просто умеют этих собак готовить? Тем более, как ты сам пишешь, на форумах ты один поешь о ненадежности БД, может в консерватории что?

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

V>Например, если документ Word неожиданно навернулся (это обычно происходит в момент записи и неожиданного сбоя аппаратуры в этот момент), то у нас в распоряжении есть временный теневой файл на диске, который создает сам Word, и который обычно содержит информацию, очень близкую к оригиналу.
В твоей системе этот документ всегда открывается прямо на сервере? И при копировании грохнуться не может? Все файлы независимы друг от друга?

V>- файлы на диске можно хранить не под своим оригинальным именем, а под составным. В начале имени идет некий префикс, в котором зашифрована версия документа, например: $12$ПамяткаТорговымПредставителям.DOC
V>- файл отсылается юзверю целиком, после возврата — целиком сохраняется, но, ессно, уже под другим именем c обновленной версией. После успешного сохранения в базу заносится референс на новую версию файла и контрольная сумма по нему.
Как узнать, что файл сохранился успешно? Что делать если сохранился неуспешно? Что делать если два файла связаны между собой и должны быть одной версии? Что делать, если два файла связаны и один сохранился успешно, а другой нет? Что делать если в БД по каким-то причинам не прошла транзакция с метаинформацией о записаном документе? Что делать, если упала вся БД (она ведь у нас теперь падает)?

V>- для важных документов создаются копии в репозитории-зеркале. Обычно это как минимум другой винчестер (но лучше — другой хост).
V>- регулярно в фоновом режиме производится сканирование и проверка контрольных сумм файлов в хранилище (хранилищах). В случае наличия правильного файла в одном из зеркал, все восстанавливается. Если нет, то в базу заносится соотв. запись и посылаются оповещения админам.
То есть пишем еще ручную систему зеркалирования?

V>ИМХО, простейшими ср-вами достигается надежность, гораздо выше, чем надежность СУБД.
Это вряд ли..

V>Ибо для СУБД, повторюсь, аналогичная надежность достигается в случае, если вероятность сбоя = P_fs / K, где P_fs — вероятность сбоя файловой системы, K — кол-во документов в системе.
Неверно. Во-первых надежность твоей системы будет всегда хуже БД, потому что она зависит и от надежности БД и от надежности каждого из файлов, а во-вторых, ты не учел еще надежность написанной в ручную системы восстановления, и вообще всей системы, и вероятность отсутствия в ней ошибок.

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

V>И еще. Вы пробовали когда-нибудь сжимать (shrink) многогигабайтные (десятки гиг) файлы данных MS SQL?
А зачем их сжимать?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

S>> Вернее Двухнаправленный Список (В пику Sinclair про однонаправленные итераторы)
M>Элементы, как правило, все-таки в направленый, но это уже вопрос реализации...

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

Реализация всех элеменах в листевых страницах несколько проще, быстрее итд.

S>> Но при этом ненужно хранить состояние, если оно меняется то при переходах нужно его востанавливать.
M>Состояние чего? Тут я не успеваю за полетом твоей мысли...
Состояние в дереве. То бишь всю иерархию от корня, при проходе только по листовым страницам это ненужно
S>>Хотя версионность и здесь поможет
M>Версионность-то здесь причем? Это уже совсем из другой оперы.

Не скажи. Опера то одна и таже а реализации несколько различные. Перестройка индексов при блокировочнике более значимая проблема, чем при версионнике, так как может затрагивать множество страниц. Хотя для однопоточного использования монописуально.

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

ANS>>Пойдём по шагам. Начнём с простейшего: пример хранения графа с циклами при помощи ordpath.
M>Потребую от графа умения сериализоваться и десериализоваться в xml, сведя тем самым задачу к известной.

Хм. Можно пример, во что сериализуется такое:

            Obj1 (name="abcd", next=Obj2)
            Obj2 (name="qwerty", next=Obj1)

И пример XPath запроса который вытащит мне объекты у которых obj.next.name="ta-ta-ta"?

ANS>>Попробовали б они не сделать, когда маркетологи говорят "надо".

M>Уж посылать в лес маркетологов они умеют изумительно.

Типа "Ну не шмогла я, не шмогла"?

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>Реализация всех элеменах в листевых страницах несколько проще, быстрее итд.
Реализация чего? Я тебя вообще перестаю понимать...

S> Состояние в дереве. То бишь всю иерархию от корня, при проходе только по листовым страницам это ненужно
Какую иерархию от корня? Состояние чего в дереве?

S> Не скажи.
Скажу.

S> Опера то одна и таже а реализации несколько различные.
Реализации чего? Прохода по дереву? Его модификации?

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Хм. Можно пример, во что сериализуется такое:
ANS>

ANS>            Obj1 (name="abcd", next=Obj2)
ANS>            Obj2 (name="qwerty", next=Obj1)
ANS>

Не, ты не понял. Ты придумал граф объектов, ты его и сериализуй. Вот когда сериализуешь, тогда БД его и сохранит.

ANS>И пример XPath запроса который вытащит мне объекты у которых obj.next.name="ta-ta-ta"?
Прежде чем на реляционки наезжать, покажи мне объектную БД, которая так умеет..

При условии, что Name вообще может быть виртуальный метод.

ANS>Типа "Ну не шмогла я, не шмогла"?
Нет, "Вы наобещали, вы и делайте"

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

M>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>Хм. Можно пример, во что сериализуется такое:
ANS>>

ANS>>            Obj1 (name="abcd", next=Obj2)
ANS>>            Obj2 (name="qwerty", next=Obj1)
ANS>>

M>Не, ты не понял. Ты придумал граф объектов, ты его и сериализуй. Вот когда сериализуешь, тогда БД его и сохранит.

Нет, уж. Ты сказал "без проблем" — вот и продемонстрируй.

ANS>>И пример XPath запроса который вытащит мне объекты у которых obj.next.name="ta-ta-ta"?
M>Прежде чем на реляционки наезжать, покажи мне объектную БД, которая так умеет..

При условии, что Name вообще может быть виртуальный метод.

Не, ты не понял.

Ты сказал, что реляционка для хранения объектов это "самое то" на основании, то что в неё можно легко XML запихнуть и запросы по нему летать будут. Я сомневаюсь в подобном обобщении. Что касается виртуальных методов, то давай пока без них (хотя GemStone/S это могёт). Подобный запрос, кстати, можно сделать на ORM.

И было бы интересно увидеть как это выглядит на WinFS.

ANS>>Типа "Ну не шмогла я, не шмогла"?
M>Нет, "Вы наобещали, вы и делайте"

Вот и у меня такая мысль появилась, что WinFS занимаются исключительно маркетологи.

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Нет, уж. Ты сказал "без проблем" — вот и продемонстрируй.
Читай внимательно, я сказал "без проблем если сериализуется". Ты придумал, ты и сериализуй..

ANS>Не, ты не понял.

Я ли?

ANS> Ты сказал, что реляционка для хранения объектов это "самое то" на основании, то что в неё можно легко XML запихнуть и запросы по нему летать будут.
ANS>Я сомневаюсь в подобном обобщении.
Твое право

ANS> Что касается виртуальных методов, то давай пока без них (хотя GemStone/S это могёт).
С GS и прочими Jasmin-ами свои тараканы...
А про виртуальные методы — это я к тому, что критикуя — предлагай. Реляционные системы есть, и неплохо справляются со своей работой на очень широком классе задач. ООБД на данный момент — удел энтузиастов и очень узкого класса приложений.
То, что они положили в основу реляционку означает, что у этой системы в принципе есть шанс увидеть свет, там хотя бы движек рабочий.
А как бы это выглядело будь она целиком объектной? Я уже не в первый раз пытаюсь тебя спросить...

ANS>Подобный запрос, кстати, можно сделать на ORM.
Можно, как раз с этим никто не спорит. И опять-таки, чем не вариант?

ANS>И было бы интересно увидеть как это выглядит на WinFS.
Мне самому интересно. Но как я уже говорил, мне хватило бы, если бы там просто был доступен обычный SQL. И похоже все идет к тому, что там будет DLinq, по крайней мере это было бы очень логично...

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

M>Вот, кстати, по поводу "А они за основу взяли реляционку

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>Ну-ну. И ты готов реализовать OrdPath на реляционном 2000 ом?
А зачем? Но если надо, то Nested Sets, который очень здорово напоминает OrdPath, известен уже очень давно и для иерархий его реализовывали еще на 4.3, если не раньше, так что не проблема.
Можешь Келко на досуге перечитать..

GZ>Классификатор OrdPath весьма интересен, но она не реляционен.
Да ну? Сам по себе нет, но результат его работы — более чем.

GZ> Для него все равно нужен был свой механизм и своя интерпретация.
Естественно нужна, но уже поверх реляционки. После того, как преобразовали иерархию с помощю OrdPath — это реляционка в чистом виде.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

GZ>>Ну-ну. И ты готов реализовать OrdPath на реляционном 2000 ом?
M>А зачем? Но если надо, то Nested Sets, который очень здорово напоминает OrdPath, известен уже очень давно и для иерархий его реализовывали еще на 4.3, если не раньше, так что не проблема.
Ничего общего между OrdPath и Nested Set. OrdPath — это классификатор, один из подвидов Dewey. Та же линейная скорость вставки и удаления, возможность сортировки иерархии, но с сохранением порядка последовательности, и с возможностью ссылки на различные домены. Второе — не очень реляционно. Первое — я бы не сказал, но сильно влияет на функционирование оптимизатора запросов. Oracle не зря вычленил сортировку из вложенных запросов. Microsоft частично тоже.
M>Можешь Келко на досуге перечитать..

С удовольствием. Только не знаю что это. Че за книженция?

GZ>> Для него все равно нужен был свой механизм и своя интерпретация.
M>Естественно нужна, но уже поверх реляционки. После того, как преобразовали иерархию с помощю OrdPath — это реляционка в чистом виде.
Ну не в чистом виде. Каждую запись OrdPath, а это набор битов, все таки надо обрабатывать по особому.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

ЗХ>Господа, не флейма ради совершенно!

Не флейма ради.
Во первых, то что ты уже намекнул. Файловое хранилище также является базой данных и операционная система выполняет функции системы управления базой данных. Разница в реализациях хранения.
Реляционное хранение это строгоструктурированная система хранения данных. Это готовая универсальная модель данных в которой можно хранить все. Единственное ограничение — ты должен хранить данные в строгоструктурированном реляционном виде. И тут есть и плюсы и минусы. Начну с плюсов.
1. Доступность. Ты можешь получить любое поле из объекта по некоторым свойствам. Можешь получить набор объектов. При этом не зная как физически все это хранится уровне.
2. Эффективность доступа к большим данным. Реляционка содержит очень эффективные механизмы работы с большим количеством данных. Настолько эффективные, что программисту не нужно задумываться с какой сложностью O(log N) он работает. Без учета структуры данных это сделать практически невозможно. Кроме того, поддерживается кэширование данных с учетом типа обращения к ним, и структуры данных.
3. Преобразование. Ты можешь получить объекты в том виде которые тебе нужны. Сам SQL построен так, что ты можешь вернуть единый результат полей из нескольких таблиц. То есть, возможность работы на другой модели отличной от модели таблиц.(то что в реальной OODB системе сделать невозможно).
4. Оптимальность физ. хранения. Реляционная система чрезвычайно эффективно хранит данные на диске. Так, она не хранит избыточных данных, и хранит эффективно для доступа к ним. При этом учитывается структура данных. Реальный механизм физического хранения скрыт от программиста, и он очень сложен. И это есть гут.
5. Консистентность данных. Серьезная база данных предоставляет средства для хранения данных в согласованном состоянии. Система ссылочной целостности. Без учета структуры, сделать такое невозможно. Ну и ACID транзакционность. При неожиданном отключении питания, база данных оставаться в согласованном состоянии. При включении самовосстанавливаться. Это достаточно сложный механизм. Все случаи, о которых я знаю, потери базы данных были от кривых рук программистов, шибко умных администраторов, ну и проблемы железа. От всех трех случаев есть дополнительный вид защиты в виде backup.
6. Продвинутая система администрирование. Администрирование идет не только на уровне системы в целом, но и администрирование данных. Тут есть конечно и проблемы, типа того что не все поддерживают защиту на уровне строк, но в основном достичь того-же без знания структуры данных невозможно.
7. Масштабируемость. Серьезная база данных масштабируема. Она масштабируема как по доступу к данным(опустим священные войны блокировочников vs версионников), так и по расширяемости(кластеризация).

Недостатки:
1. Избыточность. Если у тебя килобайт данных, то подключать монстра к оперированию этими данными не стоит. Точно так же как excel таблица, несмотря на то, что она реляционна, избыточно для хранения в базе данных. В этом случае показания к файловой системе. База данных эффективна к операциям с данными про большой сложности O.
2. Слабоструктурированность. Если у тебя данные неструктурированны, то особой разницы между реляционной базой данных и файлами нет. И в том, и другом случае у тебя некоторый массив информации(blob), который ты должен сам распарсить и обработать. Единственное чем тебе может помочь БД — это возможность администрирования, транзакционность в случае если есть связи со структурированными данными. В остальном ее механизмы будут избыточны и лежать мертвым грузом.
3. Имеют изменяющуюся структуру. В данном случае рулят OODB поддерживающие версионификацию объектов. Или реализовывать самому ручками. РСУБД хреноватенько работают при частом изменении структуры данных.
4. Вычислителная ублюдочность встроенных в СУБД языков. Внутренний язык заточен под эффективную обработку данных. Что касается вычислительных и больших задач, то тут они неоптимальны. Приходится выгружать данные. В случае если нет другой задачи, то оставшиеся механизмы РСУБД — избыточны.
5. Отсутсвие полноценного навигационного доступа. Если у тебя сложный граф объектов, и ты должен пробегать по ним постоянно, то система предназначенная для работы с большим O буксует. В этом случае надо пользоваться либо ООDB, либо выкачивать данные и обрабатывать в памяти. Понятно, если задача состоит только из работы с данным графом, то механизмы РСУБД — избыточны.
Это пожалуй все показания для реализации в файловой системе.

Теперь по развития:
В РСУБД внедряются системы работы с слабоструктурированными данными. Это ввод в схему и обработку блобов. Внедрение полуструктурированного XML. Системы обработки медиаданных. Полнотекстовый поиск. Внедряются полноценные языки программирования.
Файловые системы приближаются к системам РСУБД. Как бы то, структурирование файлов, транзакционность.
Но все же сомневаюсь что они когда-нибудь они сольются в экстазе. IMHO Основная проблема в структурированности данных.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>Ничего общего между OrdPath и Nested Set.
Вот совсем-совсем ничего?

GZ> Та же линейная скорость вставки и удаления, возможность сортировки иерархии, но с сохранением порядка последовательности, и с возможностью ссылки на различные домены.
Общее с NS я выделил. В лучшую сторону OP отиличается линейной вставкой.
А "ссылка на различные домены" — это что?

GZ> Второе — не очень реляционно.
Что именно здесь нереляционного?

GZ>С удовольствием. Только не знаю что это. Че за книженция?
Это не книженция, это популяризатор такой, довольно одиозный и хамоватый — Джо Келко, NS очень любит.

GZ>Ну не в чистом виде.
В чистом.

GZ> Каждую запись OrdPath, а это набор битов, все таки надо обрабатывать по особому.
Кому обрабатывать? С точки зрения реляционного движка это просто число в реляционной таблице, все обработки и интерпретации этих чисел лежат уровнем выше и реляционки не касаются.
Грубо говоря, OP можно представить как черный ящик, который на входе получает иерархию, а на выходе выдает реляционную таблицу. Иными словами — это еще один способ привести иерархию к реляционному виду, только на этот раз встроеный в БД и заточеный под работу с xml.

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

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

А что будет, если сбойнет FAT или MFT? А что будет если сбойнет MBR? Или ты хочешь сказать что такого не бывает?

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

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

GZ>>Ничего общего между OrdPath и Nested Set.
M>Вот совсем-совсем ничего?
Да особо то ничего.

GZ>> Та же линейная скорость вставки и удаления, возможность сортировки иерархии, но с сохранением порядка последовательности, и с возможностью ссылки на различные домены.
M>Общее с NS я выделил. В лучшую сторону OP отиличается линейной вставкой.
Это алгоритм совершенно другого класса.

M>А "ссылка на различные домены" — это что?
GZ>> Второе — не очень реляционно.
M>Что именно здесь нереляционного?
Различные типы кортежей.

GZ>> Каждую запись OrdPath, а это набор битов, все таки надо обрабатывать по особому.
M>Кому обрабатывать? С точки зрения реляционного движка это просто число в реляционной таблице, все обработки и интерпретации этих чисел лежат уровнем выше и реляционки не касаются.
M>Грубо говоря, OP можно представить как черный ящик, который на входе получает иерархию, а на выходе выдает реляционную таблицу. Иными словами — это еще один способ привести иерархию к реляционному виду, только на этот раз встроеный в БД и заточеный под работу с xml.
Попробуй посмотреть план запроса типа для

select @x.query('/People[2]')

Замечательный набор compute scalar на фоне ordered sequence. В терминах чистой реляционной алгебры будет сложновато.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>Да особо то ничего.
Отлично, уже прогресс, с совсем ничего, до особо ничего...
Предназначен в целом для того же, работает похоже, а больше да, ничего.

GZ>Это алгоритм совершенно другого класса.
Какого другого?

GZ>Различные типы кортежей.
Что такое тип кортежа?

GZ>Замечательный набор compute scalar на фоне ordered sequence.
Еще раз: Все эти вычисления лежат сверху реляционки. Это преобразование XPath к нормальному виду, чтобы выполнить реляционный запрос.
Я не пойму, ты сомневаешься, что OP можно реализовать в ручную, поверх какой-нибудь БД? Зря сомневаешься.

GZ> В терминах чистой реляционной алгебры будет сложновато.
А что касается терминов чистой реляционной агебры — это вообще отдельный разговор, ни одна реляционная БД в них не укладывается.
Однако в данном случае, результат работы OP — совершенно классическое отношение, как минимум в третьей нормальной форме. Что в нем нереляционного?

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

GZ>>Да особо то ничего.
M>Отлично, уже прогресс, с совсем ничего, до особо ничего...
M>Предназначен в целом для того же, работает похоже, а больше да, ничего.
Работает непохоже.

GZ>>Это алгоритм совершенно другого класса.
M>Какого другого?
Классификаторов с сохранением пути.
Переслал тебе статью. Посмотри. Это как раз и есть тот же класс алгоритмов.(всю ночь писал)

GZ>>Различные типы кортежей.
M>Что такое тип кортежа?
Набор аттрибутов.

GZ>>Замечательный набор compute scalar на фоне ordered sequence.
M>Еще раз: Все эти вычисления лежат сверху реляционки. Это преобразование XPath к нормальному виду, чтобы выполнить реляционный запрос.
M>Я не пойму, ты сомневаешься, что OP можно реализовать в ручную, поверх какой-нибудь БД? Зря сомневаешься.
Не зря. Пробовал.

GZ>> В терминах чистой реляционной алгебры будет сложновато.
M>А что касается терминов чистой реляционной агебры — это вообще отдельный разговор, ни одна реляционная БД в них не укладывается.
Вообще-то укладываются. Любую операцию SQL2000 можно описать набором базовых реляционных операций.
M>Однако в данном случае, результат работы OP — совершенно классическое отношение, как минимум в третьей нормальной форме.
Откуда третья?
M>Что в нем нереляционного?
Не путай результат, и работу. Реляционка это не отношение. На диске пара сегмент-дорожка также можно сказать что реляционны. Все дело в применяемых операциях. То бишь операций реляционной алгебры. И тут в OP не все так однозначно. Все таки иерархия над данными с изменяемым набором аттрибутов, которые ссылаются на различные домены.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

S>>Реализация всех элеменах в листевых страницах несколько проще, быстрее итд.
M>Реализация чего? Я тебя вообще перестаю понимать...

Алгоритм несколько проще и быстрее.

S>> Состояние в дереве. То бишь всю иерархию от корня, при проходе только по листовым страницам это ненужно
M>Какую иерархию от корня? Состояние чего в дереве?

Состояние это иерархия (граф) страниц с соответствующими индексами в PageItems и NodeItem

S>> Не скажи.
M>Скажу.

S>> Опера то одна и таже а реализации несколько различные.
M>Реализации чего? Прохода по дереву? Его модификации?

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

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

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

S>Алгоритм несколько проще и быстрее.
Алгоритм чего? Есть ссылки между листьями и ссылки между эелементами, на практике реализуются и те и те. Что здесь проще и быстрее? Проще и быстрее чем что?

S> Состояние это иерархия (граф) страниц с соответствующими индексами в PageItems и NodeItem
Состояние — это состояние, граф — это граф.

S>Не совсем.
Совсем.

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

S>для версионников это не нужно, т.к. выделяются новые страницы и блокировки нужны только на этапе выделения новых страниц
То есть все-таки нужны?

S> и модификации ссылок на новые версии.
Какие версии?
Еще раз. К этому уровню версионность/блокировочность никакого отношения не имеют. Вообще. Вся версионность/блокировочность реализуется уровнем выше. И версионники и блокировочники работают с деревом +/- одинаково.
Пойми, если для какого-то сценария блокировочнику будет выгодно создать копию страницы в памяти и как-то поиграться с "версиями" этих страниц для модификации дерева (хотя на самом деле этого никто не делает, на сколько я знаю), то никаких проблем для блокировочника это не составит.
Так что блокировочность/версионность к данному разговору не имеют никакого отношения.

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

... [RSDN@Home 1.2.0 alpha rev. 619]

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

GZ>Работает непохоже.
Похоже-похоже..

GZ>Классификаторов с сохранением пути.
NS как раз и есть оно самое.

GZ>Набор аттрибутов.
Набор атрибутов — это кортеж, а не тип кортежей.
Ты хочешь сказать, что в одном отношении получаемом после OP в кортежах разный набор атрибутов? Тогда бы это не было отношением и реляционный движек не смог бы с этим работать.

GZ>Не зря. Пробовал.
Как можно таблицу не запихнуть в БД?

GZ>Вообще-то укладываются.
Вообще-то нет..

GZ>Любую операцию SQL2000 можно описать набором базовых реляционных операций.
Не-а. Например, как раз засада с доменами — современные СУБД, позволяют выполнять операции с разными доменам, чего с точки зрения реляционной алгебры быть не должно. Одно из Коддовских SQL flaw, если я правильно помню...

M>>Что в нем нереляционного?
GZ>Не путай результат, и работу.
Я-то как раз ничего не путаю, все это время я говорю исключительно о результате, а ты почему-то пытаешься приплести именно механику работы самого OP. В данном случае меня совершенно не интересует как OP работает, о чем я уже писал ни раз. Как работает — это другой разговор, можем обсудить отдельно.

GZ> Реляционка это не отношение.
Отношение это один из базовых принципов реляционки, равно как и операции, о которых ты говоришь ниже.

GZ> Все дело в применяемых операциях. То бишь операций реляционной алгебры. И тут в OP не все так однозначно.
Ну не надо OP применять операции реляционной алгебры. Считай, чо это OR-маппер такой, внутри себя он может делать все что угодно, главное что до реляционного движка доходят исключительно реляционные запросы, согласущиеся с принципами реляционной алгебры на столько, на сколько это дело вообще способна согласовать современная РСУБД.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

E>Я бы понял, если бы были предоставлены соответствующие системные вызовы (open_trx и close_trx)

Насколько я понял, в том NTFS, который будет в Висте, такие вызовы будут (причем с учетом распределенных транзакций). Будет вобще системный API для управления транзактными ресурсами.

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

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

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

S>>Алгоритм несколько проще и быстрее.
M>Алгоритм чего? Есть ссылки между листьями и ссылки между эелементами, на практике реализуются и те и те. Что здесь проще и быстрее? Проще и быстрее чем что?

Есть ссылки на элементы (значения при кластерном индексе) которые хранятся в как PageItems так и NodeItem.
Реализация где все ссылки хранятся на листовом уровне в итоге проще в реализации и
S>> Состояние это иерархия (граф) страниц с соответствующими индексами в PageItems и NodeItem
M>Состояние — это состояние, граф — это граф.

состояние это значения графа на определенный момент.
S>>Не совсем.
M>Совсем.

S>> При модификации в блокировочнике тебе придется блокировать не только страницу на которой находится элемент, но и в зависимости от наполнения и родительские страницы, т.к. при переполнении страниц, могут модифицироваться страницы до корня.
M>Родительскую страницу надо блокировать только на время ее модификации.
Пример возьмем кластерный индекс с размером записи в 4 кб. Модификация родитеьских страниц будет очень частая. Причем количество таких станиц не менее 20

S>>для версионников это не нужно, т.к. выделяются новые страницы и блокировки нужны только на этапе выделения новых страниц
M>То есть все-таки нужны?

Разумеется но это кратковременные блокировки по аналогии много читателей один писатель.
S>> и модификации ссылок на новые версии.
M>Какие версии?
Вспомним что це таке версионность. Каждая страница имеет свою версию и ссылку на страницу с предыдущей версией.
M>Еще раз. К этому уровню версионность/блокировочность никакого отношения не имеют. Вообще. Вся версионность/блокировочность реализуется уровнем выше. И версионники и блокировочники работают с деревом +/- одинаково.
M>Пойми, если для какого-то сценария блокировочнику будет выгодно создать копию страницы в памяти и как-то поиграться с "версиями" этих страниц для модификации дерева (хотя на самом деле этого никто не делает, на сколько я знаю), то никаких проблем для блокировочника это не составит.

Логика другая. И алгоритмы другие.
M>Так что блокировочность/версионность к данному разговору не имеют никакого отношения.

S>>Вообще версионность для меня намного выглядит более приемлемым вариантом, хотя и более затратным.
M>Ты уверен, что хорошо представляешь как это на самом деле работает?
Да. Скажу по секрету, что алгоритм Б+ деревьев делал не зная о их существовании, а версионность прикручивал тоже раньше, а про то что это версионность узнал из статьи синклера.

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

S> Есть ссылки на элементы (значения при кластерном индексе) которые хранятся в как PageItems так и NodeItem.
О каком кластерном индексе ты ведешь речь? Нет никакого кластерного, есть самый обычный. Кластерный — это уже детали конкретной реализации, которые опять-таки не имеют никакого отношения к разговору.

S>Реализация где все ссылки хранятся на листовом уровне в итоге проще в реализации
Так ты о том, почему в B+ все ссылки на данные в листьях? С этим мы уже давно разобрались.

S> состояние это значения графа на определенный момент.
И что не так с этим состоянием и зачем его надо хранить?

S> Пример возьмем кластерный индекс с размером записи в 4 кб. Модификация родитеьских страниц будет очень частая. Причем количество таких станиц не менее 20
Ну будет частой, при частой вставке, и что? Хочешь сказать, что используя "версионность" можно избежать блокировки страницы на время модификации?

S> Разумеется но это кратковременные блокировки по аналогии много читателей один писатель.
Ну так и при обычном блокировании тоже самое. Всегда накладывается кратковременный latch на страницу только на время ее модификации.

S> Вспомним что це таке версионность.
Да я как-бы не забываю.

S> Каждая страница имеет свою версию и ссылку на страницу с предыдущей версией.
Зачем это нужно при модификации дерева? Приседания вокруг версионности начинаются тогда, когда прикладному коду нужна устаревшая версия страницы, а не самому дереву для модификации. Самому дереву никакой пользы, кроме вреда, от версионности нет.

S> Логика другая. И алгоритмы другие.
Все одинаковое. Разница только в том, что в одном случае версионность нужна прикладному коду, а в другом нет. Понимаешь, есть такая вещь как декомпозиция и инкапсуляция. Все кто пользуются деревом работают с ним как с черным ящиком, через подробно описанные интерфейсы.
Поэтому если внутри этого черного ящика, вдруг, паче чаянья, понадобилось бы реализовать версионность, в том или ином виде, для каких-то своих внутренних целей, то никаких проблем бы это не составило.
Если же прикладному коду, уровнем выше версионность нужна, то появляются дополнительные алгоритмы для того чтобы достать другие версии, пользы же и выгоды для модификации самого дерева от этого никакой, только геморрой дополнительный.

S> Да.
Боюсь что ты заблуждаешься.

S>Скажу по секрету, что алгоритм Б+ деревьев делал не зная о их существовании, а версионность прикручивал тоже раньше, а про то что это версионность узнал из статьи синклера.
Понимаешь, у себя ты можешь реализовывать что угодно, я рассказываю о том как индексы в реальных БД устроены... Скажем в SQL 2005 даже в режиме версионности никаких плясок с версиями страниц в принципе нет, на сколько мне известно.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

S>> Есть ссылки на элементы (значения при кластерном индексе) которые хранятся в как PageItems так и NodeItem.
M>О каком кластерном индексе ты ведешь речь? Нет никакого кластерного, есть самый обычный. Кластерный — это уже детали конкретной реализации, которые опять-таки не имеют никакого отношения к разговору.
Почмуже???

S>>Реализация где все ссылки хранятся на листовом уровне в итоге проще в реализации
M>Так ты о том, почему в B+ все ссылки на данные в листьях? С этим мы уже давно разобрались.

S>> состояние это значения графа на определенный момент.
M>И что не так с этим состоянием и зачем его надо хранить?

Это нужно при хранении ссылок в родительских .
S>> Пример возьмем кластерный индекс с размером записи в 4 кб. Модификация родитеьских страниц будет очень частая. Причем количество таких станиц не менее 20
M>Ну будет частой, при частой вставке, и что? Хочешь сказать, что используя "версионность" можно избежать блокировки страницы на время модификации?
И большая вероятность дидлоков при одновременной модификации и прочей бени.
Нет. Но опять же при версионности нет длинных блокировок. Обеспечивается чистое чтение.
S>> Разумеется но это кратковременные блокировки по аналогии много читателей один писатель.
M>Ну так и при обычном блокировании тоже самое. Всегда накладывается кратковременный latch на страницу только на время ее модификации.
А как обеспечивается чистое чтение, если в начале в базе было одно состояние а на выходе другое

S>> Вспомним что це таке версионность.
M>Да я как-бы не забываю.

S>> Каждая страница имеет свою версию и ссылку на страницу с предыдущей версией.
M>Зачем это нужно при модификации дерева? Приседания вокруг версионности начинаются тогда, когда прикладному коду нужна устаревшая версия страницы, а не самому дереву для модификации. Самому дереву никакой пользы, кроме вреда, от версионности нет.
Состояние данных на на начальном этапе чтения.

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

S>> Да.
M>Боюсь что ты заблуждаешься.

S>>Скажу по секрету, что алгоритм Б+ деревьев делал не зная о их существовании, а версионность прикручивал тоже раньше, а про то что это версионность узнал из статьи синклера.
M>Понимаешь, у себя ты можешь реализовывать что угодно, я рассказываю о том как индексы в реальных БД устроены... Скажем в SQL 2005 даже в режиме версионности никаких плясок с версиями страниц в принципе нет, на сколько мне известно.

Интересно а как с клястерными??? Или он как индекс не расматривается и не берется в расчет????

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

S>Почмуже???
Потомуже!!! Ты еще не забыл о чем разговор? О B+ деревьях ваще, а кластерный индекс — это совершенно конкретная реализация оного дерева в совершенно конкретном сервере. И с точки зрения рассматриваемого вопроса он мало чем отличается от всех остальных, поэтому нет смысла закладываться на то что индекс у нас сугубо кластерный.

S> Это нужно при хранении ссылок в родительских .
В B+ ссылки на данные в родительских не хранятся, или ты не отех ссылках? Тогда о каких?

M>>Ну будет частой, при частой вставке, и что? Хочешь сказать, что используя "версионность" можно избежать блокировки страницы на время модификации?
S> И большая вероятность дидлоков при одновременной модификации и прочей бени.
Там нету дедлоков ваще, как факт. И прочей бени тоже нету.

S> Нет. Но опять же при версионности нет длинных блокировок. Обеспечивается чистое чтение.
Блинский фиг, в третий раз тебе говорю. Нету длинных блокировок там ваще. Даже при работе блокировочника. Страница блокируется только на время модификации самой страницы, хоть в блокировочнике, хоть в версионнике, хоть в SGT, хоть где.

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

S>Состояние данных на на начальном этапе чтения.
Для дерева это нужно только в том случае, если это требуется прикладному коду.

S> Интересно а как с клястерными??? Или он как индекс не расматривается и не берется в расчет????
Все берется, кластерный, в данном случае, от обычного мало чем отличается.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

S>>Почмуже???
M>Потомуже!!! Ты еще не забыл о чем разговор? О B+ деревьях ваще, а кластерный индекс — это совершенно конкретная реализация оного дерева в совершенно конкретном сервере. И с точки зрения рассматриваемого вопроса он мало чем отличается от всех остальных, поэтому нет смысла закладываться на то что индекс у нас сугубо кластерный.

S>> Это нужно при хранении ссылок в родительских .
M>В B+ ссылки на данные в родительских не хранятся, или ты не отех ссылках? Тогда о каких?
Речь о состояниях пошла от этого типа индекса.

M>>>Ну будет частой, при частой вставке, и что? Хочешь сказать, что используя "версионность" можно избежать блокировки страницы на время модификации?
S>> И большая вероятность дидлоков при одновременной модификации и прочей бени.
M>Там нету дедлоков ваще, как факт. И прочей бени тоже нету.
При одновременной модификации она возможна если не накладывать блокировку на весь индекс.

S>> Нет. Но опять же при версионности нет длинных блокировок. Обеспечивается чистое чтение.
M>Блинский фиг, в третий раз тебе говорю. Нету длинных блокировок там ваще. Даже при работе блокировочника. Страница блокируется только на время модификации самой страницы, хоть в блокировочнике, хоть в версионнике, хоть в SGT, хоть где.

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

Хорошо как происходит чтение новой в транзакции при незавершенной транзакции при переполнении страниц????

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

Внутреннее состояние волнует меньше всего. Интерес представляет только чистое чтение. Другое дело как будут хранится данные для отката и востановление. При применении версионности это достаточно элементарно и надежно.
S>>Состояние данных на на начальном этапе чтения.
M>Для дерева это нужно только в том случае, если это требуется прикладному коду.

Оно требуется достаточно часто особенно при долгих вычислениях.
S>> Интересно а как с клястерными??? Или он как индекс не расматривается и не берется в расчет????
M>Все берется, кластерный, в данном случае, от обычного мало чем отличается.
Не совсем. Чёс по таблице и по клястерному индексу нечто другое.

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

S>Речь о состояниях пошла от этого типа индекса.
От какого типа?

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

S> Хорошо как происходит чтение новой в транзакции при незавершенной транзакции при переполнении страниц????
S> То есть при переполнении в незавершенной транзакции родительская страница не меняется???
Меняется. Если тебе так будет понятнее, то с точки зрения СУБД расщепление страницы в случае переполнения — это отдельная транзакция. Вставка нового ключа — это тоже отдельная транзакция и удаление ключа — тоже транзакция. Если все эти действия надо отменить, то выполняются компенсирующие транзакции, для приведения базы в исходное состояние.

S> Ладно мы плохо понимаем друг друга.
Вот уж точно.

S>Версионность только на уровне листовых страниц оправдана.
Нет. И насколько мне известно — так никто не делает, очевидно это не выгодно.

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

S> Оно требуется достаточно часто особенно при долгих вычислениях.
Ты сейчас про что говоришь? Про внешнюю транзакцию или про транзакцию модификации дерева? При модификации дерева никаких долгих вычислений нет.

S> Не совсем.
Совсем.

S> Чёс по таблице и по клястерному индексу нечто другое.
С точки зрения индекса — одно и тоже.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

V>>Можем. Это лучше, чем пожертвовать базой.

M>Базой не надо жертвовать, базой жертвуют только по двум причинам, по кривости рук и убитости диска намертво вместе со всеми бакапами. В обоих этих случаях файлы не спасут.

А можно без вот этих банальностей? Речь идет об актуальности базы. Полные или частичные бэкапы выполняются не каждую минуту. А падение базы означает именно повреждение не только самих файлов данных но и логов (иначе это даже падением не называется). Так что давай обсуждать именно "настоящие" падения.

V>> К тому же... читаем мой ответ Синклеру, все-таки.
M>Твой ответ Синклеру, это вообще что-то...

Аксес — это не БД, а потерять базу Сиквела или Оракла можно только очень этого захотев. И тут я тебе буду рассказывать именно про логи и бакапы, и умение с ними работать.

Ну... раскажи. А еще лучше озвучить причину, по которой это происходит, а не приводить выдержки из BOL. Когда я говорил о наблюдаемых случаях потери данных, то ВСЕГДА имелись вчерашние бэкапы... Но для некоторых применений вчерашний бэкап — это слишком неактульно. И вот что самое интересное, что каждый раз, когда обсуждается именно этот момент, то мне предлагается взять "соответствующее оборудование"... Которое еще недавно стоило под 10-ку зелени, т.е. сам подобный совет являлся абсурдом для большинства мелких и средних фирм, в то время как работать им все-равно надо и к потере данных они так же чуствительны, как и большие.

V>>Все доходчиво объяснил там же.
M>Там ты подробно рассказал как написать свою БД, извиняюсь, ректально, подручными средствами. Зачем, если есть готовая БД?

Дык, вроде несколько раз повторил — зачем. Затем, что есть разные ниши. Например, предполагается использование "обычной", т.е. недорогой техники, без UPS вообще или даже с UPS, но не дорогим, т.е. БЕЗ гальванической развязки с сетью, что означает именно сохранение работоспособности одной из основных причин аппаратных сбоев и сбоев записи на диски. Предложенный мною вариант более живуч в таких "боевых" условиях.

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

V>>Нет, разумеется. Для хранилища нужен только один уникальный аккаунт, которым пользуется только приложение и никто больше.
M>Аккаунт-то может и один, а вот механизмы работы с ним разные в БД и в ФС.

Это вызывает у кого-то трудности?

V>>Так и знал, что не удержишься от этого...

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

Я, пожалуй, не буду, неудобно как-то..

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

, ибо там реально рассказывать нечего. Если ты про механику самого сиквела по обеспечению сохранности данных или про процедуры полных/частичных бэкапов и восстановлений из них, то не трать время. Мне уже не раз пытались рассказывать, и почему-то эти рассказы в конце всегда приходили к совету взять "соответствующую" технику, что почти всегда неприемлимо. (Ты мне лучше про механику Sybase расскажи с их двумя логами, она чуть интереснее будет.

)

V>> можно пример современной надежной СУБД?
M>Да легко, сиквел, DB2, оракл... Надежности на десяток ФС хватит.

Во-первых, ты сравниваешь "в лоб", я же привел схему, которая минимизирует результаты потерь многократно.

Во-вторых, вот выдержка из того ответа:

Ибо для СУБД, повторюсь, аналогичная надежность достигается в случае, если вероятность сбоя = P_fs / K, где P_fs — вероятность сбоя файловой системы, K — кол-во документов в системе. Если документов много...

Если документов "много", то я тупо разделю надежность БД на это "много", и получу не так уж много в итоге.

V>>А то может я просто "не правильным" MS SQL 2000 несколько лет пользусь (а до этого 7-кой несколько лет).
M>Может быть, я-то откуда знаю?

Ты не ответил на это:

А ты помнишь, кстати, что случалось с журналами транзакций на подвисших транзакциях в 7-ке? (в 2000-м с этим полегче, но тоже иногда случалось)

У базы реальные встроенные бока, требующие постоянного наличия админа возле сервака. А ведь речь должна идти о том, чтобы системы были достаточно "самообслуживаемы".

V>>И как же это так получалось, что я почти регулярно минимум раз в год наблюдал падения MS SQL всех мастей (на разных фирмах, за которыми наблюдал)?
M>Руки? Извини, но других идей нет, потому как за последние пять лет я не наблюдал ни одной транзакции потеряной по вине падения БД.

Значит, ты работаешь с соответствующей техникой. Других объяснений нет. Почти у каждой фирмы стоит 1С на MS SQL, и я постоянно слышал о случаях потери данных, субъективно — чаще чем в каждой 10-й фирме. (пусть небольших потерь, за 1 день или несколько часов, но тем не менее...)

M>Может не тех собак ел? Или на форумах просто умеют этих собак готовить? Тем более, как ты сам пишешь, на форумах ты один поешь о ненадежности БД, может в консерватории что?

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

А ты думаешь админы любят хвастаться своими падениями?

Просто я не админ, мне глубоко пофиг "моральная" сторона вопроса. К тому же я работал в таких нишах, где мои системы должны были работать без наличия админов (5-15 рабочих мест операторов) и на совершенно "обычной" технике. Понимаешь, экономика вне пределов МКАД имеет свои особенности, которые прямо или коссвенно влияют на входные ограничения для разработчиков.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

N>если была потеряна оракловая или MSSQL БД то ДБА нужно просто увольнять без выходного пособия за то что небыло включено онлайн архивирование — проще говоря перманентный runtime backup. любая нормальная БД это поддерживает и если все правильно организовано то ничего потеряно не будет даже если контроллер будет глючить или весь RAID массив навернется.

А если НЕТ выделенного ДБА?

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

V>>Только, плиз, не надо меня просвящать насчет журналов транзакций (коих могут быть даже 2 очереди у Sybase), и прочей хренотени. На моей памяти за 5 лет базы "высоконадежного" MS SQL грохались чаще, чем раз в год (по моим наблюдениям за 3-мя фирмами оптово-розничной торговли).

N>скорее всего это были аппаратные сбои, хотя от MSSQL можно ждать чего угодно. нормальный бэкап все эти проблемы решает раз и навсегда.

"Нормальный" бэкап, это тот, который не требует присмотра админа. Который выполняется по расписанию или же нажатием одной кнопки из программы. При этом, конкретно для MS SQL необходимо отследить наличие "зависших" транзакций. При наличии оных сделать ПОЛНЫЙ бэкап (а не частичный), а потом грохнуть текущие логи, ибо они не сжимаются в присутствии "зависших" транзакций и растут с неприличной скоростью.

N>все это автоматически и без всякого гемороя делает БД. описаное решение на самом деле ничего не гарантирует.

Оно более живуче на "обычной" технике. Т.е. при более высокой вероятности потери данных, сами эти потери не столь болезненны, чем в случае с БД.

V>>ИМХО, простейшими ср-вами достигается надежность, гораздо выше, чем надежность СУБД. Ибо для СУБД, повторюсь, аналогичная надежность достигается в случае, если вероятность сбоя = P_fs / K, где P_fs — вероятность сбоя файловой системы, K — кол-во документов в системе. Если документов много, то по этой формуле СУБД сильно проигрывают, даже с самым журналированным в 2 очереди своим транзакционным хранилищем.

N>с нормальным инкрементальным онлайн бэкапом вероятность потери данных в БД равна нулю.

Не забываем, что речь о системе документооборота, где вес каждой транзакции может составлять десятки мег. Я не представляю себе онлайн бэкап в такой системе без ежедневного постоянного присутствия админа. Особенно, если над документами поддерживаются макрооперации (глобальные поиск и замена или смена стилей форматирования сразу у сотен документов).

V>>И еще. Вы пробовали когда-нибудь сжимать (shrink) многогигабайтные (десятки гиг) файлы данных MS SQL? А когда там хранились блобы по 1-10 метра? В общем, это такая жопа, по сравнению с которой стандартная дефрагментация диска выглядит наивной забавой (и к тому же может вестись в фоновом режиме).

N>это проблемы MSSQL, оракл умеет перестраивать данные в онлайне и в принципе может даже хранить блобы в отдельных файлах.

Единственная полезная мысль.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>А если НЕТ выделенного ДБА?

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

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

V>"Нормальный" бэкап, это тот, который не требует присмотра админа. Который выполняется по расписанию или же нажатием одной кнопки из программы. При этом, конкретно для MS SQL необходимо отследить наличие "зависших" транзакций. При наличии оных сделать ПОЛНЫЙ бэкап (а не частичный), а потом грохнуть текущие логи, ибо они не сжимаются в присутствии "зависших" транзакций и растут с неприличной скоростью.

"нормальный" быкап это тот который вообще делается всегда, не по расписанию или по кнопке а постоянно. админу нужно только вовремя менять ленточки. полный бэкап базы это вообще нонсенс. если MSSQL себя действительно так отвратно ведет — выкиньте его, в оракле с этим все нормально.

V>Оно более живуче на "обычной" технике. Т.е. при более высокой вероятности потери данных, сами эти потери не столь болезненны, чем в случае с БД.

на "обычной" т.е. не серверной технике вообще ни о какой живучести речи быть не может. а внутренние структуры самой файловой системы тоже легко могут полететь при аппаратном сбое.

V>Не забываем, что речь о системе документооборота, где вес каждой транзакции может составлять десятки мег. Я не представляю себе онлайн бэкап в такой системе без ежедневного постоянного присутствия админа. Особенно, если над документами поддерживаются макрооперации (глобальные поиск и замена или смена стилей форматирования сразу у сотен документов).

а я вполне себе представляю. то что у вас документы содержат в себе внутри стиль а не ссылки на стиль — это проблема проектирования.

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

M>Ну Аксес не база, а вот что касается сиквела и оракла... почему вы не делали регулярных дифов и бакапов логов в течении дня, если бакап за сутки безнадежно стар? вы делали бакап лога после падения базы? если делали, что почему не накатили на восстановленную БД?

сюда: http://www.rsdn.ru/Forum/Message.aspx?mid=1756824&only=1

V>>И вот в чем основная жопа, так это в случае, если потеряли базу — то потеряли вообще все.
M>Я повторюсь, но чтобы потерять базу надо очень постараться.

Нет, нужна лишь обычная техника и интенсивная работа.

V>>Только, плиз, не надо меня просвящать насчет журналов транзакций (коих могут быть даже 2 очереди у Sybase), и прочей хренотени.
M>Именно это мы тебе и будем рассказывать. И про журналы и про то что их можно (и нужно) выносить на разные диски, и про то что их нужно бакапить и про прочую хренотень.

На разные диски еще можно файлы данных разносить. Еще можно зеркальную реплику вести и кучу еще всякого. А еще есть требование "поставить и забыть", т.е. вложить в систему достаточно ср-в самообслуживания и самовосстановления, т.к. никакого ДБА не будет. Я про ср-ва MS SQL по обеспечению данных знаю не по наслышке потому как не только пользовался утилитами, но и прилично манипулировал программно SQL DMO, для создания собственных аналогов этих утилит, адаптированных под "пользователей", и которые вызываются юзверями прямо из программы. Без понимания чего и как, согласись, было бы трудновато.

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

Да, хуже. но я там вроде формулу приводил, относительно числа документов

Понимаешь, в твоей системе БД будет работать ОДИНАКОВО со всеми документами, т.е. перерасход ресурсов в 90% случаев, когда этого не требуется. В то время как в системе документооборота перерасход ресурсов требуется лишь для весьма важных документов.

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

Для чего нужна такая градуировка? Да просто потому, что речь может идти о многих тысячах документов весом в мегабайты. Т.е. если полностью все это хранить в БД, то могут потребоваться "специальные" конфигурации аппаратуры.

M>Что делать если в БД по каким-то причинам не прошла транзакция с метаинформацией о записаном документе? Что делать, если упала вся БД (она ведь у нас теперь падает)?

Чем меньше БД физически, тем меньше вероятность ее падения. В предложенной системе БД будет миниатюрная.

V>>- для важных документов создаются копии в репозитории-зеркале. Обычно это как минимум другой винчестер (но лучше — другой хост).
V>>- регулярно в фоновом режиме производится сканирование и проверка контрольных сумм файлов в хранилище (хранилищах). В случае наличия правильного файла в одном из зеркал, все восстанавливается. Если нет, то в базу заносится соотв. запись и посылаются оповещения админам.
M>То есть пишем еще ручную систему зеркалирования?

Скрипт на десяток строк.

V>>Ибо для СУБД, повторюсь, аналогичная надежность достигается в случае, если вероятность сбоя = P_fs / K, где P_fs — вероятность сбоя файловой системы, K — кол-во документов в системе.
M>Неверно. Во-первых надежность твоей системы будет всегда хуже БД, потому что она зависит и от надежности БД и от надежности каждого из файлов, а во-вторых, ты не учел еще надежность написанной в ручную системы восстановления, и вообще всей системы, и вероятность отсутствия в ней ошибок.

А ну да, хороший аргумент. При наличии ошибок в программе мы можем потерять данные даже в самой надежной БД.

M>Иными словами, ты предлагаешь написать свою собственную БД, со своей же системой журналирования и отказоустойчивости. Не проще ли грамотно настроить готовую? Уверяю, результат окажется не хуже.

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

V>>И еще. Вы пробовали когда-нибудь сжимать (shrink) многогигабайтные (десятки гиг) файлы данных MS SQL?
M>А зачем их сжимать?

Хороший вопрос. Поздравляю, вы из другой реальности.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

AVK>А что будет, если сбойнет FAT или MFT? А что будет если сбойнет MBR? Или ты хочешь сказать что такого не бывает?

А ответа все нет. Зато старая песня о супернадежности ФС продолжается.

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

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

V>>А если НЕТ выделенного ДБА?

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

N>а если на большем mission critical хранилище данных нет выделенного ДБА то надо увольнять, соот-но технического директора, CIO, далее по списку. в нормальных системах "подвисшие транзакции" никому не мешают и откатываются по таймауту. что значит физические размеры жесткого диска? он там что — один чтоли? должен быть такой запас физического места (которое стоит сейчас копейки), которое позволяет за несколько дней до начала напряга послать мыло админу и он вставит очередной диск в массив.

Как всегда, подобные обсуждения свелись к советам насчет аппаратуры. Поздравляю, Вы не оригинальны.
Можно вопрос на засыпку? А если на фирме НЕТ технического директора и не планируется?

V>>"Нормальный" бэкап, это тот, который не требует присмотра админа. Который выполняется по расписанию или же нажатием одной кнопки из программы. При этом, конкретно для MS SQL необходимо отследить наличие "зависших" транзакций. При наличии оных сделать ПОЛНЫЙ бэкап (а не частичный), а потом грохнуть текущие логи, ибо они не сжимаются в присутствии "зависших" транзакций и растут с неприличной скоростью.

N>"нормальный" быкап это тот который вообще делается всегда, не по расписанию или по кнопке а постоянно. админу нужно только вовремя менять ленточки. полный бэкап базы это вообще нонсенс. если MSSQL себя действительно так отвратно ведет — выкиньте его, в оракле с этим все нормально.

Диктую большими буквами. Если в БД осталяь незакрытая транзкция (надежно воспроизводимо для MS SQL 7.0 и частенько для MS SQL 2000), то единственный способ избавиться от нее — это полный бэкап базы. Об этом сказано в BOL и это так и есть, к сожалению.

Менять ленточки — это вообще пестня.

Как ты собрался выпускать такую систему на рынок для "широкого" потребления?
Для широкого применения гораздо проще заточить систему для скидывания на DVD-R, но вот как раз в этом случае крайне неудобно возиться со слишком затянувшимися diff-ами, особенно в случае восстановления. Поэтому я рекомендовал юзверям своих систем делать полный бэкап как минимум раз в месяц. (Как раз входило в процедуру закрытия периода).

V>>Не забываем, что речь о системе документооборота, где вес каждой транзакции может составлять десятки мег. Я не представляю себе онлайн бэкап в такой системе без ежедневного постоянного присутствия админа. Особенно, если над документами поддерживаются макрооперации (глобальные поиск и замена или смена стилей форматирования сразу у сотен документов).

N>а я вполне себе представляю. то что у вас документы содержат в себе внутри стиль а не ссылки на стиль — это проблема проектирования.

Да нет, люди хотят пользоваться обычными WORD-ами и EXCEL-ами, причем, хранить там не только "свои", но и "чужие" документы.
Если бы речь шла о документообороте только "своих" документов, я бы их хранил в каком-нить XML и использовал бы какой-нить CVS/SVN на основе БД для управления версиями. А юзверям бы давал интерфейс того же Ворда и Екселя. Причем, прямо из своей программы:

(обрати внимание на TAB-control

)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>А можно без вот этих банальностей?
Нельзя. В них-то и суть.

V> Речь идет об актуальности базы. Полные или частичные бэкапы выполняются не каждую минуту.
Бакап лога раз в пол-часа, даже на самой загруженой базе отъедает доли процента.

V> А падение базы означает именно повреждение не только самих файлов данных но и логов (иначе это даже падением не называется). Так что давай обсуждать именно "настоящие" падения.
Давай.

V>Ну... раскажи. А еще лучше озвучить причину, по которой это происходит, а не приводить выдержки из BOL. Когда я говорил о наблюдаемых случаях потери данных, то ВСЕГДА имелись вчерашние бэкапы... Но для некоторых применений вчерашний бэкап — это слишком неактульно.
Так воспользуемся выдержкой из БОЛ. Почему не делались более частые бакапы логов и дифов, если суточный слишком неактуально?

V>И вот что самое интересное, что каждый раз, когда обсуждается именно этот момент, то мне предлагается взять "соответствующее оборудование"...
Оборудование тоже не маловажную роль играет, если требуется такая исключительная надежность какую ты тут расписываешь.

V>Дык, вроде несколько раз повторил — зачем.
Как-то неубедительно.

V>Затем, что есть разные ниши. Например, предполагается использование "обычной", т.е. недорогой техники, без UPS вообще или даже с UPS, но не дорогим, т.е. БЕЗ гальванической развязки с сетью, что означает именно сохранение работоспособности одной из основных причин аппаратных сбоев и сбоев записи на диски. Предложенный мною вариант более живуч в таких "боевых" условиях.
Нет, он гораздо менее живучь, и гораздо более дорог в обслуживании. Потому как: выше вероятность потерять один из многочисленных документов в отдельном файле, есть вероятность рассогласования документов между собой и документов с метаданными, выше вероятность того, что система в принципе написана с ошибками, кроме разработчика системы никто не в состоянии эту систему обслуживать, кто-то должен определять какие файлы критичные, а какие нет, то есть человеческий фактор и опять-таки вероятность ошибки, ect...

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

V>Это вызывает у кого-то трудности?

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

V> Мне уже не раз пытались рассказывать,
Ну, в таком случае тебе действительно пора воспользоваться советами, а не искать фатальные недостатки в готовых системах..

V> и почему-то эти рассказы в конце всегда приходили к совету взять "соответствующую" технику, что почти всегда неприемлимо.
Техника это конечно не плохо, но ничего запредельного там не требуется...

V>(Ты мне лучше про механику Sybase расскажи с их двумя логами, она чуть интереснее будет.

)
Не на много, тем более что внизу все тот же ARIES лежит..

V>Во-первых, ты сравниваешь "в лоб", я же привел схему, которая минимизирует результаты потерь многократно.
Многократно они не минимизирует, скорее наоборот, плюс ты не учел стоимость разработки и обслуживания.

V>Если документов "много", то я тупо разделю надежность БД на это "много", и получу не так уж много в итоге.
Это в том случае, если надежность одного документа неважна и этим документом можно пожертвовать. А вот если документом жертвовать нельзя, то тут не делить, а умножать надо, что надежность во столько же раз понижает.

V>Ты не ответил на это:

А ты помнишь, кстати, что случалось с журналами транзакций на подвисших транзакциях в 7-ке? (в 2000-м с этим полегче, но тоже иногда случалось)

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

V>У базы реальные встроенные бока, требующие постоянного наличия админа возле сервака. А ведь речь должна идти о том, чтобы системы были достаточно "самообслуживаемы".
Так твоя система так же требует наличия специально обученного человека, который знает как она устроена, а нормальную СУБД достаточно настроить один раз и потом подходить к ней раз в пол-года.

V>Значит, ты работаешь с соответствующей техникой. Других объяснений нет. Почти у каждой фирмы стоит 1С на MS SQL, и я постоянно слышал о случаях потери данных, субъективно — чаще чем в каждой 10-й фирме. (пусть небольших потерь, за 1 день или несколько часов, но тем не менее...)
Никакой запредельной техники у мен нет, даже скази далеко не на всех серверах имеется.

V>А ты думаешь админы любят хвастаться своими падениями?

Просто я не админ, мне глубоко пофиг "моральная" сторона вопроса.
Еще как любят. Хлебом не корми, дай только рассказать, какой отстой этот сервер.

V>К тому же я работал в таких нишах, где мои системы должны были работать без наличия админов (5-15 рабочих мест операторов) и на совершенно "обычной" технике. Понимаешь, экономика вне пределов МКАД имеет свои особенности, которые прямо или коссвенно влияют на входные ограничения для разработчиков.
Никаких проблем. Грамотно настроенная СУБД на стандартных задачах отлично справляется и без админа. А вот если твоя система развалится, то кто ее собирать будет?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

AVK>А что будет, если сбойнет FAT или MFT? А что будет если сбойнет MBR? Или ты хочешь сказать что такого не бывает?

Если сбойнет ФАТ — то это даже прикольно... Не, действительно, я понимаю, если денег на дорогую железку нет, но не понимаю, зачем файлы в FAT хранить.

А если сбойнет NTFS, то идем сюда: www.ntfs.com. Эту программу написал парень из нашей компании из Севастополя, пока что является одной из самой лучшей для таких дел, и она вытаскивает все, что возможно. Например, если ты несколько раз изменял и сохранял один и тот же файл и на диске было достаточно места, то ты восстановишь ВСЕ версии файла, а потом отсортируешь по дате изменения. Кстати, если хранить файлы в некоем текстовом виде (для оффиса можно XML ныне), то даже бывает можно спасти данные, восстановив только часть файла (или части файла разных его версий), что совершенно не работает в случае бинарных файлов БД. Вот я когда говорил о живучести, то имел в виду эти моменты — уменьшение "болезненности" сбоев.

Если же сбойнет MBR, то мы берем бумажку, на которой предварительно записали конфигурацию разделов и за 5 сек восстанавливем. Или же можно воспользоваться одной из утилит сохранения/восстановления MBR.

Бывает действительно все. Вероятность сбоя некоего куска данных зависит от:
— размера интересующего куска данных
— частоты и характера обращений (если постоянно пишем — то вероятность сбоя высока, FAT — живой пример)

В случае с MBR — это миниатюрный read-only блок данных.

----
Мне мой товарищ из одного Киевского банка рассказывал, как им пришлось по битам восстанавливать бинарные файлы MS SQL. У них навернулось поточное резервирование, а пока чинили — сбойнул RAID

. Разумеется, в форумах об этом ни слова, ибо обсуждение таких вещей — это будет побег клиентов из такого банка, но мне была живописно обрисована хакерская по характеру нудная работа разбора в течении недели бинарного формата файлов MS SQL и восстановление всего лишь (!!!) нескольких потеряных минут работы банка.

А то там Merle утверждает, что ничего быть не может

А в описанной мною системе им пришлось бы по битам восстанавливать только 1 (один!!!) файл в конкретно том случае. Наверняка у этого файла нашлась бы копия на машине у того, кто последний его редактировал.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Нет, нужна лишь обычная техника и интенсивная работа.
На обычной технике мне такого видеть не доводилось, даже при самой интенсивной работе.

V> А еще есть требование "поставить и забыть", т.е. вложить в систему достаточно ср-в самообслуживания и самовосстановления, т.к. никакого ДБА не будет.
И в чем проблема?

V>Да, хуже. но я там вроде формулу приводил, относительно числа документов

Да вот неправильная какая-то формула..

Она верна только в том случае если можно пожертвовать документом и если документы никак не связаны между собой и нестрашно, если документы и метаданные немного разъедутся.

V>Понимаешь, в твоей системе БД будет работать ОДИНАКОВО со всеми документами, т.е. перерасход ресурсов в 90% случаев, когда этого не требуется. В то время как в системе документооборота перерасход ресурсов требуется лишь для весьма важных документов.
Кто определяет "важность" документа? где гарантия что он не ошибется?

V>А ну да, хороший аргумент. При наличии ошибок в программе мы можем потерять данные даже в самой надежной БД.
Можем, в этом и суть. И создавая собственный механизм вместо БД ты эту вероятность увеличиваешь.

V> Не знаю как сейчас с надежными железками, но по ценам 2-х летней давности — это за десятку зелени.
Это сопоставимо с потерями от рассогласования и падения базы? Если да, то ответ очевиден.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

V>>Ну... раскажи. А еще лучше озвучить причину, по которой это происходит, а не приводить выдержки из BOL. Когда я говорил о наблюдаемых случаях потери данных, то ВСЕГДА имелись вчерашние бэкапы... Но для некоторых применений вчерашний бэкап — это слишком неактульно.
M>Так воспользуемся выдержкой из БОЛ. Почему не делались более частые бакапы логов и дифов, если суточный слишком неактуально?

100 раз тут уже повторил. Из-за встроенных боков MS SQL в случае подвисших транзакций. Логи быстро растут и не сбрасываются. Т.е. в нормальном режиме сделал бэкап лога — можно его сбросить. А в случае подвисшей транзакции этот лог во-первых не сбрасывается, во-вторых — ОЧЕНЬ БЫСТРО растет в размерах. Делать каждые пол-часа гигабайтные бэкапы — это перебор, ИМХО. Вернее, это надо следить за этим всем. А следить некому.

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

Требуется просто надежность. Я исхожу из понимания рельно низкой надежности используемой техники и вся задача сводится к минимизации потерь, которые обязательно будут.

V>>Затем, что есть разные ниши. Например, предполагается использование "обычной", т.е. недорогой техники, без UPS вообще или даже с UPS, но не дорогим, т.е. БЕЗ гальванической развязки с сетью, что означает именно сохранение работоспособности одной из основных причин аппаратных сбоев и сбоев записи на диски. Предложенный мною вариант более живуч в таких "боевых" условиях.
M>Нет, он гораздо менее живучь, и гораздо более дорог в обслуживании. Потому как: выше вероятность потерять один из многочисленных документов в отдельном файле

Что значит "легче"? Если с настроенными правами в папке несанкционированно потерялся файл-документ, то это сбой. NTFS об этом тут же узнает. Можно принудительно запустить внеочередную сверку зеркал (хотя она и сама в фоне все исправит).

M> есть вероятность рассогласования документов между собой и документов с метаданными,

это не так страшно, как потеря данных. Опять же, рассогласование возможно только в случае сбоев.

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

Про ошибки я уже делал замечание. В случае ошибки программы мы можем потерять данные в самой надежной системе.

V>>А надежность базы данных, напротив, проявляется именно тогда, когда в связке работает целый комплекс мер (и потраченных на железки денег в т.ч.) денег... Да, действительно, в подобных случаях БД на порядки надежнее.
M>И твоя система так же предлагает свой комплекс мер, только собственноручных, со всеми вытекающими последствиями. У БД есть фатальный недостаток?

В случае оперирования многогигабайтными блобами — да. Это требования к аппаратуре для достижения адекватной надежности.

V>>Это вызывает у кого-то трудности?

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

Неужели ты никогда не делал application-account для MS SQL? Аналогии не видишь? Если аккаунт только 1 и он фиксированный локальный, трудностей я не вижу.

V>>Во-первых, ты сравниваешь "в лоб", я же привел схему, которая минимизирует результаты потерь многократно.
M>Многократно они не минимизирует, скорее наоборот, плюс ты не учел стоимость разработки и обслуживания.

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

V>>Ты не ответил на это:

А ты помнишь, кстати, что случалось с журналами транзакций на подвисших транзакциях в 7-ке? (в 2000-м с этим полегче, но тоже иногда случалось)

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

Да понимаешь какое дело (если понимаешь, конечно)

Эти подвисшие транзакции — болезнь клиент-серверных архитектур, так что тут надо архитектуры обсуждать, а не разработчиков. Понятное дело, что в случае выделенного сервера приложений организовать подвисшую транзакцию — это умудриться надо. А в случае клиент-сервера — достаточно лишь одного сценария, где прикладная клиентская программа ОБЯЗАННА раскидать в рамках одной транзакции данные по нескольким таблицам. А данных может быть много, а у нас был модем (со склада), и обрывы связи в неподходящие моменты.

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

V>>У базы реальные встроенные бока, требующие постоянного наличия админа возле сервака. А ведь речь должна идти о том, чтобы системы были достаточно "самообслуживаемы".
M>Так твоя система так же требует наличия специально обученного человека, который знает как она устроена, а нормальную СУБД достаточно настроить один раз и потом подходить к ней раз в пол-года.

Тому, как располагаются файлы "обучены" многие. Система потребует "специально обученного человека", то бишь спеца только в случае сбоя. А вот "большие" БД действительно требуют регулярного присутствия спецов. В моем варианте БД тоже присутствует, только она "маленькая" и действительно способна всю свою сознательную жизнь прожить на автоматическом обслуживании.

V>>А ты думаешь админы любят хвастаться своими падениями?

Просто я не админ, мне глубоко пофиг "моральная" сторона вопроса.
M>Еще как любят. Хлебом не корми, дай только рассказать, какой отстой этот сервер.

Так есть обсуждения падений или нет, че-то не понял...

V>>К тому же я работал в таких нишах, где мои системы должны были работать без наличия админов (5-15 рабочих мест операторов) и на совершенно "обычной" технике. Понимаешь, экономика вне пределов МКАД имеет свои особенности, которые прямо или коссвенно влияют на входные ограничения для разработчиков.
M>Никаких проблем. Грамотно настроенная СУБД на стандартных задачах отлично справляется и без админа. А вот если твоя система развалится, то кто ее собирать будет?

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Мне мой товарищ из одного Киевского банка рассказывал, как им пришлось по битам восстанавливать бинарные файлы MS SQL. У них навернулось поточное резервирование, а пока чинили — сбойнул RAID

.

Банк, который на главном сервере держит RAID без возможности восстановления ... Вобщем не хочу даже комментировать.

Что же касается остального — приводить в качестве альтернативы средствам обеспечения надежности БД, в которые вложены сотни миллионов баксов, шароварные утилитки ... Ну вы сами себе злобные буратины. Я только рекомендую задуматься над тем, что современные БД используются широчайше в тех же банках (в том числе и MSSQL) с громадным трафиком и что то я не слышал про банковские решения, основанные на файлах.

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

V>>Да, хуже. но я там вроде формулу приводил, относительно числа документов

M>Да вот неправильная какая-то формула..

Она верна только в том случае если можно пожертвовать документом и если документы никак не связаны между собой и нестрашно, если документы и метаданные немного разъедутся.

Они не "разъедуться" случайно. Это возможно только лишь из-за сбоя. Я ведь могу открыть транзакцию в БД, записать новую версию файла в ФС, проверить запись чтением и только потом закоммитить эту новую версию. Если будет сбой, то в локальном кеше юзверя файл останется и он может попробовать закоммитить его еще раз. Если сбой повторяемый — то что-то случилось серьезное, тут в любом случае требуется присутствие спеца-админа.

V>>Понимаешь, в твоей системе БД будет работать ОДИНАКОВО со всеми документами, т.е. перерасход ресурсов в 90% случаев, когда этого не требуется. В то время как в системе документооборота перерасход ресурсов требуется лишь для весьма важных документов.
M>Кто определяет "важность" документа? где гарантия что он не ошибется?

На этот вопрос отвечает понятие класса документа и расписанные роли. За "не важные" документы отвечают операторы. За более важные — более высокие лица.

V>> Не знаю как сейчас с надежными железками, но по ценам 2-х летней давности — это за десятку зелени.
M>Это сопоставимо с потерями от рассогласования и падения базы? Если да, то ответ очевиден.

Всей базы? У нас же тоже и бэкапы и все остальное. Я склонен расчитывать на потерю одного документа как самый плохой сценарий (хотя даже это маловероятно из-за того, что в локальном кеше юзверей в системах документооборота должны оставаться файлы дольше, чем периоды бэкапов). В любом случае, даже если за несколько лет потеряется 1 документ, то это всяко дешевле 10 тыс зелени. Документы ведь не из вакуума беруться. У документов бывают источники, и даже твердые копии, т.е. путей восстановления много и они отличаются лишь потраченным временем. А через несколько лет эксплуатации можно и на более новую и доступную технику перейти, которая может стоить уже не так много.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>>И твоя система так же предлагает свой комплекс мер, только собственноручных, со всеми вытекающими последствиями. У БД есть фатальный недостаток?

V>В случае оперирования многогигабайтными блобами — да. Это требования к аппаратуре для достижения адекватной надежности.

не

"фатальный недостаток" — он только один — ее (БД) делали не мы

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>Мне мой товарищ из одного Киевского банка рассказывал, как им пришлось по битам восстанавливать бинарные файлы MS SQL. У них навернулось поточное резервирование, а пока чинили — сбойнул RAID

.

AVK>Банк, который на главном сервере держит RAID без возможности восстановления ... Вобщем не хочу даже комментировать.

Подробностей не спрашивал, какая конфигурация RAID была, наверняка с восстановлением (5-я например). Мне сам факт сбоя RAID описывали как то, что вообще никогда не может быть.

В соответствующих эмоциях.

AVK>Что же касается остального — приводить в качестве альтернативы средствам обеспечения надежности БД, в которые вложены сотни миллионов баксов, шароварные утилитки ... Ну вы сами себе злобные буратины. Я только рекомендую задуматься над тем, что современные БД используются широчайше в тех же банках (в том числе и MSSQL) с громадным трафиком и что то я не слышал про банковские решения, основанные на файлах.

С последним я не спорю. Но ведь решение должно быть адекватно требованиям... и возможностям конечных пользователей.

Моя т.з. исходит из нескольких предпосылок:
— документооборотом нужно управлять не только в больших компаниях
— средние и мелкие компании не готовы выкладывать >$10k за сервак (или еще + столько же за зеркало)
— сам характер хранимых обычных документов (вплоть до чертежей AUTOCAD с embedded Ексель-таблицами) подразумевает, что документы могут быть большими, иногда — очень большими. Насыщенный графикой документ Word может потянуть на 5-10 мег, чертежи — на 20.
— стандартное решение на БД будет порождать очень большие логи транзакций, которыми НЕОБХОДИМО будет управлять... В одной из торговых фирм с всего 20-ю операторами даже без документооборота база росла на 50-500М в день. Логи могут расти быстрее в несколько раз (скажем, каааак начнут задним числом складские документы по 1500 строк перепроводить, вот базе весело). В случае с файлами я тоже представляю себе макро-операции над файлами, типа глобальных поиска и замены.
— для этой нишы установка и разворачивание системы должны быть автоматизированны, что нереально в случае БД, которая будет работать с большими объемами данных, потребуется нехилый спец на разворот системы.

Если же автор самого первого поста собирается разрабатывать системы для крупных корпоративных клиентов (типа банков), то БД вкупе с комплексом стандартных мер вполне нормальное решение, тем более, что оно ПРОЩЕ.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Мне мой товарищ из одного Киевского банка рассказывал, как им пришлось по битам восстанавливать бинарные файлы MS SQL.

почему же все-таки мыши колются, но продолжают жрать кактус, то бишь ставить в подавляющем большинстве oracle или mssql?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>Мне мой товарищ из одного Киевского банка рассказывал, как им пришлось по битам восстанавливать бинарные файлы MS SQL.

OE>почему же все-таки мыши колются, но продолжают жрать кактус, то бишь ставить в подавляющем большинстве oracle или mssql?

Наверно дешево, по сравнению с DB2, например. Не знаю как сейчас, но лет пять назад она стоила запредельно.

И еще, плохая масштабируемость вниз

Т.е. MS SQL адекватно работает к с небольшим кол-вом данных, так и с "огромным", а для DB2 только минимальный размер оперативки — мег. "Простые смертные" девелоперы типа нас банально не ставили и не пробовали ее и не игрались с ней, вот и не знают и не умеют. Я с MS SQL (и ораклом иногда) вожусь еще со времен P2-200MHz (128МB RAM), и вполне нормально было для разработки.

Я вот первый раз DB2 проставил на своей машине в 2000-м, было 512RAM, оно еле пыхало под юнихами и после MSSQL и Оракла выглядело крайне "недружественно".

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Они не "разъедуться" случайно.
Кто сказал? Ты не можешь этого гарантировать.

V> Я ведь могу открыть транзакцию в БД, записать новую версию файла в ФС, проверить запись чтением и только потом закоммитить эту новую версию.
Тебе не надо рассказывать чем плохи длинные транзакции в БД? И что файл волне может грохнутся уже после твоей проверки и ты узнаешь об этом только тогда, когда соберешся прочитать его в следующий раз?

V> Если будет сбой, то в локальном кеше юзверя файл останется и он может попробовать закоммитить его еще раз.
Это если ты определил этот сбой и правильно обработал.

V> За более важные — более высокие лица.
Более высокие лица не ошибаются? документы менее высоких лиц не так важны для компании?

V>Всей базы? У нас же тоже и бэкапы и все остальное.
Ты уверен, что твои бакапы так же надежны как встроенные в СУБД? Я вот совсем нет.

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

V>100 раз тут уже повторил. Из-за встроенных боков MS SQL в случае подвисших транзакций.
Откуда у вас подвисшие транзакции? Без них как-то проще.

V> Вернее, это надо следить за этим всем. А следить некому.
Не надо следить, надо просто подвисших транзакций недопускать.

V>Требуется просто надежность. Я исхожу из понимания рельно низкой надежности используемой техники и вся задача сводится к минимизации потерь, которые обязательно будут.
Для просто надежности, требуется просто железо и просто бд. И никаких критичных потерь.

V>Что значит "легче"? Если с настроенными правами в папке несанкционированно потерялся файл-документ, то это сбой. NTFS об этом тут же узнает. Можно принудительно запустить внеочередную сверку зеркал (хотя она и сама в фоне все исправит).
То есть деньги на зеркала все же есть? Тогда что-ты тут пел поповоду дороговизны железа?

V>это не так страшно, как потеря данных.
Да, не так. Это гораздо страшнее чем потеря. Потому что потеря, как правило, вылезает сразу, а по кривым данным ты можешь очень долго отчеты строить, пока это дело наружу не вылезет в самый ответственный момент.

V> Опять же, рассогласование возможно только в случае сбоев.
Только вероятность сбоев здесь опять-таки выше, потому что ты работаешь с двумя независимыми системами вместо одной.

V>Про ошибки я уже делал замечание. В случае ошибки программы мы можем потерять данные в самой надежной системе.
И я уже на него отвечал. Ненадо еще дополнительно вносить вероятность ошибки в механизм хранения, надежности это не прибавит, а наоборот, заметно ухудшит.

V>В случае оперирования многогигабайтными блобами — да. Это требования к аппаратуре для достижения адекватной надежности.
Нет там никаких запредельных требований к аппаратуре. И в любом случае твоя система здесь не будет надежнее и ты не учитываешь стоимость разработки и обслуживания — железо дешевле...

V>Неужели ты никогда не делал application-account для MS SQL? Аналогии не видишь? Если аккаунт только 1 и он фиксированный локальный, трудностей я не вижу.

Делал, потому и вижу трудности.

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

V>Да понимаешь какое дело (если понимаешь, конечно)

Эти подвисшие транзакции — болезнь клиент-серверных архитектур, так что тут надо архитектуры обсуждать, а не разработчиков.
А архитектуры кто разрабатывает? Или это реальность данная нам в ощущениях?

V>В наиболее "ответственных" местах я работал через промежуточные временные таблицы, что решало проблему. Надо ли говорить, насколько это удорожало разработку? Особенно в сравнении с той элементарной системой, о которой речь.
Да вот что-то не выглядит твоя система элементарной, скорее уж на сервер приложений все переписать проще было или разрулить транзакции так чтобы они не зависели от обрывов связи.

V>Тому, как располагаются файлы "обучены" многие. Система потребует "специально обученного человека", то бишь спеца только в случае сбоя.
Как располагаются файлы вообще — да, а вот как они располагаются именно в твоей системе, кроме разработчиков мало кто представляет.

V> А вот "большие" БД действительно требуют регулярного присутствия спецов.
Присутствия спецов требует только база в которую регулярно вносятся изменения.

V>Так есть обсуждения падений или нет, че-то не понял...

Есть, конечно, только невосстановимость там исключительно по вине рук.

V>Если моя система "развалиться", то бишь потеряет файл, то система скажет — какой это файл (мы ведь храним метаинформацию, контрольные суммы и т.д.).
Это если файл и метаинформация не разъехались и если этот файл "важный". К тому же мы тут падение "серьезное" обсуждаем, когда и данные и лог накрылись? ТАк в этом случае в своей системе ты не один файл потеряешь, а в лучшем случае десяток, причем резервные копии тоже уедут.

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

V>И ср-вами обычного эксплорера даже далеко не продвинутые юзвери вернут файл на место.
Откуда они узнают где его обычное место и как они узнают что именно его нужно восстанавливать и какую версию этого файла?

V>Или же вообще можно добавить прямо в программу опцию, типа — force commit недавний документ. Вот и все дела.
Ну-ну. Успехов. Если это у вас работает, то искренне рад, но сам я такое делать вряд ли буду. Мне проще БД грамотно настроить.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

AVK>>Банк, который на главном сервере держит RAID без возможности восстановления ... Вобщем не хочу даже комментировать.

V>Подробностей не спрашивал, какая конфигурация RAID была, наверняка с восстановлением (5-я например).

Откуда тогда потерянные данные? Видишь ли, мне приходилось несколько раз работать с банками — на главных серверах не то что RAID-5, там в обязательном порядке была возможность на ходу диски, процессоры и БП менять. Это не говоря уж о резервных серверах. Но даже если гипотетически что то потеряется, всегда есть возможность восстановить все операции по логам (не SQL-сервера, а собственно системы).

V>С последним я не спорю. Но ведь решение должно быть адекватно требованиям... и возможностям конечных пользователей.

А что это интересно за требования, в которых указано что нужно затратить немало времени, чтобы получить значительно менее надежное хранилище?

V>- документооборотом нужно управлять не только в больших компаниях

И?

V>- средние и мелкие компании не готовы выкладывать >$10k за сервак (или еще + столько же за зеркало)

На старой работе сервак стоил что то в районе 4К. Проблем со сбоями за 4 года не было вобще, хотя пара дисков при этом отдала концы. Что я делал не так? Сервер rsdn стоит где то в районе 3К, тоже никаких громадных логов и гигабайтных дифференциальных бекапов ни разу не наблюдалось. Что мы делаем не так?

V>- сам характер хранимых обычных документов (вплоть до чертежей AUTOCAD с embedded Ексель-таблицами) подразумевает, что документы могут быть большими, иногда — очень большими. Насыщенный графикой документ Word может потянуть на 5-10 мег, чертежи — на 20.

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

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

AVK>Сервер rsdn стоит где то в районе 3К, тоже никаких громадных логов и гигабайтных дифференциальных бекапов ни разу не наблюдалось. Что мы делаем не так?

Ты действительно не знаешь, откуда громадные логи беруться или прикалываешься?
А характер работы с данными какой у вас?

У вас же внесли — и забыли, потом read-only только. А представь, например, перепровести складскую накладную недельной/месячной давности (т.е. заново товар расписать). Оно же тянет удаление и расписывание по-новой всех движений, что были после перепроводимого документа. Это единовременное удаление/создание/изменение сотен тысяч строк движений в базе. И таких фокусов стабильно по нескольку в день (у крупных оптовых торгующих фирм). Вряд ли бы я особо обратил на эти проблемы сейчас, но тогда был 1999-й, система была клиент-серверной (кстати, RSDN — не клиент-сервер, а N-tier

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

V>>- сам характер хранимых обычных документов (вплоть до чертежей AUTOCAD с embedded Ексель-таблицами) подразумевает, что документы могут быть большими, иногда — очень большими. Насыщенный графикой документ Word может потянуть на 5-10 мег, чертежи — на 20.

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

Я вообще склонен работать с документами в структурированном виде (подход LotusNotes). Т.е. хранить только данные и ссылку на шаблон-визуализатор. Но такая система зато не столь универсальна. А вообще, есть же готовые системы документооборота от MS, не интересно узнать, как они там документы хранят?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>100 раз тут уже повторил. Из-за встроенных боков MS SQL в случае подвисших транзакций.
M>Откуда у вас подвисшие транзакции? Без них как-то проще.

Уже говорил — откуда. От систем клиент-сервер. И как можно избежать подвисшей транзакции, когда нам необходимо распихать данные по более чем одной таблице именно в рамках транзакции? Ведь если пихаешь var-binary, то ты не сможешь сгенерировать SQL-текст и просто транзакционно выполнить этот батч. Кстати, даже в N-tier такого можно добиться, только гораздо сложнее

V>> Вернее, это надо следить за этим всем. А следить некому.
M>Не надо следить, надо просто подвисших транзакций недопускать.

Хорошо оно конечно вслух размышлять...

V>>Требуется просто надежность. Я исхожу из понимания рельно низкой надежности используемой техники и вся задача сводится к минимизации потерь, которые обязательно будут.
M>Для просто надежности, требуется просто железо и просто бд. И никаких критичных потерь.

Опыт многих моих знакомых говорит обратное. Если речь идет о надежности БД, то она проявляется только как результат целого комплекса мер, где надежные (и дорогие) железки — мера №1.

M>То есть деньги на зеркала все же есть? Тогда что-ты тут пел поповоду дороговизны железа?

Зеркало файл-сервера — это может быть просто чей-то компьютер, с настроенными правами доступа на один из дисков. Или даже просто старый нешустрый никому не нужный комп. Ты не путай с зеркалами БД.

V>>это не так страшно, как потеря данных.
M>Да, не так. Это гораздо страшнее чем потеря. Потому что потеря, как правило, вылезает сразу, а по кривым данным ты можешь очень долго отчеты строить, пока это дело наружу не вылезет в самый ответственный момент.

Отчеты по документам не строят. Их по данным строят.

V>> Опять же, рассогласование возможно только в случае сбоев.
M>Только вероятность сбоев здесь опять-таки выше, потому что ты работаешь с двумя независимыми системами вместо одной.

В любом случае, твой аргумент работает только в том случае, если мы не знаем о сбоях.

V>>В случае оперирования многогигабайтными блобами — да. Это требования к аппаратуре для достижения адекватной надежности.
M>Нет там никаких запредельных требований к аппаратуре. И в любом случае твоя система здесь не будет надежнее и ты не учитываешь стоимость разработки и обслуживания — железо дешевле...

Насчет "железо дешевле" согласен только последние пару лет. В 2000-м у нас программисты если получали $300 в месяц, то это было неплохо. А компы для того, что говоришь ты, стоили заоблачно.

V>>Неужели ты никогда не делал application-account для MS SQL? Аналогии не видишь? Если аккаунт только 1 и он фиксированный локальный, трудностей я не вижу.

M>Делал, потому и вижу трудности.

Можно подробнее с этого места? Мне наоборот, показалось очень удобным.

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

Самое время пенисами начинать мерятся, то бишь размерами базы

Желательно — на "моем" поле, то бишь без всяческих гипотетических возможностей горячего наращивания емкости дискового массива. А лучше — вообще без массивов. А то твои слова звучат как из другой реальности.

V>>Да понимаешь какое дело (если понимаешь, конечно)

Эти подвисшие транзакции — болезнь клиент-серверных архитектур, так что тут надо архитектуры обсуждать, а не разработчиков.
M>А архитектуры кто разрабатывает? Или это реальность данная нам в ощущениях?

Да, примерно так. CORBA образца 1998-го года была еще не очень применима. DCOM и COM+ сложно настраивать в доменных сетях. До сих пор не так уж много спецов, которые хорошо это умеют. Если ты собрался что-то выпустить в 1999-м, причем, нацелился не на сверхбогатые копмании, а просто на фирмы, коих очень много, но коих 1С не в состоянии удовлетворить, то ты возьмешь клиент-сервер, если хочешь, чтобы сам факт выпуска системы состоялся.

M>... или разрулить транзакции так чтобы они не зависели от обрывов связи.

можно подробнее, а то не понятно. Я вот хочу транзакционно изменить данные в 2-х таблицах (изменить/удалить/добавить). Как мне это разрулить?

V>>Тому, как располагаются файлы "обучены" многие. Система потребует "специально обученного человека", то бишь спеца только в случае сбоя.
M>Как располагаются файлы вообще — да, а вот как они располагаются именно в твоей системе, кроме разработчиков мало кто представляет.

Надуманно звучит. Вон мыло из Outlook (Outlook Express) после падения компа многие неоднократно успешно восстанавливали.

V>> А вот "большие" БД действительно требуют регулярного присутствия спецов.
M>Присутствия спецов требует только база в которую регулярно вносятся изменения.

Без комментариев...

V>>Так есть обсуждения падений или нет, че-то не понял...

M>Есть, конечно, только невосстановимость там исключительно по вине рук.

Или имеющихся ресурсов.

V>> Учитывая бэкапы и саму специфику таких систем, например — хранить в локальном кеше клиента недавние редактируемые документы (причем, хранить гораздо дольше, чем периоды бэкапов), мы просто узнаем по мета-информации из БД (БД ведь не развалится) о том, на чьей машине этот файл.
M>Кто сказал, что БД не развалится? У нас же БД падает теперь... А если БД не падает, то и пляски вокруг отдельных файлов не нужны.

Диктую большими буквами. Вероятность падения маленькой БД минимальна, даже на "обычной" технике. Я вообще не помню, чтобы маленькие БД падали.

V>>Или же вообще можно добавить прямо в программу опцию, типа — force commit недавний документ. Вот и все дела.
M>Ну-ну. Успехов. Если это у вас работает, то искренне рад, но сам я такое делать вряд ли буду. Мне проще БД грамотно настроить.

Тем не менее, описанный прием может довести надежность практически до абсолюта и в системе, построенной на БД. Вот так и отучаются думать...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>Они не "разъедуться" случайно.
M>Кто сказал? Ты не можешь этого гарантировать.

О-о-о, опять переходим на обсуждение ошибок программы. Тем не менее, считаю, что "случайно" не разъедутся. Я точно так же могу блоб в базу не по тому ключу закинуть.

V>> Я ведь могу открыть транзакцию в БД, записать новую версию файла в ФС, проверить запись чтением и только потом закоммитить эту новую версию.
M>Тебе не надо рассказывать чем плохи длинные транзакции в БД? И что файл волне может грохнутся уже после твоей проверки и ты узнаешь об этом только тогда, когда соберешся прочитать его в следующий раз?

V>>Всей базы? У нас же тоже и бэкапы и все остальное.
M>Ты уверен, что твои бакапы так же надежны как встроенные в СУБД? Я вот совсем нет.

Да, мои бэкапы так же надежны, потому как имеют такую же физическую природу. В обоих случаях — бинарники больших размеров. Такие вот обычные беззащитные бинарники. Хошь на диске храни, хошь на DVD, хошь на стриммере... Одинаково для любого случая.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Уже говорил — откуда. От систем клиент-сервер.
Ну вот мы и добрались до сути проблемы. Виновата не БД и ее надежность, а неадекватная архитектура. При этом проблемы опять-таки не с надежностью, а с администрированием.

V> И как можно избежать подвисшей транзакции, когда нам необходимо распихать данные по более чем одной таблице именно в рамках транзакции?
Передать все одним батчем.

V>Ведь если пихаешь var-binary, то ты не сможешь сгенерировать SQL-текст и просто транзакционно выполнить этот батч.
Почему? Можно, только осторожно. И что мешало уйти от клиент-сервера, если с ним так неудобно?

V>Хорошо оно конечно вслух размышлять...
Ну дык, у меня-то таких проблем не было, вот и остается только рассуждать..

V>Опыт многих моих знакомых говорит обратное. Если речь идет о надежности БД, то она проявляется только как результат целого комплекса мер, где надежные (и дорогие) железки — мера №1.
Меро N1 — это голова и руки разработчика и админа. железки это конечно тоже хорошо, но не на столько.

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

V>Отчеты по документам не строят. Их по данным строят.
А данные откуда берутся?

V>Насчет "железо дешевле" согласен только последние пару лет. В 2000-м у нас программисты если получали $300 в месяц, то это было неплохо. А компы для того, что говоришь ты, стоили заоблачно.
Ну вот мы уже съехали к 2000-му году, а в топике речь шла про систему которую только предстоит разработать. Голь конечно на выдумки хитра, но я не пойму, ты просто оправдываешься почему вы поступили тогда именно так что ли?

V>Можно подробнее с этого места? Мне наоборот, показалось очень удобным.
У тебя есть две независимые системы в которых надо раздать права, пусть и для одного аккаунта, то есть, двойная работа и по раздаче и по контролю, что все сделано правильно.

V>можно подробнее, а то не понятно. Я вот хочу транзакционно изменить данные в 2-х таблицах (изменить/удалить/добавить). Как мне это разрулить?
Передать на сервер одним батчем.

V>Диктую большими буквами. Вероятность падения маленькой БД минимальна, даже на "обычной" технике. Я вообще не помню, чтобы маленькие БД падали.
С какого размера БД считается мальнькой?

V>Тем не менее, описанный прием может довести надежность практически до абсолюта и в системе, построенной на БД.
Так только до абсолютной ненадежности довести можно и до бесполезной траты времени и ресурсов.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

V>О-о-о, опять переходим на обсуждение ошибок программы.
С них и не уходили, так ка кэто тоже очень важный аспект проблемы.

V> Тем не менее, считаю, что "случайно" не разъедутся. Я точно так же могу блоб в базу не по тому ключу закинуть.
Можешь. Только размер кода, который тебе придется наколбасить заметно больше и он те такой тривиальный, а значит и шанс ошибиться существенно выше и, самое печальное, что ошибка эта вылезти может далеко не сразу.

V>Да, мои бэкапы так же надежны, потому как имеют такую же физическую природу. В обоих случаях — бинарники больших размеров. Такие вот обычные беззащитные бинарники. Хошь на диске храни, хошь на DVD, хошь на стриммере... Одинаково для любого случая.
Не одинаково. Потому что помимо бинарников есть еще собственно механизмы их согласованного сохранения и восстановления, и тут я как-то больше доверяю системам используемым в тысячах реальных проектов, чем написанным на коленке.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

V>>Ведь если пихаешь var-binary, то ты не сможешь сгенерировать SQL-текст и просто транзакционно выполнить этот батч.
M>Почему? Можно, только осторожно. И что мешало уйти от клиент-сервера, если с ним так неудобно?

Ну озвучь ты плиз подробности этого "осторожно". Весь день интригуешь. Я делал через промежуточные временные таблицы и был не в восторге от подобной необходимости на каждый чих.

V>>Хорошо оно конечно вслух размышлять...
M>Ну дык, у меня-то таких проблем не было, вот и остается только рассуждать..

Остается позавидовать.

Я уже понял, что ты страшно далек от народа.

V>>Опыт многих моих знакомых говорит обратное. Если речь идет о надежности БД, то она проявляется только как результат целого комплекса мер, где надежные (и дорогие) железки — мера №1.
M>Меро N1 — это голова и руки разработчика и админа. железки это конечно тоже хорошо, но не на столько.

Не знаю. В BOL настолько все ясно для тупых расписано и в форумах уже столько обсосано, что упрекнуть в неграмотности можно только совсем зеленых новичков. Мне неинтересно обсуждать подробности того, что именно я делал. Я уже неоднократно в разные годы обсуждал. Все было вполне адекватно, в конечном итоге любое обсуждение скатывалось на советы из области железок. Любое. Более того, большинство из тех, кто в пытался "поучать" реально имели гораздо меньше опыта по восстановлению данных, ибо их техника никогда не падала. На такой технике хоть в файлах все храни — фиолетово.

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

Мы так и будем по кругу ходить? А что с этими логами потом делать? Я же уже говорил о случаях многомегабайтных файлах логов. Стандартный винт забъется под завязку за пару дней, если гигабайтный лог каждые пол-часа делать (он ведь не сбрасывается на тех самых пресловутых зависших транзакциях).

V>>Отчеты по документам не строят. Их по данным строят.
M>А данные откуда берутся?

Из БД.

V>>Насчет "железо дешевле" согласен только последние пару лет. В 2000-м у нас программисты если получали $300 в месяц, то это было неплохо. А компы для того, что говоришь ты, стоили заоблачно.
M>Ну вот мы уже съехали к 2000-му году, а в топике речь шла про систему которую только предстоит разработать. Голь конечно на выдумки хитра, но я не пойму, ты просто оправдываешься почему вы поступили тогда именно так что ли?

Да нет, показываю работоспособность решения.

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

V>>Можно подробнее с этого места? Мне наоборот, показалось очень удобным.
M>У тебя есть две независимые системы в которых надо раздать права, пусть и для одного аккаунта, то есть, двойная работа и по раздаче и по контролю, что все сделано правильно.

Раздать право на одну папку и поставить политику "распространять на дочерние объекты". Думаю, секунд за 7 вложусь.

В принципе, могу и как install-action прикрутить, чтобы никому не пришлось ручками это делать.

V>>Диктую большими буквами. Вероятность падения маленькой БД минимальна, даже на "обычной" технике. Я вообще не помню, чтобы маленькие БД падали.
M>С какого размера БД считается мальнькой?

По мне до 50-100 мег.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>О-о-о, опять переходим на обсуждение ошибок программы.
M>С них и не уходили, так ка кэто тоже очень важный аспект проблемы.

Да я понял, понял. Вечный спор программиста и админа. Самое время начать обсуждать применимость GUID в качестве ключа.

V>> Тем не менее, считаю, что "случайно" не разъедутся. Я точно так же могу блоб в базу не по тому ключу закинуть.
M>Можешь. Только размер кода, который тебе придется наколбасить заметно больше и он те такой тривиальный, а значит и шанс ошибиться существенно выше и, самое печальное, что ошибка эта вылезти может далеко не сразу.

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

V>>Да, мои бэкапы так же надежны, потому как имеют такую же физическую природу. В обоих случаях — бинарники больших размеров. Такие вот обычные беззащитные бинарники. Хошь на диске храни, хошь на DVD, хошь на стриммере... Одинаково для любого случая.
M>Не одинаково. Потому что помимо бинарников есть еще собственно механизмы их согласованного сохранения и восстановления, и тут я как-то больше доверяю системам используемым в тысячах реальных проектов, чем написанным на коленке.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Да я понял, понял.
Боюсь что нет.

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

V>Нет, не надо ссылаться на тысячи реальных проектов.
Почеему же не надо? Ты же ссылаешься на свой богатый опыт безвинно загубленых БД?

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

V>Ну озвучь ты плиз подробности этого "осторожно". Весь день интригуешь.
Ничего я не интригую, я уже писал — передаешь все одним батчем, да и пулинг не забывать отключать.

V>Я делал через промежуточные временные таблицы и был не в восторге от подобной необходимости на каждый чих.

Все равно проще, чем свою систему резервирования для файлов городить.

V> Я уже понял, что ты страшно далек от народа.
Да вот как-то раньше незамечал, скорее наоборот.

V> Мне неинтересно обсуждать подробности того, что именно я делал.
Тем не менее ты исключительно этим и занимаешься.

V>Мы так и будем по кругу ходить?
А надо? Мы же уже выяснили, что проблема не в бакапах, а в кривой архитектуре... И причем здесь БД?

V>>>Отчеты по документам не строят. Их по данным строят.
M>>А данные откуда берутся?
V>Из БД.
И откуда они в БД попадают?

V>Да нет, показываю работоспособность решения.

То что оно в принципе работает, я сомневаюсь мало, видели и не такое, я сомневаюсь в надежности такого решения.

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

V>Раздать право на одну папку и поставить политику "распространять на дочерние объекты". Думаю, секунд за 7 вложусь.

В принципе, могу и как install-action прикрутить, чтобы никому не пришлось ручками это делать.
И так каждый раз с каждым типом документов?

V>По мне до 50-100 мег.
То есть все что больше этого размера не заслуживает хранения в БД? Ну, вот, скажем, та же RSDN-овская база, о которой AVK писал, 3 гига объемом и только и делает что растет. Согласно твоей логике мы должны вынести все тексты сообщений в отдельные файлы и хранить их там, для увеличения надежности...

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

V>>Ну озвучь ты плиз подробности этого "осторожно". Весь день интригуешь.
M>Ничего я не интригую, я уже писал — передаешь все одним батчем, да и пулинг не забывать отключать.

Я про varbinary спрашивал. Размер батча в MS SQL — 4k в юникодном режиме.

V>>>>Отчеты по документам не строят. Их по данным строят.
M>>>А данные откуда берутся?
V>>Из БД.
M>И откуда они в БД попадают?

Из системы ввода первички.

V>>Раздать право на одну папку и поставить политику "распространять на дочерние объекты". Думаю, секунд за 7 вложусь.

В принципе, могу и как install-action прикрутить, чтобы никому не пришлось ручками это делать.
M>И так каждый раз с каждым типом документов?

Ага, понял момент нестыковки. В общем нет, доступ к классам документов — на уровне всей системы (базы). Само же приложение работает с файлами только лишь по одному специальному аккаунту. Юзвери напрямую к файлам не общаются, они получают к себе копии файлов и отсылают их системе для сохранения.

V>>По мне до 50-100 мег.
M>То есть все что больше этого размера не заслуживает хранения в БД? Ну, вот, скажем, та же RSDN-овская база, о которой AVK писал, 3 гига объемом и только и делает что растет. Согласно твоей логике мы должны вынести все тексты сообщений в отдельные файлы и хранить их там, для увеличения надежности...

Согласно моей логике, если бы у вас была обычная техника, а не за 4k зелени, и если бы сообщений были единицы тысяч, а размер каждого — многие метры, то да. Если же эти условия не выполняются, то в БД лучше. А если бы характер работы RSDN был другой — например, данные активно редактировались бы, то можно и 2 базы сделать — для архивного контента + OLAP и для OLTP.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Я про varbinary спрашивал. Размер батча в MS SQL — 4k в юникодном режиме.
Размер батча 8k*PacketSize, народ по двести метров в XML-е гоняет, и ничего...

V>>>>>Отчеты по документам не строят. Их по данным строят.
M>>>>А данные откуда берутся?
V>>>Из БД.
M>>И откуда они в БД попадают?
V>Из системы ввода первички.
То есть из документов?

V>Ага, понял момент нестыковки. В общем нет, доступ к классам документов — на уровне всей системы (базы). Само же приложение работает с файлами только лишь по одному специальному аккаунту. Юзвери напрямую к файлам не общаются, они получают к себе копии файлов и отсылают их системе для сохранения.
Ну это же все надо настраивать, отдельно в базе, отдельно в ФС...

V>Согласно моей логике, если бы у вас была обычная техника, а не за 4k зелени,
До недавнего времени там целерон девятисотый был, баксов за 400 вся система... Да и сейчас до 4 штук мы больше тысячи недобираем...

V> и если бы сообщений были единицы тысяч,
То есть пока единицы тысячь, то можно в файлах, а как за миллион перевалило, то опять в БД?

V> а размер каждого — многие метры, то да. Если же эти условия не выполняются, то в БД лучше.
Но ведь изначально речь шла о почтовой системе, а там, как правило, нету многих метров.. размер среднего почтового сообщения как раз равен размеру сообщения на rsdn...

V>А если бы характер работы RSDN был другой — например, данные активно редактировались бы, то можно и 2 базы сделать — для архивного контента + OLAP и для OLTP.
Это уже совсем отдельный разговор...

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

V>>Я про varbinary спрашивал. Размер батча в MS SQL — 4k в юникодном режиме.
M>Размер батча 8k*PacketSize, народ по двести метров в XML-е гоняет, и ничего...

V>>>>>>Отчеты по документам не строят. Их по данным строят.
M>>>>>А данные откуда берутся?
V>>>>Из БД.
M>>>И откуда они в БД попадают?
V>>Из системы ввода первички.
M>То есть из документов?

Чаще всего нет! На самом деле реально пока существует приличный разрыв м/у данными в БД и документами обычных MS Office. В общем, это отдельная тема... Скорее, ближе к OLE и организации делопроизводства. Просто "обычная" учетная система обслуживает очень маленькую разновидность документов. Я еще не видел ни одной системы, которая полностью и качественно обслуживала приказы, заявления, контракты и т.п.

К тому же бывают еще такие стандарты и протоколы EDI-направления. Но они у нас широко не используются, и ввод первички по большей части — ручной. Для преодоления этого нужно повсеместное широкое применение стандартов B2B-EDI. Ключевое слово здесь — широкое. Ибо избавиться от ручного ввода первички можно только в случае, если партнер поддерживает совместимый стандарт.

V>>Ага, понял момент нестыковки. В общем нет, доступ к классам документов — на уровне всей системы (базы). Само же приложение работает с файлами только лишь по одному специальному аккаунту. Юзвери напрямую к файлам не общаются, они получают к себе копии файлов и отсылают их системе для сохранения.
M>Ну это же все надо настраивать, отдельно в базе, отдельно в ФС...

В базе и так придется настраивать, а отдельно в ФС — не вижу проблем настроить разрешения для всего одной учетной записи для всего одного хранилища.

V>>Согласно моей логике, если бы у вас была обычная техника, а не за 4k зелени,
M>До недавнего времени там целерон девятисотый был, баксов за 400 вся система... Да и сейчас до 4 штук мы больше тысячи недобираем...

До недавнего времени и база ваша вроде бы менее двух гиг была — копейки по сути.

V>> и если бы сообщений были единицы тысяч,
M>То есть пока единицы тысячь, то можно в файлах, а как за миллион перевалило, то опять в БД?

стоило ли комментировать часть сообщения? даже не понятно что ответить, ибо в такой постановке сама озвучка вопроса нелепа...

V>> а размер каждого — многие метры, то да. Если же эти условия не выполняются, то в БД лучше.
M>Но ведь изначально речь шла о почтовой системе, а там, как правило, нету многих метров.. размер среднего почтового сообщения как раз равен размеру сообщения на rsdn...

Хотя, я как раз "зацепился" на ветку о документообороте. Кто-то поднял одну тему, мы обсуждаем все соседние.

Да, по существу коментария так и не было.

V>>А если бы характер работы RSDN был другой — например, данные активно редактировались бы, то можно и 2 базы сделать — для архивного контента + OLAP и для OLTP.
M>Это уже совсем отдельный разговор...

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Как всегда, подобные обсуждения свелись к советам насчет аппаратуры. Поздравляю, Вы не оригинальны.
V>Можно вопрос на засыпку? А если на фирме НЕТ технического директора и не планируется?

Ээээ... Держитесь подальше от таких фирм, мой вам совет

V>Менять ленточки — это вообще пестня.

Как ты собрался выпускать такую систему на рынок для "широкого" потребления?

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

V>Да нет, люди хотят пользоваться обычными WORD-ами и EXCEL-ами, причем, хранить там не только "свои", но и "чужие" документы.

Что в вашем понимании "документооборот" ?

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

V>>Можно вопрос на засыпку? А если на фирме НЕТ технического директора и не планируется?

VVK>Ээээ... Держитесь подальше от таких фирм, мой вам совет

Совет хороший, разумеется. Жаль, что таких фирм — 90% потенциального рынка (торговые средние и мелкооптовые предприятия).

V>>Да нет, люди хотят пользоваться обычными WORD-ами и EXCEL-ами, причем, хранить там не только "свои", но и "чужие" документы.

VVK>Что в вашем понимании "документооборот" ?

а в твоем?

Документооборот — это автоматизированные сценарии работы с документами. Конкретная степень автоматизации (и набор возможностей) зависит от расшифровки понятия "документ", которая может быть весьма широкой. Если тебе показалось, что я ограничиваю понятие документа лишь порождениями офисных ворда и екселя, то это заблуждение. Кстати, один из разработанных модулей на одной из предыдущих работ — это модуль по обслуживанию контрактов и договоров (самая интересная область в автоматизированном документообороте, ИМХО, после EDI). Никакими MS-офисными документами там и не пахло, ну разве что в момент формирования твердой копии.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

N>полный бэкап базы это вообще нонсенс.

Why not differential backups?

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

V> Просто "обычная" учетная система обслуживает очень маленькую разновидность документов. Я еще не видел ни одной системы, которая полностью и качественно обслуживала приказы, заявления, контракты и т.п.
То есть документы о которых ты ведешь ресь, можно сравнить с аттачментами в почтовой системе? Как бы к реальной отчетности они отношения не имеют, но вес придают...

V>В базе и так придется настраивать, а отдельно в ФС — не вижу проблем настроить разрешения для всего одной учетной записи для всего одного хранилища.
Ну вот юзер Вася имеет правво обращаться к документу "А", а к документу "Б" не имеет, а юзер Дима — наоборот... Как разрулить? А если при этом у юзера Вася обломалась запись документа, как он из своей локальной копии документ восстановит, если у него нет соответствующих прав?

V>До недавнего времени и база ваша вроде бы менее двух гиг была — копейки по сути.
Ну да, полтора гига, что, примерно, на полтора порядка больше озвученных тобой 50-100 метров...

V>>> и если бы сообщений были единицы тысяч,
M>>То есть пока единицы тысячь, то можно в файлах, а как за миллион перевалило, то опять в БД?
V>стоило ли комментировать часть сообщения?
А почему не стоило?

V> даже не понятно что ответить, ибо в такой постановке сама озвучка вопроса нелепа...
Что здесь нелепого? Я полностью следую твоей логике — ты выдвигаешь ряд условий в которых БД хуже твоей системы, я привожу реальную ситуацию, которая под твои условия не подходит и делаю предположение, что, наверное, в этом случае БД все-таки подходит, в чем я ошибся?

V>Хотя, я как раз "зацепился" на ветку о документообороте.
Где в этой ветке, до тебя, хоть слово про документооборот??

V>Да, по существу коментария так и не было.
По какому существу? По существу мы давно уже уползли от существа...

V>И я про то.
Про что?

V> Зачем натягивать мою логику на "отдельный разговор"?
Это уже не логика, это уход от темы...

V> Для меня вообще догм и предпочтений нет.
Каждый волен демонстрировать свободу творчества...

V> Каждый случай для меня — тот самый отдельный разговор.
Тогда не надо натягивать свое решение, своей ситуации, в качестве ответа на чужую задачу совершенно другого класса и в других условиях. Рассматривай данную тему, как разговор отдельный от твоего опыта с документооборотом.

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

... [RSDN@Home 1.2.0 alpha rev. 619]

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

V>> Просто "обычная" учетная система обслуживает очень маленькую разновидность документов. Я еще не видел ни одной системы, которая полностью и качественно обслуживала приказы, заявления, контракты и т.п.
M>То есть документы о которых ты ведешь ресь, можно сравнить с аттачментами в почтовой системе? Как бы к реальной отчетности они отношения не имеют, но вес придают...

Странный у тебя взгляд на вещи. По твоему, документы — это только цифры? Например, приказ по предприятию сделать 9-е Марта выходным днем — вполне себе документ.

V>>В базе и так придется настраивать, а отдельно в ФС — не вижу проблем настроить разрешения для всего одной учетной записи для всего одного хранилища.
M>Ну вот юзер Вася имеет правво обращаться к документу "А", а к документу "Б" не имеет, а юзер Дима — наоборот... Как разрулить? А если при этом у юзера Вася обломалась запись документа, как он из своей локальной копии документ восстановит, если у него нет соответствующих прав?

Ну уж озадачил по-взрослому... Оставляю эту "сверхсложную" диллему в качестве домашнего задания... ну или попроси какого-нибудь студента подкинуть идеи на этот счет.

V>>До недавнего времени и база ваша вроде бы менее двух гиг была — копейки по сути.
M>Ну да, полтора гига, что, примерно, на полтора порядка больше озвученных тобой 50-100 метров...

Озвученные мною цифры относились к "маленькой" базе, причем здесь это? Ну не "маленькая", а "средненькая".

V>> даже не понятно что ответить, ибо в такой постановке сама озвучка вопроса нелепа...
M>Что здесь нелепого? Я полностью следую твоей логике — ты выдвигаешь ряд условий в которых БД хуже твоей системы, я привожу реальную ситуацию, которая под твои условия не подходит и делаю предположение, что, наверное, в этом случае БД все-таки подходит, в чем я ошибся?

Слушай, а нужен ли нам форум, чтобы продолжать маяться подобной вот ерундой?

То есть все что больше этого размера не заслуживает хранения в БД? Ну, вот, скажем, та же RSDN-овская база, о которой AVK писал, 3 гига объемом и только и делает что растет. Согласно твоей логике мы должны вынести все тексты сообщений в отдельные файлы и хранить их там, для увеличения надежности...

Никакой моей логике ты не следовал, так что причем здесь вообще RSDN-овская база?

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

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

V>> Каждый случай для меня — тот самый отдельный разговор.
M>Тогда не надо натягивать свое решение, своей ситуации, в качестве ответа на чужую задачу совершенно другого класса и в других условиях. Рассматривай данную тему, как разговор отдельный от твоего опыта с документооборотом.

Еще раз, идем в самое начало. Была просьба накидать мысли, где в каких случаях приемлимо одно, а где другое (ФС vs БД). Я и накидал. Причем, весьма четко обрисовал условия, при которых хранение инф. в файлах считаю обоснованным. Специально прошелся еще раз по ветке и так и не понял, при чем тут ваша база RSDN и куда лепить эти твои последние замечания?

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

На какую задачу?

-----------------
В общем, свои мысли я высказал и добавить мне нечего. Могу лишь сделать очевидный вывод за читателя, если кто успел потерять нить беседы за 5-ю последними бесполезными обменами междометиями.

1. Из личного опыта установлено, что если база хранит "большие" блобы, то при определенных условиях может начаться быстрый бесконтрольный рост размеров логов транзакций, что накладывает определенные требования на систему резервирования и сами сценарии резервирования.
2. Эти "определенные" условия были отличительной чертой клиент-серверной архитектуры, но! Большинство даже нынешних серверов приложений способны спровоцировать описанную ситуацию. Любая ситуация, где в прикладной логие создается транзакция и выполняется более, чем одна операция по модификации данных в рамках транзакции, но не в рамках одного батча — преттендент на получение описанного эффекта. (С той оговоркой, что чем короче длительность транзакций, тем меньше вероятность нарваться на описанную ситуацию)
3. Вероятность проявления вышеописанного эффекта приводит к тому, что требуется присутствие админа возле базы, что было неприемлимым условием. Во многих случаях применений систем Автора вероятность возникновения подобного эффекта была очень высока, ввиду низкой надежности техники и сети, что потребовало доп. мер по устранению эффекта. Как одна из мер — вынести большие блобы из БД.
4. Автор согласен хранить любыые данные в БД, если технические или организационные условия позволяют.
5. Для систем "будущего", с "большими и бесконечными" ресурсами проблема не исчезает, а лишь меняет свои характеристики. Например, "большой" документ может означать для нынешний условий блоб размером от 100MB-300М (видео, "сырое" аудио, растровые макеты высокого разрешения и т.д.).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Vladimir V Kochetkov wrote:
> V>Как всегда, подобные обсуждения свелись к советам насчет аппаратуры.
> Поздравляю, Вы не оригинальны.
> V>Можно вопрос на засыпку? А если на фирме НЕТ технического директора и
> не планируется?
> Ээээ... Держитесь подальше от таких фирм, мой вам совет
Да, да. Держитесь подальше, как можно дальше.
(Чтобы мы могли им продавать свой софт).

Таких фирм — подавляющее _большинство_, особенно в регионах. Так что же
теперь, наплевать на огромный рынок потенциальных клиентов?

Posted via RSDN NNTP Server 2.0

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

GZ>>Классификаторов с сохранением пути.
M>NS как раз и есть оно самое.
В честь чего? NS это некоторое дерево, которое подстроено так чтобы удобно было выгребать данные ветками. Как результат, при вставке новой ноды приходится его апдейтить не по детски. Системы где в ноде лежит полный путь от рута до self, такой проблемы нет. Существует проблема переноса веток. Приходится апдейтить все дочерние элементы. Для OP c xml это было неважно.

GZ>>Набор аттрибутов.
M>Набор атрибутов — это кортеж, а не тип кортежей.
Набор аттрибутов — это домен.

M>Ты хочешь сказать, что в одном отношении получаемом после OP в кортежах разный набор атрибутов? Тогда бы это не было отношением и реляционный движек не смог бы с этим работать.
Смотря что является результатом. То что до операции UDX или после UDX.

GZ>>Не зря. Пробовал.
M>Как можно таблицу не запихнуть в БД?
Проблема не в таблице, а в интерпретации. Таблицу можно и в экцел запихнуть. Проблема существует в построении предиката для получения всех дочерних элементов первого уровня. Типа select @x.query('/*'). Далее проблема в получении различных объектов, когда у нас может быть как объект person так и объект automobile. Хотя второе для моей постановки не нужно было.

GZ>>Любую операцию SQL2000 можно описать набором базовых реляционных операций.
M>Не-а. Например, как раз засада с доменами — современные СУБД, позволяют выполнять операции с разными доменам, чего с точки зрения реляционной алгебры быть не должно. Одно из Коддовских SQL flaw, если я правильно помню...
Если ты о потери идентифицируемости доменов, то ее можно описать реляционными операциями.

M>>>Что в нем нереляционного?
GZ>>Не путай результат, и работу.
M>Я-то как раз ничего не путаю, все это время я говорю исключительно о результате, а ты почему-то пытаешься приплести именно механику работы самого OP. В данном случае меня совершенно не интересует как OP работает, о чем я уже писал ни раз. Как работает — это другой разговор, можем обсудить отдельно.
Дык результат можно посмотреть на экране. А вот работа, даже на уровне плана запросов значительно интересней. И к тому же непонятно что ты называешь OP. Для меня это всего лишь таблица. Ты по моему под этим подразумеваешь механизм полностью. Давай сначало в этом разберемся. И что является то что ты называешь результатом: набор реляционных операций которые построены по xquery и будут выполнены реляционным механизмом, или реляционное отношение как результат выполнения xquery.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

V>Ты действительно не знаешь, откуда громадные логи беруться или прикалываешься?
V>А характер работы с данными какой у вас?

V>У вас же внесли — и забыли, потом read-only только. А представь, например, перепровести складскую накладную недельной/месячной давности (т.е. заново товар расписать). Оно же тянет удаление и расписывание по-новой всех движений, что были после перепроводимого документа. Это единовременное удаление/создание/изменение сотен тысяч строк движений в базе. И таких фокусов стабильно по нескольку в день (у крупных оптовых торгующих фирм). Вряд ли бы я особо обратил на эти проблемы сейчас, но тогда был 1999-й, система была клиент-серверной (кстати, RSDN — не клиент-сервер, а N-tier

Из всего перечисленого не понял двух вещей. Во первых — какая тут разница между клиент-сервер и N-tier. Ну а во вторых — зачем тебе нужны были подвисшие транзакции?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>Из всего перечисленого не понял двух вещей. Во первых — какая тут разница между клиент-сервер и N-tier. Ну а во вторых — зачем тебе нужны были подвисшие транзакции?

Давай так, ты прочтешь эту ветку, а потом опять спросишь. А то мне придется много copy&paste для тебя делать...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>То есть все что больше этого размера не заслуживает хранения в БД? Ну, вот, скажем, та же RSDN-овская база, о которой AVK писал, 3 гига объемом

Да бог с тобой. 3 гига она была года два назад. Сейчас 7.5. Лог на старой БД был > 3 гигов (это к вопросу о коротких логах на rsdn). На текущей лог 600М, видимо 2005 сиквел в этом отношении получше стал.

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

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

V>Чаще всего нет! На самом деле реально пока существует приличный разрыв м/у данными в БД и документами обычных MS Office.

InfoPath спасет отца русской демократии?

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

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

V>Согласно моей логике, если бы у вас была обычная техника, а не за 4k зелени

Во-первых не за 4, а за 3, во-вторых основные деньги там потрачены на производительность и юнитовое исполнение, в третьих это самое обычное самосборное железо, ничего необычного в нем нет, такое железо может себе позволить даже маленькая контора, не говоря уж о тех, для которых потеря нескольких минут смерти подобно.

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

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

GZ>>Из всего перечисленого не понял двух вещей. Во первых — какая тут разница между клиент-сервер и N-tier. Ну а во вторых — зачем тебе нужны были подвисшие транзакции?

V>Давай так, ты прочтешь эту ветку, а потом опять спросишь. А то мне придется много copy&paste для тебя делать...
Прочитал. Во многом с Merle согласен. Это ошибка архитектуры. Для справки, в то время я также работал с тиражирумым документооборотом. Особых проблем у пользователей не возникало. Подобные проблемы решались до разработки и в процессе. Теперь по сути.

1. Все имеет свою стоимость. Это настолько ясная истина которая ясна любому покупателю. Очень непонятно, почему это непонятно производителю. Итак, все имеет свою стоимость. И нормальный инкрементальный backup также. Когда я иду в магазин, я знаю что, то что дороже — чем-то лучше. И я спрашиваю у продавца, чем оно лучше. И он мне может ответить. Точно так же и в программном обеспечении. Нужно всегда знать ответ почему то, или иное решение лучше. В 1999 году, если сравнивать SQL 7.0 и Oracle 7.3+восьмерка уже появилась, это были небо и земля. И мы знали почему. В том числе и в плане надежности. И в том числе, то что у Oracle класнейший инкрементальный архивный backup который можно отвертеть до определенного времени. Что в купе с остальными достоинствами формулировалось в более надежную систему защищенную от сбоев за которую нужно больше заплатить. Если вы не можете заплатить(а достоинств у Oracle значительно больше чем только это), берите дешевле с MS SQL 7.0.
2. Насчет блобья и документов. Хранить бинарные документы в БД — в те года была плохая идея. И тут было много причин. Внедрение блобья в базы данных только началось(в Oracle 7.3 его и не было). Скорость была более чем не ахти. Повышенная нагрузка на rollback. Невозможность нормального индексирования. Достаточно много других ограничений. Поэтому выбора особо между файловой средой и базой — не было. Неструктурированные документы — на диске, структурированная информация, и информация о хранящихся документах, на сервере БД. И все должно бэкапиться.(существует правда одна проблема — рассинхронизации бэкапа, но это другая, также решаемая песня).
3. Зависшие транзакции — это проблема архитектуры решения. Они тянутся от двух вещей — невнимательность при работе с rollback + длинные транзакции. Даже если такое присутствует, нужно вполне конкретно описать пользователям что когда происходит. И что им делать в том, или ином случае. Если нету DBA — то информация должна быть предоставлена на таком уровне, чтобы это понял простой администратор. Если нету администратора, то нужно предоставлять чтобы понял пользователь. И тогда проблем уже не возникнет. А если возникает, то не по вашей вине. Мертвая БД может возникать по 3 причинам: ошибка разработчика, ошибка админа, ошибка железа. Зависшие транзакции по первым двум причинам.

... << RSDN@Home 1.2.0 alpha rev. 0>>

AndrewVK wrote:
> V>Чаще всего нет! На самом деле реально пока существует приличный разрыв
> м/у данными в БД и документами обычных MS Office.
> InfoPath спасет отца русской демократии?
Вы _в_ _реальной_ _жизни_ его использовали? В примерах в MSDN все
выглядит замечательно, и может с выделенным админом-MCSE оно и будет
работать.

Но не в наших фирмочках, где еще куча компов под Win98 стоит.

Posted via RSDN NNTP Server 2.0

AndrewVK wrote:
> Во-первых не за 4, а за 3, во-вторых основные деньги там потрачены на
> производительность и юнитовое исполнение, в третьих это самое обычное
> самосборное железо, ничего необычного в нем нет, такое железо может себе
> позволить даже маленькая контора, не говоря уж о тех, для которых потеря
> нескольких минут смерти подобно.
90% контор у нас в регионах удавятся за $300 на новое железо — это
жизненный факт. Например, мы продаем свой продукт по 700руб. на рабочее
место — заказы крупнее нескольких тысяч рублей идут в основном из
Москвы/Питера.

Posted via RSDN NNTP Server 2.0

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

GZ>>>Набор аттрибутов.
M>>Набор атрибутов — это кортеж, а не тип кортежей.
GZ>Набор аттрибутов — это домен.

http://en.wikipedia.org/wiki/Relational_model_of_database_management

The basic relational building block is the domain or data type, usually abbreviated nowadays to type. A tuple is an unordered set of attribute values.

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

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

C>Вы _в_ _реальной_ _жизни_ его использовали?

Один раз пришлось.

C> В примерах в MSDN все
C>выглядит замечательно, и может с выделенным админом-MCSE оно и будет
C>работать.

А чему там не работать и зачем там выделенный админ? InfoPath тупой как пробка, там и настраивать то особо нечего.

C>Но не в наших фирмочках, где еще куча компов под Win98 стоит.

У Altova есть легкое решение (чуть ли не ActiveX в браузер) на ту же тему.

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

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

C>90% контор у нас в регионах удавятся за $300 на новое железо — это
C>жизненный факт.

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

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

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

V>>Чаще всего нет! На самом деле реально пока существует приличный разрыв м/у данными в БД и документами обычных MS Office.

AVK>InfoPath спасет отца русской демократии?

Да, это попытка в нужном направлении.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>Согласно моей логике, если бы у вас была обычная техника, а не за 4k зелени

AVK>Во-первых не за 4, а за 3, во-вторых основные деньги там потрачены на производительность и юнитовое исполнение, в третьих это самое обычное самосборное железо, ничего необычного в нем нет, такое железо может себе позволить даже маленькая контора, не говоря уж о тех, для которых потеря нескольких минут смерти подобно.

Я никак не остановлюсь отвечать на этот уже флейм, из-за постоянного тасования моих высказываний. Там где остановка на несколько минут смерти подобна, тым совсем другой разговор. А там где серваки за $700 баксов коробка, дык там речь идет об минимизации вложений.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

GZ>1. Все имеет свою стоимость.
[skip]

Да, ты во многом прав, но Оракл не рассматривался даже близко. Моя система проработала год на 512MB ОЗУ (В то время даже это было много и дорого), Оракл практически не живет в таких условиях. Да и цена, опять же...

GZ>2. Насчет блобья и документов. Хранить бинарные документы в БД — в те года была плохая идея. И тут было много причин. Внедрение блобья в базы данных только началось(в Oracle 7.3 его и не было). Скорость была более чем не ахти. Повышенная нагрузка на rollback. Невозможность нормального индексирования. Достаточно много других ограничений. Поэтому выбора особо между файловой средой и базой — не было.

+1

именно, мои эксперименты показывали неважный отклик системы с большими блобами...

GZ>Неструктурированные документы — на диске, структурированная информация, и информация о хранящихся документах, на сервере БД. И все должно бэкапиться.(существует правда одна проблема — рассинхронизации бэкапа, но это другая, также решаемая песня).

Да все решаемо, это далеко не самая серьезная задачка.

GZ>3. Зависшие транзакции — это проблема архитектуры решения. Они тянутся от двух вещей — невнимательность при работе с rollback + длинные транзакции.

Блин, ты все-таки невнимательно прочитал. Зависшие транзакции берутся от обрыва коннекшена клиентской программы прямо посреди транзакции. И тут на самом деле только 1 способ, как бороться с этим, но он некрасивый.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Странный у тебя взгляд на вещи.
Ничего странного не вижу...

V> Например, приказ по предприятию сделать 9-е Марта выходным днем — вполне себе документ.
Да я и не спорю, и ни где не говорил, что это не документ.

V>Ну уж озадачил по-взрослому...
Удалось.

V>Озвученные мною цифры относились к "маленькой" базе, причем здесь это? Ну не "маленькая", а "средненькая".
При том, что ты же сам написал, что если база "маленькая", то с ней работать можно, а если "не маленькая", то документы надо хранить уже не в базе...
Отсюда делаем вывод, что в нашей "средненькой" базе сообщения надо хранить отдельно, чтобы свести ее к "маленькой". Все в соостветствии с твоими рассуждениями.

V>Слушай, а нужен ли нам форум, чтобы продолжать маяться подобной вот ерундой?
Предлагаешь встретиться и обсудить это в реале? Ок, пиво с тебя..

V>Никакой моей логике ты не следовал, так что причем здесь вообще RSDN-овская база?
Я тебе там подробно расписал, как именно я твоей логике следовал, лучше бы это процитировал, может тогда бы стало понятно... А заодно ответил бы еще на десяток вопросов, которые я задавал на протяжении разговора, и которые ты так и оставил без ответа.

V>Не поленился просмотреть с чего началась подветка... В общем, вы, мягко говоря, загоняете, сударь...
Просмотри внимательно еще раз.

V> Специально прошелся еще раз по ветке и так и не понял, при чем тут ваша база RSDN и куда лепить эти твои последние замечания?
Остается только посетовать на твою невнимательность и упорное нежелание видеть неудобные вопросы.

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

V>1. Из личного опыта установлено, что если база хранит "большие" блобы, то при определенных условиях может начаться быстрый бесконтрольный рост размеров логов транзакций, что накладывает определенные требования на систему резервирования и сами сценарии резервирования.
Совсем недавно мы выяснили, что блобы, на самом деле, не причем. А проблема в длинных транзакциях, которые вы умудрились подвешивать.
А поскольку вся твоя теория построена на том, что виноваты именно блобы (которые как выясняется не причем), то значит и вся теория твоя не верна.

V>2. Эти "определенные" условия были отличительной чертой клиент-серверной архитектуры,
То есть все-таки не блобы, а архитектура? Ну так, так и надо писать, а не забивать неискушенным умам голову блобами.

V> Большинство даже нынешних серверов приложений способны спровоцировать описанную ситуацию.
Способны, если руки у разработчиков кривые.

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

Вот мы и расставили все по своим местам.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

GZ>В честь чего?
В честь того, что и то и то придумано для работы с деревьями на соснове сохранения пути и порядка вложенности.

M>>Набор атрибутов — это кортеж, а не тип кортежей.
GZ>Набор аттрибутов — это домен.

Домен — это все возможные значения атрибута (тип атрибута).

GZ>Проблема не в таблице, а в интерпретации.
А интерпритация — это уже не забота БД. Забота БД — сохранить отношение и выдать подмножество этого отношения по запросу, все.
Все остальные эволюции это работа прикладного кода и к БД это не имеет никакого отношения.

GZ>Если ты о потери идентифицируемости доменов, то ее можно описать реляционными операциями.
Я о том, что реальные БД и реляционная теория понимают под доменами несколько разные вещи, в следствии чего в реальных БД возможны операции, которые по теории недопустимы.

GZ>Дык результат можно посмотреть на экране.
Я не про тот результат, я про результат, который лежит на диске в реляционной таблице.

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

GZ> И к тому же непонятно что ты называешь OP. Для меня это всего лишь таблица. Ты по моему под этим подразумеваешь механизм полностью.
OP я называю алгоритм преобразования xml в отношение и XPath в реляционный запрос. И алгоритм обратного преобразования результата XPath запроса по отношению к xml-ю.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

AVK>http://en.wikipedia.org/wiki/Relational_model_of_database_management
AVK>

The basic relational building block is the domain or data type, usually abbreviated nowadays to type. A tuple is an unordered set of attribute values.

http://en.wikipedia.org/wiki/Domain

In Database Theory, a Domain is a set of atomic values.

с доменом в sql и у Кодда с Дейтом есть большие непонятки.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

V>Я никак не остановлюсь отвечать на этот уже флейм, из-за постоянного тасования моих высказываний. Там где остановка на несколько минут смерти подобна, тым совсем другой разговор. А там где серваки за $700 баксов коробка, дык там речь идет об минимизации вложений.

Млин. Ну давай посчитаем. Выкидываем юнитовое исполнение за ненадобностью, второй процессор, 3 гига памяти и 15К винты в страйпе, бо контора, экономящая копейки на серваках может и подождать, да и надежность это повысит.
Процессор Pentium4 2.66 — $100
Серверная мамка от Supermicro — $230
Серверный корпус от того же Supermicro — $110
Гиг памяти ECC Registered от Kingston — $120
2 винта по 200 гиг для зеркала — $180

Итого — $740, в заданные рамки уложились и получили то же самое по надежности железо от тех же самых производителей, что и на rsdn.

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

AndrewVK wrote:
> C>90% контор у нас в регионах удавятся за $300 на новое железо — это
> C>жизненный факт.
> А еще жизненный факт, что конторы куда охотнее и больше тратят деньги на
> железо, нежели на софт. Я в этих региональных конторах поработал в свое
> время и знаю это доподлинно.
Поэтому наш софт и стоит 700руб. — обычной конторе он нужен для
одного-двух рабочих мест.

Posted via RSDN NNTP Server 2.0

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

C>Поэтому наш софт и стоит 700руб. — обычной конторе он нужен для
C>одного-двух рабочих мест.

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

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

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

V>Да, ты во многом прав, но Оракл не рассматривался даже близко. Моя система проработала год на 512MB ОЗУ (В то время даже это было много и дорого), Оракл практически не живет в таких условиях. Да и цена, опять же...
Ты не поверишь, но в таких условиях Oracle более чем жирно живет. 7.3 жила и на 32 мегах. Больше пользователей нужно больше памяти. Меньше пользователей — меньше памяти. 512 — это много пользователей. Могли бы и раскошелиться.

GZ>>3. Зависшие транзакции — это проблема архитектуры решения. Они тянутся от двух вещей — невнимательность при работе с rollback + длинные транзакции.
V>Блин, ты все-таки невнимательно прочитал. Зависшие транзакции берутся от обрыва коннекшена клиентской программы прямо посреди транзакции.
Поясню — это длинные транзакции. Если ты работал с SQL маленькими короткими транзакциями(а иначе с ним работать нельзя), блокировки только на уровне бизнес-транзакций, то проблемы не возникает. У меня же ни разу не возникало.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

Да я там вроде размеры блобов по 10 мег упоминал. Есть они у вас?

V>>Слушай, а нужен ли нам форум, чтобы продолжать маяться подобной вот ерундой?
M>Предлагаешь встретиться и обсудить это в реале? Ок, пиво с тебя..

приезжай на каникулы летом к нам

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

Обрывочная это логика. Понимаешь, у любой задачи есть требования. Если хотя бы одно требование выкинуть, то это будет уже совсем другая задача. Твой RSDN и близко на описанные многократно по этой ветке условия не натягивается.

M>А заодно ответил бы еще на десяток вопросов, которые я задавал на протяжении разговора, и которые ты так и оставил без ответа.

Ты вопросы одни и те же задаешь, а я пишу по 3-му кругу одно и то же...

V>> Специально прошелся еще раз по ветке и так и не понял, при чем тут ваша база RSDN и куда лепить эти твои последние замечания?
M>Остается только посетовать на твою невнимательность и упорное нежелание видеть неудобные вопросы.

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

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

Они сами подвешиваются при обрыве коннекта с клиента. Если не трудно, приведи здесь код (скрипт или кратко словами) как в 7-ке закидывать большие блобы батчем. Если не сможешь привести — то все твои советы можно смело сносить в мусор...

M>А поскольку вся твоя теория построена на том, что виноваты именно блобы (которые как выясняется не причем), то значит и вся теория твоя не верна.

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

(И, скорее, не "теория", а банальное наблюдение и соответствующее решение)

V>>2. Эти "определенные" условия были отличительной чертой клиент-серверной архитектуры,
M>То есть все-таки не блобы, а архитектура? Ну так, так и надо писать, а не забивать неискушенным умам голову блобами.

Поиск виноватых продолжался... Нормальная архитектура для своего времени. Технологий еще не было писать серьезные N-уровневые сервера в те времена.

V>> Большинство даже нынешних серверов приложений способны спровоцировать описанную ситуацию.
M>Способны, если руки у разработчиков кривые.

Значит у всех кривые (наверно только у тебя ровные). Кстати, если пользуешься дотнетом, то там по другому вообще никак штатными ср-вами. И ваш RSDN в т.ч. наверняка всем этим грешит, то бишь "кривыми руками". Вот какими, например, ты пользуешься ср-вами для построения DAL? Просьба не игнорировать вопрос, ибо было выдвинуто вполне конкретное обвинение, извольте-с объясниться. А я потом поясню как поступаю в той системе, которую разрабатываю сейчас.

V>> Любая ситуация, где в прикладной логие создается транзакция и выполняется более, чем одна операция по модификации данных в рамках транзакции, но не в рамках одного батча — преттендент на получение описанного эффекта.
M>Только проблема в том, что в нормальных системах так не делают, и писать взаимодействие с БД именно таким образом строжайше не рекомендуется, а если и приходится, то придумывают различные приседания, чтобы длинных и, тем более, подвисших транзакций не допускать.

Ты по существу давай, вот эту воду плиз больше не лей. К тому же понятие "длинная транзакция", это такое весьма неопределенное понятие... Вернее, весьма конкретное, и означает, что ты именно так и поступаешь, похоже...

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

M>Таким образом приходим к выводу, что лечили вы не болезнь (длинные подвисшие транзакции), а симптомы (большой рост лога).

Да, а кто скрывал? Тебе же с самого начала это разжевали и в рот положили. Лечение болезни обошлось бы на порядок дороже, и упомянутые фирмы банально продолжали бы работать в Excel, в крайнем случае в 1С (тогда была 6-ка в ходу — редкостная пакость)

M>Вот мы и расставили все по своим местам.

Блин, не могу всерьез относиться к твоим ответам... Что именно расставили по местам? Тебе же все это было с самого начала сказано. Что-то изменилось или выяснилось что-то новое? Ты попробуй не торопясь сложить все приведенные факторы вместе... Только не спеши с ответом, т.е. если нового ничего не будет озвучить, то, наверно и не стоит... по 3-му разу-то...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>Я никак не остановлюсь отвечать на этот уже флейм, из-за постоянного тасования моих высказываний. Там где остановка на несколько минут смерти подобна, тым совсем другой разговор. А там где серваки за $700 баксов коробка, дык там речь идет об минимизации вложений.

AVK>Млин. Ну давай посчитаем. Выкидываем юнитовое исполнение за ненадобностью, второй процессор, 3 гига памяти и 15К винты в страйпе, бо контора, экономящая копейки на серваках может и подождать, да и надежность это повысит.
AVK>Процессор Pentium4 2.66 — $100
AVK>Серверная мамка от Supermicro — $230
AVK>Серверный корпус от того же Supermicro — $110
AVK>Гиг памяти ECC Registered от Kingston — $120
AVK>2 винта по 200 гиг для зеркала — $180

AVK>Итого — $740, в заданные рамки уложились и получили то же самое по надежности железо от тех же самых производителей, что и на rsdn.

2 нормальных винта по 200 гиг — это $360 у нас. Но это не суть важно. Да, задачи по условиям 5-ти летней давности вполне можно хранить в БД на современной технике.

Но если взять современные задачи и документы, типа видео, "сырого" звука, больших растровых изображений (на сотни мег или дае гиг), то мы соблюдем коэф. пропорциональности тех задач и нынешней техники. В 10 раз показатели техники выросли с тех пор, давай возьмем в 10 раз более объемные документы.

Ну как, реально без приседаний и надзора админа это все в базе хранить? Сколько времени способна будет база работать на самообслуживании? А если у нас большая дизайнерская контора, где 200 дизайнеров с утра до вечера редактируют видео, изображения в PSD-формате (это именно они на сотни мег тянут), работают с 32-х канальным "сырым" звуком (тоже сотни мег), хранят кучи версий и т.д.

Вот каковы твои субъективные ощущения, чтобы все это хозяйство взвалить в БД на описанную конфигурацию, и при этом гарантировать, что пол-года система проживет на автоматическом обслуживании?

(Если вдруг в такой системе не дай бог подвиснет транзакция...

то свободное место на дисках кончится в течении нескольких часов)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AVK>Да бог с тобой. 3 гига она была года два назад. Сейчас 7.5. Лог на старой БД был > 3 гигов (это к вопросу о коротких логах на rsdn). На текущей лог 600М, видимо 2005 сиквел в этом отношении получше стал.

А что, вы не сбрасываете логи? После полного бэкапа можно сбрасывать лог в 0.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

GZ>Поясню — это длинные транзакции. Если ты работал с SQL маленькими короткими транзакциями(а иначе с ним работать нельзя), блокировки только на уровне бизнес-транзакций, то проблемы не возникает. У меня же ни разу не возникало.

А у меня возникало... Банально 2 связанных ADO-рекордсета коммитят батч в рамках одной транзакции. В этот момент сбой сети. Мне очень "повезло" в том плане, что в одной из фирм в здании работали сварщики постоянно, сетки были коаксиал 10Мб... В общем, сеть глючила постоянно и я несколько раз получил зависшие транзакции. Поборол через временные промежуточные таблицы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>2 нормальных винта по 200 гиг — это $360 у нас. Но это не суть важно. Да, задачи по условиям 5-ти летней давности вполне можно хранить в БД на современной технике.

Так, просьба не уходить от темы. Ты утверждал что железо на rsdn крутое и недооступное простым фирмам. Я тебе на фактах доказал, что оно вполне доступное, даже умещающееся в смехотворные 700 баксов (смехотворные потому что мой домашний компьютер в 2 раза дороже, а он в основном для баловства куплен).

V>А если у нас большая дизайнерская контора, где 200 дизайнеров

Большая дизайнерская контора с 200 только дизайнерами покупает сервер за 700 баксов. Я плакал.

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

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

V>А что, вы не сбрасываете логи?

Сбрасываем, но редко. Тот самый случай, когда full-time админа нет.

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

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

GZ>>В честь чего?
M>В честь того, что и то и то придумано для работы с деревьями на соснове сохранения пути и порядка вложенности.
Это другой класс алгоритмов. Можно решить интеграл с помощью разбития на прямоугольники(трапеции), методом Гауса, методом Монте-Карло. Это алгоритмы разного класса но решающие одну и ту же задачу.

GZ>>Набор аттрибутов — это домен.

M>Домен — это все возможные значения атрибута (тип атрибута).

Сорри, отморозился. Завтра застрелюсь.

M>Я о том, что реальные БД и реляционная теория понимают под доменами несколько разные вещи, в следствии чего в реальных БД возможны операции, которые по теории недопустимы.
Понял.

GZ>> А вот работа, даже на уровне плана запросов значительно интересней.
M>Там ничего интересного нет, самый обычный реляционный запрос.
GZ>> И к тому же непонятно что ты называешь OP. Для меня это всего лишь таблица. Ты по моему под этим подразумеваешь механизм полностью.
M>OP я называю алгоритм преобразования xml в отношение и XPath в реляционный запрос. И алгоритм обратного преобразования результата XPath запроса по отношению к xml-ю.
OK. Берем такой запрос(скопировал с msdn).

declare @x xml
set @x = '
<People>
  <Person>
    <Name>John</Name>
    <Age>24</Age>
  </Person>
  <Person>
    <Name>Goofy</Name>
    <Age>54</Age>
  </Person>
  <Person>
    <Name>Daffy</Name>
    <Age>30</Age>
  </Person>
</People>
select @x.query('/People/Person/Name[1]')

И посмотрим на план запроса.
Занятная картина.

Много всяких Compute Scalar и UDX. Команды прямо таки говоря, не слишком реляционные. И сомневаюсь что UDX нужен еще кому-то кроме xml подсистемы.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

AVK>Так, просьба не уходить от темы. Ты утверждал что железо на rsdn крутое и недооступное простым фирмам.

так и есть, 3k — это круто

AVK>Я тебе на фактах доказал, что оно вполне доступное, даже умещающееся в смехотворные 700 баксов (смехотворные потому что мой домашний компьютер в 2 раза дороже, а он в основном для баловства куплен).

У меня дома тоже дороже, потому как видюха с тюнером, плоский монитор, DVD-резак и т.д. и т.п. Программисты вообще народ не бедный... Другое дело, если бы за все эти деньги купить только голую "коробку"...

V>>А если у нас большая дизайнерская контора, где 200 дизайнеров

AVK>Большая дизайнерская контора с 200 только дизайнерами покупает сервер за 700 баксов. Я плакал.

OK, берем сервер за 5k баксов. Что-то сильно изменилось? Что-то я не вижу, чтобы люди повсеместно видео и сырое аудио в БД пихали... Может, при наличии красивой теории, что-то не так на практике?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>А что, вы не сбрасываете логи?

AVK>Сбрасываем, но редко. Тот самый случай, когда full-time админа нет.

У вас же и-нет сервак, можно удаленно все делать.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>Vladimir V Kochetkov wrote:
>> V>Как всегда, подобные обсуждения свелись к советам насчет аппаратуры.
>> Поздравляю, Вы не оригинальны.
>> V>Можно вопрос на засыпку? А если на фирме НЕТ технического директора и
>> не планируется?
>> Ээээ... Держитесь подальше от таких фирм, мой вам совет
C>Да, да. Держитесь подальше, как можно дальше.
C>(Чтобы мы могли им продавать свой софт).

C>Таких фирм — подавляющее _большинство_, особенно в регионах. Так что же
C>теперь, наплевать на огромный рынок потенциальных клиентов?

Ээээ. Я почему-то (видимо невнимательно читал) решил, что vdimas там работает. "Держитесь подальше" имелось ввиду "как от потенциального работодателя"

На потенциальных клиентов плевать конечно не нужно

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

V>Здравствуйте, Vladimir V Kochetkov, Вы писали:

V>>>Можно вопрос на засыпку? А если на фирме НЕТ технического директора и не планируется?

VVK>>Ээээ... Держитесь подальше от таких фирм, мой вам совет

V>Совет хороший, разумеется. Жаль, что таких фирм — 90% потенциального рынка (торговые средние и мелкооптовые предприятия).

См. мой ответ Cyberax'у.

V>>>Да нет, люди хотят пользоваться обычными WORD-ами и EXCEL-ами, причем, хранить там не только "свои", но и "чужие" документы.

VVK>>Что в вашем понимании "документооборот" ?

V>а в твоем?

V>Документооборот — это автоматизированные сценарии работы с документами. Конкретная степень автоматизации (и набор возможностей) зависит от расшифровки понятия "документ", которая может быть весьма широкой. Если тебе показалось, что я ограничиваю понятие документа лишь порождениями офисных ворда и екселя, то это заблуждение.

Именно так и показалось бо:

"Да нет, люди хотят пользоваться обычными WORD-ами и EXCEL-ами, причем, хранить там не только "свои", но и "чужие" документы." (с)

Здравствуйте, vdimas, Вы писали:
V>Поиск виноватых продолжался... Нормальная архитектура для своего времени. Технологий еще не было писать серьезные N-уровневые сервера в те времена.

Ну одного ты этой веткой добился — отрекламировал свою систему

Вышли мне плиз намыло линк или доку (подозреваю, для кое-кого из клиентов может пригодиться).

Vladimir V Kochetkov wrote:
> C>Таких фирм — подавляющее _большинство_, особенно в регионах. Так что же
> C>теперь, наплевать на огромный рынок потенциальных клиентов?
> Ээээ. Я почему-то (видимо невнимательно читал) решил, что vdimas там
> работает. "Держитесь подальше" имелось ввиду "как от потенциального
> работодателя"
Как работодателя — понятно (откуда у них деньги на программиста??), а
вот как закакзчиков решений — другой вопрос.

Posted via RSDN NNTP Server 2.0

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

AVK>>Так, просьба не уходить от темы. Ты утверждал что железо на rsdn крутое и недооступное простым фирмам.

V>так и есть, 3k — это круто

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

V>У меня дома тоже дороже, потому как видюха с тюнером, плоский монитор, DVD-резак и т.д. и т.п. Программисты вообще народ не бедный...

Даже мелкая фирма существенно богаче среднего программиста. Например в свое время приходилось делать IT-систему для булочной (человек 8 рабочих) — стоимость железа была в районе 5К и я бы не сказал что эту сумму пришлось долго утрясать и урезать.

AVK>>Большая дизайнерская контора с 200 только дизайнерами покупает сервер за 700 баксов. Я плакал.

V>OK, берем сервер за 5k баксов. Что-то сильно изменилось? Что-то я не вижу, чтобы люди повсеместно видео и сырое аудио в БД пихали...

А я видел такое (на Оракле). А ты видел систему для дизайнерской конторы, в которой хранились данные по предложенной тобой схеме?

V> Может, при наличии красивой теории, что-то не так на практике?

Вопрос в том, у кого теория, а у кого практика.

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

AVK>>Сбрасываем, но редко. Тот самый случай, когда full-time админа нет.

V>У вас же и-нет сервак, можно удаленно все делать.

И? Мы и делаем удаленно. Только это не значит что у нас есть человек, готовый регулярно за просто так делать нудную работу.

... << RSDN@Home 1.2.0 alpha rev. 642>>

AndrewVK wrote:
> C>Поэтому наш софт и стоит 700руб. — обычной конторе он нужен для
> C>одного-двух рабочих мест.
> И это клиент-серверное решение? Тогда надо продавать минимум десятки
> тысяч копий чтобы разработка собственного файлового хранилища окупилась.
Есть и клиент-сервер, есть и автономная версия (сам себе сервер).
Собственное файловое хранилище пишется за один день — что там сложного?

Posted via RSDN NNTP Server 2.0

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

C>Собственное файловое хранилище пишется за один день — что там сложного?

И написанное за 1 день хранилище сравнивают по надежности с промышленными БД? no comments

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

AVK>И написанное за 1 день хранилище сравнивают по надежности с промышленными БД? no comments

Можно ведь вспомнить надежность репозиториев svn на BerkeleyDB и на файловой системе

А то, что хранилище написано за один день еще не показатель -- может его до этого пять лет проектировали и проверяли на разных прототипах

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

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

S>>Речь о состояниях пошла от этого типа индекса.
M>От какого типа?

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

Так мы о алгоритмах и говорим. Вернее об оптимальных вариантах. Буду длагодарен на ссылочки этих алгоритмов.

S>> Хорошо как происходит чтение новой в транзакции при незавершенной транзакции при переполнении страниц????
S>> То есть при переполнении в незавершенной транзакции родительская страница не меняется???
M>Меняется. Если тебе так будет понятнее, то с точки зрения СУБД расщепление страницы в случае переполнения — это отдельная транзакция. Вставка нового ключа — это тоже отдельная транзакция и удаление ключа — тоже транзакция. Если все эти действия надо отменить, то выполняются компенсирующие транзакции, для приведения базы в исходное состояние.

Чем это отличается от версионности???
S>> Ладно мы плохо понимаем друг друга.
M>Вот уж точно.

S>>Версионность только на уровне листовых страниц оправдана.
M>Нет. И насколько мне известно — так никто не делает, очевидно это не выгодно.

ля обепечения уже начавшегося прохода для чистого чтения самый элементарный подход.
S>> Другое дело как будут хранится данные для отката и востановление. При применении версионности это достаточно элементарно и надежно.
M>Пойми, ну некуда впихнуть здесь версионность. Вообще некуда, нет никакой выгоды от нее, только дополнительные расходы на копирование памяти. А элементарно и надежно тут все и без версионности.
Итересно а для отката , что надо хранить???
Скажи как тогда происходит версионность для клястерного индекса. Там возможно только на уровне страниц, т.к. элементы смещаются и слишком накладно вести версионность на уровне записи.

S>> Оно требуется достаточно часто особенно при долгих вычислениях.
M>Ты сейчас про что говоришь? Про внешнюю транзакцию или про транзакцию модификации дерева? При модификации дерева никаких долгих вычислений нет.
Я говорю о состоянии БД на начало транзакции, и обеспечения доступа к данным на начало этой транзакции.
С версионностью все понятно и элементарно, как это происходит в блокировочниках (понятно но достаточно смутно, вернее достаточно много спорных моментов хорошей её реализации).

S>> Не совсем.
M>Совсем.

S>> Чёс по таблице и по клястерному индексу нечто другое.
M>С точки зрения индекса — одно и тоже.
Покажи алгоритмы обеспечивающие чистое чтение и алгоритмы версионности кластерного индекса.

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

C>>Собственное файловое хранилище пишется за один день — что там сложного?
AVK>И написанное за 1 день хранилище сравнивают по надежности с промышленными БД? no comments
Файловому хранилищу нужно делать ровно три вещи: добавлять файлы, удалять файлы и читать файлы. Такое пишется за день в 20 килобайт кода, где просто нечему глючить.

В файловом хранилище _не_ нужны SQL-запросы, транзакции, логи и т.п. — это все обеспечивается базой данных (у нас используется встроеный FireBird) для метаинформации.

Не. Тебя не поймут... Ты же людям рынок портишь.

Как они потом будут пользователям доказывать "объективную" необходимость тяжелых решений.

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

V>Ты вопросы одни и те же задаешь, а я пишу по 3-му кругу одно и то же...

И упорно не отвечаешь на заданные вопросы..

V>Я не вижу связи м/у двумя задачами, у которых требования не то что не близки, а скорее противоположны по характеру.
Ничего противоположного нет. Более того, как раз ту систему, которая нужна автору топика, гораздо больше напоминает rsdn, нежели твой документооборот.

M>>Совсем недавно мы выяснили, что блобы, на самом деле, не причем. А проблема в длинных транзакциях, которые вы умудрились подвешивать.
V> Если не трудно, приведи здесь код (скрипт или кратко словами) как в 7-ке закидывать большие блобы батчем.
Что значит как? Ты не знаешь как в хранимую процедуру параметры передать? Размер батча, как я уже писал 8k*PacketSize, в это дело любой разумный блоб влезет.

V>Если не сможешь привести — то все твои советы можно смело сносить в мусор...
Я тебя должен учить с БД работать? Ты же на этом деле слона съел...

M>>А поскольку вся твоя теория построена на том, что виноваты именно блобы (которые как выясняется не причем), то значит и вся теория твоя не верна.
V>Мне уже хочется поинтересоваться возрастом собеседника... логика потрясающая.
Так что не так в логике? Ты сторишь свою теорию, виноват, выводы из "жизненных наблюдений" на ряде посылок, помоему очевидно, что если одна из твоих посылок не верна, то и выводы сделанные из "жизненных наблюдений" тоже, того...

V> А какова односторонность подхода, просто шедевр, блин. Моя т.н. "теория" построена на пересечении сразу нескольких факторов. Похоже, тебе трудно обсуждать их все сразу, ты упорно пытаешься рассматривать их по-очереди.

А какой смысл рассматривать их все сразу, если как минимум один из них неверный?

V>Поиск виноватых продолжался...
Ну не знаю как там у тебя с поиском, но судя по твоим описаниям проблема была ясна еще три сообщения назад.

V> Нормальная архитектура для своего времени. Технологий еще не было писать серьезные N-уровневые сервера в те времена.
Как тебе уже здесь объяснили, дело не в уровнях.

V>Значит у всех кривые (наверно только у тебя ровные).
Я про всех ничего не говорил, да и про себя тоже. Вот это действительно образец не совсем линейной логики..

V> Кстати, если пользуешься дотнетом, то там по другому вообще никак штатными ср-вами.
То есть, у дотнета нет штатных средств хранимку выполнить? Как интересно...

V>И ваш RSDN в т.ч. наверняка всем этим грешит, то бишь "кривыми руками".
Откуда такой вывод?

V>Вот какими, например, ты пользуешься ср-вами для построения DAL?
RFD и хранимками.

V> К тому же понятие "длинная транзакция", это такое весьма неопределенное понятие...
Нет, "длинная транзакция" это очень конкретное понятие.

V>Вернее, весьма конкретное, и означает, что ты именно так и поступаешь, похоже...
С чего, прости, понятно?

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

V>Да, а кто скрывал? Тебе же с самого начала это разжевали и в рот положили. Лечение болезни обошлось бы на порядок дороже, и упомянутые фирмы банально продолжали бы работать в Excel, в крайнем случае в 1С (тогда была 6-ка в ходу — редкостная пакость)
Даже если принять, что на тот момент это был лучший выход, то можно сделать следующее заключение:
Если вам придется разрабатывать систему, в 1999 году, на MSSQL 7, с большим числом многомегабайтных блобов, и по каким-то причинам необходимо пользоваться длинными транзакциями для работы с оными блобами, то рекомендуется хранить блобы отдельно от базы.
(при этом вопрос согласованности блобов между собой оставляем за рамками)

V>Блин, не могу всерьез относиться к твоим ответам...
Да я уже и не рассчитываю..

V> Что именно расставили по местам?
Применимость и оправданность твоего решения.

V> Ты попробуй не торопясь сложить все приведенные факторы вместе...
Я уже сложил, и выводы озвучил. Несоглашаться с ними — твое право, а вот обсуждать все по десятому кругу, пожалуй действительно бессмыслено.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>Занятная картина.

Много всяких Compute Scalar и UDX. Команды прямо таки говоря, не слишком реляционные. И сомневаюсь что UDX нужен еще кому-то кроме xml подсистемы.
Правильно сомневаешься... Вот посмотри на этот UDX, там английским языком написано: "XML Serialize". Никто и не утверждает, что преобразования xml-я волшебным образом сами по себе станут реляционными. Я лишь утверждал, что при сохранении и для построения индексов, xml преобразуется в реляционную таблицу, чем и занимаются многочисленные Compute Scalar, UDX и XML TVF видные на плане....
Теоретически тоже самое можно написать на обычных CLR функциях и процедурах в ручную на 2005-м и ханить весь XML в обычных таблицах.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

C>В файловом хранилище _не_ нужны SQL-запросы, транзакции, логи и т.п. — это все обеспечивается базой данных (у нас используется встроеный FireBird) для метаинформации.

А транзакции? А совместный с БД бекап?

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

S> Пропустим. Тип хранения ссылок в родительских страницах.

Так и не понял о чем ты...

S> Так мы о алгоритмах и говорим. Вернее об оптимальных вариантах. Буду длагодарен на ссылочки этих алгоритмов.
Именно, например алгоритм блокирования на DAG-ах (Direct Acyclic Graph, коим является B+), описанный в том числе и у Бернстайна, гарантирует отсутствие дедлков..
Плюс, не забывай, при модификации дерева нет длинных транзакций. Проблема откатов решается компенсирующими транзакциями.

M>>Меняется. Если тебе так будет понятнее, то с точки зрения СУБД расщепление страницы в случае переполнения — это отдельная транзакция. Вставка нового ключа — это тоже отдельная транзакция и удаление ключа — тоже транзакция. Если все эти действия надо отменить, то выполняются компенсирующие транзакции, для приведения базы в исходное состояние.
S> Чем это отличается от версионности???
Тем что нет ссылок на предыдущие версии страницы. И вообще ссылок на предыдущие версии нет, и доступа к измененным данным никто не имеет, кроме меняющей транзакции.

S> ля обепечения уже начавшегося прохода для чистого чтения самый элементарный подход.
Это может быть и самый элементарный (в чем я очень сомневаюсь), но уж точно не самый выгодный.

S> Итересно а для отката , что надо хранить???
Для отката надо знать предыдущее значение ключа.

S> Скажи как тогда происходит версионность для клястерного индекса.
Вот ты вцепился в кластерный индекс. Еще раз. От обычного он ничем не отличается, вся разница в том, что в обычном ссылка на данные, а в кластерном сами данные. Алгоритм работы с индексом как таковым это не затрагивает ни в одном месте.

S> Там возможно только на уровне страниц, т.к. элементы смещаются и слишком накладно вести версионность на уровне записи.
Ага, щаз. Расскажи это разработчикам 2005-го сиквела.

S> Я говорю о состоянии БД на начало транзакции, и обеспечения доступа к данным на начало этой транзакции.
Медленно, по буквам: Для модификации дерева нет необходимости давать доступ другим транзакциям к данным на начало работы меняющей транзакции. Более того, даже если такая функциональность нужна внешнему коду, в версионных БД, то механизм отслеживания версий выносится в отдельное хранилище.

S> Покажи алгоритмы обеспечивающие чистое чтение и алгоритмы версионности кластерного индекса.
Согласованное чтение элементов дерева достигается засчет блокировок. Версионность кластерного индекса работает точно так же как и обычного, если здесь мы говорим о 2005-м сиквеле.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

S>> Так мы о алгоритмах и говорим. Вернее об оптимальных вариантах. Буду длагодарен на ссылочки этих алгоритмов.
M>Именно, например алгоритм блокирования на DAG-ах (Direct Acyclic Graph, коим является B+), описанный в том числе и у Бернстайна, гарантирует отсутствие дедлков..
M>Плюс, не забывай, при модификации дерева нет длинных транзакций. Проблема откатов решается компенсирующими транзакциями.

Это почему????
M>>>Меняется. Если тебе так будет понятнее, то с точки зрения СУБД расщепление страницы в случае переполнения — это отдельная транзакция. Вставка нового ключа — это тоже отдельная транзакция и удаление ключа — тоже транзакция. Если все эти действия надо отменить, то выполняются компенсирующие транзакции, для приведения базы в исходное состояние.
S>> Чем это отличается от версионности???
M>Тем что нет ссылок на предыдущие версии страницы. И вообще ссылок на предыдущие версии нет, и доступа к измененным данным никто не имеет, кроме меняющей транзакции.

А мне он нужен.
S>> ля обепечения уже начавшегося прохода для чистого чтения самый элементарный подход.
M>Это может быть и самый элементарный (в чем я очень сомневаюсь), но уж точно не самый выгодный.

При чесе бежишь по страницам легко и непринужденно.
S>> Итересно а для отката , что надо хранить???
M>Для отката надо знать предыдущее значение ключа.
Это понятно, но плохо согласуется с множественным чтением. А на дедлуки нарвешься если не заблокируешь весь индекс например при 2 записях на страницу.

При модификации страницы легче запомнить всю станицу. Так легче востанавливать.

Оссобенно если транзакция затрагивает множество ключей на данной странице.
Хотя я уже приводил пример кластерного индеса с размером записи в 4 кб.

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

S>> Там возможно только на уровне страниц, т.к. элементы смещаются и слишком накладно вести версионность на уровне записи.
M>Ага, щаз. Расскажи это разработчикам 2005-го сиквела.

Не могу в это поверить!!!
S>> Я говорю о состоянии БД на начало транзакции, и обеспечения доступа к данным на начало этой транзакции.
M>Медленно, по буквам: Для модификации дерева нет необходимости давать доступ другим транзакциям к данным на начало работы меняющей транзакции. Более того, даже если такая функциональность нужна внешнему коду, в версионных БД, то механизм отслеживания версий выносится в отдельное хранилище.
А мне как разнужно. Чем два хранилища отличаются от одного??? Учитывая хранения данных на разных серверах???

S>> Покажи алгоритмы обеспечивающие чистое чтение и алгоритмы версионности кластерного индекса.
M>Согласованное чтение элементов дерева достигается засчет блокировок. Версионность кластерного индекса работает точно так же как и обычного, если здесь мы говорим о 2005-м сиквеле.
Например прочитал данные в начале, в этот момоент данные в конце изменены. Как в этом случае мне помогут блокировки???

AndrewVK wrote:
> C>В файловом хранилище _не_ нужны SQL-запросы, транзакции, логи и т.п. —
> это все обеспечивается базой данных (у нас используется встроеный
> FireBird) для метаинформации.
> А транзакции? А совместный с БД бекап?
Транзакции не нужны — достаточно атомарного переименования. Бэкап вместе
с файлами БД с помощью third-party утилиты.

Posted via RSDN NNTP Server 2.0

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

C>Транзакции не нужны — достаточно атомарного переименования.

На многопользовательской системе? А как тогда бороться с разъезжанием БД и файлов?

C> Бэкап вместе
C> с файлами БД с помощью third-party утилиты.

Аналогичный вопрос — как бороться с тем, что БД и файлы разъедутся? Останавливать на время бекапа всю систему?

... << RSDN@Home 1.2.0 alpha rev. 642>>

AndrewVK wrote:
> C>Транзакции не нужны — достаточно атомарного переименования.
> На многопользовательской системе? А как тогда бороться с разъезжанием БД
> и файлов?
Правильно сервер писать — перед операциями с файлами надо взять нужную
блокировку в БД.

> C> Бэкап вместе
> C> с файлами БД с помощью third-party утилиты.
> Аналогичный вопрос — как бороться с тем, что БД и файлы разъедутся?
> Останавливать на время бекапа всю систему?
Да, это самое простое.

Posted via RSDN NNTP Server 2.0

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

M>>Плюс, не забывай, при модификации дерева нет длинных транзакций. Проблема откатов решается компенсирующими транзакциями.
S> Это почему????
Это потому, что оно так работает!!!..

Это выгоднее, чем отслеивание версий.

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

S> При чесе бежишь по страницам легко и непринужденно.
По страницам всегда бежишь легко и непринужденно.

S> Это понятно, но плохо согласуется с множественным чтением.
Отлично согласуется.

S> А на дедлуки нарвешься если не заблокируешь весь индекс например при 2 записях на страницу.
Млин, в четвертый раз тебе говорю. Нету там дедлоков, Н Е Т У, алгоритм такой. Каждая запись — отдельная транзакция, конфликтовать не с чем. И версионост здесь не спасет, а навредит, так как у версионности как раз проблемы с записью.

S> При модификации страницы легче запомнить всю станицу. Так легче востанавливать.

Ты вообще читаешь, что тебе пишут? Не надо страницу восстанавливать. Никто не обещает, что при откате страница восстановится.

S> Оссобенно если транзакция затрагивает множество ключей на данной странице.
Да хоть все ключи.

M>>Ага, щаз. Расскажи это разработчикам 2005-го сиквела.
S> Не могу в это поверить!!!
Ну проверь... Все просто как рельс: Все версии на уровне записи/ключа, все они хранятся в специальном хранилище и имеют ссылку на предыдущую версию, при непосредственной работе с деревом они не используются, так как нужны они только прикладному коду.

S> А мне как разнужно.
Ну так и делай, только механизм работы с деревом не трогай.

S> Чем два хранилища отличаются от одного???
Слова "декомпозиция" и "инкапсуляция" тебе знакомы?

S> Учитывая хранения данных на разных серверах???
Причем тут разные сервера?

S> Например прочитал данные в начале, в этот момоент данные в конце изменены. Как в этом случае мне помогут блокировки???
Так же как всю жизнь помогали, тебе статью про уровни изоляции и блокировочные режимы посоветовать?
Так бы и сказал, а то пудришь мне тут мозги с деревьями...

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

>> C>Транзакции не нужны — достаточно атомарного переименования.
>> На многопользовательской системе? А как тогда бороться с разъезжанием БД
>> и файлов?
C>Правильно сервер писать — перед операциями с файлами надо взять нужную
C>блокировку в БД.

Т.е. распределенная транзакция. И ты считаешь что это можно за один день написать?

>> Останавливать на время бекапа всю систему?
C>Да, это самое простое.

Все ясно, вопросов больше нет.

... << RSDN@Home 1.2.0 alpha rev. 642>>

AndrewVK wrote:
> C>Правильно сервер писать — перед операциями с файлами надо взять нужную
> C>блокировку в БД.
> Т.е. распределенная транзакция. И ты считаешь что это можно за один день
> написать?
Уже

Даже обработка эвристических событий есть.

>> > Останавливать на время бекапа всю систему?
> C>Да, это самое простое.
> Все ясно, вопросов больше нет.
Не забывайте, система для 10-100 пользователей. Пока ни у кого проблем с
остановкой на 5 минут для бекапа не возникало.

Posted via RSDN NNTP Server 2.0

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

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

M>>>Плюс, не забывай, при модификации дерева нет длинных транзакций. Проблема откатов решается компенсирующими транзакциями.
S>> Это почему????
M>Это потому, что оно так работает!!!..

Это выгоднее, чем отслеивание версий.
Откаты это не проблема. Проблема в чистом чтении.

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

Они взаимосвязаны и неотделимы. Алгоритм все же разный, но схожий.

S>> При чесе бежишь по страницам легко и непринужденно.
M>По страницам всегда бежишь легко и непринужденно.
Только по позже модифицированным.

S>> Это понятно, но плохо согласуется с множественным чтением.
M>Отлично согласуется.

S>> А на дедлуки нарвешься если не заблокируешь весь индекс например при 2 записях на страницу.
M>Млин, в четвертый раз тебе говорю. Нету там дедлоков, Н Е Т У, алгоритм такой. Каждая запись — отдельная транзакция, конфликтовать не с чем. И версионост здесь не спасет, а навредит, так как у версионности как раз проблемы с записью.

Нет у версионности проблем с записью. Но будут проблемы с одновременной модификацией. Проще наложить длокировку на весь индекс.
S>> При модификации страницы легче запомнить всю станицу. Так легче востанавливать.

M>Ты вообще читаешь, что тебе пишут? Не надо страницу восстанавливать. Никто не обещает, что при откате страница восстановится.

Я говорю об оптимальных решениях, в той или иной ситуации.

S>> Оссобенно если транзакция затрагивает множество ключей на данной странице.
M>Да хоть все ключи.

Твой подход при этом будет отнюдь не оптимальныим.

M>>>Ага, щаз. Расскажи это разработчикам 2005-го сиквела.
S>> Не могу в это поверить!!!
M>Ну проверь... Все просто как рельс: Все версии на уровне записи/ключа, все они хранятся в специальном хранилище и имеют ссылку на предыдущую версию, при непосредственной работе с деревом они не используются, так как нужны они только прикладному коду.

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

Неполучится. Как мне найти первоначальное значение записи по ключу, если она была модифицирована(ключ), и откомичена ???

S>> Чем два хранилища отличаются от одного???
M>Слова "декомпозиция" и "инкапсуляция" тебе знакомы?

S>> Учитывая хранения данных на разных серверах???
M>Причем тут разные сервера?

А то, что по сути это две базы.
S>> Например прочитал данные в начале, в этот момоент данные в конце изменены. Как в этом случае мне помогут блокировки???
M>Так же как всю жизнь помогали, тебе статью про уровни изоляции и блокировочные режимы посоветовать?
Смотри выше. Как при читающей транзакции по времени 2 часа мне помогут блокировки, без остановки записи. При этом одна и таже запись может меняться многократно, в том числе и ключи???? Мне нужен срез БД по времени без останоки записи.
M>Так бы и сказал, а то пудришь мне тут мозги с деревьями...

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

S> Проблема в чистом чтении.
Нету ее, нету такой проблемы.

S> Они взаимосвязаны и неотделимы.
Расскажи это разработчикам СУБД.

S>Алгоритм все же разный, но схожий.
Он вообще другой, другими вещами занимается.

S> Только по позже модифицированным.
Это никому не мешает.

S> Проще наложить длокировку на весь индекс.
Никто блокировку на весь индекс никогда не накладывает.

S> Я говорю об оптимальных решениях, в той или иной ситуации.
И что это у нас за ситуация?

S> Твой подход при этом будет отнюдь не оптимальныим.
Оптимальным. И это не мой подход — это подход реальных высокопроизводительных систем, которые используют индексы на основе B+ деревьев.

S>Поэтому проще хранить версию страницы.
Не проще. Не нужно ее хранить. Это только дополнительные расходы на память и копирование памяти.

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

S> А то, что по сути это две базы.
Какие две базы? Мы об индексе говорим — не забыл?

S>Смотри выше.
Блин, ты смотри. Такое впечатление, что ты вообще не читаешь что тебе пишут.

S>Как при читающей транзакции по времени 2 часа мне помогут блокировки, без остановки записи.
Нету у тебя там двухчасовых транзакций. Вообще.
Подними две руки, поднеси их к ушам, прижми плотно, и отдели у себя в голове усилием воли два понятия:
1. глобальная транзакция в БД (здесь она у тебя хоть сутки идти может).
2. модификация дерева рамках этой транзакции (здесь никаких длинных транзакций не бывает, здесь все транзакции короткие и заранее известные).
И мы говорим именно о втором пункте, первый никого не интересует.
И вот пока ты эти две вещи у себя в голове не отделишь, разговаривать с тобой бесполезно. Нельзя все в одну кучу мешать.

S> Мне нужен срез БД по времени без останоки записи.
Тебе может и нужен, а дереву для модификации — нет. А мы сейчас говорим именно о дереве и о том как оптимальнее всего с ним работать. И твоя версионность тут совершенно не причем. Ну то есть вообще.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

V>>Документооборот — это автоматизированные сценарии работы с документами. Конкретная степень автоматизации (и набор возможностей) зависит от расшифровки понятия "документ", которая может быть весьма широкой. Если тебе показалось, что я ограничиваю понятие документа лишь порождениями офисных ворда и екселя, то это заблуждение.

VVK>Именно так и показалось бо:

VVK>"Да нет, люди хотят пользоваться обычными WORD-ами и EXCEL-ами, причем, хранить там не только "свои", но и "чужие" документы." (с)

Именно, коллега, именно...

Надо совмещать несовместимое, системы типа LotusNotes (по архитектуре) и "обычные" документы. А если вести разговор совсем "по взрослому", то дополнительно возможность работать с документами из страны EDI просто обязана присутствовать с современных системах документооборота.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>>Таких фирм — подавляющее _большинство_, особенно в регионах. Так что же
C>>теперь, наплевать на огромный рынок потенциальных клиентов?

VVK>Ээээ. Я почему-то (видимо невнимательно читал) решил, что vdimas там работает. "Держитесь подальше" имелось ввиду "как от потенциального работодателя"

VVK>На потенциальных клиентов плевать конечно не нужно

Вообще-то я многократно упомянул, что система должна работать довольно долго БЕЗ присмотра спеца.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>Я не вижу связи м/у двумя задачами, у которых требования не то что не близки, а скорее противоположны по характеру.
M>Ничего противоположного нет. Более того, как раз ту систему, которая нужна автору топика, гораздо больше напоминает rsdn, нежели твой документооборот.

Тогда еще раз большими буквами. Ветка началась с простой просьбы пообсуждать, в каких случаях что лучше насчет ФС vs БД. Уточнения пришли уже после того, как я высказался о случае документооборота, где ФС могла бы использоваться в связке с БД. И ты отвечал ИМЕННО НА МОИ аргументы и мой случай, так что просьба не съзжать... иначе беседа теряет смысл, ввиду смены технических требований.

M>>>Совсем недавно мы выяснили, что блобы, на самом деле, не причем. А проблема в длинных транзакциях, которые вы умудрились подвешивать.
V>> Если не трудно, приведи здесь код (скрипт или кратко словами) как в 7-ке закидывать большие блобы батчем.
M>Что значит как? Ты не знаешь как в хранимую процедуру параметры передать? Размер батча, как я уже писал 8k*PacketSize, в это дело любой разумный блоб влезет.

Вроде я упомянул про текст батчей. Мне приходилось динамически генерить SQL для батчей как на клиенте так и на сервере. И я не знаю (или не нашел) как в этом случае передать большие объемы данных. Почему динамически — это отдельный вопрос, связанный с мета-архитектурой системы.

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

V>>Если не сможешь привести — то все твои советы можно смело сносить в мусор...
M>Я тебя должен учить с БД работать? Ты же на этом деле слона съел...

Я говорил о восстановлении данных.

M>>>А поскольку вся твоя теория построена на том, что виноваты именно блобы (которые как выясняется не причем), то значит и вся теория твоя не верна.
V>>Мне уже хочется поинтересоваться возрастом собеседника... логика потрясающая.
M>Так что не так в логике? Ты сторишь свою теорию, виноват, выводы из "жизненных наблюдений" на ряде посылок, помоему очевидно, что если одна из твоих посылок не верна, то и выводы сделанные из "жизненных наблюдений" тоже, того...

Пока что не выяснилось, что блобы не при чем. Значит и все дальнейшие выводы преждевременны.

V>>Поиск виноватых продолжался...
M>Ну не знаю как там у тебя с поиском, но судя по твоим описаниям проблема была ясна еще три сообщения назад.

Ну... поясни проблему мне. А то я пока только намеки видел.

V>> Нормальная архитектура для своего времени. Технологий еще не было писать серьезные N-уровневые сервера в те времена.
M>Как тебе уже здесь объяснили, дело не в уровнях.

Блин, кто и где объяснил? Ты на что-то намекал несколько постов, так и не сказал конкретно, КАК ИМЕННО надо было поступать, и считаешь что что-то объяснил? Если был не согласен, то можно было вместо литья воды вполне конкретно указать, как именно можно было решить ту техническую задачу при соблюдении всех требований. Пока что ни одно из твоих предложений в требования не влезли. Вот именно из-за того, что каждое предложение касалось только отдельной стороны вопроса.

V>>Вот какими, например, ты пользуешься ср-вами для построения DAL?
M>RFD и хранимками.

Понятно, тогда нам действительно никогда друг-друга не понять. В той системе, что пишем сейчас, например, половина таблиц неизвестна на момент выпуск системы. Такова, понимаешь ли, ныняшняя мета-реальность. Для бухгалтерских систем более 90% таблиц может быть неизвестно на момент выпука системы. А доверять юзверям писать хранимки на их прикладные сущности — это нереально. Мы как-то пытались обсуждать систему (и здесь на RSDN проскакивали эти обсуждения), как из одного мета-кода генерить две части, ту, что будет исполняться на серваке БД, и ту, что сервером приложений... В общем, ни к чему не пришли, ибо задача слишком многофакторная. Поэтому работаем "по старинке", то бишь, используем базу как хранилище объектов, а весь SQL генериться в run-time и исполняется в рамках транзакций как батч.

Большинство систем сейчас именно так и написаны. Более того, в таких системах подменяется БД-адаптер и она продолжает с успехом использоваться на совершенно разных БД.

Потому и говорю, что согласно твоей логике "у всех руки кривые". Кстати, "погибшие" ObjectSpaces — из той же оперы. Ну и популярный Hibernate (+N) и сотни других аналогичных ORM-тулзов — тоже.

V>> К тому же понятие "длинная транзакция", это такое весьма неопределенное понятие...
M>Нет, "длинная транзакция" это очень конкретное понятие.

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

V>>Да, а кто скрывал? Тебе же с самого начала это разжевали и в рот положили. Лечение болезни обошлось бы на порядок дороже, и упомянутые фирмы банально продолжали бы работать в Excel, в крайнем случае в 1С (тогда была 6-ка в ходу — редкостная пакость)
M>Даже если принять, что на тот момент это был лучший выход, то можно сделать следующее заключение:
M>Если вам придется разрабатывать систему, в 1999 году, на MSSQL 7, с большим числом многомегабайтных блобов, и по каким-то причинам необходимо пользоваться длинными транзакциями для работы с оными блобами, то рекомендуется хранить блобы отдельно от базы.
M>(при этом вопрос согласованности блобов между собой оставляем за рамками)

Это ты согласился или озвучил мое решение?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>OK, берем сервер за 5k баксов. Что-то сильно изменилось? Что-то я не вижу, чтобы люди повсеместно видео и сырое аудио в БД пихали...

AVK>А я видел такое (на Оракле).

А я видел такое тольк в медиа серверах. Но там характер работы с данными совсем другой и не подходит под приведенный пример. В медиа-серверах какую-нибудь запись закинули, а потом read-only. Я же говорю о потребности постоянно удалять/изменять большие блобы.

AVK>А ты видел систему для дизайнерской конторы, в которой хранились данные по предложенной тобой схеме?

В смысле, аудио и видео в файлах? Только так и юзают в основном. Иногда сверху небольшая учетная система заказов со ссылками на файлы.

V>> Может, при наличии красивой теории, что-то не так на практике?

Ну вот только что поинтересовался у 2-х дизайнерских контор. Никто в БД свои работы не хранит. Может ты приведешь другие примеры?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>У вас же и-нет сервак, можно удаленно все делать.

AVK>И? Мы и делаем удаленно. Только это не значит что у нас есть человек, готовый регулярно за просто так делать нудную работу.

Я в том смысле, что в моей системе полный бэкап и сброс логов делался "одной кнопкой". Потом "эту нудную работу" выполняли раз в месяц в процедуре закрытия периода. Причем люди, далекие от БД в частности и от IT в общем.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>>Собственное файловое хранилище пишется за один день — что там сложного?

AVK>И написанное за 1 день хранилище сравнивают по надежности с промышленными БД? no comments

Надежность хранилища на ФС зависит от надежности самой файловой системы, железа и от надежности инструментария, применяющегося при разработке. Для оперирования файлами весьма надежно юзать не языки, типа С/С++, а скрипты. Кстати, файловое хранилище действительно пишется за 1 день. Там усложнять некуда, мы просто юзаем функциональность ФС. Мне упорно Merle приводит аргумент, что "ТАМ же ошибиться можно"... но ошибиться везде можно, а не только в задаче, которая менее 1% от общей трудоемкости.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

C>>Транзакции не нужны — достаточно атомарного переименования.

AVK>На многопользовательской системе? А как тогда бороться с разъезжанием БД и файлов?

Имена файлов и версий централизовано генеряться сервером приложений. А вслучае клиент-серверного решения — процедурами базы.

C>> Бэкап вместе
C>> с файлами БД с помощью third-party утилиты.

AVK>Аналогичный вопрос — как бороться с тем, что БД и файлы разъедутся? Останавливать на время бекапа всю систему?

Кстати, похоже именно так.
Это полезно в любом случае, раз уж мы договорились, что обсуждаем большие объемы данных в пересчете на 1-у запись. Ведь ты же знаешь, что происходит во время бэкапа, если мы что-то изменили — измененные записи закидываются снова и снова в бэкап (вариант закидывания в бэкап снапшота я даже не рассматриваю в виду предполагаемых объемов данных). А теперь представим, что во время бэкапа на неостановленной системе трафик изменения этих огромных данных сопоставим с траффиком скидывания на стриммер, например. Да у нас бэкап может никогда не закончится.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

>>> C>Транзакции не нужны — достаточно атомарного переименования.
>>> На многопользовательской системе? А как тогда бороться с разъезжанием БД
>>> и файлов?
C>>Правильно сервер писать — перед операциями с файлами надо взять нужную
C>>блокировку в БД.

AVK>Т.е. распределенная транзакция. И ты считаешь что это можно за один день написать?

Дык, вроде даже специальные ср-ва есть. Можно в скрипте на VB пользоваться распределенными транзакциями, через MTC.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Дык, вроде даже специальные ср-ва есть.

Есть. Использовать пробовал? Я пробовал.

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

V>Кстати, файловое хранилище действительно пишется за 1 день.

Ага, при том надежнее БД. Вобщем дальше продолжать, имхо, уже не имеет смысла.

V>Мне упорно Merle приводит аргумент, что "ТАМ же ошибиться можно"...

Правильно приводит.

V> но ошибиться везде можно, а не только в задаче, которая менее 1% от общей трудоемкости.

Ты сильно ошибаешься, полагая что надежное транзактное хранилище, обеспечивающее ACID, можно сделать легко. Мне в свое время приходилось — поверь, это суперсложная задача, даже при наличии DTC и прочих. То, что на ваших задачах вам повезло на ряд моментов не напороться еще не означает, что ваш самопал надежнее БД.

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

C>Я встречал ровно одну задачу, в которой своя база данных была
C>эффективнее какой-нибудь SQLite/BDB. Этой задачей было создание
C>иерархического хранилища внутри файла

Дык, а как же Structured Storage от MS?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

AndrewVK wrote:
> V> но ошибиться везде можно, а не только в задаче, которая менее 1% от
> общей трудоемкости.
> Ты сильно ошибаешься, полагая что надежное транзактное хранилище,
> обеспечивающее ACID, можно сделать легко. Мне в свое время приходилось —
> поверь, это суперсложная задача, даже при наличии DTC и прочих.
Если рассматривать файл как единый блок, то все что нужно — это
атомарные переименования. Хотя с DTC все действительно может быть сложно

Posted via RSDN NNTP Server 2.0

vdimas wrote:
> C>Я встречал ровно одну задачу, в которой своя база данных была
> C>эффективнее какой-нибудь SQLite/BDB. Этой задачей было создание
> C>иерархического хранилища внутри файла
> Дык, а как же Structured Storage от MS?
Как раз оно и было

То есть своя реализация IStorage.

Posted via RSDN NNTP Server 2.0

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

V>Тогда еще раз большими буквами. Ветка началась с простой просьбы пообсуждать, в каких случаях что лучше насчет ФС vs БД.
В 99-м году?

V>Вроде я упомянул про текст батчей.
Разьве? Ну пусть...

V> Мне приходилось динамически генерить SQL для батчей как на клиенте так и на сервере. И я не знаю (или не нашел) как в этом случае передать большие объемы данных. Почему динамически — это отдельный вопрос, связанный с мета-архитектурой системы.
То есть, опять приходим к тому, что ты так упорно отрицаешь — проблема не в блобах, а в архитектуре.

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

V>Ну... поясни проблему мне. А то я пока только намеки видел.
Да какие намеки, уже пяток постов твердится, что виновата архитектура, а ты опять все на блобы валишь.

V>Блин, кто и где объяснил?
На вскидку, Glebz тебе об этом писал.

V> Ты на что-то намекал несколько постов, так и не сказал конкретно, КАК ИМЕННО надо было поступать, и считаешь что что-то объяснил?
Я тебе сказал конкретно — передавать транзакцию одним батчем. Более того, я практически уверен, что варианты типов транзакций были довольно ограничены и даже твой вариант с временными таблицами можно было написать универсально, один раз, для всех запросов и потом просто пользовать его везде где можно. Не байт весть какое решение, но тоже работало бы и от подвисших транзакций избавило.

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

Ты даешь конкретный вопрос, я тебе даю конкретный ответ, в том что он тебя не устраивает — я не виноват... Вот возьмешь мена архитектором, тогда и поговорим обовсей системе..

V> В той системе, что пишем сейчас, например, половина таблиц неизвестна на момент выпуск системы. Такова, понимаешь ли, ныняшняя мета-реальность. Для бухгалтерских систем более 90% таблиц может быть неизвестно на момент выпука системы. А доверять юзверям писать хранимки на их прикладные сущности — это нереально.
Классно. Хранимки, значит нереально, а таблицы реально? (Метареальность опять-таки оставим в стороне)

V> Мы как-то пытались обсуждать систему (и здесь на RSDN проскакивали эти обсуждения), как из одного мета-кода генерить две части, ту, что будет исполняться на серваке БД, и ту, что сервером приложений... В общем, ни к чему не пришли, ибо задача слишком многофакторная.
Ну, не знаю насчет многофакторности, но если я правильно понял о чем ты, то вот у того же AVK такая система вполне себе работает.

V> Поэтому работаем "по старинке", то бишь, используем базу как хранилище объектов, а весь SQL генериться в run-time и исполняется в рамках транзакций как батч.
Отсюда опять-таки два вопроса, в чем проблема перенести и Run-time в Compile-time, и если уж нельзя то почему нельзя всю транзакцию передвавть одним батчем?

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

V>Потому и говорю, что согласно твоей логике "у всех руки кривые".
V> Кстати, "погибшие" ObjectSpaces — из той же оперы. Ну и популярный Hibernate (+N) и сотни других аналогичных ORM-тулзов — тоже.
Все вменяемые ORM, и озвученные тобой в том числе, позволяют работать с транзакциями в одном батче, и вообщем-то ни для кого не секрет, что использование их "в лоб", не задумываясь о том что ты делаешь, до добра не доводит.
И то что ты поступаешь так, вовсе не значит, что так поступают все, поэтому не обобщай...

V>У нас такой длинный и бесполезный флейм от твоей манеры говорить загадками.
Что я такого сказал загадочного?

V> Я пока встречал лишь расплывчатые определения "длинных транзакций". И что характерно, мой характер работы с БД не попадает под эти определения. Но ты почему-то причислил и указал на это как на ошибку и далее построил рассуждения на этом. Жду обоснования.
Ох. Длинная — это транзакция которая в процессе своей работы взаимодействует/зависит от ресурсов вне СУБД.

V>Это ты согласился или озвучил мое решение?
Это я согласился, с рядом оговорок. В первую очередь потому, что мне на данный момент системы образца 99-го года доставляют исключительно ностальгический интерес. Я ценю изящество с каким вы выкрутились из сложившейся ситуации, но оставляю засобой право считать, что существовало более удачное решение.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

S>> Твой подход при этом будет отнюдь не оптимальныим.
M>Оптимальным. И это не мой подход — это подход реальных высокопроизводительных систем, которые используют индексы на основе B+ деревьев.

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

S>> Неполучится. Как мне найти первоначальное значение записи по ключу, если она была модифицирована(ключ), и откомичена ???
M>Ненадо тебе это. не надо. Пойми ты наконец. Самому дереву, для своей модификации не нужны старые значения ключей от предыдущего коммита. Ну нафиг они там не уперлись. не нужны. есть гораздо более эффективные алгоритмы, и именно они и используются в реальных системах.
M>Если тебе, вот лично тебе, нужны предыдущие значения этих ключей, то ты их и сохраняй где-нибудь отдельно, а дереву работать — не мешай.
А зачем эту версионность вообще вводили если по твоим словам она не нужна.

S>> А то, что по сути это две базы.
M>Какие две базы? Мы об индексе говорим — не забыл?

Про версионность индексов.
S>>Смотри выше.
M>Блин, ты смотри. Такое впечатление, что ты вообще не читаешь что тебе пишут.

S>>Как при читающей транзакции по времени 2 часа мне помогут блокировки, без остановки записи.
M>Нету у тебя там двухчасовых транзакций. Вообще.
M>Подними две руки, поднеси их к ушам, прижми плотно, и отдели у себя в голове усилием воли два понятия:
M>1. глобальная транзакция в БД (здесь она у тебя хоть сутки идти может).
M>2. модификация дерева рамках этой транзакции (здесь никаких длинных транзакций не бывает, здесь все транзакции короткие и заранее известные).
M>И мы говорим именно о втором пункте, первый никого не интересует.
M>И вот пока ты эти две вещи у себя в голове не отделишь, разговаривать с тобой бесполезно. Нельзя все в одну кучу мешать.

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

S>> Мне нужен срез БД по времени без останоки записи.
M>Тебе может и нужен, а дереву для модификации — нет. А мы сейчас говорим именно о дереве и о том как оптимальнее всего с ним работать. И твоя версионность тут совершенно не причем. Ну то есть вообще.

Смотрим выше. Ладно мы друг друга плохо понимаем. Поэтому предлагаю на этом покончить.

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

S> Тогда давай разбираться.
А до этого мы чем занимались?

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

S>Что будет более производительным.
Нет. Не будет. Это будет менее производительным, так как тратится время и ресурсы процессора на копирование страницы.

S>А зачем эту версионность вообще вводили если по твоим словам она не нужна.
Ее вводили для прикладного кода, а не для модификации дерева. А мы сейчас говорим именно о модификации дерева.
Я устал тебе повторять, что это две совершенно разные вещи.

S> Про версионность индексов.
Самим по себе индексам версионность ненужна, они прекрасно справляются без нее.

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

S> А это может быть достигнуто только при применении версионности страниц дерева.
Все, надоело. Берешь Бернстайна, берешь Ульмана, берешь Грея, внимательно читаешь, потом берешь исходники Postgree, смотришь доки MSSQL и Oracle. И только после этого возвращаешься и мы продолжаем разговор про версионность.
И таких категоричных и неверных утверждений ты больше не делаешь, если тебе ничего лучшего придумать не получается — это вовсе не значит, что лучшего алгоритма не существует.

S> Смотрим выше.
На что? Я же не виноват что ты не можешь отделить задачу работы с деревом от своих личных прикладных нужд.

S> Поэтому предлагаю на этом покончить.
Давно пора.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

M>внимательно читаешь, потом берешь исходники Postgree, смотришь доки MSSQL и Oracle. И только после этого возвращаешься и мы продолжаем разговор про версионность.

кстати, если версионности страниц индекса нет, то как версионные БД производят поиск по индексу при условии что нужно работать с данными "в прошлом"? т.е. если индексы чисто блокировочные, и есть две транзакции, первая уровня изоляции как минимум oracle statement level read (пусть, oracle read only) которая строит отчет, а вторая удаляет все записи из таблицы с помощью delete. очевидно что вторая транзакция достаточно сильно модифицирует индекс, вы хотите сказать что она будет заблокирована пока построение отчета (с использованием индекса) не закончится?

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

N> очевидно что вторая транзакция достаточно сильно модифицирует индекс, вы хотите сказать что она будет заблокирована пока построение отчета (с использованием индекса) не закончится?
Нет, читающая транзакция полезет в лог за старыми значениями. В данном случае старые значения нужны не самому индексу для своей модификации, а читающей транзакции. И это ее головная боль, как эти значения получить, вся необходимая информация ей будет предоставлена, но, еще раз повторюсь, сам для себя индекс этой информацией не пользуется, а у нас речь именно о том как работает сам индекс, а не транзакции поверх него.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

N>> очевидно что вторая транзакция достаточно сильно модифицирует индекс, вы хотите сказать что она будет заблокирована пока построение отчета (с использованием индекса) не закончится?
M>Нет, читающая транзакция полезет в лог за старыми значениями. В данном случае старые значения нужны не самому индексу для своей модификации, а читающей транзакции. И это ее головная боль, как эти значения получить, вся необходимая информация ей будет предоставлена, но, еще раз повторюсь, сам для себя индекс этой информацией не пользуется, а у нас речь именно о том как работает сам индекс, а не транзакции поверх него.
То бишь для того, что бы обратиться по индексу, сначало я должен обратиться к некоему глобальному индексу где храняться все измененный ключи, а затем к если не нашел то, к таблице??? Хорошо это вариант,а как быть при проходе по индексу????

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

S>> А это может быть достигнуто только при применении версионности страниц дерева.
M>Все, надоело. Берешь Бернстайна, берешь Ульмана, берешь Грея, внимательно читаешь, потом берешь исходники Postgree, смотришь доки MSSQL и Oracle. И только после этого возвращаешься и мы продолжаем разговор про версионность.
M>И таких категоричных и неверных утверждений ты больше не делаешь, если тебе ничего лучшего придумать не получается — это вовсе не значит, что лучшего алгоритма не существует.

А на пальцах никак???? А можно исходники MSSQL и Oracle???

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

V>> Мы как-то пытались обсуждать систему (и здесь на RSDN проскакивали эти обсуждения), как из одного мета-кода генерить две части, ту, что будет исполняться на серваке БД, и ту, что сервером приложений... В общем, ни к чему не пришли, ибо задача слишком многофакторная.
M>Ну, не знаю насчет многофакторности, но если я правильно понял о чем ты, то вот у того же AVK такая система вполне себе работает.

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

V>> Поэтому работаем "по старинке", то бишь, используем базу как хранилище объектов, а весь SQL генериться в run-time и исполняется в рамках транзакций как батч.
M>Отсюда опять-таки два вопроса, в чем проблема перенести и Run-time в Compile-time,

В компайл-тайм непонятно еще какая база будет в качестве бэкенда, у каждого адаптера есть свой SQL-рендерер.

M> и если уж нельзя то почему нельзя всю транзакцию передвавть одним батчем?

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

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

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

Комментировать не могу, ибо это "общепринятая практика". Она диктуется тем, что "маленькие команды" поднимают "большие" задачи. Если бы вынуждены полностью вручную описывать писать персистентность своих данных в БД, и тем более, поддерживать это все up to date после рефакторинга, нам бы потребовалось в двое больше народу на разработку.

V>>Потому и говорю, что согласно твоей логике "у всех руки кривые".
V>> Кстати, "погибшие" ObjectSpaces — из той же оперы. Ну и популярный Hibernate (+N) и сотни других аналогичных ORM-тулзов — тоже.
M>Все вменяемые ORM, и озвученные тобой в том числе, позволяют работать с транзакциями в одном батче, и вообщем-то ни для кого не секрет, что использование их "в лоб", не задумываясь о том что ты делаешь, до добра не доводит.

Ну поэкпериментируй сам с NHibernate и с теми же большими блобами

M>И то что ты поступаешь так, вовсе не значит, что так поступают все, поэтому не обобщай...

Я как раз так не поступаю. У нас свой ORM-тул, построенный на базе RFD. Просто в текущей задаче не стоит вопрос генерирования очень больших текстов батчей, поэтому автогенерированный нами SQL нас устраивает.

V>> Я пока встречал лишь расплывчатые определения "длинных транзакций". И что характерно, мой характер работы с БД не попадает под эти определения. Но ты почему-то причислил и указал на это как на ошибку и далее построил рассуждения на этом. Жду обоснования.
M>Ох. Длинная — это транзакция которая в процессе своей работы взаимодействует/зависит от ресурсов вне СУБД.

Оk. Т.е. если я явно в коде создал транзакцию, типа connection.BeginTransaction(), то это — длинная транзакция. Но понимаешь в чем дело... Когда я должен согласованно прочитать кучу данных, причем разнородную кучу данных... Более того, то, что будет в последней части кучи зависит от тех результатов, что пришли в первой части кучи... Получается, что для такого согласованного извлечения множества данных я должен вытаскивать их из базы в рамках одной транзакции, но я пока не представляю как это сделать в рамках одного батча у нас (просто решение о зачитке последующих кусков принимается исходя из состояний кешей для соотв. связанных сущностей, т.е. из текста SQL батча этот факт не разглядеть). Т.е., если бы все просто сводилось к серии запросов — то было бы проще... А так, я явно создаю транзакцию, управляю временем ее жизни ВНЕ БД, т.е. получается — создаю длинную транзакцию... И если в этот момент сервак приложений по каким-либо причинам грюкнется, то вот у нас и останется та самая подвисшая транзакция, "из-за неправильной архитектуры" (c) не мой. И что характерно, похоже, что многие репортовые тулы работают аналогично. Например у MS есть иерархический провайдер, что позволяет частично решить описанную проблему, но он у такой провайдер есть только к MS SQL.

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

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

Вопрос действительно интересный. Гораздо проще сделать систему которая обслуживает многие тысячи или миллионы коротких транзакций в сутки (типа — банковская платежная система), ибо БД идеально заточены имено под такие сценарии использования.

Так же вполне себе сущестуют медиа-серваки. Но там тоже характер работы с данными весьма специфичен, а именно: строка данных (пусть даже очень большая) заливается лишь однажды, а затем read-only.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>Дык, вроде даже специальные ср-ва есть.

AVK>Есть. Использовать пробовал? Я пробовал.

Я пробовал, когда создавал локальный кеш на основе MDB-формата. Периодически синхронизировал его с основным MS SQL серваком, причем, не по самой быстрой линии связи, в режиме транзакции, разумеется. Вроде, работало... Вернее, у меня даже в памяти подробности не отложились, видать ни с чем таким серьезным и непреодолимым не столкнулся.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AVK>Ты сильно ошибаешься, полагая что надежное транзактное хранилище, обеспечивающее ACID, можно сделать легко. Мне в свое время приходилось — поверь, это суперсложная задача, даже при наличии DTC и прочих. То, что на ваших задачах вам повезло на ряд моментов не напороться еще не означает, что ваш самопал надежнее БД.

Ну, смотри сам и покажи тонкие места:
— сервер приложений генерит уникальную версию файла (т.е. генерится уникальное имя)
— записывает файл на диск
— после проверки записанного файла заносит в базу запись о нем (т.е. подменяет линк на более новую версию... триггер таблицы мог снести старое значение в журнал изменений версий)
— после этого, если все прошло успешно, т.е. никаких эксепшенов не произошло и мы их не сгенерили, то выполнение некоего удаленного метода с клиентской машины закончилось успешно, и форма, например, закрылась.
— если произошли какие-то ошибки, то клиенту показывается MessageBox с ошибкой, и он может либо опять попробовать что-то там сохранить, либо попробовать сохранить данные локально (т.е. перейти в режим off-line).

Я чего-то в упор не вижу причин нарушений целостности БД и рассогласования данных по вине разработчика. И последовательность действий вроде тривиальная.

Есть конечно замечания к процедуре бэкапа/восстановления, здесь описал: Re[29]: Filesystem vs. Database

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

>> C>Я встречал ровно одну задачу, в которой своя база данных была
>> C>эффективнее какой-нибудь SQLite/BDB. Этой задачей было создание
>> C>иерархического хранилища внутри файла
>> Дык, а как же Structured Storage от MS?
C>Как раз оно и было

То есть своя реализация IStorage.

А чем лучше "ихней"?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

На самом деле есть другой вариант

Запись ключа инднкса состоит из ключа, номера транзакции, статуса (удалена, добавлена) и ссылку на предудущую транзакцию с данным ключем. Ключи могут только удаляться или добавляться.
Ссылка на предыдущую версию ключа у ключей содержащих PK записи можно не держать, т.к. версию можно получить на уровне записи. Замещать удаленные ключи можно либо при модификации страницы.
Этот вариант подходит????

vdimas wrote:
>> > C>Я встречал ровно одну задачу, в которой своя база данных была
>> > C>эффективнее какой-нибудь SQLite/BDB. Этой задачей было создание
>> > C>иерархического хранилища внутри файла
>> > Дык, а как же Structured Storage от MS?
> C>Как раз оно и было То есть своя реализация IStorage.
> А чем лучше "ихней"?
Хотя бы тем, что "собирает мусор" — в стандартной реализации при
удалении потока его страницы остаются в файле. И единственный способ
уменьшить его размер — создать новое хранилище и скопировать в него все
из старого.

Ну и с большими данными у меня более резво работает (позволяет делать
memory mapping через специальный интерфейс).

Posted via RSDN NNTP Server 2.0

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

V>- сервер приложений генерит уникальную версию файла (т.е. генерится уникальное имя)

Версионник значит. Транзакция в БД уже открыта?

V>- записывает файл на диск
V>- после проверки записанного файла заносит в базу запись о нем (т.е. подменяет линк на более новую версию... триггер таблицы мог снести старое значение в журнал изменений версий)

Транзакцию БД закрываем?

V>- после этого, если все прошло успешно, т.е. никаких эксепшенов не произошло и мы их не сгенерили, то выполнение некоего удаленного метода с клиентской машины закончилось успешно, и форма, например, закрылась.
V>- если произошли какие-то ошибки, то клиенту показывается MessageBox с ошибкой, и он может либо опять попробовать что-то там сохранить, либо попробовать сохранить данные локально (т.е. перейти в режим off-line).

V>Я чего-то в упор не вижу причин нарушений целостности БД и рассогласования данных по вине разработчика. И последовательность действий вроде тривиальная.

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

... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>

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

AVK>Есть. Использовать пробовал? Я пробовал.
Ну и я пробовал. По сравнению с прямым DTS — очень легко. А вот System.Transaction по сравнению с MTS — легче легкого. Он собственно и предназначен именно для построения своих транзакционных ресурсов. Сделать распределенные файловые транзакции, несколько строк кода. Другой вопрос насколько он будет надежен rollback. В случае если у тебя файлы по несколько сотен мегабайт, то формирование каждой копии будет тяжелой операцией. Если rollbaчить в самом файле, то уже меньше гарантий что будет сделана система, которая не упадет в случае выключения питания. И достичь скорости БД по записи на больших данных, тоже вряд ли удастся. Вобщем, серьезная система с полпинка тут не построишь.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

>> C>Как раз оно и было То есть своя реализация IStorage.
>> А чем лучше "ихней"?
C>Хотя бы тем, что "собирает мусор" — в стандартной реализации при
C>удалении потока его страницы остаются в файле. И единственный способ
C>уменьшить его размер — создать новое хранилище и скопировать в него все
C>из старого.

C>Ну и с большими данными у меня более резво работает (позволяет делать
C>memory mapping через специальный интерфейс).

Хм... уже хочу такой же

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>>- сервер приложений генерит уникальную версию файла (т.е. генерится уникальное имя)

AVK>Версионник значит. Транзакция в БД уже открыта?

Пусть мы просто сгенерировали уникальный идентификатор нового документа и не более того. Нам же надо сохранить новую версию под уникальным именем.

V>>- записывает файл на диск
V>>- после проверки записанного файла заносит в базу запись о нем (т.е. подменяет линк на более новую версию... триггер таблицы мог снести старое значение в журнал изменений версий)

AVK>Транзакцию БД закрываем?

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

V>>Я чего-то в упор не вижу причин нарушений целостности БД и рассогласования данных по вине разработчика. И последовательность действий вроде тривиальная.

AVK>Ну вот смотри. Предположим пишем файл. Файл записывается успешно. Далее пишем в БД. БД тоже отрабатывает успешно и транзакцию закрывает. Однако при отсылке результата коммита клиенту происходит сбой. Клиент думает что транзакция не завершилась и шлет данные по новой. В итоге в БД две идентичных записи.

Ну... это очень грубо. Клиент же не просто шлет: "сохрани вот этот мусор хоть как нибудь", он же пошлет примерно так: "сохрани вот эту версию под новым номером, и вот тебе мой текущий кукис". Мы лезем, проверяем версии, видим, кто именно изменил и под каким кукисом. Если этот же клиент и под тем же кукисом — понимаем, что он нас не понял. В смысле, с первого раза не понял и повторяем ответ. Если это был не он и текущая версия не совпадает с его заявленной, то выдаем некий диалог, где честно говорим о конфликте (типа как в CVS). В принципе, statefull-модель и управление блокировками документов (на уровне сервера приложений, а не БД) позволяет частично разруливать этот момент. Если же это тот же клиент, но с более свежым кукисом, значит, сохраняем по новой и возвращаем результат по новой (новое имя версии). Если это тот же клиент но с более старыми кукисами — кричим "kernel panic, we are sinking", или "we are under hacking" и даем отлуп

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

Да... Управление доступом к объектам... Мне удалось первый раз качественно разрулить это дело только в системе, где я полностью управлял сессиями. В сервере на дотнет это сделать оказалось еще легче. Более того, сессия является спонсором для всех временных и statefull сесионных объектов.

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

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

Файлы документов никогда не изменяются, по очевидной причине. Всегда сохраняются новые версии. После сохранения новой версии что делать со старой? А это уже пусть политика и настройки решают.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AVK>Ну вот смотри. Предположим пишем файл. Файл записывается успешно. Далее пишем в БД. БД тоже отрабатывает успешно и транзакцию закрывает. Однако при отсылке результата коммита клиенту происходит сбой. Клиент думает что транзакция не завершилась и шлет данные по новой. В итоге в БД две идентичных записи.
AVK>Сценарий посложнее. Клиент читает документ. Обращается к БД, считывает заголовок. Потом лезет к файлу и считывает его. После этого другой клиент этот документ грохает. Первый клиент в этот момент что то там в документе анализирует и на его основании вносит что то в БД. Упс, приплыли.
Это все достаточно легко решаемые проблемы. Есть другая, трудно нерешаемая. У нас есть две системы и две системы backup. Одна система бэкапится в момент t1 другая в момент t2, в результате при восстановлении изменения t2-t1 на одной из систем отсутсвует. То есть нет никакой гарантии что существует файл прописанный в БД, или наоборот, что для файла существует запись в БД.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

... [RSDN@Home 1.2.0 alpha rev. 619]

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

S> Запись ключа инднкса состоит из ключа, номера транзакции, статуса (удалена, добавлена) и ссылку на предудущую транзакцию с данным ключем.
Да, только ссылка на предыдущую версию данного ключа.

S> Ключи могут только удаляться или добавляться.
Да. Причем это требование никак не связано с версионностью. Любая модификация ключа в дереве- это всегда удаление старого значения и добавление нового.

S> Этот вариант подходит????
Примерно так и работает сиквел.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

S>А на пальцах никак????
На пальцах я тебе уже как мог рассказал...

S> А можно исходники MSSQL и Oracle???
Найдешь — поделись...

... [RSDN@Home 1.2.0 alpha rev. 619]

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

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

S>> Запись ключа инднкса состоит из ключа, номера транзакции, статуса (удалена, добавлена) и ссылку на предудущую транзакцию с данным ключем.
M>Да, только ссылка на предыдущую версию данного ключа.

S>> Ключи могут только удаляться или добавляться.
M>Да. Причем это требование никак не связано с версионностью. Любая модификация ключа в дереве- это всегда удаление старого значения и добавление нового.

На уровне промышленных БД да, на уровне своего кода не всегда.

S>> Этот вариант подходит????
M>Примерно так и работает сиквел.
А на пальцах сложно было объснить, всё своим умом доходить надо

Это один из вариантов. Версионность на уровне страниц оправдана при массовых модификациях. Напрмер многострочная часть документа, и его движения. Здесь она оправдана. Кроме того версионность на страницы увеличивает скорость чтения (нужно сверять только версию страницы).
Учитывая, что больше чтения чем записей такой подход вполне оправдан. Кроме того собирать ненужные страницы легче чем дефрагментировать дерево от ненужных версий на уровне единичных ключей, плюс вырожденность страниц будет большой при частых удалениях.

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

S> На уровне промышленных БД да, на уровне своего кода не всегда.
Это уже проблемы твоего кода. Просто модифицировать ты не имеешь права, так как с очень большой вероятностью ключ во время модификации переедет на другую страницу, поэтому любая модификация ключа индекса это всегда удаление+вставка, если мы говорим о B+.

S> А на пальцах сложно было объснить, всё своим умом доходить надо

Блин. Я устал уже повторять. Мы. обсуждаем. другой. вопрос. К механизму модификации дерева ссылки на предыдущие версии не имеют никакого отношения, они там не используются. Эти предыдущие версии лежат в совершенно отдельном хранилище и обслуживаются отдельным алгоритмом.
Механизм версионности совершенно другая тема не имеющая отношения к модификации дерева. Я не понимаю как эту мысль до тебя донести. Моего русского языка на это не хватает.

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

S> Кроме того версионность на страницы увеличивает скорость чтения (нужно сверять только версию страницы).
Ошибаешься. Версию записи нужно сверять всегда.

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

... [RSDN@Home 1.2.0 alpha rev. 619]

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

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

Posted via RSDN NNTP Server 2.0

AndrewVK wrote:
> V>Я чего-то в упор не вижу причин нарушений целостности БД и
> рассогласования данных по вине разработчика. И последовательность
> действий вроде тривиальная.
> Ну вот смотри. Предположим пишем файл. Файл записывается успешно. Далее
> пишем в БД. БД тоже отрабатывает успешно и транзакцию закрывает. Однако
> при отсылке результата коммита клиенту происходит сбой.
Называется "эвристическое событие" (heuristic event/completion), хотя в
описаной ситуации просто произойдет откат файла назад (так как коммит не
прошел). Точно так же может быть и в ситуации с двумя БД в
распределенной транзакции.

Теоретически эвристические события никак не предотвращаются, благодаря
двухфазному коммиту (two-phase commit) можно только уменьшить их
вероятность.

Для борьбы с этим можно использовать разные механизмы, например, чтобы
файлы не затирали предидущие.

> Клиент думает что транзакция не завершилась и шлет данные по новой. В итоге в БД две
> идентичных записи.
Версирование рулит.

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

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

Posted via RSDN NNTP Server 2.0

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

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

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

Согласен,

S>> А на пальцах сложно было объснить, всё своим умом доходить надо

M>Блин. Я устал уже повторять. Мы. обсуждаем. другой. вопрос. К механизму модификации дерева ссылки на предыдущие версии не имеют никакого отношения, они там не используются. Эти предыдущие версии лежат в совершенно отдельном хранилище и обслуживаются отдельным алгоритмом.

Хорошо при модификации дерева, будут пермещаться только те версии записи индекса, которые актуальны, и будуть затирать удаленные записи чья версия устарела.

При версионности на уровне страниц, тоже несколько другой алгоритм при модификации.

Изначально я говорил о версионности индекса сначало был предложен вариант с версионностью страниц с которым ты был полностью не согласен, Затем вариант с версионностью записи индекса с чем ты согласился.
Заметь что оба варианта по алгоритму отличаются от обычного.

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

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

Есть здравый смысл. Если на чтение тратится во много раз больше, то время записи не является лимитирующей стадией.

Второе не ошибается тот кто ничего не делает,все твои ссылки на промышленные БД.
S>> Кроме того версионность на страницы увеличивает скорость чтения (нужно сверять только версию страницы).
M>Ошибаешься. Версию записи нужно сверять всегда.

Зачем, если есть версия страницы????

S>> Кроме того собирать ненужные страницы легче чем дефрагментировать дерево от ненужных версий на уровне единичных ключей, плюс вырожденность страниц будет большой при частых удалениях.

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

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

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

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

S>Согласен,

Вернее не совсем, я могу изменять ссылку индекса по аналогии со словарем, или значения полей кластерноого индекса.

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

S> Хорошо при модификации дерева, будут пермещаться только те версии записи индекса, которые актуальны, и будуть затирать удаленные записи чья версия устарела.
Чего хорошего-то? Ты смешиваешь два принципиально разных механизма. Зачем?

S> Заметь что оба варианта по алгоритму отличаются от обычного.
Не отличаются.
Блин, достал. 2 алгоритма, два. понимаешь?
1. Модификация дерева.
2. Поиск разных версий для внешнего кода.
Первый никак не пользуется вторым. В данной ветке идет обсуждение исключительно первого. Версионность в нем не применяется вообще.
Неиспользуется данный механизм при модификации дерева.
Так понятно? До тех пор пока ты этого не поймешь и не определишься о каком из этих алгоритмов ты говоришь — разговор смысла не имеет.

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

S> Есть здравый смысл.
Есть. Предлагаю тебе им воспользоваться.

S> Второе не ошибается тот кто ничего не делает,все твои ссылки на промышленные БД.
Во-первых, прежде чем что-то делать, рекомендуется подумать и ознакомиться с тем, как аналогичные вещи делали до тебя.
А во-вторых, данная подветка исключительно о том как это реализовано на самом деле, и о том, почему сделано именно так, а не о том как ты можешь это придумать.

S> Зачем, если есть версия страницы????
Затем, что на странице могут быть записи разных версий.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

V>Ну... это очень грубо. Клиент же не просто шлет: "сохрани вот этот мусор хоть как нибудь", он же пошлет примерно так: "сохрани вот эту версию под новым номером, и вот тебе мой текущий кукис". Мы лезем, проверяем версии, видим, кто именно изменил и под каким кукисом. Если этот же клиент и под тем же кукисом — понимаем, что он нас не понял. В смысле, с первого раза не понял и повторяем ответ. Если это был не он и текущая версия не совпадает с его заявленной, то выдаем некий диалог, где честно говорим о конфликте (типа как в CVS).

Вот вот, что и требовалось доказать. Закат солнца вручную.

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>

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

GZ>Это все достаточно легко решаемые проблемы.

Я бы так не сказал. Проблем там предостаточно. Нам просто пришлось реализовывать свои транзакции и я очень хорошо представляю во что обходится высокий уровень изоляции.

GZ> Есть другая, трудно нерешаемая. У нас есть две системы и две системы backup. Одна система бэкапится в момент t1 другая в момент t2, в результате при восстановлении изменения t2-t1 на одной из систем отсутсвует.

Ты не понял, они предлагают пользователям курить в сторонке, пока бекап происходит. Соотв. t2-t1 всегда равно 0.

... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>

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

C>Называется "эвристическое событие" (heuristic event/completion), хотя в
C>описаной ситуации просто произойдет откат файла назад (так как коммит не
C>прошел). Точно так же может быть и в ситуации с двумя БД в
C>распределенной транзакции.

C>Теоретически эвристические события никак не предотвращаются, благодаря
C>двухфазному коммиту (two-phase commit) можно только уменьшить их
C>вероятность.

Спасибо за информацию. Ты что, всерьез считаешь что я об этом не знал?

C>Для борьбы с этим можно использовать разные механизмы, например, чтобы
C>файлы не затирали предидущие.

Ага, и все за один день работы.

>> Клиент думает что транзакция не завершилась и шлет данные по новой. В итоге в БД две
>> идентичных записи.
C>Версирование рулит.

И все за один день работы.

C>С этого места помедленнее — файлы в системах документоборота обычно
C>нельзя уничтожить. Они просто помечаются в БД как "устаревшие" и через
C>некоторое время могут быть прибиты "сборщиком мусора" (обычно после их
C>архивирования).

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

>> Первый клиент в этот момент что то там в
>> документе анализирует и на его основании вносит что то в БД. Упс, приплыли.
C>В БД для этого нужно хранить запись о том, что документ заблокирован.

Называется закат слонца вручную.

... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>

AndrewVK wrote:
> C>Для борьбы с этим можно использовать разные механизмы, например, чтобы
> C>файлы не затирали предидущие.
> Ага, и все за один день работы.
Да, один день. А что сложного? При записи/изменении файл создается с
уникальным именем (типа tmpDoc12354.doc), при коммите переименовывается
в следующий документ (Doc21.doc), а старый файл (Doc20.doc) становится
"устаревшим".

Для этой схемы в будущем планируем использовать Subversion — там и явные
транзакции с разруливанием конфликтов есть

При любом сбое можно все руками без всяких проблем переименовать и
работать дальше.

>> > идентичных записи.
> C>Версирование рулит.
> И все за один день работы.
Нам не нужны все возможные сценарии, используется простейший
lock-modify-commit-unlock.

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

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

Posted via RSDN NNTP Server 2.0

Здравствуйте, AndrewVK, Вы писали:
AVK>Называется закат слонца вручную.
Это да! Как известно, результат радикальным образом зависит от размера слонца. Маленького вручную закатить еще можно, но это приводит к иллюзиям. Однако если слонец достаточно велик, то ручной закат быстро выходит за пределы коммерческой реализуемости.

1.1.4 stable rev. 510

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

S>Это да! Как известно, результат радикальным образом зависит от размера слонца. Маленького вручную закатить еще можно, но это приводит к иллюзиям. Однако если слонец достаточно велик, то ручной закат быстро выходит за пределы коммерческой реализуемости.

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

Здравствуйте, eao197, Вы писали:
E>Только разработчикам Opera об этом не рассказывайте, пожалуйста. А то заменят свое кустарное, но очень быстрое хранилище почтовых сообщений, на что-нибудь промышленно-стандартное.
Разбудите меня, когда опера научится поддерживать ACID в своем кустарном хранилище.

1.1.4 stable rev. 510

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

S>Разбудите меня, когда опера научится поддерживать ACID в своем кустарном хранилище.

Это будет сложно, т.к. я не знаю, как именно у них хранилище организованно (вполне вероятно, что ACID у них есть).
Но вот почту в Opera терять пока не приходилось (тьфу-тьфу). Даже после жестоких принудительных перезагрузок машины.

Здравствуйте, eao197, Вы писали:
E>Это будет сложно, т.к. я не знаю, как именно у них хранилище организованно (вполне вероятно, что ACID у них есть).
E>Но вот почту в Opera терять пока не приходилось (тьфу-тьфу). Даже после жестоких принудительных перезагрузок машины.
Это просто означает, что не все йогурты одинаково полезны. Мне лично совершенно лень скачивать оперу, но что-то мне подсказывает, что никакой атомарности не будет, если в опере, скажем, выделить 5000 писем и начать перекладывать их из папки в папку. Вряд ли они вернут все на место если я рубану в это время питание.
А то, что файлуха умеет атомарно выполнять операцию переименования отдельного файла, малоинтересно для общего случая.

Вообще лично я встречал только одну софтину, претендующу на ACID поверх FS. Это SVN. И то, ее клиент совершенно неатомарен. Ну и отлаживалось это дело не один день, и даже не один месяц. Поэтому я не верю во все эти пальцы про ACID на FS. Если бы это было так просто, то это давно бы сделали. А пока мы имеем ReiserFS 4 и SVN. И, собственно, всё.

Мораль: если вы храните именованные блобы, и у вас не бывает транзакций, затрагивающих больше одного блоба, то FS — самое то. Потому что FS и есть СУБД для управления именованными блобами. В частности, ТЗ на оперу запросто может ограничиваться как раз управлением именованными блобами, и тогда никаких претензий к их стораджу нет.

А как только появляется намек на какую-то структуру внутри этих блобов, или на согласованные изменения, FS начинают сосать как промышленный пылесос.
Глупо думать, что подход, приемлемый для однопользовательского почтовика, будет столь же весело работать для многопользовательского документооборота.

1.1.4 stable rev. 510

Sinclair wrote:
> Вообще лично я встречал только одну софтину, претендующу на ACID поверх
> FS. Это SVN. И то, ее /клиент/ совершенно неатомарен.
Почему же, вот SVK вполне атомарен. Просто в обычном клиенте SVN
атомарность нафиг не сдалась.

> Ну и отлаживалось
> это дело не один день, и даже не один месяц. Поэтому я не верю во все
> эти пальцы про ACID на FS. Если бы это было так просто, то это давно бы
> сделали. А пока мы имеем ReiserFS 4 и SVN. И, собственно, всё.
В SVN используются эффективные алгоритмы дельтификации и разруливания
конфликтов. Они и занимают большую часть кода, а простейший движок для
статической структуры и без разруливания конфликтов — это совсем несложно.

> Мораль: если вы храните именованные блобы, и у вас не бывает транзакций,
> затрагивающих больше одного блоба, то FS — самое то.
Скорее не "затрагивающих больше одного блоба", а "использующих простую
модель доступа".

> есть СУБД для управления именованными блобами. В частности, ТЗ на оперу
> запросто может ограничиваться как раз управлением именованными блобами,
> и тогда никаких претензий к их стораджу нет.
Ну примерно это вам и говорили уже сообщений 30

Posted via RSDN NNTP Server 2.0

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

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

S>> Хорошо при модификации дерева, будут пермещаться только те версии записи индекса, которые актуальны, и будуть затирать удаленные записи чья версия устарела.
M>Чего хорошего-то? Ты смешиваешь два принципиально разных механизма. Зачем?

S>> Заметь что оба варианта по алгоритму отличаются от обычного.
M>Не отличаются.
M>Блин, достал. 2 алгоритма, два. понимаешь?
M>1. Модификация дерева.
M>2. Поиск разных версий для внешнего кода.
M>Первый никак не пользуется вторым. В данной ветке идет обсуждение исключительно первого. Версионность в нем не применяется вообще.
M>Неиспользуется данный механизм при модификации дерева.
M>Так понятно? До тех пор пока ты этого не поймешь и не определишься о каком из этих алгоритмов ты говоришь — разговор смысла не имеет.

Вообщеть весь сыр бор пошел вот отсюда http://www.rsdn.ru/Forum/Message.aspx?mid=1710977&only=1
А вернее о варанте хранение ссылок на элементы в родительских страницах.
S>> Я не знаю о чем ты говорил, я как раз о версионности как на таковой в плане индекса.
M>Нету версионности как таковой в плане индекса. Есть два разных механизма, каких именно — смотри выше. Я тебе уже все разживал, больше немогу. Не можешь понять — поверь: при модификации индекса версионность не используется. точка.

S>> Есть здравый смысл.
M>Есть. Предлагаю тебе им воспользоваться.

S>> Второе не ошибается тот кто ничего не делает,все твои ссылки на промышленные БД.
M>Во-первых, прежде чем что-то делать, рекомендуется подумать и ознакомиться с тем, как аналогичные вещи делали до тебя.
M>А во-вторых, данная подветка исключительно о том как это реализовано на самом деле, и о том, почему сделано именно так, а не о том как ты можешь это придумать.
Нет смотри выше
S>> Зачем, если есть версия страницы????
M>Затем, что на странице могут быть записи разных версий.

Опять в варианте с версионностью на уровне страниц, версии на уровне записи индекса актуальна относително версии страницы.
На уровне ссылки они разные. Кроме того для кластерных индексов и этого не надо.
Или ты отвергаешь вообще версионность на уровне страниц???

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

S> Вообщеть весь сыр бор пошел вот отсюда http://www.rsdn.ru/Forum/Message.aspx?mid=1710977&only=1
То есть, мы все еще говорим об индексе и только об индексе?

S> А вернее о варанте хранение ссылок на элементы в родительских страницах.
В индексе?

S>Опять в варианте с версионностью на уровне страниц, версии на уровне записи индекса актуальна относително версии страницы.
Можно, конечно, сделать и так, но на практике это слишком накладно. В том же Оракле, в котором версионнсть постраничная (не индексов, а данных) так не поступают, а осуществляют переход на новую страницу только если нужная версия записи на странице не нашлась, то есть отслеживается и версия записи, которая не равна версии страницы.
Специально для тебя оговорюсь, сейчас я говорю про версионность вообще, а не версионность при работе с индексом. При работе непосредственно с индексом версионность вообще не используется.

S> Кроме того для кластерных индексов и этого не надо.
Забудь про понятие "кластерный индекс". С точки зрения работы с B+ — "кластерный" и "не кластерный" не отличаются ничем.
Похоже у тебя проблема с выделением абстракций, ты все время скатываешься на какую-то конкретику там, где этого не надо.

S> Или ты отвергаешь вообще версионность на уровне страниц???
Я не верю в ее полезность при работе непосредственно с B+ деревом. И в принципе не верю в применимость твоего варианта версионности на уровне страниц. Я тебе в очередной раз настоятельно советую, прежде чем бросаться писать что-то своё — тщательно ознакомиться с существующими решениями.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

AVK>Процессор Pentium4 2.66 — $100
AVK>Серверная мамка от Supermicro — $230
AVK>Серверный корпус от того же Supermicro — $110
AVK>Гиг памяти ECC Registered от Kingston — $120
AVK>2 винта по 200 гиг для зеркала — $180

Что за винты?

AVK>Итого — $740, в заданные рамки уложились и получили то же самое по надежности железо от тех же самых производителей, что и на rsdn.

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

S>> Вообщеть весь сыр бор пошел вот отсюда http://www.rsdn.ru/Forum/Message.aspx?mid=1710977&only=1
M>То есть, мы все еще говорим об индексе и только об индексе?

S>> А вернее о варанте хранение ссылок на элементы в родительских страницах.
M>В индексе?
да
S>>Опять в варианте с версионностью на уровне страниц, версии на уровне записи индекса актуальна относително версии страницы.
M>Можно, конечно, сделать и так, но на практике это слишком накладно. В том же Оракле, в котором версионнсть постраничная (не индексов, а данных) так не поступают, а осуществляют переход на новую страницу только если нужная версия записи на странице не нашлась, то есть отслеживается и версия записи, которая не равна версии страницы.
M>Специально для тебя оговорюсь, сейчас я говорю про версионность вообще, а не версионность при работе с индексом. При работе непосредственно с индексом версионность вообще не используется.
Это я понял.
S>> Кроме того для кластерных индексов и этого не надо.
M>Забудь про понятие "кластерный индекс". С точки зрения работы с B+ — "кластерный" и "не кластерный" не отличаются ничем.
Не совсем. Так при изменение записи просхисходит на уровне индекса именно аналог словаря, т.к. Key,Value хранятся совместно. При простом индексе изменяется Запись по ссылке.
M>Похоже у тебя проблема с выделением абстракций, ты все время скатываешься на какую-то конкретику там, где этого не надо.
Есть такой недостаток. Каюсь.
S>> Или ты отвергаешь вообще версионность на уровне страниц???
M>Я не верю в ее полезность при работе непосредственно с B+ деревом. И в принципе не верю в применимость твоего варианта версионности на уровне страниц. Я тебе в очередной раз настоятельно советую, прежде чем бросаться писать что-то своё — тщательно ознакомиться с существующими решениями.

А их на самом деле не так много. А о том, что я говорил просто не применяются, но это не значит что неприменимы.
Так версионность на уровне страницы, кроме места, требуют одного писателя и применение возможно там где изменяются можество последовательных записей . Пример многострочная часть документа, движения документа имеющие именно такую природу, где кюч имеет вид DocID,НомерСтроки итд. И достаточно прост в реализации
Да и при версионности на уровне записи индекса достаточно много конфликтных вариантов которые нужно обходить и реализация намного сложнее.
Кроме того, разговор был бы намного продуктивнее если бы мы изначально поняли друг друга, а всё изучить невозможно, в большинстве случаев это происходит по месту.
В общем на самом деле я остался доволен беседой

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

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

1.1.4 stable rev. 510

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

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

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

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

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Posted via RSDN NNTP Server 2.0

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

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

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

Posted via RSDN NNTP Server 2.0

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

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

В различных решениях по разному.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

1.1.4 stable rev. 510

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

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

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

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

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

1.1.4 stable rev. 510

всем привет!

как проходящий мимо, не прочел всю ветку — прошу прощения, если уже без меня о том высказались — я зацепил лишь 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?

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.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

V> RSDN — не клиент-сервер, а N-tier

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1088>>

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 786>>

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

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

Posted via RSDN NNTP Server 2.1 beta

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

	От:	Зверёк Харьковский
	Дата:	26.02.06 07:28
	Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	26.02.06 09:12
Оценка:	+1

	От:	Cyberax
	Дата:	26.02.06 10:43
	Оценка:	+1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	26.02.06 10:58
Оценка:	+1

	От:	Cyberax
	Дата:	26.02.06 11:10
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	26.02.06 14:07
Оценка:	+3

От:	Merle	http://rsdn.ru
Дата:	26.02.06 14:34
Оценка:

От:	VladD2	www.nemerle.org
Дата:	26.02.06 22:40
Оценка:	27 (2)

От:	IT	linq2db.com
Дата:	27.02.06 01:00
Оценка:	26 (1)

От:	c-smile	http://terrainformatica.com
Дата:	27.02.06 02:19
Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	27.02.06 05:13
Оценка:	+2

От:	Sinclair	https://github.com/evilguest/
Дата:	27.02.06 05:49
Оценка:

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	27.02.06 05:57
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	27.02.06 06:00
Оценка:

	От:	Павел Кузнецов
	Дата:	28.02.06 06:12
	Оценка:	13 (1)

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	28.02.06 07:23
Оценка:

	От:	Воронков Василий
	Дата:	28.02.06 22:58
	Оценка:

	От:	vdimas
	Дата:	07.03.06 08:59
	Оценка:	10 (1) +1

От:	Odi$$ey	http://malgarr.blogspot.com/
Дата:	07.03.06 11:21
Оценка:	+1

От:	Vladimir V Kochetkov	https://kochetkov.github.io
Дата:	07.03.06 21:01
Оценка:

От:	EXO	http://www.az.inural.ru
Дата:	09.03.06 05:06
Оценка:

От:	Valery A. Boronin	linkedin.com/in/boronin
Дата:	26.08.08 03:22
Оценка:	2 (1)

	От:	Дельгядо Филипп
	Дата:	27.08.08 22:02
	Оценка:	-1