Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 24   вперед  Ctrl
 Re: СУБД CACHE'  [new]
Garya
Member

Откуда: Москва
Сообщений: 33188
Блог
Только что вернулся из Интерсистемс со свежими впечатлениями. С разными - как хорошими, так и не очень. Из хороших - одарили меня материалами и книжкой по Cache, что весьма приятно. Про переобпределение ID объекта и системый клас GUID мне в Интерсистемс тоже что-то говорили, но я пока не совсем понял. Из тех материалов, которыя я пока успел изучить, я понял (не знаю, правильно ли), что обращение к объекту по ObjectID - самая высокопроизводительная операция, поскольку при этом НЕ задействуются механизмы поиска, а производится прямое обращение к объекту. У меня подозрения, что переопределение ObjectID де-факто сведется к добавлению еще одного поля и к замене прямого обращения на операцию поиска по Custom-полю, которое "видится" идентификатором объекта.

У меня возникло ощущение, что над проблемами репликации (конфликты, асинхронность, двусторонний обмен данными) разработчики Cache как-то особо не заморачивались. Я пока вообще не понял, существуют ли в Cache вообще штатные средства репликации. Если существуют (почему-то пока мне на глаза не попались :) ), то как они могут работать на ПЕРЕОПРЕДЕЛЕННЫХ идентификаторах объектов? Возможно, мои опасения и не оправдаются. Но в MS SQL Server 7.0 и 2000 четыре разных вида репликации (Merge, репликация транзакций, непосредственно обновляемые подписчики и репликация снимком). О репликации в Cache мне пока лишь сообщили, что репликация ВОЗМОЖНА. Правда, не уточнили, какого вида. Придется разбираться самому.

Немного меня разочаловала реализация Relationships между объектами. Либо это связь аналог связи один-ко-многим, но без каскадных операций (то есть жесткий констрейнт как в MS SQL 7.0 и более старых версий), либо это отношение между Parent и Child, которое может быть создано только между классами, один из которых унаследован от другого, и тогда это связь с касмкадными операциями. То есть, каскадные операции реализуются ТОЛЬКО в древовидной структуре связей. При построении графа связей между объектами НЕ в древовидном виде реализовывать ссылочную целостность с каскадными операциями придется врукопашную. Небольшая подлянка от СУБД, которая позиционирует себя как "постреляционная" в то время, когда в большинстве "обчных реляционных" СУБД атрибуты каскадности на relationships давно стали привычным явлением.

Какие-то непонятки мне рассказали про поддержку транзакций. Если я правильно понял, транзакции работают не всегда, а только тогда, когда они явно объявлены. Под транзакцией подразумевается лишь последовательность операций, которую можно откатить - и всё (!?). Об уровнях изоляции транзакций речи вообще не идет. На вопрос, выполняется ли операция модификации/удаления/добавления при работе через ODBC в рамках неявной транзакции, точно ответить не смогли. Я обязательно попытаюсь найти ответ на этот вопрос. Пока же мы успели сразу после моего возвращения провести небольшой эксперимент по выявлению установленного в Cache уровня изоляции транзакций. Для чего сделали тестовое Delpi-приложение, которое работает с данными Cache через связку OLEDB (OLE DB provider for ODBC driver) - ODBC. Управление транзакциями производили явно установкой свойств ADO.Connection. Это приложение запустили в нескольких экземлярах и посмотрели, как разные экземпляры этого приложения работают с одними и теми же данными. Выяснили, что уровень изоляции в Cache соответсвует Read Uncommited (то есть грязному чтению). Но "грязночитанные" данные блокируются и не update-ятся во второй сессии до тех пор, пока в первой сессии не будет выдан Rollback либо Commit. После выдачи Rollback либо Commit в первой сессии автоматом сразу отрабатывает операция второй сессии, приложение в которой до этого на некоторое время "подвесилось" - то есть операции попадают в очередь по факту начала транзакции, а не по факту ее закрепления - и в этом же порядке отрабатывают. Попытка выставить в свойствах Connection людой другой уровень изоляции транзакций ни к чему не приводит - поведение системы остается прежним. Пытались открыть транзакцию в одной сессии и, не закрыв ее срубить приложение - слава богу, Cache сама откатывала такую транзакцию и освобождала занятые ею ресурсы.

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

Самая большая непонятка для меня - это транзакции Cache. Если часть операций выполняется НЕ в транзакции, то при выполнении инструкции вроде
Update USER.TraliVali set F1=1, F2=2, F3=3,... F100=100
...сервер начнет писать груду информации непосредственно в базу данных, не задействуя журнал транзакций. Конечно, эта операция отработает в три раза быстрее, чем в MS SQL Server, который использует трехступенчатую последовательность записи (сначала в лог, потом из лога в базу, затем пометка в логе, что транзакция записалась успешно). Но если в это момент у компьютера выключить питание, то вполне может оказаться, что проапдейтилась только часть записей, а у некоторой запис проапдейтились только часть полей. К чему может привести такая поддержка транзакционности, наверное, дополнительно объяснять не нужно.

Возможно, я что-то не так понял. А может быть и правильно. Я попытаюсь разобраться во всем получше. Если узнаю что-то дополнительно, сообщу.
22 май 03, 15:53    [206938]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Garya
Member

Откуда: Москва
Сообщений: 33188
Блог
Пардо-пардон-пардон!!!
Сейчас еще раз провели серию экспериментов. Видимо, допустили какую-то плюху при проведении первого эксперимента. Разные уровни изоляции транзакций поддерживаются. Видимо, в прошлый раз забыли перекомпилировать приложение после переустановки уровня изоляции.
Вот сколько напраслины и какую большую тень навел на плетень!
Еще раз дико извиняюсь.
22 май 03, 16:09    [206973]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
2 Garya
Попробую ответить на несколько вопросов...
При переопределении Object ID, если все правильно сделать,
поиска не понадобится.
В каше есть теневые журналы и зеркалирование, причем можно журналировать
определенные глобалы.
О транзакциях:
как я уже говорил и приводил примеры, в каше есть встроенный язык M,
в нем запись в глобалы - операция атомарная и транзакция не нужна.
Если нужно оформить транзакцию, то, действительно, нужно
TSTART
S ^zavod(1)="Test"
S ^zavod(2)="Test 2"
TCOMMIT
В случае работы с объектами, транзакции запускаются автоматически...
С бэкапом все в порядке, тк журналируются действия (если я правильно
понял)...

Надеюсь, ответил на некоторые вопросы.
22 май 03, 16:33    [207027]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gold
Member

Откуда: Харьков
Сообщений: 2947
To Garya:
Круто! Такую телегу написать - достойно восхищения. Я пока прочитал - утомился!

Мне осталось не понятно следующее:
1. Кэш версионник или блокировочник?
2. Какие всё-же режимы изоляции поддерживаются
3. С бэкапами всё мутно как-то ... Действительно, в каком режиме запускается транзакция, выполняющая бэкап?
22 май 03, 17:04    [207111]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Garya
Member

Откуда: Москва
Сообщений: 33188
Блог
2 Gold.
1. Изоляция реализуется блокировками.
2. По крайней мере четыре базовых уровня точно поддерживаются. Подробнее нужно прогу мучить.
3. Пока сам не разобрался.

> ...запись в глобалы - операция атомарная и транзакция не нужна.

2 Maksim UM. Это смотря для чего. Если только для того, чтобы быть уверенным, что ВСЯ информация записалась в процессе этой одной операции, то да - не нужна. А вот в MS SQL есть такая "репликация транзакций" (реализуется сканированием репликационным агентом журнала транзакций). Так вот, если НЕ ВСЕ операции будут выполняться транзакционно, то подобной репликацией часть измененных данных не сможет отреплицироваться.
Можно, конечно, решить, что репликация транзакций - вещь экзотическая, и не особенно-то нужна. Но как быть с бэкапом, который выполняется во время интенсивной работы пользователей? В MS SQL фиксируется CheckPoint на момент начала архивирования и в архив заносится только та информация, которая попала в базу данных ДО начала бэкапирования. Потом рекурентно дописываются блоки из журнала транзакций, которые попали в БД уже после начала архивирования до тех пор, пока в бэкап не загонится ВСЯ информация. То есть, выполнить эту операцию так, чтобы гарантировано не нарушилась целостность информации в сархивированной БД без журнала транзакций невозможно. Требование выполнения даже атомарных операций в режиме неявно автоматически запускаемых транзакций становится обязательным. И именно так работает MS SQL Server. А как выполняет Backup Cache?
22 май 03, 17:34    [207183]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
По поводу бэкапа:
я насчитал 4 варианат.
1. Concurrent External Backup
2. Non-Concurrent External Backup
3. Concurrent Caché Backup
4. Cold Backup
Подробнее сейчас некогда писать, но все это есть
в стандартной комплектации док по Cache.
О транзакциях:
в каше кроме комманд для транзакции, есть еще
комманда блокировки. Так что - что хочу тои ворочу.
Можно получить любой тип.
Например:
TSTART
L +^zavod(1),^zavod(2)
S ^zavod(1)="Test"
S ^zavod(2)="Test 2"
TCOMMIT
L
в этом примере запись в транзакции блокируется...
По поводу отношений между объектами, они могут быть:
ONE MANY
MANY ONE
PARENT CHILDREN
CHILDREN PARENT
22 май 03, 18:12    [207263]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 Maksim UM
Насчет отделов и зарплаты. В приведённом примере как я понял не учитывается что отделы могут имет подотделы, которые в свою очередь могут иметь свои подотделы и т.д. Может я это не очень четко отразил, но вроде написал что глубина иерархии неизвестна.

Если не трудно объясните по рабоче-крестьянски что означает какой оператор в языке(.F, S, ..S и т.д.).

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

Или же это не характерная для кэш задача? А для каких задач тогда он больше подходит?
23 май 03, 09:22    [207561]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Garya
Member

Откуда: Москва
Сообщений: 33188
Блог
2 Maksim UM.
Все external бэкапы не гарантируют решения тех проблем, о которых я говорил выше (так мне сказали в Интерсистемс). Что же касается Cache backup - пока не успел разобраться.

Насчет relationships. Связь один-ко-многим и многие-к-одному - это связь одного типа. Возьми берданку и погляди в ствол со стороны патронника, а затем со стороны дульной части. От этого одна берданка не превратится в две берданки. То же самое относится и к "двум" типам связи Child-Parent и Paremt-Child.

S - это set
W - это write
F - это цикл for
Меня самого жутко нервирует эта возможность однобуквенной записи всех операторов COS (иже с ним MUMPS). Дурацкая семантика. Maksim UM, если ты действительно хочешь, чтобы тебя поняли те, кто не знаком с этой идиоматикой, пиши полной записью (как это сделано в ознакомительных статьях).
23 май 03, 10:17    [207633]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
На счет короткой записи, извиняюсь, укоренившаяся превычка :)
Хотя я писал примеры, только для того, чтобы показать как сильно отличается
встроенный язык от обычных представлений о БД.
Я, наверное, плохо объясняю, но SQL в Cache не сильно отличается от других
баз.
1. Для работы с SQL обязательно нужно создавать классы.
2. Классы записываются в глобалы.
3. С глобалами можно работать напрямую (в этом случае можно здорово
выиграть в скорости).
4. При работе с глобалами напрямую, можно реализовать сложные алгоритмы обработки данных. Это, как если бы, работать с ораклом напрямую в PL/SQL
и еще глубже...
5. Характерных задачь для Cache нет, можно реализовать почти все
(жарить семечки не умеет :)
6. У объектов можно легко менять функциональность.

S - запись переменной (она может быть локальной - в памяти, и
глобальной - в БД)
F - цикл (имеет уйму параметров), можно пройтись по любому уровню вложенности.
23 май 03, 10:31    [207664]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Garya
Member

Откуда: Москва
Сообщений: 33188
Блог
Для задавшего вопрос. Ответил в другом топике:
Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД
26 май 03, 12:38    [209846]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
nobodyman
Member

Откуда:
Сообщений: 39
Дурь несусветная, по моему мнению, это должно было умереть лет 15 назад.
Однако - сила инерции.
В основе дряни - многомерный индекс (самый обычный индекс с полями разделителями |- и все) нечто вроде Беркли ДБ , ни записей ни возможности строить дополнительные индексы- МАМПС одно слово.
Т.е. - ключь - значение.
Если Вас это удовлетворяет - флаг в руки , барабан ...
Все остальные навороты - от лукавого, зрить надо в корень.
28 май 03, 11:56    [212557]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Garya
Member

Откуда: Москва
Сообщений: 33188
Блог
Насколько я понял, так называемый "многомерный" доступ к данным (который меня совершенно не прельщает) - это только одна из возможностей. Есть еще две разновидности доступа (к тем же самым данным!) - реляционный и объектный. Наибольший интерес для меня представляет объектный.
29 май 03, 09:10    [214754]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Nodir
Guest
> nobodyman:
> В основе дряни - многомерный индекс (самый обычный индекс с полями
> разделителями |- и все) нечто вроде Беркли ДБ...

Как я понимаю, основной упор в MUMPS - скорость разработки/кодирования, но и про скорость работы самой системы все уши прожужжали.
Интересно, намного ли различаются скорости обновления/доступа/чтения в M-системах (из процедур на MUMPS) и того же Berkeley DB (из программ на Си)?
13 июн 03, 09:17    [229428]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
2 Nodir
>Интересно, намного ли различаются скорости обновления/доступа/чтения в
>M-системах (из процедур на MUMPS) и того же Berkeley DB (из программ на
>Си)?

Приблизительно такая же, если писать на чистом M(UMPS), с объектами
в Cache несколько медленнее (не во всех случаях). Многое зависит от написанного кода.
16 июн 03, 10:25    [230438]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
nobodyman
Member

Откуда:
Сообщений: 39
Как я понимаю, основной упор в MUMPS - скорость разработки/кодирования, но и про скорость работы самой системы все уши прожужжали.
Интересно, намного ли различаются скорости обновления/доступа/чтения в M-системах (из процедур на MUMPS) и того же Berkeley DB (из программ на Си)?

Работать с М - языком - полная ахинея - движения по индексу врерх - вниз , копирования деревьев - поддеревьев и т.д. - это самый нижний уровень манипуляции с данными. нтерфейса в М как такового нет , многие пишут свой - пример Гефест от Програмбанка ( под телнетом наваяна вполне приличная телетайпная библиотека - но, старо). Уровень М на беркли реализуется за пару дней работы , правда с надежностью , безглючностью продукта Б я бы поспорил, местами ведет себя странно, реальных продуктов на Б я не втречал
, сам написал http://www.new-vision.tk/" TARGET="_blank">http://www.new-vision.tk/ - УТК АФИНА с использованием Б.
Беркли работает довольно быстро, есть транзакции , но нужна особая специфика работы с продуктом , это ни на что не похоже.
С М опыта реального не имел, но читал книжки , смотрел на ... видел как Гефест от Програмбанка пытальсь ставить у нас на показ. 5 часов колочения диска - результат 0 - довольно странно для суперскоростной системы , а продукт их только М без транзахциев сикуэля и объектов - навевает на грустные мысли.
16 июн 03, 11:41    [230569]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
MUK
Guest
Дискуссия напоминает мне разговор двух глухих старух в очереди.
"Раньше селедка во была, а теперь во..."
"Эх, не говори... совсем мужики перевелись".
Если кучеру долго объяснять устройство паровоза, то в конце он обязательно спросит: "А куда лошадь запрягать?".
С тоской вспоминаю свою почти 20-летнию работу с M-технологией,
где основное достоинство было в том, что можно было с не слишком квалифицированной и многочисленной командой создать инструмент генерации приложений для определенного класса ИПС задач, быстро создавать прототипы и доводить их до ума на протяжении всего периода их существования. Основным недостатком создаваемых продуктов - была их чрезвычайная живучесть. Вытравливались они с огромным трудом и их пользователи всегда недоумевали, почему на новых на два порядка более мощных компьютерах всё еле ползает, бесконечно ломается, требует особой внимательности, хотя старые системы работали как холодильники, у которых есть только одна клавиша управления - включение/выключение.
Кстати, проблема копирования информации решалась симметричной репликацией данных во многоуровневой иерархии серверов. Такое было возможно, так как изначально вся база данных распределялась по серверам на части, где могли обрабатываться одновременно только разные записи. Транзакции отсутствовали вообще. Есть много задач, где от них больше вреда, чем пользы. Сейчас я мучаюсь с ORACLE, как DBA. От SQL я sick.
Когда наблюдаешь как отчет по 150 записям на 2-х процессорном монстре с 2 Гb RAM считается полчаса и выдающиеся разработчики этого чуда ничего толком не могут объяснить, хочется зарезать человечка. Когда читаешь в присылаемом мне на дом бесплатно журнале ORACLE, что для того, чтобы правильно прибить 500 индексов в схеме и не получить невразумительное сообщение, надо понимать, что в цикл нельзя вставлять команды типа DROP и COMMIT, а то не дай бог не хватит места для накопления отката, становится страшно. Меня тошнит не только от SQL, но и от всего этого программизма с этими "прогами", "фитчами" и прочей дребеденью.
Танцуют все! А задач-то с гулькин нос.
9 июл 03, 14:55    [255967]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Garya
Member

Откуда: Москва
Сообщений: 33188
Блог
2 SergSuper. Меня самого занимал ответ на твой вопрос. Теперь я узнал на него ответ. Встроенных агрегатных функций, которые "одним махом" получают итоги по поддереву (вроде агрегатных функций SQL вкупе с group by) - нет. На самом деле для работы с деревом требуется использовать самопальные циклы, перебирающие по порядку записи поддерева или одного уровня поддерева. Но СПЕЦИАЛЬНО для всех разновидностей подобной обработки имеются функции получения "следующей записи" разными способами. Одна функция получает следующую запись в дереве на том же урвне иерархии, что и текущая. Другая функция имеет возможность получать записи с разных уровней иерархии, используя (внутри себя, видимо) стандартный рекурсивный алгоритм раскраски дерева по правилу "сначала вглубь". Имеются также функции определения местонахождения в дереве "текущей" записи.
Если честно, то у меня (как и у тебя) была надежда на более интелектуальный языковый интерфейс :(... Забавно натыкаться постоянно в ПОСТреляционной СУБД на анахронизмы и, в частности, на довление к манипулированию данными на низком уровне. Хреновый уровень абстрагирования, заставляющий программиста думать не о решении главной задачи, а о том, как строить циклы и в каой последовательности что втыкать в их тело. Можно было бы ожидать большей прозорливости от специалистов, так много говорящих об ООП.
9 июл 03, 15:26    [256014]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Меня слово "ПОСТреляционная" веселит. ИМХО это тоже самое, что сказать "постлогическая" или "постматематическая". Что мы собс-но и наблюдаем :)
9 июл 03, 16:08    [256098]     Ответить | Цитировать Сообщить модератору
 СУБД CACHE'  [new]
Magika
Member

Откуда: Хабаровск
Сообщений: 1
Помогите!!! Возникла необходимость перебросить данные из DTM в Cache. Написала небольшой скрипт, но не умею пользоваться терминалом. Как запустить прогу. Без шуток - подскажите, пожалуйста...
4 июн 04, 03:23    [721297]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
2 Magika
Законнектись через телнет или терминал.
В нем выбери неймспейс где твоя рутинка
USER>zn "namespacename" тут жми Enter
Вызови рутинку
d EntryLabel^RouName(param1,param2) тут снова Enter
Точка входа - это то, что начинается с первого символа в строке.
Если параметров вообще нет, то
d EntryLabel^RouName() если в рутинке написано
EntryLabel()
или
d EntryLabel^RouName
если написано
EntryLabel

Не паникуй ;-)
4 июн 04, 11:13    [721822]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
2 Magika
Кстати, у Вас в Хабаровске есть под боком ребята
www.dimas.ru
www.zc.khv.ru
4 июн 04, 11:16    [721849]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Sergo Gromov
Member

Откуда: Lviv Ukraine
Сообщений: 56
Нашел в себе силы, прочитал 60% всего писаного !!!! УХ !!

кАроче говоря, я пытаюсь поюзать Кашу, причём не ради праздного любопытства - для выяснения возможности портировать (ещё одно прикольное слово от ИС) собственное ПО из MSM в Кашу.

Сам работаю в М более десятка лет и нахожу Кашу довольно сырым продуктом.

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

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

Это - полемика. Если Уважаемые не сочтут за труд и чиркнут мне малость по поводу моей беды - буду признателен !!!!!!!
20 июл 04, 13:36    [820545]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Sergo Gromov

Сам работаю в М более десятка лет и нахожу Кашу довольно сырым продуктом.

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

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

Не работал с кашей ни одного дня. Делаю выводы исходя из логики. Тема очень интересная. Нужно будет покапаться.

Паровоз Каши поехал в сторону программеров - Думаю вы правы. :)

тогда время, затраченое на генерацию результата падает в разы и ограничивается лишь скоростью чтения с винта - Согласен. Один из основных вопросов, связанных с быстродействием в том, как физически данные располагаются на плоской поверхности носителя ("в плоском" адресном пространстве)? Принцип работы битмап индексов?

Верю в компетентность разработчиков Oracle, MSSQL Почему они не используют аналогичные технологии для своих СУБД?
5 ноя 04, 13:13    [1086269]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Потому что их больше волнуют вопросы Safety IMHO
5 ноя 04, 13:24    [1086322]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Andrey K
Принцип работы битмап индексов?


велкам: http://karataev.nm.ru/ind/index.html

Andrey K
Верю в компетентность разработчиков Oracle, MSSQL Почему они не используют аналогичные технологии для своих СУБД?


Вспомнилось: академика Александрова одна журналистка в интервью подначивала на тему Чернобыля и спросила что-то вроде "Почему за рубежом не делают реакторы типа РБМК?", видимо намекая что это отсталая технология. Александров чуть дара речи не лишился и единственно что смог сказать: "Потому что не умеют".

В переводе на тему топика: mssql не имеет битовых индексов, а оракл не умеет с ними работать: сегмент индекса и блокируется и журналируется целиком, и тут сразу получим дидлоки и гигантические журналы (пардон, сегменты отката). Каше умеет откатывать и журналировать операции в один бит в сегменте. Все разговоры на тему "не используйте битмап индексы в транзакционной системе" вызваны именно этим нюансом, но никак не принципом их действия. Не буду скрывать - изучал битмап индексы в разных системах, и могу сказать что движок каше - единственный на сегодняшний момент который это делает правильно с точки зрения транзакционной системы. Никакого пиара, только техническое суждение.
5 ноя 04, 14:40    [1086704]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить