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

Откуда: Благовещенск
Сообщений: 8894
f_w_p
Но на хрена козе баян? Ведь в КС все это есть. Да и потребности в этом не возникает.

Трудно что-либо на это возразить кроме того, что иногда требуется лишь небольшое дополнение... Например, меня не очень устраивает репликация у MS SQL Server, да и проблем у него очень много с реализацией XML по сравнению тем-же VFP 9.0... Но как я уже писал все это исправляется лекгим движением пальцев рук хорошего программиста во внешнем приложении... Во внешнем? Увы - да... Может в новой версии MS SQL Server это будет получше реализовано, но я пока не ковырялся в бэтте - мне Microsoft за это не будет платить... Так что старый и добрый ФС с элементами КС делает MS SQL Server очень просто и уверенно...

Для меня лично есть еще одна проблема - в искусственном снижении максимального размера таблиц, но как я уже писал ранее - эта проблема тоже обходится, если применить мозги - так система управления Евротуннеля насчитывала объем 200 GB и построена на чистом VFP...

Так что все завист от наших с Вами рук и денег заказчиков
7 май 05, 16:41    [1524934]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Некто из дома
Guest
Так что старый и добрый ФС с элементами КС делает MS SQL Server очень просто и уверенно...

Это кто такой еще, ФС с элементами КС ??????
И как он его, MS SQL, делает? Или про репликацию речь? :)
7 май 05, 19:29    [1525099]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Некто из дома
Это кто такой еще, ФС с элементами КС ??????
И как он его, MS SQL, делает? Или про репликацию речь? :)

- по скрорсти разработки приложений
- по скрорсти работы с данными
- по гибкости в работе с данными
- по оптимизации SQL запросов

Все это есть уже в этом форуме, зачем повторяться

Have a nice weekend!
7 май 05, 19:54    [1525134]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
ЛП
2 AlexCzech
И что же за функции СУБД в RAC лежат на КЛИЕНТЕ ? Или в вашем понимании БД - это файлики на диске, а instance - это так, клиентское приложение

БД - это (грубо говоря) как раз таки файлики на диске. Оракловый Instance - это СУБД
Кто мешает клиенту файл-серверной СУБД являться сервером для КС-системы?
Кто мешает Oracle RAC рассматривать в качесте такого мутанта? Файл-серверный Оракул-Рак, у которого каждый из клиентов-инстансов является... да в общем-то не важно чем он является, хоть бы и чебурашкой. Пункты 2 и 3 "официяльных недостатков ФС (в исполнении vadiminfo)" к Оракулу-Раку вполне применимы :). О чем и сказал Alexey Sh. Будете утверждать, что он был неправ?


У вас сильно упрощенное представление о работе Oracle RAC... вы действительно думаете, что он работает как 5 пользователей Access подсоединенные к одному MDB-файлу ? Это совершенно не так

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


После этого разработчики тяжело вздыхают, цедят сквозь зубы "что ж такое, как не собирай, все равно пулемет получается" и либо делают еще один КС, либо мирно расходятся по домам, оставляя 1-2 гуру на суппорте
7 май 05, 21:03    [1525205]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

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

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

А в том, что эти несколько записей - результат не обязательно выборки по первичному ключу. Есть еще соединения, группировки, значительно более сложные выбороки - по диапазону, по нескоьким полям из множества значений, которые возвратил подзапрос. Иногда лучше полное сканирование таблы, так их можно считывать за раз по несколько блоков и тем самым сократить кол-во чтений по сравнениею со сканированием по индеску. Зависит от запроса. Да и даже куски индекса PK в случае многомилиооных табл - могут быть значительными.
Тут же и 2) прявляется - сервер где запрос выполнялся может быть достаточно мощным, и выполнит навороченный SQL быстрее, чем клиенский комп. Возможно существенно быстрее. Так как само СУБД более интеллектуальное - не из нескольких dll-ек состоит.

ЛП

Чаво? Эта как? Что значат буквосочетания "субд кс .. потянуть на ось.. а то и превзойти"??? На куда тянуть и чем превзойти?
Какие времена ДОС? Вы современные клиентские места видели? И операционные системы на них? И прочий софт?
Причем тут количество разработчиков?

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


ЛП

Повторяю предыдущий вопрос/утверждение. С какого бодуна необходимость наличия СУБД (в простейшем файл-серверном случае это есть несколько dll-ек) считается недостатком ("официальным") ФС?

С того, что официально считается, реальное СУБД достаточно сложный продукт, а не несколько dll-ек.
Даже реализация базового функционала считается сложной задачей.
Возьмем Оракл - версионник, восстановления и все виды защит известные на сегодня, типов объкектов БД свыше 30. Только 7 типов таблиц. Поддержка объектных типов, XML-технолгии, Средства характерных для докуметальных БД (Oracle Text), ГИС(Spatial) и т.д. и т.п. Рапсределенных БД. и проч. Масштабирование горизональное RAC. Ведь мало наращивать аппаратные ресурсы, надо еще, чтобы производительность системы росла более или мненее, а это не так просто добиться.
Различные алгоритмы выполнения запросов. Всякие OLAP и Data Mining.
Создание приложений EJB, CORBA.

Возьмите хоть те 100 000 000. У Оракла есть средства секционирования. Т.е. одна табла разбита на секции. И хотя логически вы работаете с одной таблой, она за счет пропуска ненужных секций, по существу работет к примеру тока с 1000 000.

Это от того, что официально ИС не сводится к нескольким таблам и проге посылающей запросы на выборку.

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

ЛП

Спор "ФС vs КС", строго говоря, даже не относится к РСУБД, не говоря уже о каких-то там транзакциях.

Но "параллельная работа, восстановление и целостность"<> "транзакции".


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


Gluk (Kazan)

Необоснованное утверждение. Почему-то у меня на Oracle (и Delphi) в однеху получается лабать быстрее чем у моего дружбана на Access-е (при том что он им всю жизнь мается). Тут ить все от человека зависит

Может что-то и зависит от человека. Но скорее всего далеко не все. Конечно и от задачи зависит. Может Ваш друг выбирает сложные задачи? Однако, под простатой можно и квалификацию понимать. На аксцессе что-то работающее может сделать вообще не программист и не разработчик БД.
7 май 05, 21:11    [1525211]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
vadiminfo
Без нее мы получим систему принятия решений. Там OLAP - наиболее популярна. Это уже действительно выходит за РСУБД. Но про деятельность ФС в этом направлении не слышал. Так как там сервак совсем может понадобиться крутым. Но Оракл и, думаю, например, MS SQL (оба КС) это поддерживает


Официально MS SQL Server позиционируется как система для OLTP. Для OLAP есть MS SQL OLAP Services - это на самом деле отдельный продукт, который может использовать SQL Server в качестве хранилища, но механизмы обработки, язык запросов и т.п. у него свои. Так что MS несомненно OLAP поддерживает, MS SQL Server по сути нет
7 май 05, 21:16    [1525219]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 AlexCzech
У вас сильно упрощенное представление о работе Oracle RAC

У меня вообще нет никакого представления о работе Оракула-Рака. И оно мне без надобности.
вы действительно думаете, что он работает как 5 пользователей Access подсоединенные к одному MDB-файлу ? Это совершенно не так

Я действительно не думаю.

Я не понял, вы что, действительно несогласны с тем, что пункты 2 и 3 "офисияльных недостатков ФС в исполнении vadiminfo" - применимы к оракулу-раку? Т.е. вы несогласны с тем, что необходимо дополнительные полные копии СУБД устанавливать, а обеспечение параллельности и прочее и прочее - усложняются?
Если же вы против этого не возражаете - то о чем спор вообще.
7 май 05, 21:39    [1525258]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
ЛП
2 AlexCzech
Я не понял, вы что, действительно несогласны с тем, что пункты 2 и 3 "офисияльных недостатков ФС в исполнении vadiminfo" - применимы к оракулу-раку? Т.е. вы несогласны с тем, что необходимо дополнительные полные копии СУБД устанавливать, а обеспечение параллельности и прочее и прочее - усложняются?
Если же вы против этого не возражаете - то о чем спор вообще.


Дополнительные копии СУБД надо устанавливать, и обеспечение параллельности усложняется (для СУБД усложняются, а не для разработчика или администратора, правда)... но только от этого Oracle RAC файл-сервером не становится; кроме того, хочу еще раз заметить, что RAC - это специальное расширение СУБД Oracle, использующееся по мере необходимости для масштабирования системы. Причем Real Application Clusters применяются довольно редко, и еще реже в их использовании действительно есть насущная необходимость, а не желание админа поковырять любопытную фичу
7 май 05, 21:44    [1525266]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 vadiminfo
А в том, что эти несколько записей - результат не обязательно выборки по первичному ключу.
и т.д.

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

Тут же и 2) прявляется - сервер где запрос выполнялся может быть достаточно мощным, и выполнит навороченный SQL быстрее, чем клиенский комп

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

С того, что официально считается, реальное СУБД достаточно сложный продукт, а не несколько dll-ек.

Ссылочку дайте на это "официально считается".
А то вот тут некто Yo!! пытался утверждать, что дескать СУБД не может называться СУБД если у нее нет сбора статистики и cost-based оптимизитора. Был отправлен читать определения.
Вот и вы - или прекращайте выдумывать официальные точки зрения, или найдите мне официальную точку зрения, согласно которой СУБД не может быть реализована в виде нескольких dll-ек.

Транзакции и обеспечивают оперативный параллельный доступ.

Да неужели? Опять за определениями отправить?
Я всю жизнь думал, что транзакции (по своему определению) обеспечивают требования ACID, в коих от многопользовательской работы только требование изоляции. А сама многопользовательская работа - это чуть-чуть больше. Про упомянутое восстановление после сбоев я уж даже не буду вспоминать лишний раз, оно может быть завязано на механизм транзакций, а может и нет.
7 май 05, 22:05    [1525300]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
AlexCzech
Дополнительные копии СУБД надо устанавливать, и обеспечение параллельности усложняется (для СУБД усложняются, а не для разработчика или администратора, правда)... но только от этого Oracle RAC файл-сервером не становится;

А никто и не утверждал, что оракул-рак становится файл-сервером. Утверждалось только то, что "офисияльные недостатки ФС", как оказалось, применимы не только к ФС, но и к великими оракулам-ракам.
7 май 05, 22:09    [1525306]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
vadiminfo
Хотя у Оракла есть формы и JDeveloper, но все равно Вижуалбэйсик, который прямо в той же БД - проще. Тут даже девицы, не понимающие што они делают могут налабать что-то сетевое ФС. (Собственное наблюдение)

Эххх... Сей факт я склонен считать чуть-ли не самым главным недостатком аксеса :)
Такого иногда наваяют, что мама не горюй...
7 май 05, 22:17    [1525315]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Диченка
Member

Откуда: ИТ-Олимп, 58.1-летний супермен
Сообщений: 3989
Sergey Ch
f_w_p
Но на хрена козе баян? Ведь в КС все это есть. Да и потребности в этом не возникает.

Трудно что-либо на это возразить кроме того, что иногда требуется лишь небольшое дополнение... Например, меня не очень устраивает репликация у MS SQL Server, да и проблем у него очень много с реализацией XML по сравнению тем-же VFP 9.0... Но как я уже писал все это исправляется лекгим движением пальцев рук хорошего программиста во внешнем приложении... Во внешнем? Увы - да... Может в новой версии MS SQL Server это будет получше реализовано, но я пока не ковырялся в бэтте - мне Microsoft за это не будет платить... Так что старый и добрый ФС с элементами КС делает MS SQL Server очень просто и уверенно...

Для меня лично есть еще одна проблема - в искусственном снижении максимального размера таблиц, но как я уже писал ранее - эта проблема тоже обходится, если применить мозги - так система управления Евротуннеля насчитывала объем 200 GB и построена на чистом VFP...

Так что все завист от наших с Вами рук и денег заказчиков


А что тебя не устраивает в репликации MSSQL ? Мне было бы интересно послушать.
7 май 05, 22:27    [1525327]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Sergey Ch
Трудно что-либо на это возразить кроме того, что иногда требуется лишь небольшое дополнение... Например, меня не очень устраивает репликация у MS SQL Server, да и проблем у него очень много с реализацией XML по сравнению тем-же VFP 9.0... Но как я уже писал все это исправляется лекгим движением пальцев рук хорошего программиста во внешнем приложении... Во внешнем? Увы - да... Может в новой версии MS SQL Server это будет получше реализовано, но я пока не ковырялся в бэтте - мне Microsoft за это не будет платить... Так что старый и добрый ФС с элементами КС делает MS SQL Server очень просто и уверенно...

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

Sergey Ch
Некто из дома
Это кто такой еще, ФС с элементами КС ??????
И как он его, MS SQL, делает? Или про репликацию речь? :)

- по скрорсти разработки приложений
- по скрорсти работы с данными
- по гибкости в работе с данными
- по оптимизации SQL запросов

Все это есть уже в этом форуме, зачем повторяться

Have a nice weekend!

Ну конечно - если человек знает на отлично ФС и плохо себе представляет КС, то однозначно для него эти пункты будут актуальны. Кто бы сомневался. А я вот могу утверждать, что в связке ASA+PB могу сделать любого ФС-ника, причем в моем приложении будет куча всего, что в ФС системах будет требовать дополнительного времени и ресурсов на создание аналогов (причем примитивных). Я вот удивляюсь - если руки в КС кривые, значит мы оправдываем тем, что ФС лучше, если кроме MSSQL ничего не видели, значит КС многово не умеет (это кстати и к некоторым Ораклистам относится, которые думают, что если чего то в Оракле нет, значит этого нигде нет).

P.S. Может перестанем соревноваться в своих "незнаниях" и вместо того, чтобы говорить о недостатках того, с чем не работали, будем лучше сравнивать достоинства того, что знаем ?
7 май 05, 22:35    [1525339]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
ЛП
AlexCzech
Дополнительные копии СУБД надо устанавливать, и обеспечение параллельности усложняется (для СУБД усложняются, а не для разработчика или администратора, правда)... но только от этого Oracle RAC файл-сервером не становится;

А никто и не утверждал, что оракул-рак становится файл-сервером. Утверждалось только то, что "офисияльные недостатки ФС", как оказалось, применимы не только к ФС, но и к великими оракулам-ракам.


А, ну дык это понятно. Но при определенных обстоятельствах приходится на это идти
7 май 05, 22:53    [1525354]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
хм... я вот тут подумал...

Вот все говорят - сетевой трафик, сетевой трафик...

По скорости прикинул, да по деньгам... Гигабитный эзернет уже никого не пугает, да и цены на оборудование уже не заоблачные...
Так вот, гигабитный эзернет имеет пропускную способность, как нетрудно догадаться, гигабит в секунду. Обычный сказёвый винт дает устоявшуюся скорость передачи данных - до 100 мегабайт в секунду.
Спрашивается - или я чего-то не понимаю, или локальные сети уже быстрее жестких дисков? И если быстрее, то чего все так боятся сетевого трафика? Он что, платный что-ли?

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

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

З.Ы. Все рассуждения, разумеется, для локальный сетей.
7 май 05, 23:47    [1525380]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
ЛП
Вот все говорят - сетевой трафик, сетевой трафик...
По скорости прикинул, да по деньгам... Гигабитный эзернет уже никого не пугает, да и цены на оборудование уже не заоблачные...
Так вот, гигабитный эзернет имеет пропускную способность, как нетрудно догадаться, гигабит в секунду. Обычный сказёвый винт дает устоявшуюся скорость передачи данных - до 100 мегабайт в секунду.
Спрашивается - или я чего-то не понимаю, или локальные сети уже быстрее жестких дисков? И если быстрее, то чего все так боятся сетевого трафика? Он что, платный что-ли?
Подтверждаю!
В 100 МБитной сети имел доступ к таблице на ФС Novell (из хорошего железа) быстрее, чем к такой же таблице, расположенной на собственном локальном винте, в от полутора до нескольких раз (!), даже при том условии, что эту же сетевую таблицу одновременно со мной держали до 40 пользователей (ну и читали-писали ее, соответственно, хотя бы несколько из них).
Но это в локальных сетях. А вот по модему с ФС работать, конечно, очень тяжело будет.
8 май 05, 00:03    [1525393]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
AlexCzech
Member

Откуда:
Сообщений: 729
Вообще-то в клиент-серверной системе, находящейся в "горячем" состоянии, т.е. с запущенным не 5 минут назад сервером, показатель cache hit ratio должен быть обычно никак не меньше 90% - соответственно, сравнивать скорость сети надо все-таки не с диском, а с оперативной памятью
8 май 05, 00:08    [1525397]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
ЛП
Скажем если сравнить скорость работы с оперативной памятью и скорость рандомного доступа к диску - то разница будет на несколько порядков. Стал быть надо минимизировать обращение к диску.
Что нормальные ФС (скажем, тот же Novell) прекрасно делают. Говорят, и Windows тоже хорошо справляется - не знаю, не пробовал. Вот Samba пробовал. На неизмеримо более крутом железе работала раза в 4-8 медленнее Novell'а. Впрочем, может, просто настройщики Samba хреновые попались?
8 май 05, 00:08    [1525398]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
AlexCzech
Вообще-то в клиент-серверной системе, находящейся в "горячем" состоянии, т.е. с запущенным не 5 минут назад сервером, показатель cache hit ratio должен быть обычно никак не меньше 90% - соответственно, сравнивать скорость сети надо все-таки не с диском, а с оперативной памятью

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

Есть у вас база на 20 гигов, и сервак с оперативкой 2 гига. Как вы собираетесь обеспечить тот самый cache hit ratio не меньше 90%?

Пусть нам из 20 гигов данных надо обработать гиг информации, и выдать одну запись.
В случае КС - придется прочитать с диска этот гиг
В случае ФС - придется и прочитать с диска, и переслать этот гиг на клиента.
Но это разница всего в два раза (из предположения равной пропускной способности дисков и сети).
Если бы сеть была медленне в 100 или 1000 раз, тогда совсем другой коленкор канешна, и лишнего трафика надо было бы бояться как огня.
8 май 05, 00:24    [1525410]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
AlexCzech
Вообще-то в клиент-серверной системе, находящейся в "горячем" состоянии, т.е. с запущенным не 5 минут назад сервером, показатель cache hit ratio должен быть обычно никак не меньше 90% - соответственно, сравнивать скорость сети надо все-таки не с диском, а с оперативной памятью
И в ФС - тоже ;-) Об этом cache hit ratio я и пытался сказать ;-)

В идеале, дергать диски надо только когда в таблицы что-то пишется. И то не каждый раз. Древнийпример:
В досе, когда памяти стали в компьютеры ставить по 8 Мб или больше, я начал делать виртуальный диск размером 2 Мб, куда кешировал необходимые для работы формы в приложении данные. И не обращался больше к диску (ни локальному, ни серверному), пока не надо было сохранить изменения. Причем сохранялось все либо непосредственно по закрытии формы, либо по особому желанию пользователя (кнопка "Сохранить"). Эх, как все летало! Сейчас так не летает, хотя памяти давно уже не 8 Мб, да и память побыстрее стала ;-)))
8 май 05, 00:26    [1525412]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11373
ЛП
Так вот, гигабитный эзернет имеет пропускную способность, как нетрудно догадаться, гигабит в секунду. Обычный сказёвый винт дает устоявшуюся скорость передачи данных - до 100 мегабайт в секунду.
Спрашивается - или я чего-то не понимаю, или локальные сети уже быстрее жестких дисков?
Вообще-то, цифры достаточно близкие друг к другу, так что если и быстрее, то ненамного....

ЛП
А сетью что? Если пропускная способность сети на уровне дисковой подсистемы, то почему боимся лишний раз в сеть стукнуться?

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

ЛП
Все рассуждения, разумеется, для локальный сетей.
IPv6 тоже впечатляет.
8 май 05, 00:31    [1525416]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
ChA
Вообще-то, цифры достаточно близкие друг к другу, так что если и быстрее, то ненамного....

эээ... совершеннейший нефакт что ненамного. учитывая что
ChA
такая скорость дисковой подсистемы достижима только при чтении потока, при случайном доступе никаких 100 мегабайт не будет.


Что же до "десятков, а то и сотен машин"... Ну предположим есть десятки и сотни машин.
В случае КС - эти десятки и сотни машин подеруться за винт на сервере (через прослойку в виде SQL-сервера).
В случае ФС - они подеруться и за винт на сервере (через прослойку в виде файл-сервера), и за сеть.
Разница опять таки в два раза (даже меньше, учитывая вышесказанное про последовательный доступ).
8 май 05, 00:41    [1525422]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
Впрочем, мой пример - не совсем о cache hit ratio. ;-)))

ЛП
Есть у вас база на 20 гигов, и сервак с оперативкой 2 гига. Как вы собираетесь обеспечить тот самый cache hit ratio не меньше 90%?
Ну, это просто ;-) Есть популярные запросы и менее популярные. Соотношение их друг к другу можно принять даже не за 80%/20%, а за все 90%/10%.

Т.е.: 90% самой запрашиваемой информации хранится в 10% таблиц. Вот эти 10% и будут закэшированы, при этом cache hit ratio будет не меньше 90%.

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

Плюс правило особое для FoxPro: здесь индексы - отдельные файлы. Оптимизация у нормальных архитектурно проработанных систем идет по индексам. Ну так и закэшируются прежде всего индексы. Файл-сервер сам знает, что у него должно быть закэшировано. И механизм, AFAIK, самый примитивный - вытеснение наиболее редко используемого.
8 май 05, 00:45    [1525424]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
AlexCzech
Member

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

А если опять существует какая-то добрая фея, то интересно было бы про это послушать :)
8 май 05, 00:53    [1525434]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

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

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

Вы засомневались в тех официальных 3 пунктах недостатков. А я ответил на Ваши сомнения.
Удивляюсь, почему Вы сомневаетесь в пп 1). Одно дело выполнить на КС вызов ХП по сети идет call fn на сервер от клиента. Там на сервере (мощном) ф-я ХП выполняет запрос к 100 000 000, который должен прочитать с диска несколько ГБ. И обратно возвращает по сети 5 записей. По сети call обратно 5 записей - весь трафик.
ФС должен притащить к себе эти несколько ГБ. И потом на маленьком компе мучаться выполнять запрос. Еще периодически записывая это на свой медленный по сравнению с серверным диском и опять оттуда, читая.
В чем тут убеждать нужно?

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

ЛП

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

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

ЛП

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

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

ЛП

в коих от многопользовательской работы только требование изоляции

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


ЛП

Файл-серверный Оракул-Рак, у которого каждый из клиентов-инстансов является... да в общем-то не важно чем он является, хоть бы и чебурашкой.

Очень даже важно чем. Многие производители стремятся иметь тоже. Горизонтальное масштабирование. Из двух компов собрали один с общими дисками. Реально использовать возможности такой системы не так просто. Да еще, это было прозрачно для админа - больших отличий от работы на одном компе в управлении не было. А это дешевле чем вертикальное - одного более мощного сервака, чем эти двое.
Конечно в ФС мало что даст кластерный файл сервер. Это важно где СУБД. А клиеты кластерами не бывают. Их наоброт стремятся иметь потоньше.
8 май 05, 00:56    [1525437]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить