Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 72 73 74 75 76 [77] 78 79 80 81 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Gluk (Kazan)
2 Ptn

Cache в силу своих архитектурных причуд даже банальный FullScan не может организовать, что уж тут о хэшах говорить ?

Как понимать эту заявление? Вы доподлинно знаете Cache и COS? Или это опять болтовня
по поводу "у вас SQL неправильный"?
8 янв 07, 13:58    [3613239]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
Ну а если серьезно - не может так как ВАМ этого хочеться.


Что еще раз свидетельствует о том, что нифига то Вы не поняли

Ptn
Давайте будем честны сами с собой.


Присоединяюсь к сему благому пожеланию и всеж таки откланиваюсь
Работы дофига, ничего личного
8 янв 07, 14:07    [3613249]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
frutalino
В Cache можно 256 PC в параллель поставить легким движением руки, вставляющей разьем RJ45 в свич - и у них будет в значительной степени общее озу, обращение к которому уменьшает дисковые операции сервера.Своего рода гипертранспорт и гипер-озу.

А давайте теперь посчитаем. Ну пусть у Вас там даже оптоволокно. Итого общая пропускная способность ~100МБайт/с - т.е. в районе скорости линейного чтения ОДНОГО современного винтчестера (я не говорю про нормальные дисковые массивы, где скорость будет значительно выше). Разделим это на 256 и что мы видим? 390 КБ данных на один узел в секунду. А если данные еще и как-то после обработки нужно опять между узлами передавать? Разделим эти несчастные 390 КБ на 2? На 3? На сколько?
Ну, и кому это нужно?
8 янв 07, 14:08    [3613252]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
Gluk (Kazan)
2 Ptn

Cache в силу своих архитектурных причуд даже банальный FullScan не может организовать, что уж тут о хэшах говорить ?

Как понимать эту заявление?


Понимать так, что в Cache возможен только RangeScan, что было выяснено несколько ранее и несколько затратнее чем FullScan.

Вам тоже творческих успехов в новом Году
8 янв 07, 14:10    [3613255]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Sergei Obrastsov>>Как понимать эту заявление?

Gluk (Kazan)
Что еще раз свидетельствует о том, что нифига то Вы не поняли


Ну или как аксиому :)
8 янв 07, 14:16    [3613263]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
frutalino
Member [заблокирован]

Откуда:
Сообщений: 21
Gluk (Kazan)
frutalino
Во-во!
Ну дык каков коэффицент масштабирования в вашем «кластере»?


Приблизительно соответствующий приросту уроста ...

Что за манера задавать вопросы, смысла которых Вы не понимаете ???


Gluk первый раз за всю жизнь не "Я-кнул" - почему-то именно тогда, когда нужно было.

И ВООБЩЕ, ЧТО ЗА МАНЕРА ЗАДАВАТЬ ВОПРОСЫ, БЛ%!

МЫ НЕ ЛЮБИМ ЗАГАДЫВАТЬ ЗАГАДОК, ОТ ЭТИХ ЗАГАДОК ОДИН БЕСПОРЯДОК,
И ЕСЛИ КТО ОДЕТ НЕ ПО ФОРМЕ - БЕЙ ЕМУ ПО РОЖЕ И ВСЕ БУДЕТ В НОРМЕ.
ХЕЙ, БРАТ GLUK, ГДЕ ТВОЙ КАСТЕТ ?

да уж
вроде интеллигентный форум
х%й там
8 янв 07, 14:19    [3613270]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
frutalino
МЫ НЕ ЛЮБИМ ЗАГАДЫВАТЬ ЗАГАДОК, ОТ ЭТИХ ЗАГАДОК ОДИН БЕСПОРЯДОК,
И ЕСЛИ КТО ОДЕТ НЕ ПО ФОРМЕ - БЕЙ ЕМУ ПО РОЖЕ И ВСЕ БУДЕТ В НОРМЕ.
ХЕЙ, БРАТ GLUK, ГДЕ ТВОЙ КАСТЕТ ?


КОЛЬ ПАШЛА ТАКАЯ ПИАНКА
МНЕ КАСТЕТ НЕ НУЖЕН ДРУК
ПАДНИМАЮСЬ СПАЗАРАНКУ -
КЕРПЕЧИ КРОШУ ВАКРУГ
8 янв 07, 14:25    [3613283]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
frutalino
Member [заблокирован]

Откуда:
Сообщений: 21
Gluk (Kazan)

КОЛЬ ПАШЛА ТАКАЯ ПИАНКА
МНЕ КАСТЕТ НЕ НУЖЕН ДРУК
ПАДНИМАЮСЬ СПАЗАРАНКУ -
КЕРПЕЧИ КРОШУ ВАКРУГ


Валенки

Валенки, да валенки,
А - не подшиты, стареньки!

Нельзя валенки носить,
Ох, надо б валенки подшить.

Валенки, валенки,
А - не подшиты, стареньки!

Нельзя валенки подшить -
Надо к миленькой сходить

Нельзя к миленькой сходить -
Надо валенки подшить.

Валенки, валенки,
А - не подшиты, стареньки!

Ох ты, Коля, Коля-Николай,
Сиди дома, ... не гуляй!
Не ходи на тот конец,
Ой, не носи девкам колец!

Валенки, да валенки,
Ох, неподшиты, стареньки!

Чем подарочки носить -
Лучше валенки подшить.

Валенки, валенки,
А - не подшиты, стареньки!

Суди люди, эх, суди Бог,
Как же я любила:
По морозу босиком
К милому ходила!

Валенки, да валенки,
А - не подшиты, стареньки!
Валенки,валенки,
Эх, не подшиты, стареньки!
8 янв 07, 14:34    [3613303]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Я пару страниц назад таблицу в три поля приводил ...

Query_Text
select * from T.T


Query_Plan
Relative cost = 1333600

Read master map T.T.IDKEY, looping on ID.
For each row:
Output the row.


Ткните плииз где сдесь RangeScan ?
8 янв 07, 14:42    [3613319]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
frutalino
Member [заблокирован]

Откуда:
Сообщений: 21
Локшин Марк

А давайте теперь посчитаем. Ну пусть у Вас там даже оптоволокно. Итого общая пропускная способность ~100МБайт/с - т.е. в районе скорости линейного чтения ОДНОГО современного винтчестера . . .



с чего вдруг Вы взяли, что 100МБайт/с - это скорость "ОДНОГО современного винтчестера"?

если будет 500 сиков/секунду винчестер не сможет считать даже 1 мегабайт за час, он вообще перегреется и заклинит,
это же механическое устройство

но опять же это версия, а не утверждение
8 янв 07, 14:44    [3613321]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
Ткните плииз где сдесь RangeScan ?


На физическом уровне
8 янв 07, 14:55    [3613330]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Gluk (Kazan)
Ptn
Ткните плииз где сдесь RangeScan ?


На физическом уровне


В отличие от чего ?

Вас не устраивает то что Каша на физическом уровне работает по другому нежели MS-SQL что ли ?

Всё таки неплохо бы услышать от вас какое-нибудь пояснение или тынц.

ЗЫ: Поправьте меня если я заблуждаюсь - но сами вот эти понятия FullScan, RangeSacan - не логического ли они уровня.
8 янв 07, 15:09    [3613351]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
Gluk (Kazan)
Ptn
Ткните плииз где сдесь RangeScan ?


На физическом уровне


В отличие от чего ?

Вас не устраивает то что Каша на физическом уровне работает по другому нежели MS-SQL что ли ?

Всё таки неплохо бы услышать от вас какое-нибудь пояснение или тынц.

ЗЫ: Поправьте меня если я заблуждаюсь - но сами вот эти понятия FullScan, RangeSacan - не логического ли они уровня.


RangeScan - поочередный просмотр всех листовых страниц B+-дерева в порядке возрастания ключей, разумеется в случае Cache это скорее Index Full Scan, так как нет переходов по ROWID к строкам таблицы.
FullScan - поочередный просмотр всех блоков heap-организованной таблицы, наклав на порядок возрастания ключей. Преимущество в том, что может быть задействовано многоблочное чтение, в результате чего этот данный метод доступа получается СУЩЕСТВЕННО дешевле.

В Cache нет heap-организованных таблиц, стало быть FullScan невозможен

Суть не в том, что сделано не так как в MS SQL или Oracle, а в том, что последние обеспечивают существенно большее количество возможностей хранения данных на физическом уровне. Иногда выгоднее применять IOT-ы, иногда heap-организованные (обычные) таблицы, иногда кластеры.
Cache не предоставляет выбора. Только IOT-ы
8 янв 07, 15:21    [3613369]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

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

Нет как раз не так - не нужен никакой лидирующий язык - но я могу сделать простой скриптовый язык - что бы юзеры могли писать отчеты прямо в интерфейсе приложения.

Для разработчиков систем лидирующие языки все таки пока еще нужны.
А если про Юзеров, то можно вспомнить, что кроме SQL есть еще реляционный язык БД QBE (там бланк запроса заполняют) и туча тулс для генерации отчетов. В аксцее кстати отчеты поддерживают не скриптовый язык, а Басик для форматирования отчетов. Т.е. если не хватит конструктора можно наарматировать, хоть олимпийскую елку для соравнований.
Да и скриптовых готовых языков полно. XML, например. Он тоже лидирующий среди скриптовых и его тоже поддерживают РСУБД и не только.

Ptn

Со стороны ODBC это обыкновеннейший SQL-сервер.

Он сначало должен быть SQL - сервером, а потом можно говрить об ODBC и прочих средствах доступа из клиентов к серверу. Пока мы знаем, что он внедрил SQL - другой способ доступа из прог к SQL - серверам. Т.е. это значит, что на нем можно писать клиентские проги к настоящим
SQL серверам.
Является ли он РСУБД? А потом уже сетевая архитектура - файл сервер он там или сервер БД (SQL сервер, в частности). Т.е. поддерживает он РМД или нет. Если на нем как на С можно самому налабать поддержку РМД, то это тулса для разработки СУБД. Но Вы сказали нет. Тогда он должен поддерживать реляционные таблицы. Реляционные органичения целостности. Реляционный язык БД, а язык М выкинуть совсем, либо сделать его расширением SQL.

Ptn

И если её внимательно прочитать то можно увидеть что сравнение как таковое отсутствует.

Не совсем так. Но вот мы с Вами пытаемся прояснить насчет одного из важнейших аспектов сравнения - МД. И кстати, зачем тогда они сравнивают М с SQL, если М тоже типа РСУБД?
Надеюсь, М не реляционный язык? То что он не декларативный и не ассоциативный, надеюсь выяснили?

Ptn

Насколько я знаю негатив связан с тем что ISC выкупила фирмы и патенты связанные с М - и сейчас волевым решением выдвигает на передний план Cache, задвигая на задний ДТМ и МСМ.

Что это значит? Что мнением тех парней, что не довольны стоит принебреч? Или они Кашу считают еще хуже даже ДТМ и МСМ, на которые ISC нашла основания забить? Или что в плане отношения мумпсистов к Каше?

Ptn

>>Это ставит под сомнение ООМД в М.
Нет - его там и не было. Я уже говорил ООП появляется на уровень выше.

>>А вы говорили любая МД в М.
Такое мое мнение (с)

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

Ptn

Простите ... а разве это не так ?

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


Ptn

И были жутко популярны - увы - сеть сделала свое дело.

Заметьте - популярнее М. Откаты? И счас популярны для своего класса задач, причем в сети. Но мы то про все случаи из применения БД в ИТ?

Ptn

Ну и о чём тогда спор ;)))

Ну не о том, что лучше PL/SQL или М. Пока о том что РСУБД лучше М. Т.е. SQL + PL/SQL (или другое расширение - у СКуля T-SQL, по моему) для БД и + современные языки для клиентов и серверов приложений лучше ИС на М.
А в дальнейшем не спорим, а пытаемся прояснить как соотностятся MSSQL и Каша.

Ptn

Может - но не только - поэтому ISC настаивает на другом термине.
Куб со стороны тоже квадрат - но всё таки он не квадрат.

Для начала хотелось бы прояснить про каждый из квадратов куба. Если он РСУБД, то это можно отдельно прояснить. Каков, например, там диалект SQL и все такое. Что на нем можно.

Ptn

Это проблема понимания что такое язык БД и какав он может быть. (Как и в случае с джавой)

Ну это не проблема. SQL, пример, одного из признанных языков БД. Даже для ООСУБД требование подобного языка БД признано. Там и налабали OQL.
Должен позволять создавать все обекты БД, юзеров БД, управлять ими, извлекать инфу (включая системную), изменять ее. Не должен позволять ничего не связанного с управлением БД, например, писать драйверы.
А что в случае с Джавой? Она должна позволять реализовывать алгоритмы, програмные констркуции, модель приложения. Хоть в текстовом редакторе будь она написана. Ну там еще имеют значение библиотеки классов, для реализации известных паттернов.

Ptn

Как вы и указали SQL это специализированный язык. А вот М -неспециализированный.
Но в сравнениях это постоянно забывают.
Порой указывая на более широкий профиль М как на недостаток - что совершенно неясно.

А Вы вроде признали где-то, что специализированный как правило лучше подходит для того на чем он специализируется, чем не специализированный. Поэтому и не ясно.
8 янв 07, 15:28    [3613379]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
frutalino
чего вдруг Вы взяли, что 100МБайт/с - это скорость "ОДНОГО современного винтчестера"? если будет 500 сиков/секунду винчестер не сможет считать даже 1 мегабайт за час, он вообще перегреется и заклинит,
это же механическое устройство

А еще иногда бывает полезно читать не между строк. Какие могут быть 500 сиков в секунду при линейном чтении? А цифру эту (впрочем как и все интересующиеся) могут взять у производителей винчестеров. А что касается приличного дискового массива, то там далеко не один диск, существуют различного рода системы кэширования, как на дисковых массивах, так и в СУБД, да и информацию на диск можно писать не абы как. Так что поднимать за секунду с диска 100 МБ - не вопрос (ну кроме разве что очень специфических случаев). А что касается сиков, то 500 сиков - это порядка 5 секунд будет как раз мегабайт при размере сектора в 2048 байт и считается. Только вот получить эти 500 сиков будет проблематично, т.к. нормальная СУБД этому будет очень даже мешать...
А что же будет происходить в вашем чудо-кластере?
Может обсудим как там транзакция будет работать на таком количестве машин и сколько накладных расходов нужно будет на сохранение одной записи?
8 янв 07, 15:44    [3613398]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Gluk (Kazan)

RangeScan - поочередный просмотр всех листовых страниц B+-дерева в порядке возрастания ключей, разумеется в случае Cache это скорее Index Full Scan, так как нет переходов по ROWID к строкам таблицы.
FullScan - поочередный просмотр всех блоков heap-организованной таблицы, наклав на порядок возрастания ключей. Преимущество в том, что может быть задействовано многоблочное чтение, в результате чего этот данный метод доступа получается СУЩЕСТВЕННО дешевле.

Дело в том, что в Cache ВСЕ расписано, как Вы говорите, по индексам, нет другой структуры.
FullScan здесь частный случай RangeScan, с заданием NULL/NULL для начального/конечного узла.
Поскольку дерево пишется все-таки блоками, то и читается оно блоками, а следовательно на N
узлов - одно чтение блока с диска, они все ж таки друг за другом располагаются. Почему так, а не иначе, вполне понятно, поскольку данные не находятся в каком-то другом месте, а сидят на узлах. Как в IOT, ага.

Gluk (Kazan)

В Cache нет heap-организованных таблиц, стало быть FullScan невозможен

Если под FullScan понимать побайтное чтение файла с диска - то да, это конечно не то. Но ведь и у Вас он выглядит несколько по-другому, разве нет? :) Ну а логически разницы нет.

Лирическое отступление по поводу скорости: я не спорю, что count(*) в Oracle/MSSQL сработает быстрее чем перебор массива в Cache, это понятно и учитывается. Но вот часто ли FullScan используется на больших БД?

Gluk (Kazan)

Суть не в том, что сделано не так как в MS SQL или Oracle, а в том, что последние обеспечивают существенно большее количество возможностей хранения данных на физическом уровне. Иногда выгоднее применять IOT-ы, иногда heap-организованные (обычные) таблицы, иногда кластеры.
Cache не предоставляет выбора. Только IOT-ы

Кластеры здесь уж совсем не при чем. В Cache они тоже есть. Или вы хотели сказать partitions?
8 янв 07, 15:56    [3613414]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov

Дело в том, что в Cache ВСЕ расписано, как Вы говорите, по индексам, нет другой структуры.
FullScan здесь частный случай RangeScan, с заданием NULL/NULL для начального/конечного узла.


Да не частный он случай. RangeScan ФИЗИЧЕСКИ НЕ МОЖЕТ задействовать многоблочное чтение ОС, поскольку БЛОКИ на диске лежат вразброс. Cache могла бы реализовать аналог Index Fast Full Scan (просмотр всех, а не только листовых блоков индекса), но насколько мне известно (поправьте меня если это не так) не реализовала

Sergei Obrastsov

Поскольку дерево пишется все-таки блоками, то и читается оно блоками, а следовательно на N
узлов - одно чтение блока с диска, они все ж таки друг за другом располагаются. Почему так, а не иначе, вполне понятно, поскольку данные не находятся в каком-то другом месте, а сидят на узлах. Как в IOT, ага.


Чувствуется Ваш опыт работы с B-деревьями. Блоки лежат подряд Счаззз, как минимум там есть не листовые блоки, которые при RangeScan не просматриваются. Вразброс идет чтение, вразброс :)

Sergei Obrastsov

Но вот часто ли FullScan используется на больших БД?


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

Также если требуется прочитать более 5 (или 20, разные источники дают разную цифру) процентов строк (для составления отчета например) таблицы, FullScan становится выгоднее.
Для Cache цифра будет побольше, так как нет обращения к блокам собственно таблицы, ну пусть не 20, Если Вам понадобиться читать более 30% строк таблицы, единсвенно возможная для вас организация данных на физическом уровне СТАНЕТ ТОРМОЗОМ.

Sergei Obrastsov

Кластеры здесь уж совсем не при чем. В Cache они тоже есть. Или вы хотели сказать partitions?


В Oracle кластеры это не только RAC, имелись в виду объекты, сохраняющие в одном блоке данные нескольких (или одной, тоже применяется) таблиц, заранее соединенных join-ом. По хэшу либо по B-деревянному индексу.

Partitions тема для отдельного курения, они позволяют (кроме всего прочего) уменьшить объем данных читаемых FullScan-ами. Вам опять же недостижимо, увы
8 янв 07, 16:12    [3613437]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
))
frutalino
М программа – это 1000 запросов юзеров в секунду – поймите это один раз и навсегда.

обратно не понял, погуглил "transactions per second", обнаружилось "A $2k computer can execute about 8k transactions per second". 2005 год, ms sql, здесь :)

Ну вот, посмотрел я, значит. Итак, 8k транзакций, заметьте, не 1k запросов, локально, на машине 1.6Ghz/1Gb и вся БД в RAM, они даже время выделяют на ее "warm up", сиречь засовывание туда.
Прекрасно, даже и тексты есть. Ну так я не поленился сделать аналогичный тест в Cache.
Без фиксирования БД в памяти, правда, конечно, расширив кэш до аналогичных размеров, то есть 350 Mb. Итог: 18.1k tps. Машинка примерно такая же 1.8Ghz/1Gb, домашний комп, не $2k конечно,
подешевше. Все-таки лучше говорить о запросах в секунду.
8 янв 07, 16:21    [3613444]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
frutalino
Member [заблокирован]

Откуда:
Сообщений: 21
>> если будет 500 сиков/секунду винчестер не сможет считать даже 1 мегабайт за час
> А что касается сиков, то 500 сиков - это порядка 5 секунд будет как раз мегабайт

вообще-то за 5 секунд будет уже не 500 сиков, а 2500

> А что же будет происходить в вашем чудо-кластере?

80% сиков может идти по озу M-клиентов, не доходя до сервера
М-клиент – это компьютер, в озу которого заполз кусок М-базы
в read-запросе этот виртуальный кусок M-базы может вообще не нуждаться в обращениях к серверу

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

веб-юзеры не будут даже доходить до сервера, роль которого в концепции масштабирования уменьшается до писателя транзакций и read-старт-up загрузчика М-клиентов

итак мы приходим к Google–моде на sempron-ах.
8 янв 07, 16:28    [3613454]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Gluk (Kazan)
Да не частный он случай. RangeScan ФИЗИЧЕСКИ НЕ МОЖЕТ задействовать многоблочное чтение ОС, поскольку БЛОКИ на диске лежат вразброс. Cache могла бы реализовать аналог Index Fast Full Scan (просмотр всех, а не только листовых блоков индекса), но насколько мне известно (поправьте меня если это не так) не реализовала

Поправляю, возможен вариант просмотра именно блоков данных, не зря же там тоже ссылки правосторонние есть. Реализуется использованием неполного синтаксиса ^(index) в параметре функции перебора.

Gluk (Kazan)

Чувствуется Ваш опыт работы с B-деревьями. Блоки лежат подряд Счаззз, как минимум там есть не листовые блоки, которые при RangeScan не просматриваются. Вразброс идет чтение, вразброс :)

Во-первых, я говорю о том что 1 блок = N узлов, где N > 1. Как они там разбросаны, это уже второй вопрос; конечно чтение идет вразброс, если не заняться "дефрагментацией".

Gluk (Kazan)

Sergei Obrastsov

Но вот часто ли FullScan используется на больших БД?

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

Читаем внимательнее - написано "на БОЛЬШИХ БД". Это не там где табличек 30000 и все они малюсенькие, а там, где они именно большие.

Gluk (Kazan)

Также если требуется прочитать более 5 (или 20, разные источники дают разную цифру) процентов строк (для составления отчета например) таблицы, FullScan становится выгоднее.
Для Cache цифра будет побольше, так как нет обращения к блокам собственно таблицы, ну пусть не 20, Если Вам понадобиться читать более 30% строк таблицы, единсвенно возможная для вас организация данных на физическом уровне СТАНЕТ ТОРМОЗОМ.

Ну вот опять. Данные и индексы в M составляют одно целое. О каких собственно тормозах идет речь? Что значит "нет обращения к блокам собственно таблицы"? А к чему же я тогда обращаюсь-то?

Gluk (Kazan)

В Oracle кластеры это не только RAC, имелись в виду объекты, сохраняющие в одном блоке данные нескольких (или одной, тоже применяется) таблиц, заранее соединенных join-ом. По хэшу либо по B-деревянному индексу.

Насколько я понимаю, это уже примочки для быстроты. Никто мне не мешает сделать то же самое,
коли уж так припекло.

Gluk (Kazan)

Partitions тема для отдельного курения, они позволяют (кроме всего прочего) уменьшить объем данных читаемых FullScan-ами.

Насколько я понимаю, все-таки RangeScan-ами, а не Full.

Gluk (Kazan)

Вам опять же недостижимо, увы

Хамим... Ну да ничего, резвитесь на здоровье, я уж привык. :)
8 янв 07, 16:36    [3613461]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov

Gluk (Kazan)
Да не частный он случай. RangeScan ФИЗИЧЕСКИ НЕ МОЖЕТ задействовать многоблочное чтение ОС, поскольку БЛОКИ на диске лежат вразброс. Cache могла бы реализовать аналог Index Fast Full Scan (просмотр всех, а не только листовых блоков индекса), но насколько мне известно (поправьте меня если это не так) не реализовала

Поправляю, возможен вариант просмотра именно блоков данных, не зря же там тоже ссылки правосторонние есть. Реализуется использованием неполного синтаксиса ^(index) в параметре функции перебора.


Вообчето я говорил о возможности задействования из Cache МНОГОБЛОЧНОГО чтения на уровне ОС, хождение по правым и левым ссылкам на одном уровне это и есть RangeScan в случае B+дерева.

Sergei Obrastsov

Gluk (Kazan)

Чувствуется Ваш опыт работы с B-деревьями. Блоки лежат подряд Счаззз, как минимум там есть не листовые блоки, которые при RangeScan не просматриваются. Вразброс идет чтение, вразброс :)

Во-первых, я говорю о том что 1 блок = N узлов, где N > 1. Как они там разбросаны, это уже второй вопрос; конечно чтение идет вразброс, если не заняться "дефрагментацией".


А я говорю о том, что данные содержат ТОЛЬКО листовые блоки B+ дерева и только они будут читаться на RangeScan, никакая дефрагментация (жизненность такого подхода оставим за кадром) Вам не поможет

Sergei Obrastsov

Sergei Obrastsov

Но вот часто ли FullScan используется на больших БД?

Gluk (Kazan)
Как уже неоднократно говорилось ранее да часто. Например если таблица умещается всего в нескольких блоках, выгоднее прочитать ее целиком для поиска одной строки, чем искать по индексу.

Читаем внимательнее - написано "на БОЛЬШИХ БД". Это не там где табличек 30000 и все они малюсенькие, а там, где они именно большие.


Читаем внимательно, то что писалось про 30% это справедливо ИМЕННО для больших таблиц.
Для ОЧЕНЬ больших таблиц применяется партиционирование

Sergei Obrastsov

Ну вот опять. Данные и индексы в M составляют одно целое. О каких собственно тормозах идет речь? Что значит "нет обращения к блокам собственно таблицы"? А к чему же я тогда обращаюсь-то?


Именно поэтому 30 а не 5 ;)

Sergei Obrastsov

Gluk (Kazan)

В Oracle кластеры это не только RAC, имелись в виду объекты, сохраняющие в одном блоке данные нескольких (или одной, тоже применяется) таблиц, заранее соединенных join-ом. По хэшу либо по B-деревянному индексу.

Насколько я понимаю, это уже примочки для быстроты. Никто мне не мешает сделать то же самое,
коли уж так припекло.


В том то и дело что мешает То что на физическом уровне Вам дадены ТОЛЬКО B-деревья.
То что вы наворотите на логическом уровне для "убыстрения" ситуацию только усугубит, никак не улучшит.

Либо денормализует БД как в случае хранение max-ов и count-ов в отдельных счетчиках
Со всеми вытекающими тормозами на конкурирующем обновлении этих счетчиков и необходимостями всех этих обновлений ручками

Sergei Obrastsov

Gluk (Kazan)

Partitions тема для отдельного курения, они позволяют (кроме всего прочего) уменьшить объем данных читаемых FullScan-ами.

Насколько я понимаю, все-таки RangeScan-ами, а не Full.


Когда я говорю Full я имею в виду именно это Range будет при доступе по локально партиционированну индексу при выборке по диапазону ключей. Не всегда так везет с запросами ;)

Sergei Obrastsov

Gluk (Kazan)

Вам опять же недостижимо, увы

Хамим... Ну да ничего, резвитесь на здоровье, я уж привык. :)


Ну если Вы восприняли это таким образом, ничем не могу помочь
Под "Вам" имелось в виду Вам как пользователям Cache, экий Вы обидчивый
8 янв 07, 16:59    [3613497]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
frutalino
вообще-то за 5 секунд будет уже не 500 сиков, а 2500

Сиков будет столько, сколько позволяет механика.
автор
80% сиков может идти по озу M-клиентов, не доходя до сервера
М-клиент – это компьютер, в озу которого заполз кусок М-базы
в read-запросе этот виртуальный кусок M-базы может вообще не нуждаться в обращениях к серверу

Да, да,да. И так всегда будет вести, база распалась на независимые кусочки и каждый пользователь только с ним и работает. Только так никогда не бывает. И как только нам потребуется еще кусок базы, то нам придется его получать со скоростью 390 КБ/сек. При этом (возможно) придется закачать очень много данных, хотя может быть разумее было бы отправить часть своей выборки на другой узел и оттуда уже получить готовый ответ.
frutalino
веб-юзеры не будут даже доходить до сервера, роль которого в концепции масштабирования уменьшается до писателя транзакций и read-старт-up загрузчика М-клиентов

Да, и какие накладные расходы будут у пишущей транзакции Вы так и не огласили.
А что касается Google, так это весьма специфическое приложение мало связанное и ИС крупного предприятия, например.
8 янв 07, 17:19    [3613525]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Gluk (Kazan) В целом ваша позиция ясна. Позволю себе несколько комментариев

>>RangeScan - поочередный просмотр всех листовых страниц B+-дерева в порядке возрастания ключей, разумеется в случае Cache это скорее Index Full Scan, так как нет переходов по ROWID к строкам таблицы.

Переходы по ROWID как раз IMXO есть.
Это как раз _вроде_ в РУСБД с ROWID дело имеет только сама СУБД - предоставляя программисту определять ключи.

>>FullScan - поочередный просмотр всех блоков heap-организованной таблицы, наклав на порядок возрастания ключей.

Замечательно - в Cach'e можно полностью переопределять как структуру хранения - так и собсвтвенно механизмы доступа к ним.

>>Преимущество в том, что может быть задействовано многоблочное чтение, в результате чего этот данный метод доступа получается СУЩЕСТВЕННО дешевле.

Да вполне возможно - но от таких таблиц можно просто избавиться на этапе проектирования. Потому что нет универсальных вещей. Если в языке нет обработки исключений то программист просто напросто будет проектировать продукт с этим учетом. Точно так же ACID IMXO.

>>В Cache нет heap-организованных таблиц, стало быть FullScan невозможен

Я не настолько хорошо разбираюсь в терминах. Но дело в том что в М есть команда view - для прямого доступа к блокам БД.
С ёё помощью ничего не стоить задействовать многоблочное чтение наклав порядок возрастания индексов.
И собсно реализовать ту стратегию хранения которую требуется - если она не зарублена на этапе проектирования.
А дальше вступает в дело ООП. Который выражается в замене строк

Class T.T Extends %Persistent  -->  Class T.T Extends %PersistentHeap

>>Cache не предоставляет выбора. Только IOT-ы
Я высказал свое IMXO выше.
8 янв 07, 17:33    [3613538]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Gluk (Kazan)>>Да не частный он случай. RangeScan ФИЗИЧЕСКИ НЕ МОЖЕТ задействовать многоблочное чтение ОС, поскольку БЛОКИ на диске лежат вразброс.
Ну с одной стороны всё таки БД а не OS - RAW партиции вроде еще не отменили.

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

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

Для демона чтения возможно - но в таком случае - считайте что таблица вся в кеше.

>>Если Вам понадобиться читать более 30% строк таблицы, единсвенно возможная для вас организация данных на физическом уровне СТАНЕТ ТОРМОЗОМ.

Ну в целом да - только мне кажеться если проектировщик об этом не знает ... то да ... проблемма , тех кто его нанял :) Но IMXO в любом случае остается возможность смены алгоритма.
8 янв 07, 17:42    [3613553]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
Переходы по ROWID как раз IMXO есть.
Это как раз _вроде_ в РУСБД с ROWID дело имеет только сама СУБД - предоставляя программисту определять ключи.


Я стараюсь быть точным в формулировках. В Oracle ROWID это физический адрес данных в heap-организованных таблицах, партициях или кластерах. Поскольку всего этого благолепия в Cache нету, то и ROWID-ов быть не может. Говоря про ROWID-ы я совсем не имею в виду ручную нафигация, как Вы могли подумать

Ptn

Замечательно - в Cach'e можно полностью переопределять как структуру хранения - так и собсвтвенно механизмы доступа к ним.


Замечтательно коли так, но какова будет стоимость разработки этого велосипеда ?
Кроме того, само по себе, это еще не даст вам возможности сказать ОС, что НАДО использовать многоблочное чтение

Ptn

Да вполне возможно - но от таких таблиц можно просто избавиться на этапе проектирования. Потому что нет универсальных вещей. Если в языке нет обработки исключений то программист просто напросто будет проектировать продукт с этим учетом. Точно так же ACID IMXO.


В целом ваша позиция ясна (с)
Но так можно от всего поотказываться

Ptn

Я не настолько хорошо разбираюсь в терминах. Но дело в том что в М есть команда view - для прямого доступа к блокам БД.
С ёё помощью ничего не стоить задействовать многоблочное чтение наклав порядок возрастания индексов.


Второе весьма сомнительно, скорее всего чтение будет поблочное, причина оглашена выше

Ptn

А дальше вступает в дело ООП. Который выражается в замене строк


Это НЕСОМНЕННО перл. Теперь я знаю что такое ООП
8 янв 07, 17:48    [3613564]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 72 73 74 75 76 [77] 78 79 80 81 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить