Эталонные тесты СУБД: что было, что стало, что будет

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

В 2002 году было опубликовано около 300 различных результатов оценки СУБД, а в период с 2009 по 2012 год наблюдался всплеск бенчмаркинга по линии TPC-C: каждый производитель СУБД и оборудования считал делом чести отчитаться о результатах оценки своих продуктов. Однако в 2017 году на сайте Совета по оценке производительности обработки транзакций (Transaction Processing Performance Council, TPC.org) был опубликован лишь один актуальный результат, и тот — для встраиваемой СУБД (SQL Anywhere). Во многом причиной охлаждения интереса стали изменившиеся типовые нагрузки для СУБД и новые модели их применения, появление NoSQL и распространение новых представлений о согласованности данных. Но это лишь частичное объяснение, для того чтобы разобраться в сложившихся обстоятельствах, следует не только проанализировать новые бенчмарки, но и взглянуть на проблему эталонного тестирования СУБД в целом.

Начало

На заре эры СУБД, в начале 1970-х годов, в Bank of America, который насчитывал тогда 1 тыс. отделений и 10 тыс. операционистов, задумались освоить централизованную безбумажную технологию, в связи с чем возникла потребность в СУБД, способной обрабатывать 100 транзакций в секунду. Корпорация IBM в ответ на эту потребность предложила инструментарий для проверки этой СУБД — тест TP1, ставший первым в ряду метрик оценки работы баз данных. Он работал в пакетном режиме на стороне базы данных, не принимая во внимание ни сеть, ни время реакции оператора, а лишь последовательно проводил операции снятия и зачисления средств на клиентский счет и выдавал количество транзакций в секунду (tps).

Через десять лет емкость рынка коммерческих СУБД перевалила за миллиард долларов и создатели систем стали спешно отчитываться о выдающихся результатах выполнения TP1, сообщая о невероятных 10 тыс. tps, хотя конечные заказчики получали максимум сотню транзакций в секунду. Для наведения порядка в отрасли доцент Висконсинского университета Девид Девитт в 1982 году создал более детерминированный эталонный тест, с четкими правилами масштабирования, не ориентированный на какую-либо предметную область, а работающий с условными кортежами. Однако призванный положить конец бенчмаркинговым войнам тест лишь разжег их сильнее: случилось так, что первая коммерческая реляционная СУБД, имевшая амбиции стать главной в мире транзакционной обработки, показывала на нем очень скромные результаты. Закончилось все скандалом — ходят слухи, что лично Ларри Эллисон звонил в Висконсинский университет с требованием уволить Девитта, а получив отказ, запретил кадровой службе Oracle нанимать на работу выпускников этого вуза. Главным же итогом для индустрии в этой истории стала так называемая оговорка Девитта, согласно которой обладателю лицензии на СУБД запрещается публиковать какие бы то ни было результаты тестов производительности без согласования с производителем. Такую оговорку в текст лицензионных соглашений включили поставщики практически всех основных систем того времени. У большинства из них она в том или ином виде сохраняется и по сей день.

В противовес абстрактному Висконсинскому тесту, корпорация Tandem в 1985 году решила вернуть к жизни розничнобанковский TP1, но уже с четкой спецификацией и всеми ограничениями, при которых было бы невозможно разгонять tps. Так появился тест DebitCredit — результат работы группы архитекторов Tandem, возглавляемой Джимом Греем [1]. В этом тесте были заданы базовые стандарты эталонного тестирования производительности СУБД: впервые четко обозначалось, что должно пониматься под стоимостью системы в целом (в случае коммерческой конфигурации стоимость транзакции будет наиболее важным показателем); устанавливались правила масштабирования по количеству пользователей с пропорциональным ростом размеров таблиц; вводилось ограничение на время отклика, согласно которому 95% транзакций должно завершиться за одну секунду. Эти, казалось бы, очевидные уточнения тогда были в новинку, а сегодня без такого рода ограничений нельзя считать осмысленным любой тест производительности, имитирующий пользовательскую нагрузку.

Эпоха TPC

Тест DebitCredit не отвечал на один важный вопрос: как убедиться в том, что тот или иной результат сравним с другими? Нелегко было убедить грандов отрасли следовать указаниям Tandem, поэтому вендоры, подстегиваемые клиентами из банковской сферы, где в то время началось развертывание сети банкоматов и от производителей требовались тысячи транзакций в секунду, продолжали публиковать результаты TP1. Нужна была независимая некоммерческая организация, которая пользовалась бы авторитетом у всех производителей, и в 1988 году был создан Совет по оценке производительности обработки транзакций. На момент первого собрания, на котором были утверждены спецификации тестов TPC-A и TPC-B, в Совет входило 26 компаний, включая всех ключевых производителей СУБД тех лет: IBM, Informix, Oracle, Ingres, Sybase, DEC, Software AG, Teradata. Важными составляющими соглашения стали принятые методики расчета цены, а также обязательность аудита результатов в аккредитованной организации.

Тесты TPC-A и TPC-B отличались тем, что в первом требовались эмуляция всего окружения (терминалов, сети) и учет времени на реакцию пользователя, а второй выполнялся пакетно на стороне базы данных, да еще и с сокращенной до 30 дней историей [2]. Простота реализации TPC-B и по сей день привлекает разработчиков и консультантов. Например, входящая в стандартную поставку PostgreSQL утилита pgbench выполняет TPC-B, и первые оценки на вновь развертываемых конфигурациях многие практикующие специалисты делают именно на TPC-B. В 1990 году был опубликован первый аудированный результат TPC-A: одна из систем на платформе PA-RISC от Hewlett-Packard получила 38,2 tpsA при 29,2 тыс. долл. за транзакцию в секунду. А через четыре года появился последний, от компании DEC, для сервера на платформе AlphaServer — 3700 tpsA с ценой на транзакцию в секунду в 4,7 тыс. долл. Но такой разброс результатов вовсе не свидетельство прогресса, а лишь признак того, что к простому четырехтабличному бенчмарку оказалось легко подстроиться. В 1995 году TPC-A и TPC-B были признаны несостоятельными, и появился более совершенный TPC-C.

Рис. 1. Модель данных TPC-C

В TPC-C [2] была сменена предметная область, что отражало и экспансию рынка транзакционных систем из банковской сферы на другие отрасли — теперь в тесте требовалось имитировать работу оптового склада (рис. 1). Квантом масштабирования в бенчмарке считается склад (W, WAREHOUSE), на каждом складе десять участков (DISTRICT), оснащенных терминалом, каждый терминал предназначен для регистрации клиентских заказов (ORDER), состоящих из записей ORDER-LINE о единицах хранения (STOCK). Таких заказов (транзакций) каждый участок может провести не более 1,2 в минуту. Как только достигается предельная производительность в транзакциях в минуту (tpmC), тест масштабируется путем добавления еще одного склада, и пока 90% транзакций откликаются менее чем за 5 с, масштабирование продолжается. Кроме ввода новых заказов (45% от общей нагрузки) тест предусматривает параллельное выполнение и других видов операций: прием платежа с обновлением баланса клиента (43%), проверку статуса последней заявки от клиента (4%), проверку уровня запасов на складе (4%), а также пакетный процесс формирования заявок на доставку (4%, к нему требование по порогу отклика — 20 с).

За годы существования TPC-C в его спецификации были включены четкие требования к надежности тестируемой конфигурации, исключающие возможность «оптимизаций», например, посредством переноса журналов упреждающей записи в оперативную память. Появилась еще одна относительная метрика: W/ktpmC — потребление в ваттах за каждую 1 тыс. транзакций в минуту со сложной методикой расчета энергопотребления. Однако результатов с просчитанными ваттами опубликовано было немного. Результаты TPC-C предлагались в двух номинациях: некластерной и кластерной. Причем кластерными считались все случаи, когда узлов базы данных было более одного, и не важно, каким образом реализовывалось это разделение.

К началу 2000-х годов на сайте tpc.org накопилась критическая масса результатов: у интеграторов и их заказчиков был достаточно обширный каталог конфигураций комплектов из оборудования и СУБД с тщательно отмеренными и проверенными показателями производительности. Дело было лишь за тем, как адаптировать синтетические tpmC к реальной системе, и на этот счет появились различные толкования. Наиболее показательные «правила пересчета» предлагал специалист по настройке СУБД на ОС Solaris Алан Паркер [3], который советовал tpmC из результатов: делить на два, если в целевой системе параллельно активно формируются отчеты или выполняются пакетные задания; умножать на 2/3, если используются легковесные экранные формы по типу написанных вокруг библиотеки curses, и на 1/3 — если формы типа Oracle Forms; делить пополам, если в системе не предусмотрен монитор транзакций. На последнее правило стоит обратить отдельное внимание: спецификация TPC-C предусматривает использование монитора транзакций, что позволяет естественным образом строить кластерные конфигурации, но усложняет организацию тестирования и заведомо удорожает систему на стоимость лицензий, которые в случае Tuxedo или CICS весьма недешевы.

Наряду со всеобщим признанием TPC-C как эталона для OLTP-нагрузок, распространилось и понимание того, что мерки этого теста ничего не скажут о производительности OLAP-систем на соответствующих конструкциях, да и поведение реальных систем с большим числом оперативных отчетов заметно отличается от заданного в спецификации. Назревшую необходимость в тестировании СУБД для отчетных нагрузок пытались воплотить в тесте TPC-R, а воспроизвести поведение OLAP-системы должен был тест TPC-D, но оба получились неудачными, и производители не спешили публиковать их результаты. Та же участь постигла и просуществовавший с 2001 по 2005 год TPC-W, призванный показывать производительность СУБД для условного интернет-магазина, — «тест для онлайн-веб-коммерции», главная проблема которого была, по-видимому, в том, что он опередил время.

В 1999 году удалось создать признаваемый всеми тест для OLAP – TPC-H, в котором были устранены основные недочеты TPC-D: продуманы методика масштабирования и правила отсчета длительности выполнения запросов; кроме сложных и произвольных (ad-hoc) аналитических запросов, предусматривалось два параллельных ETL-потока обновления данных в хранилище. Было сделано отступление от нормы отказа специфицирования фрагментами кода, что позволило некоторым его частям широко распространиться в виде отдельно выполняемых SQL-запросов (многим разработчикам хорошо известен запрос, обозначаемый Q1 — первый из спецификации). Однако соответствие такой спецификации практически нереально доказать для тестов, сделанных на языке, отличном от SQL. В отличие от транзакционных тестов, результаты TPC-H зависят от «весовой категории», поэтому и обозначаются соответственно: 10000 QphH@100GB означает выполнение 10 тыс. запросов в час на базе в 100 Гбайт. По состоянию на 2017 год имеются результаты почти во всех «весовых категориях»: 100 Гбайт, 300 Гбайт, 1 Тбайт, 3 Тбайт, 10 Тбайт, 30 Тбайт, 100 Тбайт для СУБД Actian Vector, Exasol, Oracle Database и Microsoft SQL Server.

Рис. 2. Потоки TPC-E

В 2006 году была опубликована спецификация транзакционного теста нового поколения — TPC-E, в которую вошли декларативные ограничения целостности (в ранние транзакционные тесты их не включали — в СУБД образца 1990-х годов не все было хорошо с гранулярностью блокировок); были упразднены мониторы транзакций; операций на выборку предусматривалось существенно больше; предписывалось также выполнять больше неуспешных операций (рис. 2). В соответствии с чаяниями рынка опять была сменена предметная область: TPC-E должен воспроизводить деятельность брокерского дома, а модель данных описывалась тремя десятками таблиц. Производители, однако, публиковать результаты не торопились, и хотя к 2017 году на сайте собралось 78 результатов, во всех них тестировалась только система Microsoft SQL Server в некластерной конфигурации на Windows x64. Тем не менее 78 результатов — это больше, чем один у TPC-C, и вывод о конце TPC-C и передаче эстафеты TPC-E напрашивается сам собой: несомненно, что наряду с -A/B, -C, -H он закрепился среди практических бенчмарков (рис. 3).

Рис. 3. Основные тесты TPC

Новые Нагрузки — Новые тесты

В 2008 году во всемирную информационно-технологическую историю ворвался Hadoop, чему во многом благоприятствовали результаты тестирования от Yahoo!: сортировка одного терабайта данных на кластере из 910 узлов заняла 210 секунд. Этот тест, получивший название TeraSort, берет начало из уже упомянутого отчета Tandem, где он назывался AlphaSort. Для прогона TeraSort не требуется так же тщательно выстраивать окружение, как для тестов TPC, — генерация тестового набора, запуск бенчмарка и проверка результата требуют по одной командной строке, а пакетный характер теста не накладывает ограничений на результат (как только сортировка заданного объема завершена, можно останавливать таймер). Вскоре появились и другие бенчмарки для Hadoop, связанные с типами нагрузок, интересными для пакетной массово-параллельной обработки. Все самые важные из них аккуратно упакованы корпорацией Intel в инструментарий HiBench, в который включены: PageRank — ссылочное ранжирование по алгоритму от Google; Nutch Indexing — индексация текстов; оценки для задач машинного обучения — байесовская классификация и кластеризация методом K-средних. Но именно TeraSort стал фактическим стандартом для массово-параллельных систем обработки данных, породившим новую категорию тестов в TPC — серию экспресс-бенчмарков, обозначаемых TPCx-, для акцентирования на простоте воспроизведения результатов, сближающей их в этом смысле с тестами SPEC. Так родился тест TPCx-HS, в котором не обязательно сортировать ровно 1 Тбайт — следуя логике TPC-H, предусмотрены и другие «весовые категории»: от 1 до 5 Тбайт, 10, 30, 100 и 300 Тбайт. Скорее всего, этот бенчмарк уже получил путевку в жизнь.

Сложнее обстоят дела с TPC-DS и созданным на его основе тестом BigBench, зарегистрированным как экспресс-бенчмарк TPCx-BB, — по ним пока нет ни одного результата. TPC-DS предложен как альтернатива TPC-H с отвязкой от реляционной специфики, и Советом он описан как «запускаемый на системах больших данных, таких как реляционные СУБД и системы на основе Hadoop/Spark». Провести тестирование по BigBench не сложнее, чем TeraSort, и регулярно появляются сообщения о его запусках в тех или иных конфигурациях (Hive над Spark, Hive над Tez), поэтому, похоже, у него много шансов на популяризацию.

Разнообразие современных востребованных нагрузок столь велико, что само представление о границах применения СУБД в сознании практиков существенно расширилось. Обработка геопространственных данных, мультимедиа, XML, JSON — все это нагрузки для СУБД в широком смысле, и для каждой из них нужен свой эталонный тест. И даже не углубляясь в иные структуры, мы видим, что транзакционные нагрузки современности оказываются кардинально различными. Это хорошо отражает интересная коллекция разнообразных бенчмарков в инструменте OLTPBench, который работает с любой реляционной СУБД, поддерживающей JDBC. Кроме классики в виде TPC-C, в OLTPBench есть типовые нагрузки, снятые с баз данных Twitter, Wikipedia, Epinions.com, а также смесь TPC-C и TPC-H под названием benCHmark, полный комплект нагрузок YCSB (Yahoo! Cloud Services Benchmark) и графовый тест LinkBench.

LinkBench, воспроизводящий нагрузки социальной сети Facebook, изначально был призван ответить на вопрос выбора платформы хранения для этого мегасайта: оставаться на MySQL либо переходить на HBase. И хотя трехтабличная модель данных нетипична для информационных систем в классическом понимании, но раз она оказалась эффективной в столь крупной интернет-компании и поведение СУБД на ней существенно отличается от классических предметных моделей, то бенчмарк не может не вызывать интереса. К тому же подкупает его методологическая проработка: использование законов статистики при генерации данных, отсчет среднего отклика в 99-м перцентиле, отсечка выбросов, а еще и то, что тест оказался применимым для сравнения систем из совершенно разных классов. Сотрудники Facebook в итоге сделали выбор в пользу MySQL, позднее же инструмент был адаптирован для документоориентированной MongoDB, графовой OrientDB и реляционной PostgreSQL.

Рис. 4. Комплект нагрузок Yahoo! Cloud Services Benchmark

Популярность YCSB также связана с его применимостью к оценке СУБД разнообразных классов, но с простотой интерпретации результатов дело обстоит сложнее — это не один тест, а шесть (рис. 4), причем каждый решает свою специфическую задачу, а не ориентирован на смесь нагрузок. Все операции во всех тестах атомарны (одна запись — одна транзакция, максимум — чтение нескольких записей), а нагрузка подается пакетно в API-режиме. Легкость выполнения теста сделала YCSB чуть ли не самым запускаемым бенчмарком современности, с его помощью умудрялись сравнить десяток СУБД из разных классов: Cassandra, Elastic Search, Tarantool, OrientDB и др. [4]. Однако какой-то глубинный смысл в полученных результатах найти трудно, да и возможности подстройки для таких тестов при отсутствии регламентирования надежности и отказоустойчивости требуют их результаты воспринимать с осторожностью.

При всей насущности задачи построения для новых категорий СУБД новых эталонных тестов, обеспечивающих сравнимость в своем классе, инициативные попытки их создания без глубокой проработки спецификации зачастую приводят к столкновениям производителей, как это уже было во времена TP1. Показателен пример недавнего конфликта между Gridgain и Hazelcast — представителями мира резидентных гридов данных (ныне воспринимаемых не только как связующее ПО, но и как самостоятельные СУБД): один из производителей создал своеобразный бенчмарк с красноречивым названием Yardstick и оценил результаты сравнения с конкурирующей системой в свою пользу, что было оспорено другой стороной с доказательством уже собственного преимущества в точности на том же тесте.

«Карманные» средства

Проблема самостоятельной оценки производительности СУБД, в особенности в условиях малого количества надежных и проверенных результатов на TPC.org, до сих пор актуальна для практиков. С одной стороны, появляются упакованные в удобные инструменты новые тесты, надежность получаемых результатов для которых, однако, не очевидна. С другой стороны, есть удобные графические инструменты, выполняющие серию тестов TPC, такие как HammerDB или Quest Benchmark Factory for Databases. Но и их результаты нельзя считать сравнимыми с опубликованными на сайте Совета, хотя бы в силу того, что TPC-C работает в них без мониторов транзакций, запуск производится с одной нагрузочной станции, а уж о возможности предъявить эти результаты для аудита даже говорить не приходится. Но можно и немного заступиться за HammerDB: на сайте этого популярного инструмента создан общественный обменник результатами, а раз они все делаются в рамках одного инструмента, то их можно считать сравнимыми и в этом смысле ценными. Есть реализации тестов TPC, создаваемые силами энтузиастов (tpcemysql от Percona и комплект тестов OSDBLT из osdblt.sourceforge.net), но опыт их сборки и использования противоречивый.

Следствием сложностей воспроизведения больших и «правильных» бенчмарков стало смещение внимания специалистов на простые инструменты, которые «снимают» простые показатели, но делают это достаточно надежным образом — так, что обеспечивается повторяемость результатов. Например, в сообществах пользователей MySQL стандартным стал инструмент Sysbench, высчитывающий показатели ввода-вывода, работы с потоками и семафорами, загрузки процессора, а также своеобразную метрику, названную oltp. Пользователи Oracle Database используют ряд встроенных и внешних инструментов для измерения производительности процессора, памяти, подсистемы ввода-вывода на условно-максимальных нагрузках, среди которых самый полный инструмент — Peakmarks Benchware.

Атомизация метрик

А чем сегодня могут похвалиться производители машин баз данных — предконфигурированных аппаратно-программных комплексов с тщательно откалиброванной и готовой к промышленным нагрузкам СУБД? Лишь компания Teradata еще в 2003 году последний раз публиковала результаты тестов TPC-H, но при этом ее машины поставляются со встроенным инструментом замера некоторого «внутреннего QphH», обозначаемого как tPerf. В машинах Pure Data for Operational Analytics от IBM среди «паспортных показателей» можно встретить количество операций ввода-вывода (IOPS) на SQL-нагрузке, пропускную способность на SQL-нагрузке, скорость загрузки данных в терабайтах в час. Похожие показатели публикуются в «паспорте» на машины Exadata от Oracle — их флагманский комплекс X6-8 стремится впечатлить потенциального клиента небывалыми 4,13 млн SQL IOPS и пропускной способностью 350 Гбайт/с на SQL-нагрузке. Как проверить эти показатели несколькими разными способами для Oracle Database, знает любой администратор: имеется встроенный PL/SQL-пакет от Oracle, есть Benchware, а такие инструменты, как Orion и SLOB, позволяют прикинуть будущий SQL IOPS на системе хранения без установки СУБД.

Возникает вопрос: если ключевые производители комплексов с СУБД считают такие атомарные показатели, как IOPS, информативными и если их можно получить относительно понятным путем, то почему бы не взглянуть на них пристальнее? Действительно, в условиях хорошо утилизируемой процессорной мощности и высокого параллелизма количество IOPS, которые способна обеспечить СУБД, оказывается самым критическим показателем для транзакционной нагрузки и должно коррелировать с tpm и tps (при условии достаточно низкого времени отклика на максимальных нагрузках). Для аналитической нагрузки, для которой важно не столько количество операций (размеры блоков в таких базах данных, как правило, делают большими), сколько объемы «прокачиваемых» гигабайтов, «пропускная способность на SQL-нагрузке» оказывается зачастую более показательной, чем число непонятно каких запросов в час. Однако этот тезис уязвим: работа с подсистемой хранения в разных СУБД реализована принципиально по-разному (да и не все СУБД оснащены собственным менеджером томов и работают напрямую с блочными устройствами), поэтому одно и то же число SQL IOPS для разных СУБД будет означать разное количество транзакций в минуту. Кроме того, различные СУБД по-разному работают и с подключениями, что также немаловажно. Много вопросов появляется и к стандартизации инструментария: если понятно, как измерять IOPS для Oracle Database, IBM DB2 и Microsoft SQL Server, то для большинства прочих СУБД готовых инструментов нет. Но, как бы то ни было, подход заслуживает внимания хотя бы в силу того, что он потенциально универсален, а его полюсы — IOPS и пропускная способность — позволяют оценить качество выполнения нагрузок двух больших противостоящих категорий: часто записываемые небольшие порции данных и чтение больших объемов с аналитической обработкой.

***

Предлагая присмотреться к атомарным показателям ввода-вывода на специфической для обработки данных нагрузке, хочется также выразить надежду на возвращение к жизни тестов TPC — чрезвычайно трудно будет вновь собрать столь же авторитетную организацию, обеспечивающую методическую чистоту тестов и беспрекословную надежность опубликованных результатов. Есть также надежда на то, что проблема сложности работы с тестами преодолима и среди результатов tpc.org мы еще увидим данные по открытым СУБД. Ведь кому, как не им, конкурировать по стоимости транзакции с коммерческими?

За рамками рассмотрения остались специфические для тиражируемых приложений эталонные тесты, такие как SAPS (на модуле SAP SD), SAP BW-EML, стандартные бенчмарки Oracle e-Business Suite, тесты для Microsoft Dynamics AX. Результаты их выполнения иногда публикуются, однако их применимость ограничивается самими этими системами без учета расширений (да и СУБД в этих конфигурациях не обязательно является узким местом). Тем не менее сам подход, когда в основу эталонного теста ложится реальная нагрузка от реального приложения, перспективен, и популярность графового Linkbench тому свидетельство.

Еще одной примечательной тенденцией в условиях больших горизонтально масштабируемых систем становится акцент в тестировании не столько на производительности, сколько на корректности функционирования. Яркий представитель тестов нового поколения — Jepsen, которым были продемонстрированы потери данных в кластерах под управлением MongoDB, Redis и RethinkDB. Важно, что сам автор этих тестов настаивает на том, что не стоит их применять для оценки производительности (хотя метрические показатели в них снимаются) и что это только «проверка на слом». Но поскольку и производительность имеет смысл сравнивать лишь в одинаковых «классах разрушимости», то проработка такого рода проверок на корректность функционирования становится важнейшим направлением в деле построения эталонного теста для современных СУБД.

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

Литература

1. Леонид Черняк. Снова о тестах TPC // Открытые Системы.СУБД. – 2000. – № 11. – С. 34-36. URL: https://www.osp. ru/os/2000/11/178309 (дата обращения: 18.05.2017).

2. А.А. Волков. Тесты TPC // СУБД.– 1995. – № 2. С. 70-78. URL: https://www. osp.ru/dbms/archive/1995/02 (дата обращения: 18.05.2017).

3. Alan Parker. Tuning Databases on Solaris Platform. NJ: Prentice Hall, 2001, ISBN:0130834173.

4. V. Abramova, J. Bernardino, P. Furtado. Experimental Evaluation of NoSQL Databases // International Journal of Database Management Systems (IJDMS). – 2014. Vol. 6, No. 3 (June). DOI:10.5121/ijdms.2014.6301.

Статья Андрей Николаенко, «Эталонные тесты СУБД: что было, что стало, что будет» републикуется с разрешения издательства «Открытые системы» (www.osp.ru). Все права сохранены.