База размером 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 терабайтом данных, без индексов.
  2. Создать первичные и вторичные ключи с соответствующими индексами – таким образом база данных будет больше 1 терабайта.
  3. Собрать статистику по базе данных.
  4. Выполнить ряд запросов для определения производительности.

Кто больше?
Есть несколько компаний с действительно большими базами данных на 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 миллионов записей)

Итог

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

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

Подпишитесь на новости Firebird в России

Подписаться