СУБД в SQL чипе - что-то новенькое в мире DBMS

В тестах TPC-H появилась интересная система от Kickfire, заняв достаточно высокое место в тесте на 300Gb . Немного присмотревшись, появилось надежда, что кто-то наконец придумал что-то новенькое в мире DBMS. Kickfire это реляционная субд, где часть функционала оптимизатора выполняется в неком SQL-чипе, а другая часть является MySQL:

MySQL provides:
● connectivity
● security
● administration

Kickfire software provides:
● optimizer
● column store and cache
● transactional engine

SQL Chip provides:
● SQL execution
● memory management
● loader acceleration

Судя по всему SQL-чип втыкается в PCI-E слот, имеет собственную память и берет на себя выполнения некоторых реляционных операторов, к примеру берет на себя выполнение джоинов. Выглядит, что принцип похож на 3D чипы в видеокартах, которые берут на себя операции со множествами которые процессоры общего назначения выполняют не так успешно. Сторадж система также своя - колоночная (напоминает Sybase IQ). Мысль конечно не сильно новая, специализированное MPP железо для субд не редкость, но дешевые чипы, на дешевых x86 серверах, да еще и c MySQL обвязкой вполне способны устроить небольшой прорыв.

IDC: World wide RDBMS 2007 Vendor Shares

IDC опубликовали новые цифры по рынку RDBMS, первое, что бросается в глаза - изменились цифры за 2006 год. В июне 2007-го у оракла было 7,312 млрд за 2006й, а в этом отчете усохла до 7,240. Цифра IBM за 2006 увеличилась на 600 килобаксов, остальные цифры так же скачут. Будем надеяться, что просто уточнили данные, хотя рассматривая другие их отчеты верится с трудом. Второе, что бросилось в глаза - темпы роста Майкрософт снизились более, чем в 2 раза (с 25% до 11%). Оракл стабильно растет на 13-14% и пока безусловный лидер.



Подробнее.

Новости SAP-SD: Oracle RAC на 2,3,4,5 нодах и новые Opteron

IBM опубликовала еще 4 теста Oracle RAC 10g на SAP-SD Parallel, показав тем самым, как RAC может масштабироватся до 5 серьезных узлов (по 16 Power6 4.7Ghz ядер на каждом узле). В тестах участвовало 2, 3, 4 и 5 нод и на данный момент это лучший результат в SAP-SD (2-tier), что доказывает, что RAC не просто масштабируется близко к SMP, но и вполне возможно дальше, т.к. пока я не видел более чем 64-core (меня поправили: 16 power6 ядер - максимум на сегодня может предложить IBM) системы на Power6 в каком либо известном тесте.

Подробнее.

Наконец-то появились долгожданные тесты четырех-ядерных AMD Opteron, пока Opteron 2.3Ghz не смог превзойти ни результат XEON, ни SUN T5120.

Подробнее.

TPC-E: MSSQL2008 vs MSSQL2005

Судя по всему Майкрософт действительно выпустит новую версию своей субд в этом году. Компанией IBM в TPC-E опубликован результат MSSQL2008 на том же железе, что был результат MSSQL2005, новая версия в этом тесте более производительна на 12%, однако не совсем понятно за счет нововведений новой версии субд или изменений в процедурах. Новый тест использует версионный механизм для IL Snapshot не только в процедуре BrokerVolume, но теперь и в TradeStatus, который во всех предыдущих тестах MSSQL2005 использовал блокировочный IL Read Commited.
Еще примечательно, что новая система гораздо дороже: в новом тесте вместо 36Gb 15K rpm дисков использовалось то же кол-во более дорогих дисков по 73Gb 15K rpm, плюс почему-то в 3 раза подорожала память.

Подробнее.

SUN покупает MySQL AB

За $800M + $200M опций SUN покупает MySQL AB. То что SUN обязан выйти на рынок RDBMS обсуждалось уже давно, но как теперь они будут делить единственный нормальный движек Innodb с ораклом не совсем понятно.
Еще странно, что приобрели не EnterpriseDB (главного разработчика Postgres), видно клиентская база MySQL интересовала больше.

Подробнее.

Новый конкурент Oracle RAC

Sybase ASE анонсировал shared-disk кластер, где все ноды кластера имеют одинаковый доступ к файлам базы данных. Таким образом это первый shared-disk кластер на стандартном железе способный посоревноватся с Oracle RAC. Технологию parallel sysplex IBM тоже называет shared-disk кластеризацией, однако db2 может использовать shared-disk cluster только на мейнфреймах, где синхронизацией блокировок и кешей занимается сверхдорогое железо. Sybase ASE же предполагает програмно синхронизовать кеш и структуры блокировок т.е. аналог Cache Fusion в Oracle. Интересно насколько блокировочная природа и хранение блокировок в памяти ASE даст оверхед против неблокируемого чтения и хранение блокировок в блоках данных RAC.

Подробнее.

Oracle Siebel Benchmarks: 32-bit Win vs Linux + SPARC T2 vs Power6

Невероятно, но в Siebel 8.0 Benchmarks SPARC T2 победил Power6, но что еще более неворятней так то, что Windows одалела Linux. Итак по порядку: в первых двух тестах участвовали одинаковые IBM x3850 сервера, где сервер субд был на Linux (RHEL4) и различались лишь операционные системы апп-сервера. При примерно одинаковой загрузки апп-сервера 84% vs 86% Windows обслуживал 3900 vs 3500 пользователей Linux. Странно конечно, что использовались 32-bit системы, тогда как использовалось более 20Gb RAM, но еще большая странность в том, что меньшее кол-во пользователей и транзакций на Linux системе генерировало больше трафика 19.04 Mbps vs 11.36 Mbps.
Что касается Power6 и SPARC T2, то тут странностей меньше, response time Power6 гораздо красивей, но у SPARC T2 он вполне приемлим и на уровне результатов Win/Lin, а пользователей SUN сервера обслужили на 3,000 больше (10,000 vs 7,000). Еще наверно стоит заметить, что против одного 8-way сервера на Power6 было выставлено два SPARC T2 сервера, т.е. в результате у апп-серверов противников, на которые и пришлась основная нагрузка, было по 16 ядер.

Подробнее.

Рекорд Oracle RAC 10g на SAP-SD

В SAP SD Parallel опубликован кластерный результат Oracle RAC 10g на 5 узлах по 8 Power6 процессорах. Этот результат опережает на 17% самый лучший SMP результат у SAP-SD на данный момент SMP конфигурацию из 64 Itanium на 10g. Таким образом Oracle подтвердил, что его Shared Disk кластерная технология действительно масштабируется практически линейно и на большом hi-end железе. RAC показал практически в 5 раз лучший результат чем SMP результат DB2 на 8 процессорах (разница всего 8%).
Судя по всему сегодня может сложится ситуация десятилетней давности, когда Oracle реализовав materialized view показывал в разы лучшие результаты относительно конкурентов в тестах TPC-D. Теперь велика вероятность того, что RAC сможет показать в разы лучший результат в новейшем тесте TPC-E, т.к. конкуренты используют shared nothing кластерную архитектуру, которая не сможет быть столь эффективной на OLTP задаче TPC-E.

Результат.

Новости бенчмарков

DELL опубликовал еще 2 результата в TPC-E, снова на MSSQL и в версионном режиме. Сравнивать доступные 6 тестов на MSSQL пока не появится тест от Oracle или IBM не интересно.

Подробнее.

SPEC.org опубликовал первый тест SPECpower_ssj2008 измеряющий производительность и потребление энергии. Пока там всего 12 результатов и только Xeonы и старенький Opteron. Будет очень интересно посмотреть на результат Niagara II.

Подробнее.

В тестах TPC-H появились 2 новых игрока (субд): ParAccel Analytic Database и EXASOL EXASolution 2.0, оба используют MPP архитектуру, которая как известно хорошо подходит под известные заранее аналитические запросы. Результат у обоих впечатляет.

Подробнее.

TPC-E: Снова тест на MSSQL

Опубликован четвертый тест TPC-E, снова на MSSQL2k5 и снова x86. Странно, что в этом тесте не опубликованы супорт файлы, во всех трех предыдущих тестах они были опубликованы. Чтож, будем с нетерпением ждать результатов от остальных производителей субд.

Подробнее


Вторая новость от Oracle: на сайте выложен Oracle11g 64-bit Linux и 32-bit Windows. Качать тут.

--
Добавление: супорт файлы все же появились.

SUN выпустил сервера с процессором Niagara II

SUN выпустил сервера t5220 и t5120 с процессором Niagara II на борту, которые снова не впечатляют. Вместе с серверами опубликованы бенчмарки от lotus domino до SPECint/SPECfp и одного из моих любимых SAP-SD. В SAP-SD T5120 на Oracle10g и 64Gb RAM показал 10,950 SAPS, что конечно лучше, чем любой 2х процессорный результат на текущий момент, но совеошенно незначительно опережает 10,400 SAPS Quad-Core Intel Xeon Processor X5365. А со дня надень ожидается результат AMD Barselona против которого у Niagara II нет шансов. При чем нужно учитывать, что 64Gb Niagara II стоит около $60К, что почти в 2 раза дороже сервера HP (32Gb RAM) который показал 10,400 SAPS.

http://www.sun.com/servers/coolthreads/t5220/
http://www.sun.com/servers/coolthreads/t5120/

Niagara II @ SAP-SD

Oracle 11g первый тест в TPC-C

Совсем недавно на точно таком же железе 10g установил рекорд в TPC-C на Oracle Linux в плане price/performance, теперь уже 11g выступал на Windows и оказался на 1.5% быстрее. Интересно, что стоимость Windows и Linux на 3 года получилось практически одинаковой.

Подробнее

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, совершенно не учитывая реализацию этой архитектуры ...

OpenSource RDBMS market share

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

TPC-E: первый опубликованый результат

Наконец дождались первого опубликованого результата в тестах TPC-E. Первым рискнул Unisys и Microsoft MSSQL2k5. С учетом предстоящего выхода Oracle11g очень хочется верить, что ответ оракла не заставит себя долго ждать. Помню как критиковали Microsoft за то, что они за несколько месяцев до выхода mssql2k5 не публиковали никаких тестов в то время как Oracle10g участвовал в tpc-c за год до выхода. Сегодня получается, что Oracle11g вроде как официально представлен, но реально по слухам будет доступен в августе, а тестов до сих пор никаких нет. Будем надеятся, что это связано именно с подготовкой тестов TPC-E.

Подробнее.

Дополнение: присмотревшись, обнаружил интересный факт - в этом тесте включен версионный механизм (ALLOW_SNAPSHOT_ISOLATION ON) и один из запросов (BrokerVolume.SQL) который прочесывает почти всю БД использует уровень изолированости транзаций snapshot. Но еще интересней, что строчкой выше закоментирована строка
--SET TRANSACTION ISOLATION LEVEL READ COMMITTED
Как я понимаю READ COMMITED не смог выдать консистентный результат, но специалисты не стали использовать тут "родной" для блокировочника SERIALIZABLE, а включили SNAPSHOT на всю базу. Очень будет интересно будет понаблюдать в дальнейшем кто победит snapshot или serializable в остальных тестах.

Еще однин тест TPC-C на схожем железе

На этот раз mssql2k5 вывели вперед: 372,140 tpmC mssql2k5 vs 359,440 tpmC у oracle10g
однако разница между результатами целый год и и/о система с mssql оснащена дисками следующего поколения: 590 SAS vs 546 UltraSCSI дисков у оракла.

Oracle10g
MSSQL2k5