Совсем недавно в одном из топиков о производительности OLTP я увидел комментарий о том, что по версии Transaction Processing Performance Counsel, Oracle является лидером в пропускной способности. Действительно, согласно результатам ТРС-С теста, Oracle 11g Release 2 Enterprise Edition with Oracle Partitioning продемонстрировал пропускную способность около 140 тысяч транзакций в секунду (8,552,523 tpmC) на системе, базирующейся на SPARC T5-8 Server (8 процессоров, 128 ядер), цена которого $4,663,073. Более подробную информацию о тесте можно найти официальном ТРС сайте здесь http://www.tpc.org/tpcc/results/tpcc_perf_results.asp и здесь http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=113032601.

140 тысяч транзакций в секунду - очень уважаемый результат. Тем не менее, я хотел бы заметить, что в 2009 году VoltDB провел подобное тестирование и продемонстрировал сопоставимый результат в 150 тысяч транзакций в секунду на 3-узловом кластере состоящем из Dell R610 (3х8 ядер) общей стоимостью около $6000. Более того, при расширении кластера до 12 узлов (и, соответственно, увеличении стоимости аппаратных средств до $25000), тест продемонстрировал пропускную способность в 560 тысяч транзакций в секунду .

https://forum.voltdb.com/showthread.php?8-VoltDB-tpc-c-like-Benchmark-Comparison-Benchmark-Description

Basil A. SidorovЧто ж вы в TPC не рвёте всех как тузика грелкой?
Злобные вендоры проплатили, чтобы вас снимали с соревнований ещё до старта?

Да нет, мы с другими вендорами в хороших... Да и грелку рвать - не самоцель :). Просто ТРС-C спецификация написанная в 1988 году, по нашему мнению, устарела и во многом не отражает современные технологические возможности. Поэтому тест который мы провели в 2009 году является модифицированной версией ТРС-С и, как результат, не может считаться официальным. Кстати, по ссылке есть подробное описание нашего теста и отличий от официального ТРС-С, если кому-нибудь интересно.

Yo.!VoltDBДа нет, мы с другими вендорами в хороших... Да и грелку рвать - не самоцель :). Просто ТРС-C спецификация написанная в 1988 году, по нашему мнению, устарела и во многом не отражает современные технологические возможности. Поэтому тест который мы провели в 2009 году является модифицированной версией ТРС-С и, как результат, не может считаться официальным. Кстати, по ссылке есть подробное описание нашего теста и отличий от официального ТРС-С, если кому-нибудь интересно.

для OLTP еще в 2007 уже был TPC-E, но VoltDB без ACID и без изолированности транзакций там делать нечего ...

VoltDB разработан специально для поддержки ACID, включая изолированность транзакций

Alexander Ryndin
Тестирование VoltDB сделано на сильно видоизмененном тесте (ну типа эти 10% нагрузки мы не считаем кошерными, поэтому мы их выкинем)

Тест действительно видоизменен в части заказов которые поступают на один склад, но заполняются из другого. И это действительно 10% всех транзакций в тесте. Хотя я не считаю, что такой тест “сильно видоизмененый”, но при этом согласен с тем что наши результаты не могут считаться официальными в соответствиями с ТРС требованиями.


Alexander Ryndin Ну и комменты от тестеров парадовали:
https://forum.voltdb.com/showthread.php?8-VoltDB-tpc-c-like-Benchmark-Comparison-Benchmark-Description&p=27&viewfull=1#post27%5D]https://forum.voltdb.com/showthread.php?8-VoltDB-tpc-c-like-Benchmark-Comparison-Benchmark-Description&p=27&viewfull=1#post27]... since our multi-parition transactions are slower, we've limited our TPC-C-like benchmark to single-partition transactions for the time being.

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

Alexander Ryndin 2) Наверняка в TPC-C где-то прописано требование к ACID. VoltDB - это in-memory база данных, обеспечивающая Durability либо с помощью репликации, либо с помощью логгирования на диск (здравствуй Oracle Redo log). Репликация, очевидно, не может быть достаточно надежна, а логгирование в приведенном тесте, скорее всего отключено
Durability: VoltDB provides active/active intra-cluster replication of partitions in-memory (referred to as K-safety) and periodic database snapshots to disk combined with command logging to disk to ensure high availability and database durability.

В данном тесте K-safety=0. Логгирование не отключалось - в противном случае откатывание транзакций, необходимое с соответствии с тестовой спецификацией, было бы невозможным

Alexander Ryndin 3) Раз уж взялись сравнивать с Oracle на T5-8, то это не кластер. А вы сравниваете с VoltDB на 3-х и 12-ти узловом кластером. Согласен. Но при этом, все-таки, T5-8 имеет 1ТБ оперативной памяти, прямо доступной каждому из 128 ядер. Вполне вероятно, что большая часть базы сидит в кэшах на всех уровнях (как и должно происходить в System R СУБД. Да и вообще, не поймите меня неправильно, Oracle - штука заслуживающая большого уважения во многих аспектах)

Alexander Ryndin 4) Сравнение нужно проводить с одноклассниками, а то повадились сравнивать свои жигули с белазами.

Согласен в общем, но с некоторыми комментариями. Во-первых, наша цель для нашех тестов не “догнать и перегнать”, а убедиться в том, что к наша архитектурная “дорожная карта” верна и мы находимся на правильном пути в разработке нашй системы. Вы абсолютно правы в том, что Oracle и VoltDB разработаны для разных задач и, соответственно, имеют как преимущества, так и недостатки, характерные для таких специализированных архитектурных решений. Кроме того, каждая технология имеет свою коммерческую нишу. Например, мне кажется, если пользователю нужна поддержка 140 тысяч тран/сек ТРС-С, далеко не каждый мог бы заплатить $4.6 миллиона за Oracle на T5-8. Большинство, наверное, попыталось бы найти более дешевые способы поддержки подобных нагрузок. В нашем случае, видоизменение ТРС-С требования в части заказа, который поступает на один склад, но заполняется из другого накладывает определенные ограничения на бизнес-транзакцию (кстати, как часто Вы сталкиваетесь с вэб-магазинами, которые получают заказ в одном складе, а заполняют его в другом?), но если общая себестоимость системы при этом могла бы уменьшится в несколько сотен раз, то наложение такого ограничения (или его решение, например, на вэб-сервере) может иметь определенный смысл... Я полностью разделяю Вашу мысль о “Жигулях и Белазах”, но, к сожалению, по моему опыту, иногда Белаз используется там, где можно было бы и Жигулем обойтись.