Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 .. 25   вперед  Ctrl
 Re: Есть ли будущее у файл-сервера?  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
Некто из дома
Ну давайте посоревнуемся :) : пусть у вас гигабитный эзернет, пусть его скорость почти равна скорости диска.... в тот момент, когда есть один клиент и никто больше не работает А когда навалятся на сеть 100 клиентов, да еще половина из них начнет из интернета порнуху качать, а еще бэкап базы на другой сервак, а еще ... много чего еще. И сколько станет скорость? Нисколько, чтобы рвняться со скоростью шины диска.
Но хрен с ним, перетянули 10 Гигабайт данных на клиента каким-то образом. Клиент умер благополучно - потому что сам компутер не смог переварить такой объем пришедших данных. Если смог - клиентская прога умерла. Если не умерла.... Тогда значит, учитывая высказывания выше что клиентские компы чуть хуже, чем сервер, и учитывая, что сервер 4-х процовый, значит клиентские компы 2-х процовые??? Каждый с 2-мя гигами памяти? Кто это так хорошо живет?

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

Какие гигабайты? Полтопика говорилось, что ФС лучше всего в однопользовательских маленьких системах (я сам против этого тоже), но к чемпу тогда две страницы сетевой воды?

Бред какой-то, полнейший, все-равно что обсуждать, как будут летать танки, если и приделать крылья, причем приводя расчеты обтекаемости танков, величины пропеллера, размах крыла
Ну вот, еще один из дома хочет на компьютер пользователя гигабайты качать ;-) Не нужно этого, ни в КС, ни в ФС. И не занимаются этим ФС-системы. И не нужно в ФС всю БД на клиента таскать. И даже целую табличку не нужно. И оба, что КС, что ФС, умрут с такими подходами.

А вообще - при нормальном стандартном режиме работы на ПК с файл-сервера у меня за целый рабочий день тянулось чуть более 200 или 300 Мб, вот. Разумеется, при упаковке и реиндексации гораздо больше (ну, тут, понятно, действительно, нужно перекачать таблицы и индексы целиком).

А в одной известной трехзвенной системе с КС и сервером приложений, например, где даже форма открывается на среднем звене, а на ПК пользователя появляется только ее ява-образ, на ПК клиента только при открытии одной такой формы передается 1-2 Мб.
8 май 05, 13:52    [1525631]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Urri

Не нужно этого, ни в КС, ни в ФС. И не занимаются этим ФС-системы.

Речь о том, что нужно выполнить запрос к табле, в которой данных на 10 Гб.
Сам запрос вернет несколько записей, но просканировать нужно всю эту таблу. КС сканирует на сервере, а по сети получит несколько байт. А ФС запросы обрабатывает на клиенте. Потому и должен притащить себе эти 10 Гб.
Т.е. КС тащить действительно не нужно. Иначе обстоит с ФС. И была высазана мысль о том, что сети очень быстрые, и потому нет разницы, что с диска сервак КС это читает, что ФС и с диска сервака и по сети. Вот эту мысль комментировал Некто из дома.
8 май 05, 14:26    [1525654]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Geo
Member

Откуда:
Сообщений: 6883
vadiminfo
Речь о том, что нужно выполнить запрос к табле, в которой данных на 10 Гб.
Сам запрос вернет несколько записей, но просканировать нужно всю эту таблу. КС сканирует на сервере, а по сети получит несколько байт. А ФС запросы обрабатывает на клиенте. Потому и должен притащить себе эти 10 Гб.

Это неправда.
8 май 05, 14:58    [1525691]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Geo
Member

Откуда:
Сообщений: 6883
Хотя нет, вру, можно добиться и такого.
==
ЗЫ. Интересный топик, спасибо всем
8 май 05, 15:00    [1525693]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
ух блин понаписали... ну что ж, пивом затарился, значит можно веселиться дальше

2 StalkerS
ЛП

Не настолько мощнее, чтобы сто задач одновременно выполнить быстрее, чем сто более слабых компютеров (замечу, ненамного более слабых) - каждый по одной задаче. Это факт, и даже не как правило, а практически всегда

вот уж точно детский лепет. Вы что, предлагаете на все клиентские места ставить современные компьютеры ? У нас часть клиентов работают на 133 MHz пнях и 64 МВ оперативки (кажется, даже есть с 32 метрами).

Я лично - ничего не предлагаю. Но они ж, сволочи, сами современные компутеры ставят! Ну не хотят у меня пользователи на трухлявых пнях работать, и совсем не потому, что к ним какая-то там СУБД не влезет, а потому что любимый эксель долго открывается.
На работе новой секретарше компутер купили. Я репу почесал и понял, что этот компутер лет пять назад вполне мог бы позиционироваться в качестве нормального low-end сервера под СУБД. За последние пять лет клиентские машины выросли как на дрожжах, а MS SQL Server как был 2000, так и остался.
Поэтому давайте не будем о трухлявых 133-их пнях, тут топик все таки про будущее, а не про дела давно минувших дней.

Ну давайте, засосите туда по сети гигобайтную таблицу и повертите ее там.

Вы, кажется, невнимательно читаете. Мне не надо никуда ничего сосать. Клиентскому приложению достаточно пофигу где лежит файл - на локальном диске или же в сети. Как показывают прикидки, с сетью даже быстрее получается. Так что можно спокойно и не напрягаясь "вертеть" удаленным файлом, и без потери скорости.
Слон большой, поэтому жрать его будем по кусочкам.

И вообще, как раз более обычная ситуация (во всяком случае у нас), когда одновременно с сервером работают не 100 клиентов, а только 5-10 % от них, соответственно сервер использует все свои ресурсы на их обработку, и это явно быстрее, чем обработка запросов на менее мощных клиентах, даже если они "ненамного более слабые"

Я вот знаю одну занимательную историю, которую люблю рассказывать к месту и не к месту. Сядьте поудобнее, дети, и послушайте сказку.

Однажы кто-то где-то проводил небольшой эксперимент, сравнивая производительность однопроцессорной системы, и четырехпроцессорной. Два компутера, одинаковой конфигурации, тока кол-во процов отличалось. Нагрузили их какими-то процессорожрущими задачами, точно не помню, но что-то типа закрытия банковского опердня, архивированием чего-то большого, вращением картинки в фотошопе, и еще какой-то мурой. Внимание вопрос: какая система была быстрее, одно- или четырехпроцессорная, и насколько?
В этот момент многие начинают думать, что раз такой вопрос задается, значит где-то тут подвох, и, после невнятного мычания, отвечают, что быстрее была наверное однопроцессорная система. Те же, у кого сохранились остатки здравого смысла, говорят что быстрее конечно же четырехпроцессорная, но ненамного, раза в полтора-два. Так вот, все это х**ня. Быстрее конечно же 4-хпроцессорная. Примерно в 100 (сто) раз. И объяснение этому весьма простое - переключающиеся задачи затирали друг у друга процессорный кэш.
У этой сказки есть неочевидная мораль. Мораль в том, что даже на однопроцессорной системе можно было получить примерно двадцатипятикратный выигрыш в скорости - если выполнять задачи не параллельно, а последовательно. Но это уже к делу не относится.

К чему это я? А... Так вот. Скажите мне, насколько монструозным должен быть сервер, чтобы сотню задач параллельно он один выполнил быстрее, чем сотня клиентских компутеров каждый по одной? Под задачей я понимаю не "селект одназапись фром однатаблица", а, как здесь любят, "обработать гиг, а то и десяток гигов информации".

-------------------------------------

2 Некто из дома
Ну давайте посоревнуемся :) : пусть у вас гигабитный эзернет, пусть его скорость почти равна скорости диска.... в тот момент, когда есть один клиент и никто больше не работает А когда навалятся на сеть 100 клиентов

Невнимательно читаете. Я уже говорил про "сотни и тысячи машин"
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=179930&pg=10#1525422
Это для случая, когда все сто клиентов навалились на один ресурс.
Если же кто-то там порнуху качает - да и хрен бы с ним, гигабитных хабов я еще ни разу не встречал.

Но хрен с ним, перетянули 10 Гигабайт данных на клиента каким-то образом

См. выше. Не надо целиком 10 гиг никуда тянуть и целиком их вращать. Слона будем жрать по кусочкам.

Клиент умер благополучно - потому что сам компутер не смог переварить такой объем пришедших данных. Если смог - клиентская прога умерла.

На двухгиговых базах у меня ни аксес, ни комп почему-то не умирают. Говорите, на 10 умрет клиентский компутер? Ню-ню.

Какие гигабайты? Полтопика говорилось, что ФС лучше всего в однопользовательских маленьких системах (я сам против этого тоже), но к чемпу тогда две страницы сетевой воды?

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

----------------------------------------------------

2 vadiminfo
Давайте зафикируем:

Ок, давайте зафиксируем по пунктам, начиная с конца, кончая началом.
П.3. - согласен безоговорочно, и даже склонен усилить это утверждение.
П.2. - безоговорочно несогласен. Вы тут упомянули про системные требования к лонгхорну? Где-то в инете был обзор беты. Больше всего меня поразило то, что типичная инсталяция занимает на жестком диске 4.5 гигабайта, а полная - больше 6 гигабайт. Так что эта... вы со своими тремя дисками Оракл Энтерпрайз, как грится, напугали ежа голой жопой.
П.1. - согласен условно. Т.е. вроде как трафик то и больше, но вроде как и х*й бы с ним (если он конечно не платный). По скорости обращение к сети не проигрывает обращению к жесткому диску. Если ФС способно адекватно работать в локальном режиме (с чем вроде никто не спорит), то и в сетевом режиме адекватности не уменьшится. С учетом п.3 конечно же. Т.е. с учетом того, что многопользовательская (не сетевая, а именно многопользовательская) работа затрудняет ... и далее по тексту.

-----------------------------------

уффф...
скоро буду как Гаря.
8 май 05, 21:08    [1525905]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Что, нет никого?
Ну значит я победил :)
9 май 05, 03:37    [1526122]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
ЛП

Но они ж, сволочи, сами современные компутеры ставят! Ну не хотят у меня пользователи на трухлявых пнях работать, и совсем не потому, что к ним какая-то там СУБД не влезет, а потому что любимый эксель долго открывается.
На работе новой секретарше компутер купили. Я репу почесал и понял, что этот компутер лет пять назад вполне мог бы позиционироваться в качестве нормального low-end сервера под СУБД

Есть серьезные основания полагать, что вы из Москвы. Зажрались аднака, давно пора вас всех там раскулачивать ;)

Знаете что будет, если придя после праздников на работу, я заявлю, что на всех клиентов надо поставить новые компьютеры (по штуке баксов за каждый) ? Через промежуток времени, необходимый для полета через окно после пинка под зад, я окажусь за пределами нашего почтенного учреждения.
Такие компьютеры стоят в цехах, для работы распредов, и предполагается, что ничего кроме клиентской программы там работать и не должно. Если Р-133 с этим справляется, то какого дьявола там делать современным компам ?
ЛП

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

Это зависит от соотношения мощности сервера и клиентов. Если они одинаковы, то понятно, что распределив вычисления, получите результат быстрее. Однако, начав увеличивать разницу между ними, доберемся то такого момента, когда сервер справиться быстрее. Я такими тестами не занимался, и не знаю, где находиться этот предел. В любом случае, я писал, что чаще происходит обратное, когда только небольшой процент клиентов работают с сервером в каждый отдельный момент времени, что позволяет слабым клиентам получать резалтсеты со скоростью, которая и не снилась их процессорам. Собственно, для этого вся КС и замышлялась.
А разница в скорости может быть впечатляющей. Как говориться, если любите сказки - их есть у меня :

скорость работы одного из запросов, который я тестировал из интереса составила (MSSQL):

P-700 Мhz - 33 мин.;
Duron 1.2 Mhz - 16 мин.;
Ксеон 2 х 2.4 Mhz - 2 сек.

Так что, если в пике нагрузки скорость сервера и упадет до безобразно низкого значения, все остальное время клиенты будут получать результаты через 2 сек, а не полчаса, как будет в случае любимой вами ФС.
ЛП

За последние пять лет клиентские машины выросли как на дрожжах, а MS SQL Server как был 2000, так и остался

А что, серверные компьтеры из посного теста сделаны ? Совсем-совсем не выросли ?
ЛП

Слон большой, поэтому жрать его будем по кусочкам

Каким еще кусочкам ? разве, если нужно сделать запрос к таблице, она не должна приехать по сети к клиенту целиком ?
9 май 05, 12:04    [1526207]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Некто из дома
Guest
автор
Ну вот, еще один из дома хочет на компьютер пользователя гигабайты качать ;-) Не нужно этого, ни в КС, ни в ФС. И не занимаются этим ФС-системы. И не нужно в ФС всю БД на клиента таскать. И даже целую табличку не нужно. И оба, что КС, что ФС, умрут с такими подходами.

Вы забыли одну вещь: для КС тянуть все на клиента в принципе не нужно никогда, чего не сказать об ФС.
автор
А вообще - при нормальном стандартном режиме работы на ПК с файл-сервера у меня за целый рабочий день тянулось чуть более 200 или 300 Мб, вот.

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

ЛП
Я лично - ничего не предлагаю. Но они ж, сволочи, сами современные компутеры ставят! Ну не хотят у меня пользователи на трухлявых пнях работать, и совсем не потому, что к ним какая-то там СУБД не влезет, а потому что любимый эксель долго открывается.
На работе новой секретарше компутер купили. Я репу почесал и понял, что этот компутер лет пять назад вполне мог бы позиционироваться в качестве нормального low-end сервера под СУБД. За последние пять лет клиентские машины выросли как на дрожжах, а MS SQL Server как был 2000, так и остался.
Поэтому давайте не будем о трухлявых 133-их пнях, тут топик все таки про будущее, а не про дела давно минувших дней.

Вы действительно очень заблуждаетесь, думая, что Россия заканчивается сразу за МКАД и денег у всех мешки.
Так что, будем делать программы и в требованиях указывать: не менее Р4 2000 и 2 гига оперативки со сказевыми винтами?
автор
Вы, кажется, невнимательно читаете. Мне не надо никуда ничего сосать. Клиентскому приложению достаточно пофигу где лежит файл - на локальном диске или же в сети. Как показывают прикидки, с сетью даже быстрее получается. Так что можно спокойно и не напрягаясь "вертеть" удаленным файлом, и без потери скорости.
Слон большой, поэтому жрать его будем по кусочкам.

Вы умеете обрабатывать данные удаленно? Даже не забирая на клтиента? Телепатически?
Ну хорошо, давайте, сделайте: есть заказы, их 70000 в месяц, есть товары, их в среднем по 5 в заказе. Нужно вытащить все заказы за предпоследний месяц, количество товаров в которых не менее 3 штук, чтобы сумма товаров была не менее Х рублей, чтобы у клиента, который заказал заказ, было не менее 10 заказов за последние полгода с суммой не менее 1000 рублей и чтобы он когда либо в жизни заказывал китайский будильник.
Я думаю, этот запрос ничего не будет стоить и ничего на клиента тянуть не надо будет :))
автор
Скажите мне, насколько монструозным должен быть сервер, чтобы сотню задач параллельно он один выполнил быстрее, чем сотня клиентских компутеров каждый по одной?

Так у вас клиентские компутеры из прайса на серверное оборудование покупаются? :)) Или у вас распределенная система из всех 100 компутеров?? Или у вас обычно запрос вида "дай одну запись по этому ID"?
Если не то и не то, то пример бредовый - с полпинка найдется такая задача, которая положит клиента насмерть. Если конечно говорить серьезно. Иначе я
могу с той же уверенностью сказать, что я запустил самодельную ракету на луну: я ее поджог, она улетела вверх и больше я ее не видел - значит она на Луне, потому что именно туда я ее и пускал. Если бы не долетела, то упала бы - дык я ее не нашел, после запуска в глаза не видел, значит она там... Привет лунатикам
====================

Мда.
9 май 05, 14:35    [1526273]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
автор
Каким еще кусочкам ? разве, если нужно сделать запрос к таблице, она не должна приехать по сети к клиенту целиком ?


Лев - царь зверей.

Можно и так запрограммировать.
При таком программирований сдохнет не только ФС но и КС
9 май 05, 14:42    [1526279]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Есть подозрение, что все свелось к обсуждению способа перекачки данных по сети...

Для тех кто не в курсе - современные технологии позволяют это свести до минимума как в ФС, так и в КС - называется это чудо Web Services (или иногда просто COM server)... Этой технологии без разницы, что в качестве базы данных - от клиента принимается запрос в несколько байт - назад передвется ответ в зависимости от того, что запросил...
9 май 05, 15:25    [1526309]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Geo
Member

Откуда:
Сообщений: 6883
Интересно, кто первый объяснит, как в ФС выполняется запрос типа
select * from t where f1=[parameter1]
, и что куда при этом передается по сети?
:)
9 май 05, 15:35    [1526315]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
Alexey Sh

Можно и так запрограммировать.
При таком программирований сдохнет не только ФС но и КС

Sergey Ch

Для тех кто не в курсе - современные технологии позволяют это свести до минимума как в ФС, так и в КС - называется это чудо Web Services (или иногда просто COM server)... Этой технологии без разницы, что в качестве базы данных - от клиента принимается запрос в несколько байт - назад передвется ответ в зависимости от того, что запросил...

темните вы что-то там ;)
всегда думал, что при запросе в ФС к определенной таблице, она приезжает на клиента, и там обрабатывается. Что, не так ?

И про Web Services непонятно, нафиг он нужен в КС, потому как "принимается запрос в несколько байт - назад передвется ответ в зависимости от того, что запросил..." полностью соответствует определению КС
9 май 05, 15:47    [1526326]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
Geo
Интересно, кто первый объяснит, как в ФС выполняется запрос типа
select * from t where f1=[parameter1]
, и что куда при этом передается по сети?
:)


на клиент приедет весь индекс, если индекса нет то вся табличка. т.е. если постараешься то вместо 10гб тебе приедет всего лишь 1гб :)
9 май 05, 15:50    [1526331]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Geo
Member

Откуда:
Сообщений: 6883
Не знаю, как насчет "весь" индекс, но вполне возможно. Надо ЛП дождаться - он должен знать. А так верно. Так что разговоры и о 10 Гб, и о 2-3 байтах несколько преувеличены.

Забавно. Хотелось бы мне посмотреть на человека который, прогнозируя будущее существование 10Гбайтных таблиц с актуальными (не архивными) данными, стал бы делать это на файл-сервере, и послушать его доводы
9 май 05, 15:54    [1526337]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Yo!!
Geo
Интересно, кто первый объяснит, как в ФС выполняется запрос типа
select * from t where f1=[parameter1]
, и что куда при этом передается по сети?
:)


на клиент приедет весь индекс, если индекса нет то вся табличка. т.е. если постараешься то вместо 10гб тебе приедет всего лишь 1гб :)


Вы с какого дерева упали?
Зачем ВЕСЬ индекс ?
По большому счёту индексы устроены одинаково, что в КС, что в ФС.
9 май 05, 15:58    [1526340]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
>>Вы с какого дерева упали?
>>Зачем ВЕСЬ индекс ?

тогда ответит тут кто-нибудь на вопрос, что именно ездит по сети, а то пора уже пиво идти пить, а вы тут разобраться не можете ;)
9 май 05, 16:08    [1526349]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Geo

Забавно. Хотелось бы мне посмотреть на человека который, прогнозируя будущее существование 10Гбайтных таблиц с актуальными (не архивными) данными, стал бы делать это на файл-сервере, и послушать его доводы


ну такого вряд ли дождёмся, а вот почему ФС представляются многими участнниками в виде плоских файлов без индексов, поддержки транзакций- мне непонятно.

P.S. 2 all: не думайте, что я агитирую за применение ФС. просто аргументация у сторонников КС в этой дискуссии мягко говоря слабовата. Такое ощущение, что в КС не то что добрая фея, толпа злобных демонов результат клиенту отдаёт, не обращаясь к данным
9 май 05, 16:15    [1526355]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
StalkerS
>>Вы с какого дерева упали?
>>Зачем ВЕСЬ индекс ?

тогда ответит тут кто-нибудь на вопрос, что именно ездит по сети, а то пора уже пиво идти пить, а вы тут разобраться не можете ;)


Это кто разобраться не может?
Сколько чтений нужно для поиска ключа в B-дереве?
9 май 05, 16:19    [1526359]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ЛП

П.2. - безоговорочно несогласен. Вы тут упомянули про системные требования к лонгхорну? Где-то в инете был обзор беты. Больше всего меня поразило то, что типичная инсталяция занимает на жестком диске 4.5 гигабайта, а полная - больше 6 гигабайт. Так что эта... вы со своими тремя дисками Оракл Энтерпрайз, как грится, напугали ежа голой жопой.

Так три диска это по сравнению с сегодняшним одним Осей, на которых СУБД крутится. Технологии БД вроде не достигли своей вершины. Восможно, три диска совсем не предел. И то мы СУБД КС сравниваем с Осями. А скока дисков у СУБД ФС?
Ну, хорошо это Вы сомневаетесь, что СУБД склонны подтягиваться по толщине к толщине аппаратных ресурсов. Мне, кажется, пока еще не оснований сбрасывать со счетов такие тенденции. А толщина означает интеллектуальность своего рода. Это мы пытаемся в перспективу смотреть. А сегодня напрмер, диалекты SQL у КС повыразительнее чем у ФС. Да многое другое породвинутей. Или нет?

Второй аспект П2, это то, что в сети реальнее иметь один и несколько, навороченных компов (20000$-100000..$) и множество пусть по 1000$. И возможно, на самом навороченном более эффективно сложные запросы из БД выполнить, а клиентам уже передать маленький ответ, для маленькой работы. Т.е. распределение вычислений более эффективное может быть за счет многократно более высокой производительности таких навороченных серваков.
Вы в этой точке зрения находите слабые места? Если учитывать как поставлена тема, то мне кажется еще рано считать, что возможность наращивания ресурсов более дорогих компов уже исчерпана. Т.е. рано, наверное, считать, что клинты их обязательно догонят, и все они вместе станут одинаковыми, поскольку дальше расти некуда.
Я не знаю что там за компы в тестах TPC-C, но мне кажется большинству клиентов до них далековато. И СУБД ФС там нет.

ЛП

П.1. - согласен условно. Т.е. вроде как трафик то и больше, но вроде как и х*й бы с ним (если он конечно не платный). По скорости обращение к сети не проигрывает обращению к жесткому диску. Если ФС способно адекватно работать в локальном режиме (с чем вроде никто не спорит), то и в сетевом режиме адекватности не уменьшится. С учетом п.3 конечно же. Т.е. с учетом того, что многопользовательская (не сетевая, а именно многопользовательская) работа затрудняет ... и далее по тексту.

Что значит условно? Мы же договрились есть задачи где все эти недостатки не проявляются. Смотрим в плане как звучит тема. Тогда смело увеличиваем 10Гб од 100, 1000. Считаем сеть не только локальную, но и голбальную. Если ФС даже окажется сравнима в ЛВС, но значительно уступает в глобальной, то ФС затруднительно вытеснить КС, потому ограничиваться ЛВС технолгиям БД сегодня поздно. Они уже выскочили - распеределенные БД. Это важное требование. Банки с разными филиалами и все такое. Кста - там и трафик не бесплатный.

Я даже допскаю, что ФС быстрей читает файлы в виду его специализации на этом.
Но что мы получаем? Что вы скажете вот на такую чушь:
Пусть V обем, который мы должны пропучить через запрос. Если один сервак и один клиент, то КС Tk(V), Tf(V)+Tn(V) - T - время. Пусть даже Tk(V) > Tf(V) - время чтения в КС больше, так сервак более универсальный (не тока читает файлы), чем ФС. Но Вы грите Tk(V) сравнимы с Tn(V) - время прокачки по сети.
Все равно еще возможно, что Tk(V) < Tf(V)+Tn(V). Теперь пусть N клиентов. Тогда Tn(V) - должно умножиться на коэф > 1 и тем больше чем N и V - так как сеть общий ресурс.
Плюс сюда - некоторые блоки по несколько раз считываются в сети. Плюс внешний трафик, что уже сказали - парни фильмы качают. Плюс Диск + Сеть менее надежно, чем просто диск (два разных типа устройств менее надежно, чем одно) и это в частности проявляется при больших объемах (мы не учитываем при малых, потому что это и для КС плохо).
Что Вы про это думаете?
9 май 05, 21:52    [1526663]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
ииййееехх
с новым пивом в новый бой
разгребать очередную порцию дибилизма

----------------------------------------------
2 StalkerS
Это зависит от соотношения мощности сервера и клиентов. Если они одинаковы, то понятно, что распределив вычисления, получите результат быстрее. Однако, начав увеличивать разницу между ними, доберемся то такого момента, когда сервер справиться быстрее.

Так вот и скажите мне, насколько велика должна быть разница?
Возьмите в качестве задачи архивирование одного гигабайта информации. Задача оторванная от баз данных, но нагружающая процессор и дисковую систему. Замерьте, за сколько это выполняется на среднем клиентском компе, и прикиньте, какой мощности должен быть сервер, чтобы сделать тоже самое, но сто раз параллельно.
Не спорю, можно и такой сервер собрать, который это выполнит даже быстрее. Хотелось бы поглядеть на его стоимость.
Если вам претит заниматься задачами, оторванными от баз данных - лекго можно придумать аналогичную и для БД. На сотню клиентов (среднестатистических компутеров) ставим MSDE, нагружаем каждого клиента обсчетом своих миллионов записей, после этого пытаемся сконфигурировать центральный сервак с MS SQL Server'ом так, чтобы он сделал все то же самое параллельно, но быстрее.
Думаю, что даже если центральному серваку дать фору в виде времени, необходимого для пересылки нужных данных на "клиентов" - он еще не скоро догонит.

Как говориться, если любите сказки - их есть у меня :

скорость работы одного из запросов, который я тестировал из интереса составила (MSSQL):

P-700 Мhz - 33 мин.;
Duron 1.2 Mhz - 16 мин.;
Ксеон 2 х 2.4 Mhz - 2 сек.

Запустите на ксеонах сотню аналогичных запросов одновременно, но над разными диапазонами данных. Сильно сомневаюсь в том, что вы получите 200 секунд. А чем дальше от 200 секунд - тем ближе к 1000 секундам, которые можно получить на сотне дюронов.
Да, когда запустите - не забудте сюда результат выложить. Интересно будет взглянуть, меньше 1000 секунд получится или больше.

А что, серверные компьтеры из посного теста сделаны ? Совсем-совсем не выросли ?

Выросли, выросли. Только я, знаете ли, не утверждал никогда, что сервер СУБД не влезет на серверные компьютеры. А вот утверждения что сервер СУБД (файл-серверной или клиент-серверной) не влезет на клиента - звучали. И эти утверждения - бред сивой кобылы.

Каким еще кусочкам ? разве, если нужно сделать запрос к таблице, она не должна приехать по сети к клиенту целиком ?

Целиком - не должна.

-----------------------------------------------------

2 Некто из дома
Вы действительно очень заблуждаетесь, думая, что Россия заканчивается сразу за МКАД и денег у всех мешки.
Так что, будем делать программы и в требованиях указывать: не менее Р4 2000 и 2 гига оперативки со сказевыми винтами?

Так у вас клиентские компутеры из прайса на серверное оборудование покупаются?

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

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

--------------------------------------------------

2 Yo!!
Geo
Интересно, кто первый объяснит, как в ФС выполняется запрос типа
select * from t where f1=[parameter1]
, и что куда при этом передается по сети?
:)

на клиент приедет весь индекс, если индекса нет то вся табличка. т.е. если постараешься то вместо 10гб тебе приедет всего лишь 1гб :)

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

----------------------------------------

2 vadiminfo
Ну, хорошо это Вы сомневаетесь, что СУБД склонны подтягиваться по толщине к толщине аппаратных ресурсов.

Скажем так, я не знаю современных СУБД (как ФС, так и КС), которые бы не установились на современный компьютер (из "клиентского", а не "серверного" прайса). И не только бы не установились, а и вполне нормально работали бы, (с учетом того, что обслуживать им придется ровно одного клиента, а не сотни и тысячи).
Какая-нибудь Терадата может и не встанет, но я ее не знаю. Из того что знаю - всё на клиента встанет и всё будет работать. Поэтому п.2 ("необходимость установки на каждого клиента полной копии СУБД") - не является недостатком, разве что с точки зрения мальчика-инсталятора.
По п.2 закончим когда-нибудь или нет?

А сегодня напрмер, диалекты SQL у КС повыразительнее чем у ФС. Да многое другое породвинутей. Или нет?

Или нет. Продвинутый диалект SQL, да и "многое другое" - не являются родовыми признаками КС. Об этом уже сто раз на протяжении этого топика было сказано. Почему об этом надо повторять в стопервый раз? Для тупых конечно можно повторить и в стовторой, но давайте до тупых не будем опускаться.
Давайте сравним "навороченность" диалекта SQL у файл-серверного аксеса - и у какого-нибудь клиент-серверного MySQL, особенно старых версий. После этого прекратим нести чушь.

Если ФС даже окажется сравнима в ЛВС, но значительно уступает в глобальной

В самом начале "сетевой воды" я сказал, что все рассуждения только для локальных сетей. Почему я это второй раз должен повторять?

Но что мы получаем? Что вы скажете вот на такую чушь:
Пусть V обем, который мы должны пропучить через запрос. Если один сервак и один клиент, то КС Tk(V), Tf(V)+Tn(V) - T - время. Пусть даже Tk(V) > Tf(V) - время чтения в КС больше, так сервак более универсальный (не тока читает файлы), чем ФС. Но Вы грите Tk(V) сравнимы с Tn(V) - время прокачки по сети.
Все равно еще возможно, что Tk(V) < Tf(V)+Tn(V). Теперь пусть N клиентов. Тогда Tn(V) - должно умножиться на коэф > 1 и тем больше чем N и V - так как сеть общий ресурс.

Так для N клиентов и Tk должно увеличиваться, потому что все в конечном итоге будут в один винчестер ломиться (через прослойку в виде SQL Server'а). Об этом я тоже сказал.

Плюс сюда - некоторые блоки по несколько раз считываются в сети.

И это тоже уже было упомянуто (вы вообще читаете топик? или только то, что обращено лично к вам?).
Для ярко выраженной повторяемости чтений - да, в случае КС читать с диска не надо, в случае ФС читать с диска тоже не надо, но переслать по сети придется.
Если ярко выраженной повторяемости нет - то влияние сетевых накладных расходов невелико.

Плюс внешний трафик, что уже сказали - парни фильмы качают

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

Плюс Диск + Сеть менее надежно, чем просто диск

Вы про надежность или про сетевой трафик? Если про надежность - то это относится к п.3, с коим я согласился. В чем вы меня пытаетесь убедить?
10 май 05, 00:44    [1526781]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 vadiminfo
Забыл чуть-чуть.
Еще раз про сетевой трафик.
Даже в случае WAN, когда трафик платный, а скорость очень низкая - чисто клиент-сервеные решения тоже не являются оптимальными. Иногда гораздо более выгодно выполнить часть "мелкой" работы на клиенте, но сэкономить сетевой трафик. Могу привести примеры из аксесовского форума, когда люди, работающие в ADP (клиент-серверная инкарнация аксеса) использовали решения, присущие именно файл-серверным системам, и именно в целях минимазации сетевого трафика при доступе через WAN
Так что избыточный сетевой трафик является недостатком не только ФС, но и, в какой-то мере, КС тоже. И избавляться от него надо гибридными схемами. КС - не панацея.
10 май 05, 01:02    [1526796]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Geo
Member

Откуда:
Сообщений: 6883
"Самое интересное в этом вранье то, что оно вранье от первого до последнего слова" (почти (с))

- Есть ли будущее у файл-сервера?
- Есть. Если верить топику. Но топик пошел дальше: может ли ФС решать задачи КС (1)? И всегда ли КС лучше (2)? А местами даже: КС априоре лучше(3)! И, соответственно наоборот(4).

1. Может, конечно. Доказываю: довольно долго решал. В 1992 году Аэрофлот работал на системе, написанной Микроинформ на основе отечественной СУБД Мастер. Да и вообще об mssql2000 никто еще не слышал.

2. Нет, конечно. Все-таки на клиентах-"трухлявых пнях" с 32 мб озу однопользовательские задачи работают лучше, если они оформлены на ФС. Да и многопользовательские подчас тоже.

3. Нет, конечно. См. в. 2. + туда же: В принципе, большинство задач можно КС можно решить в ФС. Только часть из них гораздо более трудоемко. Пример: sql.ru в виде ФС выглядел бы например, так, как он выглядит при просмотре в новостном клиенте. И весь траффик заключался бы в довольно простой самописной репликации. И полнотекстовый поиск бы медленнее, как правило, но работал всегда.

4. Нет, конечно. Многие задачи гораздо проще и качественнее решаются в КС.

Это все моя имха, конечно. Я с sql-образными системами работаю... около 3-х лет всего. И не знаю гораздо больше, чем знаю.
----------------

2 ЛП
>> Для локации одной записи из миллиона мне, по грубым прикидкам,
>> понадобится не больше 20 чтений из индекса, и одного чтения собственно
>> записи.

Скорее не чтений из индекса и чтения записи, а чтения "страниц индекса" и "страницы, содержащей запись". Но это все-таки не самый частый случай. Чаще записи отбираются по какому-нибудь foreign key и тут уж в любом случае практически или вообще весь индекс едет. (надо, кстати, узнать, что в действительности приезжает из индекса в Access'е, если надо одну запись выбрать по этому индексу).

И хорошо-бы пример со справочником, что ли, все-таки привести, как можно экономить траффик в КС.

>> В этот момент многие начинают думать, что раз такой вопрос задается,
>> значит где-то тут подвох, и, после невнятного мычания, отвечают, что
>> быстрее была наверное однопроцессорная система. Те же, у кого
>> сохранились остатки здравого смысла, говорят что быстрее
>> конечно же четырехпроцессорная, но ненамного, раза в полтора-два.
Cлушай, хоть убей, не помню, что ж я-то ответил. Мне кажется, что "однопроцессорная" :))
10 май 05, 02:05    [1526815]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ЛП

разгребать очередную порцию дибилизма

Вы слишком критично относитесь к коллегам.

ЛП

Скажем так, я не знаю современных СУБД (как ФС, так и КС), которые бы не установились на современный компьютер (из "клиентского", а не "серверного" прайса). И не только бы не установились, а и вполне нормально работали бы, (с учетом того, что обслуживать им придется ровно одного клиента, а не сотни и тысячи).

Скажите об этом Ораклу. Интерпр 9 на ОЗУ 256Мб лезть то лезет, но тот потом больше не летает. Ни о какой рабочей БД там думать не приходится. То же было с 8 на 128Мб. Не прокатило. А Аксцесс летает и 32 МБ.
Меня смущает, что СУБД ФС много тоньше. Может они из комерческих соображений ориентируются на большинство клиентов, а не последний писк. К тому же раз на клиентов, то там должно быть еще много чего кроме них? Иначе какие они клиенты? А сервак претендует на одно занятие быть сервером БД, равно как в ФС - файл - сервером.
ЛП

По п.2 закончим когда-нибудь или нет?

Ну там еще было про распределение вычислений. Не прояснили про Серваки 20 000$ и выше. Вот например HP Integrity Superdome - 64 процессора - это c SQL Server или IBM eServer p5 595 64p - DB2 или IBM eServer p5 595 32p - Oracle. Это я содрал с TPC-C тестов. Они наверное превзойдут клиентов по 1000 баксов. Т.е. выполнят пострее запросы некоторые?

ЛП

Продвинутый диалект SQL, да и "многое другое" - не являются родовыми признаками КС.

Но являются родовым признаком интеллектуальности, который возможно связан с пп2.
Пусть не родовым, но багоприобретенным то признаком КС он является. Пусть так.

ЛП

Давайте сравним "навороченность" диалекта SQL у файл-серверного аксеса - и у какого-нибудь клиент-серверного MySQL, особенно старых версий.

Но это не совсем стыкуется с тем как звучит тема. Мы должны ориентироваться на самых продвинутых - сообразно теме. В мире есть много КС-ов уступающих Аксцессу в некоторых возможностях. Они не реализовали потенциал КС в полной мере. Давайте возьмем слаую РСУБД или ООСУБД и сделаем вывод, что эти модели сами по себе ничего не стоят.

ЛП

В самом начале "сетевой воды" я сказал, что все рассуждения только для локальных сетей. Почему я это второй раз должен повторять?

Но П1 не ограничивается только локальными сетями. Вот отсюда и недопонятка Вашей позиции.

ЛП

Так для N клиентов и Tk должно увеличиваться, потому что все в конечном итоге будут в один винчестер ломиться (через прослойку в виде SQL Server'а). Об этом я тоже сказал.

Хорошо. Тогда и Тf так же увеличится.

ЛП

Если ярко выраженной повторяемости нет - то влияние сетевых накладных расходов невелико.

А если есть? Но это имеет значение для П1? Мы же говорим не о том, что в некотрых случаях П1 не проявляется. Все 3 в некоторых случаях не проявляются. Но дело в том, что полно случаев када проявляются - и это имеет значение в том плане в каком поставлен вопрос темы.

ЛП

Вы про надежность или про сетевой трафик?

Про П1. Через повышение ненадежности при больших объемах - он может тоже усиливать роль П1. Качало качало - пошли сбои.
10 май 05, 02:09    [1526816]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 Geo
Скорее не чтений из индекса и чтения записи, а чтения "страниц индекса" и "страницы, содержащей запись".

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

Чаще записи отбираются по какому-нибудь foreign key и тут уж в любом случае практически или вообще весь индекс едет.

И опять таки - зачем весь индекс? Тебе есть разница - это Foreign Key или Primary Key? Тебе кто-то мешает читать не весь индекс, а только интересующие куски?

И хорошо-бы пример со справочником, что ли, все-таки привести, как можно экономить траффик в КС.

Как заказывали - пример со справочником
https://www.sql.ru/forum/actualthread.aspx?bid=4&tid=49300&pg=1

Cлушай, хоть убей, не помню, что ж я-то ответил. Мне кажется, что "однопроцессорная" :))

Ничего. Я тоже в свое время ответил "четырехпроцессорная, но ненамного"

---------------------------------------------

2 vadiminfo
Вы слишком критично относитесь к коллегам.

Если они гонят полную <censored>

Скажите об этом Ораклу.

Значит это недостаток убогого Оракла. Хотя у меня сильные сомнения в том, что он Оракл не способен в однопользовательском режиме обработать небольшую базку, пусть даже и на 256 мегабайтах ОЗУ. Пусть медленнее, чем специально заточенные под такие конфигурации ФС-системы, но оракл не сдохнет.

Не прояснили про Серваки 20 000$ и выше. Вот например HP Integrity Superdome - 64 процессора - это c SQL Server или IBM eServer p5 595 64p - DB2 или IBM eServer p5 595 32p - Oracle. Это я содрал с TPC-C тестов. Они наверное превзойдут клиентов по 1000 баксов. Т.е. выполнят пострее запросы некоторые?

Я не понял. То ли я плохо говорю, то ли вы плохо слышите. Читайте последнюю страницу еще раз. По возможности - внимательно читайте.

Хорошо. Тогда и Тf так же увеличится.

Да. И суммарно будет уменьшение скорости - в два раза. Драка за сеть + драка за серверный винт.
Т.е. в определенных условиях ФС проигрывает КС проигрывает не более чем в два раза - при любом количестве клиентов. И это не повод для паники. Это не есть линейная или экспоненнциальная зависимость падения скорости от количества клиентов.

Мы же говорим не о том, что в некотрых случаях П1 не проявляется.

А я говорю именно про то, что в некоторых (достаточно частых) случаях П1 - вовсе даже и не является недостатком. Именно поэтому и "условно согласен" с п.1.

Через повышение ненадежности при больших объемах - он может тоже усиливать роль П1. Качало качало - пошли сбои.

В данном случае надежность или ненадежность не зависит от объемов.
Все критичные операции минимизируются про времени (объему). И неважно сколько до этого вы "качали, качали, и пошли сбои".
10 май 05, 02:49    [1526824]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
Что, опять никого нету?
Ну, стал быть я опять всех победил.
Всех с прошедшим Днем Победы!
10 май 05, 07:55    [1526852]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить