Здравствуйте, vdimas, Вы писали:
V> А если рассматривать содержимое файла как единую "строку данных", где имя файла является ключем, то ФС замечательно предоставляет все то богатство возможностей, о которых ты упомянул.
Так как она предоставит мне возможность записи двух "строк данных" в одной ACID транзакции, и разрулит мне при этом возможные конфликты при записи этих двух "строк данных" из параллельных потоков?
V> Например, если мы храним документы, то ФС очень даже себя оправдывает, ибо используется в последнем качестве.
Только в том случае, если мы можем без проблем пожертвовать парой документов в любой момент, да и то...
V>Если надо прикрутить развитый документооборот, то БД может хранить всякие доп. признаки и связь документов с другими объектами БД, а сам файл может спокойно себе лежать в ФС.
Я уже в этом топике объяснял проблемы такого решения. В этом случае нам необходимо писать в два принципиально разных источника данных, БД и файл. На данном этапе развития научно-технического прогресса проблематично организовать распределенную транзакцию даже между двумя БД, которые знают друг о друге, а ты предлагаешь сделать то же самое с ФС, которая о БД ничего не знает.
Как БД узнает, что файл на самом деле поврежден? Кто будет бакапить файлы и обеспечивать их согласованность с БД при восстановлении? Что делать с файлом, если навернется транзакция в БД при записи информации об этом файле?
V> Причем, ФС можно настроить так, чтобы избежать несанкционированного доступа вне рассматриваемой системы путем раздачи всяких прав.
А что делать с правами в БД? Ты предлагаешь ввести две системы авторизации? Тоже отличная идея..
V>Более того, потери базы, как видно из форумов, случаются пока гораздо чаще, чем потери файлов.
Это я даже комментировтаь не буду...
V>Более того, файлы зачастую можно хоть как-то восстановить, а БД — только из резервной копии.
Классно. У БД есть хотя бы резервная копия (хотя частенько удается обойтись и без нее), и стандартные процедуры по восстановлению. А что есть у файла? Откуда он возьмется, если его грохнули по ошибке?
V> А в случае документооборота требования к надежности способа хранения содержимого документов гораздо более высоки, чем требования к надежности хранения связей/аттрибутов.
Помоему ты довольно плохо себе представляешь требования к надежности современных БД и их возможности по обеспечению оной надежности..
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 метра? В общем, это такая жопа, по сравнению с которой стандартная дефрагментация диска выглядит наивной забавой (и к тому же может вестись в фоновом режиме).
Здравствуйте, 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 всех мастей (на разных фирмах, за которыми наблюдал)?
Блин, периодически обязательно кто-нибудь найдется на форумах указать мне на "надежность" этой СУБД, хотя я на восстановлении данных для нее собаку съел. А по какой причине, интересно?
Здравствуйте, 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
Так что есть еще куда стремиться. Поэтому не выпускаю следующей стабильной версии, а пока держу в бетах, т.к. думаю, что физическую организацию хранилища еще можно усовершенствовать. Тогда можно будет продолжить разговор про производительность.
Пока же повышать производительность не устал
Только времени на это нет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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>Блин, периодически обязательно кто-нибудь найдется на форумах указать мне на "надежность" этой СУБД, хотя я на восстановлении данных для нее собаку съел. А по какой причине, интересно?
Может не тех собак ел? Или на форумах просто умеют этих собак готовить? Тем более, как ты сам пишешь, на форумах ты один поешь о ненадежности БД, может в консерватории что? Не надо переносить свой негативный опыт на всю индустрию. Я понятия не имею почему тебе так не повезло, но твой уникальный опыт является большим исключением из общего правила.
Здравствуйте, vdimas, Вы писали:
V>Ну как тебе сказать... Мне приходилось терять базы на MS Access (чаще всего), несколько раз на MS SQL (реже) и один раз даже оракловую. (Понятное дело, что всегда были копии, но для операционного дня одной из фирм, где я работал, вчерашняя копия — это безнадежно старая копия...)
Ну Аксес не база, а вот что касается сиквела и оракла... почему вы не делали регулярных дифов и бакапов логов в течении дня, если бакап за сутки безнадежно стар? вы делали бакап лога после падения базы? если делали, что почему не накатили на восстановленную БД?
V>И вот в чем основная жопа, так это в случае, если потеряли базу — то потеряли вообще все.
Я повторюсь, но чтобы потерять базу надо очень постараться.
V>Только, плиз, не надо меня просвящать насчет журналов транзакций (коих могут быть даже 2 очереди у Sybase), и прочей хренотени.
Именно это мы тебе и будем рассказывать. И про журналы и про то что их можно (и нужно) выносить на разные диски, и про то что их нужно бакапить и про прочую хренотень. Потому что именно это и обеспечивает надежность и вот именно этого от ФС ты будешь ручками добиваться очень долго, а получится все равно хуже.
V> На моей памяти за 5 лет базы "высоконадежного" MS SQL грохались чаще, чем раз в год (по моим наблюдениям за 3-мя фирмами оптово-розничной торговли).
Будем памятью меряться?
V>Например, если документ Word неожиданно навернулся (это обычно происходит в момент записи и неожиданного сбоя аппаратуры в этот момент), то у нас в распоряжении есть временный теневой файл на диске, который создает сам Word, и который обычно содержит информацию, очень близкую к оригиналу.
В твоей системе этот документ всегда открывается прямо на сервере? И при копировании грохнуться не может? Все файлы независимы друг от друга?
V>- файлы на диске можно хранить не под своим оригинальным именем, а под составным. В начале имени идет некий префикс, в котором зашифрована версия документа, например: $12$ПамяткаТорговымПредставителям.DOC V>- файл отсылается юзверю целиком, после возврата — целиком сохраняется, но, ессно, уже под другим именем c обновленной версией. После успешного сохранения в базу заносится референс на новую версию файла и контрольная сумма по нему.
Как узнать, что файл сохранился успешно? Что делать если сохранился неуспешно? Что делать если два файла связаны между собой и должны быть одной версии? Что делать, если два файла связаны и один сохранился успешно, а другой нет? Что делать если в БД по каким-то причинам не прошла транзакция с метаинформацией о записаном документе? Что делать, если упала вся БД (она ведь у нас теперь падает)?
V>- для важных документов создаются копии в репозитории-зеркале. Обычно это как минимум другой винчестер (но лучше — другой хост). V>- регулярно в фоновом режиме производится сканирование и проверка контрольных сумм файлов в хранилище (хранилищах). В случае наличия правильного файла в одном из зеркал, все восстанавливается. Если нет, то в базу заносится соотв. запись и посылаются оповещения админам.
То есть пишем еще ручную систему зеркалирования?
V>ИМХО, простейшими ср-вами достигается надежность, гораздо выше, чем надежность СУБД.
Это вряд ли..
V>Ибо для СУБД, повторюсь, аналогичная надежность достигается в случае, если вероятность сбоя = P_fs / K, где P_fs — вероятность сбоя файловой системы, K — кол-во документов в системе.
Неверно. Во-первых надежность твоей системы будет всегда хуже БД, потому что она зависит и от надежности БД и от надежности каждого из файлов, а во-вторых, ты не учел еще надежность написанной в ручную системы восстановления, и вообще всей системы, и вероятность отсутствия в ней ошибок.
Иными словами, ты предлагаешь написать свою собственную БД, со своей же системой журналирования и отказоустойчивости. Не проще ли грамотно настроить готовую? Уверяю, результат окажется не хуже.
V>И еще. Вы пробовали когда-нибудь сжимать (shrink) многогигабайтные (десятки гиг) файлы данных MS SQL?
А зачем их сжимать?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Вернее Двухнаправленный Список (В пику Sinclair про однонаправленные итераторы) M>Элементы, как правило, все-таки в направленый, но это уже вопрос реализации...
S>>Не за каждой записью, а при переходах между страницами. M>Опять-таки вопрос реализации. На практике обычно связывают и страницы и элементы, связь между элементами позволяет во-первых, не соблюдать физический порядок элементов при хранении, а во-вторых, реализовать предикатные блокировки, о чем я говорил выше.
Реализация всех элеменах в листевых страницах несколько проще, быстрее итд.
S>> Но при этом ненужно хранить состояние, если оно меняется то при переходах нужно его востанавливать. M>Состояние чего? Тут я не успеваю за полетом твоей мысли...
Состояние в дереве. То бишь всю иерархию от корня, при проходе только по листовым страницам это ненужно S>>Хотя версионность и здесь поможет M>Версионность-то здесь причем? Это уже совсем из другой оперы.
Не скажи. Опера то одна и таже а реализации несколько различные. Перестройка индексов при блокировочнике более значимая проблема, чем при версионнике, так как может затрагивать множество страниц. Хотя для однопоточного использования монописуально.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
ANS>>Пойдём по шагам. Начнём с простейшего: пример хранения графа с циклами при помощи ordpath. M>Потребую от графа умения сериализоваться и десериализоваться в xml, сведя тем самым задачу к известной.
И пример XPath запроса который вытащит мне объекты у которых obj.next.name="ta-ta-ta"?
ANS>>Попробовали б они не сделать, когда маркетологи говорят "надо". M>Уж посылать в лес маркетологов они умеют изумительно.
Здравствуйте, Serginio1, Вы писали:
S>Реализация всех элеменах в листевых страницах несколько проще, быстрее итд.
Реализация чего? Я тебя вообще перестаю понимать...
S> Состояние в дереве. То бишь всю иерархию от корня, при проходе только по листовым страницам это ненужно
Какую иерархию от корня? Состояние чего в дереве?
S> Не скажи.
Скажу.
S> Опера то одна и таже а реализации несколько различные.
Реализации чего? Прохода по дереву? Его модификации?
S> Перестройка индексов при блокировочнике более значимая проблема, чем при версионнике, так как может затрагивать множество страниц.
Ты удивишся, но и блокировочники и версионники работают с деревом примерно одинаково. По крайней мере в вопросах стандартной работы — поиска, вставки, удаления, изменения ключа. Для дефрагментации и полного перестроения индекса — таки да, можно использовать версионность для проведения этих мероприятий в on-line, но это уже другая история.
Не, ты не понял. Ты придумал граф объектов, ты его и сериализуй. Вот когда сериализуешь, тогда БД его и сохранит.
ANS>И пример XPath запроса который вытащит мне объекты у которых obj.next.name="ta-ta-ta"?
Прежде чем на реляционки наезжать, покажи мне объектную БД, которая так умеет.. При условии, что Name вообще может быть виртуальный метод.
ANS>Типа "Ну не шмогла я, не шмогла"?
Нет, "Вы наобещали, вы и делайте"
" — вот и продемонстрируй.
ANS>>И пример XPath запроса который вытащит мне объекты у которых obj.next.name="ta-ta-ta"? M>Прежде чем на реляционки наезжать, покажи мне объектную БД, которая так умеет.. При условии, что Name вообще может быть виртуальный метод.
Не, ты не понял. Ты сказал, что реляционка для хранения объектов это "самое то" на основании, то что в неё можно легко XML запихнуть и запросы по нему летать будут. Я сомневаюсь в подобном обобщении. Что касается виртуальных методов, то давай пока без них (хотя GemStone/S это могёт). Подобный запрос, кстати, можно сделать на ORM.
И было бы интересно увидеть как это выглядит на WinFS.
ANS>>Типа "Ну не шмогла я, не шмогла"? M>Нет, "Вы наобещали, вы и делайте"
Вот и у меня такая мысль появилась, что WinFS занимаются исключительно маркетологи.
" — вот и продемонстрируй.
Читай внимательно, я сказал "без проблем если сериализуется". Ты придумал, ты и сериализуй..
ANS>Не, ты не понял.
Я ли?
ANS> Ты сказал, что реляционка для хранения объектов это "самое то" на основании, то что в неё можно легко XML запихнуть и запросы по нему летать будут. ANS>Я сомневаюсь в подобном обобщении.
Твое право
ANS> Что касается виртуальных методов, то давай пока без них (хотя GemStone/S это могёт).
С GS и прочими Jasmin-ами свои тараканы...
А про виртуальные методы — это я к тому, что критикуя — предлагай. Реляционные системы есть, и неплохо справляются со своей работой на очень широком классе задач. ООБД на данный момент — удел энтузиастов и очень узкого класса приложений.
То, что они положили в основу реляционку означает, что у этой системы в принципе есть шанс увидеть свет, там хотя бы движек рабочий.
А как бы это выглядело будь она целиком объектной? Я уже не в первый раз пытаюсь тебя спросить...
ANS>Подобный запрос, кстати, можно сделать на ORM.
Можно, как раз с этим никто не спорит. И опять-таки, чем не вариант?
ANS>И было бы интересно увидеть как это выглядит на WinFS.
Мне самому интересно. Но как я уже говорил, мне хватило бы, если бы там просто был доступен обычный SQL. И похоже все идет к тому, что там будет DLinq, по крайней мере это было бы очень логично...
Здравствуйте, Merle, Вы писали:
M>Вот, кстати, по поводу "А они за основу взяли реляционку " мой любимый пример. В 2005м сиквеле ребята решили реализовать поддержку XML и XQuery. Запарились они в серьез, структура иерархическая (к слову, как и объекты) значит, наверное, хранить их надо как-то по другому? Они угрохали несколько лет на исследования как же лучше с этим делом работать, R-tree, Quadtree и прочая экзотика рассматривалась со всей тщательностью... В итоге угадайте к чему они пришли? Правильно, xml преобразуется в реляционную таблицу с помощю Ordpath (что-то вроде Nested sets, но не обладающее фатальным недостатком), индексируется B+ Tree и запросы по этому делу гоняет реляционный движек.. Так оказалось лучше всего, и это при том, что Storage Engine-ам современных БД абсолютно пофигу что хранить, им не важно реляционные данныые там или нет.
Ну-ну. И ты готов реализовать OrdPath на реляционном 2000 ом?
Классификатор OrdPath весьма интересен, но она не реляционен. Для него все равно нужен был свой механизм и своя интерпретация.
Здравствуйте, GlebZ, Вы писали:
GZ>Ну-ну. И ты готов реализовать OrdPath на реляционном 2000 ом?
А зачем? Но если надо, то Nested Sets, который очень здорово напоминает OrdPath, известен уже очень давно и для иерархий его реализовывали еще на 4.3, если не раньше, так что не проблема.
Можешь Келко на досуге перечитать..
GZ>Классификатор OrdPath весьма интересен, но она не реляционен.
Да ну? Сам по себе нет, но результат его работы — более чем.
GZ> Для него все равно нужен был свой механизм и своя интерпретация.
Естественно нужна, но уже поверх реляционки. После того, как преобразовали иерархию с помощю OrdPath — это реляционка в чистом виде.
Здравствуйте, Merle, Вы писали:
GZ>>Ну-ну. И ты готов реализовать OrdPath на реляционном 2000 ом? M>А зачем? Но если надо, то Nested Sets, который очень здорово напоминает OrdPath, известен уже очень давно и для иерархий его реализовывали еще на 4.3, если не раньше, так что не проблема.
Ничего общего между OrdPath и Nested Set. OrdPath — это классификатор, один из подвидов Dewey. Та же линейная скорость вставки и удаления, возможность сортировки иерархии, но с сохранением порядка последовательности, и с возможностью ссылки на различные домены. Второе — не очень реляционно. Первое — я бы не сказал, но сильно влияет на функционирование оптимизатора запросов. Oracle не зря вычленил сортировку из вложенных запросов. Microsоft частично тоже. M>Можешь Келко на досуге перечитать..
С удовольствием. Только не знаю что это. Че за книженция?
GZ>> Для него все равно нужен был свой механизм и своя интерпретация. M>Естественно нужна, но уже поверх реляционки. После того, как преобразовали иерархию с помощю OrdPath — это реляционка в чистом виде.
Ну не в чистом виде. Каждую запись OrdPath, а это набор битов, все таки надо обрабатывать по особому.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Господа, не флейма ради совершенно!
Не флейма ради.
Во первых, то что ты уже намекнул. Файловое хранилище также является базой данных и операционная система выполняет функции системы управления базой данных. Разница в реализациях хранения.
Реляционное хранение это строгоструктурированная система хранения данных. Это готовая универсальная модель данных в которой можно хранить все. Единственное ограничение — ты должен хранить данные в строгоструктурированном реляционном виде. И тут есть и плюсы и минусы. Начну с плюсов.
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 Основная проблема в структурированности данных.
Здравствуйте, 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. В терминах чистой реляционной алгебры будет сложновато.
Мы уже победили, просто это еще не так заметно...
можно пример современной надежной СУБД? А то может я просто "не правильным" MS SQL 2000 несколько лет пользусь (а до этого 7-кой несколько лет). А ты помнишь, кстати, что случалось с журналами транзакций на подвисших транзакциях в 7-ке? Особенно когда в базе активно изменялись блобы по нескольку мег? (в 2000-м с этим полегче, но тоже иногда случалось) 
