База размером 1 терабайт на Firebird

iBase.ru, IBSurgeon, 22.06.2009.

English text
Более подробное техническое описание теста, как это происходило

Зачем вообще создавать терабайтную базу данных на Firebird?

С каждым годом все больше и больше компаний используют СУБД Firebird как основную СУБД для хранения и обработки данных. На конференциях "Корпоративные базы данных" мы несколько лет подряд (2003-2007) приводили данные по средним объемам таких баз данных, и показывали ежегодный рост максимального объема хранимых данных. В настоящий момент это сотни гигабайт, объемы продолжают расти (см. врезку "Кто больше?"), и легко предсказать момент, когда эти базы данных станут в 2, 3 или 5 раз больше. Соответственно, администраторы и разработчики заинтересованы в изучении вопроса, как Firebird ведет себя на больших объемах данных, и как такими объемами управлять.

Также важной причиной, по которой мы провели этот тест, является расхожее мнение, что Firebird годится только для "небольших баз данных". Этот миф уже давно мертв, но некоторые аналитики и журналисты все еще упоминают его. Мы считаем, что наш тест поставит окончательный крест на этом мифе.

"Железо"

Firebird известен своей масштабируемостью, и тест подтвердил это целиком и полностью. Целью теста было только создать базу данных размером в терабайт, и мы намеренно для этого использовали обычный десктопный компьютер:

Процессор AMD Athlon 64 x2 5200
Память 4GB, (2 Samsung, 2 Huyndai)
Материнская плата MSI K9N Platinum
HDD1, операционная система и temp Seagate ST3160815AS, 160Gb, SATA II
HDD2, temp Firebird Hitachi HDT721064SLA360, 640Gb, SATA II
HDD3, база данных Seagate ST31500341AS, 1.5Tb, SATA II, (FW CC1H)

То есть, мы просто подключили диск размером 1.5Tb на офисный десктоп, без каких-либо модификаций. Этот диск был отформатирован с размером кластера 16 килобайт, аналогичным размеру страницы БД).

Программы

Для теста мы использовали загрузчик из теста TPC-C (можно скачать отсюда http://ibdeveloper.com/tests/tpc-c/). Необходимо отметить, что этот загрузчик добавляет данные небольшими порциями во все таблицы по очереди, примерно так, как обычно происходит формирование заказов в нормальных системах.

Операционная система Windows XP Professional SP3, 32bit
Firebird 2.1.3 SuperServer (snapshot)
Загрузчик: написанный еще в начале 2000 годов загрузчик tpc-c.

План

План теста состоял в следующем:

Создать базу данных и наполнить ее 1 терабайтом данных, без индексов.
Создать первичные и вторичные ключи с соответствующими индексами – таким образом база данных будет больше 1 терабайта.
Собрать статистику по базе данных.
Выполнить ряд запросов для определения производительности.

Кто больше?
Есть несколько компаний с действительно большими базами данных на Firebird. Здесь приведены только три, как примеры из разных ключевых индустрий – розница, финансы и медицина.
Bas-X
Bas-X (http://www.basx.com.au/, Австралия) является ведущим поставщиком программного обеспечения для независимых продавцов, как правило с несколькими точками продаж и управляющих групп. У двух клиентов, использующих программное обеспечение Bas-X, базы данных имеют размер 450 гигабайт, у ряда других – более 200 гигабайт.
Интересно, что Bas-X поставляет свое ПО как сервис и использует Firebird для систем с тысячами пользователей. Это действительно яркий пример предложения "облачных вычислений", и в нем используется Firebird, который отлично подходит для этой тяжелой задачи.
Watermark Technologies
Watermark Technologies (http://www.watermarktech.co.uk/, Великобритания) использует Firebird в системах финансового и государственного секторов.
ПО Watermark Technologies использует Firebird для управления документами с индексированием OCR и полнотекстовым индексированием. ПО используется финансовыми консультантами, страховыми компаниями и т. д. Некоторые базы данных этих систем имеют размер выше 300 гигабайт.
Бесплатная лицензия Firebird является одним из преимуществ, которое позволило Watermark Technologies предложить гибкую модель подписки для своих клиентов, с оплатой по мере использования.
ПрофитМед
ЗАО ПрофитМед (http://www.profitmed.net/, Россия) является одним из крупнейших фармацевтических дистрибуторов. Размер их базы данных не такой большой (~50Gb), но мы решили упомянуть их потому, что система работает в режиме высокой нагрузки, обслуживая одновременно более 300 пользователей. В этой базе данных хранятся в основном числовые данные: товарные номера медикаментов, движение товаров и т. п., и благодаря сжатию, которое используется в Firebird, база данных является достаточно компактной.

Конфигурация БД и Firebird

Размер страницы БД 16384 байт, такая же как и кластер диска, для максимальной производительности ввода-вывода (1 операция чтения-записи на 1 страницу БД). В firebird.conf мы изменили параметр TempDirectories, чтобы он указывал на отдельный диск HDD2, размером 640 гигабайт, на котором было свободно ~300 гигабайт. Параметр DefaultDbCachePages = 8192, при этом SuperServer будет занимать ~140 мегабайт памяти.

Загрузка данных

Данные загружались порциями, т. к. компьютер использовался для работы, и нужно было предусмотреть небольшие перерывы в загрузке данных. Во время загрузки данных в течение дня производилась обычная работа сразу с 8-12 программами, запущенными одновременно – Word, Excel, Firefox, Chrome, TheBat, Delphi 2007, и т. д. Если бы мы выделили компьютер специально для теста, то загрузка была бы немного быстрее, поэтому скорость загрузки данных не является максимальной.

Общее время загрузки данных ~70 часов
Всего записей вставлено: 6.2 миллиарда
Средняя скорость вставки: 24500 записей в секунду, если считать вставку непрерывной
Средний размер записи: 146 байт (минимально 13 байт, максимально 600 байт)
Транзакций 646489

То есть, на вставку было потрачено четверо суток, после чего у нас получилась база данных с размером 1 терабайт (чуть больше – 1 099 900 125 184 байт). Ниже можно наблюдать рост размера базы данных и динамику транзакций в FBDataGuard Viewer:

Индексы

Мы создавали индексы по очереди, поштучно, и замеряли время создания и размер промежуточного файла сортировки в temp. Самый большой индекс получился по самой большой таблице ORDER_LINE, разумеется. Это первичный ключ, состоящий из четырех столбцов (smallint, smallint, integer и smallint). Временный файл для сортировки индекса занял 182 гигабайта, и в базе данных индекс занял 29.3 гигабайт.
Интересно, что индекс по таблице с 3.8 миллиардами записей имел глубину 3 (т.к. размер страницы был 16к), так что объем ввода-вывода при поиске по этому индексу был в норме.

Статистика

После этого мы собрали статистику по базе данных. Это заняло 7 часов 32 минуты 45 секунд. В следующей таблице приведена общая статистика с дополнительными данными:

Таблица	Записей	Размер, Гб	Время select count(*)	Время создания индекса	Размер temp-файла, Гб	Размер индекса в БД, Гб
WAREHOUSE	12400	0.002	0s	0	0	0.0
ITEM	100000	0.012	0.7s	–	–	0.0
DISTRICT	124000	0.017	0.7s	6s	–	0.0
NEW_ORDER	111 600 000	32	20m 00s	23m 00s	4.56	0.8
CUSTOMER	372 000 000	224		41m 00s	–	2.6
customer_last				1h 52m 32s	12.4	2.3
fk_cust_ware				2h 10m 51s	–	2.3
HISTORY	372 000 000	32
ORDERS	372 000 000	25	32m 00s	45m 41s	15.2	2.5
STOCK	1 240 000 000	404		3h 34m 44s	41.5	9.2
ORDER_LINE	3 720 051 796	359		12h 6m 18s	182.0	29.3

Примечание: символ "–" в ячейках означает, что данные не были замеряны.

В более полном отчете будет приведена ссылка на статистику по базе данных для IBAnalyst и FBDataGuard.

Запросы

Первоначально, мы выполнили запросы select count(*) на некоторых таблицах (см. 4-ый столбец в таблице выше). Как вы знаете, из-за многоверсионности при select count(*) Firebird вынужден читать всю таблицу целиком, и это является достаточно "тяжелой" операцией для сервера. Обычно разработчики не выполняют select count, тем более на таблицах такого размера, но мы это сделали специально, чтобы оценить производительность Firebird и дисковой подсистемы, а также чтобы вы могли использовать эти данные для сравнения.

Также мы выполнили ряд запросов и, если честно, были удивлены хорошей производительностью:

Запрос	План и статистика	Описание
select w_id, w_name, c_id, c_last from WAREHOUSE, customer where c_w_id = w_id	PLAN JOIN (WAREHOUSE NATURAL, CUSTOMER INDEX (FK_CUST_WARE)) ------ Performance info ------ Prepare time = 15ms Execute time = 79ms Avg fetch time = 6.08 ms Current memory = 272 264 476 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 82 Writes from cache to disk = 0 Fetches from cache = 3 648	Простое объединение таблиц с 12400 и 372000000 записями. Avg fetch time = 6.08мс – это время выборки первой записи
select w_id, w_name, c_id, c_last from WAREHOUSE, customer where c_w_id = w_id and c_w_id = 10000	PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Performance info ------ Prepare time = 16ms Execute time = 78ms Avg fetch time = 6.00 ms Current memory = 272 266 148 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 88 Writes from cache to disk = 0 Fetches from cache = 3 656	Объединение этих же таблиц с дополнительным условием по отбору warehouse N 10000
select count(*) from WAREHOUSE, customer where c_w_id = w_id and c_w_id = 10000 Result = 30000	PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Performance info ------ Prepare time = 0ms Execute time = 453ms Avg fetch time = 453.00 ms Current memory = 272 263 844 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 1 048 Writes from cache to disk = 0 Fetches from cache = 60 024	Подсчет количества записей, выдаваемых предыдущим запросом (30 тысяч)
SELECT * FROM ORDER_LINE WHERE OL_W_ID = 500	PLAN (ORDER_LINE INDEX (ORDER_LINE_PK)) ------ Performance info ------ Prepare time = 0ms Execute time = 94ms Avg fetch time = 7.23 ms Current memory = 136 445 536 Max memory = 136 592 176 Memory buffers = 8 192 Reads from disk to cache = 150 Writes from cache to disk = 0 Fetches from cache = 2 402	Запрос к самой большой таблице (3.7 миллиарда записей), фетч (выборка) только первых записей.
SELECT * FROM ORDER_LINE WHERE OL_W_ID = 500	PLAN (ORDER_LINE INDEX (ORDER_LINE_PK)) ------ Performance info ------ Prepare time = 0ms Execute time = 3s 438ms Avg fetch time = 0.01 ms Current memory = 136 445 496 Max memory = 136 592 176 Memory buffers = 8 192 Reads from disk to cache = 1 840 Writes from cache to disk = 0 Fetches from cache = 598 636	Повторный запрос с выборкой всего результата на клиента (299245 записей)
select w_id, w_name, c_id, c_last from WAREHOUSE, CUSTOMER where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000)	PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Performance info ------ Prepare time = 0ms Execute time = 125ms Avg fetch time = 9.62 ms Current memory = 272 270 824 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 91 Writes from cache to disk = 0 Fetches from cache = 3 659	Еще одно объединение, с указанием диапазона выбираемых warehouse
select count(*) from WAREHOUSE, customer where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000) Result = 59 970 000	PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Performance info ------ Prepare time = 0ms Execute time = 13m 4s 718ms Avg fetch time = 784 718.00 ms Current memory = 272 268 532 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 2 332 583 Writes from cache to disk = 0 Fetches from cache = 119 977 902	Подсчет количества записей, возвращаемого предыдущим запросом (~60 миллионов записей)

Итог

По нашему мнению, результаты этого эксперимента следующие:

Без сомнения, Firebird может работать с большими базами данных. На соответствующем оборудовании вполне можно было бы создать базу данных размером 32 терабайта и получить такую же производительность.
Отличное масштабирование при минимальных затратах. Терабайтная база данных создана на обычном настольном компьютере и с ней вполне можно работать, если, разумеется, не выбирать на клиента миллионы записей или не делать select count(*) по таблицам размером в сотни гигабайт. При этом скорость выполнения поиска и объединений такая же, как на базах данных среднего размера (10-15 гигабайт).

Эксперимент еще не закончен, мы сохранили эту базу данных и в дальнейшем выполним над ней ряд других тестов, включая многопользовательские, соберем статистику и также опубликуем эти данные.

Вопросы и пожелания присылайте на terabyte@ib-aid.com и support@ibase.ru.