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

>На CACHE больше свободы в представлении и обработке данных - ну например некоторые вычисления я могу сделать уже заранее во время ввода и записать в глобали в удобной для меня форме тем самым экономится время для создания многочисленных отчетов (своеобразный OLAP).

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

А на ORACLE я вообще могу наделать MATERIALIZED VIEW с нужным представлением информации для отчётов

Так что, насчёт свободы в представлении и обработке - неубедительно.
11 сен 03, 11:38    [334663]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Summary table
Guest
MATERIALIZED VIEW есть и в DB2, толко это называется Summary table
11 сен 03, 11:53    [334712]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
BVV
Guest
...а переиндесацией заниматься не надоело? А у нас этой проблемы нет.
Вот когда 300 таблиц завяжете в "гениальном" IB или необъятном ORACL`e, вот тогда почуствуете кайф от перехода на CACHE.
...ну как вам объяснить, что хранение данных в плоскости менее удобно чем в объеме? Вот вы говорите, что будите решать, что выгоднее хранить доп. инфу, а так вот у нас инфа хранится более компактно и в этом тоже приемущество по скорости доступа. Вот вам еще один, как вы просили, маленький пример:
http://www.informservice.ru/~alex/
11 сен 03, 13:03    [334894]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
BVV
Guest
Есть и такие мнения (MUK):

С тоской вспоминаю свою почти 20-летнию работу с M-технологией,
где основное достоинство было в том, что можно было с не слишком квалифицированной и многочисленной командой создать инструмент генерации приложений для определенного класса ИПС задач, быстро создавать прототипы и доводить их до ума на протяжении всего периода их существования. Основным недостатком создаваемых продуктов - была их чрезвычайная живучесть. Вытравливались они с огромным трудом и их пользователи всегда недоумевали, почему на новых на два порядка более мощных компьютерах всё еле ползает, бесконечно ломается, требует особой внимательности, хотя старые системы работали как холодильники, у которых есть только одна клавиша управления - включение/выключение.
Кстати, проблема копирования информации решалась симметричной репликацией данных во многоуровневой иерархии серверов. Такое было возможно, так как изначально вся база данных распределялась по серверам на части, где могли обрабатываться одновременно только разные записи. Транзакции отсутствовали вообще. Есть много задач, где от них больше вреда, чем пользы. Сейчас я мучаюсь с ORACLE, как DBA. От SQL я sick.
Когда наблюдаешь как отчет по 150 записям на 2-х процессорном монстре с 2 Гb RAM считается полчаса и выдающиеся разработчики этого чуда ничего толком не могут объяснить, хочется зарезать человечка. Когда читаешь в присылаемом мне на дом бесплатно журнале ORACLE, что для того, чтобы правильно прибить 500 индексов в схеме и не получить невразумительное сообщение, надо понимать, что в цикл нельзя вставлять команды типа DROP и COMMIT, а то не дай бог не хватит места для накопления отката, становится страшно. Меня тошнит не только от SQL, но и от всего этого программизма с этими "прогами", "фитчами" и прочей дребеденью.
11 сен 03, 13:14    [334920]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Специалист
Guest
У CACHE есть преимущества, есть и недостатки.

Главное преимущество к одним и тем же данным можно обратиться 3-мя способами - объекты, SQL и напрямую (внутренний язык COS). Т.е. можно в критических участках использовать прямой доступ, а в остальных использовать SQL. Это в приниципе хорошо, но это настолько усложняет разработку и сопровождение (пару-тройку join заменит большая портянка на COS), что выбор варианта прямого доступа должен быть СИЛЬНО аргументирован.
Главный недостаток: отсутствие многих "фич" (репликация, оптимизатор/просмотр плана запросов), что называется "из коробки" (вам конечно расскажут при покупке, что реализовать это в Cache можно за 5 минут (дней/месяцев)) - но это напрягает.
Отсутствие родного OLE DB провайдера, нормальных компонентов для разработки клиентов - первый приличный с точки зрения читаемости C++ binding появился только в последней версии, для Delphi все равно ничего нет до сих пор.
По скорости (если сравнить с MS SQL):
COS - намного быстрее, НО см. выше
SQL - сопоставимо на SELECT, на INSERT - быстрее
объекты - намного медленнее

Вообще, объекты в Cache странная штука: говорят, что можно на них моделировать реальные объекты, только вот языка азпросов к этим объектам нет - только SQL. Соответственно, в объекте более одного уровня вложенности делать нельзя (да и тот кривой - с ограничением кол-ва элементов в списке) - данные потом будешь читать "руками". А если так - то зачем их использовать? Один уровень вложенности можно реализовать и на 2-х таблицах - все и так понятно. Тем более, что сами IS в своих примерах используют relationship, что АБСОЛЮТНО эквивалентно двум таблицам с FK.

НО если понадобится сделать критичную к времени систему (биллинг в реальном времени) и реляционки уже не потянут - на Cache будет запас прочности, если использовать COS. Будет сложно, но это лучше, чем писать собственную СУБД.
11 сен 03, 13:15    [334926]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Zaxx
Guest
2 BVV

>...а переиндесацией заниматься не надоело? А у нас этой проблемы нет.
А у кого это проблема есть ???? Или вы про foxpro c dbf-ами ???

>Вот когда 300 таблиц завяжете в "гениальном" IB или необъятном ORACL`e, вот тогда почуствуете кайф от перехода на CACHE.

Ну у меня их в текущем приложении (на Oracle) 680 штук, и что ? В чём кайф-то от перехода ?

>..ну как вам объяснить, что хранение данных в плоскости менее удобно чем в объеме?

Попробуте , раз вы это утвеждаете..

>а так вот у нас инфа хранится более компактно и в этом тоже приемущество по скорости доступа.

Как оно может храниться более компактно ??? Что string(200) умещается в 4-х байтах ?

>Когда наблюдаешь как отчет по 150 записям на 2-х процессорном монстре с 2 Гb RAM считается полчаса и выдающиеся разработчики этого чуда ничего толком не могут объяснить.

С кривыми-то руками можно ещё не то написать.

>Когда читаешь в присылаемом мне на дом бесплатно журнале ORACLE, что для того, чтобы правильно прибить 500 индексов в схеме и не получить невразумительное сообщение, надо понимать, что в цикл нельзя вставлять команды типа DROP и COMMIT, а то не дай бог не хватит места для накопления отката, становится страшно.

А вот судя по этой фразе , вы знаете об Oracle только по этому журналу. И то что вы "мучаетесь с ORACLE, как DBA" неудивительно. И дальнейшие ваши наезды типа "oracle отстой и вас тошнит от SQL" безпредметны, ибо вы не просто понимаете о чём говорите: drop (как и все DDL команды в Oracle) вообще не использует сегменты отката, а при COMMIT они освобождаются.
11 сен 03, 13:41    [335009]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
>>..ну как вам объяснить, что хранение данных в плоскости менее удобно чем в объеме?

>Попробуте , раз вы это утвеждаете..

Присоединяюсь к просьбе, вельми понеже.... :)
11 сен 03, 14:47    [335178]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Alexander_Chepack
Member

Откуда: London
Сообщений: 22649
А я вообще не понимаю - как можно всерьез доказывать что продукт, практически никому неизвестный (CACHE), лучше, чем продукты, которыми весь мир пользуется. Если они такие хорошие и умные - то отчего такие бедные? Бредовая какая-то дискуссия - столько сил и времени тратится на обсуждение явно маргинального (с точки зрения рынка) продукта.

А про отчет из 150 записей и пол-часа - гнать надо таких разработчиков и таких DBA'ев и вообще - зачем мучиться-то, не нравится работать DBA'ем - смени работу. А то он, блин, мучится, а пользователи, скорее всего или матеряться или плачут.

300 - таблиц - это сила :)) В SAP, например, больше 11 000 таблиц - работает и на Oracle, и на SQL Server.
11 сен 03, 15:29    [335282]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33188
Блог
Уважаемый BVV, я не являюсь сторонником травли толпой одного человека, поэтому не воспринимайте пожалуйста мои вопросы как нападки на Вас. Но мне просто не понятны некоторые вещи. Вы рассказываете о потрясающей живучести того, что не использует транзакции. Объясните пожалуйста, когда Вы делаете бэкап, Вы выгоняете пользователей из системы? Если вы делали бэкап непосредственно во время работы пользователей, то каким образом гарантируется непротиворечивость информации в этом бэкапе, если часть операций производится НЕ в транзакции?
Чтобы было уж совесм понятно, о чем я спрашиваю. База данных, как правило, занимает немалые размеры, и на бэкап БД требуется существенное время. За это время содержимое базы данных может многократно измениться в результате того, что пользователи что-то модифицируют, добавляют и удаляют. Объясните пожалуйста, каким образом при отсутствии транзакций можно выполнить бэкап, будучи уверенным, что в него записалось содержимое базы данных на один момент времени и не случилось так, что отдельные фрагменты этого бэкапа содержат отрывки базы данных, зафиксированные на разные моменты времени и, следовательно, логически между собой не согласующиеся. Это первый вопрос.

Второй вопрос как раз про скорость и SQL-запросы. Вы пытались запустить описанный выше тест просчета счастливых билетиков? В общем-то тривиальнейший SQL-запрос, который "в уме" должен сотворить 6 циклов в цикле для того, чтобы выполнить многократный авто-join одной и той же таблицы, содержащей всего 10 записей, с самой собой. Почему-то 6 циклов в цикле, которые строит MS SQL и в ORACLE отрабатывают в несколько раз быстрей, чем в Cache? Откуда взялся тезис о бешенном быстродействии Cache? Когда я задаю вопрос про этот тест, мне начинают говорить, что нужно САМОМУ ВРУЧНУЮ написать шесть циклов в цикле, тогда будет работать быстро. Ок, но это ведь нечестное сравнение, разве не так? Если нельзя доверить Cache построение шести циклов в цикле (а MS SQL и Oracle можно), то давайте будем сравнивать с теми продуктами, в которых действительно циклы в цикле нужно писать вручную. Я верно рассуждаю? Прямой доступ к данным? Ок, давай возьмем самый обыкновенный Си, откроем в нем бинарный файл и на низком уровне будем читать байты из этого файла, построив шесть циклов в цикле. Прямой доступ к данным? Прямой, прямее некуда. В этой ситуации Си опять окажется по быстродействию в выигрыше по сравнению с Cache. У меня создалось ощущение, что более высокое быстродействие, которое достигается стратегией более низкоуровневого программирования, разработчики Cache выдают за достижение. Но низкоуровнеове программирование - это не шаг вперед - это шаг назад, когда речь идет о разработке КИС. Разработчик КИС должен думать о предметной области, о бизнес-процессах, а не о том, сколько циклов друг в друга нужно вложить, разве не так? По моим выкладкам получается Cache тормознее большинства других продуктов, когда сравнение производится не килограммов с национальной принадлежностью, а сопоставимых вещей. Конечно, он может показать более высокое быстродействие, чем X-Base подобные вещи. Но X-Base-продукты умерли несколько лет назад, по крайней мере в том виде, когда в них строились циклы перебора записей. Сейчас в том же FoxPro все преимущественно построено на SQL-запросах, а не на циклах перебора. Или требуется признать, что переборка записей в цикле в Cache работает быстрее, чем в DBase III? Лично я это признал. Именно отсюда вытекает тезис о сумасшедшем быстродействии? Разве корректо проводить сравнение с древними технологиями DBase (Clipper, Fox etc)? Мне говорят, что я не прав. Может быть, ты объяснишь, в чем именно, если не трудно?

Третий вопрос о репликации. Когда я произношу слово "репликация", то апологеты Cache тут же начинают рассказывать о распределенных базах данных. Но распределенная БД к репликации имеет весьма отдаленное отношение. В MS SQL тоже можно прилинковать к одной БД несколько БД, находящихся на других серверах (и территориально находящихся где угодно), а затем обращаться с SQL-запросами к содержимому ВСЕХ серверов так, словно оно находится в одной БД. Это и есть реализация идеи распределенных БД, но это еще не репликация. В чем же отличие? В том, что при распределении БД основная задача рассовать РАЗНЫЕ данные по разным серверам (местам наиболее частого их использования) и хранить их в одном экземпляре. Репликация же решает противоположную задачу - организацию дублирования одной и той же информации на нескольких серверах. Репликация в MS SQL подразумевает наличие центра управления информационным обменом межу разными серверами, которых может быть гораздо больше двух, и могут быть они разноплановые (можно связать MS SQL, Oracle и MS Access, к примеру). Дублирование информации приводит к тому, что для получения информации не требуется каждый раз обращаться к удаленному серверу, связь с которым может быть ненадежной, медленной и дорогостоящей. На каждом сервере может иметься своя копия одной и той же информации. Для уменьшения трафика обычно между серверами передаются только изменения, которые произошли с момента последнего сеанса связи. Имеется несколько совершенно разных механизмов репликации, каждый из которых ориентирован на определенный набор условий. Одни виды репликации ориентированы на высокую оперативность обмена информацией между серверами и предполагают наличие между ними постоянных соединений. Другие могут использовать периодические или эпизодические сеансы связи (например, копирование данных с ноутбука командировочного или агента). Механизмы репликации могут задействовать различный транспорт - прямую связь серверов друг с другом, службы очередй (MSMQ), или даже тупое копирование на диски (дискеты) с механической их транспортировкой. Базы данных на разных серверах могут иметь разную структуру данных, и при передаче с одного сервера на другой может потребоваться преобразование не только физических (Oracle - MS SQL), но и логических форматов (например преобразование одного поля "Фамилия Имя и Отчество" в три отдельных поля, или преобразование поля "Дата рождения" в поле "Возраст"). Центр репликации производит все нужные преобразования. И самое главное, он отслеживает, какие данные в каком сеансе были откуда и куда переданы, чтобы при следующем сеансе связи "знать", что откуда куда нужно передавать, а что не нужно. Репликация - это очень обширная тема. Просто вкратце - есть методы однонаправленной и двусторонней репликации. По инициации обмена информации есть Pull и Push-обмен (выталкивание и вытягивание). Есть синхронные методы репликации, есть асинхронные. При асинхронном обмене могут возникать конфликты репликации (например, на двух разных серверах между сеансами связи модифицировали одну и ту же иформацию, но по-разному), а также имеется тьма схем разрешения конфликтов репликации. Самая востребованная (ИМХО!) в MS SQL - это репликация слиянием. Она позволяет производить обмен информацией асинхронно и двунаправленно и имеет несколько схем разрешения конфликтов репликации. Ничего подобного я не обнаружил в Cache. Может быть, плохо искал?

Нет, я в курсе, что дублирование информации в Cache организовать можно. Но только при наличии постоянных высокоскоростных и надежных соединений между серверами и только в одном направлении. При этом сказано, что при подобном дублировании НЕ ЗАДЕЙСТВУЕТСЯ двуступенчатая фиксация транзакций. По этому поводу куча предупреждений, даже угроз, исходя из которых лично я сделал вывод, что использовать этот механизм на практике фактически НЕЛЬЗЯ. Потому что если внезапно порвется связь между парой-тройкой серверов (из двух десятков), то информация на всех серверах рассогласуется и для того, чтобы вернуть ее в состояние "статус кво", придется их останавливать месяцев на несколько и разбираться, что откуда и куда должно передаться, чтобы ничего не потерялось и не задвоилось. Ответьте пожалуйста, как знающий человек, что я понял правильно, а что нет.
11 сен 03, 17:27    [335543]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
BVV
Guest
... ну что Вы, какая травля. Мы же в России - это просто спор:)

Чтобы узнать о механизме транзакций и LOCK`ов надо почитать инструкцию. Она совсем не сложная, но по английски.

... окончательное мнение о мощности CACHE сформируется у меня когда я закончу первую часть тестов, хотя сложно тестировать без доступа по локалке - у меня только однопользовательская версия 5.02. Поэтому приходится идти на разные ухищрения типа серверного адаптора и т.д.
...я привел чужое мнение (в скобках ник) поскольку на ORACL`е ничего серьезного не писал.

>Как оно может храниться более компактно ??? Что string(200) умещается в 4-х байтах ?
...данные хранятся в глобалях - разряженных многомерных массивах. Можно так измудриться, что доступ будет очень быстрый, а места эти данные будут занимать меньше чем например в DBF - поле текстовое организовали, но пока не заполнили и стоят ваши 200 пустых мест, а файл занимает на 200 байт больше чем анологичная инфа в CACHЕ. И это еще не все там еще архиватор можно припаять по крайней мере классы системные такие есть. Может я каверзно объяснил. Я вообщем не писатель. См. инструкцию или почитайте на news.intersys.com. Там на все вопросы отвечают сами разработчики.

На http://www.informx.ru есть инструкция по администрированию на русском.

Вообще данные можно хранить по разному - можно назначить сколько хотите стратегий хранения - деревьев, плоских SQL-таблиц или ввиде причудливых объединений. К КОТОРЫМ МОЖНО ОБРАТИТЬСЯ КАК К ОБЪЕКТАМ! Ну не упирайтесь - это же круто! Берешь к примеру объект, который в свою очередь является свойством в горе других объектов да еще и является к тому же и обстрактным и меняешь ему какую нибудь лабуду в результате гора объектов получает товые свойства и даже методы или реакции на события в том числе и события системные. А слабо вам через IE просто строить свою систему на сервере с нуля?

...не известная это не значит плохая...
11 сен 03, 22:23    [335840]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
BVV
Guest
...вспомнил что хотел написать еще. А еще вот что:
допустим Вы работаете в сетке и в бухгалтерии чаще требуется одна инфа, а в отделе продаж - другая. Под инфой я понимаю сейчас неких фрагмент сплетения кучки объектов - что то отчего то зависит и над чем то нависает.
Так вот CACHE сама в течении работы накапливает статистику по трафику по сети и распределяет данные так, чтобы трафик по сетке был минимален. То есть работает по принципу адаптивной нейронной сети. Я этот тест еще не проводил и вряд ли проведу - CACHE надо сначало купить, а начальство ...
11 сен 03, 22:32    [335845]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
BVV
Guest
Вот еще адресок для ищущих:
ftp://ftp.intersystems.com/pub/cache/
11 сен 03, 22:39    [335847]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
--...данные хранятся в глобалях - разряженных многомерных массивах. Можно так измудриться, что доступ будет очень быстрый, а места эти данные будут занимать меньше чем например в DBF

Только не надо смешивать DBF и MSSQL, Oracle и иже с ними

ну и пример. поле text в MS SQL 16 байт на ссылку. А уж хранить там можно что угодно. Я например XML документы храню - чем не разряженный массив.
Деревья опупительных размеров. В общем-то у меня это скелетон для юзеровских данных.
Сколько есть данных в нем - столько и занимает.
12 сен 03, 03:33    [335915]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Zaxx
Guest
2 BVV

>...я привел чужое мнение (в скобках ник) поскольку на ORACL`е ничего серьезного не писал.

Тогда извините за резкость в предыдущем моём посте, но вы процитировали откровенную глупость. И не надо тогда сравнивать CACHE с теми СУБД, на которых вы не работали.

>данные будут занимать меньше чем, например в DBF

Опять DBF...Мы CACHE с DBF сравниваем?

>И это еще не все там еще архиватор можно припаять.

Архиватор много куда можно припаять, но это совсем другая песня.

>См. инструкцию или почитайте на news.intersys.com.
>На http://www.informx.ru есть инструкция по администрированию на русском.

Что же вы народ то посылаете всё время на intersys? Люди читают этот форум, что бы получить грамотное и аргументированное объяснение преимуществ и недостатков разных СУБД от специалистов, которые их применяют.
Вы же можете сами аргументированно обосновать преимущество CACHE над всеми остальными СУБД?

>Так вот CACHE сама в течении работы накапливает статистику по трафику по сети и распределяет данные так, чтобы трафик по сетке был минимален.

Как это "накапливает статистику по трафику по сети"? Трафик, который создаёт CACHE или вообще трафик по всей сети?

Как это "распределяет данные"??? По времени, что ли размазывает? Типа медленнее их выдавать начинает, чтобы сетку не грузить??? А смысл? Если сеть тормозит то какая разница: клиент будет получать результат медленнее из-за сети или из-за того, что СУБД будет результат придерживать?
Вообще в клиент-серверных системах обычно проблема загрузки сети остро не стоит (кроме случаев с медленной сетью или огромным количеством клиентов).
Что-то это похоже на маркетинговые измочки некоторых не самых передовых производителей: если привлечь клиента нечем, то можно сделать "БИОТЕЛЕВИЗОР"!!!
12 сен 03, 08:46    [336021]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Эх Garya, не на том языке ты с BVV разговариваешь! Ты ему скока понаписал, а он как тебе классно ответил:
Ну не упирайтесь - это же круто!
И попробуй опровергни!


Мне лично хочется ответить словами классика:
     -  Вы стоите  на самой  низшей ступени  развития,  -  перекричал Филипп

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

Михаил Булгаков. Собачье сердце
12 сен 03, 10:16    [336183]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
И все же очень хочется услыщать что-нить про хранение данных в "объеме" и про то, как это соотноситься с их объектной организацией...

>>..ну как вам объяснить, что хранение данных в плоскости менее удобно чем в объеме?
12 сен 03, 11:40    [336409]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
jvv
Member

Откуда:
Сообщений: 43
А вот такая цитата (из соседнего форума) не может ли как то объяснить причины непонимания друг друга сторонников и противников Cache?

...Я как-то у народа спросил: "а почему все так усиленно стараются поддерживать доллар? Неужели все кругом дураки и не видят очевидного?" Оказалось, что все всё видят, но доллар будут стараться держать до последнего, зачастую даже в ущерб себе. Почему объяснять?...
12 сен 03, 12:59    [336650]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
BVV
Guest
...ладно, ладно не буду говорить о СУБД в которых не работал. SQL люблю и уважаю :) Теперь надеюсь ицидент исчерпан.:)
...что то не понял - почему вам форум то спецов не нравится?
...про объем будет - вы своими спорами сподвигли меня на тесты. Для этого мне надо перенести 360 Мег данных из Interbase, этого пока не удается (хотя ошибок тоже не сообщает). Надеюсь это не защитная фишка создателей.
За класику спасибо. Правда я так понял, что самая подходящая фраза для нашего спора про печку и Энгельса:)
12 сен 03, 13:42    [336806]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Zaxx
Guest
2 BVV

Инцидента не было, просто спор бесполезный получается.
12 сен 03, 15:02    [337004]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
DimaR
Member

Откуда:
Сообщений: 1570
360 Мег данных из Interbase

Мда... а посильнее чего нибуть выбрать, а то interbase как то не катит для высокопроизводительно СУБД, скажем Oracle?
12 сен 03, 15:17    [337048]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
Garya
Member

Откуда: Москва
Сообщений: 33188
Блог
Сэры, появилась реакция сотрудника Интерсистемс Антона Умникова на тесты, которые мы тут крутили. Опубликовано на конференции Cache.ru. Привожу ее "as is":

Приветствую!

К сожалению, в последнее время очень много далеко идущих выводов делается подписчиками CACHE_RU и других форумов в интеренет на основе доморощенных простых тестов.

Вот некоторые мои (персональные)

Соображения по поводу тестирования производительности СУБД.

Корректная постановка задачи

В качестве негативных примеров неправильного подхода к тестированию возьмем задачи, которые уже обсуждались на днях в CACHE_RU:

- Поиск подстроки типа SELECT * FROM mytable WHERE myfield LIKE '%35%'
- Нахождение количества счастливых билетов по одной таблице с десятью записями.

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

1) Несколько (десятков/сотен/тысяч) пользователей
2) Комбинация запросов на изменение и выборку данных (естественно - соотношение варьируются от системы к системе).
3) Конкретные объемы данных.
4) Конкретные требования по надежности системы, транзакционной целостности (есть системы, где последним можно принебречь)
5) Конкретная сложность предметной области (схемы данных) и бизнес логики.
6) Конкретная аппаратная и програмная платформа (например - разные СУБД очень по разному ведут себя на многопроцессорных системах).

Сначала немного теории:

В качестве ограничивающих производительность факторов выступают как минимум четыре параметра:
- Объем памяти
- Процессорное время
- Система ввода/вывода (диски, сеть)
- Внутренние ограничения СУБД и приложения (например - конфликты по блокировкам).

Интегральная производительность системы, в большинстве случаев, определяется "бутылочным горлышком" системы. Например - если процессор не справляется с обработкой данных - увеличение оперативной памяти или скорости диска никакого прироста производительности системы не даст.

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

Вернемся к нашим "неправильным" тестам.

- Поиск подстроки. Если помните - FoxPro выйграл у всех клиент-серверных СУБД.
Тест выявил ограничение по скорости работы СУБД с дисковой подсистемой. Не удивительно, что выйграла файл-серверная СУБД. Теперь немножко приблизим постановку задачи к реальной: предположим, что пользователей у системы больше одного - естественно файл серверные базы тутже _очень сильно_ просядут, поскольку им придется все данные гнать на клиента и уже там обрабатывать.

Вторая ошибка состояла в том, что мы не учли, что кроме алгоритма полного сканирования в некоторых системах возможно и использование нереляционных алгоритмов. Так, для этой задачи они позволили в Cache' сократить время поиска с 20 до 0,2 секунд.

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

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

- Другой пример "неоднозначного теста" - заливка 1000000 записей в базу. Для Cache' операция:

for i=1:1:1000000 set ^a(i)=i

будет работать раз в 100 быстрее, чем 1 миллион операций insert в реляционной СУБД. Тем не менее это не дает право утверждать, что Cache' _всегда_ в 100 раз быстрее любой реляционной СУБД.

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

Что же тогда есть "корректное тестирование"?

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

Напрмер - сколько пользователей приложения Х смогут работать на аппаратной платформе Y, если время отклика на запросы пользователя не превышает 2х секунд?

Или: какое количество записей в минуту сможет обрабатывать система X на платформе Y, если одновременно с этим приложением будут пользоватся 5 операторов?

Естественно, реализация подобного теста требует намного более серьезной подготовки, нежели просто закачка в базу одной таблицы и сравнение времени выполнения выражения select * from mytable в двух различных базах.

Что позволяет InterSystems утверждать, что Cache' работает быстрее "СУБД X"?

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

Примеры:
http://www.intersystems.ru/cache/cache_vs_oracle.html реализация реальной задачи на Cache' и Oracle
http://www.intersystems.ru/testimonials/success/billing.html миграция из InterBase
http://www.intersystems.ru/testimonials/success/justice.html перевод системы с SyBase
и другие.

Почему, если на реальных системах Cache', по утверждению InterSystems, выигрывает - на простейших тестах она проигрывает?

Как было показано выше - "простейшие" тесты могут показать результат как в пользу Cache', так и в пользу любой другой СУБД. Просто любители поговорить особенно громко обсуждаются именно тесты, где Cache', по какимто причинам проигрывает.

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

В итоге, чтобы дать однозначный ответ на вопрос: "Почему в данном конкретном тесте Cache' работает быстрее СУБД Х"? необходимо рассмотреть в деталях большое количество факторов. Более того - многие из используемых в Cache' алгоритмов являются технологическим секретом и не могут быть разглашены.

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

Если речь идет о простых тестах, где очень быстро достигается один из пределов возможностей системы, а влияние других пренебрежимо мало - например - скорость обращения к диску в случае поиска подстроки или скорость работы интерпретатора p-кода и операции $Order в случае подсчета счастливых билетов - Cache' показывает результаты ненамного отличающиеся от результатов других СУБД. Такой-же результат вы получите если перекачаете большую таблицу из одной СУБД в другую и сделаете выборку по одному-двум условиям.

При прочих равных условиях Cache' начинает стабильно показывать более высокие результаты по сравнению с другими СУБД при увеличении количества пользователей и сложности выполняемых ими запросов. То есть условия тестирования приближаются к реальным условиям эксплуатации.

Конечно, проведение такого тестирования требует серьезного подхода и времени - здесь InterSystems готова помочь компаниям оценить производительность СУБД в рамках так называемого пилотного проекта.

Возможны и варианты, при которых Cache' сразу дает радикальное увеличение производительности по сравнению с реляционными СУБД поскольку предоставляет возможности - недоступные в реляционных СУБД. Например - транзакционные bit-map индексы или прямой доступ к данным как в случае с решением задачи по поиску подстроки. В частности, подобные возможности Cache' очень часто используются в системах с высокими требованиями к производительности - например биллинговые системы, для которых задача с занесением миллиона записей в базу очень близка к реальной.

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

Заключение

СУБД - это крайне сложные системы и не случайно их стоимость может значительно превышает стоимость операционных систем и прикладного ПО. Оценка их производительности также задача нетривиальная и требует серьезного подхода.

Мне вполне понятен здоровый скептицизм людей, которые не доверяют материалам, которые находятся на сайте производителя и в рекламе. Также понятно и желание "попробовать все своими руками". Тем ни менее я призываю более серьезно относится к процессу тестирования, если уж вы действительно готовы инвестировать в него свое время. Более того InterSystems охотно поможет выполнить адекватное тестирование в рамках пилотного проекта.

Регардсы,

-Антон

Anton Umnikov (anton@intersystems.ru)
InterSystems Russia
Phone: +7 (095) 956-8808
http://www.intersystems.ru
Cache' - Make Applications Faster


ИМХО:
Я сходил по приведенным ссылочкам и внимательно отнесся к информации в самом ответе. Обратил внимание, что речь о выигрыше в быстродействии Cache по сравнению со всем прочим в основном идет, когда требуется выполнять огромное количество операций insert или update. Поскольку в Cache журналирование может быть отключено, то существенный выигрыш по этим операциям в Cache может быть получен, в частности, путем отключения механизма транзакций. К сожалению, в информации о производимых тестах об этом ничего не сказано. Для того, чтобы определиться в этом вопросе окончательно и провести сравнение честно, в равных условиях, я попробую прогнать тест по массированному добавлению записей в Cache и MS SQL 2000 как со включенным журналированием, так и с выключенным (bulk insert в MS SQL). Должен сразу сказать, что по сложившемуся у меня впечатлению, допускаю, что Cache в данном тесте вполне может выиграть. Просто структура кашевых глобалей существенно проще, и в ней меньше завязок с индексами (всякими кластерными и некластерными). Вот только насчет 100 крат имеются сомнения - подозреваю, что эта цифра была получена при сравнении журналируемой операции по таблицам, на которую было завязано имеющем много индексов, с нежурналируемой с минимальным числом индексов.

По поводу оценки тестов в файл-серверной и клиент-серверной системе - согласен полностью и во всём. По поводу оценки теста с Like я, в общем и целом, более-менее согласен, хотя и не совсем. Фактически в этом тесте выполняется полное сканирование таблицы. ИМХО, на подобном тесте в различных СУБД должны получиться достаточно близкие результаты. По поводу же оценки теста со счастливыми билетиками не согласен категорически.
То, что Full scan большой таблицы в Cache работает медленнее, говорит о том, что выборка на чтение в Cache работает медленно. Возможно, это же явилось одной из причин такого существенного проигрыша Cache в алгоритме подсчета счастливых билетиков. Хотя записей в таблице всего десять, выборка их из этой таблицы производится в цикле очень много раз, вследствие чего и происходит накопление отставания. Возможно, простейшие математические операции и операции со строками в Cache также производятся медленнее. Из-за этого многократное сравнение содержимого записей с заданным по условию в Cache притормаживает.

Предварительные выводы. Cache проигрывает на чтении, но выигрывает на записи. Более подробно впечатлениями поделюсь после прогона дополнительных тестов на запись.
15 сен 03, 19:19    [339482]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД   [new]
BVV
Guest
...лучше бы он пример привел переноса данных с Interbase, а то в статье ни слова об переносе данных, одни успехи. Перенос через DDL очень долгий.
Придется самому разбираться не цивилизованными методами.
15 сен 03, 21:38    [339584]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Little
Guest
Такой вопрос уважаемым КЭШологам.

Реализуя пресловутый тест на низком уровне...

Как бы это показать.

допустим юзер А запустил этот запрос.

select .....

допустим в таблице не 9 а 100 чисел и запрос выполняется 2 мин.

В это время, юзер Б начинает делать insert в эту таблицу (или UPDATE).

Пример на MySQL (InnoDB):
--------------------------------
ШЕЛЛ 1:


mysql> select count(*) from t t1, t t2, t t3, t t4, t t5, t t6, t t7, t t8 where
t1.i+t2.i+t3.i+t7.i=t4.i+t5.i+t6.i+t8.i;
+----------+
| count(*) |
+----------+
| 398567 |
+----------+
1 row in set (9.23 sec)

========================= ТОЧКА А ==========================

mysql> select count(*) from t t1, t t2, t t3, t t4, t t5, t t6, t t7, t t8 where
t1.i+t2.i+t3.i+t7.i=t4.i+t5.i+t6.i+t8.i;
+----------+
| count(*) |
+----------+
| 398567 |
+----------+
1 row in set (9.22 sec)

========================= ТОЧКА Б =====================

КОНЕЦ.
-------------------------------------------------------------------
ШЕЛЛ 2:

mysql> select * from t;
+------+
| i |
+------+
| 0 |
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
+------+
7 rows in set (0.00 sec)

======================== ТОЧКА А ==========================

mysql> insert into t values(100);
Query OK, 1 row affected (0.17 sec)

mysql> insert into t values(100);
Query OK, 1 row affected (0.11 sec)

mysql> insert into t values(100);
Query OK, 1 row affected (0.03 sec)

mysql> insert into t values(100);
Query OK, 1 row affected (0.02 sec)

============================== ТОЧКА Б ==========================

mysql> select * from t;
+------+
| i |
+------+
| 0 |
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 100 |
| 100 |
| 100 |
| 100 |
+------+
11 rows in set (0.00 sec)

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

Как видно, "в то время когда космические корабли, бороздят просторы..." короче в то время когда юзер А делает "долгий" селект (9 сек), юзер Б втыкает в таблицу новые записи (аналогично выглядит пример с UPDATE вместо INSERT).

При этом SELECT для юзера А выглядит атомарным и вражеские поползновения юзера Б не влияют на результат А.

ВНИМАНИЕ ВОПРОС:

Что произойдет в КАШЭ??? При использовании SQL? При использовании низкоуровневого подхода?
16 окт 03, 19:53    [380150]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Garya
Member

Откуда: Москва
Сообщений: 33188
Блог
Если вы речь ведете о уровнях изоляции, то их в каше есть :). Известно, что изоляция теоретически может достигаться с помощью версионности и блокировок. Так вот, в каше она достигается с помощью блокировок (как и в MS SQL Server).
16 окт 03, 20:15    [380174]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Little
Guest
2Garya: я просто хотел выяснить "состоятельность" или "несостоятельность" низкоуровнего доступа к данным. Оно конечно быстрее, но если следовать всем блокировкам, тот самый тест превращается в чёрте-знает-что.

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

А то гордые заявления про СУБД надоели, если "СУ" приходится реализовывать самим программистам. API это к БД, а не "СУ".
17 окт 03, 11:34    [380818]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить