AzulДоброго времени суток
вопрос может показаться тупым и дилетантским, прошу сильно не травить
суть в чем? я работаю в крупном коммерческом банке, и как сами понимаете объем операций, и как следствие записей в БД
очень большой. Ну на вскидочку миллионов 300 уникальных записей в год.
Банк работает уже 20 лет, следовательно речь идет о 6 миллиардах записей в БД.


6 миллиардов записей для современных СУБД -- немного. Для специальных, конечно, СУБД, в основном это columnstore, не MSSQL и не Oracle, про Exadata не знаю.


AzulСейчас необходима общая база по всем операциям которые раскиданы по разным системам автоматизированных банковских дней.


Так смотря что с этими данными надо делать.
Вы-то это не раскрываете, а от людей просите совета. А это ОЧЕНЬ зависит от того, что надо с данными делать.

AzulПригласили одну фирму, которая предложила за очень хорошие деньги этот проект реализовать.
Реализовать на базе решения Oracle Exadata, и как они расписывают - что даже огромные запросы - к примеру выписки за 10 лет будут крутиться за секунды.


Кому нужны выписки за 10 лет ?

У меня была БД в 55 милиардов записей, и запросы некоторые по ней проходили за несколько сот миллисекунд.
Это конечно кластер был из 8 нод, но для масштаба можно 55 на 8 поделить.
Но это были запросы на выборки, или точечные (маленькие) аргрегации.
Если нужна агрегация данных за 10 лет без доп. фильтров -- это большие объёмы, и это сделать быстро, естественно, невозможно.
Тогда решения -- предагрегации (но теряется универсальность и растут объёмы), или ещё что-то, но магии там всё равно нет.
Вы должны понимать, за счёт чего это будет достигаться, если не понимаете, или вам не могут объяснить -- значит, врут.

Azul Благодаря сохранению часто запрашиваемых данных в флеш памяти, аппаратной компрессии и т.д.


Кэши работают и в обычных СУБД, они не решают тут. нужны другие технологии ещё сверх этого.
Компрессия -- да, это здорово. Аппаратная или программная -- в общем, неважно.

AzulЯ хотел спросить - а что действительно решения Оракл такие быстрые и оптимизированные?


Это не решение Оракл, это решение Exadata. Но, ещё раз, если вам чего-то говорят, они должны уметь объяснить, за счёт чего
это происходит.
Ну и очень сильно это зависит и от данных, и от запросов, которые надо делать.

AzulПо производительности неужели MSSQL так сильно отстает?


Он не отстаёт, MSSQL -- это универсальная СУБД, ориентированная на OLTP и , с некоторыми добавками, на OLAP.
Но для больших хранилищ данных она просто не подходит.

Там вот Vertica, Exadata, Teradata, ещё может быть что-то.

Кстати, на таких объёмах можно попробовать тот же Virtuoso, он есть в бесплатном OpenSource -варианте (6ая версия),
но без кластера (а тут он не нужен, это как раз типичный объём БД для безкластерного решения).
Или ещё есть MonetDB (тоже бесплатный).
Ну и ещё дофига всяких есть решений, бесплатных. Т.е. в принципе можно пробовать и другие "более дешёвые" решения.
Но естественно со всеми надо будет РАБОТАТЬ, т.е. разбираться досконально в предметной области и постановке, и
в технологиях конкретной СУБД.


AzulВообще есть ли отставание или все эти прогнозы насчет нескольких секунд достигаются за счет аппаратной составляющей?


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

Я думаю, что скорее инженеры Экзадаты просто выпендрились, имея возможность сделать что-то аппаратно, и оно там хоть и
ускоряет само сжатие раз в 100, но всё же в СУБД основные затратные операции -- это чтение диска и сканирование данных, они в 1000-10000 раз затратнее, чем любое сжатие в памяти (на чём и стоит отрасль columnstore).
Возможно, я неправ.

Сори, ещё из решающих технологий надо, естественно, указать параллельные и распределённые вычисления.

[quot alexeyvg]Да какие тут большие объёмы?
Действительно:MasterZiv6 миллиардов записей для современных СУБД -- немного

Обычные СУБД, я бы сказал, работают с БД до миллиарда записей. Конечно, всё ещё сильно зависит от задач.


MasterZivКстати, MSSQL тоже с некоторых пор columnstore, не знаю, как там у Oracle с этим.

Ну, возможно, тогда и MSSQL можно попробовать.

AzulСпасибо огромное за ответы,
дело в том что на вскидочку все решение аппаратная составляющая + решение компании + лицензия будет стоить 1,5 - 2 млн. долларов
это многовато...
суть вопроса - можно ли реализовать это гораздо дешевле и приближенно по производительности


Можно точно. Тем более за такие деньги.

Azulа что делать с данными?
ну во первых их нужно собрать из разрозненных источников (базы MSSQL, DBF файлы, текстовые файлы и т.д.)
затем каждый раз подкачивать из схожих источников
затем из них должны формироваться отчеты


Это всё можно.

А вот это :

Azulеще они должны быть доступны через пользовательский интерфейс (пользователи не программисты) для формирования отчетов и составления новых отчетных форм

-- утопия. Без программистов ничего не работает никогда. Вам будут конечно всякие sales man ы лапшу на уши вешать, но не слушайте.