LINUX.ORG.RU

Ну вообще-то из этого теста вытекает, что у SQL Server jdbc полохо работает, а так же что при использовании того что рекомендует MS (ASP), SQL Server уделывает Оракле и MySql :)

Ogr
()

2Ogr и что за привычка нехорошая ехидничать по любому поводу?
Можешь посмотреть внимательнее и для critical database:
Microsoft SQL Server 14.33%
MySQL 19.11% (вот смертники то :-)
Oracle 32.56%
PostgreSQL 19.85% (а вот это приятно)

Так что хоть скорость и велика (на простых опять таки запросах), но предпочтения не в пользу MS SQL.

P.S.
Модератор. Можешь удалить это сообщение как порождающее флейм.

Korwin ★★★
()

2Korwin: "и что за привычка нехорошая ехидничать по любому поводу?"
И где я там ехидничал? Я всего лишь прочел статью полностью, а не первый абзац как это сделал logIN, а большенство тех кто прочтет новость на этом сайте на линк вообще ни кликнут.
"Можешь посмотреть внимательнее и для critical database"
Простите мое любопытсво, но куда посмотреть? И что те цифры означают?

Ogr
()

незаслуженно забыли InterBase. Это хоть и такой же отстой как MySQL, но по крайней мере с сохраненными проседурами :))) К тому же opensource, а в этом сравнении все (кроме mysql) proprietary, разбавить надо :)

anonymous
()

Так это же тесты Джавы под Windows. Не очень показательно. Большая часть посвящена тому, что JDBC драйвера такие кривые.

Нет чтобы переписать тесты с использованием С++ и под Unix.

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

> у SQL Server jdbc полохо работает, а так же что при использовании
> того что рекомендует MS (ASP), SQL Server уделывает Оракле и MySql

А кого это тра-ля-ля? Сравнение было честным. Плохо работает - значит в пролете ;)
На простых запросах MSSQL точно никогда не обгонит MySQL, хоть ты пляши вокруг нее с бубном.

anonymous
()

Э, да они все тестировали на винде. Тьфу. Совершенно бесполезный тест.
Какой дурак держит важные базы на винде? Новость-то - полный офтопик.

anonymous
()

Интересно, то что производительность всех испытуемых до 200 юзеров не различается. Вероятно, эта цифирь зависит от мощности железа. Напрашивается вывод: ИМХО, если мне нужно обслужить заранее известное число пользователей (напр. 100) и у меня завалялся какой-нить P-IV, SCSI RAID и т.п., то без разницы что на него ставить (с точки зрения производительности). Так?

anonymous
()

Угу... Предлагаю провести сравнительные тесты ОС, с включением туда FreeDOS в обязательном порядке...;)
А также сравнение яблок с апельсинами...:)

Irsi
()

Ага.и TR-DOS не забыть. Кто бы спорил, ехать на Запорожце накатом с горы Арарат всегда будет быстрее, чем толкать BMW (с выключенным двигателем и на скорости) в ту же самую гору!

Это я про то, что надо иметь серьёзный drainbramage, чтобы пытаться сравнивать DB2 и MySQL. Еще можно сравнивать md5 sums iso-образов дистрибутивных CD, но только эти самые md5 sums надо обязательно делить на 23.45678 (и потом округлять до ближайшего целого сверху!).

Dronov
()

По моему ламерскому взгляду в этом вопросе я думаю что завсегда будет заточка базы под определенные задачи и всех сравнивать средним мерилом не корректоно наверное. А под какие задачи они все делались?

Игорь.

anonymous
()

Рекомендую "наплевать и забыть" на этот тест.
Например, у меня MySQL "not passed" :)
Т.е. не справляется с запросами вообще.

И смею заметить, скорость реакции СУБД (DB2, Oracle, PostgreSQL, MS SQL) кардинально меняется от передвижений маленьких рычажков в настройках, не говоря уже о типах запросов.

AffreuxChien
()

2Ogr. Там справа в верхнем углу есть опросник... Но какой-то он ламерский впрочем как и сама статья :-)

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

<цитата> И смею заметить, скорость реакции СУБД (DB2, Oracle, PostgreSQL, MS SQL) кардинально меняется от передвижений маленьких рычажков в настройках, не говоря уже о типах запросов. </цитата>

FYI Для выполнения этого теста PCMag приглашал специалистов от фирм разработчиков баз данных для тонкой натсройки их DBMS. Каждой фирме давалось 3 дня для пробных запусков и настройки

walrus
()

На Linux'е из коммерческих баз данных выигрывает IBM DB2 UDB 7.2. Вопрос - а под каким Линуксом? Естественно, что для крупных приложений будет использован Linux zSeries (S/390).

Я также субъективно сравнивал IBM DB2UDB7.2 и Oracle 9i на своем PC Linux Suse 7.3. Оракул хоть и навороченней и красиво ставится в "Иксах", но менее "прозрачен" для пользователя-разработчика. IBM DB2UDB8 будет также иметь "настоящие" хранимые процедуры (хотя, IMHO, это зло) и поддержку цепочного вызова JDBC хранимых процедур.

--------

P.S.А высказывания Орга, Бизмена и прочих одиозных "бывших советских граждан" просто веселят меня своей несерьезностью.

--------

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

<цитата> Ну вообще-то из этого теста вытекает, что у SQL Server jdbc полохо работает, а так же что при использовании того что рекомендует MS (ASP), SQL Server уделывает Оракле и MySql :) </цитата>

Другими словами - если сравнивать MSSQL "на общих условаях" то он почему то проигрывает. А если поместить в особые условия (где никто другой не тестировался) - то он еще ого-го!

walrus
()

Скажите лучше, использует ли кто SAP DB? Стоит ли с ней связываться?

Между прочим, этот сервер тоже, как ныне модно, open source

anonymous
()

Лично для меня этот тест интересен тем, что появились хоть какие-то реальные замеры производительности при больших нагрузках. А то сколько раз плевались в mysql - что он плохо работает при больших нагрузках и при большом числе пользователей, и при больших обьемах баз данных - а вот теперь видно стало, чего стоят эти наезды.

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

> Лично для меня этот тест интересен тем, что появились хоть какие-то
> реальные замеры производительности при больших нагрузках. А то
> сколько раз плевались в mysql - что он плохо работает при больших
> нагрузках и при большом числе пользователей, и при больших обьемах
> баз данных - а вот теперь видно стало, чего стоят эти наезды.
> walrus (*) (2002-02-28 11:16:23.0)

Полный бред. mySQL умеет быстро делать только линейный SELECT. Ты попробуй сделать join хотя бы 3 таблиц тысяч по сто записей в каждой... Ну как? А пять join в одном запросе? И посмотри, что конкретно mySQL при этом делает! Это же полный 3.14здец. И не надо говорить, что можно (нужно) не делать столько join в одном запросе... Надо, Вася, надо (C).

И вообще... Сохранёнок - нет. Внешних ключей - нет. Транзакций - нет. Вложенных запросов - нет. Объединений/пересечений - нет. Одним словом - дерьмо.

wild

anonymous
()

Хе, у меня ссылка просто не работает, но из сообщений я понял, что в тестировании принимал участие JDBC слой. А вот это некорректно. Уже хотя бы потому, что тот же Oracle имеет две версии JDBC драйвера - OCI8 и Thin. Одна из которых использует нативные библиотеки OCI8, а второй - чисто явский. Естественно, что первый драйвер обгонит второй. Вот и получается, что Oracle быстрее Oracle. Правда здорово? А Sybase, например, для JDBC использует TDS протокол(Tabular Data Stream), насколько я помню - реализация явская, тоже не самый быстрый способ. Так что меряли-то? Связку СУБД + JDBC драйвер? Грязный опыт получился.

Но в данный условиях теста(когда замеры производятся на клиенте, я ничего не напутал?), тестирование под Windows вполне оправданно, потому, что виндовый клиент в двухуровневой архитектуре - вполне оправданное решение.

Полуденный Бес

anonymous
()

2 wild Не надо ругаться 8) Так сложилось, что не всем и не всегда надо держать большие базы. Вот мне лично (подчеркиваю - лично, не для работы, а для "баловства") mySQL'я вполне хватает - десяток таблиц по тысяче записей, не более... И не вижу смысла в применении более навороченных систем для моих нужд. Это я к чему - не стоит говорить "дерьмо". Стоит говорить "применимо в отдельных случаях".

Zulu ★★☆☆
()

Все как то забыли про Sybase он не в лидерах но он гараздо лучьше MSSQL вот именно поэтому мы его и используем . Т.е. по отношению цена производительность качество это как раз то.

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

<цитата> И вообще... Сохранёнок - нет. Внешних ключей - нет. Транзакций - нет. Вложенных запросов - нет. Объединений/пересечений - нет. Одним словом - дерьмо. </цитата>

Плохому танцору известно что мешает -- отсутствие subselects ;-)

Между прочим PCMag тест как раз был реальным приложением - online book store - а не надуманными проверками 10 join в одном select

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

<цитата> но из сообщений я понял, что в тестировании принимал участие JDBC слой. А вот это некорректно. Уже хотя бы потому, что тот же Oracle имеет две версии JDBC драйвера - OCI8 и Thin. Одна из которых использует нативные библиотеки OCI8, а второй - чисто явский. Естественно, что первый драйвер обгонит второй. Вот и получается, что Oracle быстрее Oracle. Правда здорово? </цитата>

Выбор JDBC драйвера и его настроек делался инженерами фирмы разработчика DBMS - для Оракла - соответсвенно оракловцами, для mysql - mysql-вцами и тд

walrus
()

walrus: > Плохому танцору известно что мешает -- отсутствие subselects ;-)

Ты видимо кроме веба и не видел ничего.

>Между прочим PCMag тест как раз был реальным приложением - online >book store - а не надуманными проверками 10 join в одном select

А мускулю и 3-х хватает, чтобы в ступор его ввести. Бухгалтерия - тоже реальное приложение. Но если у тебя из-за dirty reads нарушится целостность данных, то тебя подвесят за яйца.

Про MS SQL: Using the driver, we were unable to get more than about 200-page-per-second throughput, and the problem was clearly the driver?the database was only at about 15 percent to 20 percent CPU utilization at this load. The driver also has memory leaks: We could see on WebLogic's administration console that less memory was freed each time the Java virtual machine did a garbage collection. Because of these leaks, the Microsoft JDBC driver was unable to run for 8 hours straight.

Havoc ★★★★
()

2 ROMUL

Я, признаться, сомневаюсь, что по цене-производительности Sybase MSSQL сделает. Вот цена-производительность-надежность Sybase многих уработает. Тут правда, должен всплыть еще один фактор - а на скольких платформах живет СУБД? И здесь MSSQL отдыхает, конечно.

Полуденный Бес

anonymous
()

2 walrus


"Выбор JDBC драйвера и его настроек делался инженерами фирмы разработчика DBMS - для Оракла - соответсвенно оракловцами, для mysql - mysql-вцами и тд" - это я понял, но положения дел-то это не меняет.

Полуденный Бес

anonymous
()

народ не знаю как вам но мне не интересно обсуждать какая база быстрее какая ОС круче и т.д. на работе линух дома вынь 98 и никогда не будет приложения которое б работао везде лучше, быстрее ... и никогда не будет базы (DBMS имеется ввиду конечно) которая б показывала на всех тестах лучшие результаты ... неинтересно ... если ты выбрал Oracle для каких то нужд ну зачем людям навязывать ... бред ... насчет баз могу зказать одно мне понравился Cache'(www.intersystems.ru) может он не самый быстрый но жизнь разработчику делает легче ... оракл на моих тестах показал непредсказуемость ... для меня это важнее ... я хочу знать что будет делать база когда делаещ ~100 совершенно непохожих запроса ... конечно DB2 самая предсказуемая ... но поддержки (на переферии //как говорил шефчук) совершенно никакой ... а я не монстр чтоб сидеть все ночи напролет на работе и мучить DB2 ... каждый выбирает то что ему подходит и никакие тесты не смогут мне ответить на вопрос что юзать для меня удобнее...

djal

anonymous
()

а про такую базу как PROGRESS забыли? или незнают вовсе ?:)

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

<цитата> Ты видимо кроме веба и не видел ничего. </цитата>

А! Вот и на личноти перешли! Ну чтож - давай животами будем меряться.. Самый большой проект, который я сделал - имел более 100 таблиц и по нескольку миллионов записей в некоторых таблицах. ИМЕННО ПОЭТОМУ я знаю, что для реальной работы с серьезными базами данных требуются не "хранимые процедуры с триггерами" а отдельное приложение (application server) к которому обращаются уже все остальне клиенты. А этот app.serv уже делает и проверку вводимых данных и целостность обеспечивает и другую необходимую обработку. Лично я предпочитаю делать это на CORBA, некоторые на EJB, сейчас еще всякое .net c## и тд появилось.

А программы где клиенты лезут прямо в базу данных - это, извините, хорошо разе что для бухгалтерии..

Насчет 3 join - приведите пожалуйста пример, потому что у меня и "покруче" sql запросы были без всяких поблем в mysql.

<цитата>Про MS SQL: Using the driver, blah-blah-blah...</цитата>

Ага Вот и здесь нашлось нечто, что мешает танцорам..

walrus
()

> а про такую базу как PROGRESS забыли?
Я бы попросил в приличном обществе не произносить слов "progress" и "pervasive".
Нельзя так выражаться. Вдруг дувушки читают?
-----
Progress был интересен в своё время своей IDE и своим 4GL.
Сейчас - заслуженно забыт.

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

http://www.rscom.ru/?eng=0&where=3&page=3

http://listserv.sap.com/pipermail/sapdb.general/

> Could you please elaborate a bit more on this? What makes you think that> PostgreSQL is only suited for small applications and doesn't scale well?

- with SAP-DB you can have mirrored DATADEV-Spaces on different harddisks(loose your harddisk with postgres and you will know)

- with SAP-DB you can have mirrored LOGDEV-Spaces on different harddisks

- with SAP-DB you can have raw-devices (higher performance, safer transaction handling)

- with SAP-DB you can do backups without disturbing the normal work

- with SAP-DB you can reconstruct a destroyed DB with your LOG

> > Hi folks, > > I just have to tell you this, 'cause I'm so happy. > > Sunday evening I ordered the SAP DB CD from SAP's Website, > received it today, and 3 hours later everything was up and running > on a SUSE Linux 7.2, the first db created, the first C++ Program > written and compiled, and ... it even worked. > > I just can't believe it. Thanks a lot to you folks at SAP to > providing this under the GPL and all your effort. > This is so much fun, and I was afraid I would spend weeks on this. > > Next thing I do is kick interbase and postgreSQL from my server ;) > > Thanks, >

I used to order 2 releases via their webpage and me too I was very happy. SAP-DB and the SAP-DB free(!!) service is much more than you get from other vendors for lot of money. Congratulation to SAP and the SAP-DB team!

www.sapdb.org

anonymous
()

> имел более 100 таблиц
Ну, всего-то сотня.
Правда, не верится, что даже в такой простой БД никогда не было формально неверных данных.

> для реальной работы с серьезными базами данных требуются не "хранимые процедуры с триггерами" а отдельное приложение

Прежде всего требуется хреновина, по фамилии "constraint" и сестра её по фамилии "foreign key", да брат ихний "trigger".
-------
Увы, увы. Реальная жизнь такова, что MySQL у меня эффективно пашет только на одном проекте.

Только не надо говорить, что транзакции типа "H" и необходимость оных не относятся к реальной жизни.
Факты таковы, что MySQL не пригоден для ведения сложных БД (сс. целостность) и очень плохо окучивает запросы, характерные для хранилища.

AffreuxChien
()

Пока тут народ holy wars мается, нормальные люди пишут под MS SQL на ASP для тех у кого корпорейтив стандарт - MS, на MySQL WEB с соответствующим соотношением select/update, под Оракл/Java - там где считают его более подходящим, и имеют на хлеб с маслом от тех, других и третьих.

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

Так об том и речь, что в пролёте не MS SQL Server (который, несмотря на ненавистную для красноглазых марку "Microsoft" - более чем достойный продукт, сравнимый с Oracle, чего об игрушках вроде MySQL не скажешь даже по сильной пьяни), а Жаба и дебильная технология JDBC.

Antichrist
()

Paskin:
Угу.
Правда, MS-овский уж год не пригождался :)

AffreuxChien
()

2 Makc

А что Progress? До опупения неудобная штука. И кривая к тому же.

Полуденный Бес

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

> 2 wild Не надо ругаться 8) Так сложилось, что не всем и не всегда
> надо держать большие базы. Вот мне лично (подчеркиваю - лично, не
> для работы, а для "баловства") mySQL'я вполне хватает - десяток
> таблиц по тысяче записей, не более... И не вижу смысла в применении > более навороченных систем для моих нужд. Это я к чему - не стоит
> говорить "дерьмо". Стоит говорить "применимо в отдельных случаях".
Zulu (*) (2002-02-28 12:06:08.0)

Да просто достало словоблудство по поводу "скорости", "непадучести" и т.д. всяческих поделок типа mySQL. За ругань приношу извенеия.

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

> <цитата> И вообще... Сохранёнок - нет. Внешних ключей - нет.
> Транзакций - нет. Вложенных запросов - нет.
> Объединений/пересечений - нет. Одним словом - дерьмо. </цитата>
> Плохому танцору известно что мешает -- отсутствие subselects ;-)
Ну, танцую я, конечно, плохо... ;) Но не из-за subselect'ов

> Между прочим PCMag тест как раз был реальным приложением - online
> book store - а не надуманными проверками 10 join в одном select
> walrus (*) (2002-02-28 12:10:38.0)

У меня тоже _реальные_ приложения.
Пример:
60 с копейками таблиц. Небольшие, вообщем-то по размеру. Запрос с пятью INNER JOIN внутри (надо так). mySQL делает это счастье 10 минут. При этом mySQL делал FULL JOIN в temp таблицы... Вопросы есть?

wild

anonymous
()

postgresql не учавствовала - не захотела.

logIN
() автор топика

Ну не знаю чем MS SQL лучше - эти триггеры и foreign keys в MySQL, по-моему, вполне заменяются средствами приложений. У меня сперва база (таблиц немного, но каждая таблица - это около 2-х миллионов записей и 70 полей, 50 из которых - VARCHAR(100), а 20 - INT(11)) работала на MS SQL на сервере под Win2k, потом грохнул Win2k, поставил Linux и MySQL, и все заработало быстрее, даже сотрудники заметили.

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

SAP DB действительно open source, но для ее сборки из исходников требуются утилиты от SAP распостраняемые(как я понял) только в бинарном виде. К тому же конретно на вашем Linux дистрибутиве он может и не собратся(у меня например сборка спокнулась на проблемах с bison). Sarras

anonymous
()

2logIN: что вообщем-то говорит скорей в их пользу, чем наоборот имхо...:)

Irsi
()

Да, про MySQL под нагрузкой... Я в него зарулил как-то весь httpd_access.log от всех клиентов sweb.ru - после 3 миллионов записей (дня 2) зачихался и опустил httpd :((((((((((((( Четвёртый, настроенный на скорость как рекомендуют.

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

<цитата> - после 3 миллионов записей (дня 2) зачихался </цитата>

Опять же в pcmag тесте самая толстая таблица была примерно 50 миллионов записей (для mysql). И что интересно - все работало. И что самое главное - тест был сделан не мной и не Вами а посторонними незаинтересованными людьми.

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

> Ну не знаю чем MS SQL лучше - эти триггеры и foreign keys в MySQL, > по-моему, вполне заменяются средствами приложений. У меня сперва
Угу. И СУДБ тоже можно ручками с нуля... Теоритически... И вообще, зачем эти СУДБ? Файлы - forever! ;)))

> база (таблиц немного, но каждая таблица - это около 2-х миллионов
> записей и 70 полей, 50 из которых - VARCHAR(100), а 20 - INT(11)
Чисто для любопытсва, просветите, что можно в базе с такой моделью данных хранить?

> работала на MS SQL на сервере под Win2k, потом грохнул Win2k,
> поставил Linux и MySQL, и все заработало быстрее, даже сотрудники
> заметили.
Небось, кроме SELECT * FROM someTable; ничего не делалось. Кстати, а что за софт юзал эту базу, который можно вот так, лЁгко, перенести с Мастдая на Юних?

> anonymous (*) (2002-02-28 15:39:11.0)

wild

anonymous
()

2Irsi (*) (2002-02-28 15:43:34.0): я это сказал не за и не против. просто сказал. ;-)

logIN
() автор топика

> Небось, кроме SELECT * FROM someTable; ничего не делалось.

Похоже на то. И мускулисты забывают про существование иакой вещи, как лог транзакций.

Чтобы заметить его влияние, можно сделать простой тест на нормальной базе:
delete from big_table
truncate table big_table

и ощутить разницу.
Хинт: во втором случае ничего в лог не пишется.

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

> Похоже на то. И мускулисты забывают про существование иакой вещи, > как лог транзакций. ^^^^^^^^^^ Лог чего????? муСКУЭЛ знает, что такое "транзакция"? ;))))))

Хотя, вроде, обещают, что обучат муСКУЭЛ умным словам типа ROLLBACK ;))))

> Havoc (*) (2002-02-28 17:48:45.0)

wild

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