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

Откуда: Москва
Сообщений: 11378
ЛП
В случае КС - эти десятки и сотни машин подеруться за винт на сервере (через прослойку в виде SQL-сервера).
В случае ФС - они подеруться и за винт на сервере (через прослойку в виде файл-сервера), и за сеть.
Разница опять таки в два раза (даже меньше, учитывая вышесказанное про последовательный доступ).
Да нехай дерутся, честно говоря, перестал понимать нить обсуждения :) За что боремся, так сказать ? Типа, быстрая "сетка" возвращает ФС на передовые позиции, или где ?
8 май 05, 00:58    [1525439]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 Urri
Нуу... в общем-то да :)
Если "меньшая" часть данных является "наиболее актуальной", то в случае КС читать с диска её не надо, а в случае ФС - читать тоже не надо (закешируется файл-сервером), но пересылать по сети таки придется.

Однако при обработки данных без ярко выраженной "актуальности" - влияние дополнительных сетевых расходов невелико.
Что меня пугает :)
Может всякие там OLAP-системы для немерянных анализов - лучше на ФС делать?

-------------------------------
2 AlexCzech
Я что-то не совсем понимаю, кто и где в ФС-архитектуре кэширует данные ?

Кто, кто... сервер кеширует.
Если речь об ОС, то боюсь она если что и кэширует - то не в тех объемах и не по тем закономерностям, которые нужны для обработки данных... и уж тем более никак не удастся на этот процесс влиять.

Для небольших баз (до нескольких Гб) - да хоть всю базу в память положить, и не нужны никакие закономерности. А ФС вообще то изначально и расчитан на небольшие базы.
8 май 05, 00:58    [1525440]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 vadiminfo
Вы очень невнимательно читаете.

Вы засомневались

Я засомневался? Где?

в тех официальных 3 пунктах недостатков.

Еще раз - ссылку на "официальность" или прекратите пороть чушь.

А я ответил на Ваши сомнения.

Бредом и детским лепетом "офисияльно=общепринято"

Удивляюсь, почему Вы сомневаетесь в пп 1).

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

Вы еще возьмите слабенький комп для сервака КС.
Но как правило факт. Сервер мощнее.

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

СУБД навороченное с продвинутыми оптимизаторами и тучей алгоритмов.

Это не к спору "ФС vs КС". Продвинутый оптимизатор и куча алгоритмов не являются родовыми признаками КС. Та же самая rushmore-оптимизация успешно применяется и в MS SQL Server, и в VFP, и в Access.
Никто не мешает на клиенте (ФС-клиенте) держать продвинутый оптимизатор и тучу алгоритмов. Клиент от этого не сдохнет. Не убеждайте меня в обратном, потому что у меня на домашней машине два скуля крутятся и не пердят. А моя домашняя машина на "навороченный" сервер никак не тянет.

Ну, наверное, лекции курса третьго по специальности ИТ какого-нибудь ВУЗА.

Мои ВУЗ-овские преподаватели приходили ко мне на работу учиться основам баз данных. Я прекрасно знаю уровень "лекций третьего курса". Найдите какой-нибудь другой "офисияльный" источник.

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

По поводу же "СУБД из нескольких dll-ек" - спросите например ASCRUS'а наскольо "тяжелы" решения Sybase для КПК. Замечу - полноценные КС-решения. После этого прекратите пороть чушь о сверхтяжелых серверах.

Насчет транзакций - еще раз. Изоляция (из ACID-требований) <> concurency control и проч. Странно что приходится это объяснять. И "все эти блокировки, многие версии данных" - относятся к транзакциям постольку поскольку.

А что ФС? Аксцесс, например, по моему имеет ограничения.

Все имеют ограничения. Дальше что?
8 май 05, 01:25    [1525448]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
ChA
ЛП
В случае КС - эти десятки и сотни машин подеруться за винт на сервере (через прослойку в виде SQL-сервера).
В случае ФС - они подеруться и за винт на сервере (через прослойку в виде файл-сервера), и за сеть.
Разница опять таки в два раза (даже меньше, учитывая вышесказанное про последовательный доступ).
Да нехай дерутся, честно говоря, перестал понимать нить обсуждения :) За что боремся, так сказать ? Типа, быстрая "сетка" возвращает ФС на передовые позиции, или где ?

Да ни за что не боремся. Пытался для себя понять, насколько же страшен тот самый "ужасный сетевой трафик".
8 май 05, 01:28    [1525451]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11378
ЛП
Пытался для себя понять, насколько же страшен тот самый "ужасный сетевой трафик".
Ааа... Согласен, актуальность упомянутого на гигабите, до некоторой степени, утеряна...
8 май 05, 01:50    [1525457]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
ЛП
2 AlexCzech
Я что-то не совсем понимаю, кто и где в ФС-архитектуре кэширует данные ?

Кто, кто... сервер кеширует.
Если речь об ОС, то боюсь она если что и кэширует - то не в тех объемах и не по тем закономерностям, которые нужны для обработки данных... и уж тем более никак не удастся на этот процесс влиять.

Для небольших баз (до нескольких Гб) - да хоть всю базу в память положить, и не нужны никакие закономерности. А ФС вообще то изначально и расчитан на небольшие базы.


Не понял... какой сервер ? ОС Windows 2003 (или 2000, неважно) Server кэширует у себя в памяти 2 Гигабайтный аксессовский файл ? Это как выглядит вообще ?
8 май 05, 01:55    [1525459]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 AlexCzech
Не понял... какой сервер ? ОС Windows 2003 (или 2000, неважно) Server кэширует у себя в памяти 2 Гигабайтный аксессовский файл ? Это как выглядит вообще ?

Я что-то не понял... Вы видите какие-то принципиально неразрешимые проблемы?
В чем сложности? Если на сервере есть Х гигабайт свободной оперативной памяти - кто мешает закешировать файл размером не больше Х гигабайт?

Если виндузовый файл-сервер не кеширует по умолчанию таким образом (а он таки не кеширует по умолчанию таким образом) - то его можно заставить так делать. Если нельзя заставить - то можно обмануть. Было бы желание.
8 май 05, 02:56    [1525469]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
На самом деле, конечно же, глобальной проблемы тут никакой нет... но есть масса локальных, которые все вместе сливаются в один большой геморрой. И геморрой вызван тем, что файловый кэш - это файловый кэш, а никак не кэш данных. И работает он совершенно по другим законам
8 май 05, 03:23    [1525476]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
ну раз проблем нет - то и чудненько.
а другие законы или не другие законы - мне достаточно параллельно, коли вся база уже в мозгах лежит.
8 май 05, 03:29    [1525477]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

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

Я засомневался? Где?

Ну если Вы не сомневались, тогда просто я не так понял все рассуждения про первичныве ключи и проч сравнения КС и ФС в части, пп1)
А ясного признания не увидел. А ведь Вы сторонник ФС? Вот и подумал, что то все возрважения. Ну или приуменьшение этого недостатка.

Т.е. можно считать этот недостаок ФС признаным?

ЛП

Еще раз - ссылку на "официальность" или прекратите пороть чушь.


Ну по предмету Технолгии БД у меня была 5, а там был подобный вопрос на экзамене. А все это утверждено министерством образования (официальность). Ну во многих толстых книгах встречается этот факт. Потому я и решил, что это общепринятое.
Но если Вы относитесь с подозрением к мин образования и его процедурам утверждения курсов, то тада можете считать, что это все чушь.


ЛП

Бредом и детским лепетом "офисияльно=общепринято"

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

ЛП

В чем я сомневаюсь? В том что ФС больший трафик генерит? Где я в этом сомневаюсь, пальцем ткните???

Тогда почему просто не сказали, что это факт? А Вы ведь, вроде, явно согласились только с 3). При этои комментировали 1). Что тогда это было?
Такая форма признания верности этого пункта?

ЛП

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

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

Не уверен, что 100 клиентов - это вообще приемлемая цифра для многих СУБД ФС.



ЛП

Никто не мешает на клиенте (ФС-клиенте) держать продвинутый оптимизатор и тучу алгоритмов. Клиент от этого не сдохнет.

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

ЛП

Мои ВУЗ-овские преподаватели приходили ко мне на работу учиться основам баз данных. Я прекрасно знаю уровень "лекций третьего курса". Найдите какой-нибудь другой "офисияльный" источник.

Мои были уже достаточно обучены еще до моего прихода. Если Вы научили своих некоторым вещам, то возможно, это преждевременно.


ЛП

По поводу же "СУБД из нескольких dll-ек" - спросите например ASCRUS'а наскольо "тяжелы" решения Sybase для КПК. Замечу - полноценные КС-решения. После этого прекратите пороть чушь о сверхтяжелых серверах.


Возможно и чушь, но туда куда надо. Полноценные КС- решения - как я понимаю - частный случай. А мы то в целом сравниваем. Ну кое где и Досовкие решенния - полноценные ИС для своей задачи.

ЛП

Насчет транзакций - еще раз. Изоляция (из ACID-требований) <> concurency control и проч. Странно что приходится это объяснять. И "все эти блокировки, многие версии данных" - относятся к транзакциям постольку поскольку.

Без изоляции concurency control возможно, для кого-то и представляет интерес, но не могу себе представить кто это может быть. Можно открыть Аксцесс в эксклюзивном режиме. Но это все-таки последовательный доступ. А "все эти блокировки, многие версии данных" если не относятся к транзакциям, то о них можно забыть. Так ни к чему другому они, скорее всего, не относятся даже постольку поскольку. Так их основная задача избежать потеряных обновлений, грязных чтений - в общем, влияния транзакций друг на друга. Ни для чего другого они вроде и не нужны были до сих пор.
8 май 05, 03:45    [1525484]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 vadiminfo
Ну если Вы не сомневались, тогда просто я не так понял все рассуждения про первичныве ключи и проч сравнения КС и ФС в части, пп1)

Вы спросили - "что делать с ... .... большим объемом сетевого трафика"
Ответ был простой - принять во внимание, пытаться минимизировать, средства для этого есть, хоть и применимы не всегда, и эффективность порой недостаточна.
Дальнейший спор - непонятно о чем.

А ясного признания не увидел

А я и не считаю, что сетевой трафик есть глобальное и неоспоримое зло. О чем уже и написал достаточно много.
Это же ответ на вопрос "Т.е. можно считать этот недостаок ФС признаным?"
:)

А ведь Вы сторонник ФС?

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

Ну по предмету Технолгии БД у меня была 5

Поздравляю вас. У меня было всего лишь 3 с минусом, да и то - по хоровому пению.

Не уверен, что 100 клиентов - это вообще приемлемая цифра для многих СУБД ФС.

Вы не уверены, а у меня 150 юзеров на аксесе сидело, активно работало и не жаловалось.
Так что "может перестанем соревноваться в своих незнаниях" (с) ASCRUS

Представьте что может быть на много мощнее - ведь на один мощный сервак можно разориться? Это одно из достоинств КС.

И это же - один из ее недостатков. Избавились от одного узкого места в системе (сеть) - получили другое (умирающий сервак).

СУБД ФС должны стоять на каждом клиенте, а не на самом толстом.

Еще раз повторю. 99% персоналок ("клиентских мест") - уже имеют у себя ФС СУБД под названием MS Jet. И даже не замечают этого. А вы утверждаете что мол оно куда-то там не встанет, дескать клиент недостаточно толстый.
Еще раз повторю, что следующая клиентская ось - будет иметь в себе юкон. А вы утверждаете, что дескать юкон на клиента не влезет. Влезет, и даже вазелин не понадобится.

Еще будем говорить про "супер-толстые сервера"?
8 май 05, 04:26    [1525490]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
AlexCzech
Я что-то не совсем понимаю, кто и где в ФС-архитектуре кэширует данные ? Если речь об ОС, то боюсь она если что и кэширует - то не в тех объемах и не по тем закономерностям, которые нужны для обработки данных... и уж тем более никак не удастся на этот процесс влиять.

А если опять существует какая-то добрая фея, то интересно было бы про это послушать :)


Существует. Клиент кэширует. И Shared Lock вешает на кэшированные страницы(точнее - сначала shared Lock- потом чтение), правда ненадлого. иначе писатели встанут.

По поводу lock за физической границей файла. Novell Netware - тож не возражает против этого. Или всё мастдай кроме *nix?
8 май 05, 09:47    [1525530]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 Alexey Sh
По поводу lock за физической границей файла. Novell Netware - тож не возражает против этого.

Кстати, аксес вроде только поверх майкрософтовских и новеловских сетей работает? Или я неправ?
8 май 05, 10:02    [1525535]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
StalkerS
Member

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

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

вот уж точно детский лепет. Вы что, предлагаете на все клиентские места ставить современные компьютеры ? У нас часть клиентов работают на 133 MHz пнях и 64 МВ оперативки (кажется, даже есть с 32 метрами). Ну давайте, засосите туда по сети гигобайтную таблицу и повертите ее там.
И вообще, как раз более обычная ситуация (во всяком случае у нас), когда одновременно с сервером работают не 100 клиентов, а только 5-10 % от них, соответственно сервер использует все свои ресурсы на их обработку, и это явно быстрее, чем обработка запросов на менее мощных клиентах, даже если они "ненамного более слабые"

Есть такая известная филосовская идея о том, что все в мире движется по спирали. КС весьма напоминает старые мэйнфремы, возможно в будущем опять возратимся и к ФС, но имхо, не сейчас ...
8 май 05, 11:22    [1525563]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
автор
КС весьма напоминает старые мэйнфремы


а почему "напоминает" ? Список отличий - в студию!
8 май 05, 11:32    [1525567]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Некто из дома
Guest
Мать мать мать..... Что тут творится.....

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

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

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


Бред какой-то, полнейший, все-равно что обсуждать, как будут летать танки, если и приделать крылья, причем приводя расчеты обтекаемости танков, величины пропеллера, размах крыла
8 май 05, 11:47    [1525578]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
2 Некто из дома : просто кто-то сказал,что ему в КС -конструкции гигагабайты на клиента нужно гонять, а ему ответили, что с этой задачкой ФС может справиться не хуже
8 май 05, 11:54    [1525583]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
ASCRUS
Раньше я уже видел народ, который ставил SQL = MS. Но чтобы теперь КС = MS - это сильно. Извините, но если Вы кроме MSSQL ничего не видели, то зачем тут рассуждать о недостатках КС ?

Ну почему - же, еще Oracle 8...
8 май 05, 12:00    [1525591]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Диченко
А что тебя не устраивает в репликации MSSQL ? Мне было бы интересно послушать.

Отсутствие гибкости и уверенности на 100%, что проводка прошла - то есть на месте произошло обновление а вот передалось оно или нет - это еще вопрос ответ на который Вы не всегда можете дать однозначно...

Кроме того немного запутанная схема, когда много филиалов и кто-то вышел из синхронизации, а кто-то нет (то есть кому-то надо делать уже snap-shot, а кто-то может продолжать работать)... Все это требует дополнительных накладных расходов и внимания персонала (которому надо платить зарплату)... Кроме того репликация MS SQL server создает мягко говоря большой трафик... Последняя неприятная вещь - требуются на каждый сервер лицензии, что очень дорого...

Альтернатива только одна - делать все проводки в одном месте - то есть доступ через Интернет - ну а в этом случае, что там на "удаленном конце" - ФС или КС в общем-то без разницы и зависит только от пристрастий программиста...
8 май 05, 12:18    [1525598]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Sergey Ch
Последняя неприятная вещь - требуются на каждый сервер лицензии, что очень дорого...

Я плакалЪ
8 май 05, 12:21    [1525600]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
StalkerS
Member

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

а почему "напоминает" ? Список отличий - в студию!

дык типа того, мониторы сейчас графические, сервер размером не с спортзал, в общем много всяких отличий ;)
8 май 05, 12:24    [1525602]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
Alexey Sh
AlexCzech
Я что-то не совсем понимаю, кто и где в ФС-архитектуре кэширует данные ? Если речь об ОС, то боюсь она если что и кэширует - то не в тех объемах и не по тем закономерностям, которые нужны для обработки данных... и уж тем более никак не удастся на этот процесс влиять.

А если опять существует какая-то добрая фея, то интересно было бы про это послушать :)


Существует. Клиент кэширует. И Shared Lock вешает на кэшированные страницы(точнее - сначала shared Lock- потом чтение), правда ненадлого. иначе писатели встанут.


Ну клиенту-то в общем ничего не мешает и в КС-системах данные кэшировать, тока не надо это ему за исключением отдельных частных случаев
8 май 05, 12:26    [1525605]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Alexey Sh
автор
КС весьма напоминает старые мэйнфремы


а почему "напоминает" ? Список отличий - в студию!

В мэйнфреме - передавалось изображение на монитор в одну сторону и информация с клавиатуры в другую...

В КС - обработка идет на толстом клиенте (не важно что это только Browser - все равно это полноценный компьютер)... И передаются данные в обе строны, которые затем интерпретируются клиентской программой в удобный для человека вид...

P.S. Ничего личного, просто мое видения вышеуказанных различий...
8 май 05, 12:27    [1525606]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Alexey Sh
Sergey Ch
Последняя неприятная вещь - требуются на каждый сервер лицензии, что очень дорого...

Я плакалЪ

Я тоже, когда бюджет проекта - кот наплакал, а задачу решать надо...

На мой скромный взгляд все различия можно свести к деньгам, ну а результат для конечного пользователя один
8 май 05, 12:30    [1525608]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 ЛП
Вот нашел в толстой книге, в той же и про те три недостатка (Томас Конноли "Базы данных") про сложность СУБД: "СУБД является весьма сложным видом программного обеспечения, предназначенным для предоставления перечисленных в предыдущем разделе служб". А в предыдущем разделе пречисляются службы предложенные Кодом. Возможно, те кто вообще впервые выдвинул требования к СУБД - группа CODASYL смотрели на это проще.

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

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





ЛП

Вы не уверены, а у меня 150 юзеров на аксесе сидело

Я на аксцеесе97 в одной системе сказал им, что больше 10, то я ни за что не отвечаю. На одной фирме в 1999, где собирались реализовывать решения на Аксцессе, сказали что до 34. Где-то написано.
Правда, недавно и для Ораклового решения када по одному ТЗ потребовали, что нужно еще 100 к тем 16 что были. И хотя у этих 100 довольно простые запросы - я все посчитав, и увидев что вроде им больше 1 Мб не выделяется, написал что компу нужно 1 Гб оперативки, а еще подумав решил перезаложиться и написал, что то был минимум, а лучше 2 Гб. Т.е. я с осторожностью отношусь и КС када это касается реальной ответсвенности. Другое дело - теоретически.

ЛП

И это же - один из ее недостатков. Избавились от одного узкого места в системе (сеть) - получили другое (умирающий сервак).

Вот то, что это недостаток согласится трудно. Вот тоже задача из практики. 30 млн или что-то типа того (забыл точные цифры) заприсей в месяц. Запрос должен отрабатывать 1 сек - он там за месяц, причем любой должет сборать средние значения. Ну там навороченный сервак и используя спец средсва СУБД - секционирование (толщина), я добился требуемого у заказчика - там кластер из двух 4 - процессорных, навороченные диски - шустрые. Но наш сервака 4 пр и хоть и быстрые диски, но помедленее - 5-6 сек отрабатывал. Как этого добиться на ФС? Какие там должны клиенты стоять? Какая сеть должна быть? Что за фичи СУБД должно поддерживать?

ЛП

Еще раз повторю. 99% персоналок ("клиентских мест") - уже имеют у себя ФС СУБД под названием MS Jet. И даже не замечают этого. А вы утверждаете что мол оно куда-то там не встанет, дескать клиент недостаточно толстый.
Еще раз повторю, что следующая клиентская ось - будет иметь в себе юкон. А вы утверждаете, что дескать юкон на клиента не влезет. Влезет, и даже вазелин не понадобится.

Еще будем говорить про "супер-толстые сервера"?

Я про то что ФС не встанет на клиента не говорю - тада ФС пролетела бы раз и на всегда. У них как раз задача встать на любой. И в этом их преимущество для небольших задач. Если бы у них не было никаких преимуществ, они бы давно исчезли. Хотя и КС имеют тонкие редакции.

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

Давайте зафикируем:
Т.е. из тех трех пунктов остался тока пп2, с которым вы совсем не согласны?
С 1 и 3 Вы так или иначе согласны. С учетом, что на практике в отдельных случаях они могут не проявляться. Но есть случае где могут иметь значение.
Причем именно как недостатки в сарвнении, а не для обоих ФС и КС одновременно.
8 май 05, 13:03    [1525611]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить