x86 vs ARM: сложность инструкций

Там всё ожидаемо.

Оракл заточил своё железо под свою базу. И то, в ихних кластерах почему-то два ксеона для «sql processing» стоят :). Я не буду спорить что оракл знает толк в базах. Но это не доказывает что такое нельзя сделать на x86. Кстати, обычных бенчмарков sparc T5 что-то нигде нет.

Так бы давно уже были на ксеонах отказоустойчивые 16-32 сокетные сервера.

Исторически на рынке не присутствуют. Это не нужно большим вендорам, особенно hp и ibm которые свои процы пилили (hp itanium разрабатывала совместно с intel). А так есть и серваки с 4ТБ памятью от hp и xeon-ы с RAS (Reliability, Availability, and Serviceability). Кстати, вот на счёт «аппаратных фишек» как ты любишь: http://www.intel.com/Assets/PDF/whitepaper/323479.pdf :) Что касается 16-32 сокета то есть bullx S6030 с четырьмя сокетами которые могут формировать суперноды до четырёх узлов.

обычных бенчмарков sparc T5 что-то нигде нет

А это всё дурная практика запрета на публикацию результатов бенчей.

Кластеры это немного не то. Кластер в случае, скажем, СУБД Oracle это неминуемо RAC, а это в свою очередь, почти наверняка означает портирование, т.е. изменение продукта. Из реально больших систем с большой базой я лично имел дело только с Oracle M9000, IBM P595 и HP Superdome. Ничем похожим по надёжности на x86 не пахло тогда, и до сих пор не пахнет. Были надежды на Superdome 2 на ксеонах, но по крайней мере пока ничего нет.

Покажите мне систему на x86 в которой при выходе из строя половины памяти и процов не остановится сервис? На которой можно не выключая ничего продуктивного поменять или добавить процессоры и память, на ходу?

Пока что проприетарные risc платформы дают много того, чего нет на x86. То, что кому-то это всё не надо, не делает их в этом смысле менее крутыми для тех, кому оно надо.

Если убрать фактор цены, то железо, конечно крутое. Вопрос не в том что «не надо». Это просто оочень дорого.

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

Кластер налагает ряд ограничений, например, на то что можно использовать в оракловой базе. Пайпы и т.п. в RAC не будут работать. Подходы к управлению производительностью и многое другое отличаются для standalone db и для clustered db.

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

А то, что x86 серверы стоят сильно дешевле и будущее за ними - очевидно. Так же, как и то, что будущее за дешёвым аутсорсом (где на одного гуру приходятся десятки «негров»-студентов), а не за квалифицированными высокооплачиваемыми собственными админами. Вопрос только в том, насколько это хорошо. И вообще, вопрос в том, стоит ли проводить «оптимизацию» бизнеса, направленную исключительно на снижение издержек. Может быть, лучше направлять усилия на то, чтобы бизнес приносил больше выручки? :)

Т.е. нагрузка должна поддерживать кластеризацию, что не всегда реализуемо.

Вопрос в том насколько часто это не реализуемо. Я понимаю что гораздо проще отвалить кучу бабла и дать умным дядям решить все проблемы.

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

Все об этом мечтают :) Когда ты начинаешь бизнес он не станет приносить сразу много бабла. Он может вообще не приносить существенного заработка N лет. Ты не можешь взять и купить большую тачку, придётся брать то на что деньги есть. И если на этом этапе сделать масштабируемую архитектуру то проблемы производительности будут решаться докупкой нового железа.

Т.е. можно деньги вкладывать в железо, а можно в ПО. Тут уж кому что больше нравится. Я считаю что надо искать баланс.

Вопрос в том насколько часто это не реализуемо. Я понимаю что гораздо проще отвалить кучу бабла и дать умным дядям решить все проблемы.

Лично я это видел в жизни, в банковской среде, в телеком индустрии. Как правило, это большая (десятки и сотни терабайт данных) оракловая база с логикой внутри, десятки тысяч сессий и всё это в итоге на одном физическом сервере. Конечно же, пока это не x86

Что касается оптимизации - это моя больная мозоль. Не хочу заниматься, но приходится...

десятки и сотни терабайт данных

десятки тысяч сессий

на одном физическом сервере

Неужели это нельзя разбить шардингом? На вопрос «зачем» отвечу «чтоб дешевле».

Пайпы и т.п. в RAC не будут работать.

Что такое «пайпы»?

Неужели это нельзя разбить шардингом?

Чем разбить?

Оракловые конвейры или пайпы: http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_pipe.htm

Чем разбить?

Руками на этапе проектирования и внедрения.

Оракловые конвейры или пайпы

Честно говоря, вижу какой-то адский код на смеси бейсика, sql и c. Но вот почему на RAC не работают эти pipes я не понял. Смахивает на урезание продукта, оракл это любит. И вообще, такие вещи давно обкатаны. Берёшь какой-нить большой enterprise message bus и обмениваешься данными между любыми тачками, а не только локально команды дёргаешь.

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

Касательно RAC - эта хрень ведь не просто так стоит своих денег и по сути не имеет аналогов. Скорее всего дело не в искусственных ограничениях.

Этот вопрос лучше задать спецам по большим ораклам, а я не DBAшник, мне только вершки известны.

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

Мы говорим о готовых продуктах под ключ или о разработке таких продуктов?

Всё равно кто-то пишет это ПО. Вот эти люди могут заложить в систему нужные свойства. Только тут конфликт интересов. Исполнителю хочется «направлять усилия на то, чтобы бизнес приносил больше выручки». У заказчика же стремление сокращать издержки.

ведь не просто так стоит своих денег

По мне так в большинстве случаев не стоит :(. Как минимум пока счёт не идёт на сотни гигов данных. Вообще, тут даже не объём важен, а то что ты с этим делаешь. На посгресе тоже не вопрос сделать многотеррабайтные базы даже в пределах одной тачки (пруфы в гугле). И, конечно, возможности и суппорт будут не те что в оракле. Но тут надо определиться что нужно.

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

А то можно долго хвастаться, например, «а моя СУБД держит триггеры на C». Но когда я столкнулся с сишными триггерами в боевом продукте мне захотелось убивать. Там где было достаточно key-value БД воткнули ппц который программисты за 9 или 10 месяцев так и не смогли нормально отрефакторить. И так со многими фичами. У меня знакомый на стажировке работал программистом БД банка (и такое бывает) в одной братской республике, так там такой индусокод был... Не удивительно что нужны тачки размером с комнату чтобы функции over 64k строк|кб (уже не помню) работали. Доходило до маразма, функцию били на две потому что возможности субд не позволяли создавать одиночные функции такого объёма.

В реальности это выглядит так: Есть софтовый продукт за $100500 тыщ. Для твоих нужд чтобы использовать этот продукт надо ещё железку за $100500 тыщ. Ты говоришь, а давайте, я вместо этой железки использую кластер x86 за $100500/2. Вендор говорит - ради бога, но нашему продукту для работы на кластере нужно доработки, стоимость доработок будет к основной сумме ещё $100500/2, и полгода времени. Поэтому пока что железки за $100500 всё ещё продаются, не смотря на наличие более дешёвых и производительных на сокет x86 железок.

Пока что я не вижу альтернативы oracle или ibm в промышленных БД mission critical, в тех же телекоме и банках. Если есть истории успеха x86 - буду очень рад познакомиться, ибо сам сейчас вынужден оную писать...

ибо сам сейчас вынужден оную писать...

вот ты нам и расскажешь :)

Да вот очень не хотелось бы. К сожалению, найти новую работу не так просто оказалось...