Нью-Йоркская фондовая биржа переходит на Linux

А также Лондонской биржи.

Гет ин зе фектс колбек? =))))

Переход с unix на unix - не так интересен как переход с MS SQL на unix.

> Переход с unix на unix

Там не с юникса переход, а со специфической IBMовской системы.

Главное - количество Линукса на планете неуклонно растёт! :)

NASDAQ врядли. Как это ни печально, MS SQL рвет по всем параметрам все существующие СУБД. Разве что Оракл потягаться может. :(

Факты приведете?

Очень авторитетное заявление от anonymous :)))

онанистмуз он и в африке онанистмуз )))

Выборка ~1000 строк из 100000 по LIKE (3 символа) к четырем строковым колонкам. ~3 сек. Вставка 200000 строк (строка ~0.5Kb) - 90 сек. PIV HT, 1Gb RAM. Буду искренне и безмерно счастлив если Postgre/MySQL/SQLite/etc смогут так же.

По моему опыту MS SQL на Dual Athlon 3800+ 1 Гиг памяти, винт 7200rpm 16Мб кэш работает в 2-3 медленнее, чем PostgreSQL на PIII 1 GHz, 256 MБ памяти, 4200 об/мин винт - ноутбук вобщем ;)

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

>Выборка ~1000 строк из 100000 по LIKE (3 символа) к четырем строковым колонкам. ~3 сек. Вставка 200000 строк (строка ~0.5Kb) - 90 сек. PIV HT, 1Gb RAM. Буду искренне и безмерно счастлив если Postgre/MySQL/SQLite/etc смогут так же.

"Лжёшь собака, сукин сын Якин" @ Иван Васильевич меняет профессию. 22000 строк несколько десятков колонок - 3 сек, тоже самое на постгре на приведенной конфигурации - 3 сек.

кеш выключи

>Выборка ~1000 строк из 100000 по LIKE (3 символа) к четырем строковым колонкам. ~3 сек

и что это вообще за цифры? запрос был с fetch'ем ?

Не лгу GladAlex. Это печальная правда. Я сейчас сижу и наблюдаю за этим процессом. кроме всего прочего вставкой занимается прога на .NET

Когда я попробовал это сделать на мускуле - он просто сожрал нафиг проц, память и завис. Я не дождался окончания операции.

>Опыт школьников с помоечным железом и быдлокодеришек использующих пых и мускуль никому не интересен - для такого мусора мускуль и делали.

Это ты о себе? Пых и мускуль никогда не использовал, мальчик. Смотрим сюда: http://www.linux.org.ru/jump-message.jsp?msgid=645589&lastmod=10946569099... и сюда http://ondemandiq.com/demo.htm - навороченый движёк для всех отчётов и графиков строится на хранимых процедурах MS SQL. Так что сравнить было с чем.

>кеш выключи

зачем?

> и что это вообще за цифры? запрос был с fetch'ем ?

нет. результат - ~1000 строк. неправильно выразился.

>Когда я попробовал это сделать на мускуле - он просто сожрал нафиг проц, память и завис.

Мускуль не использовал, не знаю: было недостаточно возможностей, когда я выбрал Postgre. По поводу вставки на .Net - у нас аналогичное приложение: из-за того, что нужно проверять дубликаты и на таблицах много индексов (для отчётов) скоростью похвалиться не можем.

Раздроби себе голову кувалдой, если читать не умеешь. Речь шла о говномускуле, которому место на свалке - это говно за 3 мажорных версии даже SP не научилось поддерживать. Постгре стоит убить только за кривую систему бекапов как в мускуле, в остальном он хорош.

Разбей себе или научись читать сам: я говорил о Postgre, см. первый пост.

>>кеш выключи

>зачем?

чтоб запросы не кешировались, нужен результат чистой работы сервера

> Это ты о себе? Пых и мускуль никогда не использовал, мальчик. Смотрим сюда: http://www.linux.org.ru/jump-message.jsp?msgid=645589&lastmod=10946569099... и сюда http://ondemandiq.com/demo.htm - навороченый движёк для всех отчётов и графиков строится на хранимых процедурах MS SQL. Так что сравнить было с чем.

Сайт-то школьники на лабах делали? На таком сайте ничего серьёзного размещено быть не может.

>Постгре стоит убить только за кривую систему бекапов как в мускуле, в остальном он хорош.

Кривая система у MS - ни разу не было, чтобы без проблем прошёл: перевести в SQL без потерь для него похоже вообще нереально. Приходится всякими идиотскими утилитами пользоваться типа SQL Compare или SQL Delta, но и те на 100% синхронизировать не могут.

Сравни с этими двумя элегантными строчками из PostgreSQL:

$ pg_dump dbname | gzip > filename.gz # backup

$ createdb dbname ; gunzip -c filename.gz # restore

А MS так не умеет в принципе.

OnDemandIQ - по ходу графики ZedGraph рисует?

Зачем кеш выключать? LIKE выражение и так меняется постоянно...

>Сайт-то школьники на лабах делали? На таком сайте ничего серьёзного размещено быть не может.

Ага, получи demo account и удивись, один из заказчиков сервиса - крупная фармацевтическая компания в США имеющая отделения во всех штатах.

>OnDemandIQ - по ходу графики ZedGraph рисует?

Нет. Сам проект ты так не увидишь, нужно в demo зайти или ролик хотя бы посмотреть.

>Зачем кеш выключать? LIKE выражение и так меняется постоянно...

Ага, только таблица таже самая. Перезагрузи сервер и запусти опять - результаты будут кардинально отличаться.

Так и запишем: "ниасилил enterprise manager с бинарными бекапами и database maintenance wizard, прикручивает костыли с дампом в текст и последующей упаковкой".

А если нужно забекапить только изменения? А только логи транзакций? Написать десяток скриптов и ждать пока они прожуют базу на 300Гб?

PS. За год+ аптайма mssql ниразу небыло чтоб бекапы криво записались/развернулись.

Конечно, может MS SQL Server по возможностям и превосходит MySQL, а по роботе «из коробки» превосходит PostgreSQL. Вот только до Oracle ему так же далеко :). Oracle не зря бабло гребёт :).

Линуксу до винды так же далеко :). MS не зря бабло гребёт :).

Да, два года тра..ся с MS SQL. Ну его нах это поделие. С бэкапами и правда та еще ж..а. PS Просто, когда поминают это начинаю плеваться и выражаться не цензурными словами. Never more кароче.

>Ага, только таблица таже самая. Перезагрузи сервер и запусти опять - результаты будут кардинально отличаться.

Ну и что с того что таблица та же? Сервер работает, кеширует - это его работа! Ты же не перезапускаешь сервер после каждого запроса? А запросы отличаются (точнее параметры SP). Если у него есть память - то по мне пускай хоть всю базу туда запихнет, главное чтоб меня не долбали - "Какого оно так тормозит??"

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

DB2 кто нить пробывал на PPC и вообще какой спор на i386 архитектуре ? быдлоскула научилась на ней работать? может кто нить на ппц тестил какую нить опенсоурсную бд по соотношению цена/производительность с MSSQL - отпишитесь.

>А запросы отличаются (точнее параметры SP). Если у него есть память - то по мне пускай хоть всю базу туда запихнет, главное чтоб меня не долбали - "Какого оно так тормозит??"

Да запросы отличаются, но если база несколько десятков или сотен Гиг и 100 пользователей на сайте одновременно, то кэш и память идёт лесом. Вот тогда тебя и начнут долбать пользователи, а нас долбают манагеры - хотят 100 user-oв, как у них это получиться не знаю: где-то с декабря тр... с оптимизацией: чего стоит хотя бы только включение indexed views или мультиверсионности (по умолчанию lock - так сервер был спроектирован изначально ;), а про оптимизацию запросов вообще молчу, чего приходится выдумывать ;)

То и оно. Сначала была 7ка. (Файерберд, конечно, не додятигивает до таких тяжеловесов. Но как же это все таки удобно: select * from func1(args) inner join ... IBExpert сказка, выводит время запросов с точностью до миллисекунды, ммм. В то время еще в вендах жил.) Убивало, что приходилось тут и там использовать временные таблицы. Тут появляется 2000ый. Обрадовался по началу - функции. Толку от этих функций ноль. Временные таблицы не создашь, переменные таблицы по скорости работы - бррр, помню как пришлось переписывать после пары попыток сделать что то путное, забыл и больше так не делал. Так и приходилось делать через ж..у - exec да курсоры. Однако данные все равно надо куда то запихать, на это тоже нужно время. Логика - руки, блин, не из того места у разработчиков растут. А как оно тормозит на выборках. Предметная область была дороги - куча таблиц, куча столбцов, запросы по индексу и все равно тормозило.

>Ждём перехода от NASDAQ: ;) как известно там пока всё работает на MS SQL Server.

Откуда информация?

> Раздроби себе голову кувалдой, если читать не умеешь

Я гляжу, большой спец, раз так выражаешься. Жена не дает?

Бугага однако! Ждем когда ее примеру последует лондонская. И еще с бОльшим нетерпением ждем отчетов о внедрении.

Get the facts!

>NASDAQ врядли. Как это ни печально, MS SQL рвет по всем параметрам все существующие СУБД. Разве что Оракл потягаться может. :(

DB2 еще. Тройка лидеров: MS SQL, IBM DB2 и Oracle.

>Выборка ~1000 строк из 100000 по LIKE (3 символа) к четырем строковым колонкам. ~3 сек. Вставка 200000 строк (строка ~0.5Kb) - 90 сек. PIV HT, 1Gb RAM. Буду искренне и безмерно счастлив если Postgre/MySQL/SQLite/etc смогут так же.

Это вы наверное у серванта единственный клиент :) в MS-SQL тормоза растут, в зависимости от количества клиентов, в геометрической прогрессии.

>MS SQL рвет по всем параметрам все существующие СУБД

Особенно по количеству поддерживаемых аппаратно-программных платформ :)

> Выборка ~1000 строк из 100000 по LIKE (3 символа) к четырем строковым колонкам. ~3 сек

Во тормоза-то...

mysql> select count(*) from stats;
+----------+
| count(*) |
+----------+
| 664848   |
+----------+
1 row in set (0.01 sec)

mysql> select level from stats where comment like '%las%' and desc like '%las%' and storedby like '%las%' and manuf like '%las%';
...
...
1660 rows in set (1.26 sec)

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

>Во тормоза-то...

Не худо бы сравнить аппаратные характеристики и размер БД...

> Различные нашисты и молодогвардейцы получили бабло на акции по поддержке мелкософта?

Всех этих людей совершенно необходимо убить.

mysql> select count(id) from log;
+-----------+
| count(id) |
+-----------+
|    983531 |
+-----------+
1 row in set (0.01 sec)
mysql> select * from log where state LIKE '%err%'  and message LIKE '%jam%' and subsystem LIKE '%pri%' and time LIKE '%200%'; 
...
1048 rows in set (0.43 sec)
Это на VPS хостинге. Что я делаю не так?

> mysql> select level from stats where comment like '%las%' and desc like '%las%' and storedby like '%las%' and manuf like '%las%'; ... ... 1660 rows in set (1.26 sec)

а теперь замени and на or и включи секундомер.

1Gb RAM, P4 630 3GHz с выключенным гипертредингом, ибо HT кал mysqlю только вредит, размер таблицы указан, база вообще неохватная, там таблиц много больших, вся в память не влезет никак.
Ну подкручен, конечно mysql немного, не стандартный конфиг, но с того приросту скорости от силы несколько %

А тормознее и неудобнее чем MS SQL я базы вообще не видел.
Postgres лохматых версий и то гораздо шустрее был. А уж нынешние
оракл, постгрес и мускуль рвут это убожище от микрософта как тузик грелку. DB2 не щупал, но скорее всего тоже уделает.

Конечно, можно выключить кэш на процессоре, загнать фс в sync и заставить таки какой постгрес копошится медленнее MS SQL, но это ж как постараться надо. Такое только проплаченным МС "тестерам" под силу.

А в это время Медвед и Мининформсвязи переходят на венду.

Респект бирже - откат видимо не взяли.