134 ответов в теме

[Kil]

Как человек, работающий в крупной компании - системном интеграторе, внесу свои 5 копеек. Во всех переговорах, во всей документации, во всех договорах всегда используется калькирование, а именно "блейд-сервер". Точка!
Да, слово "лезвие" тоже используется. НО! Оно НИКОГДА не используется в виде выражения "сервер-лезвие", а ТОЛЬКО для обозначения конкретного сменного модуля. Типа "лезвие сдохло", "заменил пару лезвий". Вот в таком варианте иногда используют, но никогда-никогда-никогда не используется это убогое "сервер-лезвие"...

[DeadMazay]

Нашли о чем спорить
Блейд-лезвие, клинок. Название я так понимаю родилось потому что они втыкаются в стойку как нож во что либо, тем более если брать формат 1U, то достаточно тонкая штуковина, раза в 2-3 тоньше обычного системника, не говоря уж об обычных серверах.
ИМХО, автор сам решает переводить сленг или нет.

[Blasfemer]

Расскажите еще и про запАснЫй выход.

Я просто не могу пройти мимо!
Ну почему? ПОЧЕМУ ЖЕ?!? ПАЧИМУ "Ы"???

[Kil]

Я просто не могу пройти мимо!
Ну почему? ПОЧЕМУ ЖЕ?!? ПАЧИМУ "Ы"???

А фиг его знает, кстати
Грамота.ру

[Cptn Z]

Я просто не могу пройти мимо!
Ну почему? ПОЧЕМУ ЖЕ?!? ПАЧИМУ "Ы"???

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

[wiz]

В чем проигрывает? Обычно паритет такой - в мускле повыше скорость, постгрес более фичаст.

Начиная с 8.3 мускль по скорости тоже сливает. А выигрывает, как и PHP - на распространённости и бесплатности. В остальном - ненадёжное кривое гамно q:

[Blasfemer]

"запасной" говорят нормальные люди.

Я то говорю "запасной", а вот почему в ощественном транспорте пишут "запасный", меня с детства интресовало!

Тебе тоже, кстати сюда.

Не стоит посылать на х#й людей, которые благодарят тебя за работу...

[lampochka]

Начиная с 8.3 мускль по скорости тоже сливает. А выигрывает, как и PHP - на распространённости и бесплатности. В остальном - ненадёжное кривое гамно q:

по бесплатности вроде что мускуль что постгрес совершенно одинаковые Правда мускуль скупил Сан...
и вроде собирался выпускать платную версию...

[Gwin]

по бесплатности вроде что мускуль что постгрес совершенно одинаковые Правда мускуль скупил Сан...
и вроде собирался выпускать платную версию...

MS SQL Express тоже бесплатен и полнофункционален. Ограничение есть на кол-во процессоров и оперативной памяти, если не ошибаюсь.

[EyeCutter]

Даааа... Люди пытаются побустить OLTP-систему твердотельными дисками и кластерами )) Деццкий сад и сбоку ясли. С таким разрабами, методами и затратами лаги в Еве никогда не исчезнут )

[DarkPhoenix]

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

[EyeCutter]

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

Да мне пофиг, просто констатирую факт - не то бустят и не тем

[DarkPhoenix]

Я конечно хз, имеешь ли ты ввиду способы получше - софтовые или железные, но железное подразделение, ясное дело, в софт не лезет

[EyeCutter]

Я конечно хз, имеешь ли ты ввиду способы получше - софтовые или железные, но железное подразделение, ясное дело, в софт не лезет

Первый самый главный косяк Железо и его архитектура проектируется под софт и расчетные нагрузки, если у проекта нет бюджетных проблем. Второй главный косяк - бустить в OLTP-системах надо коммуникации и связи, т.к. время отклика и его процессинг намного сложнее, чем подготовка данных для него.

[DIMFIRE]

Будем надеяться что реально станет меньше лагать.

ЗЫ. народ-а вам по большому счету не все равно как переводиться? от того правильный или неправильный перевод у топикстартера серваки ни быстрее ни медленнее работать не начнут.

[Demian Lee]

многие тут высказывались, разрешите и мне высказаться ))

1. выбор SQL сервера зависит от самой базы.
1.1 мускул надежен и быстр, но на небольших базах до 100к строк, выше он проигрывает мелкомяхкому.
1.2 постгрес на больших базах часто валится, на малых базах у него есть свои преимущества перед мускулом.
1.3 кроме обьема базы важным фактором является надежность, безопасность и ресурсоемкость, мелкомяхкий страдает всеми тремя, поэтому требует много дорогого железа. чем старши дети тем дороже у них игрушки.
1.4 масштабируемость. мелкомяхкие заявляют об отличной масштабируемости своей поделки. но кАпнем глубже, что есть масштабируемость и как она реализована. один из вариантов репликация. репликация в понятих мелкомягких это перелив всей базы(либо таблицы целиком) с одного сервера на другой, к чему это ведет. Как раз к тому что перелив большой базы занимает очень много времени.

2. безопасность самих серверов - это тоже немаловажный фактор... уж извините, но ВЫНЬ не как не назовешь безопасной и отказоустойчивой системой. дыра на дыре, и другой дырой прикрывается - это ФАКТ.

3. доступ, также не маловажный фактор. опять же разберемся он зависит от структуры ОС
3.1 Вынь - ядро системы с добавленными IP протоколом, как дополнительный функционал, типа фаервола или антивиря - вывод плохой доступ.
3.2 *nix - IP протокл часть ядра - вывод думаю понятен.

ЗЫ: разбирать что хорошо, а что плохо на самом деле глупо... наше дело получать фан, дело разработчиков обеспечить обеспечить нам этот фан )))... насколько хорошо они это делают мы и так все видим, и у видим в будущем.

ЗЫЫ: Не стреляйте в пианиста, играет как умеет (С) надпись в американском салуне 1800 лохматый год.

[lampochka]

mysql 8.3? вроде шестую пилют еще...

postgresql-8.3

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

У вас есть примеры? Напишите о них разрабам постгреса, а то они наивные пишут на главной странице, что у них нет сведений о том, что их БД когда-нибудь падала... И нам ссылочку, интересно почитать

[Gwin]

многие тут высказывались, разрешите и мне высказаться ))

1. выбор SQL сервера зависит от самой базы.
1.1 мускул надежен и быстр, но на небольших базах до 100к строк, выше он проигрывает мелкомяхкому.
1.2 постгрес на больших базах часто валится, на малых базах у него есть свои преимущества перед мускулом.
1.3 кроме обьема базы важным фактором является надежность, безопасность и ресурсоемкость, мелкомяхкий страдает всеми тремя, поэтому требует много дорогого железа. чем старши дети тем дороже у них игрушки.
1.4 масштабируемость. мелкомяхкие заявляют об отличной масштабируемости своей поделки. но кАпнем глубже, что есть масштабируемость и как она реализована. один из вариантов репликация. репликация в понятих мелкомягких это перелив всей базы(либо таблицы целиком) с одного сервера на другой, к чему это ведет. Как раз к тому что перелив большой базы занимает очень много времени.

2. безопасность самих серверов - это тоже немаловажный фактор... уж извините, но ВЫНЬ не как не назовешь безопасной и отказоустойчивой системой. дыра на дыре, и другой дырой прикрывается - это ФАКТ.

3. доступ, также не маловажный фактор. опять же разберемся он зависит от структуры ОС
3.1 Вынь - ядро системы с добавленными IP протоколом, как дополнительный функционал, типа фаервола или антивиря - вывод плохой доступ.
3.2 *nix - IP протокл часть ядра - вывод думаю понятен.

ЗЫ: разбирать что хорошо, а что плохо на самом деле глупо... наше дело получать фан, дело разработчиков обеспечить обеспечить нам этот фан )))... насколько хорошо они это делают мы и так все видим, и у видим в будущем.

ЗЫЫ: Не стреляйте в пианиста, играет как умеет (С) надпись в американском салуне 1800 лохматый год.

Обожаю теоретиков с тезисами из "кулхацера".
Даёшь холивар!


P.S.
Замечу, что серьёзные *nix профи никогда безапеляционно не заявляют о превосходстве *nix'ов над виндой - это удел "вьюношей бледных, со взором горящим".

[Psihius]

Нде, народ жгёт. Особенно на тему баз данных

EVE изначально работает на MSSQL серверах. По той простой причине, что когда его начинали делать - mysql ещё был дестким лепетом, да и PostgreSQL тоже не настолько хорош. В такого типа апликациях нужны тригеры, полноценные процедуры и прочие нужные вещи, котороых тогда в первом небыло, а второй был ещё слишком медлителен (да и найти хорошего специалиста по PostgreSQL сложно).

В плане чистой скорости шустрее всех MySQL, при условии что его правильно использовать и оптимизировать. MySQL одна из самых простых СУБД, там мало наворотов - поетому она и быстрее, т.к. лёгкая.

Другое дело если смотреть на возможности и их реализацию, то MySQL в этом плане проигрывает PostgreSQL и MSSQL. Почему они не выбрали PostgreSQL - знают только они, но я думаю в то время небыло ни той поддержки, ни той надёжности, ни специалистов. А MSSQL и поддержка, и специалисты, и по возможностям подходил, ну и существенно дешевле чем Oracle.

А так, если заняться оптимизацией любой СУБД, можно добиться хороших результатов в скорости работы. Разница только в том, что в MySQL таких механизмов очень много и много разного типа storage engines, что позволяет делать одну базу сразу на нескольких типах движков в зависимости от задач - это и позволяет выжать очень большую производительность из MySQL. А пример консалтинговой компании Percona с её форком InnoDB, который уделывает на больших базах и многопроцессорных системах стандартный InnoDB чуть ли не в разы, прекрасно илюстрирует что ещё можно сделать патчами и доработками (google кстати использует именно MySQL для всего, что не связанно с поиском - потому что быстро и не жадно до ресурсов).
А ещё есть MySQL NDB Cluster - ни у MSSQL, ни у PostgreSQL ничего подобного нету (в плане технической реализации, кластеры у них конечно есть), а то, сколько из этого можно выжать производительности при должном проектировании я вообще молчу.