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

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

Программы

Операционная система 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 мегабайт памяти.

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

Общее время загрузки данных

Индексы Статистика После этого мы собрали статистику по базе данных. Это заняло 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 Примечание: символ "–" в ячейках означает, что данные не были замеряны. Запросы

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

📎📎📎📎📎📎📎📎📎📎