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

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

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

Вообщем в тот самый один процент как раз укладываются ad-hoc запросы администратора для диагностики системы, а в остальном я бы от read uncommitted все-таки воздерживался..

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

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

Любое транзакционное чтетие если специально не указываетсмя no lock замедляет выборку. Если чтение происходит часто, то...

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

Ну, тебя. Там даже теоритически ничего случиться не может. Максимум сработает ограничение или тригер.

M>Вообщем в тот самый один процент как раз укладываются ad-hoc запросы администратора для диагностики системы, а в остальном я бы от read uncommitted все-таки воздерживался..

Если производительности хватает, то естественно. А если нет, то можно и соптимизировать. Ничего страшного в грязном чтение нет. Глвное чтобы данные были не критичны.

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

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

Ну, это от сервера зависит. Тот же Оракл позволяет несколько экземпляров сервера для одной БД запускать. Думаю, при этом вряд ли от блокировок файлов избавиться. Другим (более новым северам) это без надобности.

M>Да ну?!! И как мне осуществить блокировку на уровне записи с помощю MultiReadExclusive, причем Update Lock?

Создать по объекту для каждой записи.

M>РДБ — это не лобовой механизм, просто он позволяет избавится от такой кучи проблем, о которой ты даже и не подозреваешь..

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

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

M>>Да ну?!! И как мне осуществить блокировку на уровне записи с помощю MultiReadExclusive, причем Update Lock?
VD>Создать по объекту для каждой записи.
Update lock все раво не получится...

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

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

VD>Любое транзакционное чтетие если специально не указываетсмя no lock замедляет выборку. Если чтение происходит часто, то...
Стоимость наложения блокировки, по сравнению с самим чтением и прочей лабудой, которой приходится заниматься серверу при выборке, это другой порядок малости...
А вот последствия грязного чтения могут быть очень грустными.

VD>Если производительности хватает, то естественно. А если нет, то можно и соптимизировать. Ничего страшного в грязном чтение нет. Глвное чтобы данные были не критичны.
Вот-вот, сегодня они не критичны, а завтра...
В подавляющем большинстве случаев, если удается с помощю грязного чтения серьезно поднять производительность, то существует способ добиться того же эффекта не применяя приемы на грани фола.

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

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

S>> 1,2,3. За счет синхронизации MultiReadWriteExclusive. Некоторые БД вообще работают только на чтение, или запись очень редка итд.

VD>А. Ну-ну. Писать синхронизацию вручную... нет уж увольте.
Зато строить деревья транзакций правда за этим следит SQL нормально.
Меня просто интересуют временные затраты от блокировок. С MultiReadWriteExclusive все проблемы транзакций исчезают. Да и общее время на запись, во много раз меньше чем на чтение и в определенных системах имеют место на жизнь. Нужно просчитывать.

S>> А в том же M$ SQL грязное чтение нормальное явление.

VD>Что-то я ни разу не видел. Обысно рид-комитед все используют.
NoLock поверь очень часто. Значит не так быстр SQL.

S>> Транзакции только для отката с одновременным ведением журнала транзакций. Соответственно и надежность. NTFS уже имеет эту возможность.( правда до конца не разбирался)

VD>Гы-гы. И от чего же у меня реест на одной из мешин умер когда во время дефрагментации (утилитами ХаРэ) вырубилось питание? А вот с сиквел-сервером такого еще ни разу не видел. Там журнал. Максимум будет откачена последняя транзакция.
Согласен. Но кто ж мешает свой журнал вести????
S>>4. Система сама прекрасно кэширует файлы, когда хватает памяти по принципу мапфайлов + кэш раид массивов практически можно делать какой хочешь.

VD>Далеко не прекрасно. Иначе бы орлы из МС и напрягаться не стали бы. В сиквел-сервере кэширование свое, потому как прямой доступ к памяти значительно шустрее чем доступ к файловому кэшу.
А файл мэппинг это не прямой доступ к памяти ????? Там если мне не изменяет память запись страницами. У меня к тебе небольшая просьба.Сравни мап файлами с SQL не сложно на просчете какой нибудь таблицы. А то что чтение из кэша медленней это понятно но достигает 150 мб за 0,375 сек у меня хоть и память 400 но шина 266.


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

VD>Внутри сиквела все это используется, но от тебя вся эта низкоуровневая каша скрыта. И по мне так это замечательно.
В SQL можешь получить обычную группировка по составному индексу без всяких дополнительных включений по группировкам. Каждому свое.
S>>6. Без проблем. Обычно это Б-деревья с двухнаправленным списком для навигации (хотя можно и без них, но возникают проблемы при перестроении индекса при вставках и удалении). Причем без хранения индексного выражения в индексе а только с хранением ссылки на запись, для индексации любых данных.

VD>Вот и спрашивается нафига все это класть на свой гроб?
Объясню. Сейчас закупаем POS терминалы. Внутри DOS и DBase. Эта программа будет работать долгие годы, но специально заточить под нее свою иерархическую БД не составляет труда. Но при этом на штрих код или код можно легко использовать Хэш-Таблицу, на многострочную часть двухнаправленные списки, индекс только на чеки.
Не SQL же ставить, а скорость и надежность будет выше чем DBF.

S>>Да нет скорее из-за того что нет определенных наработок. И легче взять уже готовое, с неоходимыми переделками под себя.

VD>Можно взять и другие конструкторы или дорабатывать готовую системц. Но вот что-то в основном бирут именно 1С. Хотя возможно скоро будут брать Аксапту.
Акзапта очень дорога и за 200 кб. И берут ее очень мало. А если посчитать время внедрения 1,5 — 2 года то ....

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

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

S>> Но малобюджетные локальные РБД не представляют особой сложности. Но они нужны. Не всем же на Оракулах работать.

AVK>MSDE сделает твою малобюджетную РСУБД и по скорости и по надежности и по малобюджетности. Jet, которого особо малобюджетным не назовешь он делает как котенка.
Ну с Jet сравнивать не серьезно. А почему РСУБД??? Да же если РСУБД просто провести тест на чтение из Мап файла структурированных данных, это окажется медленнее чем MSDE??? Зачем тогда вообще программировать какие — то еще SortedList,B++ tree, HashTable, QuickSort придумывают (правда лет этак 40 назад). Надо сразу все данные программы хранить в MSDE???
Причем постраничное хранение данных не ведет к увеличению скорости, но зато позволяет следить за всеми произведенными изменениями в разных таблицах.
А база с ранним связыванием и иерахическим построением, и прямыми ссылками ну никак не может оказаться медленнее MSDE.
Несколько вопросов
1. Зачем использовать ключ, если можно хранить прямую ссылку (номер записи).
2. Зачем на многострочную часть (Подчиненные записи) создавать составной индекс, если на владельце можно хранить только ссылку на первую и последнюю запись, а подчиненные записи представлять ввиде двухнаправленных списков. Тоже касается и справочниками с группами. Любая иерархия может быть представлена в виде деревьев без каких либо индексов, или комбинированный подход ????
3. Почему в нормальном программировании все связи на прямых ссылках??? Чем эти связи отличаются в БД???

Сделать ООП надстройку над Такой БД несложно (впрочем как и с РБД) причем на стороне сервера и программирование при этом будет мало отличаться от обычного, нежели при SQL.
А выборки путем считывания в определенного размера массив с последующей обработкой очень быстрый. Если и есть разница то она скорее покроется вычислительными операциями, чем считыванием из кэша. И в чем будет измеряться эта разница???
Например для разбора по строкам откэшированного текстового файла 150 мб у меня уходит менее 2 сек. А считывание в буффер составляет 0.375 сек. Не замерял чтение блоками, но могу проверить.

При том что не нужна репликация.
Согласен, что нужно учитывать ссылочную целостность и в SQL это делается на раз, но для определенных задач это легко можно делать. Все зависит от задачи. И на это удет далеко не вся жизнь, а лишь малая толика.

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

S>> Файловые блокировки в локальных БД LockFile, LockFileEx. А каков механизм в SQL????
M>Дык яж говорю, в многопользовательской реляционной БД файл, как таковой не блокируется в принципе, тоесть в него может писать только один процесс, процесс самого сервера. А вот что, зачем, как и в каком порядке туда пишется — разруливает БД, что в конечном итоге оказывается на много эффективнее. Блокировки происходят не на уровне файла, а на уровне конкретной записи, страницы данных или таблицы.



S>> В итоге MultiReadExclusive будет намного экономичней будет.
M>Да ну?!! И как мне осуществить блокировку на уровне записи с помощю MultiReadExclusive, причем Update Lock?
А зачем, если кроме одного клиента писать и читать никто не может????

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

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

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

S>> Есть еще TSE, Цитрикс

VD>Это и есть замазывание идеологических дыр. Да и 300 терминал клиентов положат любую сеть и любой сервер. А у (на рсдн) нас на сервере 400 клиентов — это норма, а ведь мы ХТМЛ по сети гоняем...
Это быо ответ на http://www.rsdn.ru/Forum/Message.aspx?mid=404296&only=1

Автор: Merle
Дата: 08.10.03

.
Хотя технологии XWindow достаточно интересны. Никаких перносов данных. Гоняй только экраны.
теже майн фреймы. Ну а 400 клиентов это разве много для многопроцессорной машины. И транзакции вам особо не нужны. Закидывай в блобы, только темы индексируй.
Заранее извиняюсь за делитанство. Это лишь мое представление.

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


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

Отчасти да, отчасти неудачным опытом при сравнении с Interbase, а отчасти тем, что до недавнего времени у самого был 200 AMD, а в конторе 400 PIII. И приходилось из г. делать конфетку. То же касается и 1С но только в клиент серверном варианте через DCOM, когда нужно было делать отчеты по сети.
Перейдя на Athlon 2400+ все стало мгновенным. Может я во многом неправ, но мне кажется что крупица здравого смысла в моих рассуждениях есть.

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

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

Ошибаешся. Как раз именно блокировки могут остановить всю систему. Чтение же данных из кэша не такая уж ресурсоемкая операция.

M>А вот последствия грязного чтения могут быть очень грустными.

Не могут если данные не важны. Пример я уже приводил.

M>Вот-вот, сегодня они не критичны, а завтра...

И завтра. Справочники есть справочники.

M>В подавляющем большинстве случаев, если удается с помощю грязного чтения серьезно поднять производительность, то существует способ добиться того же эффекта не применяя приемы на грани фола.

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

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

S> Согласен. Но кто ж мешает свой журнал вести????

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

S> А файл мэппинг это не прямой доступ к памяти ?????

Прямой. Вот только он замедляем дисковые операции так как обращение идет по 4 килобайта. В МС-сиквиле используюется множество оптимизаций, как то чтение экстентами по нескольку страниц, использование страниц в 8 (а не 4 как в НТ) кил, планирование кэша... Все это можно конечно написать. Вот только там этим занимаются отдельные иследовательские команды. У тебя таких ресурсто попросту нет.

S> Там если мне не изменяет память запись страницами. У меня к тебе небольшая просьба.Сравни мап файлами с SQL не сложно на просчете какой нибудь таблицы. А то что чтение из кэша медленней это понятно но достигает 150 мб за 0,375 сек у меня хоть и память 400 но шина 266.

В общем, содай тест... сравним.

S> Объясню. Сейчас закупаем POS терминалы. Внутри DOS и DBase. Эта программа будет работать долгие годы, но специально заточить под нее свою иерархическую БД не составляет труда.

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

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

Куда ставить? На пос ты ничего не поставишь. Хэш-таблицы тебе тоже никто не запрещает применять. А данные можно хринить и в обычхы таблицах. В общем, сам выдумываешь трудности, сам же их и решашь.

S> Акзапта очень дорога и за 200 кб. И берут ее очень мало. А если посчитать время внедрения 1,5 — 2 года то ....

Что то? Ее купил МС рано или поздно они доведут цену до приемелом для массового потребителя (или сделают лайт-версию).

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

M>Update lock все раво не получится...

Эээ... Ты точно уверен что понимаешь, что такое MultiReadExclusive?

M>Ну чтож.. безумству храбрых поем мы песТню... Только что-то мне кажется это утопия...

Мне тоже.

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

VD>Эээ... Ты точно уверен что понимаешь, что такое MultiReadExclusive?
Уупс, промазал...
Но как бы это в любом случае, не фонтан.

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

M>>Да ну?!! И как мне осуществить блокировку на уровне записи с помощю MultiReadExclusive, причем Update Lock?
S> А зачем, если кроме одного клиента писать и читать никто не может????
Вот именно за тем, чтобы могли. Что увеличит степень параллелизма, а следовательно производительность при многопользовательской работе...

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

VD>Ошибаешся. Как раз именно блокировки могут остановить всю систему.
Только если они конфликтуют между собой или под них памяти не хватает. Во всех остальных случаях это действтельно другой порядок малости. Вылизан этот механизм просто до невозможного состояния.

VD>Все равно грязное чтение — это самый шустрый вариант. В общем, если применять эту возможность обдуманно, то ничего страшного нет.
Тут уж лучше переспать, чем недоесть..
Вообщем не думаю, что есть здачи, где грязое чтение единственный способ поднять производительность до приемлемого уровня. А раз что-то можно сделать более надежно, значит надо более надежно и делать.

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

M>Но как бы это в любом случае, не фонтан.

Естествнно. Это же поре кода. Вся стратегия блокировок в коде... жуть.

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

S> Ну с Jet сравнивать не серьезно.

Тогда с 1С тем более несерьезно.

S> А база с ранним связыванием и иерахическим построением, и прямыми ссылками ну никак не может оказаться медленнее MSDE.

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

S> 1. Зачем использовать ключ, если можно хранить прямую ссылку (номер записи).

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

S> 2. Зачем на многострочную часть (Подчиненные записи) создавать составной индекс,

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

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

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

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

Не думаю что это увеличит производительность.

S> 3. Почему в нормальном программировании все связи на прямых ссылках??? Чем эти связи отличаются в БД???

А подумать?

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

VD>>Далеко не прекрасно. Иначе бы орлы из МС и напрягаться не стали бы. В сиквел-сервере кэширование свое, потому как прямой доступ к памяти значительно шустрее чем доступ к файловому кэшу.
S> А файл мэппинг это не прямой доступ к памяти ????? Там если мне не изменяет память запись страницами. У меня к тебе небольшая просьба.Сравни мап файлами с SQL не сложно на просчете какой нибудь таблицы. А то что чтение из кэша медленней это понятно но достигает 150 мб за 0,375 сек у меня хоть и память 400 но шина 266.

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

[skip]

S>>> Ну MS SQL тоже падают не реже чем дбф. Восстановление тоже, что и дбф при повреждении журнала транзакций.
Ню-ню...

VD>>Ни разу не видел. Слышал один раз как раз в сочетании с 1С. И это был MSSQL 6.x.
S> А я не один раз так как иногда захожу на 1С форумы. Диски летят.

VD>>В отличии от ДБФ в сиквеле используются журналирование. ДБФ-у до этого очень далеко.
S> Ну акто запрещает сделать это самому???? При чем я не сторонник РБД а уж DBF тем более.
S>>> А почему бы и нет. Разный подход. Это отнюдь не велосипед ведь еще и Каша есть.

[skip]

S>>> В том числе. Но платформа V7 объективно была нужна.
В итоге имеем громадное число ламеров по стране "автоматизирующих деятельность предприятия".

VD>>Не платформа V7, а некий конструктор с пребилднутыми конфигурациями.
S> И псевдо ОО подходом. Далеким от настоящего, но. В итоге в 8 ке пришли к прямым запросам.
S>>>Но время идет а воз и ныне там (V8 улучшенная версия не более).

[skip]

S> Но ДБФ+TSE обгоняют SQL версию.
Еще раз: "версия 1С ДБФ + сервер терминалов обгоняет версию 1С для SQL". Какие можно сделать из этого выводы?
Читаем в блокноте словарь данных 1Cv77.dd версии для SQL — "так... повсюду наблюдаем хинты tablockx..."
Во вторых следует представлять масштабируемость решения на 1С в любом исполнении: ДБФ или SQL — она никакая, объяснять думаю не нужно. Я уже не говорю (хотя наоборот говорю) про другие замечательные особенности 1С:

Версия ДБФ: "так тут один из клиентов абнормально завершился: все клиенты выходим, один из клиентов заходит монопольно, переиндексирует ВСЕ индексы в базе, выходит, все можно работать остальным".

Версия SQL: "так мы тут новый релиз свежий от 1С установили: что такое — перестали работать некоторые отчеты, а некоторые дают другие результаты — ничего в следующем релизе это наверное будет исправлено." И так периодически через три на раз.

Версии SQL, ДБФ:
"так сегодня начало месяца — никто документы проводить не может, пользователь входит монопольно (для SQL тоже!) — пересчет оперативных итогов" — это типа кэширования агрегатных данных по регистрам.

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

ну а про "язык запросов 1С" я уже ничего не буду говорить лень писать.

Ну так за что мы еще любим 1С? Любовь зла...