Владимир Иванов
У меня как у инженера 10-летний опыт работы на различных SQL-серверах. Для себя я сделал вывод, что современные SQL-сервера способны вытягивать SQL-запросы в 10-20 млн. фактов, далее жестокий даун, что у MS SQL, что у Oracle.

Константин Лисянский Oracle и MS SQL - СУБД, которые разрабатывались для транзакционных систем. Ничего удивительного, что они не справляются с нагрузками, типичными для хранилищ данных. Для этого специальные СУБД надо использовать. Тем более, если речь о рознице идёт.


А вот экспериментальные данные:
select count(*) from sales_fact_1997
28,962,208 строк (68 секунд)

(перезагрузка сервера)
select count(*) from sales_fact_1997
WHERE product_id = 1
and time_id = 741
and customer_id = 614
and store_id = 17 (111 секунд)

create index sales_fact_1997_product on sales_fact_1997(product_id)
(416 сек)
select count(*) from sales_fact_1997
WHERE product_id = 1
and time_id = 741
and customer_id = 614
and store_id = 17
(61 сек)

create index sales_fact_1997_time on sales_fact_1997(time_id) (393 сек)

select count(*) from sales_fact_1997
WHERE product_id = 1
and time_id = 741
and customer_id = 614
and store_id = 17
(3 сек)


Теперь - о железе. Athlon XP 2500+ (Barton), 1 Gb ОЗУ PC-2700, EIDE Western Digital JB-800 (и Ось и СУБД - на одном диске. Своп - на нем же). Ось - Windows 2003 AS.

Как видим, уже простое индексирование в MS SQL 2000 на, простите, персоналке, дает неплохой результат, да и без индексов стопором результат не назовешь). А еще до Oracle и bitmap индексов не добрались... Это так, к слову о "пределах стандартных РСУБД".

Вообще говоря, приведенные выше данные были получены на подготовительном этапе тестирования Opteron - в 32-х и 64-х битных режимах. У кого будет интерес - пишите, вышлю ссылку.

олапист добавлять в запрос join'ы ко всем измерениям не забываем, не забываем

select /*+ INDEX(sales_fact_1997 sales_fact_7_by_time_bit) */ sum (store_sales) store_sales_total,
sum (store_cost) store_cost_total,
sum (unit_sales) unit_sales_total
from sales_fact_1997 t
where time_id in
(select time_id from "time_by_day" t where
(the_day = TRANSLATE('Saturday' USING NCHAR_CS) or the_day = TRANSLATE('Sunday' USING NCHAR_CS)))

10,926 сек.

Это уже на Opteron (2 проца, 6 Гб ОЗУ, но диск даже медленее), Oracle-64, bitmap-индексы использованы.

В целом же мы тестировали не СУБД, а Opteron-ы, и надо сказать, что во время тестов пришлось увеличить таблицу фактов ровно в 8 раз, иначе все было совсем уж неубедительно...

Константин Лисянский
/*+ INDEX(sales_fact_1997 sales_fact_7_by_time_bit) */
А без этого слабо?
DmitrySЭто коммент:-)

Пошел офф-топ...

Нет, не слабо. Я просто скопировал из протокола тестов первый запрос, попавший под руку.

Сам же хинт возник вот как. Тестируя Opteron-ы на 6 GB, мы обнаружили, что 28 Мегастрок маловато будет. Поэтому накатили еще таблицу на 28х8 Мегастрок. К чему я это? Тестируя самые разнообразные возможности, обнаружено в частности, что на 28 Мстрок выборка по ключу в 5 раз эффективнее сканирования таблицы, а вот на 28х8 - наоборот, сканирование таблицы оказалось раза в три эффективнее.

Это так, к слову о селективности ключей...

олапистну вы все же вот это попробуйте для большей убедительности:

SELECT "store"."store_id", "time_by_day"."the_year", "time_by_day"."quarter", "time_by_day"."month_of_year", "product"."product_id", "promotion"."media_type", "promotion"."promotion_name", "customer"."customer_id", "customer"."education", "customer"."gender", "customer"."marital_status", "customer"."yearly_income", "sales_fact_1997"."unit_sales", "sales_fact_1997"."store_cost", "sales_fact_1997"."store_sales", "sales_fact_1997"."product_id", "sales_fact_1997"."store_sales"-"sales_fact_1997"."store_cost" FROM "sales_fact_1997", "store", "time_by_day", "product", "promotion", "customer" WHERE ("sales_fact_1997"."store_id"="store"."store_id") AND ("sales_fact_1997"."time_id"="time_by_day"."time_id") AND ("sales_fact_1997"."product_id"="product"."product_id") AND ("sales_fact_1997"."promotion_id"="promotion"."promotion_id") AND ("sales_fact_1997"."customer_id"="customer"."customer_id")
Не понял, что Вы хотите получить в итоге? Все 28 миллионов строк на клиенте? Так это нужен клиент "правильный". Или первую строку, удовлетворяющую условию?

Запускаю такой вот запрос, созданный на основе предложенного и одного из моих:
PiSELECT
"store"."store_id", "time_by_day"."the_year", "time_by_day"."quarter", "time_by_day"."month_of_year",
"product"."product_id", "promotion"."media_type", "promotion"."promotion_name", "customer"."customer_id", "customer"."education",
"customer"."gender", "customer"."marital_status", "customer"."yearly_income", "sales_fact_1997"."unit_sales", "sales_fact_1997"."store_cost",
"sales_fact_1997"."store_sales", "sales_fact_1997"."product_id", "sales_fact_1997"."store_sales"-"sales_fact_1997"."store_cost"
FROM "sales_fact_1997", "store", "time_by_day", "product", "promotion", "customer"
WHERE ("sales_fact_1997"."store_id"="store"."store_id")
AND ("sales_fact_1997"."time_id"="time_by_day"."time_id")
AND ("sales_fact_1997"."product_id"="product"."product_id")
AND ("sales_fact_1997"."promotion_id"="promotion"."promotion_id")
AND ("sales_fact_1997"."customer_id"="customer"."customer_id")
AND ( "customer"."account_num" = 94933843612.0)
AND ("time_by_day"."the_date" = '1998-01-10')
AND ("store"."store_name" = 'Store 17')
107 секунд и 1232 строки результата под MS SQL (в описанной выше конфигурации Athlon).
Так что, по прежнему Владимир Иванов У меня как у инженера 10-летний опыт работы на различных SQL-серверах. Для себя я сделал вывод, что современные SQL-сервера способны вытягивать SQL-запросы в 10-20 млн. фактов, далее жестокий даун, что у MS SQL, что у Oracle.

?

Владимир ИвановВы знаете у MS SQL есть способ делать
select count(*)
фактически моментально на любом объеме данных. Но это уже вопрос к шаманам MS SQL.
select count(*) фактически моментально на любом объеме данных - это да, достаточно иметь ключ на таблицу. Но здесь же, в этой ветке, демонстрировался не только select count(*) и нет только на MS SQL...

Запросы наглядно показали, что при достаточном объема памяти указанные Вами размеры базы данных
Владимир Ивановв 10-20 млн. фактов
не выглядят пугающе, а уж тем более не вызывают
Владимир Ивановжестокий даун, что у MS SQL, что у Oracle

Я не случайно указывал на то, что конечная цель моего тестирования были Opteron, т.е. процессоры, которые дают возможность сохранить наработанное ПО и постепенно перейти в архитектуру 64-х бит. Я прогнозирую в течении двух лет "обвальное" увеличение памяти только в домашних компьютерах до 2-4 Гиг - благодаря платформе AMD-64. А это значит, что для в однопользовательской среде запросы к неиндексированной базе данных на миллионы записей будут занимать десятки секунд, в индексированных - секунды.

Владимир Иванов
Рассматривать AMD-системы даже как тестовые для серверов. Мда...

Кому как. Выбор серверной платформы - сугубо личное дело:
Четырехпроцессорные серверы корпорации Hewlett-Packard на базе AMD Opteron™ гарантируют исключительную производительность
Процессор AMD Opteron™ станет базовой платформой для новых мощных корпоративных серверов и рабочих станций Sun
Rambler работает на процессорах AMD
Процессоры AMD Opteron™ становятся базовой платформой нового центра корпоративных приложений Fujitsu Systems Europe
Процессоры AMD OPTERON™ становятся основой кластерного решения швейцарского федерального технологического института
Суперкомпьютер под номером 6, построенный компанией Linux Networx для Национальной лаборатории в Лос-Аламосе, стал лучшим в списке Top500 среди систем на базе процессора AMD Opteron
Для кластерного суперкомпьютера выбран AMD
Университет штата Юта выбирает процессор AMD Opteron™ и решение ANGSTROM MICROSYSTEMS для самого большого в Юте компьютера Национальная лаборатория в Лос-Аламосе выбирает процессор AMD Opteron™ для моделирования системы национальной обороны США
Процессоры AMD Opteron™ будут использоваться для создания одного из мощнейших суперкомпьютеров мира Dawning 4000A

Выбор можно было бы и продложить, но я только добавлю, что указанный в конфигурации Athlon XP 2500+ - это не сервер, а мой персональный офисный компьютер. ;)

В целом я рассматриваю наш обмен мнениями как беседу, в которой каждому есть что сказать. Конечно, лучше говорить фактографически, поскольку наша отрасль меняется очень быстро, чему я личный свидетель еще с 1979 года, когда набивал курсовую на перфокартах на "электронном богатыре" ЕС-1022 :)

Thank you!

OR Pi Не понял, что Вы хотите получить в итоге? Все 28 миллионов строк на клиенте?

Это запрос, которая посылается на сервер при процессинге кубика.

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

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

Или я не прав?

Продолжая страую тему - производительность серверов (в том числе в рознице).

Мои тестовые данные, приведенные выше, возникли во время подготовки статьи Анализ консолидированных данных: тестируем платформу AMD Opteron .

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

Второй момент. В ходе демонстрации серверов на Opteron мы столкнулись с заказчиком (украинская розничная сеть), утверждающим что вот приезжали спецы от Cognos в одну украинскую торговую сеть где-то летом 2004 г. , попытались открыть проект - и неудача! Продукт не прошел предложенное тестирование:

1. Как сервер кубов он не справился - не смог за сутки постоить куб на базе заказчика. Заказчик собственными силами на MS AS успевает построить куб за ночь на том же железе и той же базе.

2. Как клиент продукт тоже не подошел - не получился доступ к виртуальным кубам MS AS (см. выше)

По первому пункту просьба откликнуться, кто что знает. У меня подозрение, что у заказчика база не совсем стандартная, поскольку объем ее составляет около 200 миллионов записей (около 20 за квартал).

Владимир Иванов2Birkhoff. Просто у Oracle аварийно-усточивый кластер и кластер для создания многосерверного паралеллизма одно и тоже.
У MS и Терадата это не так. Отдельно кластер сверхпараллелизма и отдельно аварийно-усточивый кластер (failover cluster). Можно 2 кластера использовать отдельно, можно не использовать любой на выбор.
Кластер Oracle дает выйгрыш до 30% при переходе от 1й ноды к 3м. Кластер MS дает тут примерно 300%. Однако кластер Oracle можно подложить под SAP R3, а кластер MS нет. Правда по SAP Benchmark лидирует MS SQL и без кластеров.

Владимир, Вы так уверенно приводите цифры, что аж не хватает духу Вам не поверить. Но, помня Гитлера - Чем больше ложь, тем охотнее в нее верят , - мне хотелось бы спросить, откуда цифры то?

Вот, к примеру, что пишет Oracle:
http://dsvolk.msk.ru/oracle/rac/FederatedvsClustered.pdf?PHPSESSID=c0bd5ed7c789fd5e428a2d20c3ded32fFederated databases cannot scale when
queries access data by alternate keys that
are not the partitioning key

Consider a 10-node federated database with a DPV on the Employee table with columns (Employee Number Primary Key, Email, …). A basic OLTP query on an alternate key, such as SELECT * FROM Employee WHERE EMAIL =
‘joe.smith@acme.com’ will be broadcast to all 10 nodes, although it will return only one record. As you add nodes (go from 10 nodes to 12, say) this query will
perform worse, since it will now require responses from 12 nodes instead of 10. This behavior of federated databases is not a function of the quality of
implementation; it is inherent in the architecture. In contrast, even early 90’s versions of shared-disk clusters (such as IBM DB2-Sysplex for the Mainframe and Oracle Parallel Server) scaled up very well on
alternate-key access for read-mostly workloads. And Oracle9i Real Application Clusters scales up very well on alternate-key access for the read-write workloads
typical of OLTP.

Владимир Иванов

В к слову зря о TPC как о неком формальном тесте. Тест TPC эмулирует не некий академический тест. TPC это модель работы очень крупной торговой компании (ордер, оплата и т.д.). Таким образом, это модель тех самых крупных розничных сетей, где раньше все укладывала Терадата+MicroStrategy. Падение Терадаты ниже пола показывает, причем имеено на задачах целевого сегмента рынка, что универсальные SQL-сервера победили. Терадата вероятно замечательная система, но это уже прошлое.


Владимир, извините за вставки 5-ти копеек много месяцев спустя, но просто к сведению TPC - это тесты серверов. Не СУБД.

Мне, как работающему с ERP системами (по 1 000 - 30 000 объектов в базе), трудно понять, как можно судить о "скорости" СУБД только по тесту на 5-7 таблицах, причем в режиме на вставку записей.

Да, тест TPC говорит о многом, но не о всем. Например, тот же MS SQL хорошо продавался задолго, как он стал лидером этого теста, но и его продажи не подскочили до потолка после того, как он вырвался на самый наверх.

Не берусь утверждать, но по слухам долгожданный Yukon не дал скачка производительности, но зато приблизился к Oracle по самой базовой функциональности - из чистого "блокировщика" появились элементы "версионника" (Правда, я говорю это с чужих слов).

Так что не стоит прогнозировать чью-то смерть - базы всякие нужны, базы всякие важны.