Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
 Re: В защиту файл-сервера  [new]
x
Guest
2 Серега
2 Очень древний человек

Похоже вы в полемическом задоре забыли, что кроме функций чтения и записи определенного количества байтов из файла, существуют еще и функции установки позиции чтения. И работоет это не только в сети, но и на локальном диске.
23 окт 03, 10:24    [389315]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я
Guest
>>>Вот объясни мне (тоже не самому "новому русскому" 8-) принцип работы,
>>>когда с файл сервера читаются "кусочки". Если есть таблица с полем N
>>>которое имеет миллион разных значений, то как показать юзеру только те
>>>записи у которых N=3 например. Какими "кусочками" ты это наковыряешь?
>>>Объясни мне общую "физику" процесса.

1. Запрашиваем головной блок индекса. По нему определяем след. веточный блок.
2. Запрашиваем блок индекса по нему ищем следующий.
3. Если получен не листовой блок повторяем 2.
4. По ссылке в листе определяем блок файла данных содержащих нужную запись.
5. Считываем блок данных, достаем запись.
6. Повторяем 4. 5. пока блок индекса не кончится или перестанет удовлетворятся условие.
7. Проверяем след. листовой блок индекса (обычно листья связаны в двуноправленный список), если там есть ссылки на нужные данные идем на 4.

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

Это я не к тому что ФС круто а КС не круто, это в качестве ликбеза...
Работаю с Oracle и надеюсь , что жизнь не заставит возвращаться на ФС...
но от тюрьмаы и от сумы не зарекайся...
23 окт 03, 10:47    [389372]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Очень древний человек
Guest
to Серега
>тогда такие файлы и не открывались по сети.
Если в твоем ВЦ дела обстояли именно так, то это не значит что так же было везде. "Физику" Я тебе уже объяснил.
А ты можешь объяснить "физику" как это серверу CS удается найти все записи Where pole = 'N' , не загоняя полностью всю БД в оперативную память? ;) :)
23 окт 03, 16:44    [390456]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Серега
Member

Откуда:
Сообщений: 887
Вот я и вернулся. 8-)


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

Очень древний человек
>А ты можешь объяснить "физику" как это серверу CS удается найти все записи Where pole = 'N' , не загоняя полностью всю БД в оперативную память? ;) :)
Не могу. Потому что иногда таблицы (а не БД!!!) именно полностью загоняются в оперативку. В оракле (например) это называется FULL SCAN.
12 ноя 03, 11:30    [414118]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
2 Серега:
Вероятнее всего будет произведено сканирование _поля_ "Зарплата" по всей таблице, если таблица не индексирована по этому полю. Никак не полное затягивание базы на клиента, а то таблицы со строковыми полями просто умирали бы !
12 ноя 03, 11:41    [414141]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Серега
Member

Откуда:
Сообщений: 887
2Mik Prokoshin
Ну тут сканировать придется минимум 3 поля "Код человека", "Дата" и "Зарплата". А это практически вся таблица. Да к тому же я еще могу условий (вполне жизненных) придумать.
12 ноя 03, 12:01    [414202]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я
Guest
2 Серега.
Это не соответствует начальной задаче, напоминаю Вы спрашивали: "Если есть таблица с полем N которое имеет миллион разных значений, то как показать юзеру только те записи у которых N=3 например. Какими "кусочками" ты это наковыряешь?".

Естественно в Вашем новом примере придется тащить или всю таблицу зряплаты или ее кусок за прошлый год если найдется удачный индекс для этого.
Насчет сканирования _поля_ как сказал Mik Prokoshin сильно сомневаюсь... хотя в случае записей фиксированной длины соответственно с фиксированного размера полями в принципе это реализуемо, но не думаю чтобы ктонить этим занимался, возможно кроме случаев создания своего собственного движка для сильно специализированной базы...
12 ноя 03, 12:10    [414219]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
2 Серега:
Сканируется поле "Зарплата", по найденному полю подтягиваются остальные нужные поля записи.
2 Я:
Этим занимается Foxpro for DOS, например, иначе бы запросы ползали, а не летали :-)
За остальные СУБД не ручаюсь.
12 ноя 03, 12:18    [414245]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я
Guest
2 Mik Prokoshin
Летают... ползают... крылья... ноги... хвосты...
Давайте уж ссылку на документацию или тех.ноту какую...
Ну можно еще перхват сетевого трафика, с расшифровкой...
А так... соррии... "Не верю!" (с) Сами знаете
12 ноя 03, 12:42    [414298]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Crip
Member

Откуда:
Сообщений: 2490
О чем тут можно говорить?
Кто этому человеку Oracle доверил?
12 ноя 03, 14:04    [414521]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я
Guest
Точно, вешать таких, желательно на фонарях...
12 ноя 03, 14:48    [414657]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Серега
Member

Откуда:
Сообщений: 887

Это не соответствует начальной задаче
А где в "моих условиях" говорилось что поле N индексированое? И почему "мои новые условия" другие? "Если есть таблица с полем N которое имеет миллион разных значений, то как показать юзеру только те записи у которых N=3 например" Подставь вместо N "зарплата", и что это изменит?
Да и вообще тут КС и ФС сравнивали помнится, а не подсчет конкретной зарплаты вроде.


2Crip
Это в мой огород булыжник? 8-)
12 ноя 03, 17:44    [415194]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
Ну, подробные изыскания с перехватом выполнения функций ОС и расшифровкой сетевого трафика минимум баков на 500 потянут :-)

А сужу я примитивно - найди небыструю сетку, можешь параллельно ее загрузить еще трафиком, сделай большой файл с одним только полем "Зарплата" и рядом - с пачкой текстовых полей по 255 символов, такое же число записей. Посмотри разницу по времени в запросах (а она будет весьма невелика). Далее выполни простое копирование файла (far, OS copy) и запрос - сравни время. Подумай, как это может выполняться.
Я подобными вещами уж лет 10 назад озадачивался :-)
12 ноя 03, 17:52    [415211]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я
Guest
2 Mik Prokoshin
>>>А сужу я примитивно - найди небыструю сетку,
Ну построение небыстрой сетки српециально для эксперемента, да и поски fox 2.6 под dos то же не дешевы будут... ;)
>>>Посмотри разницу по времени в запросах (а она будет весьма невелика).
В каких запросах? В запрашивающих одно поле и все? Дык, это как раз показывает обратное, что и в том и том случае тянеться все, а разница только на создание курсора разного объема в памяти... Время каких запросов Вы предлагаете сравнивать?
>>> Далее выполни простое копирование файла (far, OS copy) и запрос -
>>>сравни время.
Ага, а если копировать на битую дискету 5.25 то разница во времени заставит
замереть в божественном благоговении перед волшебными технологиями...
Копиравание в OS выполняет запись на медленное устройство, то бишь диск,
а запрос создает структуру в оперативной памяти... так что не катит такое сравнение... тогда уж надо было писать прогу выполняющую чтение файла в память и ее результаты сравнивать.

2 Серега
>>>А где в "моих условиях" говорилось что поле N индексированое?
А где говорилось , что нет? Считайте, что после анализа схемы данных и возможных запросов пользователей я его проиндексировал :)
>>> И почему "мои новые условия" другие?
Патамучта есть некотарая разница между поиском конкретного значения и вычеслением всяко-разных агрегтных функций, не находите?
>>>Да и вообще тут КС и ФС сравнивали помнится, а не подсчет конкретной
>>>зарплаты вроде.
Да я вообще ничего не сравнивал и тем более не делал выводов, Вы попросили объяснить "общую физику процесса" на примере поиска записи с КОНКРЕТНЫМ значением без полного перетаскивания таблицы на клиента, я объяснил, по крайней мере попытался. Если вы спрашивали одно а имели ввиду другое, то я в этом не виноват, неправильно заданный вопрос - половина неправильного ответа.
12 ноя 03, 18:38    [415322]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
>В каких запросах? В запрашивающих одно поле и все? Дык, это как раз показывает обратное, что и в том и том случае тянеться все, а разница только на создание курсора разного объема в памяти... Время каких запросов Вы предлагаете сравнивать?

Ага, если бы все тянулось, то разница была бы весьма велика. (размер-то на порядки будет различаться)

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

Насколько я помню, так делал ДОС Навигатор - читал в память и потом только писал. Так что сравнить можно было. Да и диск тогда был... весьма быстрее сети.
12 ноя 03, 19:33    [415418]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я
Guest
>>>Ага, если бы все тянулось, то разница была бы весьма велика. (размер-то
>>>на порядки будет различаться)
Интересно, с чего бы это размер будет отличаться на порядки?
И в случае запроса одного поля тянем ВСЮ таблицу и в случае запроса всех полей тянем ВСЮ таблицу, размер тянутого по сети ОДИНАКОВ и "невиликая разница во времени" возникает за счет размещение уже в оперативной памяти разного объема структур.
А вот если бы все происходило по вашему сценарию, т.е. тянуться только запрашиваемые поля, то вот тут то размер и должен был бы отличаться на порядки ( в одном случае тянем ВСЮ таблицу т.к запрвшиваем все поля, в другом вырезку по одному полю) соответственно и время должно отличаться СУЩЕСТВЕННО, если бы работа шла по этому сценарию.
Теперь смотрим , что показали проведенные вами 10 лет назад тесты, цытирую: "Посмотри разницу по времени в запросах (а она будет весьма невелика)". Вывод: Поскольку разница по времени в запросах была невилика, значит работа шла, к сожалению, по сценарию полной закачки, и не реализует fox вырезки полей :(.
>>>Да и диск тогда был... весьма быстрее сети.
Эхх... а девушки какие были....
13 ноя 03, 10:11    [415859]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Crip
Member

Откуда:
Сообщений: 2490

Файл-сервер точно также тянет только нужные поля, а если построены соответствующие индексы, то только удовлетворяющие условию записи. Поиск по бинарному дереву также не предполагает скачивания файла целиком.
По-моему это все ежу понятно...
13 ноя 03, 10:15    [415866]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
2 Я:
Вы не поняли условий тестирования.
Имелось в виду - сравнить выборки из разных таблиц - первая состоит из одного поля, вторая - из 10, в нее включено такое же поле для выборки.
13 ноя 03, 10:48    [415950]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я
Guest
2Mik Prokoshin
Ok. Тогда да, но по возможности проверю.
Вот только свой вариант эксперимента я уже поставил,
и он дал ожидаемые мной результаты , т.е. та самая разница во времени не велика, как объясните?

2Crip
Вы бы хоть прочитали сначала, а то действительно и ёж уже понял...
Речь не идет о доступе к ограниченому набору записей таблицы и отсеивании етого набора по индекcу, речь идет о "выгрызании" конкретного поля из таблицы. Я всего лишь прошу "документального" ну или "эксперементального" подтверждения реализации этого механизма в Fox.
13 ноя 03, 11:08    [416024]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
> в случае запроса одного поля тянем ВСЮ таблицу и в случае запроса всех полей тянем ВСЮ таблицу, размер тянутого по сети ОДИНАКОВ и "невиликая разница во времени" возникает за счет размещение уже в оперативной памяти разного объема структур

Приведите условия тестирования более конкретно, насколько я понял, таблица была одна и та же, а к-во полей, участвующих в запросе различалось где ? В WHERE или SELECT ... Тогда поясню :-)
13 ноя 03, 12:05    [416200]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я
Guest
Количество полей различалось в select, where пустое во избежание наводок:).
Таблица 1 числовое поле n(10) и 18 полей с(254)
зафигал туда около 50000 записей.

select number_field from ...
и
select * from ...

Да, тестировалось на VFP 5.0 , фокса для дос не нашел :)
13 ноя 03, 12:19    [416258]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
ФайлСерверФоревер
Guest
to Я
Да говорят же вам "Вы не поняли условий тестирования"!
Речь идет не о
select number_field from table1
и
select * from table1 .
А о
select number_field from tableBIG (1 числовое поле n(10) и 18 полей с(254))
и
select number_field from tableSMALL (1 числовое поле n(10) only)

Разница по времени между этими двумя запросами будет значительно меньше, чем между
select number_field from tableBIG (1 числовое поле n(10) и 18 полей с(254))
и
select * from tableBIG (1 числовое поле n(10) и 18 полей с(254)),
что свидетельствует о том, что Fox НЕ перетягивает по сети ВСЕ поля (а уж на клиенте херит не нужные), а "вычисляет" сразу адреса нужных полей и перетягивает только их.
13 ноя 03, 13:48    [416534]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
ФайлСерверФоревер
Guest
to Серега
посмотри отпочковавшийся от нас топик "Re: В защиту файл-сервера"
Там тебе еще раз расскажут, каким "чудесным" образом Fox-у удается бегать по DBF, не перегоняя его целиком на локал по сети.
13 ноя 03, 13:56    [416558]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Я и ёжик
Guest
2ФайлСерверФоревер
>>>Да говорят же вам "Вы не поняли условий тестирования"!
Вот, еще один нам с ёжиком объяснять пришел...
Это Вы забыли прочитать или понять дискуссию, сообщение которое вы так яростно опровергаете касалась просьбы Mik Prokoshin привести более конкретно условия МОЕГО тестирования, дабы он мог дать пояснение.

Впрочем это не важно, людям свойственно ошибаться, мне вот интереснее
обсудить следующее Ваше замечание:
>>>что свидетельствует о том, что Fox НЕ перетягивает по сети ВСЕ поля (а
>>>уж на клиенте херит не нужные), а "вычисляет" сразу адреса нужных
>>>полей и перетягивает только их.
И что, он так делает всегда? Но ведь даже нам с ёжиком понятно, что это далеко не всегда выгодно, часто быстрее будет запросить одной операцией блок данных целиком и перегнать его по сети, чем организовывать десять запросов на выборку десяти полей ( ну пусть нужные поля идут не подряд, а по очереди с ненужными).
Таким образом в Fox должен быть механизм принимающий решение каким способом проводить выборку и соответственно мануал для программера поясняющий как дизайнить базу и приложение что бы этот механизм гарантировано использовался или неиспользовался. Дайте наконец ссылку и "все кончится" (с) тф Собака Баскервилей.
13 ноя 03, 14:29    [416652]     Ответить | Цитировать Сообщить модератору
 Re: В защиту файл-сервера  [new]
Mik Prokoshin
Member

Откуда: Барнаул
Сообщений: 1240
А ссылки нет и быть не может, так же, как про алгоритмы оптимизатора запросов MSSQL. Эти вещи создателей кормят :-)
О Вашем примере - не могу ничего сказать,подобные вещи никогда не тестировал. Я имел в виду запросы вида
SELECT * FROM tt WHERE Field=...
т.е. с некоторым условием выборки, по полям этих условий обычно и идет оптимизация. И вполне возможно, что при размере записи менее скольки-то, берется вся запись целиком.
И еще могу отметить, что алгоритмы выборок в фоксе под винды уже наверняка другие, т.к. славу самой быстрой персональной СУБД Фокс утратил после 2.6 :-)
13 ноя 03, 15:19    [416800]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить