Здравствуйте, 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 >>
и солнце б утром не вставало, когда бы не было меня
Построение объектной модели так, чтобы производительность была не катастрофически хуже RDBMS — вот наша задача 
