Re: очень хочется squirrelsh
> Сравнивать оракл
> и постгрес смысла не имеет, а вот постгрес и эскулайт - вполне.
+1000
Для каждого продукта есть своя область применения. «Универсальность» не говорит о применении всегда и во всем (даже возможность этого применения).
Возьмем для примера запрос из жизни – получить данные на/за определенный период, дополнительные условия для простоты ставить не будем. Создадим вьюшки.
Имеем: небольшую БД на пару десятков Гб, искомые данные есть объединение нескольких таблиц (ну не обрывки же нормализованных таблиц получать). В операции принимают участие 5-6 таблиц, часть «легких» (справочных) часть продуктивных (в среднем по 10 млн. записей на таблицу).
И так, говорим – «нам надо выбрать из середины 50 записей» (утрировано конечно, но что бы не парится с датами).
Предусловия:
Есть СУБД с полностью идентичной структурой (максимально возможно с учетом разных СУБД)
Firebird, PostgreSQL, MySQL, DB2, MS SQL, Oracle – все версии «свежие» (на лето 2009 года).
Все (за исключением MS SQL, которая имеет версию 2008 и работает на таком же железе но под управлением Windows 2008) работает под управлением Debian на серверном железе (в стойке).
Клиенты отсутствуют (за исключением машины с которой запускаются тесты).
В общем, цель поста не «официально» показать результаты, ибо нет возможности сейчас эти цифры тут выложить.
При первом запросе самым медленным оказался MS SQL самым «быстрым» Oracle. При повторных запросах, в лидерах остались PostgreSQL & Oracle & Firebird (!!!). При наложении условий на вьюшки Firebird отпал, PostgreSQL давал сравнимые результаты только со второго-третьего раза того же запроса (относительно Oracle).
В общем, разница по времени составила в среднем в 100 раз между самым «медленным» и самым «быстрым» результатом.
DB2 «выпала» потому, что, подозреваю что дело не в СУБД а в руках что её ставили, так что не стоит обращать внимание на участие этой СУБД в «тестах».
Таким образом, есть определенные области использования, есть определенные задачи и наборы данных, есть условия при которых будут работать с этими данными. В общем, это целый комплекс требований, и сам выбор СУБД не так тривиален. Но четко можно сказать, для
«сигмента в n данных – использовать Firebird, MySQL, SQLite , MS SQL, PostgreSQL …», «сигмента в n*k данных – использовать MS SQL, DB2, Oracle, PostgreSQL …»,
«сигмента в n*2k данных – использовать DB2, Oracle, PostgreSQL …»,
«сигмента в n*ak данных – использовать DB2, Oracle»
А попытки натянуть коротенькое одеяло на все свои хотелки и условия – ни к чему хорошему не приведёт, последующий переход намного сложней чем первичное проектирование. Не стоит притягивать свою упертость и утверждение «универсальная» для всего.. :)
Оперировать миллионами пользователей и терабайтами данных так же не стоит. Это не бойцовский ринг, на практике таких данных нет (если вдруг где то есть – то либо аналитики там стреляются теперь, либо таких аналитиков надо гнать). Не в силу их отсутствия, а в силу нормального проектирования – мы же в этом случае о промышленном использовании говорим.
--
С уважением,
Виктор mailto:PyrVic@gmail.com
Reply to: