TPC-E: DELL как и предыдущие 2 результата использует IL Snapshot

Третий результат в новом OLTP тесте от TPC. В этом тесте DELL использовал 4xIntel Dual-Core Xeon и Microsoft SQL server. Как и предыдущие 2 результата использующие Microsoft SQL server, DELL использует версионный механизм в тесте.

Подробнее

SAP-SD: SUN T2000 второй тест - слабовато

Sun опубликовал новый тест системы T2000 на этот раз на 8 ядрах 1.4Ghz T1 процессор и Oracle10g. Результат: 5530 SAPS, что почти в 2 раза слабее систем на двух процессорах Xeon X5365 (4-cores), который раза в три дешевле системы T2000.
Еще тест интересен тем, что Sun уже публиковал тест T2000 в конце 2005 года на 8 ядрах 1.2Ghz, но на бесплатной субд MaxDB, тогда результат был 4780 SAPS. Учитывая, что разница ядер составляет 200Mhz, плюс разница в версии приложения SAP R/3 (тогда использовалась версия 2004, сейчас 2005) то можно смело предположить, что смена субд с субд с MaxDB на Oracle10g практически никакого эфекта не произвела. Судя по всему MaxDB неплохо оптимизирована под SAP R/3 т.к. разница между Microsoft SQL Server и Oracle иногда доходит до 30% (в пользу Oracle).

Подробнее.

Forrester: DBMS Market Overview

Интересные таблички нашлись в презентации Forrester:

DBMS product	% of enterprises using DBMS
SQL Server	81%
Oracle	77%
DB2	53%
Access	28%
Sybase	23%
IMS	19%
Informix	19%
MySQL	17%
Teradata	13%
Adabas	9%
IDMS	8%
PostgreSQL	4%
Filemaker	2%
Ingres	2%
Progress	2%

В компаниях с доходами > $500M

Oracle	67%
SQL Server	55%
DB2	51%

Презентация

TPC-E: IBM в след за Unisys использует версионный механизм

Вторым в тесте TPC-E выступил IBM на x86 блейдах с Windows и MSSQL2k5. IBM так же как и первый тест использует IL snapshot в BrokerVolume.sql, вместо казалось бы "родного" для MSSQL serializable. И это при том, что система не большая, всего 2x Xeon 5160 на сервере субд.
ЗЫ. Похоже на основной страничке небольшая ошибка: там написано, что был 1 процессор, но в полном репорте уже идет речь о 2х процессорах и MSSQL2k5 лицензирован на 2.
ЗЫЫ. о, ошибочку поправили ...

Обзор версионных субд глазами воинствующего ораклойда

Давно хотел немного пошалить и собрать в одном документике архитектуру различных версионных субд, вокруг которых достаточно регулярно возникают самые интересные религиозные войны. Вот тут я и попробовал пройтись по архитектуре некоторых распространенных сегодня субд MVCC (multi-version concurency control).
За идеал версионной архитектуры конечно же возьму архитектуру Oracle, идеальность которой как известно сомнению не подлежит :)

Итак приступим: на низшей ступени стоят файл-серверные субд, такие как Foxpro и Accsess и прочая. Тут нет ничего: вместо ACID транзакций - "fake" [1], нет понятия уровня изолированности транзакций или консистентного набора (вместо этого некая буферизация), отсутствует стоимостный оптимизатор и самое прикольное - полная беззащитность БД. Любой кто имеет доступ к системе может записать все, что злобной душе угодно напрямую в файл БД минуя субд.
По транзакциям, как важнейшему компоненту субд, наверно стоит пройтись отдельно. Например в Foxpro это выглядит примерно так: средствами ОС на куски файла (к стате ну очень отдаленно напоминает как Oracle хранит блокировки в блоках данных) ставятся блокировки, после чего модифицируется некий кеш на клиенте и только после commit, содержимое кеша сбрасывается в файлик БД (dbf). В результате, если происходит сбой (файл-сервера или в сети) после фиксации транзакции, во время сбрасывания кеша, БД просто превращается в неконсистентную кашу, т.к. отвернуть неудачную транзакцию просто некому. При Insert ситуация не так страшна, т.к. судя по всему сначала данные записываются в конец файла и только потом модифицируется его заголовок, поэтому Foxpro может врубится, что данные заголовка не совпадают с реальным размером файла, а вот с Update все веселее - клиент просто молча может сбросить лишь часть данных кеша и молча погибнуть, при этом, о таком веселом происшествии прознать нет никакой возможности. Сложно сказать как это происходит в Access т.к. Майкрософт скрывает технические подробности, но судя по структуре файла Access тут таже беда, т.к. вернуть оригинальную версию строки при неудачной транзакции попросту неоткуда.
Немного снизить шансы такого сбоя можно попробовав перетащив систему на клиент-серверную архитектуру, например с помощью встроенных функций SOAP, но ACID транзакции и консистентный набор от этого к сожалению не появятся.

На заметно более высоком уровне развития находятся Interbase и его open source клон Firebird. Тут уже присутствуют зачатки почти всех признаков "взрослых" субд, единственно, напрочь отсутствует лог транзакций. Firebird существует в двух архитектурах: Classic и Superserver.
В Classic туча независимых сессий/процессов имеющих собственный отдельный кеш, зато процессы бывает раскидываются операционной системой по разным процессорам.
Superserver, появившийся позже, имеет один процесс и единый на все сессии кеш, что уже немного больше напоминает взрослые субд, облом состоит в том, что этот единственный процесс должен быть привязан к одному процессору, т.е. smp/многоядерные системы не супортится.
Концепция MVCC Firebird досталась еще от Rdb компании DEС и сильно отличается от нашего "идеала": При модифицируемой транзакции новые версии строк пишутся прямо в тот же блок или рядом с оригинальной версией, причем в большинстве случаев не вся строка, а только "дельта" между оригинальной и новой строкой (если дельта выходит больше, чем строка, пишется вся строка). По commit модифицируется Transaction Inventory Page (TIP) (заголовок дата-файла), где отмечается статус транзакции, по сути одним движением головки HDD, что и гарантирует ACID и невозможность беды подобной Foxpro. [2] Далее асинхронный процесс подчищает ненужные версии строк из файлов данных, что конечно же отлично сказывается на самочувствии остальных пользователей.
С уровнями изолированности транзакций тут так же не все гладко (в сравнении с остальными версионниками): READ COMMITED не обеспечивает консистентное чтение на уровне стэйтмента. [3]
[Добавление: в InterBase 7.x появился transaction log и smp support в superserver архитектуре]

Следующим идет Postgres, тут все уже гораздо лучше, есть WAL (write-ahead log) лог транзакций, сессии реализованы в виде процессов и имеют общий кеш, READ COMMITED обеспечивает консистентный набор стейтмента, все как у больших. Единственное большое разочарование - схожая с Firebird схема хранения версий строк или их дельты прямо в файлах данных, и соответственно необходимость в сборе мусора.

Microsoft SQL server 2005 практически полностью скопировал реализацию MVCC Oracle/Postgres, но как обычно MS немного не дотянул. Например, Oracle оперирует версиями блока данных, а сиквел строками. Оперирование блоками позволяет универсально накладывать версионность на любой объект, плюс позволяет делать оптимизацию: если блок уже стоит в очереди на сброс (на носитель), Oracle может создать копию блока и модифицировать именно копию, вместо того, чтоб дожидаться когда блок окажется на носителе.
Второе крупное различие - в mssql2k5 версии строк хранятся в tempdb, в то время как в Oracle в отдельной структуре сегментов отката (в оракле для отдельных транзакций можно создавать отдельные сегменты отката ). Tempdb часто становится головной болью администратора mssql и без версионности, проблеме i/o в tempdb на msdn посвящена не одна нота т.к. там помимо временных таблиц и табличных переменных хранятся сортировки и курсоры. Добавление в tempdb еще и версий строк делает и без того перегруженный tempdb узким местом в системе. Кроме этого MSSQL вынужден раз в минут (или при нехватке места) заниматся сбором мусора из tempdb, что также создает дополнительную нагрузку.
Следующее различие в том, что сегменты отката Oracle защищены от безразмерного роста и место пространства отката используется циклически (размер и их кол-во может задаваться админом). При неправильном размере сегментов очень длинная транзакция может получить ошибку ORA-01555 snapshot too old, в результате чего откатится лишь одна транзакция, в то время как в mssql2k5 ни что не ограничит рост tempdb, в результате одна «неудачная» транзакция может просто переполнить tempdb и остановить работу всех пользователей (есть job которым можно как-то попробовать среагировать).

Будете смеяться, но с точки зрения концепций MySQL/Innodb оказывается ближе всех - у него как и в Oracle выделены два лога UNDO и REDO, однако оперирует не блоками, а строками. [4] Поскольку UNDO отдельная структура, которую можно использовать циклически - нет необходимости в сборе мусора. Однако блокировки как и mssql хранятся в отдельной структуре в памяти, а не в блоках данных, кроме этого mysql исповедует multi-threading архитектуру, такую архитектуру Oracle использует только на Windows платформе.

To be continued ...

ЗЫ расстановка была только по степени похожести на архитектуру Oracle, совершенно не учитывая реализацию этой архитектуры ...