LINUX.ORG.RU

Сравнение Open Source СУБД


0

0

Institute for Applied Knowledge Processing и Fabalabs Software GmbH провели исследования по сравнению Open Source СУБД (Firebird 1.5.2, Ingres r3 3.0.1, MaxDB 7.5.0.23, MySQL 4.1.10 и PostgreSQL 8.0.1) и опубликовали результаты в pdf-документе "Comparison of the Enterprise Functionalities of Open Source Database Management Systems"

>>> Подробности

anonymous

Проверено: Shaman007 ()

Поражён обьективностью=(

anonymous
()

Для Postgresql отсутствует поддержка Linux x86-32, отговорку я не понял:
The most important platforms supported by the DBMS are shown in the following table. If you are looking for a particular operating system / architecture which is missing, then please make sure that
you visit the provided resources.

logIN
()

а подскажите мне пионеру в постгрессе можно выделять права на уровне колонок? или только на всю таблицу?

anonymous
()

Бегло (очень) посмотрел: а почему там не написано ничего про тригеры и хранимые процедуры?

Davidov ★★★★
()
Ответ на: комментарий от logIN

Как это отсутствует поддержка лину-х86 ? У меня под федорой 8.0.2 работает и не заикается, собран из сорцов без всяких хаков.

anonymous
()
Ответ на: комментарий от Davidov

Потому что известно_где их нет :) Это как сравнения известно_кого с Oracle - получается что последний медленнее для веб-сайтов с сотней страниц и десятком хостов в день :)

Eldhenn
()
Ответ на: комментарий от anonymous

>Как это не написано? Страница 30.

Ой, сорри. Чего-то слишком бегло. Ща почитаем :)

Davidov ★★★★
()

Хорошее сравнение, молодцы. Из предложений - включить в обзор сравнение GIS реализаций для СУБД Например, postgis для postgresql. Для остальных есть ли похожие проекты - не знаю.

anonymous
()
Ответ на: комментарий от anonymous

>майкрософт наконец опубликовало tpc-c тест юкона, как и ожидплось майкрософт сосет :)

Не Microsoft, а HP. И не проиграл, а выиграл.

anonymous
()
Ответ на: комментарий от anonymous

chto meshaet vam sozdat' VIEW, hotja by i dlja odnoj kolonki? mozhno povozitsja s RULE.

anonymous
()

гыгыгы. мускуль как всегда отсосал по полной

anonymous
()

А посоветуйте новичку какая из этих СУБД летше? не для чего-то конкретно а в обшем.

anonymous
()

А посоветуйте новичку какая из этих СУБД лутше? не для чего-то конкретно а в обшем.

anonymous
()
Ответ на: комментарий от anonymous

Ну блин, и совем недорого :))

anonymous
()
Ответ на: комментарий от anonymous

Очень легко и быстро осваиваиваемая, почти со всеми возможностями современных СУБД, мало жрёт и весит - Firebird. Клон Interbase от Borland'а, но Firebird IMHO лучше, к тому же бесплатный :). Тока под линь гуишных прог для работы с ней наверняка нет. Но всё в принципе лёгко делается скриптами.

anonymous
()
Ответ на: комментарий от anonymous

http://www.ibase.ru/ - тут были линки на гуй для Firebird. Прадва не знаю есть ли для 1.5. Последний раз на эту БД смотре при версии 1.0.

А кто из многоуважаемых может высказаться в сторону самой быстрой БД (даже не бесплатной)? На малых базах и небольших запросах практически все работают достаточно шустро (за исключением монстров), но стоит перейти за 7-ми значное кол-во записей с 10+ полей и сделать нормальный запрос, тормоза просматриваются везде.

К примеру нужно сделать update в котором where = на 2-3 поля, like на пару полей и between на пару полей (в результате выборка где-то на 500 000 - 1 500 000 записей). А в таблице около 80 000 000 записей.

Кто с таким сможет справиться за 3-5 секунд? Это реально вообще?

Общался с сотрудниками Cache - вроде били себя пяткой в грудь... Но протестировать у меня так руки и не дошли.

Пробовал MySQL, PostgreSQL, Firebird(1.0), SQLite, Sybase, Oracle. Результат меня удивил:

MySQL, PostgreSQL, Firebird - трудились почти одинаково минут 40 - час.

SQLite - раза в 1,5 подольше наверное.

Sybase - спустя несколько ч_а_с_о_в (порядка 6 часов если я правильно помню) выдал ошибку о том что ему не хватает места под transaction backup и бросил это дело.

Оракул я вырубил после долгого ожидания результата (решил что будет не быстрее sybase)

По сей день так и не нашел ничего сверхестественного и в то же время доступного (недоступное знаю что вроде есть) для обработки больших объемов данных, пригодного для WWW.

ok
()
Ответ на: комментарий от ok

Разработчику оторвать все, что торчит. Сразу после постановщика задачи.

baka-kun ★★★★★
()
Ответ на: комментарий от ok

За других не скажу, но за оракл -- смешно. Шутку понял. Рекомендую начать думать, может тогда чего получится.

Casus ★★★★★
()
Ответ на: комментарий от ok

Результат выборки 1 000 000 записей примерно по 8 байт поле и 10 полей в таблице будет составлять около 80 мегабайт. Т.е. сервер должен читать данные с диска и выдавать их клиенту со скоростью 25-30 мегабайт в секунду. (Это чисто прикидка безотносительно к тому Oracle это или MySQL) Конечно такое возможно, но на не самых базовых машинах. И это о выдаче результата, а ведь нужно время на сканирование таблицы...

И что - действительно есть потребность в получении 1000000 записей клиентом ?

anonymous
()
Ответ на: комментарий от anonymous

> Результат выборки 1 000 000 записей

А там не выборка, там обновление! Чтение-изменение-запись. Это не считая транзакции. "Душераздирающее зрелище". Да еще и кривейшие индексы, скорее всего.

Хочется автора спросить: а нахрена это ему? Что-то я с огромным трудом представляю себе рутинную задачу обновления в один прием миллиона записей. Да еще и для "WWW".

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Нда - про update я и не углядел. Аффтару - в начальную школу в Бобруйск поучиться...

anonymous
()
Ответ на: комментарий от baka-kun

Коротко:

Есть товар с 10 параметрами, каждый параметр имеет по 10-200 значений.

Для каждого сочетания нужно сгенерить SKU по определенной формуле зависящей от значений параметров.

Другая задача - добавляется товар в базу. При этом указываются крайние значения параметров и шаг, либо просто перечисляются возможные значения (если нет возможности посчитать их). При этом кол-во сочетаний так же может быть более миллиона. Главное что все сочетания нужны для инвентаризации (т.е. просто список возможных знечений для каждого из параметров - не подходит).

Вобщем хочется человеку одним махом изменить данные для достаточно большого кол-ва данных.

Это кому интересно, хотя мне кажется это уже другая тема.

ok
()
Ответ на: комментарий от anonymous

> И что - действительно есть потребность в получении 1000000 записей клиентом ?

На получение - легко. Например, какая-нибудь статистическая обработка. На изменение IMHO врядли, скорее это уже какой-то косяк в проектировании

step
()
Ответ на: комментарий от ok

>http://www.ibase.ru/ - тут были линки на гуй для Firebird. Прадва не знаю есть ли для 1.5. Последний раз на эту БД смотре при версии 1.0.

Наверное имелся ввиду IbExpert? Он тока под Вынь. :( А тулза классная, правда её огромные возможности являются причиной её нехилой тормознутости. А FB 1.5 рулит. Я на него перекинулся под Вынью с Interbase'а по причине того, что его Classic вариант в отличии от суперсервера (а борланд классик уже не лепит) на каждое клиентское подключение создаёт свой отдельный процесс и клиенты обслуживаются "параллельно" и равноправно. А в классик варианте один громоздкий или бездарный запрос от одного клиента способен привести к тому, что все остальные клиенты будут "курить" в сторонке ожидая пока полностью не отработает "тормоз". Честно говоря так и не понял, а нах... тогда нужен Superserver если он такой тупой?

anonymous
()
Ответ на: комментарий от ok

Значения параметров можно вынести в отдельную таблицу/таблицы, а состоящий из комбинаций результат получать через join (можно и вьюшку сделать). Тогда при добавлении товара или изменении списка параметров не нужно заносить в базу все возможные комбинации и работы будет на пару порядков меньше.

breaK
()
Ответ на: комментарий от ok

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

anonymous
()
Ответ на: комментарий от anonymous

Кстате - да! PostgreSQL вплоть до 7.{чего то} имел дефолтные настройки подходяшие для машин с 64~128 MB RAM. После устраивания "барских щедрот" :) в конфигах сразу хорошело ....

anonymous
()
Ответ на: комментарий от breaK

2 breaK (*) (08.06.2005 15:45:55)

Этот вариант спасает в случае если:

1) нету инвентаризаии товаров... (в противном случае как можно узнать кол-во для каждого сочетания параметров)

2) не нужен собственный SKU для каждого сочетания (т.е. свой собственный код для каждого сочетания параметров).

Более того. Этот вариант был первоначальным и летал "шо немой" на любой БД. Но позволял покупать отсутствующие товары или же просто не существующие (не все сочетания могут существовать)...

Поправьте если я не прав.

ok
()
Ответ на: комментарий от ok

Думать над чужими задачами влом ;) Но так на первый взгляд может быть тебе действительно Cache' поможет.
Но только надо приготовиться, что эта БД _совсем_ другая по сравнению с реляционными. Там данные лежат в деревьях. А объекты, реляционные таблицы и т.д. - это всё равно на деревья сверху натянуто, как интерфейс.
Внутренний язык ('M') такой закорючный, что поначалу кажется сущим кошмаром, после него perl - это так, халява ;)

Dimentiy ★★
()
Ответ на: комментарий от Dimentiy

2 Dimentiy (*) (08.06.2005 23:04:32)

Спасибо за предупреждения... Хотя теоретически я это знаю. А про думанье над чужими задачами - это дело конечно лишнее... :) Я выдал эти данные для того что бы дать представление о задаче, под которую хотел бы найти БД. Только и всего.

ok
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.