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

Откуда:
Сообщений: 673
Зл0й
Нужна вам СУБД - возьмите MySQL. Только не берите постргес, потому что он-тупиковая ветвь развития.
Что значит возьмите??? PostgreSQL можно взять, а MySQL просто так взять нельзя.
14 ноя 07, 10:20    [4913084]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Yo.!
Guest
pavelvp
Зл0й
Нужна вам СУБД - возьмите MySQL. Только не берите постргес, потому что он-тупиковая ветвь развития.
Что значит возьмите??? PostgreSQL можно взять, а MySQL просто так взять нельзя.

ну и кто мне может помешать взять GPL продукт ?
14 ноя 07, 12:29    [4914208]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Yo.!
ну и кто мне может помешать взять GPL продукт ?
То, что все изменения внесённые в данный продукт тоже будут GPL.
14 ноя 07, 13:16    [4914657]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Yo.!
Guest
pavelvp
Yo.!
ну и кто мне может помешать взять GPL продукт ?
То, что все изменения внесённые в данный продукт тоже будут GPL.

и чо ? ну будет развиваемая и Россией открытая GPL субд и закрытые приложения правительственных структ сверху над этой субд. не вижу проблемы, хотя имхо постгрес выглядит гораздо перспективней...
14 ноя 07, 13:39    [4914899]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Yo.!
pavelvp
Yo.!
ну и кто мне может помешать взять GPL продукт ?
То, что все изменения внесённые в данный продукт тоже будут GPL.

и чо ? ну будет развиваемая и Россией открытая GPL субд и закрытые приложения правительственных структ сверху над этой субд. не вижу проблемы, хотя имхо постгрес выглядит гораздо перспективней...


На мой взгляд постгрес бесперспективен в принципе. Ввиду кривой идеологии хранения версий в блоках, со сборкой мусора (vacuum) и прочими прелестями. По уму надо выкинуть всю эту ересь на фиг и сделать нормальный WAL и хранить в блоке только одну версию данных. Что собственно и сделано в Оракле, InnoDB/MySql. Но это означает что надо просто весь постгрес взять и переписать. А зачем такое счастье, когда есть InnoDB, пусть и недоделанная на данном этапе. Я вообще сторонник выкинуть из MySql нафиг все лишнее типа поддержки MyIsam и BerkeleyDB, и добиться более-менее нормальной работы того что останется. Задача явно разрешимая так как принципиальных косяков (на уровне идеологии) в связке MySQL-InnoDB нет. А фичи можно потом дописать, по мере необходимости. В постгресе всякие клевые фичи есть, но только вот ядро и идеология там кривые, и сделать с этим ничего нельзя - только взять и с нуля написать новый постгрес.
16 ноя 07, 03:05    [4923502]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Yo.!
Guest
Зл0й

На мой взгляд постгрес бесперспективен в принципе. Ввиду кривой идеологии хранения версий в блоках, со сборкой мусора (vacuum) и прочими прелестями. По уму надо выкинуть всю эту ересь на фиг и сделать нормальный WAL и хранить в блоке только одну версию данных. Что собственно и сделано в Оракле, InnoDB/MySql. Но это означает что надо просто весь постгрес взять и переписать. А зачем такое счастье, когда есть InnoDB, пусть и недоделанная на данном этапе. Я вообще сторонник выкинуть из MySql нафиг все лишнее типа поддержки MyIsam и BerkeleyDB, и добиться более-менее нормальной работы того что останется. Задача явно разрешимая так как принципиальных косяков (на уровне идеологии) в связке MySQL-InnoDB нет. А фичи можно потом дописать, по мере необходимости. В постгресе всякие клевые фичи есть, но только вот ядро и идеология там кривые, и сделать с этим ничего нельзя - только взять и с нуля написать новый постгрес.

Хм ... WAL в постре есть, вы походу UNDO имеете ввиду. и не понял вашей уверености в том, что переписать небольшую часть сторадж системы постгреса сложнее, чем довести до ума оптимизатор, язык хп, schema, partitioning и сотни других вещей которые на десятилетия отстают от постгре в mysql ?
16 ноя 07, 10:27    [4924118]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
автор
Возьмите Linux, ... возьмите MySQL, ... возьмите PostgreSQL...

основная мысль, проталкиваемая политиками перед выборами, состоит в том, что Россия должна иметь СВОЮ операционную систему и т.п. Т.е. не ту, которая разрабатывается абстрактно фиг знает где, а ту, которая разрабатывается именно в России. Собственно, такие варианты линуксов давно есть.
19 ноя 07, 13:19    [4933356]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
ыудусе
Guest
kdv
автор
Возьмите Linux, ... возьмите MySQL, ... возьмите PostgreSQL...

основная мысль, проталкиваемая политиками перед выборами, состоит в том, что Россия должна иметь СВОЮ операционную систему и т.п. Т.е. не ту, которая разрабатывается абстрактно фиг знает где, а ту, которая разрабатывается именно в России. Собственно, такие варианты линуксов давно есть.


Кхм
Царь-Сервер, Царь-ОС, Царь-СУБД ... Поставить на Красной Пощади шоб японцы фотались
22 ноя 07, 05:54    [4947940]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Yo.!

Хм ... WAL в постре есть, вы походу UNDO имеете ввиду. и не понял вашей уверености в том, что переписать небольшую часть сторадж системы постгреса сложнее, чем довести до ума оптимизатор, язык хп, schema, partitioning и сотни других вещей которые на десятилетия отстают от постгре в mysql ?


Вы исходники Постгреса видели. Там "переписать небольшую часть сторадж системы постгреса" не получится. Масштаб задачи не тот. Фичи типа языка ХП на самом деле дописать не так уж и тяжко. Вообще тут надо как следует посмотреть, может просто интегрироваться с JVM и забить на язык ХП.

А еще, я бы на оупенсорсный Ингрес обратил внимание. Вполне ничего СУБД.
30 ноя 07, 04:03    [4985215]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Yo.!
Guest
Зл0й

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

видел, все у них получится. если есть аргументы, внимательно выслушаю, а сотресать воздух пустыми заявами я тоже умею :)

Зл0й

Фичи типа языка ХП на самом деле дописать не так уж и тяжко. Вообще тут надо как следует посмотреть, может просто интегрироваться с JVM и забить на язык ХП.

вся история развития субд говорит об обратном ...

Зл0й
А еще, я бы на оупенсорсный Ингрес обратил внимание. Вполне ничего СУБД.

банальный блокировочник, что там интересного ?
3 дек 07, 12:56    [4994952]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Yo.!
Зл0й

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

видел, все у них получится. если есть аргументы, внимательно выслушаю, а сотресать воздух пустыми заявами я тоже умею :)

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


Yo.!

Зл0й

Фичи типа языка ХП на самом деле дописать не так уж и тяжко. Вообще тут надо как следует посмотреть, может просто интегрироваться с JVM и забить на язык ХП.

вся история развития субд говорит об обратном ...

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


Yo.!

Зл0й
А еще, я бы на оупенсорсный Ингрес обратил внимание. Вполне ничего СУБД.

банальный блокировочник, что там интересного ?

А интересного там то, что это реально работающая СУБД которую я могу бесплатно поставить в production environment не опасаясь за последствия такого шага. Она не будет "затыкаться" и с ней не надо будет постоянно "воевать" в отличие от того же постгреса. Ингрес конечно не Оракл, но реально "рабочая" - стабильная и масштабируемая СУБД. Да старомодная, да ограниченная по фичам, но халява ведь.
3 дек 07, 19:38    [4997872]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
sqllex
Member

Откуда: Kiev
Сообщений: 710
Зл0й
Она не будет "затыкаться" и с ней не надо будет постоянно "воевать" в отличие от того же постгреса. Ингрес конечно не Оракл, но реально "рабочая" - стабильная и масштабируемая СУБД. Да старомодная, да ограниченная по фичам, но халява ведь.

Где вы эту инфу откопали о Постгресе?
Я знаю реальный проект, работающий с базами в сотни гигабайт. Фирма торгует информацией (собирает ее, хранит в БД Постгреса). Работает давно и успешно.
В штате 2 ДБА.

Как то это плохо соотносится с вашими словами.
3 дек 07, 20:25    [4997949]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Yo.!
Guest
Зл0й

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

это сотресание воздуха, есть отчеты где код постгреса признан образцовым (тулза какая-то прочесывала на предмет ошибок в коде). дальше, можно ничего не менять, а просто добавить новый IL, допустим обозвать его snapshot, алгоритмы все разжеваны и доступны свободно. за последние несколько лет это фокус прокатил у MS, Mysql и Sybase IQ (по слухам прокатит и у ASA), не вижу ничего сверъхестественного в том что такой же фокус прокатит и у постгреса ...

Зл0й
А еще, я бы на оупенсорсный Ингрес обратил внимание. Вполне ничего СУБД.

банальный блокировочник, что там интересного ?[/quot]
А интересного там то, что это реально работающая СУБД которую я могу бесплатно поставить в production environment не опасаясь за последствия такого шага. Она не будет "затыкаться" и с ней не надо будет постоянно "воевать" в отличие от того же постгреса. Ингрес конечно не Оракл, но реально "рабочая" - стабильная и масштабируемая СУБД. Да старомодная, да ограниченная по фичам, но халява ведь.[/quot]
ну если вы уверовали в существование базбажного кода, то мне нечего ответить. вокруг ingress даже комунити нет, ну а если бы это была такая чудесная субд, то пост-ингрес (Postgres) просто не появился бы.
3 дек 07, 21:26    [4998038]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
sqllex
Зл0й
Она не будет "затыкаться" и с ней не надо будет постоянно "воевать" в отличие от того же постгреса. Ингрес конечно не Оракл, но реально "рабочая" - стабильная и масштабируемая СУБД. Да старомодная, да ограниченная по фичам, но халява ведь.

Где вы эту инфу откопали о Постгресе?
Я знаю реальный проект, работающий с базами в сотни гигабайт. Фирма торгует информацией (собирает ее, хранит в БД Постгреса). Работает давно и успешно.
В штате 2 ДБА.

Как то это плохо соотносится с вашими словами.


Сотни гигабайт на сегодняшний день это ничего. У меня в Wells Fargo было хранилище данных на 80 терабайт, в одном из подразделений компании Ebay - на 20. Это - серьезные объемы данных, то есть такие где уже сам по себе объем данных начинает вызывать проблемы. Например в Оракле начинаются проблемы с производительностью recursive SQL и приходится привлекать Oracle Support и оптимизировать с их помощью Oracle Data Dictionary. Стандартные решения из книжки Тома Кайта тут не прокатывают, в отличие от базульки на 200 гиг. Это во времена 7го оракла проблемы начинались с 200 гиг примерно, а Оракл уже надысь 11й вышел, у пацанов в продакшне 2й релиз десятки стоит.

У этой вашей фирмы, с 200 гиг базулькой как туда данные пишутся? К ним вообще есть какой-то конкурентный доступ (чтение-запись) или нет? Потому что ели там доступ например типа "новые данные только добавляются + периодическое чтение" то эта задача легко решается без применения СУБД вообще. Причем пути ее решения известны с 70х годов прошлого века, еще со времен System/370. Так что применение постгреса для решения такой "детской" задачи не свидетельствует о его качестве как СУБД. Скорее наоборот.
4 дек 07, 21:55    [5003446]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
сурьозныйе мужыки начали письками меряться
4 дек 07, 21:57    [5003449]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Yo.!
Зл0й

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

это сотресание воздуха, есть отчеты где код постгреса признан образцовым (тулза какая-то прочесывала на предмет ошибок в коде). дальше, можно ничего не менять, а просто добавить новый IL, допустим обозвать его snapshot, алгоритмы все разжеваны и доступны свободно. за последние несколько лет это фокус прокатил у MS, Mysql и Sybase IQ (по слухам прокатит и у ASA), не вижу ничего сверъхестественного в том что такой же фокус прокатит и у постгреса ...

Сссылка на "какие-то" отчеты - это как раз и есть сотрясение воздуха, причем с вашей стороны. Я лично код постгреса читал и плевался. Насчет тулзы ищущей ошибки в коде вы издеваетесь, я надеюсь? Какой тулз найдет вам ошибки проектирования? Например когда есть интерфейс высокого уровня а код лезет в нижний уровень и создает ненужные зависимости - это как? Постгрес весь написан именно так, от и до, без внятной четкой структуры, и модульности и дисциплины.

Насчет алгоритмов которые "разжеваны" и "доступны свободно" вы жестоко заблуждаетесь. Вы читали "Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery" авторов Vossen, Gottfried; Weikum, Gerhard? А "Transaction Processing: Concepts and Techniques" Jim Gray вы читали? Судя по вашим утверждениям - нет, что объясняет ваше весьма поверхностное владение предметом обсуждения. Напомните-ка мне сколько лет ушло у Microsoft на то чтобы сделать snapshot? Это при том что данная компания мягко выражаясь "не испытывает недостатка ресурсов". Даже в этих умных книжках изложены "академические" алгоритмы, которые для написания реального продукта непригодны. Они - это идея и начальная точка для разработки. Чтобы получить систему которая стабильно работает и масштабируется вверх вам придется очень серьезно потрудиться и ваш конечный продукт будет серьезно отличаться от того что в умной книжке написано. Иначе мы имели бы десятки, если не сотни различных альтернатив на рынке СУБД.

Yo.!

Зл0й

Yo.!

Зл0й
А еще, я бы на оупенсорсный Ингрес обратил внимание. Вполне ничего СУБД.

банальный блокировочник, что там интересного ?

А интересного там то, что это реально работающая СУБД которую я могу бесплатно поставить в production environment не опасаясь за последствия такого шага. Она не будет "затыкаться" и с ней не надо будет постоянно "воевать" в отличие от того же постгреса. Ингрес конечно не Оракл, но реально "рабочая" - стабильная и масштабируемая СУБД. Да старомодная, да ограниченная по фичам, но халява ведь.

ну если вы уверовали в существование базбажного кода, то мне нечего ответить. вокруг ingress даже комунити нет, ну а если бы это была такая чудесная субд, то пост-ингрес (Postgres) просто не появился бы.

Постгрес был "пост" по отношению к университетскому ингресу. Это - 80е годы. Современный Ингрес (коммерческий) к университетскому имеет примерно такое же отношение как 11й оракл ко 2му.

У меня на самом деле подход практичный до безобразия. Предположим мне нужно поставить систему чтобы обрабатывал некий поток конкурентных транзакций приходящих из приложения. Если речи об обработке транзакций нет - СУБД вообще не нужна, можно журналируемой файловой системой обойтись. Если я буду пропускать более-менее серьезный объем транзакций через Ингрес, при грамотно написаном приложении система будет стабильно и надежно работать. На том же самом серьезном объеме транзакций Постгрес просто ляжет и будет лежать даже не дрыгаясь. А причина - в идиотском storage engine.

Пацаны из Datallegro когда строили свой Data Warehouse Appliance начали с MySQL. Потом они переключились с него на Ingres. И получили вполне неплохой продукт в отличие от всяких Бизгресов и Greenplum'ов. Если бы вам представилась возможность плотно поработать с этими двумя продуктами (Datallegro vs. Greenplum), вам все было бы понятно с Ингресом и Постгресом.
4 дек 07, 22:36    [5003532]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Yo.!
Guest
2Зл0й

гы-гы, человек, что лабал версионность в mssql утверждал, что на это ушло пара человеко-месяцев, т.е. даже если он приврал на порядок, то выходит от силы пара человеко лет
Еще смешно, что сторадж система mssql те же яйца что и постгреса, только сбоку. МС вместо файлов данных зипихнула версии в файлы базы темпдб, теже строки вместо блоков, тот же сбор мусора и та же каша.
Причем объясняя почему так быстро - потому как еще в 80х была опубликована хорошо проработаная теоритическая база. будете настаивать найду тот тред. к стате, раз уж вы "в теме", откройте для себя vldb конференцию, большинство фундоментальных алгоритмов оракла было опубликована там.

Что же до ингрес, то призывы возлагать мишен критикал задачи на ущербный блокировочник который помер еще в прошлом тысячилетии и на сегодня осталось 3 живых инсталяции на планете мне не понятны ...
5 дек 07, 00:26    [5003729]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
sqllex
Member

Откуда: Kiev
Сообщений: 710
Зл0й

Сотни гигабайт на сегодняшний день это ничего. У меня в Wells Fargo было хранилище данных на 80 терабайт, в одном из подразделений компании Ebay - на 20. Это - серьезные объемы данных, то есть такие где уже сам по себе объем данных начинает вызывать проблемы.

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

Зл0й
У этой вашей фирмы, с 200 гиг базулькой как туда данные пишутся? К ним вообще есть какой-то конкурентный доступ (чтение-запись) или нет?

200 Гб? Это откуда?
Я где-то год назад перестал с ними тесно общаться, поэтому не могу указать точно объем данных на текущее время. Когда-то сам был удивлен решением об использовании Постгрес. Интересовался проблемами, на что мне со снисходительным удивлением отвечали: а какие должны быть проблемы?
Специфика бизнеса требует получать текущие отчеты по запросам заказчиков в том числе и по свежедобавленным данным. Поэтому (и не только поэтому) - OLTP, хотя так и просится применять OLAP для обработки заказов. Добавление и первичная обработка данных идет паралельно с обработкой поисковых запросов.
5 дек 07, 11:19    [5004957]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

Yo.! wrote:
> гы-гы, человек, что лабал версионность в mssql утверждал, что на это
> ушло пара человеко-месяцев, т.е. даже если он приврал на порядок, то
> выходит от силы пара человеко лет
В личной беседе, я так полагаю?
Поелику тынца почему-то не вижу :(

Posted via ActualForum NNTP Server 1.4

5 дек 07, 14:12    [5006549]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Yo.!
Guest
locky

Yo.! wrote:
> гы-гы, человек, что лабал версионность в mssql утверждал, что на это
> ушло пара человеко-месяцев, т.е. даже если он приврал на порядок, то
> выходит от силы пара человеко лет
В личной беседе, я так полагаю?
Поелику тынца почему-то не вижу :(

тынц тута:
http://forum.privet.com/viewtopic.php?t=48469

вот тут он же рассказывает где и как пашет, там же проскакивает цифра о кол-ве кодеров ядра, но так нудно рассказывает ...
http://www.gotdotnet.ru/Channel9/303324.aspx
5 дек 07, 15:36    [5007438]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
2Yo:
В последней версии - ASA10 появилась поддержка snapshot.
6 дек 07, 10:52    [5010618]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Yo.!
Guest
Ggg_old
2Yo:
В последней версии - ASA10 появилась поддержка snapshot.

а есть url хоть на какие-то подробности ? буквально пару месяцев назад просматривал whats new от ASA10 и незаметил и намека. ASCRUS, говорил, что планировалось что то серьезней, чем в темпдб заснуть версии.
6 дек 07, 12:01    [5011211]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Сейчас на сайбэез.ком в разделе документации доступны олько pdf-файлы, а онлайн хтмл-ек я не нашел. Я кое-что вставлю сюда из втроенной справки, но т.к эта тема в этом топике оффтоп, то при желании можно продолжить в сайбезовом разделе. Версии хрянятся таки в темповых фалах, не в темпдб, т.к у аса нет темпдб. Любые темповые данные аса сохраняет во временных файлах, множество которых она создает и удаляет по своему усмотрению в процессе работы. Внендрение поддержки снапшот изоляции, кстати улучшило аса как блокировочник, т.к. они разработчики изменили алгоритмы управления индексами (версионность индексов), которые даже в режиме чистого блокировочника позволяют АСАшке лучше управлять блокировками.
Итак:

SQL Anywhere® Server - SQL Usage > Using Transactions and Isolation Levels > Isolation levels and consistency
A snapshot is a set of data that has been committed in the database. When using snapshot isolation, all queries within a transaction use the same set of data. No locks are acquired on database tables, which allows other transactions to access and modify the data without blocking. SQL Anywhere supports three snapshot isolation levels that let you control when a snapshot is taken:

snapshot Use a snapshot of committed data from the time when the first row is read, inserted, updated, or deleted by the transaction.

statement-snapshot Use a snapshot of committed data from the time when the first row is read by the statement. Each statement within the transaction sees a snapshot of data from a different time.

readonly-statement-snapshot For read-only statements, use a snapshot of committed data from the time when the first row is read. Each read-only statement within the transaction sees a snapshot of data from a different time. For insert, update, and delete statements, use the isolation level specified by the updatable_statement_isolation option (can be one of 0 (the default), 1, 2, or 3).
...[skiped]...
The following statements cannot be executed within a snapshot transaction:

ALTER INDEX
ALTER TABLE
CREATE INDEX
DROP INDEX
REFRESH MATERIALIZED VIEW
REORGANIZE TABLE
TRUNCATE TABLE is allowed only when a fast truncation is not performed because in this case, individual DELETEs are then recorded in the transaction log. See TRUNCATE TABLE statement.

In addition, if any of these statements are performed from a non-snapshot transaction, then snapshot transactions that are already in progress that subsequently try to use the table return an error indicating that the schema has changed.

Materialized view matching avoids using a view if it was refreshed after the start of the snapshot for a transaction.
...[skiped]...
Row versions
When snapshot isolation is enabled for a database, each time a row is updated, the database server adds a copy of the original row to the version stored in the temporary file. The original row version entries are stored until all the active snapshot transactions complete that might need access to the original row values. Remember that a transaction using snapshot isolation sees only committed values, so if the update to a row was not committed or rolled back before a snapshot transaction began, the snapshot transaction needs to be able to access the original row value. This allows transactions using snapshot isolation to view data without placing any locks on the underlying tables.

The VersionStorePages database property returns the number of pages in the temporary file that are currently being used for the version store. To obtain this value, execute the following query:

Old row version entries are removed when they are no longer needed. Old versions of BLOBs are stored in the original table, not the temporary file, until they are no longer required, and index entries for old row versions are stored in the original index until they are not required.

You can retrieve the amount of free space in the temporary file using the sa_disk_free_space system procedure. See sa_disk_free_space system procedure.

If a trigger is fired that updates row values, the original values of those rows are also stored in the temporary file.

Designing your application to use shorter transactions and shorter snapshots will reduce temporary file space requirements.

If you are concerned about temporary file growth, you can set up a GrowTemp system event that specifies the actions to take when the temporary file reaches a specific size. See Understanding system events.


И часть изменений в индексах:

Indexing enhancements The following enhancements have been made to indexing:

New index implementation Previous releases of SQL Anywhere contained two different indexing implementations that were chosen automatically based on the declared size of the indexed columns. In SQL Anywhere 10, a new implementation of compressed B-tree indexes is used throughout, and older B-tree indexing technology has been eliminated. The new indexes store a compressed form of the index key value in the index entry, separate and distinct from the value in the row. This is required to support snapshot isolation.

Support for snapshot isolation In previous SQL Anywhere releases, index entries were deleted on UPDATE or DELETE statements immediately. To support snapshot isolation, there is potential for several index entries to point to the same logical row with different index key values. These multiple index entries are managed by the database server so that any one connection can see only one of the entries for any given row. Periodically, a daemon within the server will physically delete these extra index entries when they are no longer needed (as transactions COMMIT or ROLLBACK). Retaining index entries for uncommitted DELETEs also improves semantic consistency of the concurrency control mechanisms in SQL Anywhere. See Snapshot isolation.
6 дек 07, 15:57    [5013631]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
Valery Shiskin
Member

Откуда:
Сообщений: 786
Есть ряд СУБД с открытым кодом, где активно, а то и в первых рядах разработчики россияне. Весь мир может использовать и пользуется такими СУБД. Коммерческий продукт должен сам доказать что он лучше (пример InlellyJ Idea), а не заявлять "хватит платить". Кстати, уже обговаривается, по крайней мере по TV, необходимость оснащения атомных электростанций отечественными СУБД. Я ничего не имею против, но только должен знать, что эта/эти СУБД тестировались десятилетиями по всему миру, а не тольго в недрах какого-либо НИИ.
11 дек 07, 11:24    [5031100]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs HyTech. По мотивам откровений Ковалевского  [new]
hytech
Guest
Давайте вернемся к теме? Грядет автоматизация одного ГОСа - и на полном серьезе рассматривается перспектива выбора HyTech в качестве субд вместо MS DE / Oracle Lite / Oracle SE.

Есть ли те кто реально работал стой СУБД? Можете дать ответы на ряд вопросов:
jdbc дравер к ней есть? или хотя бы odbc?
платформа - только Вин или Линукс/Атласикс ?
поддержка транзакций?
какие-то известные ограничения?

Это будет вполне современное J2EE приложение в качестве хранилища на удаленных местах (центральная база Оракль) использующее (возможно) HyTech. На территории будет стоять один сервер на нем база + JSP/JSF морда для работы с ней и несколько(5-10) рабочих машин с MSIE. Связи с внешним миром может и не быть.

Храниться будет несколько табличек по ~ 1 ..2 миллиона записаей + полно мелких табличек -- справочников. Периодически из территориальной базы будет выгружаться дельта и на собаках (на флешках) отвозиться в центральный оффис - и там сгружаться в оракл. В другую сторону взаимодействие минимальное. -- Справочники и результаты явных запросов. Т.е. фактически на замену Cashe'

Стоит / Нестоит так делать? Именно по части выбору ХайТеча.

Поделитесь плз опытом - знанием. Кричать все г...но возмите нормальный Оракль я тоже умею)) Хотелось бы обоснованных рекомендаций...Или необрот от-рекомендаций .
17 дек 07, 15:43    [5058614]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить