Здравствуйте, Morgun, Вы писали:
M>Меня уже почти год мучает вопросы связанные перспективами развития БД.
M>Началось все когда делал диплом. Это была обучалка по технологии программирования. Обучалка не совсем такая к которым все привыкли. Главная в ней часть (фича, изюминка) -"интеллектуальный" тренажер. Строишь себе UML диаграмму по заданию, а помощник (как в Office) тебя поправляет и "ценные" советы дает. Ессесенно там кое-чего из алгоритмов ИИ было (как сильнодействующее на комиссию средство, да и просто интересно), трехзвенка с собственным сервером приложений и т.д. и т.п. M>Но не в том вопрос. Требование которое я изнально себе поставил — наполняемость системы. Т.е. преподаватель должен мочь новые задания описывать и в систему вводить. Вопрос — как хранить? Думал долго — 2 дня в упор. Пришел к выводу, что пока лучше сделать хранения в "алгоритмическом графе" ("И-ИЛИ" граф с вершиной-циклом) (до естественного языка мне еще ой как далеко). Физически попробовал сначала сделать реляционную структуру для описания задания, но понял что запутался — взял XML за основу проект разом упростился. Сделанный вывод: реляционный подход в хранении данных не для всех задач хорошо.
M>Проблема вернулась в новом лице после защиты. Новое лицо — документооборот. Хороший документооборот — гибкий документооборот. Формы и состав документов могут меняться во времени и это не должно отражаться на системе в целом.
M>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. Внутри нашего отдела АСУ не все разделяют это мнение разделяют.
M>А что думает уважаемое сообщество? Кто имел опыт разработки с использованием XML и Объектно Ориентированных БД поделитесь опытом и ощущениями, пожалуйста.
Я лично высажу свое мнение. Изначально была делема между иереархическими БД и реляционными. Первая поддерживала естественную ссылочную адрессацию, которая поддерживала скорость, и ООП которого тогда не было.
Победил уневерсализм и репликация. Скорость была предана на алтарь универсальности и доступности Юзерам. SQL прекрасно вписывается в реляционность. XML вообще отстой проповедуемый M$. То же документооборот решается на блобах с индексированными словосочетаниями яля Яндекс. Ну а 2 дня мало. Пьян.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Morgun, Вы писали:
M>А что думает уважаемое сообщество? Кто имел опыт разработки с использованием XML и Объектно Ориентированных БД поделитесь опытом и ощущениями, пожалуйста.
О-о-о, наш человек, наш. Все, сдаю английский и начинаю новую жизнь. Мое мнение высказано здесь.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Morgun, Вы писали:
M>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. Внутри нашего отдела АСУ не все разделяют это мнение разделяют.
Не сможет.
M>А что думает уважаемое сообщество? Кто имел опыт разработки с использованием XML и Объектно Ориентированных БД поделитесь опытом и ощущениями, пожалуйста.
Просто XML вообще без шансов, т.к. в нем нет такого понятия как индекс, что делает его бесполезным.
Есть так называемыен объектные базы (ZoDB, Hibernate и т.п.). Но эти не всегда могут справиться с серьезным объемом документов.
Плюс для них гораздо сложнее оптимизировать. Т.к. если что то тормозит то нужно менять структуру данных, а это вызывает необходимость переписывания половины приложения. Тогда как для реляционных просто индексы перевесить и запрос переписать(только 1 — который тормозит).
Кроме того такие вещи как репликация становятся невозможны.
Переход на новую структуру тоже гемморой(он правда везде геморрой, но в объектных базах это обычно нечто совершенно особенное).
Так что вообщем люди которые твое мнение не разделяют правы. Это очень серьезный риск связываться с объектной базой. Т.е. решение с реляционной 100% будет работать, возможно потребует чуть больше работы. Решение с объектной с некоторой вероятностью завалит проект или создаст тонну работы уже когда офигенные деньги на проект потрачены.
Я не утверждаю что объектные базы вообще бесполезны, но стоит различать persistance storage где хранятся мелкие данные и с ними действительно удобно работать и промышленные хранилища которые содержат миллионы записей.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Serginio1, Вы писали:
S> Так нормализация в РБД тянет за собой огромный индекс на подчиненные связи, где это как в нормальном программировании решается на двух напрвленными списками. Экономия на вставку и удаление, а так же надежность.
Это заблуждение. Нормализация никакого отношения к индексам не имеет. В реляционной алгебре вообще нет такой сущности, как индекс. А нормализация определяется в терминах РА.
Индексы в реляционных базах введены как раз для ускорения операций. S> Репликация в РБД хорошо вписывается, т.к. связи построены с применением инндексов, а не прямой или коственной (номер записи) ссылки.
Ты, похоже, неправильно понимаешь термин "индекс". Индексы не имеют никакого отношения к репликации. Если ты имеешь в виду то, что записи идентифицируются первичным ключом, т.е. значениями атрибутов, то да — это помогает реплицироваться.
S> Теперь объясню почему мне не нравится SQL. Если посмотреть на затраты разбора инструкций Insert, Update итд при может тратится намного больше времени чем сама вставка. Я сторонник прямого доступа с ранним связыванием, особенно когда база не изменяется и не требуется работа с удаленными БД.
Ну давай посмотрим. Дла сверхкоротких запросов такая ситуация может иметь место, но таких запросов в конечной системе не может быть много. Для оптимизации фазы синтаксического разбора все современные СУБД предоставляют двухстадийный механизм — подготовку стейтмента, и собственно выполнение. Между первой и второй стадиями могут менять параметры, и вторую стадию можно выполнять многократно. Т.е. мы выполнили связывание, получив предкомпилированный запрос, и потом выполняем его миную синтаксический разбор. S> И когда приводят тесты со временем за часы сразу вспоминаю любимые ДВК-2.
Хм. Самый хреновый результат из опубликованных МС в TPC-C составляет около девяти тысяч транзакций в минуту. Сервер — машинка с гигагерцовым PIII. Т.е. послабже нонешнего десктопа. При этом транзакция — это нифига не инкремент каунтера, это ввод заказа на товар, средним размером 10 позиций, в систему, где параллельно выполняются еще всякие запросы. Может, я не так понял, и ты говоришь про XML? S> Но у РБД очень много премуществ прежде всего в простоте использования и конфигурирования БД.
Ну естественно. На самом деле, в большинстве случаев попытка родить что-то свое приведет к тому, что либо пострадает надежность (ACID properties), либо производительность, либо и то и другое. А если вдруг удастся сохранить и то и другое, то внести любое изменение будет стоить просто безумных затрат. S>А раз за этим еще стоят монстры индустрии то конкурирующие подходы не нужны.
Подходы — нужны. Иначе зачем монстрам развивать свои продукты? S>Хотя специализированные БД нужно писать с высокой оптимизацией с применением различных списфиских алгоритмов, где SQL и РБД сильно проигрывают особенно на сильно разветвленных БД и применеием иерархии (свинное ухо).
Согласен. РБД — не панацея. Просто потому, что большинство из них садится в лужу на "простейших" запросах типа select * from plane where (x-x0)*(x-x0)+(y-y0)*(y-y0)<R*R
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Года два-три назад я плотненько знакомился с ООСУБД. Самой концептуально чистой и полной была Poet (споследствии переименованая в FastObjects). Есть основания полагать, что она таковой и осталась, потому как и темпы развития у нее повыше, чем у конкурентов.
Советую обратить внимание на них в первую очередь.
Что еще интересно, poet до какой-то версии поддерживало odmg (даже 3.0!!!), а затем от этой поддержки отказались. На наш вопрос "Почему?" был ответ — "Из-за слабой эффективности/производительности" .
Здравствуйте, Morgun, Вы писали:
M>Вопросы есть, конечно. M>Какую модель представления данных вы использовали?
Собственная разработка, основанная на семантических категориях: Сущность, Объект, Взаимосвязь, Параметр, Значение Признака, Семантическая координата и др...
т.е. при отображении Предметной Области в Модель используются различные способы и средства...
M>Каков характер связки — данные/алгоритмы?
Есть знания о Предметной Области — Модель (это не только данные), а есть
знания как решать задачу — алгоритмические.
В качестве прикладных зыков используется Java, С++ (возможность использования и других языков)
M>В каких предметных областях использовали?
реализованы/реализуются системы:
— Персонал
— АвтоЦетнр (СУП)
— Документооборот
— Ветеринарный контроль
— Сопровождение сложных технических изделий
— Кредитный союз
— Диагностика радиоэлектронной аппаратуры (ОКР)
— Медицинская диагностика (НИР)
M>Удобство разработки?
Разработка ведется на другом уровне
(как факт — небольшой коллектив, а кол-во реализованных систем см. выше)
M>Производительность? M>и т.д. и т.п.
В каких цифрах?
Установите систему и посмотрите сами
M>Если можно — краткое описание системы в электронном виде.
заходите на наш сайт и почитайте там.
(цель сайта другая, но вводные матералы есть)
Я вот не понимаю, почему мы должны выбирать реляционные хранилища с введением "разумной доли избыточности". Почему другие типы хранилищ не могут быть эффективнее (по производительности и объему данных)? В чем секрет реляционного подхода, который дает ему неоспоримое преимущество над иерархическим, например. Теория графов, на которой основаны иерархические СУБД старее реаляционной. Подобные системы появились значительно раньше чем РСУБД, следовательно опыт должен быть больше.
Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную. Зачем, собственно, мы тратим силы и средства для того чтобы притянуть зауши РСУБД для формализации всего этого?
Я не вижу серьезных аргументов, почему РСУБД должны быть быстрее иерархических. И там и там можно строить индексы, и там и там можно выполнять запросы. Просто иерархическая модель более гибкая чтоли. Реляционная модель, при всем моем уважении к ней, является подмножеством иерархической. Это подмножество специально было введено для упрощения работы с данными. Но ведь когда это было? На дворе 21 век!
Или я чего-то не понимаю?
Наверное это национальная забава — поиск единственного
верного учения, методологии, языка программирования, ОС и пр...
Нет и не будет универсального, удобного на все случаи
жизни способа представлять данные.
Конечно же, реляционное представление не может быть одинаково
хорошим для любых задач, так же как и XML.
Я понял, что у тебя возникла проблема, как эффективно хранить много деревьев.
Из моего лично опыта, в ИИ довольно часто встречается такая проблема.
Попытаюсь описать эту проблему немного иначе.
Частенько при создании сложных систем (не обязательно ИИ)
есть некое явное, компактное и понятное описание метамодели знаний (иногда говорят о метазнаниях)
и нужно эффективно работать с множеством частных случаев этой метамодели (instance).
Когда все это обсуждается на бумаге и не задумываются о реализации,
то нам доступны не только теории 1-го порядка (например исчисление предикатов 1-го порядка),
но и теории 2-го и более высоких порядков.
Что мы имеем доступного на компьютерах?
Увы, ничего выше первого порядка мы реально работающего так и не имеем.
Реляционные базы — это система первого порядка.
Думаю одна из причин твоих проблем лежит в этой плоскости.
Современные копьютеры очень плохи для описания метамоделей,
метаметамоделей и далее.
Как эффективно на современных компьютерах реализовать например
исчисление предикатов 2-го порядка — это пока нерешенная проблема.
Уверен, будь у тебя эффективная ООСУБД, ты бы в итоге столкнулся
с похожими проблемами, что и с реляционными БД.
Здравствуйте, Morgun, Вы писали:
M>Но не в том вопрос. Требование которое я изнально себе поставил — наполняемость системы. Т.е. преподаватель должен мочь новые задания описывать и в систему вводить. Вопрос — как хранить? Думал долго — 2 дня в упор. Пришел к выводу, что пока лучше сделать хранения в "алгоритмическом графе" ("И-ИЛИ" граф с вершиной-циклом) (до естественного языка мне еще ой как далеко).
В этом случае как правило данные храняться ввиде набора правил, состоящих из предиката, описывающего применимость правила и тела. Тело может быть либо написанным на алгоритмическом языке, либо какой то другой структурой, например графом, который может быть представлен тем же XML. В любом случае выбирать правило надо все целиком, а в таких условиях реляционной структуры, хранящей тело в блобе более чем достаточно.
M>Проблема вернулась в новом лице после защиты. Новое лицо — документооборот. Хороший документооборот — гибкий документооборот. Формы и состав документов могут меняться во времени и это не должно отражаться на системе в целом.
Как то давно, когда я был совсем молодой, видел я как вели учет наши деды, на бумаге без компьютеров. Так вот — хранили они данные исключительно в реляционном виде .
M>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости.
Сможет, если немного повозится. Другое дело что в терминах ОО мыслить проще.
Здравствуйте, Serginio1, Вы писали:
S> Так разговор на данном этапе даже не о записи а о чтении и расширенной организации данных.
Да, я намеренно избегал говорить о записи. Там все начинает жить несколько по-другому. Скорость тут ни при чем, вопрос в том — не напоремся ли мы при использовании RID на необхдимость перезаписи ссылок? Как там с дефрагментацией удаленного дело обстоит? S>Вы Синклеером говорите что ООП на стороне сервера это тормоза, а я что нет и даже во многих случаях выигрышь.
Нет, я этого нигде не говорил. Просто ты валишь в одну кучу совершенно не связанные между собой вещи. ООП не имеет никакого отношения к иерархическим базам данных; они, в свою очередь, не имеют никакого отношения к проблеме RID vs PK. S>А нужна прежде всего гибкость и скорость разработки а не за сколько выполнится тот или иной запрос.
Вот второе высказывание с твоей стороны в этой беседе, c которым я могу согласиться. Ты в следующий раз так и начинай с разумных вещей, а не рассказывай про то, как двусвязные списки побеждают RDBMS Я все же не вполне согласен, в том смысле, что совсем отменить требования performance нельзя. Но важность скорости разработки, конечно же, рулит чем дальше, тем сильнее. S>ECO, OBjectSpasec на сторону сервера!!!!!
Итак, предлагаю закончить эту дискуссию на постулировании трех вещей:
1. Алгоритмы, применяемые в RDBMS, были разработаны для условий нехватки вычислительных мощностей и памяти
2. Снижение стоимости памяти может сделать оправданным применение на низком уровне тех алгоритмов, которые ранее игнорировались в мире RDBMS
3. Снижение стоимости вычислительных мощностей выдвигает на первый план скорость разработки систем, а не быстродействие при эксплуатации, что может сделать оправданным применение на низком уровне тех алгоритмов, которые ранее игнорировались в мире RDBMS.
Следующий виток — в новой ветке
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Дело-то не сколько памяти адресуется и поддерживается чипсетом, а сколько это память стоит.
если считать по цене памяти для обычных персоналок: 256мб — 60$, 128г ~ 3000$, вспомним, что это память для сервера (* 2-5), что все 128гб память надо уместить в маленький объем (* 3-10), вспомним, что эта память будет выпускается малыми партиями, поэтому себестоимость высокая (* 3-10), такая память наукоемкая, требующая быстрой отдачи с вложенных денег (* 2-5)
Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы.
Тем более 128гб памяти — это не так уж много, 1млн простых записей вида имя, описание, дата, цена, где имя — 100 символов, описание — 500 символов, получается 1млн * (100 символов + 500 символов) * 2 байт/символ = 1.2гб, т.е. в памяти поместится всего 100 таблиц, это не считая всяких overhead-ов, кэшей и т.д.
Если же, например, описания идут не plain-текст, а rich-текстом (doc, html, xml), то описание уже может быть и 2000 символов, и четыре тысячи, а ведь скорее всего захочется и full-text index по этим описаниям- это еще одна копия этих же данных и т.д.
1. "Бессмысленность" данных, хранящихся в БД, т.е. интерпретация "смысла" данных в БД лежит либо непосредственно на пользователе, либо на прикладном алгоритме.
2. Слабые выразительные возможности. Если в системе невозможно в явном виде отобразить ту или иную информацию, то это приводит либо к потере данной информации, либо к ее искажению, что в свою очередь влечет за собой построение "упрощенной" модели, отображающий не саму задачу, а "взгляд" на решение задачи с позиции текущих требований.
3. "Жесткость" структур хранения информации...
Для решения этих (и других проблем) в нашем коллективе разработана База Знаний, с собственным языком описания знаний. Есть реализованные коммерческие проекты.
Так что эта тема нам очень даже близка
Если есть вопросы — пишите...
Здравствуйте, Serginio1, Вы писали: S>>Да я все понимаю. Вот только RDBMS выберет ту стратегию, которая быстрее для данного случая. Первым будет выполнен самый селективный запрос. Возможно, документы без данного товара вообще не будут сканироваться. S> Ну если так уж хочется все обставить индесами, то двухсвяхные списки не помеха, та же таблица.
ничего не понял. S>>Да с этим-то я согласен. Только в середину двусвязного списка прыгнуть нельзя. S> Ну да у тебя огромные подчиненные записи. И насколько это нужно.
Я тебе привел пример. Вот такой вот возник ad-hoc запрос. И решение с двусвязным списком начинает резко сливать, поскольку другую стратегию сканирования выбрать уже нельзя. S>>Что такое "многомиллионный индекс"???? Возьми СУБД и оцени объем индекса по инту для миллиона записей. По сравнению с исходной таблицей. При чем здесь выбор алгоритма??? S> Тады два инта (и еще номер записи). Тыже на середину документа прыгать хочешь. Тут AVK недавно считал так у него трилионы записей вышли. Но обновление индекса тебя не тревожит ?????
Да не тревожит меня обновление индекса! Эта операция вообще практически ничего не стоит! Стоят только обращения к диску. А их не более 3х на модификацию индекса. Зато потом чтений многократно меньше. S>>Ты уже определись, что критикуешь. 1С — отстой, никто и не спорит. Но они не пользуются RDBMS! В этом и состоит их проблема. Поэтому критиковать RDBMS c оглядкой на 1С — ошибка. S>Ну насчет отстоя я бы не сказал. Вполне приличная архитектура (правда изначально была заточена на ДБФ), но и 8 ке не сильно то они и ушли. S> Почему это не пользуются??? Просто беда в том, что тянут на клиента много. Вот в 8 ке трехзвенку делают. А под SQL тоже большинство работает через TSE.
Вот я и говорю — отстой. Передовые ребята уже отходят от трехуровневой архитектуры, потому как она недостаточно гибкая, а 1С все еще продвигают решения в терминах файл-сервера и ISAM. Понимаешь, их проблема ровно в том же, что и у предлагаемых тобой иерархических БД. Только они засасывают справочник из DBF, а потом делают по нему фильтр, а ты предлагаешь засасывать его из двусвязного списка. Ключ к успеху — это декларативное проектирование. Именно оно позволяет серверу выбрать наилучший в данном контексте способ добиться требуемого. В отличие от императивного программирования, которое ограничивает деятельность системы жесткими рамками. S> Да и разговор идет о том, что RDBMS хорошо, но большее ее расширение еще лучше. Просто RDBMS это просто подвид иерархических БД.
Я согласен с тем, что большее расширение RDBMS — это хорошо. Но не в сторону иерархических БД, упаси байт! Кстати, именно в эту сторону SQL-99 двигается. Ха-ха. Я посмотрю на него лет через 10.
Я кстати тебе вообще очень рекомендую книгу Гарсиа-Молина и других. Как курс по проектированию СУБД, а не БД. Там про все это очень подробно рассказано. И про XML, и про иерархии, и про структурированные файлы.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, bkat, Вы писали:
B>Это может рассматриваться и как достоинство. B>Хранить данные лучше отдельно от их интерпретации. B>Сегодня ты можешь данные проинтепретировать одним B>образом и сделать одни выводы, а завтра — совсем иначе. B>Данные же останутся одними и теми же
Есть обработка данных, а есть интерпретация. ;-)
В основе любой задачи лежит Модель Предметной Области (ПО), в не зависимости от того как она реализована.
Реляционные СУБД хранят только фактические данные о ПО, Объектные СУБД в основе хранят только информацию об Объектах ПО. Реально необходимо хранить гараздо больше семантической информации для адекватного представления информации.
Для простых задач способ представления и хранения информаци не критичен, для сложных (сильно связанных) задач без "правильного" (соответствующего действительности, а не текущего взгляда на проблему) представления информации нельзя создать устойчивую к изменениям систему — приходится постоянно модифицировать исходные структуры данных. Если же использовать соответствующие семантические принципы описания информации, то можно оперировать уже абстрагированными понятиями, что делает решение задачи инвариантным к изменяющимся условиям. (О-как ;-)
P.S. "Понимание" смысла хранящейся информации позволяет запрашивать у системы ЛЮБУЮ информацию в терминах самой задачи (см. механизм запросов системы br-a-vo).
Здравствуйте, AndrewVK, Вы писали:
AVK>В этом случае как правило данные храняться ввиде набора правил, состоящих из предиката, описывающего применимость правила и тела. Тело может быть либо написанным на алгоритмическом языке, либо какой то другой структурой, например графом, который может быть представлен тем же XML. В любом случае выбирать правило надо все целиком, а в таких
условиях реляционной структуры, хранящей тело в блобе более чем достаточно.
Все это само собой. Но что в блобе то хранится — XML, например? Если так то структура уже не чисто реляционная.
M>>Проблема вернулась в новом лице после защиты. Новое лицо — документооборот. Хороший документооборот — гибкий документооборот. Формы и состав документов могут меняться во времени и это не должно отражаться на системе в целом. AVK>Как то давно, когда я был совсем молодой, видел я как вели учет наши деды, на бумаге без компьютеров. Так вот — хранили они данные исключительно в реляционном виде .
Хмм... Но 3NF там точно не пахло. Потом, учет — еще не документооборот. Там такие "документики" попадаются, типа "Проиказ такой-то от такого-то числа. Считать в приказе на отчисление номер такойто студентку Алтунину Марию Алтуниной Ринатой". Причем обе студентки существуют.
Формы документов изменяются в последнее время довольно часто. Меняется даже состав некоторых документов — яркий пример ИНН ввели и сказали он нужен там-то и там-то. Еще через год скажут, вот здесь-то он тоже нужен, а здесь нам все равно.
И что — каждый раз проводить "технические" дни — перестраивать схему БД, останавливать работу вуза. Гибкость системы документооборота — это умение перестраиваться на ходу, не останавливаясь, это постоянная "совместимость" со старыми видами документов и в тоже время не зависимость от них.
Чем мне импонируют ООБД — эти задачи решаются в них двумя словами — наследование + полиморфизм.
M>>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. AVK>Сможет, если немного повозится. Другое дело что в терминах ОО мыслить проще.
Модель ООБД (обертку) тоже можно построить на базе реляционной БД (наоборот кстати тоже). Только возиться надо долго.
Здравствуйте, Morgun, Вы писали: M>Кстати Sinclair ты не планируешь заняться этими вопросами с научной точки зрения (в смысле диссер защитить). Я думаю такой человек как ты смог бы — наработки у тебя уже есть.
Ну вот мне осталось сдать английский язык для официального зачисления в аспирантуру, и ровно этим я и собираюсь заниматься. Собсно, реферат, который ты прочитал, мне пришлось написать при подаче документов в аспирантуру. Там и намечен план работ. Наработок, правда, пока ровно 0 — только вумные мысли. Но уже надо чево-то делать.
Пока не знаю, с какого конца браться:
1. Надо проанализировать существующие системы на предмет отклонения от 11 требований.
2. Скоро до нас должен доехать превью Yukon от MS. Есть мнение, что в него можно запихивать почти произаольный .NET код, что вызывает неудержимое желание набросать маппер из объектной модели в него, который уже будет поддерживать 11 требований.
3. Надо попробовать наколбасить тестовые приложения. Я тут вплотную занялся чтением TPC-C, с целью критически его осмыслить. Уж очень мне подозрительно отсутствие всяких модных кашей в ихних списках. Хочу придумать достаточно компактный тест насчет 11 требований. Пока все как-то смутно.
4. Теория. Читать, читать, и прикидывать, что из теорий применимо.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, bravo, Вы писали:
B>На самом деле в реляционных БД больше проблем
B>Вот самые существенные на наш взгляд:
B>1. "Бессмысленность" данных, хранящихся в БД, т.е. интерпретация "смысла" данных в БД лежит либо непосредственно на пользователе, либо на прикладном алгоритме.
Это может рассматриваться и как достоинство.
Хранить данные лучше отдельно от их интерпретации.
Сегодня ты можешь данные проинтепретировать одним
образом и сделать одни выводы, а завтра — совсем иначе.
Данные же останутся одними и теми же..
Простите что долго не было — Интернет только появился.
Вы писали:
B>На самом деле в реляционных БД больше проблем B>Вот самые существенные на наш взгляд: B>1. "Бессмысленность" данных, хранящихся в БД, т.е. интерпретация "смысла" данных в БД лежит либо непосредственно на пользователе, либо на прикладном алгоритме. B>2. Слабые выразительные возможности. Если в системе невозможно в явном виде отобразить ту или иную информацию, то это приводит либо к потере данной информации, либо к ее искажению, что в свою очередь влечет за собой построение "упрощенной" модели, отображающий не саму задачу, а "взгляд" на решение задачи с позиции текущих требований. B>3. "Жесткость" структур хранения информации...
Абсолютно со всем согласен. Спасибо за аргументы. чем их больше — тем легче мне на душе.
B>Для решения этих (и других проблем) в нашем коллективе разработана База Знаний, с собственным языком описания знаний. Есть реализованные коммерческие проекты. B>Так что эта тема нам очень даже близка B>Если есть вопросы — пишите...
Вопросы есть, конечно.
Какую модель представления данных вы использовали?
Каков характер связки — данные/алгоритмы?
В каких предметных областях использовали?
Удобство разработки?
Производительность?
и т.д. и т.п.
Если можно — краткое описание системы в электронном виде.
Здравствуйте, Sinclair, Вы писали:
S>Ну давай посмотрим. Дла сверхкоротких запросов такая ситуация может иметь место, но таких запросов в конечной системе не может быть много. Для оптимизации фазы синтаксического разбора все современные СУБД предоставляют двухстадийный механизм — подготовку стейтмента, и собственно выполнение. Между первой и второй стадиями могут менять параметры, и вторую стадию можно выполнять многократно.
Еще есть ХП, которые тоже храняться в прекомпилированном виде.
Здравствуйте, Alexey Shirshov, Вы писали:
AS> Почему другие типы хранилищ не могут быть эффективнее (по производительности и объему данных)?
Почему? Могут, но далеко не всегда... А реляционный подход более универсален он показывает наибольшую производительность в самом широком спектре приложений.
AS> В чем секрет реляционного подхода, который дает ему неоспоримое преимущество над иерархическим, например.
В универсальности.
AS> Теория графов, на которой основаны иерархические СУБД старее реаляционной. Подобные системы появились значительно раньше чем РСУБД, следовательно опыт должен быть больше.
Стех пор ка все осознали преимущества реляционного подхода, на иерархические и прочие сетевые СУБД конкретно забили, поэтому о большом опыте тут говорить не приходится.
AS>Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную.
Отнюдь не большинство.
Весь кайф реляционного подхода именно в его универсальности, это еще дядя Кодд доказал на пальцах на своем знаменитом выступлении.
AS> Зачем, собственно, мы тратим силы и средства для того чтобы притянуть зауши РСУБД для формализации всего этого?
Затем, что РСУБД тянутся хотя бы за уши, а все остальные, чаще всего, приходится тянуть за что-то более другое.
AS>Я не вижу серьезных аргументов, почему РСУБД должны быть быстрее иерархических.
Потому что большинство проблем свести к иерархическим СУБД окажется сложнее. Там где проще с иерархией — иерархические СУБД действительно рулят, но таких задач на удивление мало.
AS> Просто иерархическая модель более гибкая чтоли.
Как раз наоборот. Из всех известных, на данный момент, моделей работы с данными самой гибкой является реляционная.
AS> На дворе 21 век!
Yes, I do, а что толку?
A>Посмотрите базу данных Cache, причем именно в части глобалей и языка CacheScript.
А потом ужастнитесь и забудте об этом, как о страшном сне.... И главное, главное! Никогда не вспоминайте.
Здравствуйте, Serginio1, Вы писали:
S> И при этом огромные затраты на подчиненные записи. Например сточная часть документа. И тянется огромный индекс на всю таблицу.
Какие затраты? Какой индекс? Ничего никуда не тянется...
S> Сделав подчиненную таблицу ввиде двухнаправленного списка избавляемся от этого недостатка.
Она и так в виде этого списка, если очень захотеть.
Ты пытаешся изложить преимущества конкретныого подхода для решения конкретной задачи, это не серьезно. Ты в одном месте в ручную, под свою задачу с оптимизировал, хитрой реализацией двунаправленного списка — другие задачи тут же сливают на этой же реализации.
Вся сила РСУБД в универсальности, оди одинаково хорошо побходят для подавляющего ольшинства задач.
S> Реляционные базы это выхолощенные иерархические, где применяется очень маленький набор подходов. Да это надежно, но не эффективно.
Это очень эффективно, потому как быстро, просто и надежно.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, DarkGray, Вы писали:
DG>>Дело-то не сколько памяти адресуется и поддерживается чипсетом, а сколько это память стоит. S>Вот и я о том же. Мы еще IA32 не исчерпали, а уже ждем панацеи от Amd64. Бред. Вопрос именно в том, что пока мало кто может себе позволить сервак с более чем 4 GB памяти.
Для домашних комьтеров это уже норально, а ты о серверах. Стоимость Amd64 на порядки ниже IA32 и UltraSPARC
Прочти про Sun Fire V20z http://www.amdnow.ru/#1080436001 3 килобакса совсем не подъемная цена по сравнению со стоимостью програмного обеспечения????
Или все мыслить старыми категориями ,правда концепции SQL еще старее.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Для домашних комьтеров это уже норально, а ты о серверах. Стоимость Amd64 на порядки ниже IA32 S>Ну хватит с темы-то съезжать, а? Тебе русским по белому пишут: для СУБД неважно, что применяется, Pentium IV или Athlon 64. Память для них стоит одинаково. Ты тут пел про какие-то проблемы с адресным пространством, которые якобы решаются с помощью 64 разрядов. Так вот — НЕТ этих проблем. Уже 10 лет как нету.
Это не я пел а Вы про память дисковые операции итд. Спасибо впервые узнал что проблема адресного пространства решена аж 10 лет тому назад по стоимости близкой к домашнему компьютеру. Буду знать. И чего это 64 разрядной виндовс еще нет в релизе??? Да и M$ только недавно анансировало 64 SQL Server и хвастались что количество транзакций в секунду у них дико выросли.
А сколько стоят спарки???? И сколько у тебя памяти на самом могучем серверое????
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Меня уже почти год мучает вопросы связанные перспективами развития БД.
Началось все когда делал диплом. Это была обучалка по технологии программирования. Обучалка не совсем такая к которым все привыкли. Главная в ней часть (фича, изюминка) -"интеллектуальный" тренажер. Строишь себе UML диаграмму по заданию, а помощник (как в Office) тебя поправляет и "ценные" советы дает. Ессесенно там кое-чего из алгоритмов ИИ было (как сильнодействующее на комиссию средство, да и просто интересно), трехзвенка с собственным сервером приложений и т.д. и т.п.
Но не в том вопрос. Требование которое я изнально себе поставил — наполняемость системы. Т.е. преподаватель должен мочь новые задания описывать и в систему вводить. Вопрос — как хранить? Думал долго — 2 дня в упор. Пришел к выводу, что пока лучше сделать хранения в "алгоритмическом графе" ("И-ИЛИ" граф с вершиной-циклом) (до естественного языка мне еще ой как далеко). Физически попробовал сначала сделать реляционную структуру для описания задания, но понял что запутался — взял XML за основу проект разом упростился. Сделанный вывод: реляционный подход в хранении данных не для всех задач хорошо.
Проблема вернулась в новом лице после защиты. Новое лицо — документооборот. Хороший документооборот — гибкий документооборот. Формы и состав документов могут меняться во времени и это не должно отражаться на системе в целом.
Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. Внутри нашего отдела АСУ не все разделяют это мнение разделяют.
А что думает уважаемое сообщество? Кто имел опыт разработки с использованием XML и Объектно Ориентированных БД поделитесь опытом и ощущениями, пожалуйста.
30.03.04 14:06: Перенесено модератором из 'Философия программирования' — _MM_
Здравствуйте, Serginio1, Вы писали:
S> Я лично высажу свое мнение. Изначально была делема между иереархическими БД и реляционными. Первая поддерживала естественную ссылочную адрессацию, которая поддерживала скорость, и ООП которого тогда не было.
Ну если так — были еще и так называемые сетевые БД (иерархические их частный случай). Однако ОО поддерживать они не могли — его как ты сказал не было. Это дела давно минувших дней.
S> Победил уневерсализм и репликация. Скорость была предана на алтарь универсальности и доступности Юзерам. SQL прекрасно вписывается в реляционность. XML вообще отстой проповедуемый M$. То же документооборот решается на блобах с индексированными словосочетаниями яля Яндекс. Ну а 2 дня мало. Пьян.
Тогда победил структурный подход. А репликацию ты по-моему зря сюда присоединил (это вообще ко всему относится, а не только к реляционным).
S> SQL прекрасно вписывается в реляционность.
Еще бы SQL не вписался — он проектировался под реляционное исчисление.
S>XML вообще отстой проповедуемый M$. Это ты вообще зря. Мне кажется ты его не пользовал совсем — что так заявляешь. И проповедует его далеко не MS (и уж точно не он его придумал). Он на Unix платформах вообще помоему раньше появился.
S>То же документооборот решается на блобах с индексированными словосочетаниями яля Яндекс. Ну а 2 дня мало.
Яндекс — это если правильно понял не документооборот, а поисковая машина.
2 дня в упор — в самый раз. Учти — диплом защитил на ура — теперь кондидатскую писать буду.
Здравствуйте, Аноним, Вы писали:
А>Наверное это национальная забава — поиск единственного А>верного учения, методологии, языка программирования, ОС и пр... А>Нет и не будет универсального, удобного на все случаи А>жизни способа представлять данные. А>Конечно же, реляционное представление не может быть одинаково А>хорошим для любых задач, так же как и XML.
Ты меня не правильно понял. Моя задача — не найти универсальное решение, а очертить круг для которого то или иное (реляционное или нереляционное) решение подходит лучше. Что в моем дипломе XML оказался лучшим решением, чем реляционная структура — это я доказал.
А>Я понял, что у тебя возникла проблема, как эффективно хранить много деревьев.
А>Из моего лично опыта, в ИИ довольно часто встречается такая проблема. А>Попытаюсь описать эту проблему немного иначе. А>Частенько при создании сложных систем (не обязательно ИИ) А>есть некое явное, компактное и понятное описание метамодели знаний (иногда говорят о метазнаниях) А>и нужно эффективно работать с множеством частных случаев этой метамодели (instance). А>Когда все это обсуждается на бумаге и не задумываются о реализации, А>то нам доступны не только теории 1-го порядка (например исчисление предикатов 1-го порядка), А>но и теории 2-го и более высоких порядков. А>Что мы имеем доступного на компьютерах? А>Увы, ничего выше первого порядка мы реально работающего так и не имеем. А>Реляционные базы — это система первого порядка. А>Думаю одна из причин твоих проблем лежит в этой плоскости. А>Современные копьютеры очень плохи для описания метамоделей, А>метаметамоделей и далее. А>Как эффективно на современных компьютерах реализовать например А>исчисление предикатов 2-го порядка — это пока нерешенная проблема.
Очень точно все разложил по полочкам. Я интересовался вопросами ООБД и в частности их математическими аспектами. Все так как ты сказал. Нужны системы высших порядков. В частности с исследованиями этих областей знаний связывались разработчики ООБД. Некоторые даже достигли успехов, хоть и небольших.
А>Уверен, будь у тебя эффективная ООСУБД, ты бы в итоге столкнулся А>с похожими проблемами, что и с реляционными БД.
Да я и не спорю. Но у меня стоит конкретная задача — документооборот. Я думаю тут таких больших проблем с "порядками" не возникнет. Моя задача — заложить в систему гибкость и мне кажется реляционная база — путь к неуспеху (а может быть и провалу) проекта.
P.S. Если тебе известны некоторые публикации о тех вопросах, которые ты затронул — перечисли их, пожалуйста. Я буду очень признателен.
Здравствуйте, Аноним, Вы писали:
S>>XML вообще отстой проповедуемый M$. А> Это ты вообще зря. Мне кажется ты его не пользовал совсем — что так заявляешь. И проповедует его далеко не MS (и уж точно не он его придумал). Он на Unix платформах вообще помоему раньше появился.
В написании стандарта принимал участие в том числе и человек из микрософт.
Хотя это конечно же не гововрит о том что xml--отстой.
Здравствуйте, bravo, Вы писали:
B>Реально необходимо хранить гараздо больше семантической информации для адекватного представления информации.
Так в чем проблема?
Реляционный подход тем и хорош, что в этом представлении можно хранить любую информацию в любом количестве, причем этот подход очень хорошо формализован.
Вопрос лишь в трудозатратах.
B>P.S. "Понимание" смысла хранящейся информации позволяет запрашивать у системы ЛЮБУЮ информацию в терминах самой задачи (см. механизм запросов системы br-a-vo).
Ну с этим не поспоришь..
Здравствуйте, AndrewVK, Вы писали:
M>>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. AVK>Сможет, если немного повозится. Другое дело что в терминах ОО мыслить проще.
[+]
Проблема не в том, что реляционный подход недостаточно гибок, он гибок на столько на сколько это вообще возможно.
А в том, что пока не существует (а если и существует, то не реализован) универсальный механизм позволяющий переходить от реляционного представления к какому-нибудь более другому. Каждая частная задача OR Mapping'а — та еще головная боль.
Здравствуйте, Merle, Вы писали:
M>Проблема не в том, что реляционный подход недостаточно гибок, он гибок на столько на сколько это вообще возможно. M>А в том, что пока не существует (а если и существует, то не реализован) универсальный механизм позволяющий переходить от реляционного представления к какому-нибудь более другому. Каждая частная задача OR Mapping'а — та еще головная боль.
Тем не менее меппинг где нибудь делать нужно, поскольку диск принципиально плоское устройство. И ты надеешься что существует универсальный алгоритм этгго меппинга?
Здравствуйте, bravo, Вы писали:
B>Есть обработка данных, а есть интерпретация. B>В основе любой задачи лежит Модель Предметной Области (ПО), в не зависимости от того как она реализована. B>Реляционные СУБД хранят только фактические данные о ПО, Объектные СУБД в основе хранят только информацию об Объектах ПО. Реально необходимо хранить гараздо больше семантической информации для адекватного представления информации. B>Для простых задач способ представления и хранения информаци не критичен, для сложных (сильно связанных) задач без "правильного" (соответствующего действительности, а не текущего взгляда на проблему) представления информации нельзя создать устойчивую к изменениям систему — приходится постоянно модифицировать исходные структуры данных. Если же использовать соответствующие семантические принципы описания информации, то можно оперировать уже абстрагированными понятиями, что делает решение задачи инвариантным к изменяющимся условиям. (О-как B>P.S. "Понимание" смысла хранящейся информации позволяет запрашивать у системы ЛЮБУЮ информацию в терминах самой задачи (см. механизм запросов системы br-a-vo).
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
AVK> И ты надеешься что существует универсальный алгоритм этгго меппинга?
Алгоритм-то наверняка существует, проблема лишь в скорости.
Реляционный подход очень хорошо формализован, что позволило придумать для него кучу алгоритмов и вспомогательных механизмов повышающих производительность. Насколько я понимаю с объетным подходом пока что такой фокус не проходит.
Точнее может и проходит, но пока только для очень частных случаев, в то время как реляционный подход куда как более универсален и достойную производительность может показать практически на любой задаче.
А>Ну если так — были еще и так называемые сетевые БД (иерархические их частный случай). Однако ОО поддерживать они не могли — его как ты сказал не было. Это дела давно минувших дней.
Можно как угодно называть, главное принцип хранения и построения связей.
Так нормализация в РБД тянет за собой огромный индекс на подчиненные связи, где это как в нормальном программировании решается на двух напрвленными списками. Экономия на вставку и удаление, а так же надежность.
А>Тогда победил структурный подход. А репликацию ты по-моему зря сюда присоединил (это вообще ко всему относится, а не только к реляционным).
Репликация в РБД хорошо вписывается, т.к. связи построены с применением инндексов, а не прямой или коственной (номер записи) ссылки.
S>>XML вообще отстой проповедуемый M$. А> Это ты вообще зря. Мне кажется ты его не пользовал совсем — что так заявляешь. И проповедует его далеко не MS (и уж точно не он его придумал). Он на Unix платформах вообще помоему раньше появился.
Но его продвижение в Net (во многих случаях оправдан) иногда раздражает. Там где прекрасно вписывается бинарная сериализация. Еще один пример для переноса данных (репликация) и даже для хранения применяют XML. Но так как приходится его разбирать в память получают огромные тормоза. С тем же успехом можно выделять память под объекты в заранее выделенном куске памяти и доступ к объектам делать с поправкой на базовый адрес или применять отображаемые в память файлы. Причем там, где эта операция составляет несколько секунд, все происходит за 30 минут.
Теперь объясню почему мне не нравится SQL. Если посмотреть на затраты разбора инструкций Insert, Update итд при может тратится намного больше времени чем сама вставка. Я сторонник прямого доступа с ранним связыванием, особенно когда база не изменяется и не требуется работа с удаленными БД.
Рассуждения Программиста 1С. Не судите строго.
И когда приводят тесты со временем за часы сразу вспоминаю любимые ДВК-2.
Но у РБД очень много премуществ прежде всего в простоте использования и конфигурирования БД. А раз за этим еще стоят монстры индустрии то конкурирующие подходы не нужны. Хотя специализированные БД нужно писать с высокой оптимизацией с применением различных списфиских алгоритмов, где SQL и РБД сильно проигрывают особенно на сильно разветвленных БД и применеием иерархии (свинное ухо).
S>>То же документооборот решается на блобах с индексированными словосочетаниями яля Яндекс. Ну а 2 дня мало.
А> А>Яндекс — это если правильно понял не документооборот, а поисковая машина. А>2 дня в упор — в самый раз. Учти — диплом защитил на ура — теперь кондидатскую писать буду.
В документо оборот так же и входит поисковая машина. А хранеие документов в блобах самый оптимльнй путь с возможностью их быстрого поиска и классификации.
А>Если я неправ скажите.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Реляционный подход тем и хорош, что в этом представлении можно хранить любую информацию в любом количестве, причем этот подход очень хорошо формализован. M>Вопрос лишь в трудозатратах.
:) ;)
В конечном итоге все к ним и сводится (трудозатратам) ;)
Здравствуйте, Sinclair, Вы писали:
S>О-о-о, наш человек, наш. Все, сдаю английский и начинаю новую жизнь. Мое мнение
Спасибо, большое.
В списке литературы у вас в основном ACMовские издания. Что это такое знаю — на олимпиаду ездил 2 раза. Сейчас тренирую команду. Известны ли вам какие-либо книги переведенные на русский язык посвященные теоритическим аспектам ООБД?
Про "объектную" обертку над реляционными БД (чисто структурная реализация). Пытался реализовать нечто подобное летом. Пробовал на "обертке" решить задачу выборки фирм с телефонами начинающимися с цифр 35 (фирм 20000, телефонов 200000). Результаты впечатлили: Interbase и Oracle (!) упали (уснули и не проснулись). Аналогичное решение на SQL Servere отработало за 0,5 секунды.
В чем прикол — до сих пор не понял.
Здравствуйте, Morgun, Вы писали: M>В списке литературы у вас в основном ACMовские издания. Что это такое знаю — на олимпиаду ездил 2 раза. Сейчас тренирую команду. Известны ли вам какие-либо книги переведенные на русский язык посвященные теоритическим аспектам ООБД?
Увы, лично мне такие книги неизвестны. Более того, мне неизвестны даже англоязычные книги на эту тему. Ну, кроме собсно ODMG. M>Про "объектную" обертку над реляционными БД (чисто структурная реализация). Пытался реализовать нечто подобное летом. Пробовал на "обертке" решить задачу выборки фирм с телефонами начинающимися с цифр 35 (фирм 20000, телефонов 200000). Результаты впечатлили: Interbase и Oracle (!) упали (уснули и не проснулись). Аналогичное решение на SQL Servere отработало за 0,5 секунды. M>В чем прикол — до сих пор не понял.
Скорее всего какой-то стеб с индексами. Если вдруг для этого поля был хеш-индекс, то придется делать scan вместо seek. Хотя даже при table scan несчастные 200 килозаписей не должны смущать приличный сервер.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Так нормализация в РБД тянет за собой огромный индекс на подчиненные связи, где это как в нормальном программировании решается на двух напрвленными списками. Экономия на вставку и удаление, а так же надежность. S>Это заблуждение. Нормализация никакого отношения к индексам не имеет. В реляционной алгебре вообще нет такой сущности, как индекс. А нормализация определяется в терминах РА.
S>Индексы в реляционных базах введены как раз для ускорения операций. S>> Репликация в РБД хорошо вписывается, т.к. связи построены с применением инндексов, а не прямой или коственной (номер записи) ссылки. S>Ты, похоже, неправильно понимаешь термин "индекс". Индексы не имеют никакого отношения к репликации. Если ты имеешь в виду то, что записи идентифицируются первичным ключом, т.е. значениями атрибутов, то да — это помогает реплицироваться.
Я имею ввиду, что связи в РБД построены на первичных ключах (индексах, хэш таблиц) но в основном первичный ключ представляет индекс ( хотя в параддоксе это скорей всего иерархический массив), а не ссылках. Но например на многострочную часть документа обычно применяется составной индекс, а таковых записей за миллионы.
S>> Теперь объясню почему мне не нравится SQL. Если посмотреть на затраты разбора инструкций Insert, Update итд при может тратится намного больше времени чем сама вставка. Я сторонник прямого доступа с ранним связыванием, особенно когда база не изменяется и не требуется работа с удаленными БД. S>Ну давай посмотрим. Дла сверхкоротких запросов такая ситуация может иметь место, но таких запросов в конечной системе не может быть много. Для оптимизации фазы синтаксического разбора все современные СУБД предоставляют двухстадийный механизм — подготовку стейтмента, и собственно выполнение. Между первой и второй стадиями могут менять параметры, и вторую стадию можно выполнять многократно. Т.е. мы выполнили связывание, получив предкомпилированный запрос, и потом выполняем его миную синтаксический разбор.
Согласен. Но параметры все равно разбирать приходится. В итоге приходим в удаленным процедурам аля Net Remoting. И зачем тогда SQL нужен??? В большинстве случаев это уже жестко забитые запросы. Плюс ограничение на длину запроса и из-за этого различные ухищрения .
ООП уже сколько на дворе. А SQL непобедим. Особенно мне нравится смотреть на сложные запросы с огромным количеством подзапросов, джоинов и юнионов + темповых таблиц, или загрузка из текстовых данных и последнее время из XML.
По большому счету я не против РБД иногда без них никак, но против SQL. Хотя раньше был от него в восторге.
S>> И когда приводят тесты со временем за часы сразу вспоминаю любимые ДВК-2. S>Хм. Самый хреновый результат из опубликованных МС в TPC-C составляет около девяти тысяч транзакций в минуту. Сервер — машинка с гигагерцовым PIII. Т.е. послабже нонешнего десктопа. При этом транзакция — это нифига не инкремент каунтера, это ввод заказа на товар, средним размером 10 позиций, в систему, где параллельно выполняются еще всякие запросы. Может, я не так понял, и ты говоришь про XML?
На сайте Cashe. http://www.intersystems.ru/cache/cache_vs_oracle.html
S>> Но у РБД очень много премуществ прежде всего в простоте использования и конфигурирования БД. S>Ну естественно. На самом деле, в большинстве случаев попытка родить что-то свое приведет к тому, что либо пострадает надежность (ACID properties), либо производительность, либо и то и другое. А если вдруг удастся сохранить и то и другое, то внести любое изменение будет стоить просто безумных затрат.
А почему бы не разделить подходы. И не валить все в одну кучу.
S>>А раз за этим еще стоят монстры индустрии то конкурирующие подходы не нужны. S>Подходы — нужны. Иначе зачем монстрам развивать свои продукты?
Может Net сдвинет эту скалу. S>>Хотя специализированные БД нужно писать с высокой оптимизацией с применением различных списфиских алгоритмов, где SQL и РБД сильно проигрывают особенно на сильно разветвленных БД и применеием иерархии (свинное ухо). S>Согласен. РБД — не панацея. Просто потому, что большинство из них садится в лужу на "простейших" запросах типа select * from plane where (x-x0)*(x-x0)+(y-y0)*(y-y0)<R*R
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Увы, лично мне такие книги неизвестны. Более того, мне неизвестны даже англоязычные книги на эту тему. Ну, кроме собсно ODMG.
Жаль, жаль...
M>>Про "объектную" обертку над реляционными БД (чисто структурная реализация). Пытался реализовать нечто подобное летом. Пробовал на "обертке" решить задачу выборки фирм с телефонами начинающимися с цифр 35 (фирм 20000, телефонов 200000). Результаты впечатлили: Interbase и Oracle (!) упали (уснули и не проснулись). Аналогичное решение на SQL Servere отработало за 0,5 секунды. M>>В чем прикол — до сих пор не понял. S>Скорее всего какой-то стеб с индексами. Если вдруг для этого поля был хеш-индекс, то придется делать scan вместо seek. Хотя даже при table scan несчастные 200 килозаписей не должны смущать приличный сервер.
Да вот же — чушь какая-то. И запросы и структура — абсолютно идентичны. Даже планы исполнения запросов одинаковы. Я даже думал из-за машины. В трех местах проверил — везде так.
Sinclair, скажи пожалуйста, ты на как на вопросы ООБД вышел (из-за чего, кого)? Мне это очень интересно.
Здравствуйте, AndrewVK, Вы писали:
M>>Все это само собой. Но что в блобе то хранится — XML, например? Если так то структура уже не чисто реляционная. AVK>А про чистоту никто и не говорил. Разговор был про применимость.
Ну я про подход спрашивал: то что ты предложил — это гибрид. Согласен — это довольно хорошо работает.
M>>Хмм... Но 3NF там точно не пахло. AVK>А кто сказал что при использовании РСУБД нужна 3НФ?
Нам довольно сильно рекомендовали как наиболее "правильную" и применимую что-ли. Ни подумай ничего такого, слово "денормализация" мне тоже знакомо.
Здравствуйте, Morgun, Вы писали:
M>Sinclair, скажи пожалуйста, ты на как на вопросы ООБД вышел (из-за чего, кого)? Мне это очень интересно.
По историческим причинам. Начал коммерческое программирование с участия в команде разработчиков учетной системы. Парни, не испугавшись, взялись делать ORM. Корявый, медленный, глючный — он даже почти заработал.
С тех пор у меня зреет уверенность, что для успешной разработки приложений автоматизации бизнеса необходимо поддерживать ООП, т.к. в этой отрасли оно самое быстрое. А пропасть между интерфейсом, логикой и хранением меня удручает хуже горькой редьки.
Я хочу получить идеальную систему, в которой разработчик бизнес логики пишет свой кусок кода, размечает его атрибутами, которые сообщают остальной системе необходимую информацию, и инсталляет это в сервер. После чего у всех пользователей сервера сразу доступна расширенная функциональность.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Morgun, Вы писали:
S>Я хочу получить идеальную систему, в которой разработчик бизнес логики пишет свой кусок кода, размечает его атрибутами, которые сообщают остальной системе необходимую информацию, и инсталляет это в сервер. После чего у всех пользователей сервера сразу доступна расширенная функциональность.
Это желание делает тебе честь. Меня тоже удручает наличие указаных тобой "пропастей", хотя мой опыт как прикладного программиста еще не слишком велик.
Буду откровенен — поскольку сегодня меня зачислили в аспирантуру (официально) и мой руководитель (LaptevVV) настаивает на продолжении работ по развитию моего дипломного проекта, у меня появился (кроме практического — документооборот) еще и "чиста научный" интерес к этому вопросу (Напомню тема диплома — обучалка по "Технологии программирования").
Насколько я успел понять — вопрос хранения данных в настоящее время — один из краеугольных вопросов инжинерии ПО. И следовательно он обязательно должен быть хотя бы освящен в рамках диссера по этой тематике.
Больше всего меня огорчает тот факт, что русскоязычного сообщества занимающегося вопросами альтернативных способов хранения данных я не нашел. Может быть его нет в природе?
Кстати Sinclair ты не планируешь заняться этими вопросами с научной точки зрения (в смысле диссер защитить). Я думаю такой человек как ты смог бы — наработки у тебя уже есть.
M>Кстати Sinclair ты не планируешь заняться этими вопросами с научной точки зрения (в смысле диссер защитить). Я думаю такой человек как ты смог бы — наработки у тебя уже есть.
Здравствуйте, mikkri, Вы писали:
M>>Кстати Sinclair ты не планируешь заняться этими вопросами с научной точки зрения (в смысле диссер защитить). Я думаю такой человек как ты смог бы — наработки у тебя уже есть.
M>Звучит!
M>Против Sinclair ничего личного не имею.
Здравствуйте, Sinclair, Вы писали:
S>Ну вот мне осталось сдать английский язык для официального зачисления в аспирантуру, и ровно этим я и собираюсь заниматься. Собсно, реферат, который ты прочитал, мне пришлось написать при подаче документов в аспирантуру. Там и намечен план работ. Наработок, правда, пока ровно 0 — только вумные мысли. Но уже надо чево-то делать.
Значит коллеги.
Реферат я правда не писал — зачли статью про диплом.Английский сдать не так сложно — мне философия труднее далась (сдал на 5 но попотеть пришлось).
S>Пока не знаю, с какого конца браться: S>1. Надо проанализировать существующие системы на предмет отклонения от 11 требований.
Это обязательно. Но систем ООБД я не много знаю: чаще всего упоминают Cache, O2, Orion. Вживую не видел ни одного.
S>2. Скоро до нас должен доехать превью Yukon от MS. Есть мнение, что в него можно запихивать почти произаольный .NET код, что вызывает неудержимое желание набросать маппер из объектной модели в него, который уже будет поддерживать 11 требований.
Признаюсь о таком услышал впервые — если можно поподробнее. Если можешь дай пару ссылок на описания.
S>3. Надо попробовать наколбасить тестовые приложения. Я тут вплотную занялся чтением TPC-C, с целью критически его осмыслить. Уж очень мне подозрительно отсутствие всяких модных кашей в ихних списках. Хочу придумать достаточно компактный тест насчет 11 требований. Пока все как-то смутно.
Я думаю — для диссера (кандидатского) много приложений не надо. Надо одно, но достойное — желательно с применением к действительно практической задаче. Когда "наколбасишь" много (может быть с помощью своих аспирантов) — можешь докторскую защитить.
S>4. Теория. Читать, читать, и прикидывать, что из теорий применимо.
О теоретических аспектах — упомянуто у C.Кузнецова в статье на CITForumе (там даже ссылки есть). Вопрос был затронут и здесь.
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, Morgun, Вы писали:
M>Реферат я правда не писал — зачли статью про диплом.Английский сдать не так сложно — мне философия труднее далась (сдал на 5 но попотеть пришлось).
Не, я во-первых физик, а во-вторых — бакалавр выпуска 97го. А философия у нас — халява
S>>1. Надо проанализировать существующие системы на предмет отклонения от 11 требований. M>Это обязательно. Но систем ООБД я не много знаю: чаще всего упоминают Cache, O2, Orion. Вживую не видел ни одного.
Я видел Versant, сейчас стоит свежепоставленный Cache 5.1 single user. Вообще в списке предполагаемых жертв сейчас
M>Признаюсь о таком услышал впервые — если можно поподробнее. Если можешь дай пару ссылок на описания.
Спасибо Мальборо — он рядом положил ссылку.
M>Я думаю — для диссера (кандидатского) много приложений не надо. Надо одно, но достойное — желательно с применением к действительно практической задаче.
Вопрос интересный. Для меня главное — определить место этой технологии среди существующих. А то получается "да здравствует наша ОДБМС — самая быстрая среди нашей ОДБМС!" С этой точки зрения, надо хотя бы один тест провести на поле "хозяев", т.е. RDBMS. Если будет практическое применение, то надо честно показать, чем наша реализация лучше альтернативы (если она, конечно, лучше). С этим вообще беда — мне ни разу не удалось увидеть реализацию коммерческой системы хотя бы на Oracle и MS SQL — чтобы сравнить реальную проихводительность в конкретном случае. Слишком дорого оказывается. А если разрабатывать весь код в "режиме совместимости", то результат получится совершенно нерелевантным. В общем, нужно не просто доказательтво того, что базу Northwind можно наколбасить и в такой системе, а демонстрация преимуществ. M>Когда "наколбасишь" много (может быть с помощью своих аспирантов) — можешь докторскую защитить.
Да тут хотя бы что-то наколбасить... Гульбарий там собрать... А докторский саквояж мне, если чо, друзья купют. M>О теоретических аспектах — упомянуто у C.Кузнецова в статье на CITForumе (там даже ссылки есть). Вопрос был затронут и здесь.
Почитаю. Ты, кстати, кинь прямой линк на статью — а то там Кузнецов-то довольно много чего опубликовал.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я хочу получить идеальную систему, в которой разработчик бизнес логики пишет свой кусок кода, размечает его атрибутами, которые сообщают остальной системе необходимую информацию, и инсталляет это в сервер. После чего у всех пользователей сервера сразу доступна расширенная функциональность.
А чем это будет принципиально отличаться от EJB, если не секрет?
Здравствуйте, Sinclair, Вы писали:
S>2. Скоро до нас должен доехать превью Yukon от MS. Есть мнение, что в него можно запихивать почти произаольный .NET код, что вызывает неудержимое желание набросать маппер из объектной модели в него, который уже будет поддерживать 11 требований.
Гы . Вобще то юкон, судя по синтаксису, один черт может вернуть только датасет. Т.е. запуск нетовского кода выглядит так:
select * from DotNetClass
Здравствуйте, AndrewVK, Вы писали: AVK>А чем это будет принципиально отличаться от EJB, если не секрет?
Ну, вообще-то я написал в реферате список требований. Насколько я знаю, никакая реализация их не удовлетворяет. Если я ошибаюсь — можно меня ткнуть.
В частности, я не видел ни одного сервера, который умеет что-то типа
Здравствуйте, AndrewVK, Вы писали:
AVK>Гы . Вобще то юкон, судя по синтаксису, один черт может вернуть только датасет. Т.е. запуск нетовского кода выглядит так: AVK>select * from DotNetClass
Ну, вроде как так писать нельзя
Я пока что понял следующее:
1. Сторед процедуры можно будет писать на дотнете. При этом они могут делать все, что угодно, и даже возвращать resultset на клиента — точь-в-точь как обычные процедура на T-SQL. Но они должны быть статическими методами класса.
2. Функции теперь можно писать на дотнете. Причем как скалярные, так и датасетные. С теми же особенностями. Отличия — будет поддерживаться статистика и индексирование по функциям.
3. В сервере теперь можно хранить value-типы, в дополнение к встроенным.
Вот, в общем-то, и все. Никаких from DotNetClass писать нельзя, если только DotNetClass не имя таблицы или view. Дальше пока спекулировать смысла нету — надо щупать ево за мягкие места. А то, как известно, при смешивании килограмма повидла с килограммом дерьма получается два килограмма дерьма.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Все, что можно кверить — это поля. Что является вопиющим нарушением инкапсуляции.
в cachё можно методы класса в запросах использовать.
... << RSDN@Home 1.1 beta 2 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Все, что можно кверить — это поля. Что является вопиющим нарушением инкапсуляции.
Насколько я помню в EJB 2.0 добавлен язык запросов, EJB-QL. В частности селект имеет такой синтаксис:
SELECT OBJECT(variable)
FROM abstractSchemaName [AS] variable
[WHERE value comparison value]
где value:
The value can be a parameter, the result of a numeric or string function, a variable (e.g. hotel), a member inside this variable separated using the dot '.' operator (e.g. hotel.name), or a constant (e.g. 'Pleasant Inn', 23, TRUE).
Так что, насколько я понимаю, все EJB 2.0 compatible сервера должны такое уметь.
Здравствуйте, AndrewVK, Вы писали:
AVK>Или функция, которая может быть дотнетным классом .
Ну насколько я понимаю для этого дотнетный класс должен уметь сериализоваться в таблицу...
Здравствуйте, _MarlboroMan_, Вы писали: _MM_>в cachё можно методы класса в запросах использовать.
Еще раз — это статические невиртуальные методы! Кроме того, это не интерфейсы, а классы.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Так что, насколько я понимаю, все EJB 2.0 compatible сервера должны такое уметь.
А вот как у них интересно с производительностью таких запросов?
Если там реализована нормальная инкапсуляция, тгда кждое сравнение — это новый вызов метода, и индекс фиг построишь...
Здравствуйте, AndrewVK, Вы писали: AVK>Насколько я помню в EJB 2.0 добавлен язык запросов, EJB-QL. В частности селект имеет такой синтаксис:
AVK>
AVK>SELECT OBJECT(variable)
AVK>FROM abstractSchemaName [AS] variable
AVK>[WHERE value comparison value]
AVK>где value: AVK>
AVK>The value can be a parameter, the result of a numeric or string function, a variable (e.g. hotel), a member inside this variable separated using the dot '.' operator (e.g. hotel.name), or a constant (e.g. 'Pleasant Inn', 23, TRUE).
AVK>Так что, насколько я понимаю, все EJB 2.0 compatible сервера должны такое уметь.
Ну, все ODMG 1.0 совместимые сервера тоже должны такое уметь. Именно поэтому пока что никто не может похвастаться такой совместимостью. Как только увидишь хотя бы один, который и вправду может выполнить запрос по виртуальному методу — свистни, а?
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну как — функцию в юконе можно написать на дотнете.
Ну да. Но только она тогда будет статическим мембером класса. Что не есть класс. Когда я пишу select * from EmployeeClass, то я ожидаю, что инстансы EmployeeClass будут объектами "сотрудник". А фактически мы имеем просто некоторую функцию, которая где-то взяла какой-то рекрдсет и отдает его нам. При этом надо понять, что она никак не может вернуть "коллекцию дотнетовских классов". Она может вернуть набор записей, некоторые поля которых суть дотнет классы.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Merle, Вы писали:
M>Если там реализована нормальная инкапсуляция, тгда кждое сравнение — это новый вызов метода, и индекс фиг построишь...
Ну это уже чисто логическая проблема, конкретная реализация тут не при чем, выполнять такие запросы можно исключительно перебором.
Здравствуйте, Sinclair, Вы писали:
S>Ну, все ODMG 1.0 совместимые сервера тоже должны такое уметь. Именно поэтому пока что никто не может похвастаться такой совместимостью.
Нет, я к тому чтобы тебе хотя бы в архитектурном плане велосипедов не изобретать. А реализацию ты можешь конечно и свою придумать.
S>Как только увидишь хотя бы один, который и вправду может выполнить запрос по виртуальному методу — свистни, а?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AndrewVK, Вы писали:
AVK>>Ну как — функцию в юконе можно написать на дотнете. S>Ну да. Но только она тогда будет статическим мембером класса. Что не есть класс. Когда я пишу select * from EmployeeClass, то я ожидаю, что инстансы EmployeeClass будут объектами "сотрудник". А фактически мы имеем просто некоторую функцию, которая где-то взяла какой-то рекрдсет и отдает его нам.
Так и я о том же — юкон в деле создания OODBMS сильно не поможет, просто позволит проще писать ХП.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет, я к тому чтобы тебе хотя бы в архитектурном плане велосипедов не изобретать. А реализацию ты можешь конечно и свою придумать.
Я согласен. Вот только за 10 лет этот велосипед никто не сделал. Может, от того что постановка задачи неверна? Вот я и хочу пересмотреть это все.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я согласен. Вот только за 10 лет этот велосипед никто не сделал.
Ты знаешь, а на практике подобное вобщем то не особенно то и нужно, потому что делать такое можно только для небольших выборок, а небольшие можно и руками обработать.
S>Может, от того что постановка задачи неверна? Вот я и хочу пересмотреть это все.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>>Подходы — нужны. Иначе зачем монстрам развивать свои продукты? S>> Может Net сдвинет эту скалу.
AVK>Java пока не сдвинула.
А надежда теплится. С другой стороны DB 2 тоже Net приаттачивает. Может конкуренция и подстегнет к принципиально другому.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> А надежда теплится. С другой стороны DB 2 тоже Net приаттачивает. Может конкуренция и подстегнет к принципиально другому.
Здравствуйте, Sinclair, Вы писали:
S>>>1. Надо проанализировать существующие системы на предмет отклонения от 11 требований. M>>Это обязательно. Но систем ООБД я не много знаю: чаще всего упоминают Cache, O2, Orion. Вживую не видел ни одного. S>Я видел Versant, сейчас стоит свежепоставленный Cache 5.1 single user. Вообще в списке предполагаемых жертв сейчас S>
Откуда все это берешь? (возьмешь?)
M>>Признаюсь о таком услышал впервые — если можно поподробнее. Если можешь дай пару ссылок на описания. S>Спасибо Мальборо — он рядом положил ссылку.
Посмотрел — по всей видимости Microsoft идет тем же путем, что и в IIS/ASP.NET ("code behind page"). Немного не верится в рост производительности.
M>>Я думаю — для диссера (кандидатского) много приложений не надо. Надо одно, но достойное — желательно с применением к действительно практической задаче. S>Вопрос интересный. Для меня главное — определить место этой технологии среди существующих. А то получается "да здравствует наша ОДБМС — самая быстрая среди нашей ОДБМС!" С этой точки зрения, надо хотя бы один тест провести на поле "хозяев", т.е. RDBMS.
Абсолютно точно. Причем если этот тест будет в нашу пользу — технология уже имеет право на существование. Если нет — не все потеряно. Достаточно доказать, что производительность не будет резко с нижаться при увеличении объемов данных (сам знаешь — "математика в программировании").
Кроме того важен (я бы сказал он самый важный) аспект трудозатрат при реализации решения. "В этом случае на реализацию ушло такое количество ч/м (написано столько миллионов строк кода), а в этом столько то (столько тысяч строк кода)". Вопрос в необходимости и приемлимости нового метода снимется сам собой.
S>Если будет практическое применение, то надо честно показать, чем наша реализация лучше альтернативы (если она, конечно, лучше). С этим вообще беда — мне ни разу не удалось увидеть реализацию коммерческой системы хотя бы на Oracle и MS SQL — чтобы сравнить реальную проихводительность в конкретном случае. Слишком дорого оказывается. А если разрабатывать весь код в "режиме совместимости", то результат получится совершенно нерелевантным. В общем, нужно не просто доказательтво того, что базу Northwind можно наколбасить и в такой системе, а демонстрация преимуществ.
По поводу режима совместимости согласен. Если проект будет серьезный (и работать будет), то можно поискать его аналоги на рынке и попросить производителей расказать о преимуществах их системы и трудоемкости работ по ее созданию.
M>>Когда "наколбасишь" много (может быть с помощью своих аспирантов) — можешь докторскую защитить. S>Да тут хотя бы что-то наколбасить... Гульбарий там собрать... А докторский саквояж мне, если чо, друзья купют.
Хорошие друзья = залог успеха.
M>>О теоретических аспектах — упомянуто у C.Кузнецова в статье на CITForumе (там даже ссылки есть). Вопрос был затронут и здесь. S>Почитаю. Ты, кстати, кинь прямой линк на статью — а то там Кузнецов-то довольно много чего опубликовал.
M>Откуда все это берешь? (возьмешь?)
Пока не знаю Реально — скорее всего для большинства систем добудутся демки.
M>Абсолютно точно. Причем если этот тест будет в нашу пользу — технология уже имеет право на существование. Если нет — не все потеряно. Достаточно доказать, что производительность не будет резко с нижаться при увеличении объемов данных (сам знаешь — "математика в программировании"). M>Кроме того важен (я бы сказал он самый важный) аспект трудозатрат при реализации решения. "В этом случае на реализацию ушло такое количество ч/м (написано столько миллионов строк кода), а в этом столько то (столько тысяч строк кода)". Вопрос в необходимости и приемлимости нового метода снимется сам собой.
Полностью согласен с обоими высказываниями. M>Хорошие друзья = залог успеха. M>здесь M>и M>здесь
Спасибо.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
WC>Года два-три назад я плотненько знакомился с ООСУБД. Самой концептуально чистой и полной была Poet (споследствии переименованая в FastObjects). Есть основания полагать, что она таковой и осталась, потому как и темпы развития у нее повыше, чем у конкурентов. WC>Советую обратить внимание на них в первую очередь. WC>Что еще интересно, poet до какой-то версии поддерживало odmg (даже 3.0!!!), а затем от этой поддержки отказались. На наш вопрос "Почему?" был ответ — "Из-за слабой эффективности/производительности" .
Здравствуйте, Sinclair, Вы писали:
S>Я хочу получить идеальную систему, в которой разработчик бизнес логики пишет свой кусок кода, размечает его атрибутами, которые сообщают остальной системе необходимую информацию, и инсталляет это в сервер. После чего у всех пользователей сервера сразу доступна расширенная функциональность.
Это я так. Увидел краткое описание того, что у нас работает уже полтора года.
Идеала получить не удалось, потому что человеческий фактор и лень этому не очень способствуют
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Morgun, Вы писали:
M>>Реферат я правда не писал — зачли статью про диплом.Английский сдать не так сложно — мне философия труднее далась (сдал на 5 но попотеть пришлось). S>Не, я во-первых физик, а во-вторых — бакалавр выпуска 97го. А философия у нас — халява
S>>>1. Надо проанализировать существующие системы на предмет отклонения от 11 требований. M>>Это обязательно. Но систем ООБД я не много знаю: чаще всего упоминают Cache, O2, Orion. Вживую не видел ни одного. S>Я видел Versant, сейчас стоит свежепоставленный Cache 5.1 single user. Вообще в списке предполагаемых жертв сейчас S>
Интуитивно от успешной ООСУБД ожидается не менее высокая производительность, чем в РСУБД, так как первая должна включать возможности последней как частный, вырожденный случай объектной модели.
Весьма странный вывод. Обычно от реализации частного случая чего-либо ожидается более высокая производительность, чем от реализации общей модели, не правда ли?
P.S. Я не оспариваю преимущества ООБД при решении _определённого_ класса задач (сам когда-то работал с MUMPS), скорее, занудствую по поводу построения фразы
Re[3]: Что означает понятие skills в резюме для работодателя
Интуитивно от успешной ООСУБД ожидается не менее высокая производительность, чем в РСУБД, так как первая должна включать возможности последней как частный, вырожденный случай объектной модели.
A>Весьма странный вывод. Обычно от реализации частного случая чего-либо ожидается более высокая производительность, чем от реализации общей модели, не правда ли?
Возможно, я неудачно построил фразу. Смысл в том, что успешная ООСУБД не должна заставлять платить за то, чем не пользуешься. Если ты скомпилируешь С программу плюсовым компилятором, она не станет работать медленнее.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
допустим в базе 100000 заказов, по примерно 5 товаров в каждом
как быстро можно выбрать первые 10 из них, у которых хотя бы один заказанный товар имел стоимость > 1000
и еще один вопрос: есть ли поддержка версий документов?
чтоб можно было посмотреть историю изменений, откатить назад и т.д.
и соответственно какой-нть механизм публикации данных?
это я думаю — насколько возможно использование данной системы для создания сайтов
да, а как обстоят дела с правами?
как разграничить какие документы кто и где может создавать и что с ними вообще делать?
Re: Реляционное против нереляционного
От:
Аноним
Дата:
19.03.04 19:20
Оценка:
Здравствуйте, Morgun, Вы писали:
M>Проблема вернулась в новом лице после защиты. Новое лицо — документооборот. Хороший документооборот — гибкий документооборот. Формы и состав документов могут меняться во времени и это не должно отражаться на системе в целом.
Форма представления, не важно, на бумаге или на экране, не изменяет сущности понятий. К примеру, твой начальник, как был начальником, так им и останется, а как ты этот факт отобразиш потребителю информации — отдельная история.
M>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. Внутри нашего отдела АСУ не все разделяют это мнение разделяют.
Народ ночи не спит, книжки умные про проектирование БД пишет, да все без толку, учись читать правильно.
Если анализ проблемы позволяет выделить 1 или более неизменяемой структуры, стандартно их называют — сущности, и установить связи между ними, то такая проблема разрешима средствами реляционок, и более того, в большинстве случаев реляционная БД будет почти идеальным решением. Экзотические случаи, когда структура информации может кординально меняться от записи к записи, по большей части сводятся к стандартной теории введением некоторой избыточности. Из средств, предназначеных для обработки данных опираясь на структуру каждой конкретной записи, а не всей БД, наиболее на слуху — это XML. (Интересно, а еще что либо подобное есть?)
M>А что думает уважаемое сообщество? Кто имел опыт разработки с использованием XML и Объектно Ориентированных БД поделитесь опытом и ощущениями, пожалуйста.
Сорри за глупый вопрос, а что такое Объектно Ориентированные БД?
Здравствуйте, Аноним, Вы писали:
А>Форма представления, не важно, на бумаге или на экране, не изменяет сущности понятий. К примеру, твой начальник, как был начальником, так им и останется, а как ты этот факт отобразиш потребителю информации — отдельная история.
Спор не о внешнем предствлении, a о внутреннем. Начальник останется начальником. Документ останется документом, но состав документа может пояеняться.
Совершенно верно, Форма представления не определяет сущность — сущность определяет состав формы представления. А что если сущность может поменяться во времени? У нас это так. В РСУБД — ответ обычно в изменении структуры БД.
M>>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. Внутри нашего отдела АСУ не все разделяют это мнение разделяют. А>Народ ночи не спит, книжки умные про проектирование БД пишет, да все без толку, учись читать правильно.
Прочел и не одну — диссер пишу.
А>Если анализ проблемы позволяет выделить 1 или более неизменяемой структуры, стандартно их называют — сущности, и установить связи между ними, то такая проблема разрешима средствами реляционок, и более того, в большинстве случаев реляционная БД будет почти идеальным решением.
А кто спорит?
А> Экзотические случаи, когда структура информации может кординально меняться от записи к записи, по большей части сводятся к стандартной теории введением некоторой избыточности.
Что имелось в виду под стандартной теорией?
А> Из средств, предназначеных для обработки данных опираясь на структуру каждой конкретной записи, а не всей БД, наиболее на слуху — это XML. (Интересно, а еще что либо подобное есть?)
А структура записи не как не относится к структуре БД? А какже тогда 2НФ?
А>Сорри за глупый вопрос, а что такое Объектно Ориентированные БД?
Почитайте хотя бы на CitForume.
Re[3]: Реляционное против нереляционного
От:
Аноним
Дата:
20.03.04 09:22
Оценка:
Здравствуйте, Morgun, Вы писали:
M>Спор не о внешнем предствлении, a о внутреннем. Начальник останется начальником. Документ останется документом, но состав документа может пояеняться. M>Совершенно верно, Форма представления не определяет сущность — сущность определяет состав формы представления. А что если сущность может поменяться во времени? У нас это так. В РСУБД — ответ обычно в изменении структуры БД.
Когда я писал в первый раз, я всео лишь хотел сказать: Ни кто не утверждал, что РСУБД — решение всех проблем. Вы один из многих, кому довелось сталкнуться с ситуацией, когда это не работает. Распространеннось реляционных БД означает только то, что большинство задач укладываются в схему сущностей и отношений. Для остальных — всегда есть XML.
M>Что имелось в виду под стандартной теорией?
Теория, опираясь на которую строят реляционные БД.
В грубом приближении:
1. Анализируем возможные запросы к будущей системе, и групируем атрибуты в одну и более сущностей (Это не будут сущности в том смысле, к которому привыкли разработчики реляционок — потому что выбор количества таких атрибутов и их групировка в сущности в общем-то условны).
2. Устанавливаем связи между нашими псевдосущностями. (Здесь и возникает избыточность)
3. Атрибуты, не отнесенные ни к одной сущности храним в таблице вида: id, rec_id, attr_type, attr_value.
Далее можем использовать средства, ориентированные на РСУБД. Недостаток такой схемы — слишком медленно идет выборка по атрибутам не вошедшим ни в одну из сущностей.
M>А структура записи не как не относится к структуре БД? А какже тогда 2НФ?
А разве это не относится к реляционной модели?
Здравствуйте, Аноним, Вы писали:
А>Когда я писал в первый раз, я всео лишь хотел сказать: Ни кто не утверждал, что РСУБД — решение всех проблем. Вы один из многих, кому довелось сталкнуться с ситуацией, когда это не работает. Распространеннось реляционных БД означает только то, что большинство задач укладываются в схему сущностей и отношений. Для остальных — всегда есть XML.
Вот и хотелось бы выяснить где граница между задачами, где РСУБД применимы, а где нет. И какие подходы применимы за этой границей (кроме XML). Какие инструменты уже есть. Какие идеи есть, но еще не реализованы.
M>>Что имелось в виду под стандартной теорией? А>Теория, опираясь на которую строят реляционные БД.
Это просто неточность в формулировке была — я не сразу понял, что имеется в виду теория РСУБД — вот и уточнил.
M>>А структура записи не как не относится к структуре БД? А какже тогда 2НФ? А>А разве это не относится к реляционной модели?
Относится. НФ выработаны для реляционной модели. Я о записях.
Re[5]: Реляционное против нереляционного
От:
Аноним
Дата:
22.03.04 10:20
Оценка:
Здравствуйте, Morgun, Вы писали:
M>Вот и хотелось бы выяснить где граница между задачами, где РСУБД применимы, а где нет. И какие подходы применимы за этой границей (кроме XML). Какие инструменты уже есть. Какие идеи есть, но еще не реализованы.
Найдеш кричи. В свое время я пытался найти сервер, принмающий запросы на SQL подобном языки, и при этом использующий, к примеру, XML файлы в качестве хранилища. Не нашел.
M>Относится. НФ выработаны для реляционной модели. Я о записях.
Собственно, тогда о чем речь? Если мы говорим о РСУБД, тогда применим весь накопленый по этому поводу материал, к примеру — приведение к нормальным формам таблиц проекта. Если мы говорим о случаях неприменимости РСУБД, то стоит задуматься о признаках таких ситуаций. Один из таких признаков — невозможность определить фиксированную структуру записи, даже с разумной долей избыточности. (В качестве примера, можно взять формат ISO-2709, более извесный как MARC формат, служащий для обмена библиографической информацией. Стандартно определены ~150 атрибутов, которые могут использоваться, плюс к этому — они могут повторяться почти произвольное число раз, плюс к этому — допускается введение в систему атрибутов, определяемых администратором, при этом необходимо иметь возможность выборки и сортировки, хотябы по некоторым из атрибутов. Создать более менее стройную систему при такой постановке задачи, хотябы с 50% избыточности я не смог, по этой причине и пришлось искать обходные пути по прикручиванию SQL сервера к этому делу.)
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную. Зачем, собственно, мы тратим силы и средства для того чтобы притянуть зауши РСУБД для формализации всего этого?
Я типа сории.. но не могли бы вы мне сказать где можно почитать про иерархические модели данных? и есть ли какие-нибудь уже реализованные хранилищя построенные на этой модели?
Лучше умереть сидя чем жить стоя
Искусственный интеллект — ничто по сравнению с естественной глупостью http://www.bevip.ru
хъ
FT>Я типа сории.. но не могли бы вы мне сказать где можно почитать про иерархические модели данных? и есть ли какие-нибудь уже реализованные хранилищя построенные на этой модели?
Реестр, например! Про устройство можно почитать в книге Рассиновича и Соломона.
Более жизненый пример, NXD — Native XML Databases. Сейчас достаточно хороших реализаций уже с десяток. Поищи в гугле.
Здравствуйте, FruT, Вы писали:
AS>>Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную. Зачем, собственно, мы тратим силы и средства для того чтобы притянуть зауши РСУБД для формализации всего этого?
Согласен на все 100%
FT>Я типа сории.. но не могли бы вы мне сказать где можно почитать про иерархические модели данных? и есть ли какие-нибудь уже реализованные хранилищя построенные на этой модели?
Посмотрите базу данных Cache, причем именно в части глобалей и языка CacheScript.
Здравствуйте, Barmaglot, Вы писали:
A>>Посмотрите базу данных Cache, причем именно в части глобалей и языка CacheScript.
B>А потом ужастнитесь и забудте об этом, как о страшном сне.... И главное, главное! Никогда не вспоминайте.
Интересно почему должна быть такая реакция?
Есть ли какие-нибудь аргументы? или это личная неприязнь?
Здравствуйте, Barmaglot, Вы писали:
B>Здравствуйте, Alexey Shirshov, Вы писали:
AS>> Почему другие типы хранилищ не могут быть эффективнее (по производительности и объему данных)? B>Почему? Могут, но далеко не всегда... А реляционный подход более универсален он показывает наибольшую производительность в самом широком спектре приложений.
AS>> В чем секрет реляционного подхода, который дает ему неоспоримое преимущество над иерархическим, например. B>В универсальности.
AS>> Теория графов, на которой основаны иерархические СУБД старее реаляционной. Подобные системы появились значительно раньше чем РСУБД, следовательно опыт должен быть больше. B>Стех пор ка все осознали преимущества реляционного подхода, на иерархические и прочие сетевые СУБД конкретно забили, поэтому о большом опыте тут говорить не приходится.
AS>>Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную. B>Отнюдь не большинство. B>Весь кайф реляционного подхода именно в его универсальности, это еще дядя Кодд доказал на пальцах на своем знаменитом выступлении.
И при этом огромные затраты на подчиненные записи. Например сточная часть документа. И тянется огромный индекс на всю таблицу.
Сделав подчиненную таблицу ввиде двухнаправленного списка избавляемся от этого недостатка.
Реляционные базы это выхолощенные иерархические, где применяется очень маленький набор подходов. Да это надежно, но не эффективно.
Но позволить расширить набор не позволяет сам доступ к базе, а не только ее структура. Много говорилось об ООП в БД , который легко стоится и на реляционных базах, но нет доступа к данным на уровне локальных БД и гибкости обсчета данных. Сейчас наблюдается уклон в этом направлении всех производителей БД. AS>> Зачем, собственно, мы тратим силы и средства для того чтобы притянуть зауши РСУБД для формализации всего этого? B>Затем, что РСУБД тянутся хотя бы за уши, а все остальные, чаще всего, приходится тянуть за что-то более другое.
AS>>Я не вижу серьезных аргументов, почему РСУБД должны быть быстрее иерархических. B>Потому что большинство проблем свести к иерархическим СУБД окажется сложнее. Там где проще с иерархией — иерархические СУБД действительно рулят, но таких задач на удивление мало.
AS>> Просто иерархическая модель более гибкая чтоли. B>Как раз наоборот. Из всех известных, на данный момент, моделей работы с данными самой гибкой является реляционная.
AS>> На дворе 21 век! B>Yes, I do, а что толку?
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Re[7]: Реляционное против нереляционного
От:
Аноним
Дата:
25.03.04 10:53
Оценка:
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Я вот не понимаю, почему мы должны выбирать реляционные хранилища с введением "разумной доли избыточности". Почему другие типы хранилищ не могут быть эффективнее (по производительности и объему данных)? В чем секрет реляционного подхода, который дает ему неоспоримое преимущество над иерархическим, например. Теория графов, на которой основаны иерархические СУБД старее реаляционной. Подобные системы появились значительно раньше чем РСУБД, следовательно опыт должен быть больше.
Проблема не в теоретическом подходе, по крайней мере для меня, а в распространенности. Сколько есть систем, поддерживающих SQL, а сколько вы знаете иерархических БД? AS>Большинство понятий окружающего мира лучше всего вписываются именно в иерархическую модель, нежели реляционную.
Спорное утверждение, на мой взгляд. AS>Я не вижу серьезных аргументов, почему РСУБД должны быть быстрее иерархических. И там и там можно строить индексы, и там и там можно выполнять запросы. Просто иерархическая модель более гибкая чтоли. Реляционная модель, при всем моем уважении к ней, является подмножеством иерархической. Это подмножество специально было введено для упрощения работы с данными. Но ведь когда это было? На дворе 21 век!
Еще раз повторюсь, проблема в распространенности реализаций. На сегодняшний день подавляющее большинство серверов БД — реляционные, не зависимо от того, правильно или нет это с точки зрения теории.
Здравствуйте, Serginio1, Вы писали:
B>>Весь кайф реляционного подхода именно в его универсальности, это еще дядя Кодд доказал на пальцах на своем знаменитом выступлении. S> И при этом огромные затраты на подчиненные записи. Например сточная часть документа. И тянется огромный индекс на всю таблицу. S> Сделав подчиненную таблицу ввиде двухнаправленного списка избавляемся от этого недостатка.
И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы. Да, запрос "дай мне строки этого документа" выполнтся немножко быстрее, из-за того, что не надо сканировать индексные страницы. Но как ты собрался выполнять запрос "найти самую раннюю дату, когда продавался заданный товар", если строка документа — это ссылка на товар, а дата есть только в самом документе?
В реляционном хранилище есть возможность индивидуального доступа к строкам документа (что и требует, собственно, наличия ссылки вверх в каждой из них), а в двусвязном списке приходится навигироваться вдоль все тех же путей.
Конечно, мы можем построить вторичный индекс и для такой схемы хранения, но преимущества подхода начнут очень-очень быстро исчезать. Фактически, это предоставление привилегированного положения одной из связей в модели. Это сулит существенное усложнение оптимизатора (по сравнению с generic-вариантом), а фактический выигрыш оказывается невелик. S> Реляционные базы это выхолощенные иерархические, где применяется очень маленький набор подходов. Да это надежно, но не эффективно.
Нет. Мы же это уже обсуждали! От того, что ты делаешь однопользовательскую базу без транзакций на двусвязных списках, и она опережает СУБД с поддержкой ACID на некоторых видах запросов не означает, что RDBMS неэффективны. Иначе бы на www.tpc.org они бы сейчас не рулили. Хочется опровергнуть — вперед, там лежат полные описания тестов. Берите конфигурацию из тех, что подоступнее, и воспроизводите. Если удастся хотя бы 50% самого низкого перформанса получить, то уже можно присматривать роллс-ройс или астон-мартин присматривать. S> Но позволить расширить набор не позволяет сам доступ к базе, а не только ее структура. Много говорилось об ООП в БД , который легко стоится и на реляционных базах, но нет доступа к данным на уровне локальных БД и гибкости обсчета данных. Сейчас наблюдается уклон в этом направлении всех производителей БД.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
B>>>Весь кайф реляционного подхода именно в его универсальности, это еще дядя Кодд доказал на пальцах на своем знаменитом выступлении. S>> И при этом огромные затраты на подчиненные записи. Например сточная часть документа. И тянется огромный индекс на всю таблицу. S>> Сделав подчиненную таблицу ввиде двухнаправленного списка избавляемся от этого недостатка. S>И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы. Да, запрос "дай мне строки этого документа" выполнтся немножко быстрее, из-за того, что не надо сканировать индексные страницы. Но как ты собрался выполнять запрос "найти самую раннюю дату, когда продавался заданный товар", если строка документа — это ссылка на товар, а дата есть только в самом документе?
Легко. Обычно выделяется группа документо удовлетворяющие данной дате а потом идет сканирование по подчиненным записям. S>В реляционном хранилище есть возможность индивидуального доступа к строкам документа (что и требует, собственно, наличия ссылки вверх в каждой из них), а в двусвязном списке приходится навигироваться вдоль все тех же путей.
Двух связный список находится в таблице. Тот же самый обход с чтением данных блоками. S>Конечно, мы можем построить вторичный индекс и для такой схемы хранения, но преимущества подхода начнут очень-очень быстро исчезать. Фактически, это предоставление привилегированного положения одной из связей в модели. Это сулит существенное усложнение оптимизатора (по сравнению с generic-вариантом), а фактический выигрыш оказывается невелик.
Ну да многомиллионный индекс это не выигрыш??? Да опять же ты мыслишь оптимизатором. Интересно когда ты просто выбираешь алогритм при программировании ты оборачиваешься на оптимизатор????
S>> Реляционные базы это выхолощенные иерархические, где применяется очень маленький набор подходов. Да это надежно, но не эффективно. S>Нет. Мы же это уже обсуждали! От того, что ты делаешь однопользовательскую базу без транзакций на двусвязных списках, и она опережает СУБД с поддержкой ACID на некоторых видах запросов не означает, что RDBMS неэффективны. Иначе бы на www.tpc.org они бы сейчас не рулили. Хочется опровергнуть — вперед, там лежат полные описания тестов. Берите конфигурацию из тех, что подоступнее, и воспроизводите. Если удастся хотя бы 50% самого низкого перформанса получить, то уже можно присматривать роллс-ройс или астон-мартин присматривать.
Берем комплексную 1С. А там связей ... Большинство работает на ДБФ+TSE. Это быстрее, хотя и не надежно. Для того, что бы сделать базу нормальной заточенной под SQL нужно потратить огромное количество времени и не факт, что удастся.
Смесь Запросов и курсоров при обсчете на сервере сразу бы решила огромное количество проблем, в том числе и применение не стандартых связей итд.
А кто мешает совершенствовать доступ к БД с транзакциями итд. То что работает в RDBMS наработано лет 20 назад. А других походов пруд пруди.
Но зачем что то совершенствовать???? Конечно легче всего скачивать данные на клиента, а потом по образу работы с локальными базами обсчитывать результаты. Будем надеятся что конкуренция сподвигнет многих на другие подходы.
S>> Но позволить расширить набор не позволяет сам доступ к базе, а не только ее структура. Много говорилось об ООП в БД , который легко стоится и на реляционных базах, но нет доступа к данным на уровне локальных БД и гибкости обсчета данных. Сейчас наблюдается уклон в этом направлении всех производителей БД.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы. Да, запрос "дай мне строки этого документа" выполнтся немножко быстрее, из-за того, что не надо сканировать индексные страницы. Но как ты собрался выполнять запрос "найти самую раннюю дату, когда продавался заданный товар", если строка документа — это ссылка на товар, а дата есть только в самом документе? S> Легко. Обычно выделяется группа документо удовлетворяющие данной дате а потом идет сканирование по подчиненным записям.
Да я все понимаю. Вот только RDBMS выберет ту стратегию, которая быстрее для данного случая. Первым будет выполнен самый селективный запрос. Возможно, документы без данного товара вообще не будут сканироваться. S> Двух связный список находится в таблице. Тот же самый обход с чтением данных блоками.
Да с этим-то я согласен. Только в середину двусвязного списка прыгнуть нельзя. S> Ну да многомиллионный индекс это не выигрыш??? Да опять же ты мыслишь оптимизатором. Интересно когда ты просто выбираешь алогритм при программировании ты оборачиваешься на оптимизатор????
Что такое "многомиллионный индекс"???? Возьми СУБД и оцени объем индекса по инту для миллиона записей. По сравнению с исходной таблицей. При чем здесь выбор алгоритма??? S> Берем комплексную 1С. А там связей ... Большинство работает на ДБФ+TSE. Это быстрее, хотя и не надежно. Для того, что бы сделать базу нормальной заточенной под SQL нужно потратить огромное количество времени и не факт, что удастся.
Да факт, факт. Просто в свое время про...ли время на DBF. Вот теперь и показывают отвратительное масштабирование. S> Смесь Запросов и курсоров при обсчете на сервере сразу бы решила огромное количество проблем, в том числе и применение не стандартых связей итд.
А кто мешает совершенствовать доступ к БД с транзакциями итд. То что работает в RDBMS наработано лет 20 назад. А других походов пруд пруди. S> Но зачем что то совершенствовать???? Конечно легче всего скачивать данные на клиента, а потом по образу работы с локальными базами обсчитывать результаты. Будем надеятся что конкуренция сподвигнет многих на другие подходы.
Ты уже определись, что критикуешь. 1С — отстой, никто и не спорит. Но они не пользуются RDBMS! В этом и состоит их проблема. Поэтому критиковать RDBMS c оглядкой на 1С — ошибка.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы. Да, запрос "дай мне строки этого документа" выполнтся немножко быстрее, из-за того, что не надо сканировать индексные страницы. Но как ты собрался выполнять запрос "найти самую раннюю дату, когда продавался заданный товар", если строка документа — это ссылка на товар, а дата есть только в самом документе? S>> Легко. Обычно выделяется группа документо удовлетворяющие данной дате а потом идет сканирование по подчиненным записям. S>Да я все понимаю. Вот только RDBMS выберет ту стратегию, которая быстрее для данного случая. Первым будет выполнен самый селективный запрос. Возможно, документы без данного товара вообще не будут сканироваться.
Ну если так уж хочется все обставить индесами, то двухсвяхные списки не помеха, та же таблица. S>> Двух связный список находится в таблице. Тот же самый обход с чтением данных блоками. S>Да с этим-то я согласен. Только в середину двусвязного списка прыгнуть нельзя.
Ну да у тебя огромные подчиненные записи. И насколько это нужно. S>> Ну да многомиллионный индекс это не выигрыш??? Да опять же ты мыслишь оптимизатором. Интересно когда ты просто выбираешь алогритм при программировании ты оборачиваешься на оптимизатор???? S>Что такое "многомиллионный индекс"???? Возьми СУБД и оцени объем индекса по инту для миллиона записей. По сравнению с исходной таблицей. При чем здесь выбор алгоритма???
Тады два инта (и еще номер записи). Тыже на середину документа прыгать хочешь. Тут AVK недавно считал так у него трилионы записей вышли. Но обновление индекса тебя не тревожит ????? S>> Берем комплексную 1С. А там связей ... Большинство работает на ДБФ+TSE. Это быстрее, хотя и не надежно. Для того, что бы сделать базу нормальной заточенной под SQL нужно потратить огромное количество времени и не факт, что удастся. S>Да факт, факт. Просто в свое время про...ли время на DBF. Вот теперь и показывают отвратительное масштабирование. S>> Смесь Запросов и курсоров при обсчете на сервере сразу бы решила огромное количество проблем, в том числе и применение не стандартых связей итд. S> А кто мешает совершенствовать доступ к БД с транзакциями итд. То что работает в RDBMS наработано лет 20 назад. А других походов пруд пруди. S>> Но зачем что то совершенствовать???? Конечно легче всего скачивать данные на клиента, а потом по образу работы с локальными базами обсчитывать результаты. Будем надеятся что конкуренция сподвигнет многих на другие подходы. S>Ты уже определись, что критикуешь. 1С — отстой, никто и не спорит. Но они не пользуются RDBMS! В этом и состоит их проблема. Поэтому критиковать RDBMS c оглядкой на 1С — ошибка.
Ну насчет отстоя я бы не сказал. Вполне приличная архитектура (правда изначально была заточена на ДБФ), но и 8 ке не сильно то они и ушли.
Почему это не пользуются??? Просто беда в том, что тянут на клиента много. Вот в 8 ке трехзвенку делают. А под SQL тоже большинство работает через TSE.
Да и разговор идет о том, что RDBMS хорошо, но большее ее расширение еще лучше. Просто RDBMS это просто подвид иерархических БД.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
Да ты все за РСУБД, а посмотри сколько на XML делается и ничего ты не против.
Иерархические БД намного интереснее XML как по хранению данных так и скорости доступа.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Sinclair, Вы писали: S> Да ты все за РСУБД, а посмотри сколько на XML делается и ничего ты не против.
В смысле? Никаких ни OLTP ни OLAP систем на XML не существует. Он прекрасен как медленный транспорт в гетерогенных средах. S> Иерархические БД намного интереснее XML как по хранению данных так и скорости доступа.
Согласен. Но опять же, критика XML ничем не помогает в доказательстве недостатков RDBMS
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, Alexey Shirshov, Вы писали:
[]
А>Еще раз повторюсь, проблема в распространенности реализаций. На сегодняшний день подавляющее большинство серверов БД — реляционные, не зависимо от того, правильно или нет это с точки зрения теории.
Мы спорим о том что более распространено на данный момент? Я нет, а ты?
Я высказал мысли о том, что возможно иерархические БД (понятное дело на основе XML Infoset или другой XML data model) будут теснить реляционный как по степени распространнености, так и по другим (техническим) показателям. Для этого я не вижу никаких препядствий.
хъ
S>И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы.
С чего то?
S>Да, запрос "дай мне строки этого документа" выполнтся немножко быстрее, из-за того, что не надо сканировать индексные страницы. Но как ты собрался выполнять запрос "найти самую раннюю дату, когда продавался заданный товар", если строка документа — это ссылка на товар, а дата есть только в самом документе?
Не понял. Если ты клонишь к тому, что индексы могут существовать только в реляционной модели — твои заблуждения не знают границ!
S>В реляционном хранилище есть возможность индивидуального доступа к строкам документа (что и требует, собственно, наличия ссылки вверх в каждой из них), а в двусвязном списке приходится навигироваться вдоль все тех же путей.
Ты про sequental acess и random access? Опять не понимаю, почему random access связывается у тебя исключительно с РБД.
S>Конечно, мы можем построить вторичный индекс и для такой схемы хранения, но преимущества подхода начнут очень-очень быстро исчезать.
Почему?
S>Фактически, это предоставление привилегированного положения одной из связей в модели. Это сулит существенное усложнение оптимизатора (по сравнению с generic-вариантом), а фактический выигрыш оказывается невелик.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>>>Да я все понимаю. Вот только RDBMS выберет ту стратегию, которая быстрее для данного случая. Первым будет выполнен самый селективный запрос. Возможно, документы без данного товара вообще не будут сканироваться. S>> Ну если так уж хочется все обставить индесами, то двухсвяхные списки не помеха, та же таблица. S>ничего не понял.
Двухсвязный список хранится в таблице. Где записи связязаны через поля. Кстати такой связь существует в парадоксовской базе, и используется при обходе по первичному индексу. S>>>Да с этим-то я согласен. Только в середину двусвязного списка прыгнуть нельзя. S>> Ну да у тебя огромные подчиненные записи. И насколько это нужно. S>Я тебе привел пример. Вот такой вот возник ad-hoc запрос. И решение с двусвязным списком начинает резко сливать, поскольку другую стратегию сканирования выбрать уже нельзя.
Ничего оно не сливает. Хочешь делай индекс, а лучше используй OLAP итд. Это одна из организаций хранения данных. S>>>Что такое "многомиллионный индекс"???? Возьми СУБД и оцени объем индекса по инту для миллиона записей. По сравнению с исходной таблицей. При чем здесь выбор алгоритма??? S>> Тады два инта (и еще номер записи). Тыже на середину документа прыгать хочешь. Тут AVK недавно считал так у него трилионы записей вышли. Но обновление индекса тебя не тревожит ????? S>Да не тревожит меня обновление индекса! Эта операция вообще практически ничего не стоит! Стоят только обращения к диску. А их не более 3х на модификацию индекса. Зато потом чтений многократно меньше.
В многопользовательской среде, приперестроении индекса при переполнении страницы будет как минимум на 2 больше. И почему тебя не удивляет, что Б+ деревья во всяком случае на нижнем уровне это двух связный список?????? Двухсвязные списки есть и используются напрополую.
А чтений будет столько же сколько и при двухсвязном списке, т.к. номер записи в таблице ты получаешь из индекса. S>>>Ты уже определись, что критикуешь. 1С — отстой, никто и не спорит. Но они не пользуются RDBMS! В этом и состоит их проблема. Поэтому критиковать RDBMS c оглядкой на 1С — ошибка. S>>Ну насчет отстоя я бы не сказал. Вполне приличная архитектура (правда изначально была заточена на ДБФ), но и 8 ке не сильно то они и ушли. S>> Почему это не пользуются??? Просто беда в том, что тянут на клиента много. Вот в 8 ке трехзвенку делают. А под SQL тоже большинство работает через TSE. S>Вот я и говорю — отстой. Передовые ребята уже отходят от трехуровневой архитектуры, потому как она недостаточно гибкая, а 1С все еще продвигают решения в терминах файл-сервера и ISAM. Понимаешь, их проблема ровно в том же, что и у предлагаемых тобой иерархических БД. Только они засасывают справочник из DBF, а потом делают по нему фильтр, а ты предлагаешь засасывать его из двусвязного списка. Ключ к успеху — это декларативное проектирование. Именно оно позволяет серверу выбрать наилучший в данном контексте способ добиться требуемого. В отличие от императивного программирования, которое ограничивает деятельность системы жесткими рамками.
Ты глубоко ошибаешься. Никто ни чего не засасывает. Тот же курсор по индексу и с блокировкой на запись, но можно зная формат хранения и засасывать но это уже изыски, или через API засасывать данные как это делается и в SQL, но это исключение чем правило. И вообще выбор записей в локальных БД и SQL ничем не отличаются, кроме того что блокировки идут на уровне файлов, а не например критических секций или эвентов, как это лего сделать при клиент серверной архитектуре. S>> Да и разговор идет о том, что RDBMS хорошо, но большее ее расширение еще лучше. Просто RDBMS это просто подвид иерархических БД. S>Я согласен с тем, что большее расширение RDBMS — это хорошо. Но не в сторону иерархических БД, упаси байт! Кстати, именно в эту сторону SQL-99 двигается. Ха-ха. Я посмотрю на него лет через 10. S>Я кстати тебе вообще очень рекомендую книгу Гарсиа-Молина и других. Как курс по проектированию СУБД, а не БД. Там про все это очень подробно рассказано. И про XML, и про иерархии, и про структурированные файлы.
Спасибо, но почемуто я лучше Вирта,Бакнелла,Сэждвика почитаю. Просто БД это один из подвидов программирования. Теже структуры, связи, блокировки транзакции итд. И еще раз повторю RDBMS это подвид Иерархических БД. Б+ деревья это яркий пример использования прямой иерархии, но не применяемый в таблицах, кроме ссылок на блоб поля.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
хъ
S>Я тебе привел пример. Вот такой вот возник ad-hoc запрос. И решение с двусвязным списком начинает резко сливать, поскольку другую стратегию сканирования выбрать уже нельзя.
Я не понимаю, откуда взялся список?
хъ
S>Я согласен с тем, что большее расширение RDBMS — это хорошо. Но не в сторону иерархических БД, упаси байт!
Ну никто не настаивает. Продолжай изучение РСУБД.
S> Кстати, именно в эту сторону SQL-99 двигается. Ха-ха. Я посмотрю на него лет через 10.
А я на тебя.
S>Я кстати тебе вообще очень рекомендую книгу Гарсиа-Молина и других.
Кстати, не очень книжка. Даже с точки зрения реляционной теории, не говоря уж о объектных СУБД.
S>Как курс по проектированию СУБД, а не БД. Там про все это очень подробно рассказано. И про XML, и про иерархии, и про структурированные файлы.
Если тебе хватило про xml того, что там написано на 3-х страничках, тогда для меня твои доводы перестают быть удивительными.
Что бы закончить эту тему. То отличие иерархических БД (в моем понимании) отличается только различием связей. Если в обычных РБД это первичный индекс то в иерархических РБД это пряммая ссылка на запись и соответственно применение различных структур. Но при добавлении уникального индекса она лекго превращается в обычную РБД когда нужен обмен между базами или репликация. Но при работе в своей базе скорость получения ссыочной записи возрастает. Так же как и в обычном программировании для связей по некоторому ID использутся хэш таблицы и Б+ деревья, но ссылки на объек идут через указатель. Представь какие были бы тормоза если вместо ссылки на объект записывался его ID в хэш таблице?????
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Что бы закончить эту тему. То отличие иерархических БД (в моем понимании) отличается только различием связей.
Ок. Вот только кажется мне, что это называется не иерархическими, а сетевыми БД (в первых основная концепция — не указатель, а принадлежность кортежа другому). Ну, да это вопрос терминологический.
В таком случае фактически ты предлагаешь хранить такой специальный тип данных "RID", который будет указывать прямо на физический локейшн кортежа? В каких-то случаях это может привести к повышению производительности. В некоторых — к снижению.
Интересно, почему же вместо него используются FK? Надо покопать в эту сторону.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Что бы закончить эту тему. То отличие иерархических БД (в моем понимании) отличается только различием связей. S>Ок. Вот только кажется мне, что это называется не иерархическими, а сетевыми БД (в первых основная концепция — не указатель, а принадлежность кортежа другому). Ну, да это вопрос терминологический. S>В таком случае фактически ты предлагаешь хранить такой специальный тип данных "RID", который будет указывать прямо на физический локейшн кортежа? В каких-то случаях это может привести к повышению производительности. В некоторых — к снижению. S>Интересно, почему же вместо него используются FK? Надо покопать в эту сторону.
Это связано прежде всего с обменом. FK для ссылочной целостности и его можно строить и на RID. Но никто же не мешает для каждой записи иметь уникальный ключ аналог PK как для репликации. Вот у меня хренова куча разнородных баз и для обмена существуют уникальные ключи состоящие из двух полей автоинкремента и ID базы. (вернее все в одну строку).
Но на RID можно делать более хитрые связи и структуры таблиц и при этом полностью соответствовать классическим РБД. Но это уже в компетенции разработчиков.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Что бы закончить эту тему. То отличие иерархических БД (в моем понимании) отличается только различием связей. S>Ок. Вот только кажется мне, что это называется не иерархическими, а сетевыми БД (в первых основная концепция — не указатель, а принадлежность кортежа другому). Ну, да это вопрос терминологический. S>В таком случае фактически ты предлагаешь хранить такой специальный тип данных "RID", который будет указывать прямо на физический локейшн кортежа? В каких-то случаях это может привести к повышению производительности. В некоторых — к снижению.
Вот только назови эти случаи. Сам по себе RID уникален и должен прописываться вместе с записью как PK это нужно для апдейтов при корректировке записи клиентом. Для совмещения с другими базами и репликации придется делать еще поле и индекс. Да при этом вставка и модификация несколько (а может и нет, т.к. на RID не нужно строить индекс, а при изменении не надо лезть в индекс для поиска записи). Но при этом джойны уверяю вырастут в разы.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Serginio1, Вы писали:
S>>> Что бы закончить эту тему. То отличие иерархических БД (в моем понимании) отличается только различием связей. S>>Ок. Вот только кажется мне, что это называется не иерархическими, а сетевыми БД (в первых основная концепция — не указатель, а принадлежность кортежа другому). Ну, да это вопрос терминологический. S>>В таком случае фактически ты предлагаешь хранить такой специальный тип данных "RID", который будет указывать прямо на физический локейшн кортежа? В каких-то случаях это может привести к повышению производительности. В некоторых — к снижению. S> Вот только назови эти случаи. Сам по себе RID уникален и должен прописываться вместе с записью как PK это нужно для апдейтов при корректировке записи клиентом. Для совмещения с другими базами и репликации придется делать еще поле и индекс. Да при этом вставка и модификация несколько (а может и нет, т.к. на RID не нужно строить индекс, а при изменении не надо лезть в индекс для поиска записи). Но при этом джойны уверяю вырастут в разы.
Вернее будет сказать не совсем, так как при репликации между базами в ссылочных полях придется вместо RID вставлять PK а при модификации по PK находить или вставлять запись и вписываь RID. Соответственно это несколько сложнее. Поэтому и оставили в таком виде. И соответственно иерархические БД связаны с этими проблемами. Но на мой взгляд это не такая уж и проблема.
Если же репликации нет то и проблем нет вообще.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
S>>И получаем в награду кучу других. Видишь ли, любой другой сторадж встревает с тем, чтобы выполнять разные запросы. AS>С чего то?
Судьба такой.
AS>Не понял. Если ты клонишь к тому, что индексы могут существовать только в реляционной модели — твои заблуждения не знают границ!
Нет, это ты сам придумал..
Что тебе даст индекс в иерархической системе? В идеальном случае опять получится та же реляционка, только с дополнительным геморроем по обеспечению иерархии. Так зачем платить больше?
AS>Ты про sequental acess и random access? Опять не понимаю, почему random access связывается у тебя исключительно с РБД.
Ну сделай эффективный sequental acess по иерархической БД, а я на тебя посмотрю.
AS>Почему?
Потому что в итоге ты получишь ту же реляционку.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>xml как транспорт конечно прекрасен, но его возможности значительно превосходят данный аспект.
Ага, только к OLTP и OLAP его возможности имеют очень мало отношения.
Здравствуйте, Serginio1, Вы писали:
S> Но при этом джойны уверяю вырастут в разы.
Заблуждаешься. Ты даже не представляешь, какой выигрыш дает при join'е оптимизация с учетом B tree индекса и твоя схема по сравнению с этим — просто детский лепет.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Я не понимаю, откуда взялся список?
Читай внимательно.
AS>Кстати, не очень книжка. Даже с точки зрения реляционной теории, не говоря уж о объектных СУБД.
А читать пробовал?
Здравствуйте, Barmaglot, Вы писали:
B>Здравствуйте, Serginio1, Вы писали:
S>> Но при этом джойны уверяю вырастут в разы. B>Заблуждаешься. Ты даже не представляешь, какой выигрыш дает при join'е оптимизация с учетом B tree индекса и твоя схема по сравнению с этим — просто детский лепет.
Раскажи поподробнее об оптимизации с учетом B+ дерева, вместо прямой ссылки. Вот программисты тупые держат всегда прямые ссылки на объект (хотя это и виртуальный адрес), вместо Хэш таблицы или Б+ дерева в памяти????
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали: S> Вот только назови эти случаи. Сам по себе RID уникален и должен прописываться вместе с записью как PK это нужно для апдейтов при корректировке записи клиентом. Для совмещения с другими базами и репликации придется делать еще поле и индекс. Да при этом вставка и модификация несколько (а может и нет, т.к. на RID не нужно строить индекс, а при изменении не надо лезть в индекс для поиска записи). Но при этом джойны уверяю вырастут в разы.
Ну, во-первых, размер RID как минимум в 4 раза больше стандартного INT, который используется для FK. Насчет индексов ты не прав — без них ты не обеспечишь ссылочную целостность. Что ты будешь делать, когда удаляется запись? Правильно, для всех FK, которые ссылаются на ее отношение, нужно проверить exists(select * from referrer where FK = @PK). Так что индекс — нужен. Если ты имел в виду индекс по PK, который требовался для обеспечения уникальности — тут да, есть некоторая экономия. Выращивание джойнов в разы — это самообман. Проценты — это более точная оценка. А для кластерного индекса (который, обыкновенно, и делается для PK) разница будет еще меньше. Если ты в этом не уверен, то я тебе намекну — стоимость join зависит только от количества сканируемых страниц. Вот и оцени разницу для clustered int PK и для 16-byte RID. Никаких разов, уверяю тебя, ты даже в некластерном варианте не получишь.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Вот только назови эти случаи. Сам по себе RID уникален и должен прописываться вместе с записью как PK это нужно для апдейтов при корректировке записи клиентом. Для совмещения с другими базами и репликации придется делать еще поле и индекс. Да при этом вставка и модификация несколько (а может и нет, т.к. на RID не нужно строить индекс, а при изменении не надо лезть в индекс для поиска записи). Но при этом джойны уверяю вырастут в разы. S>Ну, во-первых, размер RID как минимум в 4 раза больше стандартного INT, который используется для FK.
Зачем ему быть таким же большим, если это только номер записи???? Являющийся и уникальным ID.
S> Насчет индексов ты не прав — без них ты не обеспечишь ссылочную целостность. Что ты будешь делать, когда удаляется запись? Правильно, для всех FK, которые ссылаются на ее отношение, нужно проверить exists(select * from referrer where FK = @PK). Так что индекс — нужен. Если ты имел в виду индекс по PK, который требовался для обеспечения уникальности — тут да, есть некоторая экономия. Выращивание джойнов в разы — это самообман. Проценты — это более точная оценка.
Почему то я тебе не верю. Или опыт у меня маленький. Проигрыш Б+ деревьев по отношению Хэш таблицы в 4 раза, а разница хэш таблиц по сравнению с массивом это уже десятки раз. При этом учитывая что данные либо кэшируются а памяти (либо кэшируются на файловом уровне либо как в SQL на уровне страниц впринципе механизм одинаковый) и при работе с кэшированными данными разница весьма ощутима, даже не с кэшированными данными с RID это один доступ, с Б+ деревом как минимум 2 (проход по дереву + прыжок на запись). А джойны самая дорогая операция.
Ну а для FK можно делать и более сложные структуры. В любом случае FK по RID не проблема.
S>А для кластерного индекса (который, обыкновенно, и делается для PK) разница будет еще меньше. Если ты в этом не уверен, то я тебе намекну — стоимость join зависит только от количества сканируемых страниц. Вот и оцени разницу для clustered int PK и для 16-byte RID. Никаких разов, уверяю тебя, ты даже в некластерном варианте не получишь.
Ну да и много у тебя клястерных индексов????? Давай посчитаем соотношения. Кроме всего прочего никто не мешает производить разные дейстия поиск в зависимости от метаданных либо прямая ссылка, либо поикс в кластерном индексе
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>Ну, во-первых, размер RID как минимум в 4 раза больше стандартного INT, который используется для FK. S> Зачем ему быть таким же большим, если это только номер записи???? Являющийся и уникальным ID.
Ну а как ты хотел? Либо это — физический указатель на запись, который самодостаточен для ее извлечения. Тогда в него включен идентификатор БД, файла, страницы в файле, и номер записи в странице. Не меньше 16 байт! А если это — всего лишь "номер записи" — тогда, извини, никакого выигрыша не будет. Знаешь, почему? Да потому, что его придется преобразовывать каким-то образом в RID! А это и есть индекс, от которого ты стараешься избавиться. S> Почему то я тебе не верю. Или опыт у меня маленький. Проигрыш Б+ деревьев по отношению Хэш таблицы в 4 раза, а разница хэш таблиц по сравнению с массивом это уже десятки раз. При этом учитывая что данные либо кэшируются а памяти (либо кэшируются на файловом уровне либо как в SQL на уровне страниц впринципе механизм одинаковый) и при работе с кэшированными данными разница весьма ощутима, даже не с кэшированными данными с RID это один доступ, с Б+ деревом как минимум 2 (проход по дереву + прыжок на запись). А джойны самая дорогая операция.
Опыт у тебя маленький. Ты считаешь не те операции. При работе в памяти соотношения будут похожие. Но как только ты залудишь работу со страничным кэшем, как в настоящих серверах, соотношения станут совсем другими. Я не могу понять, почему ты не хочешь читать учебники. Фраза про "два доступа для B+ против одного для RID" ясно это показывает. При выполнении Join никаких проходов и прыжков не делается. Правильный способ оценить — посчитать общее количество сканируемых страниц. Ты что, вправду думаешь, что B+ tree индекс удвоит количество страниц? Ну сходи в MS SQL Enterprize Manager — там есть страничка, которая показывает размеры таблиц и индексов. А сколько раз там на каждую страницу косвенная адресация в CPU происходит — никого не интересует. Не влияет это на стоимость.
S> Ну да и много у тебя клястерных индексов?????
Да мне ровно 1 хватит! Индекс по PK! Ты пойми, что вся разница между твоим подходом и моим — это индексация по PK. Потому, что индексация по FK все равно нужна, RID это или Identity. S>Давай посчитаем соотношения. Кроме всего прочего никто не мешает производить разные дейстия поиск в зависимости от метаданных либо прямая ссылка, либо поикс в кластерном индексе
Да не спорю я. Просто твои ожидания различий в быстродействии RID против кластерных индексов основаны на заблуждениях.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Barmaglot, Вы писали:
S>> И при этом огромные затраты на подчиненные записи. Например сточная часть документа. И тянется огромный индекс на всю таблицу. B>Какие затраты? Какой индекс? Ничего никуда не тянется...
Реляционная таблица в принципе не может быть быстрой без индекса.
Так что без индексов нет ни одной реляционной базы данных, а вот их количество определяется требованием к скорости обработки.
S>> Сделав подчиненную таблицу ввиде двухнаправленного списка избавляемся от этого недостатка. B>Она и так в виде этого списка, если очень захотеть. B>Ты пытаешся изложить преимущества конкретныого подхода для решения конкретной задачи, это не серьезно. Ты в одном месте в ручную, под свою задачу с оптимизировал, хитрой реализацией двунаправленного списка — другие задачи тут же сливают на этой же реализации. B>Вся сила РСУБД в универсальности, оди одинаково хорошо побходят для подавляющего ольшинства задач.
Универсальность и достигается за счет повышения сложности, увеличения подтаблиц и огромного количества индексов.
Плата за это — огромный рост базы данных и серьезное повышение аппартных требований.
Правда огромный плюс: РСУБД работают одиннаково медленно на любых задачах — плата за универсальность.
S>> Реляционные базы это выхолощенные иерархические, где применяется очень маленький набор подходов. Да это надежно, но не эффективно. B>Это очень эффективно, потому как быстро, просто и надежно.
Про эффективность говорить не приходится.
Самая крутая РСУБД Oracle "работает одиннаково медленно" на любом объеме данных — описание дано программистом довольно двано работающим с Oracle.
При правильном использовании (как и в любой задаче) применение иерархических СУБД дает примерно выигрыш от 20 до 50 раз по скорости работы (при тех же аппаратно-технических требованиях)
Примеры можно взять из многочисленных success story например на сайте www.instersystems.ru
Если не смотреть на забугорников — то достаточно посмотреть на последние billing системы российских разработчиков (http://www.mobill.ru/csp/komta/index.csp) — просто перевод с SQL базы на эмуляцию SQL на иерархии.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>Ну, во-первых, размер RID как минимум в 4 раза больше стандартного INT, который используется для FK. S>> Зачем ему быть таким же большим, если это только номер записи???? Являющийся и уникальным ID. S>Ну а как ты хотел? Либо это — физический указатель на запись, который самодостаточен для ее извлечения. Тогда в него включен идентификатор БД, файла, страницы в файле, и номер записи в странице. Не меньше 16 байт! А если это — всего лишь "номер записи" — тогда, извини, никакого выигрыша не будет. Знаешь, почему? Да потому, что его придется преобразовывать каким-то образом в RID! А это и есть индекс, от которого ты стараешься избавиться.
Это делается за счет кэширования информации о страницах в виде массива, как для файловых страниц так и для страниц сервера. И доступ осуществляется как RID shr 13 получаем адрес страницы.
( при 8 кб размере страницы) и RID AND ((1 SHL 13)-1). Как видишь за две операции получаем нужныю страницу и положение в ней. S>> Почему то я тебе не верю. Или опыт у меня маленький. Проигрыш Б+ деревьев по отношению Хэш таблицы в 4 раза, а разница хэш таблиц по сравнению с массивом это уже десятки раз. При этом учитывая что данные либо кэшируются а памяти (либо кэшируются на файловом уровне либо как в SQL на уровне страниц впринципе механизм одинаковый) и при работе с кэшированными данными разница весьма ощутима, даже не с кэшированными данными с RID это один доступ, с Б+ деревом как минимум 2 (проход по дереву + прыжок на запись). А джойны самая дорогая операция. S>Опыт у тебя маленький. Ты считаешь не те операции. При работе в памяти соотношения будут похожие. Но как только ты залудишь работу со страничным кэшем, как в настоящих серверах, соотношения станут совсем другими. Я не могу понять, почему ты не хочешь читать учебники. Фраза про "два доступа для B+ против одного для RID" ясно это показывает. При выполнении Join никаких проходов и прыжков не делается. Правильный способ оценить — посчитать общее количество сканируемых страниц. Ты что, вправду думаешь, что B+ tree индекс удвоит количество страниц? Ну сходи в MS SQL Enterprize Manager — там есть страничка, которая показывает размеры таблиц и индексов. А сколько раз там на каждую страницу косвенная адресация в CPU происходит — никого не интересует. Не влияет это на стоимость.
Понимаешь я сам работаю с файлами, работаю со страницами и могу сказать, что при кэшированных страниц очень быстро. Как доступ так и запись.
Если же использовать B+ tree вместо RID разница сразу бросается в глаза. ( правда к миллионам записей)
Говоря о нехватке памяти то 64 процессоры снимают эти ограничения и все идут к этому. Так что все о чем ты говоришь это уже анахронизм.
Объясни механизм Select d.Docid,s.Descr,d.Количество,r.Descr
From d,s,r
Where (D.Toard=S.ID) and (D.Изм=r.ID) ??????
То есть никаких прыжков ???? Все очень плавно при ID PK или RID. S>> Ну да и много у тебя клястерных индексов????? S>Да мне ровно 1 хватит! Индекс по PK! Ты пойми, что вся разница между твоим подходом и моим — это индексация по PK. Потому, что индексация по FK все равно нужна, RID это или Identity. S>>Давай посчитаем соотношения. Кроме всего прочего никто не мешает производить разные дейстия поиск в зависимости от метаданных либо прямая ссылка, либо поикс в кластерном индексе S>Да не спорю я. Просто твои ожидания различий в быстродействии RID против кластерных индексов основаны на заблуждениях.
Кроме всего прочего на RID действительно объектный код быдет работать намного быстрее и не отличатся от обычного объектного программирования.
А вот теперь Этот же самый запрос но усложненный кодга в зваисимости от товара нужно вычислять еще кучу всяких данных и ветвления могут быть очень разнообразными и одним запросом не обойтись либо на каждом шаге генерить новые и с клиента, как впрочем это делается и сейчас.
Второй вопрос как поступать с неопределенными полями когда поле может ссылаться на разные таблицы ????
Опять клиент, опять индекс.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, avbochagov, Вы писали:
A>Универсальность и достигается за счет повышения сложности, увеличения подтаблиц и огромного количества индексов. A>Плата за это — огромный рост базы данных и серьезное повышение аппартных требований. A>Правда огромный плюс: РСУБД работают одиннаково медленно на любых задачах — плата за универсальность.
Да-да-да. Может, Cache таки выйдет из тени, и займет хотя бы 50е место на www.tpc.org?
A>Про эффективность говорить не приходится. A>Самая крутая РСУБД Oracle "работает одиннаково медленно" на любом объеме данных — описание дано программистом довольно двано работающим с Oracle. A>При правильном использовании (как и в любой задаче) применение иерархических СУБД дает примерно выигрыш от 20 до 50 раз по скорости работы (при тех же аппаратно-технических требованиях) A>Примеры можно взять из многочисленных success story например на сайте www.instersystems.ru
Ну, во-первых, можно спросить, с чего вдруг Cache стала "иерархической СУБД"? Таких вольностей себе даже маркетологи не позволяют. Или ты все не-RDBMS называешь "иерархическими"?
Далее, ты не мог бы все-таки привести ссылки на конкретные success stories, где есть выигрыш от 20 до 50 раз по скорости работы по сравнению с RDBMS? Я с пяток просмотрел бегло — нету таких цифир. Там вообще про производительность нема. A>Если не смотреть на забугорников — то достаточно посмотреть на последние billing системы российских разработчиков (http://www.mobill.ru/csp/komta/index.csp) — просто перевод с SQL базы на эмуляцию SQL на иерархии.
Хм. На самом сайте нет никаких упоминаний про переход с чего-то на Cache. И никаких сравнений производительности тоже нету.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Прошу прощения конечно S> Это делается за счет кэширования информации о страницах в виде массива, как для файловых страниц так и для страниц сервера. И доступ осуществляется как RID*RecordSize shr 13 получаем адрес страницы. S> ( при 8 кб размере страницы) и RID*RecordSize AND ((1 SHL 13)-1). Как видишь за две операции получаем нужныю страницу и положение в ней.
Причем в массиве информации о страницах может содержаться информация не только о расположении страницы в файле но и о информации о кэшированной страницы в памяти (так оно наверное и есть). Для примера такой вариант работает в http://www.rsdn.ru/Forum/Message.aspx?mid=450320&only=1
Здравствуйте, Serginio1, Вы писали: S> Это делается за счет кэширования информации о страницах в виде массива, как для файловых страниц так и для страниц сервера. И доступ осуществляется как RID shr 13 получаем адрес страницы. S> ( при 8 кб размере страницы) и RID AND ((1 SHL 13)-1). Как видишь за две операции получаем нужныю страницу и положение в ней.
Да причем тут кэширование??? Какой еще массив? Я тебя спрашиваю, RID у тебя физический? Из формулы вроде физический. И ты правда думаешь, что тебе хватит под него 32 бита? Это уж совсем убогонькая БД получается. Для очень упрощенных случаев. Напрмер, что файлов в ней не может быть несколько. Ну и т.д. S> Понимаешь я сам работаю с файлами, работаю со страницами и могу сказать, что при кэшированных страниц очень быстро. Как доступ так и запись.
Блин, ты меня уже утомил. Ты пойми, что кэширование никакого отношения к объему перелопачиваемой информации не имеет! Потому, что оно применяется и для RDBMS, и для того, что ты по какой-то ошибке называешь "иерархическими СУБД". Вопрос в количестве этих самых страниц! S> Если же использовать B+ tree вместо RID разница сразу бросается в глаза. ( правда к миллионам записей)
Ну приведи примеры-то! Вот я иду и смотрю в Enterprize Manager. S> Говоря о нехватке памяти то 64 процессоры снимают эти ограничения и все идут к этому. Так что все о чем ты говоришь это уже анахронизм.
Ну-ну. Снимают они. Ты что думаешь, 1GB физической памяти как-то лучше работать станет под 64 разрядами, чем под 32мя? Это заблуждение.
Объясни механизм
Select d.Docid,s.Descr,d.Количество,r.Descr
From d,s,r
Where (D.Toard=S.ID) and (D.Изм=r.ID) ??????
А чего тут объяснять? Тебе надо рассказать как работает Join? Или что? Или тебя берут сомнения в том, что для выполнения join при помощи RID тебе потребуется чего-то меньше делать? Ясен пень, что по S.ID и по D.ID у нас как раз будут кластерные индексы (или ты сомневаешься?). Ок, я тут взял методику подсчета размера кластерного индекса из инструкции к MS SQL. Так вот, для данных размером в 1 мегабайт размер B+ tree clustered index равен примерно 1 странице. А для одного гигабайта данных у нас потребуется ажно 326 страниц, или 0.2 процента от самих данных. Вот тебе и ответ на вопрос, в какие разы RID эффективнее. Именно столько процентов придется прибавить к затратам на сканирование табличек R и D. Я не вижу тут способа как-то радикально изменить ситуацию. S> Кроме всего прочего на RID действительно объектный код быдет работать намного быстрее и не отличатся от обычного объектного программирования.
Так, не надо мне тут тему менять. То, что ты называешь "объектным кодом", люди называют Navigational Queries (ты уж извини, пришлось маленько твои мысли почитать). Это для случаев, когда используются именно указатели, и джойны типа "select from owner where owner->car->color = 'red'" — большая редкость по сравнению с разымемнованием указателя. Да, в таких случаях имеет смысл применять несколько другой подход к физической организации данных — см. Versant. Но я никак не вижу, каким боком это относится к
1. иерархическим СУБД
2. превосхоству системы с RID — адресацией над RDBMS.
Я тебе, кстати, тайну открою — в версанте внутри реляционный движок используется, и предикатный поиск сделан ровно через него S> А вот теперь Этот же самый запрос но усложненный кодга в зваисимости от товара нужно вычислять еще кучу всяких данных и ветвления могут быть очень разнообразными и одним запросом не обойтись либо на каждом шаге генерить новые и с клиента, как впрочем это делается и сейчас.
А вот в этом случае CPU cost начинает играть некоторую роль. Тем не менее, ты все равно должен прочитать 1GB c диска. Пойми, что никакого отношения к тому, как реализованы ссылки — через FK/PK или через RID — это отношения не имеет. Ты пытаешься свалить в одну кучу термины из совершенно разных слоев модели. Ну почитай учебники-то наконец! Я уже скоро свою ODBMS рисовать начну, мне соратники нужны будут.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали: S> Причем в массиве информации о страницах может содержаться информация не только о расположении страницы в файле но и о информации о кэшированной страницы в памяти (так оно наверное и есть). Для примера такой вариант работает в http://www.rsdn.ru/Forum/Message.aspx?mid=450320&only=1
S> очень быстрый доступ, не сравним с Б+ деревьями.
Ты что-то путаешь. Не надо сравнивать упражнения по доступу в оперативке с файловым обменом. То, что B+ tree не рулит для оперативки, известно лет тридцать как. Накладные расходы на них в случае дисковой подсистемы пренебрежимо малы.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Это делается за счет кэширования информации о страницах в виде массива, как для файловых страниц так и для страниц сервера. И доступ осуществляется как RID shr 13 получаем адрес страницы. S>> ( при 8 кб размере страницы) и RID AND ((1 SHL 13)-1). Как видишь за две операции получаем нужныю страницу и положение в ней. S>Да причем тут кэширование??? Какой еще массив? Я тебя спрашиваю, RID у тебя физический? Из формулы вроде физический. И ты правда думаешь, что тебе хватит под него 32 бита? Это уж совсем убогонькая БД получается. Для очень упрощенных случаев. Напрмер, что файлов в ней не может быть несколько. Ну и т.д.
Ну насчет нескольких файлов это да. А насчет множества таблиц в одном файле то информация о расположении страниц таблицы кэшируется в массиве от 0..N. Легким движением мы находим индекс в массиве из него получаем информацию о расположении страницы в файле и если страница загружена в память то ее адрес. S>> Понимаешь я сам работаю с файлами, работаю со страницами и могу сказать, что при кэшированных страниц очень быстро. Как доступ так и запись. S>Блин, ты меня уже утомил. Ты пойми, что кэширование никакого отношения к объему перелопачиваемой информации не имеет! Потому, что оно применяется и для RDBMS, и для того, что ты по какой-то ошибке называешь "иерархическими СУБД". Вопрос в количестве этих самых страниц!
Ну извини. Не хотел утомлять. S>> Если же использовать B+ tree вместо RID разница сразу бросается в глаза. ( правда к миллионам записей) S>Ну приведи примеры-то! Вот я иду и смотрю в Enterprize Manager.
Да при чем здесь перелоапченные страницы??? Как раз при кэшировании это мало влияет, так как работаешь с памятью а здесь уже другие критерии. А у тебя в есть RID ???? То есть в индесе то он есть, и для тебя легче добраться до RID через Б+ легче чем прямое применение??? S>> Говоря о нехватке памяти то 64 процессоры снимают эти ограничения и все идут к этому. Так что все о чем ты говоришь это уже анахронизм. S>Ну-ну. Снимают они. Ты что думаешь, 1GB физической памяти как-то лучше работать станет под 64 разрядами, чем под 32мя? Это заблуждение. S> Объясни механизм S>
S> Select d.Docid,s.Descr,d.Количество,r.Descr
S> From d,s,r
S> Where (D.Toard=S.ID) and (D.Изм=r.ID) ??????
S>
S>А чего тут объяснять? Тебе надо рассказать как работает Join? Или что? Или тебя берут сомнения в том, что для выполнения join при помощи RID тебе потребуется чего-то меньше делать? Ясен пень, что по S.ID и по D.ID у нас как раз будут кластерные индексы (или ты сомневаешься?). Ок, я тут взял методику подсчета размера кластерного индекса из инструкции к MS SQL. Так вот, для данных размером в 1 мегабайт размер B+ tree clustered index равен примерно 1 странице. А для одного гигабайта данных у нас потребуется ажно 326 страниц, или 0.2 процента от самих данных. Вот тебе и ответ на вопрос, в какие разы RID эффективнее. Именно столько процентов придется прибавить к затратам на сканирование табличек R и D. Я не вижу тут способа как-то радикально изменить ситуацию.
Еще раз. Кластерный индек насколько я помны это запись в в Б+ дереве. Ты не путаешь с хэш таблицами???? S>> Кроме всего прочего на RID действительно объектный код быдет работать намного быстрее и не отличатся от обычного объектного программирования. S>Так, не надо мне тут тему менять. То, что ты называешь "объектным кодом", люди называют Navigational Queries (ты уж извини, пришлось маленько твои мысли почитать). Это для случаев, когда используются именно указатели, и джойны типа "select from owner where owner->car->color = 'red'" — большая редкость по сравнению с разымемнованием указателя. Да, в таких случаях имеет смысл применять несколько другой подход к физической организации данных — см. Versant. Но я никак не вижу, каким боком это относится к
S>1. иерархическим СУБД S>2. превосхоству системы с RID — адресацией над RDBMS. S>Я тебе, кстати, тайну открою — в версанте внутри реляционный движок используется, и предикатный поиск сделан ровно через него S>> А вот теперь Этот же самый запрос но усложненный кодга в зваисимости от товара нужно вычислять еще кучу всяких данных и ветвления могут быть очень разнообразными и одним запросом не обойтись либо на каждом шаге генерить новые и с клиента, как впрочем это делается и сейчас.
Вот любители SQL или без него навигацию, обсчет итд никак нельзя. Вот бедные обычные программисты используют хэш таблицы для группирования данных,
массивы для хранения, указатели для связей и никак не поймут, что такая же организация данных намного легче и быстрее обсчитывается в SQL.
Что Select это круче чем Foreach, а оптимзатор сделает очень крутую работу. Правда не пойму почему нет стандартных Б+ деревьев в памяти или двухуровнего его аналога. Если бы доступ к данным на стороне сервера был таким же как и в локальных БД я бы и без SQL легко обошелся бы. Понятно что с таким доступом и использования процесса сервера сразу мног проблем, но тот же Юкон хоть самую малость но уже позволяет использовать объектные подходы. S>А вот в этом случае CPU cost начинает играть некоторую роль. Тем не менее, ты все равно должен прочитать 1GB c диска. Пойми, что никакого отношения к тому, как реализованы ссылки — через FK/PK или через RID — это отношения не имеет. Ты пытаешься свалить в одну кучу термины из совершенно разных слоев модели. Ну почитай учебники-то наконец! Я уже скоро свою ODBMS рисовать начну, мне соратники нужны будут.
Вот интересно напридумывали всяких терминов которые в обычном программировании совсем по другому называются. А вот превосходство от применения RID прежде всего будет наблюдаться при объектном а не SQL подходе вот о чем я речь веду. Хотя организация хранения доступа итд останется тойже самой. Курсоры же никто не отменял. А построить объектную модель над РБД это как два пальца, но на стороне сервера.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Причем в массиве информации о страницах может содержаться информация не только о расположении страницы в файле но и о информации о кэшированной страницы в памяти (так оно наверное и есть). Для примера такой вариант работает в http://www.rsdn.ru/Forum/Message.aspx?mid=450320&only=1
S>> очень быстрый доступ, не сравним с Б+ деревьями. S>Ты что-то путаешь. Не надо сравнивать упражнения по доступу в оперативке с файловым обменом. То, что B+ tree не рулит для оперативки, известно лет тридцать как. Накладные расходы на них в случае дисковой подсистемы пренебрежимо малы.
Вот именно, что 30 лет назад. Сейчас и FAT32 кэшируется не только на уровне цепочек страниц и но и на уровне их загрузки в память на уровне файл маппинг и запись происходит в странцы в памяти а на диск записывается ассинхронно. Как и слежение за выгрузкой малоиспользуемых страниц при нехватке памяти. А уж на уровне сервера это все уже продумано давно. При этом повторюсь при 64 битных ОС и процессоров дисковые проблемы вообще отходят на задний план.
Вот пример http://www.rsdn.ru/forum/Message.aspx?mid=556030&only=1
Здравствуйте, Serginio1, Вы писали: S> Ну насчет нескольких файлов это да. А насчет множества таблиц в одном файле то информация о расположении страниц таблицы кэшируется в массиве от 0..N. Легким движением мы находим индекс в массиве из него получаем информацию о расположении страницы в файле и если страница загружена в память то ее адрес.
Отлично. Ну вот и посчитай размер этого массива по сравнению с размером B+ дерева. Как насчет динамики? Когда мы удаляем запись? Массив остается неизменным? S> Да при чем здесь перелоапченные страницы??? Как раз при кэшировании это мало влияет, так как работаешь с памятью а здесь уже другие критерии. А у тебя в есть RID ???? То есть в индесе то он есть, и для тебя легче добраться до RID через Б+ легче чем прямое применение???
Нет, не легче. Я тебе еще раз говорю — затраты на добирание через B+ по сравнению с прямым обращением — доли процента. S> Еще раз. Кластерный индек насколько я помны это запись в в Б+ дереве. Ты не путаешь с хэш таблицами????
Я-то ничего не путаю. Я тебе привел результаты расчета объема того самого B+ дерева, которое используется для кластерного индекса. Формулы здесь. S>>> Кроме всего прочего на RID действительно объектный код быдет работать намного быстрее и не отличатся от обычного объектного программирования. S> Вот любители SQL или без него навигацию, обсчет итд никак нельзя. Вот бедные обычные программисты используют хэш таблицы для группирования данных, S>массивы для хранения, указатели для связей и никак не поймут, что такая же организация данных намного легче и быстрее обсчитывается в SQL.
Именно. S> Что Select это круче чем Foreach, а оптимзатор сделает очень крутую работу.
Естественно сделает! И Select порвет твой foreach просто невероятным образом. Почему-то все корпоративные решения в развитом мире делаются именно на Select, а не на Foreach. S>Правда не пойму почему нет стандартных Б+ деревьев в памяти или двухуровнего его аналога.
Тебе еще раз объяснить про различие диска и памяти? Пока тебе не нужен файловый обмен — нафиг тебе не уперлось B-дерево. S>Если бы доступ к данным на стороне сервера был таким же как и в локальных БД я бы и без SQL легко обошелся бы.
Ага-ага. И без ACID тоже. Вот 1С уже обошлись без SQL. Ну-ну. S>Понятно что с таким доступом и использования процесса сервера сразу мног проблем, но тот же Юкон хоть самую малость но уже позволяет использовать объектные подходы.
Эта самая малость не имеет никакого отношения к тому, что проповедуешь ты. У меня этот юкон стоит на машине. S> Вот интересно напридумывали всяких терминов которые в обычном программировании совсем по другому называются.
Ты про какие термины? S>А вот превосходство от применения RID прежде всего будет наблюдаться при объектном а не SQL подходе вот о чем я речь веду.
Говорила калина "как я с медом хороша". Отвечал ей мед "а я и без тебя неплох". А без объектного подхода они нам зачем? S>Хотя организация хранения доступа итд останется тойже самой.
Это какой "той же"? S>Курсоры же никто не отменял. А построить объектную модель над РБД это как два пальца, но на стороне сервера.
Ха-ха. То-то никто этого не делает Построение объектной модели так, чтобы производительность была не катастрофически хуже RDBMS — вот наша задача
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали: S> Вот именно, что 30 лет назад. Сейчас и FAT32 кэшируется не только на уровне цепочек страниц и но и на уровне их загрузки в память на уровне файл маппинг и запись происходит в странцы в памяти а на диск записывается ассинхронно.
Гм. И что? Мы говорим вовсе не о FAT32. Ты пойми, что ограничивать размер базы размером оперативки — гнилое занятие. Не хочешь ограничивать — добро пожаловать в сравнение disk access с memory access. S>А уж на уровне сервера это все уже продумано давно. При этом повторюсь при 64 битных ОС и процессоров дисковые проблемы вообще отходят на задний план.
Ты вместо того, чтобы повторяться, аргументы приведи. Ну причем тут 64 разряда? S> Вот пример http://www.rsdn.ru/forum/Message.aspx?mid=556030&only=1
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Ну насчет нескольких файлов это да. А насчет множества таблиц в одном файле то информация о расположении страниц таблицы кэшируется в массиве от 0..N. Легким движением мы находим индекс в массиве из него получаем информацию о расположении страницы в файле и если страница загружена в память то ее адрес. S>Отлично. Ну вот и посчитай размер этого массива по сравнению с размером B+ дерева. Как насчет динамики? Когда мы удаляем запись? Массив остается неизменным?
Массив страниц таблиц. Конечно остается на месте. Если же все записи удалены то странца записывается в список удаленных таблиц и при запросе на выделение новой страницы выдается именно она. S>> Да при чем здесь перелоапченные страницы??? Как раз при кэшировании это мало влияет, так как работаешь с памятью а здесь уже другие критерии. А у тебя в есть RID ???? То есть в индесе то он есть, и для тебя легче добраться до RID через Б+ легче чем прямое применение??? S>Нет, не легче. Я тебе еще раз говорю — затраты на добирание через B+ по сравнению с прямым обращением — доли процента. S>> Еще раз. Кластерный индек насколько я помны это запись в в Б+ дереве. Ты не путаешь с хэш таблицами???? S>Я-то ничего не путаю. Я тебе привел результаты расчета объема того самого B+ дерева, которое используется для кластерного индекса. Формулы здесь.
S>>>> Кроме всего прочего на RID действительно объектный код быдет работать намного быстрее и не отличатся от обычного объектного программирования. S>> Вот любители SQL или без него навигацию, обсчет итд никак нельзя. Вот бедные обычные программисты используют хэш таблицы для группирования данных, S>>массивы для хранения, указатели для связей и никак не поймут, что такая же организация данных намного легче и быстрее обсчитывается в SQL. S>Именно. S>> Что Select это круче чем Foreach, а оптимзатор сделает очень крутую работу. S>Естественно сделает! И Select порвет твой foreach просто невероятным образом. Почему-то все корпоративные решения в развитом мире делаются именно на Select, а не на Foreach.
Ну ну. А сам селект что использует???? Наверное и запрос компилирутся и схемы там разные использует, и QuickSort использует и хэш таблицы.
Куда же он порвет если все тоже и использует. Дай указатель на адрес памяти. Но это не безопасно, а считывание записи в буффер безопасно и затраты при этом минимальны. Вот и не построишь объектныю БД на SQL. S>>Правда не пойму почему нет стандартных Б+ деревьев в памяти или двухуровнего его аналога. S>Тебе еще раз объяснить про различие диска и памяти? Пока тебе не нужен файловый обмен — нафиг тебе не уперлось B-дерево.
Уже писал ответ. Кэширование в SQL не использутся??? А если учесть, что в основном работа ведется с актуальными данными то они все закэшированы в памяти и их объем не велик по сравнению со всей базой. Ну а если памяти где нибуд к десяткам гигабайт то .... S>>Если бы доступ к данным на стороне сервера был таким же как и в локальных БД я бы и без SQL легко обошелся бы. S>Ага-ага. И без ACID тоже. Вот 1С уже обошлись без SQL. Ну-ну.
Как раз и не обошлись. Только большая часть работы на клиенте и все ее премущества малопригодны т.к. применяется объектный подход с множесвом ссылок и кучей мелких запросов нужность которых выясняется в процессе алгоритма. S>>Понятно что с таким доступом и использования процесса сервера сразу мног проблем, но тот же Юкон хоть самую малость но уже позволяет использовать объектные подходы. S>Эта самая малость не имеет никакого отношения к тому, что проповедуешь ты. У меня этот юкон стоит на машине.
У меня тоже. Но хотя бы на уровне DataSet при передачи данных. S>> Вот интересно напридумывали всяких терминов которые в обычном программировании совсем по другому называются. S>Ты про какие термины? S>>А вот превосходство от применения RID прежде всего будет наблюдаться при объектном а не SQL подходе вот о чем я речь веду. S>Говорила калина "как я с медом хороша". Отвечал ей мед "а я и без тебя неплох". А без объектного подхода они нам зачем? S>>Хотя организация хранения доступа итд останется тойже самой. S>Это какой "той же"? S>>Курсоры же никто не отменял. А построить объектную модель над РБД это как два пальца, но на стороне сервера. S>Ха-ха. То-то никто этого не делает Построение объектной модели так, чтобы производительность была не катастрофически хуже RDBMS — вот наша задача
Когда будет доступ на строне сервера такой же как и на локальных БД будет и производительность и ООП.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали: S>>Я-то ничего не путаю. Я тебе привел результаты расчета объема того самого B+ дерева, которое используется для кластерного индекса. Формулы здесь.
Здесь, значит, опровержений нет? Отлично. S>>Естественно сделает! И Select порвет твой foreach просто невероятным образом. Почему-то все корпоративные решения в развитом мире делаются именно на Select, а не на Foreach. S> Ну ну. А сам селект что использует???? Наверное и запрос компилирутся и схемы там разные использует, и QuickSort использует и хэш таблицы.
Конечно! Вот только какая именно схема будет применяться, выбирается на основании объективных характеристик данных, а не прихоти программера. Читать про Cost-based оптимизацию. S> Куда же он порвет если все тоже и использует.
Вот туда и порвет. В отличие от тупого foreach, select может использовать и index scan, и различные варианты стратегии. Лень перечислять, если честно. А foreach как был форичем — так и останется. S>Дай указатель на адрес памяти.
? По-русски пиши. Не понимаю. S>Но это не безопасно, а считывание записи в буффер безопасно и затраты при этом минимальны.
? Что кому небезопасно? S>Вот и не построишь объектныю БД на SQL.
К чему ты это вообще? Адрес, память... На SQL — нельзя построить объектную БД. Уже попробовали. Bold, Versant... Вот только на основе твоих СУБД, живущих в памяти, тоже нельзя. S> Уже писал ответ. Кэширование в SQL не использутся??? А если учесть, что в основном работа ведется с актуальными данными то они все закэшированы в памяти и их объем не велик по сравнению со всей базой.
Интересно. Почему же тогда у нас на практике I/O cost такой большой... В принципе, удешевление памяти идет вроде бы быстрее роста потребностей в объемах на малоформатных задачах. Значит, вскоре применение RID выйдет на более передний план. Хотя в большинстве случаев рассматриваются все же двух- и более- проходные алгоритмы. S>Ну а если памяти где нибуд к десяткам гигабайт то ....
Ты своими глазами такие системы видел? Или так, теоретически рассуждаешь? В принципе, скоро такие системы станут коммерчески доступны. Но что-то мне подсказывает, что не все будет просто в датском королевстве... S> Как раз и не обошлись. Только большая часть работы на клиенте и все ее премущества малопригодны т.к. применяется объектный подход с множесвом ссылок и кучей мелких запросов нужность которых выясняется в процессе алгоритма.
Вот-вот. Я и говорю — обошлись без SQL. Все на клиенте колбасят. Верх некомпетентности. S>>Эта самая малость не имеет никакого отношения к тому, что проповедуешь ты. У меня этот юкон стоит на машине. S> У меня тоже. Но хотя бы на уровне DataSet при передачи данных.
Блин. Эта самая малость не имеет никакого отношения к тому, что проповедуешь ты! S>>> Вот интересно напридумывали всяких терминов которые в обычном программировании совсем по другому называются. S> Когда будет доступ на строне сервера такой же как и на локальных БД будет и производительность и ООП.
Это какой "такой же доступ"?
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Вот именно, что 30 лет назад. Сейчас и FAT32 кэшируется не только на уровне цепочек страниц и но и на уровне их загрузки в память на уровне файл маппинг и запись происходит в странцы в памяти а на диск записывается ассинхронно. S>Гм. И что? Мы говорим вовсе не о FAT32. Ты пойми, что ограничивать размер базы размером оперативки — гнилое занятие. Не хочешь ограничивать — добро пожаловать в сравнение disk access с memory access. S>>А уж на уровне сервера это все уже продумано давно. При этом повторюсь при 64 битных ОС и процессоров дисковые проблемы вообще отходят на задний план. S>Ты вместо того, чтобы повторяться, аргументы приведи. Ну причем тут 64 разряда?
Как раз в ограничении памяти которые 64 разряда снимают и все записи и чтение ведутся без подкачки данных. S>> Вот пример http://www.rsdn.ru/forum/Message.aspx?mid=556030&only=1
S>> записи в 20 МБ. S>И причем тут этот пример? Он вообще не имеет отношения к теме разговора.
Имеет в сравнении disk access с memory access, и RID vs B+ деревья. ООБД vs SQL. Там где SQL подход рулит при ограничении памяти при ее обилии возможны совсем другие подходы которые не будут сказываться на производительности и безопасноти.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
S>> Когда будет доступ на строне сервера такой же как и на локальных БД будет и производительность и ООП. S>Это какой "такой же доступ"?
В ЛБД используя индексы и тд считывая по одной (редко блоками) в любой момент я могу поменять направление выборки, что невозможно в SQL.
Курсоры есть и в SQL, но нормальную надстроку над ними сделать на данном этапе нельзя. Дай быстрый курсор и ООП на стороне сервера и доступ не на уровне строки SQL а на уровне API и функций считывания записи. Пока премущество SQL в том, что выборка компилируется и проход очень быстрый сравнимый с проходом по массиву через указатели. Тот же foreach но на уровне указателей . В локальной БД я и сам все что нужно с оптимизирую и использую данные индекса если нужно доступ к нему есть, а во многих задачах вообще не нужно ни чего оптимизировать тупой последовательный проход с ветвлениями. Пусть даже потеряю в скорости в 2 раза зато выиграю в гибкости в 100 раз.
Про 1С. Думаешь они от хороей жизни большую часть на клиенте делают???? Будь возможнось делать на стороне сервера все там бы и происходило.
Любой модуль проведения документа использует огромную кучу разнообразных данных, неопределенных полей, иерархию итд. И в чем здесь премущество SQL. Не делать таких сложных баз и связей??? И почему так популярна 1С???? А представь все что делает 1С даже интерпретатор но на стороне сервера??? Скорость разработки высока, скорость обработки данных еще выше. Вариант с ДБФ + TSE доказывают это. Но нужна надежность и еще большая скорость. Рано или поздно все равно придут к этому. Кстати продажи 1С за рубежем достаточно большие. Можно плеваться в ее сторону но это факт.
Посмотрим что выдаст M$ с акзаптой и навижном. Кстати и сейчас они на нашем рынке проигрывают 1С.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали: S> Как раз в ограничении памяти которые 64 разряда снимают и все записи и чтение ведутся без подкачки данных.
Да ну, придумал тоже. 64 разряда никак не повлияют на количество памяти в системе . Ты вообще в курсе, какой предел адресуемой оперативной памяти у IA32? S> Имеет в сравнении disk access с memory access, и RID vs B+ деревья. ООБД vs SQL. Там где SQL подход рулит при ограничении памяти при ее обилии возможны совсем другие подходы которые не будут сказываться на производительности и безопасноти.
Ну вот с этого и надо было начинать. А то "иерархические БД" какие-то...
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Как раз в ограничении памяти которые 64 разряда снимают и все записи и чтение ведутся без подкачки данных. S>Да ну, придумал тоже. 64 разряда никак не повлияют на количество памяти в системе . Ты вообще в курсе, какой предел адресуемой оперативной памяти у IA32?
Нет зато Athlon 64 http://www.amdnow.ru/#1080436001 32 ГБ. И это не предел. S>> Имеет в сравнении disk access с memory access, и RID vs B+ деревья. ООБД vs SQL. Там где SQL подход рулит при ограничении памяти при ее обилии возможны совсем другие подходы которые не будут сказываться на производительности и безопасноти. S>Ну вот с этого и надо было начинать. А то "иерархические БД" какие-то...
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Как раз в ограничении памяти которые 64 разряда снимают и все записи и чтение ведутся без подкачки данных. S>Да ну, придумал тоже. 64 разряда никак не повлияют на количество памяти в системе . Ты вообще в курсе, какой предел адресуемой оперативной памяти у IA32?
Насчет IA32 не знаю а во Athlon 64 http://www.amdnow.ru/#1080436001 32 ГБ И это не предел. S>> Имеет в сравнении disk access с memory access, и RID vs B+ деревья. ООБД vs SQL. Там где SQL подход рулит при ограничении памяти при ее обилии возможны совсем другие подходы которые не будут сказываться на производительности и безопасноти. S>Ну вот с этого и надо было начинать. А то "иерархические БД" какие-то...
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
A>>Правда огромный плюс: РСУБД работают одиннаково медленно на любых задачах — плата за универсальность. S>Да-да-да. Может, Cache таки выйдет из тени, и займет хотя бы 50е место на www.tpc.org?
А как сравнивать? по SQL? Сейчас буча идет — сами производители SQL баз говорят что этот тест нихрена немеряет, не соответствует реалиям современной жизни.
S>Ну, во-первых, можно спросить, с чего вдруг Cache стала "иерархической СУБД"? Таких вольностей себе даже маркетологи не позволяют. Или ты все не-RDBMS называешь "иерархическими"?
Да не могут себе этого их маркетологи позволить!
Если кто-то видит это название иерархическая СУБД — то сразу все сакс, говно, было уже и т.д.... "а Вот MS SQL рулит"...
S>Далее, ты не мог бы все-таки привести ссылки на конкретные success stories, где есть выигрыш от 20 до 50 раз по скорости работы по сравнению с RDBMS? Я с пяток просмотрел бегло — нету таких цифир. Там вообще про производительность нема.
“Running on the same hardware that supported the Sybase system, Cache is 100 times faster handling transactions, and 20 times faster than Sybase overall."
— Rolf Streb, IT Manager, Department of Justice, Bern
И еще
“With Cache , we are getting a much faster system that enables us to be 20-100 times more faster, is much easier to maintain, and takes far less system administration."
— Rolf Streb, IT Manager, Department of Justice, Bern
A>>Если не смотреть на забугорников — то достаточно посмотреть на последние billing системы российских разработчиков (http://www.mobill.ru/csp/komta/index.csp) — просто перевод с SQL базы на эмуляцию SQL на иерархии. S>Хм. На самом сайте нет никаких упоминаний про переход с чего-то на Cache. И никаких сравнений производительности тоже нету.
Здравствуйте, Serginio1, Вы писали: S>>Это какой "такой же доступ"? S> В ЛБД используя индексы и тд считывая по одной (редко блоками) в любой момент я могу поменять направление выборки
А что такое "направление выборки"? S> что невозможно в SQL. S> Курсоры есть и в SQL, но нормальную надстроку над ними сделать на данном этапе нельзя.
А зачем вообще тебе потребовались курсоры? S>Дай быстрый курсор и ООП на стороне сервера и доступ не на уровне строки SQL а на уровне API и функций считывания записи.
Ты надеешься получить какую-то прибыль с того? S>Пока премущество SQL в том, что выборка компилируется и проход очень быстрый сравнимый с проходом по массиву через указатели. Тот же foreach но на уровне указателей .
Нет. Преимущество SQL — в статистике. Ты можешь динамически управлять используемыми планами при помощи настройки индексов в зависимости от реальных нужд. При этом тебе не придется менять бизнес-логику. Для foreach ты должен сразу выбрать, кто из отношений будет итерироваться снаружи. S>В локальной БД я и сам все что нужно с оптимизирую и использую данные индекса если нужно доступ к нему есть,
Ага. Вот только во-первых статистика по этому индексу тебе недоступна, а во-вторых ты стоимость этой оптимизации как оцениваешь? Неделя траха (40 часов) на каждый запрос? А DBA просто выполнит Create Index за 1 минуту, и всё приложение взлетит. S>а во многих задачах вообще не нужно ни чего оптимизировать тупой последовательный проход с ветвлениями. Пусть даже потеряю в скорости в 2 раза зато выиграю в гибкости в 100 раз.
Я никак не могу понять, почему ты называешь фиксированный алгоритм, вбитый заботливыми руками, "гибким". Чем же он таким волшебным гибче, чем SQL? S> Про 1С. Думаешь они от хороей жизни большую часть на клиенте делают???? Будь возможнось делать на стороне сервера все там бы и происходило.
Нет конечно. Просто они в тот момент, когда надо было деньги в Client-Server вбухивать, файл-сервером развлекались. Вот и имеют теперь legacy system. S> Любой модуль проведения документа использует огромную кучу разнообразных данных, неопределенных полей, иерархию итд. И в чем здесь премущество SQL.
Да делали мы такие модули проведения документа. При грамотном проектировании в хранимых процедурах это все летает так, что 1С умрет от зависти.
Фактически, проблема в том, что ООП предлагает большое количество концепций, которые существенно упрощают девелопмент. Все эти неопределенные поля — от убогости. Для каждой конкретной задачи я тебе наколбашу схему на основе SQL, которая безо всяких неопределенных полей будет выполняться в тыщу раз быстрее перебора. Вопрос в том, что делать, когда появляется новый класс того самого документа. В рамках классического RDBMS подхода придется сильно переработать модель отношений.
Но я в который раз объсняю — никакого отношения к RID/PK это не имеет. Вопрос совсем-совсем в другом. Недостаточно внести указатели и API в RDBMS. Так ты сможешь только вернуться в каменный век. Вопрос в том, как грамотно объяснить движку ODBMS, что ты от него хочешь. И дать ему возможность выбрать алгоритм не хуже, чем для RDBMS.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали: S>>> Как раз в ограничении памяти которые 64 разряда снимают и все записи и чтение ведутся без подкачки данных. S>>Да ну, придумал тоже. 64 разряда никак не повлияют на количество памяти в системе . Ты вообще в курсе, какой предел адресуемой оперативной памяти у IA32? S> Насчет IA32 не знаю а во Athlon 64 http://www.amdnow.ru/#1080436001 32 ГБ И это не предел.
Ну так поинтересовался бы. В соответствии с http://www.intel.com/design/Pentium4/manuals/25366513.pdf, начиная с Pentium Pro (1995) предел размеров внешнего адресного пространства — 64GB. Так что в течение этих десяти лет вовсе не отсутствие Amd64 сдерживало рост размеров памяти. Кстати, ссылка, которую ты приводишь, она вовсе не про Athlon 64 — почитай. Там речь идет про Opteron, который вроде как не совсем 64-разрядный, и вообще совсем другой процессор .
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>>>Это какой "такой же доступ"? S>> В ЛБД используя индексы и тд считывая по одной (редко блоками) в любой момент я могу поменять направление выборки S>А что такое "направление выборки"?
Помнишь мы решали проблему прдажи в день. Кроме того есть сложные выборки и в зависимости от данных выбирать тот или иной алгоритм. S>> что невозможно в SQL. S>> Курсоры есть и в SQL, но нормальную надстроку над ними сделать на данном этапе нельзя. S>А зачем вообще тебе потребовались курсоры? S>>Дай быстрый курсор и ООП на стороне сервера и доступ не на уровне строки SQL а на уровне API и функций считывания записи. S>Ты надеешься получить какую-то прибыль с того?
Конечно это гибкость обсчета данных. S>>Пока премущество SQL в том, что выборка компилируется и проход очень быстрый сравнимый с проходом по массиву через указатели. Тот же foreach но на уровне указателей . S>Нет. Преимущество SQL — в статистике. Ты можешь динамически управлять используемыми планами при помощи настройки индексов в зависимости от реальных нужд. При этом тебе не придется менять бизнес-логику. Для foreach ты должен сразу выбрать, кто из отношений будет итерироваться снаружи.
Да иногда и нет как такоког плана и он не нужен. Например проведение товара по партиям ( разбор товар на комиссии, свой, документ прихода) одновременное снятие с резерва, контроль остатков как по партиям так и по складам, взаиморасчеты как просто дебет кредит так и по кредитам.
ИТД. Конечно взмылив задницу можно и на хранимых процедурах написать используя темп таблицы огромное количество мелких запросов.
А про расчет зарплаты закрытие месяца в бухгалтерии вообще промолчу.
А это как правило основные задачи. А для остальных вещей есть ОЛАПы итд. S>>В локальной БД я и сам все что нужно с оптимизирую и использую данные индекса если нужно доступ к нему есть, S>Ага. Вот только во-первых статистика по этому индексу тебе недоступна, а во-вторых ты стоимость этой оптимизации как оцениваешь? Неделя траха (40 часов) на каждый запрос? А DBA просто выполнит Create Index за 1 минуту, и всё приложение взлетит.
Да и не нужна она в основном. Нужны тупые остатки по товарам о типе товара на каждом шагу информация по клиенту S>>а во многих задачах вообще не нужно ни чего оптимизировать тупой последовательный проход с ветвлениями. Пусть даже потеряю в скорости в 2 раза зато выиграю в гибкости в 100 раз. S>Я никак не могу понять, почему ты называешь фиксированный алгоритм, вбитый заботливыми руками, "гибким". Чем же он таким волшебным гибче, чем SQL? S>> Про 1С. Думаешь они от хороей жизни большую часть на клиенте делают???? Будь возможнось делать на стороне сервера все там бы и происходило. S>Нет конечно. Просто они в тот момент, когда надо было деньги в Client-Server вбухивать, файл-сервером развлекались. Вот и имеют теперь legacy system. S>> Любой модуль проведения документа использует огромную кучу разнообразных данных, неопределенных полей, иерархию итд. И в чем здесь премущество SQL. S>Да делали мы такие модули проведения документа. При грамотном проектировании в хранимых процедурах это все летает так, что 1С умрет от зависти. S>Фактически, проблема в том, что ООП предлагает большое количество концепций, которые существенно упрощают девелопмент. Все эти неопределенные поля — от убогости. Для каждой конкретной задачи я тебе наколбашу схему на основе SQL, которая безо всяких неопределенных полей будет выполняться в тыщу раз быстрее перебора. Вопрос в том, что делать, когда появляется новый класс того самого документа. В рамках классического RDBMS подхода придется сильно переработать модель отношений.
Ага напаример берем бухгалтерию, проводка представляет собой дебет субконто1,субконто2,субконто1, где субконто для каждого счета свой и никуда не денешься и без аналитики никуда. И как ты советуешь ииследовать операцию документа одним запросом???? А иногда вообще стоят задачи найди то не известно что, только по определенным признакам документа. S>Но я в который раз объсняю — никакого отношения к RID/PK это не имеет. Вопрос совсем-совсем в другом. Недостаточно внести указатели и API в RDBMS. Так ты сможешь только вернуться в каменный век. Вопрос в том, как грамотно объяснить движку ODBMS, что ты от него хочешь. И дать ему возможность выбрать алгоритм не хуже, чем для RDBMS.
Все это имеет отношение к объектному подходу в БД и увеличение ее производительности. И дать мне самому делать выборки в различных напрвлениях в зависимости от данных на каждом шаге. И при этом использовать Select для известных выборок. Одно другому не мешает.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>>>> Как раз в ограничении памяти которые 64 разряда снимают и все записи и чтение ведутся без подкачки данных. S>>>Да ну, придумал тоже. 64 разряда никак не повлияют на количество памяти в системе . Ты вообще в курсе, какой предел адресуемой оперативной памяти у IA32? S>> Насчет IA32 не знаю а во Athlon 64 http://www.amdnow.ru/#1080436001 32 ГБ И это не предел. S>Ну так поинтересовался бы. В соответствии с http://www.intel.com/design/Pentium4/manuals/25366513.pdf, начиная с Pentium Pro (1995) предел размеров внешнего адресного пространства — 64GB. Так что в течение этих десяти лет вовсе не отсутствие Amd64 сдерживало рост размеров памяти. Кстати, ссылка, которую ты приводишь, она вовсе не про Athlon 64 — почитай. Там речь идет про Opteron, который вроде как не совсем 64-разрядный, и вообще совсем другой процессор .
Athlon 64 он же Hammer он же Opteron он же Athlon 64 FX-53 это просто разные линейки. Кстати intel сам сечас делает АМД совместимы процессоры,
так что твоя информация устарела.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Re[9]: Реляционное против нереляционного
От:
Аноним
Дата:
29.03.04 18:02
Оценка:
Здравствуйте, 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 — производства!
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали: S> Athlon 64 он же Hammer он же Opteron он же Athlon 64 FX-53 это просто разные линейки. Кстати intel сам сечас делает АМД совместимы процессоры, S> так что твоя информация устарела.
Ну, я человек тупой — не судьба мне понять, что Athlon 64 FX-53 и Opteron — одно и то же. Тем не менее, аргумент про 64GB на IA32 ясен?
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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 подход рулит при ограничении памяти при ее обилии возможны совсем другие подходы которые не будут сказываться на производительности и безопасноти.
Да будут, потому что от дисковых операций все равно никуда не денешся — это раз. И потому, что объемы информации растут гораздо быстрее чем объемы оперативной памяти способные ее вместить — это два.
Здравствуйте, 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 и диску, соответственно.
хъ
B>Во втретьих от дисковых операций все равно никуда не уйдешь потому как каждая транзакция обязана при фиксации сбрасывать данные на диск, иначе об устойчивости вообще говорить нельзя.
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>Здравствуйте, 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. А таких задач пруд пруди.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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 особо не поворочаешь все сразу уперлось бы в чтение диска а это не так.
Кроме всего прочего большая часть БД не используется а работа ведется с актуальными на данный момент данными и их объем не сравним с общим объемом, а на этом кэширование и работает.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> То есть кэширование страниц не используется и ассинхронной записи на диск не существует??? Но это их беды.
Именно не используется, и именно не существует. И это не их беды, это требования устойчивости транзакций. Без этого ни о какой надежности речи идти не может.
В Mission critial системах даже аппаратные write back кеши отключают, тем более, что пользы от них не очень много.
S> То есть БД работает не со страницами в памяти а только с диском (да и то система кэширут их в памяти).
Какая система? ОС не кеширует ничего — все дисковые операции БД производит напрямую.
S> Асинхронно.
Хрен там. Никакой асинхронности. Пока БД не убедится, что данные доехали до диска, commit не произойдет, все блокировки будут удерживаться, ect...
Тебе уже три человека говорят, почитай же теорию наконец, поймешь, почему все сделано именно так.
S> Их не так и много даже сейчас за счет кэширования. При чем если бы было наоборот то и SQL особо не поворочаешь все сразу уперлось бы в чтение диска а это не так.
Не поверишь, но это именно так. В большинстве систем диск самое узкое место.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Alexey Shirshov, Вы писали:
AS>> Синхронно на диск уходит запись в лог. M>Ну и какая разница? Запись в лог — не дисковая операция? Страница лога пишется в разы быстрее? M>Один фиг к диску обращаться. Почитал бы и ты теорию что ли....
И какое имеет это отношение к выборкам данных???? И можно легко посчитать затраты на лог как дымаешь какими они окажутся и сколько процентов по времени будут занимать по отношению к общим затратам ???? у диска свой кэш есть.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Все о чем SQL выигрывает вернее сильная часть это глобальные выборки, т.к. в примере подсчета продаж в день он опускает руки .
??? SQL? Первый раз слышу. Хотя с кривыми руками можно действительно любую систему положить..
S>Но в задач с проведением документов а они и являются основными критическими затратами это не нужно.
Что не нужно?
S> Select * From s where ID=:ID Согласен что такой запрос будет скомпилирован, но SetPrimsryIndex, GetRecordForKey(ID) и как видишь кода лишнего совсем немного.
О чем ты? При чем тут скомпилирован?
S> Тебе показать проведение начисления зарплаты???? Где тысячи ветвлений.
И ты предлагаешь эти тысячи ветвлений в ручную описывать? Флаг в руки.
S> Если бы все было так просто. Парус нормальную бухгалтерию выпустить не может. А все потому что структура бухгалтерии не однородна и не вписывается в прямолинейные запросы SQL. А таких задач пруд пруди.
Бухгалтерия в SQL вписывается идеально, его не в последнюю очередь именно для таких задач и придумывали. Поверь, гораздо проще разобраться наконец с тем как это правильно работает, а не городить велосипед с квадратными колесами.
Здравствуйте, Serginio1, Вы писали:
S> И какое имеет это отношение к выборкам данных????
Прямое.
S>И можно легко посчитать затраты на лог как дымаешь какими они окажутся и сколько процентов по времени будут занимать по отношению к общим затратам ????
Достаточное, чтобы быть узким местом.
S> у диска свой кэш есть.
Блин, в 5й раз говорю. Все обращения к диску идут в обход всех кешей. RTFM.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> То есть кэширование страниц не используется и ассинхронной записи на диск не существует??? Но это их беды. M>Именно не используется, и именно не существует. И это не их беды, это требования устойчивости транзакций. Без этого ни о какой надежности речи идти не может. M>В Mission critial системах даже аппаратные write back кеши отключают, тем более, что пользы от них не очень много.
S>> То есть БД работает не со страницами в памяти а только с диском (да и то система кэширут их в памяти). M>Какая система? ОС не кеширует ничего — все дисковые операции БД производит напрямую.
Пусть будет так. И каковы затраты на запись. Давай посчитаем 20ГБ в сек скорость записи не самого хорошего диска. Сколько данных в секунду записывается в реальной базе?????
За весь рабочий день столько не наберется. S>> Асинхронно. M>Хрен там. Никакой асинхронности. Пока БД не убедится, что данные доехали до диска, commit не произойдет, все блокировки будут удерживаться, ect...
M>Тебе уже три человека говорят, почитай же теорию наконец, поймешь, почему все сделано именно так.
S>> Их не так и много даже сейчас за счет кэширования. При чем если бы было наоборот то и SQL особо не поворочаешь все сразу уперлось бы в чтение диска а это не так.
И как они еще ворочаются. 20ГБ в сек значит предел для них. А вы тут SQL SQL. M>Не поверишь, но это именно так. В большинстве систем диск самое узкое место.
То есть если страницы в памяти то они все равно каждый раз считываются с диска???? Запись в БД занимаю небольшие затраты по сравнению с чтением.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> И какое имеет это отношение к выборкам данных???? M>Прямое.
S>>И можно легко посчитать затраты на лог как дымаешь какими они окажутся и сколько процентов по времени будут занимать по отношению к общим затратам ???? M>Достаточное, чтобы быть узким местом.
S>> у диска свой кэш есть. M>Блин, в 5й раз говорю. Все обращения к диску идут в обход всех кешей. RTFM.
Последний вопрос сколько MB у тебя записывается в день и давай сравним со скоростью в 20 МБ/сек
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Все о чем SQL выигрывает вернее сильная часть это глобальные выборки, т.к. в примере подсчета продаж в день он опускает руки . M>??? SQL? Первый раз слышу. Хотя с кривыми руками можно действительно любую систему положить..
Бедный Sinclair, не знал что у него кривые руки. S>>Но в задач с проведением документов а они и являются основными критическими затратами это не нужно. M>Что не нужно?
S>> Select * From s where ID=:ID Согласен что такой запрос будет скомпилирован, но SetPrimsryIndex, GetRecordForKey(ID) и как видишь кода лишнего совсем немного. M>О чем ты? При чем тут скомпилирован?
S>> Тебе показать проведение начисления зарплаты???? Где тысячи ветвлений. M>И ты предлагаешь эти тысячи ветвлений в ручную описывать? Флаг в руки.
А куда деваться такой очень мудренный алгоритм придуманный нашими мудрыми законотворцами.
S>> Если бы все было так просто. Парус нормальную бухгалтерию выпустить не может. А все потому что структура бухгалтерии не однородна и не вписывается в прямолинейные запросы SQL. А таких задач пруд пруди. M>Бухгалтерия в SQL вписывается идеально, его не в последнюю очередь именно для таких задач и придумывали. Поверь, гораздо проще разобраться наконец с тем как это правильно работает, а не городить велосипед с квадратными колесами.
Ты покажи мне этот велосипед. Вот народ тупой всякие Акзапты Навижн 1С используют а тут есть готовое решение и мимо него проходят.
Поделись я посмотрю на реально работающую систему и сравню.
И как вы там с субконто работаете???? Операция имеет множество проводок с различными счетами у которых свой набор субконто, а вид ь проводки может быт только один. Или вы только суммы пишете как насчет аналитики????
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Последний вопрос сколько MB у тебя записывается в день и давай сравним со скоростью в 20 МБ/сек
Опять не правильно вопрос ставишь.
Не сколько мегабайт в день, а сколько страниц надо сбросить и поднять с диска во время работы одной транзакции и сколько таких транзакций в системе в день проходит.
Точно не скажу, надо мониторить, но можешь мне поверить — вполне достаточно. Особенно эти цифры впечатляют, когда с базой одновременно начинают работать хотя бы десять человек, а не два-три.
S> Пусть будет так. И каковы затраты на запись. Давай посчитаем 20ГБ в сек скорость записи не самого хорошего диска. Сколько данных в секунду записывается в реальной базе????? S> За весь рабочий день столько не наберется.
Не правильно считаешь. 20 Гб пишется за раз, а тут скидываются и поднимаются странички в среднем 8К размером. Да еще в разных частях диска. Так что о 20 Гб можешь забыть.
Тебе не зря ведь приводили стоимость дисковых операций по сравнению со всеми остальными...
S> И как они еще ворочаются. 20ГБ в сек значит предел для них. А вы тут SQL SQL.
Да. занимательная у тебя получается арифметика.
S> То есть если страницы в памяти то они все равно каждый раз считываются с диска????
Нет конечно, но все страницы не с кешируешь.
S> Запись в БД занимаю небольшие затраты по сравнению с чтением.
Не большие, но вполне заметные.
Здравствуйте, DarkGray, Вы писали:
S>> Меня за 3мб убьют. Но в атлонах применяется HypperTrasport до 12 ГБ в секунду (новый до 20). S>> http://www.amdnow.ru/reviews/hypertransport/index3.shtml S>> А как на счет 128 Гбайт(!)
DG>Дело-то не сколько памяти адресуется и поддерживается чипсетом, а сколько это память стоит.
DG>если считать по цене памяти для обычных персоналок: 256мб — 60$, 128г ~ 3000$, вспомним, что это память для сервера (* 2-5), что все 128гб память надо уместить в маленький объем (* 3-10), вспомним, что эта память будет выпускается малыми партиями, поэтому себестоимость высокая (* 3-10), такая память наукоемкая, требующая быстрой отдачи с вложенных денег (* 2-5)
в (2*3) раза. DG>Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы.
6-9 килобаксов.
DG>Тем более 128гб памяти — это не так уж много, 1млн простых записей вида имя, описание, дата, цена, где имя — 100 символов, описание — 500 символов, получается 1млн * (100 символов + 500 символов) * 2 байт/символ = 1.2гб, т.е. в памяти поместится всего 100 таблиц, это не считая всяких overhead-ов, кэшей и т.д.
Ну сто тысячные справочники видел (только там наименование пишут) миллионных еще нет. DG>Если же, например, описания идут не plain-текст, а rich-текстом (doc, html, xml), то описание уже может быть и 2000 символов, и четыре тысячи, а ведь скорее всего захочется и full-text index по этим описаниям- это еще одна копия этих же данных и т.д.
А кто предлагал использовать doc, html, xml. Речь идет о несколько другой организации хранения данных и работа с данными как в локальных базас с ООП надстройкой над хранимыми данными и обрабокой на стороне сервера. Теже ECO ObjectSpace работают только на стороне клиента. На стороне сервера этого нет. Для объектного подхода нужени быстрый доступ по ссылкам а это можно решить введение прямой ссылки (номер записи)
и возможно другие подходы для хранения (как двунапрвленные списки, деревья итд). Хранение однотипных данных оптимально хранить в таблицах так что рляционность сохраняется и все наработанные алгоритмы остаются. Тоже дерево может хранится в одной таблице только ссылки на дочерние записи указывают на номер их записи. Все тоже самое только доступ другой.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
S>>> у диска свой кэш есть. M>>Блин, в 5й раз говорю. Все обращения к диску идут в обход всех кешей. RTFM. S> Последний вопрос сколько MB у тебя записывается в день и давай сравним со скоростью в 20 МБ/сек
Возьмем для примера магазин, вот тот же amazon.com.
Вот здесь написано, что у них было 1млн. операций за год, насколько я понимаю — одна операция — одна продажа.
1млн. продаж / 365дней / 24часа / 60минут = 2 продажи в минуту
1 продажа — это не просто запись в одну таблицу, а это авторизация, проверка баланса, перевод денег, выписка накладной, убирание товара со склада и т.д. Каждая из этих операций сопровождается изменением хотя бы одной таблицы.
Кроме продаж, еще есть сессии пользователей, у пользователей есть их настройки и т.д. За пользователями сейчас часто "шпионят", запоминая их предпочтения. И все это тоже надо хранить.
ps
amazon.com — это, конечно, что-то далекое, но можно взять обычный магазин. Возьмем тот же библио-глобус, касс в нем в районе десятка, пустых касс я у них не видел, обслуживание покупателя в районе 1 минуты, т.е. получаем те же 10 продаж в минуту.
ps
Да, учти еще, что в час пик нагрузка может быть в 10-1000 раз быть больше, особенно для online-магазина.
Здравствуйте, Sinclair, Вы писали:
A>>А так — вот A>>http://www.intersystems.com/cache/testimonials/performance.html S>Кул! Червь сомнений меня уже начал мучить. Хотя есть такое подозрение, что у них просто по Sybase не было нормальных спецов... Тем не менее, знак хороший — значит Sybase нифига не чемпион. Шутка На самом деле — получение инструмента, которые позволяет так ускорить разработку даже при небольшом понижении производительности — уже круто. Так что я, в общем, впечатлен. Будем исследовать опыт передовиков OLTP — производства!
Скорость разработки не увеличивается. Она такая же.
А вот скорость работы заметно выше.
S> И какое имеет это отношение к выборкам данных???? И можно легко посчитать затраты на лог как дымаешь какими они окажутся и сколько процентов по времени будут занимать по отношению к общим затратам ???? у диска свой кэш есть.
C Merle бесполезно спорить. Он глух как support@rsdn.ru и никогда не признается, что лоханулся. Ведь модер форума БД, да еще и такой парень как Merle просто не может лохануться!
А то, что он немного путает сброс данных и запись log records в лог — ну это не беда. В конце концов, он всегда тебе сможет доказать, что log records это тоже ведь данные! так что в самом общем смысле он был прав.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Последний вопрос сколько MB у тебя записывается в день и давай сравним со скоростью в 20 МБ/сек M>Опять не правильно вопрос ставишь. M>Не сколько мегабайт в день, а сколько страниц надо сбросить и поднять с диска во время работы одной транзакции и сколько таких транзакций в системе в день проходит. M>Точно не скажу, надо мониторить, но можешь мне поверить — вполне достаточно. Особенно эти цифры впечатляют, когда с базой одновременно начинают работать хотя бы десять человек, а не два-три.
Очень интересно посмотреть на результаты. Но при объеме памяти больше чем БД на подкачку время не будет тратится.
А по поводу 10 человек то просто с синхронным чтением и записью на откомпилированных выборках и записях это вообще не заметно, т.к. глобальные выборки делаются редко а все остальное занимает милисекунды меньшее чем посылка пакета по сети которые становятся в очередь.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
S>>>> у диска свой кэш есть. M>>>Блин, в 5й раз говорю. Все обращения к диску идут в обход всех кешей. RTFM. S>> Последний вопрос сколько MB у тебя записывается в день и давай сравним со скоростью в 20 МБ/сек
DG>Возьмем для примера магазин, вот тот же amazon.com.
DG>Вот здесь написано, что у них было 1млн. операций за год, насколько я понимаю — одна операция — одна продажа. DG>1млн. продаж / 365дней / 24часа / 60минут = 2 продажи в минуту
Да огромная цифра. Есть фирмы с множеством складов по 20 компьютеров и у каждого очередь. И работали на DBASE но это простейшие операции где сложный расчет не нужен. DG>1 продажа — это не просто запись в одну таблицу, а это авторизация, проверка баланса, перевод денег, выписка накладной, убирание товара со склада и т.д. Каждая из этих операций сопровождается изменением хотя бы одной таблицы.
DG>Кроме продаж, еще есть сессии пользователей, у пользователей есть их настройки и т.д. За пользователями сейчас часто "шпионят", запоминая их предпочтения. И все это тоже надо хранить.
DG>ps DG>amazon.com — это, конечно, что-то далекое, но можно взять обычный магазин. Возьмем тот же библио-глобус, касс в нем в районе десятка, пустых касс я у них не видел, обслуживание покупателя в районе 1 минуты, т.е. получаем те же 10 продаж в минуту.
Только одно забываешь, что работают кассы обычно для безопасности в оффлайне, а внутри обычные ДБФ таблицы. И обычно никаких остатков одни обороты. Да они могут скидывать предварительную информацию на сервер, но там мало контроля за партиями товаров, кредитами итд. И организация таких баз плевое дело. Не в нагрузке а в количестве рассчетов и ветвлений и обращении за дополнительной информации к бд по каждой проводке. В бухгалтерских системах эти затраты огромны. DG>ps DG>Да, учти еще, что в час пик нагрузка может быть в 10-1000 раз быть больше, особенно для online-магазина.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Barmaglot, Вы писали:
A>>Про эффективность говорить не приходится. B>И не говори.
Хорошо, не буду. Просто для примера: крупный магазин работал на системе аналогичной Cache несколько лет, размер все базы (бухгалтерия, склад, и т.д.) не превысил 700МБ — соотвественно сервер P3 266, 128МБ озу.
Сейчас систему сменили на 1с sql — купили сервер P4 2ГГЦ, 1ГБ озу, сокращение рабочих мест с 23 до 8, жалуются что медленно...
A>>Самая крутая РСУБД Oracle "работает одиннаково медленно" на любом объеме данных — описание дано программистом довольно двано работающим с Oracle. B>Давай сюда этого программиста, за базар отвечать будет. Может быть в те времена, когда Оракл была "самой крутой" может быть так и было, но сейчас это совсем не так.
Какая сейчас самая крутая? вопрос без подвоха... просто интересно.
A>>При правильном использовании (как и в любой задаче) применение иерархических СУБД дает примерно выигрыш от 20 до 50 раз по скорости работы (при тех же аппаратно-технических требованиях) B>Угу, только с небольшой поправочкой, а точнее с двумя. B>1. Не в 20-50, а в 2-3.
Ссылочку я уже приводил. там указывается даже не 20-30, а 50-100 раз увеличение быстродействия.
B>2. Только в очень специальных задачах, которые идеально ложатся в рамки иерархических СУБД. А таких задач, в настоящее время, просто мизерное количество.
Весь мир иерархия. А в РСУБД это приходится притягивать за уши.
A>>Примеры можно взять из многочисленных success story например на сайте www.instersystems.ru B>Эти многочисленные SS просто детский лепет, по сравнению с количеством и объемом информации, который хранят и в обрабатывают РСУБД. B>Когда хоть какая-нибудь иерархическая база появится на tpc.org вот тогда и поговорим, а до этого времени все это не серьезно.
В характристиках Ролс-Ройсов про мощность мотора пишут — "ДОСТАТОЧНАЯ". Так что? отстойная машина?
B>P. S. B>Господа, вы забываете еще один аспект универсальности RDBMS. Информация имеет свойство хранится очень и очень долго. И сама информация переживает системы ее обработки. Благодаря тому, что в/из реляционную структуру можно перевести данные любой сложности — нет никаких проблем обработки реляционных данных многолетней давности, собранных в системах о которых мы даже не знаем. Все же остальные модели, в том числе и иерархическая предполагают некоторую зависимость способа хранения данных от самих данных, и когда со временем данные потребуется представить в другом виде это потребует серьезного перестроения модели хранения этих данных.
Вот, вот... Та же Intersystems на рынке уже более 25 лет... и обеспечивает между все продуктами совместимость.
B>А реляционная модель подобным мутациям не подвержена.
Ввиду своей мутационности изначально....
прошу не обижаться. ну ОЧЕНЬ не люблю реляционную модель.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Пусть будет так. И каковы затраты на запись. Давай посчитаем 20ГБ в сек скорость записи не самого хорошего диска. Сколько данных в секунду записывается в реальной базе????? S>> За весь рабочий день столько не наберется. M>Не правильно считаешь. 20 Гб пишется за раз, а тут скидываются и поднимаются странички в среднем 8К размером. Да еще в разных частях диска. Так что о 20 Гб можешь забыть. M>Тебе не зря ведь приводили стоимость дисковых операций по сравнению со всеми остальными...
Тфу 20МБ. Это скорость чтения записи по байтам.
S>> И как они еще ворочаются. 20ГБ в сек значит предел для них. А вы тут SQL SQL. M>Да. занимательная у тебя получается арифметика.
Ну ошбся в тыщу раз 20МБ
S>> То есть если страницы в памяти то они все равно каждый раз считываются с диска???? M>Нет конечно, но все страницы не с кешируешь.
А их много и не надо только к частобращаемым а обычно это актуальные остатки справочники итд которые легко помещаются даже в обычный объем памяти. Для других задач есть ОЛАП итд.
S>> Запись в БД занимаю небольшие затраты по сравнению с чтением. M>Не большие, но вполне заметные.
Так разговор на данном этапе даже не о записи а о чтении и расширенной организации данных. Вы Синклеером говорите что ООП на стороне сервера это тормоза, а я что нет и даже во многих случаях выигрышь. А нужна прежде всего гибкость и скорость разработки а не за сколько выполнится тот или иной запрос. ECO, OBjectSpasec на сторону сервера!!!!!
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Но при объеме памяти больше чем БД на подкачку время не будет тратится. S> А по поводу 10 человек то просто с синхронным чтением и записью на откомпилированных выборках и записях это вообще не заметно, т.к. глобальные выборки делаются редко а все остальное занимает милисекунды меньшее чем посылка пакета по сети которые становятся в очередь.
По этому поводу есть анекдот хороший...
Смотрит медведь на бегемота, час смотрит, два, три... Наконец бегемоту это надоедает он и говорит:
— Ну чего уставился?
— Да вот думаю, таким бы хлебальцем, да медка бы навернуть!
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Прям минуя ядро ОС и его дисковый кеш менеджер?
Именно так.
AS>Более того, никогда данные не пишутся на диск сразу же. Они попадают в buffer pages менеджера буферов, откуда по checkpoint-у перекачиваются на диск.
По чекпоинту данные из лога перебрасываются в основную базу. При фиксации данные всегда сбрасываются на диск в лог — это азбука.
AS>Так что Ваня, марш учить теорию и читать Дилани.
Ты это кому-нибудь другому говори.
AS>C Merle бесполезно спорить. Он глух как support@rsdn.ru и никогда не признается, что лоханулся. Ведь модер форума БД, да еще и такой парень как Merle просто не может лохануться!
Алекс, забываешься. Фиг бы с ним но ты еще не прав и по сути дела.
AS>А то, что он немного путает сброс данных и запись log records в лог — ну это не беда.
А теперь расскажи мне, что такое Log records. И как именно они пишутся в лог пишутся в лог, что такое лог и зачем он вообще нужен.
Нет, я жду.
AS>В конце концов, он всегда тебе сможет доказать, что log records это тоже ведь данные!
Нет, не данные? А что это, расскажи пожалуйста?
Здравствуйте, DarkGray, Вы писали:
DG>Дело-то не сколько памяти адресуется и поддерживается чипсетом, а сколько это память стоит.
Вот и я о том же. Мы еще IA32 не исчерпали, а уже ждем панацеи от Amd64. Бред. Вопрос именно в том, что пока мало кто может себе позволить сервак с более чем 4 GB памяти.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, avbochagov, Вы писали:
A>Скорость разработки не увеличивается. Она такая же. A>А вот скорость работы заметно выше.
Вот странно, что success stories все больше говорят об ускорении разработки, а не о увеличении производительности. Но тебе, наверное, виднее.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Anatolix, Вы писали: S>>Согласен. РБД — не панацея. Просто потому, что большинство из них садится в лужу на "простейших" запросах типа select * from plane where (x-x0)*(x-x0)+(y-y0)*(y-y0)<R*R
A>На них все садятся. Объектная БД требует специальную структуру данных чтобы такие запросы быстро выполнять. При этом если у тебя формула измениалась то программу переделывать в объектной базе сложнее.
A>В реляционной достаточно сделать индекс по вычисляемому полю, или просто это поле хранить в таблице, заполнять триггером можно (а можно и руками).
Увы. В приведенном примере никакого вычисляемого поля ввести нельзя. Нужно рассматривать нелинейные системы индексации, про которые, к слову, почти ничего и не разработано. Коммерчески, вроде как, применяются R-деревья и Mail-деревья.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Alexey Shirshov, Вы писали: AS>А каким образом хорошая скорость B+tree может быть связана с дисковыми операциями?
Таким, что оно минимизирует количество обращений к диску, а не разыменования указателей в памяти. Вот и всё.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Прям минуя ядро ОС и его дисковый кеш менеджер?
Именно так, читай CreateFile, флаг FILE_FLAG_WRITE_THROUGH.
FILE_FLAG_WRITE_THROUGH
Instructs the system to write through any intermediate cache and go directly to disk. The system can still cache write operations, but cannot lazily flush them.
AS>Более того, никогда данные не пишутся на диск сразу же. Они попадают в buffer pages менеджера буферов, откуда по checkpoint-у перекачиваются на диск.
Ты либо что-то не то читаешь, либо где-то не там. Берем MSSQL, простейшая транзакция.
BEGIN TRANSACTION
INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
А теперь смотрим какие действия выполняются при выполнении подобной операции:
BEGIN TRANSACTION Written to the log cache area but there is no need to flush to stable storage because the SQL Server has not made any physical changes.
INSERT INTO tblTest
1. Data page is retrieved into SQL Server data cache, if not already available.
2. The page is latched, pinned, and marked dirty, and appropriate locks are obtained.
3. An Insert Log record is built and added to the log cache.
4. A new row is added to the data page.
5. The latch is released.
6. The log records associated with the transaction or page does not need to be flushed at this point because all changes remain in volatile storage.
COMMIT TRANSACTION
1. A Commit Log record is formed and the log records associated with the transaction must be written to stable storage. The transaction is not considered committed until the log records are correctly assigned to stable storage.
2. Data page remains in SQL Server data cache and is not immediately flushed to stable storage. When the log records are properly secured recovery can redo the operation if necessary.
3. Transactional locks are released.
То есть, в доке к сиквелу английским по белому написано, что log records должны сбросится на диск при фиксации транзакции. log records содержит сами данные, для того, чтобы в случае любого сбоя эти данные можно было бы накатить на основную базу. Надеюсь, для тебя не сюрприз, что весь дисковый обмен в СУБД идет постранично, то есть даже если на диске надо поменять 1 байт, то перезаписывается вся страница целиком.
А теперь объясни мне пожалуйста, чем, в контексте нашего разговора, это лучше чем просто сброс страницы данных на диск (в плане производительности)?
И так, еще раз. Я утверждаю, что при фиксации транзакции данные обязаны быть сброшены на диск — будешь спорить?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Alexey Shirshov, Вы писали:
AS>>Прям минуя ядро ОС и его дисковый кеш менеджер? M>Именно так, читай CreateFile, флаг FILE_FLAG_WRITE_THROUGH. M>
M>FILE_FLAG_WRITE_THROUGH
M>Instructs the system to write through any intermediate cache and go directly to disk. The system can still cache write operations, but cannot lazily flush them.
О каком кэше идет речь. Так как система сама кэширует страницы. А есть еще кэш диска который наращивается в Raid массивах?????
Каков дневной объем лога??? Разницы нет что записывать байт что страницу.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> О каком кэше идет речь. Так как система сама кэширует страницы. А есть еще кэш диска который наращивается в Raid массивах?????
Еще раз повторюсь. Во всех mission critical системах все аппаратные кеши на запись настоятельно рекомендуют отключать.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> О каком кэше идет речь. Так как система сама кэширует страницы. А есть еще кэш диска который наращивается в Raid массивах????? M>Еще раз повторюсь. Во всех mission critical системах все аппаратные кеши на запись настоятельно рекомендуют отключать.
И еще записывать в амбарную книгу (и это не шутка видел и такие вещи).
Давай все таки определимся и займемся арифметикой. Журнал транзакций необходимая вещь и однозначно должна быть прописана любая трнзакция. Но под него как правило отводится отдельный диск. Какова скорость записи на современные диски???? Каков объем информации записываемой например за день???
Каково время записи единичной информации????
В иоге получим суммарное время записи в журнал транзакций. Очень интересно узнать эту величину.
И сравнить с временем доступа к записям обсчет результатов и уже самой конечной фазой — запись.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали: S> Для домашних комьтеров это уже норально, а ты о серверах. Стоимость Amd64 на порядки ниже IA32
Ну хватит с темы-то съезжать, а? Тебе русским по белому пишут: для СУБД неважно, что применяется, Pentium IV или Athlon 64. Память для них стоит одинаково. Ты тут пел про какие-то проблемы с адресным пространством, которые якобы решаются с помощью 64 разрядов. Так вот — НЕТ этих проблем. Уже 10 лет как нету.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Блин, Иван, ну дай ты ему возможность тебя поймать, а? Мы вообще не про запись говорили. И не стоит про нее начинать, потому что эта тема никакого отношения к RID vs PK не имеет, равно как и к противоборству иерархических СУБД с реляционными. Техника протоколирования никак не меняется.
Да, действительно, на практике если у тебя working set относительно небольшой, то ты можешь вообще никогда не выполнять считывания с диска. Ну поменял ты состояние страницы, даже если выбранная схема протоколирования требует ее отфлашить — ну и пес с ним, пока тебе не понадобилось место в страничном кэше — можно ничего не читать. Вообще интересная теория — классики рассматривают случаи неприменимости двухпроходных алгоритмов, а у нас вообще все полгига базы можно в память отмапить, и еще полтора для временных отношений останется.
Вопрос-то теперь ровно в том: каков характерный размер дополнительной памяти необходим под временные буфера, если все join происходят исключительно при помощи RID? И не окажется ли так, что мы всегда для таких случаев сможем применять алгоритмы с пайплайнингом, оставляя для более екзотических джойнов старые добрые B-деревья?
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Блин, Иван, ну дай ты ему возможность тебя поймать, а?
Да что я, против что ли? Пусть ловит, только по делу, а он же откровенную глупость говорит.
S>Мы вообще не про запись говорили. И не стоит про нее начинать, потому что эта тема никакого отношения к RID vs PK не имеет, равно как и к противоборству иерархических СУБД с реляционными.
Имеет, хотя, возможно, не в первом приближении.
S>Да, действительно, на практике если у тебя working set относительно небольшой, то ты можешь вообще никогда не выполнять считывания с диска.
Ну вообщем да. Только на таких системах (где все данные в память влезают) разница в разы между использованием хеш-таблицы и дерева на время отклика практически никакого эффекта не оказывает. Эти разы, по любому микросекунды.
А вот как только размер базы вырастает на столько, что в память перестает помещаться (а БД имеют свойство расти), то деревья сразу же начинают выигрывать, причем существенно.
S> Ну поменял ты состояние страницы, даже если выбранная схема протоколирования требует ее отфлашить — ну и пес с ним, пока тебе не понадобилось место в страничном кэше — можно ничего не читать. Вообще интересная теория — классики рассматривают случаи неприменимости двухпроходных алгоритмов, а у нас вообще все полгига базы можно в память отмапить, и еще полтора для временных отношений останется.
Но опять-таки, это все шевелится ровно до тех пор, пока база влезает в память, а гарантировать это можно далеко не всегда.
S>Вопрос-то теперь ровно в том: каков характерный размер дополнительной памяти необходим под временные буфера, если все join происходят исключительно при помощи RID?
Каким образом? У нас для каждой записи будет прямая ссылка на остальные записи? Для всех связей, которые могут быть в системе?
S>И не окажется ли так, что мы всегда для таких случаев сможем применять алгоритмы с пайплайнингом, оставляя для более екзотических джойнов старые добрые B-деревья?
А смысл? Возможно это того и стоит, но в первом приближении выигрыш в несколько раз, это микросекунды. И вполне может оказаться так, что сложность сопровождения всего этого хозяйства окажется дороже.
Что-то мне не очень верится пока в эту идею.
DG>>Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы. S> 6-9 килобаксов.
128гб? ссылку, пожалуйста.
DG>>Если же, например, описания идут не plain-текст, а rich-текстом (doc, html, xml), то описание уже может быть и 2000 символов, и четыре тысячи, а ведь скорее всего захочется и full-text index по этим описаниям- это еще одна копия этих же данных и т.д. S> А кто предлагал использовать doc, html, xml.
Пользователь.
S> Речь идет о несколько другой организации хранения данных и работа с данными как в локальных базас с ООП надстройкой над хранимыми данными и обрабокой на стороне сервера. Теже ECO ObjectSpace работают только на стороне клиента. На стороне сервера этого нет. Для объектного подхода нужени быстрый доступ по ссылкам а это можно решить введение прямой ссылки (номер записи)
Что мешает сделать индекс для реляционной базы, который будет хранить эту прямую ссылку?
ИМХО, проблема не в прямых ссылках, а в том, что реляционная база не поддерживает полиморфизм.
Если у нас есть таблица "одежда", и таблица "еда", то сделать таблицу "отгружаемый товар" — очень тяжело.
Потому что реляционная база не поддерживает ссылкы на разнотипные (из разных таблиц) данные.
Но может это просто стоит прикрутить к реляционное базе?
S> Да огромная цифра. Есть фирмы с множеством складов по 20 компьютеров и у каждого очередь. И работали на DBASE но это простейшие операции где сложный расчет не нужен.
Такие базы очень примитивные, и плохо покрывают реальные запросы менеджеров.
Менеджера интересуют следующие фичи:
1. На сколько эффективно используется складское помещение?
2. Автоматическое формирование цены на основе ряда показателей (закупочная цена, налоги, курс валюты)
3. Кластеризация покупателей, а также стандартная корзина каждого кластера
4. Оплата платежей, используя пластиковые карточки, корпоративные счета и т.д.
5. Гибкая система формирования скидок.
и т.д.
Здравствуйте, Serginio1, Вы писали:
S> Каково время записи единичной информации???? S> В иоге получим суммарное время записи в журнал транзакций. Очень интересно узнать эту величину. S> И сравнить с временем доступа к записям обсчет результатов и уже самой конечной фазой — запись.
Занимательная статистика...
Конкретные цифры не знаю, но частенько наблюдал, как транзакции выстраиваются в очередь, читобы записать данные на диск. Очередь не на блокировках, ни на чем-то еще, а именно ожидание пока физическое устройство освободится и сможет записать/считать очередную порцию данных. Пропускную способность диска ты знаешь лучше меня, она здесь ограничивающий фактор, вот и считай какой объем данных проползает в день через такую систему.
Здравствуйте, DarkGray, Вы писали:
DG>>>Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы. S>> 6-9 килобаксов.
DG>128гб? ссылку, пожалуйста. http://www.amdnow.ru/reviews/hammer/index6.shtml
DG>>>Если же, например, описания идут не plain-текст, а rich-текстом (doc, html, xml), то описание уже может быть и 2000 символов, и четыре тысячи, а ведь скорее всего захочется и full-text index по этим описаниям- это еще одна копия этих же данных и т.д. S>> А кто предлагал использовать doc, html, xml.
DG>Пользователь.
S>> Речь идет о несколько другой организации хранения данных и работа с данными как в локальных базас с ООП надстройкой над хранимыми данными и обрабокой на стороне сервера. Теже ECO ObjectSpace работают только на стороне клиента. На стороне сервера этого нет. Для объектного подхода нужени быстрый доступ по ссылкам а это можно решить введение прямой ссылки (номер записи)
DG>Что мешает сделать индекс для реляционной базы, который будет хранить эту прямую ссылку?
Это вопрос к разработчикам. Есть проблемы при обмене с базами, когда вместо прямой ссылки нужно подставлять другой PK для обмена данными. DG>ИМХО, проблема не в прямых ссылках, а в том, что реляционная база не поддерживает полиморфизм. DG>Если у нас есть таблица "одежда", и таблица "еда", то сделать таблицу "отгружаемый товар" — очень тяжело. DG>Потому что реляционная база не поддерживает ссылкы на разнотипные (из разных таблиц) данные.
DG>Но может это просто стоит прикрутить к реляционное базе?
Тоже не проблема, но упирается все в SQL а в нем все беды такого подхода. А подход работы как с локальными базами отметается из- за безопасности (неизвестно что ты будешь воротить в адресном пространстве сервера, но это уже проблемы разработчика) и вообще то нужна компиляция всех связей в том числе и построенных на таблицах объектов.
А вот на локальной БД все это строится легко и скорость очень высокая без всякой статистики и оптимизаторов, но понятно что надежность несколько хуже и для эмуляции клиент сервера применяют TSE что бы уменьшить трафик и использовать кэширование файлов, либо самому организовывать сервер например на DCOM или сокетах. Но нужно делать еще огромный пласт по синхронизации, транзакциям итд но решаемо.
Особенно если делать свою базу. Но это так отход от темы.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
DG>>>>Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы. S>>> 6-9 килобаксов.
DG>>128гб? ссылку, пожалуйста. S>http://www.amdnow.ru/reviews/hammer/index6.shtml
И где там написано, что 128гб памяти стоит 6 килобаксов?
Там только написано:
В результате, память для программ представляется одним целым, так же, как и в обычных SMP-системах. Максимальный ее объем в 8-процессорной системе составит 128 Гбайт(!), поскольку каждый из процессоров SledgeHammer в состоянии использовать максимум 8 модулей памяти по 2 Гбайт каждый.
S> А вот на локальной БД все это строится легко и скорость очень высокая без всякой статистики и оптимизаторов,
Скорость высокая, только пока запросы, используются только те, что задумал разработчик, как только пользователь захотел подергать нестандартные запросы, то база построенная по такой схеме — либо, вообще, не может выполнить такие запросы, либо сильно проседает по производительности.
Здравствуйте, DarkGray, Вы писали:
S>> Да огромная цифра. Есть фирмы с множеством складов по 20 компьютеров и у каждого очередь. И работали на DBASE но это простейшие операции где сложный расчет не нужен.
DG>Такие базы очень примитивные, и плохо покрывают реальные запросы менеджеров. DG>Менеджера интересуют следующие фичи: DG>1. На сколько эффективно используется складское помещение? DG>2. Автоматическое формирование цены на основе ряда показателей (закупочная цена, налоги, курс валюты) DG>3. Кластеризация покупателей, а также стандартная корзина каждого кластера DG>4. Оплата платежей, используя пластиковые карточки, корпоративные счета и т.д. DG>5. Гибкая система формирования скидок. DG>и т.д.
5. План закупок на основании продаваемости товара и его остатков и периодичности поставок итд.
Вот все перечисленное тобой вещи не составляют больших проблем и любой программист 1С щелкает все это как семечки. Проблемы возникают с организацией сложных расчетов при проведении документа. Обычно поступают так документы проводятся с минимальными рассчетами а в конце дня по ним формируются сложные проводки но уже с сгруппированными данными или консолидируются в другой базе где работа ведется с общими данными уже сгруппированными для нормального учета. В том числе и олап. В принципе даже желательно разбивать на отдельные специализированные базы и 1 универсальную.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, DarkGray, Вы писали:
DG>>>>>Итого цена получилась 3000 * 2-5 * 3-10 * 3-10 * 2-5 ~ 700000$, число, конечно, не очень большое, но довольно ощутимое, для отдельно взятой средней фирмы. S>>>> 6-9 килобаксов.
DG>>>128гб? ссылку, пожалуйста. S>>http://www.amdnow.ru/reviews/hammer/index6.shtml
DG>И где там написано, что 128гб памяти стоит 6 килобаксов?
Прошу прощения ошибся на порядок. Ну у отдельно взятой фирмы и объем баз несколько другой.
DG>Там только написано: DG>
DG>В результате, память для программ представляется одним целым, так же, как и в обычных SMP-системах. Максимальный ее объем в 8-процессорной системе составит 128 Гбайт(!), поскольку каждый из процессоров SledgeHammer в состоянии использовать максимум 8 модулей памяти по 2 Гбайт каждый.
Уже есть 32ГБ а про 128 был ответ на ограничение на 64 ГБ для IA64. S>> А вот на локальной БД все это строится легко и скорость очень высокая без всякой статистики и оптимизаторов,
DG>Скорость высокая, только пока запросы, используются только те, что задумал разработчик, как только пользователь захотел подергать нестандартные запросы, то база построенная по такой схеме — либо, вообще, не может выполнить такие запросы, либо сильно проседает по производительности.
Ну да в Парусе,Навижн, Акзапте, 1С пользователи дружно жмут Select * From ???? Достаточно жестко забитые программы, только отчетами и можно по моему баловаться а случись что разработчики за новый гонорар все подправят.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Так разговор на данном этапе даже не о записи а о чтении и расширенной организации данных. S>Да, я намеренно избегал говорить о записи. Там все начинает жить несколько по-другому. Скорость тут ни при чем, вопрос в том — не напоремся ли мы при использовании RID на необхдимость перезаписи ссылок? Как там с дефрагментацией удаленного дело обстоит?
Обычно как везде из удаленных записей организуется список И у каждой таблицы есть два поле FirstDeleted.
При удалени записи Record.Next:=FirstDeleted; FirstDeleted:=Record.RID. Понятно что размер записи не должен быть меньше 2 инта если нам хватает 2 милиарда записей. Проблема только при обмене данных и придется делать единый PK для обмена между базами получая все туже реляционность, но внутри базы использовать RID. S>>Вы Синклеером говорите что ООП на стороне сервера это тормоза, а я что нет и даже во многих случаях выигрышь. S>Нет, я этого нигде не говорил. Просто ты валишь в одну кучу совершенно не связанные между собой вещи. ООП не имеет никакого отношения к иерархическим базам данных; они, в свою очередь, не имеют никакого отношения к проблеме RID vs PK.
Это как бы две составляющие ООП имеет отношение к различным способам организации данных и легко к ним адаптируется. S>>А нужна прежде всего гибкость и скорость разработки а не за сколько выполнится тот или иной запрос. S>Вот второе высказывание с твоей стороны в этой беседе, c которым я могу согласиться. Ты в следующий раз так и начинай с разумных вещей, а не рассказывай про то, как двусвязные списки побеждают RDBMS Я все же не вполне согласен, в том смысле, что совсем отменить требования performance нельзя. Но важность скорости разработки, конечно же, рулит чем дальше, тем сильнее. S>>ECO, OBjectSpasec на сторону сервера!!!!! S>Итак, предлагаю закончить эту дискуссию на постулировании трех вещей:
S>1. Алгоритмы, применяемые в RDBMS, были разработаны для условий нехватки вычислительных мощностей и памяти S>2. Снижение стоимости памяти может сделать оправданным применение на низком уровне тех алгоритмов, которые ранее игнорировались в мире RDBMS S>3. Снижение стоимости вычислительных мощностей выдвигает на первый план скорость разработки систем, а не быстродействие при эксплуатации, что может сделать оправданным применение на низком уровне тех алгоритмов, которые ранее игнорировались в мире RDBMS.
S>Следующий виток — в новой ветке
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, avbochagov, Вы писали: A>Хорошо, не буду. Просто для примера: крупный магазин работал на системе аналогичной Cache несколько лет, размер все базы (бухгалтерия, склад, и т.д.) не превысил 700МБ — соотвественно сервер P3 266, 128МБ озу.
A>Сейчас систему сменили на 1с sql — купили сервер P4 2ГГЦ, 1ГБ озу, сокращение рабочих мест с 23 до 8, жалуются что медленно...
Аргументы про 1С против RDBMS не принимаются.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Это ты вообще зря. Мне кажется ты его не пользовал совсем — что так заявляешь. И проповедует его далеко не MS (и уж точно не он его придумал). Он на Unix платформах вообще помоему раньше появился.
Мы уже победили, просто это еще не так заметно...
наличие указаных тобой "пропастей", хотя мой опыт как прикладного программиста еще не слишком велик. 
