За $800M + $200M опций SUN покупает MySQL AB. То что SUN обязан выйти на рынок RDBMS обсуждалось уже давно, но как теперь они будут делить единственный нормальный движек Innodb с ораклом не совсем понятно.
Еще странно, что приобрели не EnterpriseDB (главного разработчика Postgres), видно клиентская база MySQL интересовала больше.
Подробнее.
января 16, 2008
января 12, 2008
Новый конкурент 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.
Подробнее.
Подробнее.
января 10, 2008
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 ядер.
Подробнее.
Что касается Power6 и SPARC T2, то тут странностей меньше, response time Power6 гораздо красивей, но у SPARC T2 он вполне приемлим и на уровне результатов Win/Lin, а пользователей SUN сервера обслужили на 3,000 больше (10,000 vs 7,000). Еще наверно стоит заметить, что против одного 8-way сервера на Power6 было выставлено два SPARC T2 сервера, т.е. в результате у апп-серверов противников, на которые и пришлась основная нагрузка, было по 16 ядер.
Подробнее.
января 03, 2008
Рекорд 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.
Результат.
Судя по всему сегодня может сложится ситуация десятилетней давности, когда Oracle реализовав materialized view показывал в разы лучшие результаты относительно конкурентов в тестах TPC-D. Теперь велика вероятность того, что RAC сможет показать в разы лучший результат в новейшем тесте TPC-E, т.к. конкуренты используют shared nothing кластерную архитектуру, которая не сможет быть столь эффективной на OLTP задаче TPC-E.
Результат.
Подписаться на:
Сообщения (Atom)