Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 38 39 40 41 42 [43] 44 45 46 47 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
c127

Еще раз повторяю, то, что Вы предлагаете не хеш абсолютно. У Вас обычный индекс, использующий встроенный алгоритм поиска М системы, если в М, например, полный перебор, то и Ваш так называемый "хеш" ^index(hash_x1)=number будет полным перебором, хотя в теории должен быть константой. При желании конечно назвать хешем можно и это, достаточно назвать переменную hash_x1, чтобы неизвестно какой алогоритм стал хешем. А назвали бы btree_x1, был бы бинарным деревом.

Ну еще бы, конечно у меня это обычный индекс. Поскольку ничего кроме индексов и данных
на них система не хранит. Индекс ничего использовать не может, он просто есть. А уж как
я к нему обращаюсь, это уж мое дело. Или использование полного перебора, или прямое
обращение. Что же касается алгоритма, то речи об этом, насколько я помню, не было. Речь
шла о структуре. Так что вся Ваша писанина - это просто желание докопаться хоть до чего-нибудь. Понимаю и сочувствую.

В M нет "встроенного алгоритма поиска", а есть прямое обращение к узлу дерева. Возможность
выбора следующего/предыдущего узла на этом уровне - это из той же серии "прямых обращений".
Даже использование $QUERY, дающего полную ссылку до следующего узла с данными, это тоже "прямое обращение", только не на отдельном уровне, а на всем дереве.
21 ноя 06, 04:24    [3427346]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp
Ptn
Потому что тут IMXO нужна таблица с 4-мя полями! Это понятно ? С соотвествующими ДОП индексами.
??? В М эта структура ложится в один глобал. Соответственно в РСУБД индекс будет тоже один. Если ты извини, как баран, упёрся и не желаешь думать, то пусть будет 4 атрибута или скажем 200. Ну так, на всякий случай. Место они занимать не будут. Но эквивалентный индекс будет всё равно один!!!

Это очень здорово, что Вы так уверены! Я думаю, что пора прекратить споры и приступить к испытательной оценке полученных структур. Согласны?
21 ноя 06, 04:31    [3427350]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
mumps-ист
Guest
MX -- ALEX
Продаем готовый коробочный продукт для средних-мелких фирм
покупателю вообще до п..ды - сделан он на MUMPSe или на SQL-педерастии
если "оно-в-коробке" работает лучше других - значит берет и платит
патаму чта ане умеют считать бабки - и пока довольны.
пока - нет резона
MUMPS-лучше


ALEX, несколько выпросов к Вам: ваша система подерживает уровень изоляции транзакций serializable (это когда одна транзакция не видит изменения сделанные другой)?
Если да, то если не секрет какую стратегию блокировок вы используете и сколько по времени заняла реалиация данного механизма?

Мой опыт общения с Cache показал, что когда начинается честная реализация ACID (как например, объекты в Cache) - то скорость вставки падает на порядок (сравнивал запись простой структуры через прямой и объектный доступ). Чтение не тестировал, но читал, что SQL тоже хороших результатов не дает (там может и оптимизатор просто слабый).
21 ноя 06, 07:43    [3427451]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
mumps-ист
MX -- ALEX
Продаем готовый коробочный продукт для средних-мелких фирм
покупателю вообще до п..ды - сделан он на MUMPSe или на SQL-педерастии
если "оно-в-коробке" работает лучше других - значит берет и платит
патаму чта ане умеют считать бабки - и пока довольны.
пока - нет резона
MUMPS-лучше


ALEX, несколько выпросов к Вам: ваша система подерживает уровень изоляции транзакций serializable (это когда одна транзакция не видит изменения сделанные другой)?
Если да, то если не секрет какую стратегию блокировок вы используете и сколько по времени заняла реалиация данного механизма?

Мой опыт общения с Cache показал, что когда начинается честная реализация ACID (как например, объекты в Cache) - то скорость вставки падает на порядок (сравнивал запись простой структуры через прямой и объектный доступ). Чтение не тестировал, но читал, что SQL тоже хороших результатов не дает (там может и оптимизатор просто слабый).


Да при SQL скорость у Cache не блещет. На форуме есть топик там приводили сравнения скорости SQL у Oracle и Cache на одном железе на одинаковых запросах. Cache проиграл причем прилично. Запрос был не очень сложный. Если взять сложный запрс то думаю у Cache вообще все плохо будет. Даже сами InterSystem признают что SQL доступ у них не ахти какой (Но деньги за это берут немалые) :)
21 ноя 06, 08:57    [3427530]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
pavelvp>>Перестаньте сюда писать. Над вами наверное кот Экслера уже ржот...

Перестаньте мне отвечать - над Вами сил уже нет ржать :) :lol:

Анекдот.
- Сидит горЭц, играет в шахматы с бараном. Мимо проходить прохожий.
- О! и что ? хорошо играет ?
- А баран он и есть баран, отвечает горЭц.
- А счет то какой ?
- Одын - Одын.

ЗЫ: На личности вы уже давно скатились, эпитетов понаписали, - но всё еще продолжаете "играть" :)

>>Чтобы узнать как работает $order посмотрите на план запроса SergSuper.

Мне ?? Бу-га-га Ы-ы-ы-ы - а ну марш rtfm, открою по секрету плана там два. И второй ничем от SergSuper не отличается - но к сажалению коньюктивит лечать врачи а не оппоненты :)

ЗЫ: Пишу из пад стула, белые и пушистые РУСБД-ники меня учить будут как у нас проги работают ы-ы-ы [смахивает слезу умиления]. Что бы мы без ваз делали то Бу-га-га.

OS/360
>>а чем они отличаются???

Есть мнение и что машина по выполненияю плана в свою очередь является надстройкой над байт машиной. Тонкой но надстройкой.
21 ноя 06, 09:35    [3427631]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Lulay
Member

Откуда:
Сообщений: 16
CACHE очень хорошо работает с иерархическими структурами, в этом её сила.

Вариант выборки 50 млн записей из одной таблицы, это не показатель... Скорее всего, обе СУБД покажут сходные результаты. Может быть, CACHE будет чуть быстрее.
21 ноя 06, 10:09    [3427780]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Lulay
CACHE очень хорошо работает с иерархическими структурами, в этом её сила.

...а иерархическая структура эквивалентна обычной таблице из двух полей

Ну хоть напишите мне что можно такого хорошего сделать, чего я не смогу сделать с помощью таблицы из двух поле?

Вот только про скорость не надо, при выборке одной записи(а по несколько Каше не умеет) это далеко не главный показатель
21 ноя 06, 10:45    [3428027]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
Речь
шла о структуре. Так что вся Ваша писанина - это просто желание докопаться хоть до чего-нибудь. Понимаю и сочувствую.


Структура, сама по себе, НИКОМУ не нужна без тех преимуществ которые она дает. Когда говориться "хэш" - подразумевается КОНСТАНТНОЕ время доступа. Реализовать такое на МУМПСЕ не получится (хоть ты тресни), по причине того, что на физичексом уровне нам разрешено пользоваться ТОЛЬКО (очень падоброму) B-деревьями. А у них время доступа логарифмическое :)

Вам другого не дадено (и написать руками возможности нет) понимаю и сочуствую.

Еще раз повторюсь. Если кому-то придет в голову реализовать ВСЕ хранение данных в IOT - на него будут смотреть как на ДУРАКА. Хотя возможность такая безусловно имеется.
21 ноя 06, 10:56    [3428111]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Joker_Ya
mumps-ист
Мой опыт общения с Cache показал, что когда начинается честная реализация ACID (как например, объекты в Cache) - то скорость вставки падает на порядок (сравнивал запись простой структуры через прямой и объектный доступ). Чтение не тестировал, но читал, что SQL тоже хороших результатов не дает (там может и оптимизатор просто слабый).


Да при SQL скорость у Cache не блещет. На форуме есть топик там приводили сравнения скорости SQL у Oracle и Cache на одном железе на одинаковых запросах. Cache проиграл причем прилично. Запрос был не очень сложный. Если взять сложный запрс то думаю у Cache вообще все плохо будет. Даже сами InterSystem признают что SQL доступ у них не ахти какой (Но деньги за это берут немалые) :)


Речь шла не об использовании SQL-настройки, а об обеспечении более-менее честной изоляции транзакций средствами Cache
21 ноя 06, 10:59    [3428141]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Lulay
CACHE очень хорошо работает с иерархическими структурами, в этом её сила.


Если на уровне физики мы можем только обращаться к узлу B-дерева и перемещаться к следующему/предыдущему есть повод усомниться и в этом
21 ноя 06, 11:02    [3428158]     Ответить | Цитировать Сообщить модератору
 12 правил "ну я" для форума SQL.RU  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
12 правил "ну я" для форума SQL.RU:

1) Кто-нибудь что-нибудь пишет.
2) Если утверждение длинное и полное то отвечают
2.1) Ну что вы нам тут учебник копипастите
2.2) Этот автор нам не авторитет, вот вы у нашего авторитета (в нашей библии) такого не найдете.
а если короткое то
2.3) Если сила только в этом то это отстой
2.4) Столько умов работали над еще вот чем и вот чем, а вы нам тут.
3) Периодически желательно переходить на личности, ибо согласно женской логике если неправ утверждающий то неправильно и все что он утверждает.
4) Почаще нужно повторять вопросы типа "А вот мне все равно не понятно, значит так мне никто и не ответил, значит никто не знает и все кто этим занимается ламеры", это прививает теме вечный налет недоделанности.
5) Участвовать в обсуждении структур и оценки алгоритмов а-ля Кнут, с формулами, не являясь ни разу разработчиком нижнего уровня и в особенности рассуждая о системах которые четко не декларируют свое внутреннее устройство и алгоритмику.
6) Приводить свой опыт как критерий оценки всех систем на свете.
7) Насылать десяток-другой постов с одним и тем же вопросом и умничанием на тему что типа я вот не могу ничего понять, но после ответа не посылать такое эе количество постов "спасибо что вразумили", а послать в лучшем случае один, кратенько типа ну хрен с вами, работайте как вам хочется. Но потом снова все повторить.
8) Любое утверждение периодически называть преувеличением, никогда не описывая что же является границей преувеличено - не преувеличено.
9) Интересуясь чем-либо, ожидать ответа только на том языке который сам знаешь. Спрашивая о мампсе - ожидать ответа на sql.
10) Никогда не сравнивать две системы на одном железе.
11) Обсуждая программную систему, написанную N лет назад, утверждать что они все ламеры потому что не знают, что спустя какие-то 5-6 лет в другой СУБД появилась бета как раз для одной из ее функций.
12) В конце концов всегда можно написать один из типовых постов
12.1) Что вы хотели этим сказать? Это придает предыдущему посту налет нелепости.
12.2) Ну вот, началось. Придает автору весу в собственных глазах.
12.3) Что-то вас сегодня понесло. Аналогично.
12.4) В любом сообщении можно что-то уточнить. Это придает предыдущему посту вечное состояние нераскрытости темы.
12.5) В конце концов, ни одна документация не является полной.
21 ноя 06, 11:35    [3428437]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67524
Блог
Sergei Obrastsov
Что же касается алгоритма, то речи об этом, насколько я помню, не было. Речь
шла о структуре. Так что вся Ваша писанина - это просто желание докопаться хоть до чего-нибудь. Понимаю и сочувствую.

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

Есть некий интерфейс доступа к данным, например популярный в различных средах map <key, value> - то есть набор пар, в которых ключ (key) уникален и позволяет более-менее эффективно получить значение (value). Этот интерфейс может скрывать под собой разные реализации с разными характеристиками. Скажем, реализация на основе сбалансированных деревьев обеспечивает логарифмическое время выборки (как среднее, так и максимальное). Реализация хэшем обеспечивает константное лучшее время выборки при линейном худшем.

Что важно - интерфейс у этих реализаций одинаковый. Отличается у них физика реализации. Вы же нарисовали нечто, похожее по интерфейсу, в котором употребили слово hash - и пытаетесь объяснить, что это и есть "то что просили". С тем же успехом я могу нарисовать в своей программе примерно следующий код

procedure Cache ;
begin
  Sleep ( 10000 ) ;
  raise Exception.Create ( 'Internal error' ) ;
end ;

и на этом основании рассказывать, что ваша разлюбезная Каша только и делает, что тормозит и глючит.
21 ноя 06, 11:41    [3428492]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
mumps-ист
MX -- ALEX
Продаем готовый коробочный продукт для средних-мелких фирм
покупателю вообще до п..ды - сделан он на MUMPSe или на SQL-педерастии
если "оно-в-коробке" работает лучше других - значит берет и платит
патаму чта ане умеют считать бабки - и пока довольны.
пока - нет резона
MUMPS-лучше


ALEX, несколько выпросов к Вам: ваша система подерживает уровень изоляции транзакций serializable (это когда одна транзакция не видит изменения сделанные другой)?
Если да, то если не секрет какую стратегию блокировок вы используете и сколько по времени заняла реалиация данного механизма?

Мой опыт общения с Cache показал, что когда начинается честная реализация ACID (как например, объекты в Cache) - то скорость вставки падает на порядок (сравнивал запись простой структуры через прямой и объектный доступ). Чтение не тестировал, но читал, что SQL тоже хороших результатов не дает (там может и оптимизатор просто слабый).


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

пока проблем не было -
все случаи сбоев (не более 4-х) за последние годы на сотне обьектов
разруливались нашим спец журналом - даже без общесистемного

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

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

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

обьекты и m-SQL - не используем - только классический стандартный MUMPS -
для поддержания совместимости между CACHE-MSM-M3lite-GT.M
и для высокой скорости отработки запросов

весь интерфейс - через EXCEL :
на m-сервере - виртуальный многооконный многопользовательский
EXCEL на MUMPSe - в котором все и происходит - и синхронно
отображается на реальные интерактивные EXCELи у пользователей

взаимодействие с сервером может проходить
и в пакетном режиме - сразу вся таблица из EXCEL одномоментно
посылается на сервер - например вся приходная накладная с
очень большой спецификацией ( но контроль при вводе всегда
интерактивный - по каждому полю )

система разрабатывалась без EXCEL - 10 лет
и последние 5-6 лет - с EXCELem
21 ноя 06, 11:45    [3428530]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
SergSuper
[Ну хоть напишите мне что можно такого хорошего сделать, чего я не смогу сделать с помощью таблицы из двух поле?


Запихать-то в два поля можно, вопрос что дальше? С таким же успехом я запихаю все Ваши таблицы в одно дерево и что?

Вот Вам пример.

Входные данные - xml-документы с глубиной скажем 5-6 уровней элементов, объемом примерно 100-150 Kb

Требуется имея Вашу таблицы из двух полей
1) загрузить эти документы
2) осуществлять выборки/изменения и удаления заданных атрибутов/элементов
3) делать стат.отчеты по загруженным документам по заданной структуре элементов и атрибутов

Предполагается то Вы будете делать это на стандартных средствах РСУБД, т.е. реализованных во всех РСУБД.

Как будете решать задачу?

P.S. это ж надо так до абсурда из двух полей скатиться :(
21 ноя 06, 11:46    [3428541]     Ответить | Цитировать Сообщить модератору
 Re: 12 правил "ну я" для форума SQL.RU  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ну я
12 правил "ну я" для форума SQL.RU:

1) Кто-нибудь что-нибудь пишет.
...
12.5) В конце концов, ни одна документация не является полной.


К чему это ? А, ну ладно ...
Вам как человеку не запятнавшего себя публичным высказыванием глупостей, вопрос:

Как можно на Cache организовать Хэш-таблицу (с константным временем доступа разумеется) ?

Спасибо
21 ноя 06, 11:54    [3428619]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Rus000
P.S. это ж надо так до абсурда из двух полей скатиться :(


И теперь я знаю, что имя этому абсурду - М
21 ноя 06, 12:04    [3428701]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Rus000
Требуется имея Вашу таблицы из двух полей
1) загрузить эти документы
2) осуществлять выборки/изменения и удаления заданных атрибутов/элементов
3) делать стат.отчеты по загруженным документам по заданной структуре элементов и атрибутов

1. Вобще-то разбор файла XML - всяко не задача СУБД. Хотя и не сложная
2,3. Никаких трудностей не вижу. Давайте примеры

Rus000

P.S. это ж надо так до абсурда из двух полей скатиться :(

абсурд - это думать что иерархия не может быть представлена таблицой из двух полей
21 ноя 06, 12:05    [3428719]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
softwarer
Странно, что Вы решаете уникальные задачи на невиданное быстродействие

Не стоит упирать на то, чего я не говорил. Это про невиданное быстродействие.
По меньшей мере некрасиво с Вашей стороны.

softwarer

Есть некий интерфейс доступа к данным, например популярный в различных средах map <key, value> - то есть набор пар, в которых ключ (key) уникален и позволяет более-менее эффективно получить значение (value). Этот интерфейс может скрывать под собой разные реализации с разными характеристиками. Скажем, реализация на основе сбалансированных деревьев обеспечивает логарифмическое время выборки (как среднее, так и максимальное). Реализация хэшем обеспечивает константное лучшее время выборки при линейном худшем.

Ну что ж, давайте посмотрим, что же я делаю не так. Согласен, вариант ^index(hash, id)
не позволяет получить константного времени доступа. Я просто Вас неверно понял, поскольку
сам использую такой вариант для форсированного изменения сортировки индексов. Тоже hash
своего рода. За это sorry, конечно.

Ну а что насчет варианта 2, который на строке? Тоже не то? Ну тогда я плюну на B-tree, займу
блоков у системы и, пользуясь возможностями прямого доступа к блокам БД, сам построю то,
что мне нужно. Правда, не понимаю зачем.
21 ноя 06, 12:52    [3429127]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
В M нет "встроенного алгоритма поиска", а есть прямое обращение к узлу дерева.
Как мы тут выяснили всё-таки есть - функция $order. Учите матчасть :-) Шутка.
Это вот это ^a(1,2,3) Вы называете прямым обращением? Тут у Ptn вон $order байт-машина за одну инструкцию выполняет.
И вообще, Ваше "прямое обращение к узлу дерева" суть поиск по ключу в B*-дереве. Не говорите больше про "прямое обращение", т.к. нет в М никаких прямых обращений (ну конечно когда уже мы в дерево спустились, только не в узел, а в лист, тогда уж перебор прямой идёт). Прямым обращением можно назвать только доступ по ROWID к записи таблицы.

Sergei Obrastsov

Но эквивалентный индекс будет всё равно один!!!

Это очень здорово, что Вы так уверены!
Нейл Паппалардо видимо был уверен не меньше меня :-)
Я думаю, что пора прекратить споры и приступить к испытательной оценке полученных структур. Согласны?
Да, пожалуйста :-) Испытывайте. Только зачем, непонятно...
21 ноя 06, 13:02    [3429221]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp
Прямым обращением можно назвать только доступ по ROWID к записи таблицы.
В ROWID входит номер блока и смещение внутри него? Если так, то конечно. А если нет?

pavelvp

Да, пожалуйста :-) Испытывайте. Только зачем, непонятно...
Запросто. Я просто надеялся, что Вы загоритесь желанием доказать несостоятельность Cache.
Но Вы, конечно, все знаете заранее и без тестирования.
21 ноя 06, 13:11    [3429311]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
pavelvp
Прямым обращением можно назвать только доступ по ROWID к записи таблицы.
В ROWID входит номер блока и смещение внутри него? Если так, то конечно. А если нет?


Так и кое что сверх того, например номер файла, номер партиции ...
именно поэтому его нельзя считать номером записи. Это физический адрес записи (в Oracle во всяком случае)
21 ноя 06, 13:14    [3429335]     Ответить | Цитировать Сообщить модератору
 Re: 12 правил "ну я" для форума SQL.RU  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Gluk (Kazan)

Как можно на Cache организовать Хэш-таблицу (с константным временем доступа разумеется) ?


Сейчас нельзя. Возможно ISC когда-нибудь решит что это нужно сделать

Однако можете Вы напомнить при каких значениях N константное время поиска будет меньше времени поиска в сбалансированном дереве? Думаю здеь дела обстоят также как и про вырожденные случаи с фуллсканом, обсужденным выше.
21 ноя 06, 13:15    [3429345]     Ответить | Цитировать Сообщить модератору
 Re: 12 правил "ну я" для форума SQL.RU  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
ну я
12 правил "ну я" для форума SQL.RU:


маладца! многое подметил веро :)
21 ноя 06, 13:15    [3429355]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Вопрос к специалистам по Каше.

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

И еще скажите мне, уважаемые знатоки М-систем: в ссылках, которые в Каше так быстро работают(за счет, конечно, прямого доступа по адресу), какой адрес храниться - области памяти или области на диске?

Таки хочу понять, почему же оно быстрее получается (если получается вообще).
21 ноя 06, 13:19    [3429388]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Gluk (Kazan)
Rus000
P.S. это ж надо так до абсурда из двух полей скатиться :(


И теперь я знаю, что имя этому абсурду - М


можно поинтересоваться почему?

Тут в соседней ветке обсуждалось решение на M стоимостью в $4B ... думаете за абсурд будут столько платить?
21 ноя 06, 13:21    [3429406]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 38 39 40 41 42 [43] 44 45 46 47 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить