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

Откуда: Северная Калифорния
Сообщений: 686
Итого, сухой остаток

На сегодня ни одна СУБД не поддерживает уровни изоляции транзакций в полном соответствии со стандартом ANSI. Более того, стандарт ANSI далеко не полностью оговаривает все возможные варианты поведения СУБД применительно к изоляции транзакций. Блокировщики отлконяются от стандарта в одну сторону а версионники - в другую.

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

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

То есть Информикс с новой фичей несколько лучше старого но да Оракла ему по прежнему далеко. Существует целый класс задач (см пост Yo! выше) которые ни Информикс ни любая другая СУБД-блокировщик по нормальному решать не умеет. И такое положение вещей не изменится пока не будет переписано ядро СУБД, что в случае конкретно Информикса скорее всего не будет сделано никогда.
24 дек 08, 20:00    [6616387]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Зл0й пишет:

> На сегодня ни одна СУБД не поддерживает уровни изоляции транзакций в
> полном соответствии со стандартом ANSI. Более того, стандарт ANSI далеко
> не полностью оговаривает все возможные варианты поведения СУБД
> применительно к изоляции транзакций. Блокировщики отлконяются от
> стандарта в одну сторону а версионники - в другую.

Но я хочу подчеркнуть: отклонение в "верхнюю" сторону конкретной реализации
уровня в данной СУБД допустимо по стандарту.

Posted via ActualForum NNTP Server 1.4

24 дек 08, 20:18    [6616424]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Yo.!
onstat-

А в чем прелесть версиoнности на OLTP ?

в конкретный примерах, если не затруднит?

прелесть - получение консистентных набора без блокирования половины субд и проблем с дедлогами, вам это уже несколько раз демонстрировалось. ;) за примером идите на TPC-E, там очень красиво видно как в первом тесте МС пыталась запустить без версионности (осталась закоментированая строка), но в итогде длинный читающий запрос был выполнен все же на уровне IL Snapshot. в последних тестах еще один длинный запрос начали выполнять на IL snapshot.


Почему вы думаете, что постоянно тащить все версии данных дешевле, чем подождать освобождения блокировки ? "Длинные читающие запросы" в OLTP системах случаются once in a while, а ресурсов ваша версионность жрет от души.
26 дек 08, 23:54    [6627961]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
Выбегалло

Почему вы думаете, что постоянно тащить все версии данных дешевле, чем подождать освобождения блокировки ? "Длинные читающие запросы" в OLTP системах случаются once in a while, а ресурсов ваша версионность жрет от души.

в олтп почти наверника все версии будут в кеше, а длинные запросы в том tpc-e не так уж редко вылазят.
27 дек 08, 13:02    [6628447]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
Выбегалло

Почему вы думаете, что постоянно тащить все версии данных дешевле, чем подождать освобождения блокировки ? "Длинные читающие запросы" в OLTP системах случаются once in a while, а ресурсов ваша версионность жрет от души.

в олтп почти наверника все версии будут в кеше,

Если пытаться анализировать технические причины сабжа ( почему Informix displaces Oracle at China Telcom )
Есть 2 варианта работы системы.
1. Очень много горячих блоков в кеше.
По этому пунткту informix имеет 2 очень важных перймущества
а. Ядро СУБД контролирует контексты выполнения пользовательских сессий, то есть пользовательской сессии не будет выделен процессор, если сессия не может получить доступ к ресурсу ( он защищен мутексом) по причине особенностей внутренней многозадочности ядра.
Все что выделяет ОС она выделяет ядру Informix, а оно само решает какую пользовательскую сессию в этом контексте выполнения крутить.
Насколько я знаю , проблема горячих блоков в Oracle решается через параметр _spin_count то есть простым опросом мутексов сессиями. Если Вы знаете другие возможности Oracle по борьбе с ожиданиями на горячих блоках в буферном кеше приведите ссылки. ( Про реверсивные индексы я знаю).

б. Informix имеет возможность( через параметр) поделить буферный кеш на несколько независимых LRU.

2. Изменений много, но они равномерно распределены между блоками таблиц.
В этом случае Ваше наверняка абсолютно не очевидно.

Yo.!

а длинные запросы в том tpc-e не так уж редко вылазят.


Давайте поделим систему 2 части, регистрационная часть, это та которая выполняет всю OLTP
работу, и отчетная часть в которой как раз и могут вылазить длинные запросы.

С точки зрения регистрационной части, консистентность на какой то момент в прошлом
( будь то даже начало текущего запроса), не имеет никаких преймушеств, так как
необходимо оперировать с реальными значениями на момент их изменения.
Поэтому програмисты Oracle используют явное блокирование записей
через select for update или DBMS_LOCK , версионные механизмы здесь не работают.


Что касается отчетной части, соглаcен, что версионные механизмы Oracle удобнее.

При выборе СУБД оценивается соотношение регистрационной и отчетных
операций в системе, какие из них важнее, и чем дешевле пожертвовать.

Думаю и надеюсь , что китайцы сделали свой выбор на базе всесторонней оценки возможностей
сабжевых СУБД, а не откатов и прочей политической лабуды.
27 дек 08, 16:07    [6628654]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
onstat-

а. Ядро СУБД контролирует контексты выполнения пользовательских сессий, то есть пользовательской сессии не будет выделен процессор, если сессия не может получить доступ к ресурсу ( он защищен мутексом) по причине особенностей внутренней многозадочности ядра.

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

б. Informix имеет возможность( через параметр) поделить буферный кеш на несколько независимых LRU.

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

onstat-

В этом случае Ваше наверняка абсолютно не очевидно.

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

onstat-

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

не факт, мне кажется в полне логичным отказать в доступе т.к. на момент запроса на счету не было достаточно средств. версионник проиграет только в случае совершенной необходимости пессимистичной блокировки т.к. не имеет всего того зоопарка блокировок который есть у типичного блокировочника ... хотя озвученая доля 90% в телекомах Китая и явно больше 50% в России наверно наверно говорит о том, что оптимистичная блокировка в задачах телекома привалирует (на наших широтах).
27 дек 08, 18:29    [6628866]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7672
Tons of Fun @ informix

К сообщению приложен файл. Размер - 0Kb
28 дек 08, 03:20    [6629583]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Yo

к стате, а в информиксе можно назначить буфер с отличным от других размером блоков ?

Да:
[quote IDS]

IBM Informix Dynamic Server, Version 11.50
--------------------------------------------------------------------------------


BUFFERPOOL
onconfig.std values
Operating systems with 2K default page size:
BUFFERPOOL default,buffers=10000,lrus=8,lru_min_dirty=50.00,
lru_max_dirty=60.50
BUFFERPOOL size=2k,buffers=50000,lrus=8,lru_min_dirty=50,
lru_max_dirty=60
Operating systems with 4K default page size:
BUFFERPOOL default,buffers=10000,lrus=8,lru_min_dirty=50.00,
lru_max_dirty=60.50
BUFFERPOOL size=4k,buffers=10000,lrus=8,lru_min_dirty=50,
lru_max_dirty=60

[/quote]
28 дек 08, 13:05    [6629770]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
onstat-

а. Ядро СУБД контролирует контексты выполнения пользовательских сессий, то есть пользовательской сессии не будет выделен процессор, если сессия не может получить доступ к ресурсу ( он защищен мутексом) по причине особенностей внутренней многозадочности ядра.

чтоб объявить это преимуществом, нужно хоть какое-то обоснование. мне история с этим вопросом представляется так: оракл столкнувшись с проблемой производительности переключения контекста процессов в винде принял решение на этой платформе использовать тхредовую модель,
но при этом не переводить на тхреды отсальные платформы (по понятным причинам).

Я не знаю, по каким ?

Yo.!

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

Этот API Informix написал еще в 1993 году.

Понять теоретическое обоснование, почему именно так поступили разработчики можно отсюда

http://en.wikipedia.org/wiki/Branch_predication
http://en.wikipedia.org/wiki/Branch_prediction
http://en.wikipedia.org/wiki/Branch_misprediction

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


Yo.!

onstat-

б. Informix имеет возможность( через параметр) поделить буферный кеш на несколько независимых LRU.

это древняя фича в оракле, к стате,

Ссылочку приведите пожалуйста, как я могу поделить конкретный буфферный пулл на несколько LRU
И как этим управлять?

Yo.!

а в информиксе можно назначить буфер с отличным от других размером блоков ?

Уже ответили.

Yo.!

onstat-

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

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


На счете уже небыло, а в undo на момент начала запроса было значение
которого хватало, ИМХО без пессиместичной блокировки тут не обойтись.
29 дек 08, 11:59    [6631616]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
onstat-

юнихов с тхредами по прежнему не все гладко, в линуксе так просто сыро. в винде с точностью до наоборот, потому и пришлось обоим в 1993 выкатывать тхредовые версии. в плане шедулеров математики тут не причем, мячь сейчас у линуксойдов, которые сию секунду обкатывают на линуксовом ядре кажется три стратегии шедулеров.
по буферным кешам в оракле есть три дефолтных пула, один стандартный, на другой ЛРУ не распростроняется и используется, чтоб напрочь закешировать объект, третий ровно наоборот, предотвратить кеширование. кроме этого можно насоздавать свои пулы и задать объектам (таблицы, индексы, партиции) имя дефалтного пула через опцию BUFFER_POOL, эта фича была уже в семерке.
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14249/adlob_design.htm
с информиксом прочел доку и ничего не понял. "Operating systems with 2K default page size" - что такое дефаулт применительно к ОС ? речь о файловой системе или где ? и как то не понял, если нужно отлично от дефаулта, то что ? к стате в догонку, можно ли в информикесе в одной базе часть таблиц иметь с 8К страницей, другую с 16К ?

по поводу писсемистичной блокировки - ну если совсем необходимо оно есть в оракле в виде for update и dbms_lock. но судя по популярности оракла в телекомах они больше оптимистичную применяют.
29 дек 08, 14:03    [6632543]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!

onstat-

с информиксом прочел доку и ничего не понял. "Operating systems with 2K default page size" - что такое дефаулт применительно к ОС ? речь о файловой системе или где ? и как то не понял, если нужно отлично от дефаулта, то что ? к стате в догонку,


Informix page это почти тоже самое что в Oracle block.

автор

The basic unit of database server I/O is a page. Page size might vary among computers.


Yo.!

можно ли в информикесе в одной базе часть таблиц иметь с 8К страницей, другую с 16К ?


конечно, создаете дбпространство
http://publib.boulder.ibm.com/infocenter/idshelp/v111/index.jsp?topic=/com.ibm.adref.doc/adref426.htm

Потом создаете таблицу в этом дбпространстве
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqls.doc/sqls301.htm



Yo.!

по поводу писсемистичной блокировки - ну если совсем необходимо оно есть в оракле в виде for update и dbms_lock. но судя по популярности оракла в телекомах они больше оптимистичную применяют.


Вовсе не факт, они применяют, то что не нарушает логической целостности данных.
29 дек 08, 15:14    [6633119]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
onstat-

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



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

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

Поэтому я могу сказть что только Oracle со своим линухом сможет чего то добиться.
Другие разработчики не могут учитывать пожелания всех подряд, потому что это практически не реализуемо.
29 дек 08, 17:02    [6633872]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
herr
Member

Откуда:
Сообщений: 163
Yo.!
без версионности пытатся переманить пользователей оракла, да еще и на OLTP - утопия.

конечно, утопия!
как же без версионности делать нижеследующее

Yo.!

MasterZiv

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

Пример: select * from table

можно еще select * from calls или select * from cdr и идти пить чай с бубликами ;) (все же пройдет и будет результ)


Зл0й
Например в одной из OLTP баз у меня на работе он установлен в 3 часа. Поскольку запросы выполняющиеся по 3 часа в OLTP базах как правило не встречаются, то вероятность получить ошибку вместо данных мизерная.

Попросите Yo.! выполнить парочку десятков вышеприведенных запросов на Вашей базе ;)

А вообще рад что Oracle обладает такими замечательними способностями как версионность...и делает на этом акцент.
Особенно видя, как народ форматирует какой-то SQLище на десять тысяч строк в Toadе и при этом утверждая что он (SQL) аж не делает deadlockов! Так ведь и не делает! Работает!

Так что работы хватит для всех в ближайщем будущем

Yo.!

хотя озвученая доля 90% в телекомах Китая и явно больше 50% в России наверно наверно говорит о том, что оптимистичная блокировка в задачах телекома привалирует (на наших широтах).

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

---

В телекомах, особенно сейчас, когда маржа все падает, а кол-во транзакций (звонков) выросло-и-растет с каждым днем, все чаще-и-чаще присматриваются к альтернативам...
29 дек 08, 23:15    [6634916]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
herr, учитесь писать менее эмоционально и более информативно
29 дек 08, 23:43    [6634966]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
onstat-

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

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

И вообще, как информикс работает. из курса по осям смутно помню, что процесс это понятие на уровне процессора, соответсвенно при переключении просессов CPU производит аппаратно огромную работу в том числе востанавливая значения регистров, если для ОСи информикс один процесс (наверно однин на процессор) значит никто информиксу аппаратно не вычисляет адреса, не востанавливает значения регистров ...
29 дек 08, 23:54    [6634986]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
onstat-

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

честно - не знаю, а вы знаете ? наверно в каких-то шедулерах можно, в других наверное нельзя. но если можно у меня ломается мозг, что это может дать ?


Это может дать представление, что ОС не с состоянии
знать ( угадать ) когда процесс ( нить) пользовательской сессии заснет на латче, и вообще нужно ли ее будить в настоящий момент, хотя ее время( по шадулеру) уже наступило,
в соответсвии с
http://en.wikipedia.org/wiki/Branch_predication
http://en.wikipedia.org/wiki/Branch_prediction
http://en.wikipedia.org/wiki/Branch_misprediction

Yo.!

информикс проводит какую-то оптимизацию основаную на знании о кол-ве латчей ? можно чуть развернутей, что там за оптимизация ?



Так Вам это уже рассказывали

https://www.sql.ru/forum/actualthread.aspx?bid=29&tid=271249&pg=4&hl=%e2%e5%f0%f1%e8%ee%ed%ed%ee%f1%f2%fc#2649266
30 дек 08, 10:24    [6635489]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Yo!
на другой ЛРУ не распростроняется и используется, чтоб напрочь закешировать объект

Это неверно. Все там распространяется, и все там вытесняется по LRU, просто детали этого механизма несколько отличаются.
30 дек 08, 11:15    [6635784]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
onstat-

Это может дать представление, что ОС не с состоянии
знать ( угадать ) когда процесс ( нить) пользовательской сессии заснет на латче,

url с подробностями наконец можно увидеть ? ну ждет к примеру сессия25 латча на блок38 в кеше и что это знание дает ? перед переключением на сессию25 проверять латч - глупо, будем войную работу часто и густо делать.

onstat-

и вообще нужно ли ее будить в настоящий момент, хотя ее время( по шадулеру) уже наступило,
в соответсвии с
http://en.wikipedia.org/wiki/Branch_predication
http://en.wikipedia.org/wiki/Branch_prediction
http://en.wikipedia.org/wiki/Branch_misprediction

мне не понятно какое отношение это имеет к информикс ? мне не понятно откуда могут возникнуть ветви в ожиданиях. и совершенно не понятно почему вы выбрали латчи, а не блокировки, почему не погадать по блокировках, их больше
короче очень хочется документик от ИБМ рассказывающий о своем шедулере, прирно такой какие есть по шедулерам современных осей.

Yo.!

https://www.sql.ru/forum/actualthread.aspx?bid=29&tid=271249&pg=4&hl=%e2%e5%f0%f1%e8%ee%ed%ed%ee%f1%f2%fc#2649266

не вижу описания оптимизации. там описана софтварная эмуляция базовых возможностей процессора. ядро субд состоит из множества подсистем очень далеких друг от друга. движек SQL как ни крути будет иметь переключение контекста на исполнение интерпритатора PL/SQL и я не вижу преимуществ в софтварной эмуляции такого переключения.

2Apex
ОК, там я сильно не вникал.
30 дек 08, 11:42    [6635973]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Yo.!

мне не понятно какое отношение это имеет к информикс ? мне не понятно откуда могут возникнуть ветви в ожиданиях. и совершенно не понятно почему вы выбрали латчи, а не блокировки, почему не погадать по блокировках, их больше
короче очень хочется документик от ИБМ рассказывающий о своем шедулере, прирно такой какие есть по шедулерам современных осей.


Нет там никакого scheduler-а в понимании ОС. Потому что невытесняемая многозадачность. Каждая нить сама ставит себя в очередь к латчу и передает управление планировщику, который пробегает очередя, проверяет какие нити перешли в состояние готовности и переставляет их в очередь на выполнение, и запускает первую нить из очереди.
2 янв 09, 20:11    [6643281]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
С версионностью разобрались, закономерным образом не нашли у СУБД-блокировщиков (на примере Информикса) никаких существенных преимуществ. Теперь полезли искать эти преимущества в архитектуре сервера. Их там тоже нет. Потому, что как показывает практика многопоточная архитектура сервера СУБД не дает никаких ощутимых преимуществ по сравнению с многопроцессной. Оракловый инстанс на юниксе, если его рассматривать "с высоты птичьего полета" представляет собой немеряных размеров кусок shared memory к которому прицеплена дюжина системных процессов самой СУБД. А в информиксе - один большой и толстый процесс у которого внутри куча нитей (трэдов, потоков). Синхронизация доступа к памяти в обоих случаях осуществляется "ручками" потому как память в обоих случаях разделяемая. Более того, Оракл в виндовой версии тоже представляет собой один большой процесс с кучей трэдов внутри. Сделано это потому что винды в отличие от Юникса и особенно Линукса не умеют переключать процессы с приемлемой производительностью. В Оракле написан API который позволяет в значительной степени абстрагироваться от нюансов реализации ОС.

Вообще, раз зашла речь про такие вещи как latch contention, то при грамотно спроектированном приложении в них обычно упираются при попытках выжать последние 2% производительности из системы из которой 98% уже выжато. Причина очевидна - все те явления которые происходят в оперативной памяти случаются примерно на 1-2 порядка быстрее чем те которые затрагивают подсистему ввода-вывода.

Я предполагаю что в причина по которой в China Telecom поменяли одну СУБД на другую не имеет ровным счетом никакого отношения к производительности самой СУБД. Была некая команда криворуких разработчиков, сделавших систему которая работала через пень-колоду. Хреново работало не потому что СУБД "кривая" а от неумения проектировать и разрабатывать, то есть от банальной кривизны рук. Систему-то можно даже и на IMS с коболом и CICS сделать, если уметь. Это правда это будет гораздо дороже чем реляционная СУБД, но работать будет. Когда криворуких выгнали взашей, то на смену им пришла другая команда с другим инструментом (Информикс). Могла бы прийти команда с DB2 в качестве инструмента, ничего бы не поменялось.

Я видел немало проектов по переходу с одной СУБД на другую, как правило кривизна рук разработичков списывается на кривизну СУБД. Ищется некая магическая серебряная пуля в виде другой СУБД. И не находится.
3 янв 09, 01:41    [6644170]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7672
У информиха и по сей день много толстых телекомуникационных клиентов, типа AT&T, Verizon, Sprint Nextel. Так чта выбор CT не удивителен. Также можно вспомнить Walmart, Mastercard, и Home Depot. Видимо, где требуется процессинг огромного количества OLTP там требуется информикс. А там, где это не требуется (во множестве случае, ИМХО), можно обойтись и "другими системами" :)
3 янв 09, 02:37    [6644219]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Интересно, почему IBM им продал informix а не свой любимый DB2. Думаю, что о тредах, латчах и блокировках китайцы думали меньше всего, вернее те кто принимал решение руководствовались другими критериями - ценой вопроса в деньгах и времени. Скорее всего оракл проявил жадность невиданных даже для китайцев масштабов и пролетел.
А блокировки, изоляции, латчи - это всё грустный удел гиков.
3 янв 09, 12:45    [6644330]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7672
Ggg_old
Скорее всего оракл проявил жадность невиданных даже для китайцев масштабов и пролетел.
А блокировки, изоляции, латчи - это всё грустный удел гиков.
Почему? Оракел у них и так уже был куплен... Сами подумайте - зачем им покупать лицензии информикса при оплаченных оракловых?
3 янв 09, 17:31    [6644650]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7672
Ggg_old
те кто принимал решение руководствовались другими критериями - ценой вопроса в деньгах и времени.
Руководство не принимает решения, а выбирает из того, что ему предложат :)
3 янв 09, 17:40    [6644657]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Значит предложение оракла оказалось неконкурентноспособным. Все просто.
Нам остается только гадать о подробностях их тендера. Но мораль сей басни такова, что последний информикс выиграл очень большой тендер в неравных стартовых условиях.
3 янв 09, 18:48    [6644716]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить