Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Новости Cache' сюда пожалуйста!  [new]
MX-ALEX
Member

Откуда:
Сообщений: 104
KostyaNext
[quot Andrew_256]2tygra:

В частности, была реальная БД по регистрации состояний устройств, (устройство, имя,значение). Причем данные не удалялись а непрерывно росли. Если в начале эксплуатации удавалось записать до 100 состояний в секунду, то через месяц, когда количество обьектов (записей) выросло до неск. сот тысяч, удавалось вставлять максимум 5 состояний в секунда, и это при почти 100% загрузке дисковой подсистемы и CPU!

не отходя от компьютора прямо сейчас прогоняю тест на cache
- вставка в глобаль миллиона записей со случайным индексом и значениями
k ^test
f x=1:1:1000000 s ^test(x,1)=1
f x=1:1:1000000 s dev=$r(99),name=$r(99),q=$r(99),^test(dev,name)=q
..................
весь тест прошел за 10 секунд
то есть 100 000 за секунду
Как Вам удалось делать 5 штук за секунду ??
15 мар 05, 13:15    [1386440]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
KostyaNext

Ну ты сказочник, Андрюшка. Я тоже много тестировал MSSQL и Cache. Так вот, практически нет операций, на которых Cache был бы быстрее. Да, работать с обьектами иногда удобнее, но скорость - ужасно.


Лично мне странно, что производители Cache позиционируют ее для работы с объектами. Само внутреннее устройство этой СУБД не может обеспечить быструю работу с объектами (впрочем, в сравнении с РСУБД+ORM оно выглядит вполне пристойно). Для быстрой работы с объектами нужно использовать настоящие объектные СУБД (Versant).
15 мар 05, 14:23    [1386811]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
MX-ALEX
Member

Откуда:
Сообщений: 104
Alexey Rovdo
KostyaNext

Ну ты сказочник, Андрюшка. Я тоже много тестировал MSSQL и Cache. Так вот, практически нет операций, на которых Cache был бы быстрее. Да, работать с обьектами иногда удобнее, но скорость - ужасно.


Лично мне странно, что производители Cache позиционируют ее для работы с объектами. Само внутреннее устройство этой СУБД не может обеспечить быструю работу с объектами (впрочем, в сравнении с РСУБД+ORM оно выглядит вполне пристойно). Для быстрой работы с объектами нужно использовать настоящие объектные СУБД (Versant).

вот именно !
а без обьектов - летает !
или им надо серьезно занятся ядром под обьекты
( не исключаю что это уже делается )
15 мар 05, 14:49    [1386958]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Alexey Rovdo
Лично мне странно, что производители Cache позиционируют ее для работы с объектами. Само внутреннее устройство этой СУБД не может обеспечить быструю работу с объектами (впрочем, в сравнении с РСУБД+ORM оно выглядит вполне пристойно). Для быстрой работы с объектами нужно использовать настоящие объектные СУБД (Versant).

Лично мне странна Ваша уверенность что существует СУБД, которая может работать с объектами. Все СУБД работают с данными. А объекты - это видимость этих данных с некоторой точки зрения. В файле хранятся байты. Хранить их наиболее оптимально с точки зрения доступа в дереве. При подъеме данных в оперативную память с помощью языка поддерживающего классы мы можем увидеть эти данные в виде объектов. Каше как СУБД работает с данными. Та часть Каше которая интерпретатор поддерживает объектный синтаксис с весьма развитыми возможностями и мы можем увидеть данные в виде объектов.
15 мар 05, 15:04    [1387040]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ну я

Все СУБД работают с данными. А объекты - это видимость этих данных с некоторой точки зрения. В файле хранятся байты. Хранить их наиболее оптимально с точки зрения доступа в дереве. При подъеме данных в оперативную память с помощью языка поддерживающего классы мы можем увидеть эти данные в виде объектов. Каше как СУБД работает с данными. Та часть Каше которая интерпретатор поддерживает объектный синтаксис с весьма развитыми возможностями и мы можем увидеть данные в виде объектов.


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

Основные отличия истинно объектных СУБД от всех прочих лежат именно в том, как они складывают объектные данные в хранилище, как формируют и поддерживают целостность межобъектных ссылок и навигации по ним, а также в механизмах кэширования объектных данных. Сами же программные интерфейсы доступа к объектам могут быть совершенно идентичными в системах самого разного класса.
15 мар 05, 15:37    [1387262]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 ну я

>>Хранить их наиболее оптимально с точки зрения доступа в дереве.

Это вы сами так решили ?

Тогда надо бы обосновать.

С точки зрения доступа, например ко всем данным - дерево НИКОГДА не оптимальнее, скажем списка т.к. в дереве нужен какой-никакой алгоритм обхода.

и т.п.
15 мар 05, 17:15    [1387845]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Мимо пробегал....
Guest
автор
Вы и правы и не правы. Биты и байты тоже можно назвать лишь абстракцией и перейти на уровень магнитных полей и электрических сигналов


Биты и байты - это нифига не абстракция а, наоборот, очень даже .... конкреция , реализуемая железом. Поэтому разные системы и сравнивают на близком по уровню или, лучше, одинаковом железе, что там биты и байты одинаковые. А в остальном - согласен.
15 мар 05, 18:04    [1388053]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Andreww
2 ну я

>>Хранить их наиболее оптимально с точки зрения доступа в дереве.

Это вы сами так решили ?

Тогда надо бы обосновать.

С точки зрения доступа, например ко всем данным - дерево НИКОГДА не оптимальнее, скажем списка т.к. в дереве нужен какой-никакой алгоритм обхода.

и т.п.

Да, можно привести пример когда дерево менее эффективно, не буду спорить. Есть задачи когда массив предпочтительнее.
15 мар 05, 22:49    [1388550]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
MX-ALEX
Member

Откуда:
Сообщений: 104
Andreww
2 ну я
С точки зрения доступа, например ко всем данным - дерево НИКОГДА не оптимальнее, скажем списка т.к. в дереве нужен какой-никакой алгоритм обхода.
и т.п.

согласен - но практически разница может быть сведена к нулю
например в CACHE/MSM есть функция выбора следующего узла дерева
$q() которая перебирает ВСЕ узлы слева направо независимо
от уровня ветви

пример: командная строка
s z="^tree" f s z=$q(@z) q:'$l(z) w !,z," ",@z
распечатает ВСЕ дерево без остатка и мигом

этот алгоритм обхода думаю не сложный и не времязатратный
16 мар 05, 14:11    [1390634]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Наверное все-таки правильнее упомянуть и определенных ограничениях такого механизма (а они наверняка существуют). Например, пока совершенно не очевидно, что мы можем осуществлять кластеризацию элементов дерева по произвольному критерию с такой же легкостью, как это доступно при традиционном способе хранения списков. Что, впрочем, вовсе не перечеркивает преимущества дерева в других ситуациях.
16 мар 05, 14:54    [1390840]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
>>s z="^tree" f s z=$q(@z) q:'$l(z) w !,z," ",@z этот алгоритм обхода думаю не сложный и не времязатратный

Издеваетесь ?

Может расскажете что это за алгоритм, а то s z="^tree" f s z=$q(@z) q:'$l(z) w !,z," ",@z как то не очень понятно:) ?

Кроме того в случае полного обхода дерева алгоритм ВСЕГДА НУЖЕН, в случае списка НЕ НУЖЕН, в случае массива ТОЖЕ НЕ НУЖЕН.
16 мар 05, 15:02    [1390875]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Andreww
Издеваетесь ?

Может расскажете что это за алгоритм, а то s z="^tree" f s z=$q(@z) q:'$l(z) w !,z," ",@z как то не очень понятно:) ?

Да с какого перепугу надо издеваться? Язык такой.
Запросы на sql в три-десять экранов - гораздо большее издевательство.

Даю расшифровку
s z="^tree" - записать в переменную с именем z значение "^tree" (set)
f - цикл (for)
s z= - в цикле записывать в переменную z
@z - косвенность, взять из строки z значение и рассматривать его как имя
$q - взять следующее имя в дереве относительно имени которое было в переменной z (query), возвращает строку со следующим именем
$l(z) - взять длину в байтах
' - отрицание - если ноль вернуть 1 иначе ноль
q: - прервать если не ноль (quit), выходит из цикла если длина z ноль
w - записать в текущий девайс (write)
! - перевод строки
z - пойдет значение строки z
@z - пойдет значение узла имя которого в переменной z

Для мампсистов нормальный стандартный мампс читается с полпинка. Как и в других языках, в нем также есть свои идиомы.
16 мар 05, 15:57    [1391213]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
MX-ALEX
Member

Откуда:
Сообщений: 104
ну я
Andreww
Издеваетесь ?

Может расскажете что это за алгоритм, а то s z="^tree" f s z=$q(@z) q:'$l(z) w !,z," ",@z как то не очень понятно:) ?

Да с какого перепугу надо издеваться? Язык такой.
Запросы на sql в три-десять экранов - гораздо большее издевательство.

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

спасибо за пояснения
кто знает MUMPS тому все ясно
а для других не менее уважаемых коллег я хотел всего лишь
показать что язык такой же компактный как PHP
и не переутомлять азбукой
хотя изучение MUMPS как второго - третьего языка проходит за час
(перерыв на пиво и обед в том числе)
пояснение к этой командной строке - уже 10% объема Курса MUMPS
16 мар 05, 16:58    [1391588]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 ну я

>>Да с какого перепугу надо издеваться? Язык такой.
>>Запросы на sql в три-десять экранов - гораздо большее издевательство

именно издеваетесь :)

Читать эти козявки невозможно. Сокрашение нормальных операторов до одной буквы АБСОЛЮТНО ничего не даёт в плане скорости выполнения, зато серьёзно затрудняет чтение. При помощи какого-нибудь препроцессора так исковеркать можно любой язык, только какой смысл - непонятно.

Пояснения это уже изощрённое издевательство :

"взять следующее имя в дереве" - в дереве нет "имён", есть только пары вида Ключ-Значение и вершины(узлы).
"w - записать в текущий девайс (write)" Что за "девайс" ? Надеюсь не на ленту ? Хорошенкий был-бы алгоритм обхода :)
" перевод строки" А он тут каким боком ?
"@z - пойдет значение узла имя которого в переменной z" Помогите ! Спасите ! Узлы (ага ! они таки есть !) пойдут.

Вообщем-то никто не просил вырисовыать козявочек, у нас для этого коллега ЧАЛ имеется. Просто хотел уяснить (без издевательств и ерничанья), как например тут - http://algolist.manual.ru/ds/walk.php каким алгоритмом дерево обходится. В ответ получил "запись в девайс" и "перевод строки"
16 мар 05, 17:16    [1391679]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мне кажется это какая-то болезнь всех Кашистов - путать людей непонятными терминами (узлы, глобали и т.п.). Причем все время пытаются создать впечатление, что за этим стоит невиданная по совершенству технология. Прямо скажем такой подход несколько смущает - если не сказать сильнее. Одно из двух - либо люди, работающие с Cache, просто настолько быстро привыкают к тому, чтобы манипулировать этими "глобалями" и "узлами" в своей речи, что просто забывают о неизвестности и непонятности этих терминов собеседникам, либо (что кажется более вероятным) пытаются скрыть за этой завесой некоторые отрицательные стороны технологий Cache (которые, как я уже отмечал выше, всегда есть у любой технологии).
16 мар 05, 17:42    [1391835]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Господа, когда разговор начинает утомлять, остается сказать только одно - учите матчасть.
В конце концов, когда мампсистам по роду деятельности приходится сталкиваться с реализациями sql, мы тоже берем и учим матчасть. Это относится к любому языку - не знаем языка - учим матчасть.
16 мар 05, 18:00    [1391958]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 ну я

Да вас никто не просил программу на каком-то языке приводить.

Просили внятно описать АЛГОРИТМ ОБХОДА ДЕРЕВА для которого разница между обходом списка и массива "практически может быть сведена к нулю".

Попросили просто обосновать.

В качестве обоснования повесили соплю s z="^tree" f s z=$q(@z) q:'$l(z) w !,z," ",@z

И дополнили "обяснением" про "запись в девайс" и "перевод строки".

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

Подозрения, похоже справедливы раз вместо ОПИСАНИЯ АЛГОРИТМА советуют выучить какой-то малоизвестный язык программирования.
16 мар 05, 18:17    [1392046]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Andreww
АЛГОРИТМ ОБХОДА ДЕРЕВА для которого разница между обходом списка и массива "практически может быть сведена к нулю".
Попросили просто обосновать.

Мампс оперирует деревьями, которые хранятся в файлах. Файл - это последовательность байт. Для эффективности кеширования файл делится на блоки. В каждом блоке файла хранится несколько ключей узлов и / или значений этих узлов. В каждой реализации мампса формат немного свой, но принципы примерно такие же. При вставке узла он вставляется всегда в сортированном виде. При необходимости блок расщепляется. Те же принципы используют и sql реализации при хранении индексов деревянного вида (классический вариант). При последовательном проходе по ключам, а это то что выполнял в предыдущем примере проход в цикле с итерацией по $query, выполняет практически линейный проход внутри одного блока. Практически - означает не в точности, поскольку блоки могут быть расщеплены и при проходе может произойти переход к другому блоку. Вероятность того, что два соседних (в порядке сортировки) ключа лежат в одном блоке достаточно высокая чтобы сделать суждение о практической эквивалентности такого прохода по дереву и прохода по эквивалентному ему массиву.

Andreww
какой-то малоизвестный язык программирования.

Это кому как малоизвестно, тут дело лично Ваше.
16 мар 05, 19:19    [1392239]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Alexey Rovdo
Причем все время пытаются создать впечатление, что за этим стоит невиданная по совершенству технология.

;-)
Сначала был мампс, потом появились sql и прочие абстракции. Если внимательно вчитаться например в стандарты sql, то можно обнаружить много интересного про поддержку мампса в sql.
типа тынц
Это не невиданная технология, это основа баз данных. Эффективные СУБД появились когда обкатали хранение деревьев в файле. Потом поверх этого каждый производитель накручивал что-то свое. Чтобы пробиться на рынок серьезных инсталляций, толкается реклама что типа автоматический оптимизатор решает все проблемы и вашим сервером данных может управлять любая обезьяна, все легко и просто и с помощью визуальных средств и строгая типизация не даст ей ошибиться и прочая мутота. Вот эта реклама видимо и создает впечатление что мампс - это невиданная технология. Сомневаюсь чтобы тот же к примеру Microsoft в своих декларациях о поддержке стандартов sql хоть бы отдаленно упомянул слово mumps. А это часть стандарта тем не менее. Может быть вам стоит переиначить свой вопрос?
16 мар 05, 19:32    [1392270]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Недоучка
Guest
ну я
Alexey Rovdo
Причем все время пытаются создать впечатление, что за этим стоит невиданная по совершенству технология.

;-)
Сначала был мампс, потом появились sql и прочие абстракции. Если внимательно вчитаться например в стандарты sql, то можно обнаружить много интересного про поддержку мампса в sql.
типа тынц
.....
.....
А это часть стандарта тем не менее. .....


Вы сейчас договоритесь до того, что Fortran - часть стандарта SQL...
16 мар 05, 19:46    [1392307]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
MX-ALEX
Member

Откуда:
Сообщений: 104
Andreww
2 ну я

Да вас никто не просил программу на каком-то языке приводить.

Просили внятно описать АЛГОРИТМ ОБХОДА ДЕРЕВА для которого разница между обходом списка и массива "практически может быть сведена к нулю".

Попросили просто обосновать.

В качестве обоснования повесили соплю s z="^tree" f s z=$q(@z) q:'$l(z) w !,z," ",@z

И дополнили "обяснением" про "запись в девайс" и "перевод строки".

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

Подозрения, похоже справедливы раз вместо ОПИСАНИЯ АЛГОРИТМА советуют выучить какой-то малоизвестный язык программирования.

мы гоняем на MUMPS сотни задач на разных предприятиях
более десяти лет
понятный язык, хорошая база - что еще надо ?
не нравится - никто ж не заставляет
чего обижаться ?
обосновать лучше смогут в InterSystems
мы практики - для нас программа - лучшее "ОПИСАНИЕ АЛГОРИТМА"
а что работает быстро и легко сопровождается - подтверждаю
17 мар 05, 09:40    [1392943]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 ну я.

>>Мампс оперирует деревьями, которые хранятся в файлах. Файл - это последовательность байт.

Т.е. с rawdevice MUMPS не работает ? :)

>>Для эффективности кеширования файл делится на блоки.

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

>>В каждом блоке файла хранится несколько ключей узлов и / или значений этих узлов.

По другому и быть не может - кроме как в блоке, хранить негде (см. выше).

>>При вставке узла он вставляется всегда в сортированном виде.

Поясните что такое "сортированный вид узла" ?

>>При необходимости блок расщепляется.

В общем в голове восхитительная каша. И при этом хватает смелости делать заявления типа - "... учите матчасть ...".
Так вот, для того что бы дерево именовалась Б-деревом должны выполняться следующие условия :

1. Должен быть определён "корневой блок"
2. В каждом блоке должен находится список ключей К1...Кn такие что K1<=K2<=K3...<=Kn
3. Каждый блок должен содержать признак того является он листом или нет (это необязательно)
4. В каждом блоке, если он не лист, должен находится список ссылок на "дочерние" блоки C1(К1),C2(К2)...Cn(Кn)

Если интересует более детальное описание, откройте Кормена или Кнута, там есть :)

Пока же :

1. Так вот у вас просто "В каждом блоке файла хранится несколько ключей узлов" это раз.
Вы забыли указать, что в каждом блоке ещё и храниться список указателей на "дочерние" блоки.

2. Непонятен случай как быть в случае нескольких блоков ведь "При необходимости блок расщепляется" - в каждом блоке есть ссылка на другой блок или как ?


>>Те же принципы используют и sql реализации при хранении индексов деревянного вида (классический вариант).

Нет не те же. Вы кое-что пропустили.


>>При последовательном проходе по ключам, а это то что выполнял в предыдущем примере проход в цикле с итерацией по $query, выполняет практически линейный проход внутри одного блока.
Вот первый блок закончился и ... что будет если файл занимает несколько блоков ?

>>Практически - означает не в точности, поскольку блоки могут быть расщеплены и при проходе может произойти переход к другому блоку.
КАК ??? ОТКУДА МЫ УЗНАЁМ АДРЕС(СМЕЩЕНИЕ) СЛЕДУЮЩЕГО БЛОКА ?
В каждом блоке хранится адрес следующего блока или ... как ?


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

Так вот, насколько я смог понять из сбивчивого объяснения и закорючек в которых есть Цикл и Порядок обхода с получением адреса след блока в вашем случае
всё хранится в виде СВЯЗАННОГО СПИСКА. Внутри этого списка есть нек. структуры в виде B*-дерева. (Как всё это согласовывать в многопользовательской среде ?)
Поэтому и сравнивая обход СПИСКА с обходом СПИСКА мы получаем одинаковый результат (удивительно правда).

Всё почти как в современных РСУБД, только там можно хранить B*-дерево отдельно (в виде индекса) а можно хранить Дерево и данные вместе.

У всего есть свои плюсы и минусы :

Раздельное хранение :
+ Индекс можно отключить перед массовой операцией обновления\удаления
+ Может существовать несколько индексов и использоваться будут только необходимые
+ Индекс можно изменять паралелльно со обновлением данных (допуская дисбаланс)
- Накладные расходы при работе с разными объектами (данными и индексами)

Хранение данных и дерева вместе :
+ Нет накладных расходов на отдельное чтение индекса и данных
- Данные всегда должны быть представленные в виде Key-Value
- Массовые операции обновления\удаления всегда будут приводить к расходам на балансировку дерева

Решать разработчику как хранить (в случае соврем. РСУБД), в случае КАШЕ - выбора НЕТ.

Вот и получаем при попытке массовой вставке :

"В частности, была реальная БД по регистрации состояний устройств, (устройство, имя,значение). Причем данные не удалялись а непрерывно росли. Если в начале эксплуатации удавалось записать до 100 состояний в секунду, то через месяц, когда количество обьектов (записей) выросло до неск. сот тысяч, удавалось вставлять максимум 5 состояний в секунда, и это при почти 100% загрузке дисковой подсистемы и CPU!"

Система только и занимается тем , что дерево балансирует.
17 мар 05, 17:02    [1395330]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Предыдущий пост многое проясняет в отношении Cache и если высказанные там догатки верны, то можно сделать и некоторые выводы о целесобразности применения Cache в определенных задачах, а именно (все в значении "вероято", поскольку требует комментариев от знатоков Cache):

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

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

3. Система не ориентирована на обработку сетевых структур и прямую навигацию.

Учитывая сказанное применение системы может оказаться оправданным в задачах. которые не предполагают интенсивного обновления и ввода данных, но требуют построения сложной аналитики и/или обслуживания большого количества запросов на чтение (как мне кажется, это могут быть складские программы, бухгалтерия, CRM и т.п.).
17 мар 05, 17:22    [1395387]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
Недоучка
Guest
Andreww: "Если интересует более детальное описание, откройте Кормена или Кнута, там есть :)"

Не - лучше Вирта, у него с картинками.... :-)
17 мар 05, 17:59    [1395546]     Ответить | Цитировать Сообщить модератору
 Re: Новости Cache' сюда пожалуйста!  [new]
MX-ALEX
Member

Откуда:
Сообщений: 104
Alexey Rovdo
Предыдущий пост многое проясняет в отношении Cache и если высказанные там догатки верны, то можно сделать и некоторые выводы о целесобразности применения Cache в определенных задачах, а именно (все в значении "вероято", поскольку требует комментариев от знатоков Cache):

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

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

3. Система не ориентирована на обработку сетевых структур и прямую навигацию.

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

1) да не тормозит !
не отходя от компьютора прямо сейчас прогоняю тест на cache
- вставка в глобаль миллиона записей со случайным индексом и значениями
k ^test
f x=1:1:1000000 s ^test(x,1)=1
f x=1:1:1000000 s dev=$r(99),name=$r(99),q=$r(99),^test(dev,name)=q
..................
весь тест прошел за 10 секунд
то есть 100 000 за секунду
2)
3) прямая навигация - именно преимущество MUMPS !
можно напрямую обращаться по ключу - по части ключа - к узлу
- к следующей записи - к предыдущей - все что придумаете
для этого есть функции навигации

(некоторые вопросы этой дискуссии можно прояснить из приложения)

К сообщению приложен файл (m.txt - 11Kb) cкачать
18 мар 05, 09:45    [1396507]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить