Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7   вперед  Ctrl      все
 Re: В защиту файл-сервера  [new]
Я и ёжик
Guest
>>>А ссылки нет и быть не может, так же, как про алгоритмы оптимизатора
>>>запросов MSSQL. Эти вещи создателей кормят :-)
Ну если не алгоритмы оптимизатора, то уж методы доступа к данным которыми будет реализован запрос в документации к Oracle например описаны, да и способы помочь оптимизатору встать на путь истинный тоже, думаю с MSSQL ситуация таже. Да собственно и более интимные подробности работы оптимизатора не скрываются, см. например "Cost Control: Inside the Oracle Optimizer" |> (регистрация на OTN свободная).

>>> Я имел в виду запросы вида SELECT * FROM tt WHERE Field=...
>>>т.е. с некоторым условием выборки, по полям этих условий обычно и идет
>>>оптимизация. И вполне возможно, что при размере записи менее скольки-
>>>то, берется вся запись целиком.

Имеется ввиду, что Field в нашем случае не индексировано?
13 ноя 03, 16:20    [416987]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я и ёжик
Guest
Чего то у меня со ссылуой не получилось в вот такая УРЛа: http://otn.oracle.com/oramag/webcolumns/2003/techarticles/burleson_cbo_pt1.html
13 ноя 03, 16:23    [417000]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
Ест-стно, Field - просто поле.
13 ноя 03, 18:34    [417335]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
Посмотрел статью.
Нет уж, то, что приведено, на алгоритм работы оптимизатора не тянет. Это скорее, можно сравнить с описанием оптимизации Рашмора. А Вы просите, фактически, чтобы Вам документировали: при каких значениях конкретных статистик и других факторов какое решение оптимизатором принимается. Это ноу-хау... о нем только догадываться можно.
14 ноя 03, 12:51    [418312]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я и ёжик
Guest
>>>Это скорее, можно сравнить с описанием оптимизации Рашмора.
Ну вот оптимизация же Рашмора описывается, и описывается, что надо
делать/неделать что бы она применялась, в очень правильном разделе оптимизация доступа к таблицам и индексам (MSDN VFP), а вот
"выкусвания полей" почему то не описывается, странно, а ведь в специфических случаях это может дать офигитильное преимущество...
как то нелогично скрывать свои достоинство в условиях рынка и конкуренции.

>>> при каких значениях конкретных статистик и других факторов какое
>>> решение оптимизатором принимается.
Ну тогда хотя бы информацию о том что статистика все таки собирается должна же быть, поскольку без статистики , в частносте о частоте искомого
значения в поле, не принять правильного решения когда вищипывать значение поля а когда сразу тянуть таблицу. Чего то не помнится что бы в Fox 2.6 какая либо статистика собиралась , да и до VFP 5 то же, позже не знаю.
А без такой статистики правильного решения не принять, не думаю что
разработчикам fox-а вбабахали бы технология которая в большинстве случаев только портила бы показатели, все таки неплохой продукт был.

Кстати ваш вариант эксперемента поставил и получил результаты не соответствующие вашим утверждениям, т.е. разница во времени выполнения офигенная, что говорит о том что все таки , даже если вдруг технология "выкусывания" (по недорозумению) и использовалась в Fox 2.6, то к VFP 5 ее уже убрали, и правильно сделали надо сказать.
14 ноя 03, 14:23    [418581]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
Поскольку Вы меня сильно заинтриговали, я все же попробовал поставить эксперимент, о котором говорил. Увы, Я БЫЛ НЕ ПРАВ, идет действительно полная перекачка файла на станцию, "выкусывания" поля никакого нет !
Не знаю уж, почему я много лет назад истолковал по-своему результаты тестов, но ведь действительно - разница при разном размере большая.
Приношу извинения за введение в заблуждение !
Вывод - пора уж все-таки на SQL переходить :-)
14 ноя 03, 17:47    [419230]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я и ёжик
Guest
Ничего, бывает, зато мило побеседовали (ёжик опять же много чего понял).
Успехов!
14 ноя 03, 18:08    [419261]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Кхе - кхе....:)

Ну а как можно было думать иначе? Когда речь идет о файл-сервере, то изначально подразумевается, что на клиента предается именно файл. ФС ничего другого не умеет, кроме как передавать файл. И для того, что бы обновить один байт он перекинет весь файл. Ну может это это как-то оптимизировано, наверное он блоками передает и обновляет, но это разбиение на блоки к строению файла и к его содержимому никакого отношения не имеет, потому что ФС не знает как устроены передавемые файлы. Конечно индексы могут здесь децл помочь, но не во всех случаях. Например если нужно обновить одну запись, то туда-сюда передасться не меньше блока, где эта запись храниться, размером с файловый буфер ОС (1-8кб) - и слава богу, индекс сыграл. Но если нужно 1000 таких записей, то вероятно, что буфер придется обновлять 1000 раз. А если мы посылаем запрос на суммирование по всей таблице? Мы ее целиком перегоним на клиента, при том, что нам нужно всего одна цифра.

Конечно можно и тесты устраивать, но ежели представлять себе эту механику (не надо знать в тонкостях, но хотя бы в общих деталях), то даже мысли такие (типа "выкусывает поле") попросту не возникнут. Но это общая картина - к сожалению все меньше людей ее представляют( кстати, ИМХО, поэтому и начинают прокатывать всякие рекламные штучки типа "наша СУБД работает в 100 раз быстрее делаая при этом тоже самое" - ну не бывает такого:)
14 ноя 03, 18:40    [419326]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я и ёжик
Guest
2 U-gene
>>> Ну а как можно было думать иначе? Когда речь идет о файл-сервере,
>>>то изначально подразумевается, что на клиента предается именно файл.
>>>ФС ничего другого не умеет, кроме как передавать файл. И для того, что
>>>бы обновить один байт он перекинет весь файл.
Да легко можно так думать, достаточно хотя бы поверхностно знать основы построения операционных систем и файловых сервисов (ёжик кивает).
Прочитайте для начала цитату ниже. Вы почему то считаете, что файловые сервисы работают по модели загрузки-выгрузки, в то время как все широко используемые сейчас работают как раз по второй модели, т.е. по модели удаленного доступа (И кстати совершенно непонятно, где вы умудрились столкнуться с первой? Поделитесь печальным опытом).
писал:
"Сетевые операционные системы" Н. А. Олифер, В. Г. Олифер, Центр Информационных Технологий. "Распределенные файловые системы"
Файловый сервис может быть разделен на два типа в зависимости от того, поддерживает ли он модель загрузки-выгрузки или модель удаленного доступа. В модели загрузки-выгрузки пользователю предлагаются средства чтения или записи файла целиком. Эта модель предполагает следующую схему обработки файла: чтение файла с сервера на машину клиента, обработка файла на машине клиента и запись обновленного файла на сервер. Преимуществом этой модели является ее концептуальная простота. Кроме того, передача файла целиком очень эффективна. Главным недостатком этой модели являются высокие требования к дискам клиентов. Кроме того, неэффективно перемещать весь файл, если нужна его маленькая часть.

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


>>>Но это общая картина - к сожалению все меньше людей ее представляют
Вы даже не знаете насколько тут правы... ;))

Да, дабы не вызывать лишнего флейма: не надо меня убеждать, что клиент-серверная технология для построения баз данных в большинстве случаев лучше, я это и без Вас знаю. Мы с ёжиком просто выступаем против безграмотных нападков на файл-серверную архитектуру, нападайте, но грамотно, а то конфузно както становиться...
К тому же понятие "лучше" очень растяжимо и кроме чисто технологических
вполне могут присутствовать "финансовые","временные", "человеческие" и прочие факторы которые все могут повернуть в другую сторону.
Всем успехов! И это... не кашляйте ;)
14 ноя 03, 19:53    [419433]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
Типа, достали. Устроил я у ся на работе тпц.орг для фокспры ?6.

Для других файл-серверных СУБД (Аксес, Парадокс, Эпроч, ДБейс и ещё
какие-нить есть наверна) результат будет немного похуже

Чё имеем: Две таблицы, одна с мильоном записей и одна с десятком тысяч записей. В каждой одно числовое поле заполненное случайными целыми числами от 1 до 10000 и 5 текстовых полей длиной 50 символов и заполненных случайными буквами. Всего 4 файла лежащие в сети на каком-то диске, обе таблицы проиндексированы по числовому полю

файл, размер, время за которое можно переписать с диска на диск средствами ОС
--------------------------------------------------------------------------------
test1.dbf - 243 Мб, 57.733 с ---------- 1 млн. записей
test1.cdx - 5.60 Мб, 1.563 с ---------- индекс по числовому полю
test2.dbf - 2.43 Мб, 0.440 с ---------- 10 тыс. записей
test2.cdx - 0.047 Мб, 0.050 с --------- индекс по числовому полю

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

сделал 4 запроса повторив каждый по 5 раз с разными условиями поиска по
числовому проиндексированному полю для учёта погрешности. Во всех запросах возвращалось примерно по 100 записей.

1. все поля из одной большой таблицы
select * from test1 into cursor cursor1 where any_numb=14 nofilter
время выполнения 1.191, 0.832, 0.831, 0.971 и 1.022 секунд
2. одно текстовое поле из одной большой таблицы
select txt1 from test1 into cursor cursor1 where any_numb=15 nofilter
время выполнения 1.111, 0.982, 0.761, 1.001 и 1.052 секунд
3. все поля из большой таблицы сджоиненной с небольшой
select * from test1 a join test2 b on a.any_numb=b.any_numb into cursor cursor1
where a.any_numb=16 nofilter
время выполнения 0.981, 0.792, 0.951, 0.961 и 1.052 секунд
4.одно текстовое поле из большой таблицы сджоиненной с небольшой
select a.txt1 from test1 a join test2 b on a.any_numb=b.any_numb into cursor
cursor1 where a.any_numb=17 nofilter
время выполнения 1.021, 1.062, 0.931, 0.842 и 0.791 секунд

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

Результаты впечатляющие и говорят сами за себя:
1. Файл-серверные технологии на данный момент содержат достаточно средств для создания эффективных информационных систем малого и среднего размера.
2. Кривые руки не смогут помочь дурной голове и наоборот.
3. Продукция фирмы 1ц одинаково тормозит и в дбф и в скл версии что не мешает им грести бабло - значит не всё так однозначно в жизни.
15 ноя 03, 19:41    [419928]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
QQ__
Guest
друзья вот к вам пришел бухгалтер магазинчика и сказал "у нас есть 2 или 3 компьютера... не самые новые там Целероны 1 Мегагерцовые с 128 оперативки... напишите мне программу учета товара в магазине.. у меня 10 000 наименований.." и... многие из Вас, как я видел из этого форума скажут "Мы возьмем Оракл или Сиквель сервер + там Дельфи и напишем, и будет это быстро и круто стоить это будет килобакс а то и больше!!"
а бухгалтер скажет "вы что сдурели - да мне на базаре готовый СД с 1 С за 5 дролларов предлагали и программера возьму к себе он за 2000 долларов мне все настроит и за 100 обучит деффок..." я при таком САМ был...
а другому я сказал за 200 баков напишу - только время дай и на ВФП 5,0 напишу и будет работать...
так то.....
а вы тута гонитесь за производительностью и так дале... да какая производительность имеет значение если 1С ТАААК тормозит - сам видел...
16 ноя 03, 00:51    [420002]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
karly™
Guest
2 Я

Где ежа взял? Такого же хочу!
16 ноя 03, 01:09    [420010]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я и ёжик
Guest
2 karly™
А его вроде Crip привел (в качестве аргумента), а он и прижился у меня, ничего такой ёжик, веселый, спасибо Crip-у.
Спроси у него может он и для тебя приведет.
16 ноя 03, 12:06    [420058]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Вам и Вашим ежам

Я, конечно, понимаю, что файл реально целиком на клиента не передается. Это, собс-но, я и имел в виду, когда сказал "это как-то оптимизировано, наверное он блоками передает и обновляет". Так что, если вам показалось, что я считаю, "что файловые сервисы работают по модели загрузки-выгрузки", дык это от невнимательности наверное.

И спасибо за ссылку:). Кстати, именно там написано, что в удаленном доступе оптимально кеширование как на стороне сервера, так и на стороне клиента. Поэтому я бы, например, не стал утверждать, что в процессе выполенения команды на чтение записи длиной в 1-10-100 байт, по сети будет передано именно это количество. К сожалению, я не смог найти каких-либо подтверждения или опровержения этому, но почему то мне кажеться, что передастся 1-2-4-8 кб (это у меня какая то память от Новелей 10 -летней давности:). Существует вероятность, что в следующий раз мы попадем в этот буфер, и через сеть ничего качать не придется. Ну может я не прав, передается именно 1-10-100 байт... но, блин, в этом случае сеть еще больше нагрузиться... прикиньте какой в сети пинг-понг (т.е. трафик) будет, если мы начнем читать некий файл побайтно. Кстати, это тоже в вашей ссылке отмечено :).

Так штаа..... вазвращщаю Вам Ваши пожелания....
16 ноя 03, 16:42    [420175]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 QQ__

Не смеши народ

-- Tygra's --
18 ноя 03, 12:26    [422411]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
aag
Member

Откуда: Москва
Сообщений: 1955
2 QQ__ :

Распостраненное заблуждение... Бухгалтер, который знаком с 1С и которому ее достаточно, ее и купит. А вот он не знает ни ее, ни Паруса ни др. таких пр-м, или если недостаточно ее функционала - вот тогда он позовет программера и скажет "напиши мне программу..." И программер возьмет MSSQL и Delphi - там же, на базаре, по 100 руб. штучка и напишет ему м.б. даже дешевле чем ваши программеры на VFP и 1с :)


Nobody faults but mine... (LZ)
18 ноя 03, 13:31    [422603]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
OldPferd
Member

Откуда: Конопляновка
Сообщений: 1515
Ну отчего же не посмешить

Вчера был тут в одной конторе (довольно крупная сеть магазинов в С-Пб и Москве) - писали, что им нужен программист со знаниями Clipper и MS SQL
Думал речь идет о переводе в MS SQL. А они - все о Clipper'е
Ну достигает dbf каких-то больших размеров (миллион записей, кажется сказали), режут и удаляют в архив. Сопровождают. Блокировки в сети устанавливают пессимистические. Чтобы работало на современных машинах к exe нужно специальный obj долинковывать (пару лет назад мне такого не нужно было)
Работает, конечно, много сделано. Затраты на перевод всего большие потребуются. А хозяевам прибыль нужна. Какой там клиент-сервер? Кому оно нужно трогать все это? И тем кто там работает - заплатят им что ли?
Но говорят, что ушел программист,а найти специалиста на Clipper сейчас уже не так просто, как раньше
Ну так и будет все работать пока работается

Помню году в 1989 понял, что пора с ЕС сваливать - стал осваивать персоналки, через год пришлось уволиться, чтобы не "застояться". Хотя на работе все нормально было, и з/п, и должность.
А потом рассказывали - там через пару лет пришли программисты на машинное время на ЕС-ку, а их не пускают. Ее продали, оказывается.
18 ноя 03, 14:11    [422727]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Ermak
Member

Откуда: Tomsk
Сообщений: 811
2 OldPferd

Что тут можно сказать, вольному воля.
Случай можно сказать типичный.

Это как нарыв, болит но терпеть пока можно, а ежели резать, то больно и страшно.
Только вот ведь какая штука, все равно придется резать.
18 ноя 03, 15:13    [422915]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
А еще бывает по-другому:
Работает хрень, еще на FoxPro 2.6 for DOS сделана, работает, потом этот чудо программист, чтобы отчитаться перед начальством, просто поднимает все это на VFP и работает оно дальше все так же, а люди все матерятся и ....
Бывает и такой вот перевод системы

-- Tygra's --
18 ноя 03, 15:20    [422943]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
tygra. А чего ей не работать-то? Ей еще лучше прежнего работать-то. Сеточка 100 мегабитная стоит, карточки сетевые от сквозняка не глючат. Файл-сервер P4 под W2000 крутится. Ночью, по расписанию бэкап делается. Юзера с закрытыми глазами батоны жмут. И точно знают, что если ТАМ ввести 0, а ТАМ "бубу", то вся инфа, набранная за день, грохнется. И никогда так не делают.
18 ноя 03, 22:30    [423529]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ты не понял - это говно, извиняюсь, глючит по-страшному. Как в предыдущей версии, так и под винду. Но зато - можно пальцы веером гнуть: Теперь ведь под Windows !!!!!

-- Tygra's --
19 ноя 03, 16:12    [424839]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
Про глюки не надо. Все от ручек зависит - и Delphi от Fox ничем не отличается в этом плане.
20 ноя 03, 08:01    [425567]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
OldPferd
Member

Откуда: Конопляновка
Сообщений: 1515
Поддерживаю предыдущего оратора
И файл-серверные приложения (в своих рамках,конечно) могут быть вполне нормальными.
20 ноя 03, 09:56    [425711]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Я про руки и говорил :)

-- Tygra's --
20 ноя 03, 11:30    [425906]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Crip
Member

Откуда:
Сообщений: 2490
Да-да tygra. Сам когда-то начинал в такой конторе.Еще коробочный софт писали... Прога переписана была на VFP с клиппера практически в лоб , с еще большим количеством багов. Нанятые позже программеры( и я в том числе) навернули кучу интерфейсных прибамбасов, а ядро , согласно требованиям руководства, так и осталось гнилым.Брали клиента дешевизной...Мрак...
20 ноя 03, 15:20    [426587]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить