Здравствуйте, Alexey Shirshov, Вы писали:

AS>Мы спорим о том что более распространено на данный момент? Я нет, а ты?
Я тоже не отом.
AS>Я высказал мысли о том, что возможно иерархические БД (понятное дело на основе XML Infoset или другой XML data model) будут теснить реляционный как по степени распространнености, так и по другим (техническим) показателям. Для этого я не вижу никаких препядствий.
Я тоже особых препятствий не вижу, хотя реализации подобных серверов, которые мне удалось попробовать, меня не вдохновили. (Отсутствие общепринятой спецификации на язык запросов, то что есть сильно походит на притянутый за уши XML. Большинство из виденых мною коммерческих, и как минимум 99% из OpenSource реализованы на Java, что не всегда хорошо. Почти полное отсутствие понятия об индексировании и оптимизации запросов, что в условиях промышленной эксплуатации не приемлемо. Отсутствуют, пусть и менее функциональные, зато более легкие, в смысле ресурсов системы, реализации серверов.)

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

Здравствуйте, avbochagov, Вы писали:
A>А как сравнивать? по SQL?
Ну... например. Вот в Берне ребята утверждают, что они именно на SQL получили 100-кратное ускорение транзакций. А так — почему бы и не без SQL? Задача-то четко очерчена — склады, товары, накладные... Если удается сделать это без SQL, при сохранении ACID — вперед.
A>Сейчас буча идет — сами производители SQL баз говорят что этот тест нихрена немеряет, не соответствует реалиям современной жизни.
Что-то я не заметил. Зато вот они новые результаты туда постят — вот это буча.
A>Да не могут себе этого их маркетологи позволить!
A>Если кто-то видит это название иерархическая СУБД — то сразу все сакс, говно, было уже и т.д.... "а Вот MS SQL рулит"...
Даже не смешно. Просто их маркетологи называют вещи своими именами. Разреженные массивы — разреженными массивами, R-деревья — R-деревьями... Нету там никакой иерархии .
A>Там пробегала история про переход системы документооборота в Берне с Sybase SQL на Cache.
A>По их (не Intresystems, а системщики из Берна) быстродействие поднялось в 20-30 раз.
A>А так — вот
A>http://www.intersystems.com/cache/testimonials/performance.html
Кул! Червь сомнений меня уже начал мучить. Хотя есть такое подозрение, что у них просто по Sybase не было нормальных спецов... Тем не менее, знак хороший — значит Sybase нифига не чемпион. Шутка На самом деле — получение инструмента, которые позволяет так ускорить разработку даже при небольшом понижении производительности — уже круто. Так что я, в общем, впечатлен. Будем исследовать опыт передовиков OLTP — производства!

Здравствуйте, Serginio1, Вы писали:
S> Athlon 64 он же Hammer он же Opteron он же Athlon 64 FX-53 это просто разные линейки. Кстати intel сам сечас делает АМД совместимы процессоры,
S> так что твоя информация устарела.
Ну, я человек тупой — не судьба мне понять, что Athlon 64 FX-53 и Opteron — одно и то же. Тем не менее, аргумент про 64GB на IA32 ясен?

Здравствуйте, avbochagov, Вы писали:

A>Реляционная таблица в принципе не может быть быстрой без индекса.
И что?

A>Так что без индексов нет ни одной реляционной базы данных, а вот их количество определяется требованием к скорости обработки.
И что?

A>Универсальность и достигается за счет повышения сложности, увеличения подтаблиц и огромного количества индексов.
Нет.
Универсальность — это свойство самой модели. Платить за это приходится описанием систеы в терминах этой модели, не больше и не меньше. Индексы и количество таблиц — это лишь те самые "термины модели", и говорить в данном контексте об их количестве как кретерии оценки сложности этой системы — смысла не имеет.

A>Плата за это — огромный рост базы данных и серьезное повышение аппартных требований.
Гы. Шутить изволите? Базы данных, а с ними и аппаратные требования, растут в связи с ростом информации, которую необходимо хранить и обрабатывать.

A>Правда огромный плюс: РСУБД работают одиннаково медленно на любых задачах — плата за универсальность.
Заблуждаешься.
RDBMS работаю одинаково быстро и, в тоже время, одинаково хорошо подходят для подавляющего боьшинства задач — и в этом их главное преимущество.

A>Про эффективность говорить не приходится.
И не говори.

A>Самая крутая РСУБД Oracle "работает одиннаково медленно" на любом объеме данных — описание дано программистом довольно двано работающим с Oracle.
Давай сюда этого программиста, за базар отвечать будет. Может быть в те времена, когда Оракл была "самой крутой" может быть так и было, но сейчас это совсем не так.


A>При правильном использовании (как и в любой задаче) применение иерархических СУБД дает примерно выигрыш от 20 до 50 раз по скорости работы (при тех же аппаратно-технических требованиях)
Угу, только с небольшой поправочкой, а точнее с двумя.
1. Не в 20-50, а в 2-3.
2. Только в очень специальных задачах, которые идеально ложатся в рамки иерархических СУБД. А таких задач, в настоящее время, просто мизерное количество.

A>Примеры можно взять из многочисленных success story например на сайте www.instersystems.ru
Эти многочисленные SS просто детский лепет, по сравнению с количеством и объемом информации, который хранят и в обрабатывают РСУБД.
Когда хоть какая-нибудь иерархическая база появится на tpc.org вот тогда и поговорим, а до этого времени все это не серьезно.


P. S.
Господа, вы забываете еще один аспект универсальности RDBMS. Информация имеет свойство хранится очень и очень долго. И сама информация переживает системы ее обработки. Благодаря тому, что в/из реляционную структуру можно перевести данные любой сложности — нет никаких проблем обработки реляционных данных многолетней давности, собранных в системах о которых мы даже не знаем. Все же остальные модели, в том числе и иерархическая предполагают некоторую зависимость способа хранения данных от самих данных, и когда со временем данные потребуется представить в другом виде это потребует серьезного перестроения модели хранения этих данных.
А реляционная модель подобным мутациям не подвержена.

Здравствуйте, avbochagov, Вы писали:

A>А как сравнивать? по SQL?
Причем тут SQL?
По количеству проведенных заказов в минуту.

A>Сейчас буча идет — сами производители SQL баз говорят что этот тест нихрена немеряет, не соответствует реалиям современной жизни.
Гы...
Это идет не сейчас, а все время существования этого теста. И всегда поднимали ее те, кто не мог показать мало-мальски адекватного результата в этих тестах.

A>Да не могут себе этого их маркетологи позволить!
Маркетологи могут себе позволить гораздо больше чем разработчики — лиш бы продавалось. Яркий пример — бага в Оракловском read committed, о которой разработчики прекрастно знают, но поправить не могут, потому как на тестах типа tpc — это довольно серьезная фора. А маркетологи же не допускают упоминания об этой особенности в документации... Так и живут..

A>Если кто-то видит это название иерархическая СУБД — то сразу все сакс, говно, было уже и т.д.... "а Вот MS SQL рулит"...
Ну так правда ведь...

Здравствуйте, Serginio1, Вы писали:

S>>>А уж на уровне сервера это все уже продумано давно. При этом повторюсь при 64 битных ОС и процессоров дисковые проблемы вообще отходят на задний план.
Да млин! Ну почитай же теорию.
Во-первых самые дорогие не джойны, а дисковые операции — причем все остальное, по сравнению с ними — вообщи фигня полная. Знаешь какая формула рассчета стоимости физических операий для Ораклового оптимизатора? Logical I/O = CPU + 1000 * Physical I/O. То есть стоимость дисковых операций на три порядка больше чем работа с CPU.
Во вторых B-tree рулит при дисковых операциях, причем именно потому, что в состоянии обеспечить самый эффективный кеш данных — ни какой хеш и другие извращения здесь не сравнятся.
Во втретьих от дисковых операций все равно никуда не уйдешь потому как каждая транзакция обязана при фиксации сбрасывать данные на диск, иначе об устойчивости вообще говорить нельзя.
В четвертых иметь постоянный адрес на диске для записи во время всей ее жизни ужастно не оптимально, а при наличии кластерного индекса и невозможно. А значит твоя система прямых ссылок вынуждена обеспечивать поддержку перемещения данных по диску, что сводит на нет все преимущества.


S>Там где SQL подход рулит при ограничении памяти при ее обилии возможны совсем другие подходы которые не будут сказываться на производительности и безопасноти.
Да будут, потому что от дисковых операций все равно никуда не денешся — это раз. И потому, что объемы информации растут гораздо быстрее чем объемы оперативной памяти способные ее вместить — это два.

Здравствуйте, Morgun, Вы писали:

M>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. Внутри нашего отдела АСУ не все разделяют это мнение разделяют.

Не сможет.

M>А что думает уважаемое сообщество? Кто имел опыт разработки с использованием XML и Объектно Ориентированных БД поделитесь опытом и ощущениями, пожалуйста.

Просто XML вообще без шансов, т.к. в нем нет такого понятия как индекс, что делает его бесполезным.

Есть так называемыен объектные базы (ZoDB, Hibernate и т.п.). Но эти не всегда могут справиться с серьезным объемом документов.

Плюс для них гораздо сложнее оптимизировать. Т.к. если что то тормозит то нужно менять структуру данных, а это вызывает необходимость переписывания половины приложения. Тогда как для реляционных просто индексы перевесить и запрос переписать(только 1 — который тормозит).

Кроме того такие вещи как репликация становятся невозможны.

Переход на новую структуру тоже гемморой(он правда везде геморрой, но в объектных базах это обычно нечто совершенно особенное).

Так что вообщем люди которые твое мнение не разделяют правы. Это очень серьезный риск связываться с объектной базой. Т.е. решение с реляционной 100% будет работать, возможно потребует чуть больше работы. Решение с объектной с некоторой вероятностью завалит проект или создаст тонну работы уже когда офигенные деньги на проект потрачены.

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

Здравствуйте, Barmaglot, Вы писали:

B> Logical I/O = CPU + 1000 * Physical I/O. То есть стоимость дисковых операций на три порядка больше чем работа с CPU.
Конечно же Cost = Ph I/O + CPU * 1000 — в торопях описался... Точнее сама формула немного сложнее, но порядок именно такой — стоимость дисковых операций на три порядка выше всего остального...

Здравствуйте, Serginio1, Вы писали:

S> Вот программисты тупые держат всегда прямые ссылки на объект (хотя это и виртуальный адрес), вместо Хэш таблицы или Б+ дерева в памяти????
Они не тупые, просто они это делают в памяти. А всю базу в память редко когда удается запихнуть, а если удается, то это не та база, где надо рекорды производительности показывать.
А для дисковых операций лучше B+tree пока что еще ничего не придумали.

B>> Logical I/O = CPU + 1000 * Physical I/O. То есть стоимость дисковых операций на три порядка больше чем работа с CPU.
B>Конечно же Cost = Ph I/O + CPU * 1000 — в торопях описался... Точнее сама формула немного сложнее, но порядок именно такой — стоимость дисковых операций на три порядка выше всего остального...

Первый вариант был правильнее, если считать, что CPU и Ph I/O — это кол-во операции(обращений) к CPU и диску, соответственно.

Здравствуйте, Barmaglot, Вы писали:

хъ

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

Не правда ваша. Читать теорию.

Здравствуйте, Barmaglot, Вы писали:

B>Здравствуйте, Serginio1, Вы писали:

хъ

B>А для дисковых операций лучше B+tree пока что еще ничего не придумали.

А каким образом хорошая скорость B+tree может быть связана с дисковыми операциями?

Здравствуйте, Alexey Shirshov, Вы писали:

Вах, какой топик пропустил.....


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

AS>Не правда ваша. Читать теорию.

Нет Алекс, тут не прав ты и почитать теорию надо бы тебе. Без сброса данных на диск перед фиксацией транзакции вся Durability идет лесом стройными рядами.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Sinclair, Вы писали:


S> В ЛБД используя индексы и тд считывая по одной (редко блоками) в любой момент я могу поменять направление выборки, что невозможно в SQL.
Угу, и за это ты платиш производительностью, причем фатально.

S> Курсоры есть и в SQL, но нормальную надстроку над ними сделать на данном этапе нельзя. Дай быстрый курсор и ООП на стороне сервера и доступ не на уровне строки SQL а на уровне API и функций считывания записи.
Уровень API тебе ничего не даст — SQL и есть тот самый API, самый низкоуровневый из всех возможных, ниже некуда.


S> Пока премущество SQL в том, что выборка компилируется и проход очень быстрый сравнимый с проходом по массиву через указатели. Тот же foreach но на уровне указателей .
Аааааа.... Это пестню не задушишь не убъешь...

S>В локальной БД я и сам все что нужно с оптимизирую и использую данные индекса если нужно доступ к нему есть, а во многих задачах вообще не нужно ни чего оптимизировать тупой последовательный проход с ветвлениями. Пусть даже потеряю в скорости в 2 раза зато выиграю в гибкости в 100 раз.
Ну чего ты говоришь? Какая гибкость в жестко прописаном алгоритме под конкретную задачу?

S> И почему так популярна 1С????
Потому, что бухгалтера очень консервативны и потому, что лучше всех умеет правильно бумажку для налоговой распечатать. Все, других причин нет.

Здравствуйте, Merle, Вы писали:

хъ

M>Нет Алекс, тут не прав ты и почитать теорию надо бы тебе.

Точно?

M>Без сброса данных на диск перед фиксацией транзакции вся Durability идет лесом стройными рядами.

Данные сбрасываются на диск менеджером буферов асинхронно. Синхронно на диск уходит запись в лог.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>>Здравствуйте, Sinclair, Вы писали:


S>> В ЛБД используя индексы и тд считывая по одной (редко блоками) в любой момент я могу поменять направление выборки, что невозможно в SQL.
M>Угу, и за это ты платиш производительностью, причем фатально.
Угу чем мне платить если задача такова что и 20 запросов не хватит охватить выборку. А на производительности это не сказывается.
Все о чем SQL выигрывает вернее сильная часть это глобальные выборки, т.к. в примере подсчета продаж в день он опускает руки . Но в задач с проведением документов а они и являются основными критическими затратами это не нужно.


S>> Курсоры есть и в SQL, но нормальную надстроку над ними сделать на данном этапе нельзя. Дай быстрый курсор и ООП на стороне сервера и доступ не на уровне строки SQL а на уровне API и функций считывания записи.
M>Уровень API тебе ничего не даст — SQL и есть тот самый API, самый низкоуровневый из всех возможных, ниже некуда.

Select * From s where ID=:ID Согласен что такой запрос будет скомпилирован, но SetPrimsryIndex, GetRecordForKey(ID) и как видишь кода лишнего совсем немного.
S>> Пока премущество SQL в том, что выборка компилируется и проход очень быстрый сравнимый с проходом по массиву через указатели. Тот же foreach но на уровне указателей .
M>Аааааа.... Это пестню не задушишь не убъешь...

S>>В локальной БД я и сам все что нужно с оптимизирую и использую данные индекса если нужно доступ к нему есть, а во многих задачах вообще не нужно ни чего оптимизировать тупой последовательный проход с ветвлениями. Пусть даже потеряю в скорости в 2 раза зато выиграю в гибкости в 100 раз.
M>Ну чего ты говоришь? Какая гибкость в жестко прописаном алгоритме под конкретную задачу?
Тебе показать проведение начисления зарплаты???? Где тысячи ветвлений.
S>> И почему так популярна 1С????
M>Потому, что бухгалтера очень консервативны и потому, что лучше всех умеет правильно бумажку для налоговой распечатать. Все, других причин нет.
Если бы все было так просто. Парус нормальную бухгалтерию выпустить не может. А все потому что структура бухгалтерии не однородна и не вписывается в прямолинейные запросы SQL. А таких задач пруд пруди.

Здравствуйте, Sinclair, Вы писали:

S>>Хотя специализированные БД нужно писать с высокой оптимизацией с применением различных списфиских алгоритмов, где SQL и РБД сильно проигрывают особенно на сильно разветвленных БД и применеием иерархии (свинное ухо).
S>Согласен. РБД — не панацея. Просто потому, что большинство из них садится в лужу на "простейших" запросах типа select * from plane where (x-x0)*(x-x0)+(y-y0)*(y-y0)<R*R

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

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

Здравствуйте, Barmaglot, Вы писали:

B>Здравствуйте, Serginio1, Вы писали:

S>>>>А уж на уровне сервера это все уже продумано давно. При этом повторюсь при 64 битных ОС и процессоров дисковые проблемы вообще отходят на задний план.
B>Да млин! Ну почитай же теорию.
B>Во-первых самые дорогие не джойны, а дисковые операции — причем все остальное, по сравнению с ними — вообщи фигня полная. Знаешь какая формула рассчета стоимости физических операий для Ораклового оптимизатора? Logical I/O = CPU + 1000 * Physical I/O. То есть стоимость дисковых операций на три порядка больше чем работа с CPU.
То есть кэширование страниц не используется и ассинхронной записи на диск не существует??? Но это их беды.
B>Во вторых B-tree рулит при дисковых операциях, причем именно потому, что в состоянии обеспечить самый эффективный кеш данных — ни какой хеш и другие извращения здесь не сравнятся.
То есть БД работает не со страницами в памяти а только с диском (да и то система кэширут их в памяти).
B>Во втретьих от дисковых операций все равно никуда не уйдешь потому как каждая транзакция обязана при фиксации сбрасывать данные на диск, иначе об устойчивости вообще говорить нельзя.
Асинхронно.
B>В четвертых иметь постоянный адрес на диске для записи во время всей ее жизни ужастно не оптимально, а при наличии кластерного индекса и невозможно. А значит твоя система прямых ссылок вынуждена обеспечивать поддержку перемещения данных по диску, что сводит на нет все преимущества.
Не адрес а номер записи. Есть массив
PagePos= Record
OfseetInDisc:Integer;
PointerInMemory:Integer;
IsChange:boolean;
end;
Для каждой таблицы создантся массив последовательных страниц
PageArray:Array of PagePos;
Индекс в массиве страниц находится как RID*SizeRecord shr 13. Если страница не загружена в память то она загружается.
Смещение записи на странице RID*SizeRecord And ((1 shl 13)-1).
Посчитай затраты на Б+ деревья.
Соответственно при выгрузке страницы пр нехватке памяти PointerInMemory обниливается.
При реструкторизации данных номер записи как был так и остался и последовательны список страниц генерится заного.

Ну а при объеме страницы 8 кб этот массив занимает не так много места.

S>>Там где SQL подход рулит при ограничении памяти при ее обилии возможны совсем другие подходы которые не будут сказываться на производительности и безопасноти.
B>Да будут, потому что от дисковых операций все равно никуда не денешся — это раз. И потому, что объемы информации растут гораздо быстрее чем объемы оперативной памяти способные ее вместить — это два.
Их не так и много даже сейчас за счет кэширования. При чем если бы было наоборот то и SQL особо не поворочаешь все сразу уперлось бы в чтение диска а это не так.
Кроме всего прочего большая часть БД не используется а работа ведется с актуальными на данный момент данными и их объем не сравним с общим объемом, а на этом кэширование и работает.

Здравствуйте, Alexey Shirshov, Вы писали:

AS> Синхронно на диск уходит запись в лог.
Ну и какая разница? Запись в лог — не дисковая операция? Страница лога пишется в разы быстрее?
Один фиг к диску обращаться. Почитал бы и ты теорию что ли....

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
S>> Athlon 64 он же Hammer он же Opteron он же Athlon 64 FX-53 это просто разные линейки. Кстати intel сам сечас делает АМД совместимы процессоры,
S>> так что твоя информация устарела.
S>Ну, я человек тупой — не судьба мне понять, что Athlon 64 FX-53 и Opteron — одно и то же. Тем не менее, аргумент про 64GB на IA32 ясен?
Меня за 3мб убьют. Но в атлонах применяется HypperTrasport до 12 ГБ в секунду (новый до 20).
http://www.amdnow.ru/reviews/hypertransport/index3.shtml
А как на счет 128 Гбайт(!)
http://www.amdnow.ru/reviews/hammer/index6.shtml