Здравствуйте, 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 оно не проиграет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Зверёк Харьковский,
> Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные. Мое чувство прекрасного почему-то подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле". <...> Очень ли это глупо?
Нет, более того, более-менее так устроена "база" сообщений новой, девятой, Оперы. Можешь поставить, и поковырять в готовом виде, если интересно. Там же, в форуме активно обсуждаются особенности данной системы хранения почты.
Основные плюсы:
система заведомо более устойчива к разнообразным нарушениям целостности данных
в частности, антивирусы будут "сносить" отдельные сообщения, а не всю базу
для обработки могут использоваться сторонние утилиты
в частности, desktop search systems будут корректно работать out of the box, безо всякой "умной" с ними интеграции
и т.п.
Основные минусы:
"жрет" больше дискового пространства (кластеры-шмастеры, чтоб им...)
медленнее обрабатывается (например, backup)
и т.п.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не собираясь участвовать в дискуссии по существу (все уже сказали, что стоит), хочу лишь одно отметить — ИМХО высказанные мнения вполне подтверждают правильность идеи MS об интеграции FS и DB.
PD>Один только вопрос — что из этой интеграции получится ? Будем надеяться, что не гибрид ужа с ежом.
Уже именно это и получилось. Они же за основу взяли реляционку. А хотелось бы некое более объектное хранилище.
Здравствуйте, kan_izh, Вы писали:
_>Serginio1 wrote:
>> Q>Там используется стандартная схема с Б-деревьями и хешем по имени. Это >> означает, что время поиска есть логарифм (причем с большим основанием) >> от числа файлов. 1.000.000 файлов в этом случае — это всего-то 5-6 >> чтений блока с диска в худшем случае. Только совсем уж древние ФС не >> используют эту схему, а используют линейный поиск. >> А по маске типа с ведущим * ??? _>А что? СУБД будет себя лучше вести? _>Говорилось же об обращении по точному имени. В FAT поиск линейный будет в любом случае, в отличие от.
Я не о СУБД. При определенном хранении поиск по маске будет незаметенн в отличие от.
и определяется только скоростью поточного чтения с диска
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, IT, Вы писали:
IT>>>Все известные мне почтовые клиенты используют в качестве хранилища базы собственного формата. Т.е. не стандартные БД, а что-то своё, оптимизированное под задачу.
ЗХ>>Ммммм...
ЗХ>>А так
? Ну и вот так еще, до кучи.
IT>Ну так и я о том же. Свой формат хранения, один или несколько файлов. Можно как The Bat! иметь пару файлов на каждую папку, файлы с сообщениями и индексами.
Я, собственно, этими ссылками пытался показать, что в *nix-овом окружении, во-первых, форматы стандартны (т.е. не каждый клиент свой формат выдумывает, а есть 2-3 стандарта, а все клиенты их используют); а во-вторых, наиболее распространенный формат — Maildir, который как раз 1 сообщение/файл.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>> А хотелось бы некое более объектное хранилище. M>В лес объектные хранилища.
Ну это "Каждому Своё". Опять же как эти объекты интерпритировать. Долой плоское представление, даешь объектное отображение
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Нет, более того, более-менее так устроена "база" сообщений новой, девятой, Оперы.
А Омеа наоборот... Индексы отдельно, вся база в нескольких файлах, работает довольно шусто и стабильно.
ПК> система заведомо более устойчива к разнообразным нарушениям целостности данных
Вот это непонятно. Как раз тут основные пролемы:
— Запись не атомарна, можно добавить метаданные, а запись конкретного файла с сообщением по каким-то причинам не пройдет.
— Конкретное сообщение грохнется, а метаданные останутся.
Так что с целостностью очевидные проблемы...
Здравствуйте, Merle, Вы писали:
ANS>> А хотелось бы некое более объектное хранилище. M>В лес объектные хранилища.
В лес должно уйти наследие 30-летней давности под названием файл, и любые попытки скрестить реляционку с файлами.
О, а что там про Ораклиную InternetFS слышно?
eao197 wrote: > Это справедливо только для одной операции -- открытия файла по точно > известному имени. Но ведь это не единственная операция. Файлы создаются > и удаляются. Причем создаваться и удаляться они могут пачками. А > модификация большого индекса (даже в случае с B+ деревьями) может быть > не такой уж и дешовой операцией. Особенно при некоторых стечениях > обстоятельств (например, если имена файлов будут образовывать монотонно > возрастающию ключи).
Именно для этого в Reiser4 придумали специальную модификацию алгоритма с
B-деревьями — они назвали его "Dancing Trees". По описанию он
откладывает баллансировку дерева до момента когда это необходимо.
По benchmark'ам у них на сайте — вроде совсем неплохо получилось
(массовое создание/удаление у них как раз там есть).
Merle wrote: > # ПК> система заведомо более устойчива к разнообразным нарушениям > целостности данных > Вот это непонятно. Как раз тут основные пролемы: > — Запись не атомарна, можно добавить метаданные, а запись конкретного > файла с сообщением по каким-то причинам не пройдет. > — Конкретное сообщение грохнется, а метаданные останутся. > Так что с целостностью очевидные проблемы...
Вы все еще считаете, что все файловые системы заканчиваются FAT и NTFS?
Давным-давно есть атомарные FS с гарантированой целостностью, а в
Reiser4 атомарность умудрились сделать еще и без потери скорости.
Здравствуйте, eao197, Вы писали:
E>На самом деле при правильном приготовлении очень даже ничего штучка.
Я просто к тому, что совершенно непонятны страдания Andrei N.Sobchuck по этому поводу..
Очевидно, что объектный API там будет, а что там внизу лежит — дело десятое.
Вот, кстати, по поводу "А они за основу взяли реляционку " мой любимый пример. В 2005м сиквеле ребята решили реализовать поддержку XML и XQuery. Запарились они в серьез, структура иерархическая (к слову, как и объекты) значит, наверное, хранить их надо как-то по другому? Они угрохали несколько лет на исследования как же лучше с этим делом работать, R-tree, Quadtree и прочая экзотика рассматривалась со всей тщательностью... В итоге угадайте к чему они пришли? Правильно, xml преобразуется в реляционную таблицу с помощю Ordpath (что-то вроде Nested sets, но не обладающее фатальным недостатком), индексируется B+ Tree и запросы по этому делу гоняет реляционный движек.. Так оказалось лучше всего, и это при том, что Storage Engine-ам современных БД абсолютно пофигу что хранить, им не важно реляционные данныые там или нет.
Здравствуйте, Cyberax, Вы писали:
C>Вы все еще считаете, что все файловые системы заканчиваются FAT и NTFS?
Вы уже считаете, что с NTFS никто не работает?
И вообще, Вы все еще не научились читать сообщения полностью? Здесь никакая, даже самая замечательная ФС не спасет. Принципиально предполагается запись в два разных источника данных и надо как-то согласовывать их между собой. И каким бы замечательным один источник данных не был, e. g. зашибенская ФС, которая умеет кофе по утрам готовить, все равно есть вероятность, что другий источник в тапочки написает.
C>Давным-давно есть атомарные FS с гарантированой целостностью, а в C>Reiser4 атомарность умудрились сделать еще и без потери скорости.
Еще раз. Эти замечательные FS скопируют мне атомарно два разных файла? Они обеспечат мне атомарность записи и в файл, и в БД? И все конфликты при этой записи разрулят?
Чудес не бывает. Даже между двумя БД грамотно разрулить распределенную транзакцию — проблема, а тут транзакцию между БД и ФС, а у ФС заведомо меньше информации о структуре данных.
Здравствуйте, Cyberax, Вы писали:
C>Давным-давно есть атомарные FS с гарантированой целостностью, а в C>Reiser4 атомарность умудрились сделать еще и без потери скорости.
Кстати, ты можешь показать в описании Reiser4, где говорится, что Reiser4 поддерживает атомарность для нескольких изменений нескольких файлов сразу (т.е. чтобы изменение нескольких файлов составляло одну транзакцию)?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Это справедливо только для одной операции -- открытия файла по точно известному имени. Но ведь это не единственная операция. Файлы создаются и удаляются. Причем создаваться и удаляться они могут пачками. А модификация большого индекса (даже в случае с B+ деревьями) может быть не такой уж и дешовой операцией. Особенно при некоторых стечениях обстоятельств (например, если имена файлов будут образовывать монотонно возрастающию ключи).
Это почему???
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
E>>Это справедливо только для одной операции -- открытия файла по точно известному имени. Но ведь это не единственная операция. Файлы создаются и удаляются. Причем создаваться и удаляться они могут пачками. А модификация большого индекса (даже в случае с B+ деревьями) может быть не такой уж и дешовой операцией. Особенно при некоторых стечениях обстоятельств (например, если имена файлов будут образовывать монотонно возрастающию ключи).
S>Это почему???
Что именно "почему"?
Частые ребалансировки B+ дерева, имхо, это не дешевая операция (расчепления и объединения страниц).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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) на добавление и удаление.
подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле". <...> Очень ли это глупо?
Мы уже победили, просто это еще не так заметно...
