Флуд на тему "Win vs. *nix" из темы "PC vs Laptop"

[svu]

Ежу понятно, что мускул во многом отстает от оракла. Но это не повод задирать нос и формулировать "не RDBMS!"

[Stingray]

Сообщение от ixania

query план оптимайзеру в мускуле и в других опенсорсных базах, до уровня ms sql, oracle and db2 как до луны пешком, к сожалению...

Граждане. Я вот вас не понимаю. Вот вы сидите, постите сюда одно и то же, и совсем при этом интернет не читаете?
На украине вот, говорят, эпидемия свиного гриппа - а власти скрывают.
А в этом посте говорят, что MS SQL излечивает от всех болезней.
А ещё говорят, что если загрузить в MS SQL что-то нетривиальное - то нужно все запросы творчески переписывать. И тут же пишут, что это всё сделает оптимайзер.
Так вы уж определитесь - переписывать или оптимайзер. Потому что если переписывать, то можно взять и самый простой MySQL (или даже Bigtable) и написать всё так как нужно.

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

[YellowMan]

Сообщение от rojer

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

Не факт - мускул хорош только под определенные задачи, да насколько я знаю Гуглу таки пришлось написать googleFS или как его там под мускул.

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

Я в принципе всегда готов к честному сравнению мускула и мс скл на типичных задачах. Как например на tpc.org - мускул там кстати никогда не засветился. с чего бы это?

Ну а насчет эффективности - давай сравним допустим по отношению transaction per second / people
У меня суммарно примерно 150-200 000 tps обслуживают 3 человека. Зона нашей ответственности заканчивается там где заканчивается сетевой кабель от серверов БД.
А как у адвордс, включая, тебя, разработчиков, тех кто бекапит итд?

YellowMan добавил 06.11.2009 в 10:16

Сообщение от svu

Но это не повод задирать нос и формулировать "не RDBMS!

Повод-повод. Мускул не management system ни разу. Просто RBD сервер который только недавно научился ACID. И нифига он не соответствует стандарту ANSI SQL потому что в стандарте прописаны вещи которые в нем не реализованы.

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

[rojer]

> googleFS или как его там под мускул.

нет, GFS не имеет никакого отношения и никак не связана с mysql.

естественно я тут не один, нас по 6 человек в дублине и маунтин вью, и мы занимаемся не только бэдой, бэда только часть нашей ответственности.
я не буду вдаваться в подробности, но приведу тебе такой простой расчёт - если бы каждый процессор облагался данью в 50 килобаксов, то при числе серверов 2000, среднем числе процов 3 (часть 2-, часть 4-сокетных машин) и средней з/п сотредника 100 тыс. в год (всё очень грубые аппроксимации), можно было бы нанять и год кормить 3000 человек.
и даже самый скромный SQL Server 2008 R2 Standard Edition, стоящий жалкие 7500 баксов на проц, позволил бы нанять в нашу команду ещё 450 человек.

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

[nikulina]

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

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

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

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

Сообщение от YellowMan

Мускул не management system ни разу.

- не надо, это смешно звучит

[YellowMan]

О чем и речь - вы слишком нестандартная компания, ваш частный случай не показывает общей картины.
Ты можешь перечислить сколько компаний в мире запускают базу на 6000 процессорах? Хотя вполне возможно что пользуя мс скл или оракл вы бы обошлись 500 процессорами. И вполне может быть вам бы хватило бесплатных версий.

И я так понимаю ты не споришь что мускул лучше мс скл? То что для ваших задач он выгоднее я уже понял

YellowMan добавил 06.11.2009 в 11:26

Сообщение от nikulina

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

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

В твоем сравнении лучше смотрится мыло и допустим, зола. И тем и другим можно стирать, и золу можно достать бесплатно. Вот только стирка займет раз в десять больше времени и результат будет так себе.
В принципе я уже писал - готов поставить бутылку коньяка на МС СКЛ. Есть желающие?

YellowMan добавил 06.11.2009 в 11:28

Сообщение от nikulina

- не надо, это смешно звучит

А почему? Можешь мне в мускуле сделать аналитику данных?

YellowMan добавил 06.11.2009 в 11:29

Сообщение от rojer

нет, GFS не имеет никакого отношения и никак не связана с mysql.

http://code.google.com/p/mysql-filesystem-engine/ - это вроде?

[nikulina]

Сообщение от YellowMan

http://code.google.com/p/mysql-filesystem-engine/ - это вроде?

даже я знаю, что это мимо

This is a project for the MySQL Filesystem storage engine. It translates normal files on your server into relational tables inside of MySQL.

то, что ты нашел - это я так понимаю, гугл выделил место под чужие проекты.

http://labs.google.com/papers/gfs.html - вот оно настоящее. которое gfs

[YellowMan]

Не, gfs это другое - это для поиска. Они там пишут 10 из примерно 10 000 результатов.
База данных заканчивается там где начинается слово "примерно"

Я слышал что гугл писал свой storage engine для мускула. ибо все существующее их не устраивало. Если это так то мы говорим не о том что Гугл использует мускул а о том что гугл на основе мускул создал свою базу под свои нужды, так будет правильнее.

[nikulina]

Сообщение от YellowMan

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

я, конечно, не DB-админ, но тем не менее - indexed view частично можно обойти просто индексами для таблицы. понятно, что надо конкретизировать ситуацию, но таки оно необходимо сильно не всегда.
а про блокировки - это только вопрос скорости работы нескольких приложений

[rojer]

YM> О чем и речь - вы слишком нестандартная компания, ваш частный случай не показывает общей картины.

в этом месте как раз всё довольно стандартно. нашу основную веб-аппликуху кроме большого числа одновременных юзеров ничего особенно не отличает - это ява, кой-какой middle tier и, собственно, mysql. всё интересное - в сервинге (то, что отдаёт рекламу) и статистике (то, что считает показы и клики, строит отчёты).

в общем, по-моему всё настолько очевидно, что даже и спорить не о чем. если в своё время сделать правильный выбор, то смасштабированное решение на mysql будет экономить *огромные* деньги. проблема, конечно, в том, что никогда не знаешь, что надо будет масштабировать, а что так и останется на всю жизнь на одном сервере, за который, так уж и быть, можно отвалить 7.5 кусков (но 57? хм...)

rojer добавил 06.11.2009 в 11:54
YM> Я слышал что гугл писал свой storage engine для мускула.

это как раз относится к "интересному" - статистике. да, рядом с мускулем стоят ещё пара тысяч серверов, которые гоняют специальную приблуду для того, чтобы можно было сказать, условно говоря, select X from DailyCampaignStats where ... и оно не уходило в себя на сутки
они - тоже в нашей ответственности.

YM> ибо все существующее их не устраивало.

с таким rate of updates, как у статистики adwords и adsense, не справится ни одна SQL-ная база, я тебе гарантирую это. грубо говоря, если бы на каждый показ "ads by google" шёл update или insert, всё бы нафиг легло и мёртво лежало, даже без селектов

YM> Если это так то мы говорим не о том что Гугл использует мускул а о том что гугл на основе мускул создал свою базу под свои нужды, так будет правильнее.

вот у меня к тебе встречный вопрос - а мог бы ты к своему варехаузу за 57 килобаксов прикрутить свой специальный storage engine, который делает то, что тебе надо?

и нет, mysql-filesystem-engine - это не оно. этого нет в открытом доступе.

[nikulina]

Сообщение от YellowMan

Можешь мне в мускуле сделать аналитику данных?

вот потому и смешно, что - по-твоему, мускуль недостоин называться management system из-за отсутствия аналитики

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

[Stingray]

Сообщение от YellowMan

Не, gfs это другое - это для поиска. Они там пишут 10 из примерно 10 000 результатов.
База данных заканчивается там где начинается слово "примерно"

Я под стол.

P.S. Про гугл много чего в интернете пишут. И далеко не всё из этого - бред. Поэтому перед тем как что-то восклицать, вполне можно ознакомиться, например, с этим: http://glinden.blogspot.com/2009/02/...wsdm-2009.html

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

Хотя зачем я это рассказываю

[YellowMan]

Сообщение от rojer

это как раз относится к "интересному" - статистике. да, рядом с мускулем стоят ещё пара тысяч серверов, которые гоняют специальную приблуду для того, чтобы можно было сказать, условно говоря, select X from DailyCampaignStats where ... и оно не уходило в себя на сутки
они - тоже в нашей ответственности.

YM> ибо все существующее их не устраивало.

с таким rate of updates, как у статистики adwords и adsense, не справится ни одна SQL-ная база, я тебе гарантирую это. грубо говоря, если бы на каждый показ "ads by google" шёл update или insert, всё бы нафиг легло и мёртво лежало, даже без селектов

Роджер, я честно говоря не понял зачем вам вообще база данных если агрегатируют данные какие-то "еще пару тысяч серверов" и у вас нет апдейта и инсерта?

Я так понимаю что эта приблуда работает следующим образом: Вы где-то отдельно, при помощи специального софта скорее всего в памяти серверов накапливаете данные по адвордс, потом агрегатируете там-же и потом в базу сливаете агрегатированные данные уже готовые для аналитики или биллинга.
Если это так то я сейчас не буду говорить про релаибилити такого подхода ( это типа когда один из серверов сдох не успев слить аналитику в базу и часть данных оказались потеряны. Кстати люди жалуются на точность адвордс - может быть и из-за этого?).
Я буду говорить про то что вы используете мускул просто как большое хранилище в которое 99.9999% времени заливается последовательные данные- это даже не OLTP и не OLP.
Тогда я вас понимаю, да. Вам мускул подойдет, вы не используете и 5% всех возможностей современных RDBMS и ничего сложнее мускула вам и не надо в принципе.
Да и вполне может быть что для ваших объемов - это действительно единственный выход.

Сообщение от rojer

вот у меня к тебе встречный вопрос - а мог бы ты к своему варехаузу за 57 килобаксов прикрутить свой специальный storage engine, который делает то, что тебе надо?

Да конеччно - в МС СКЛ это называется CLR, поддерживает .Net. У Оракла свой путь, там жаба.

Сообщение от rojer

если в своё время сделать правильный выбор, то смасштабированное решение на mysql будет экономить *огромные* деньги. проблема, конечно, в том, что никогда не знаешь, что надо будет масштабировать, а что так и останется на всю жизнь на одном сервере, за который, так уж и быть, можно отвалить 7.5 кусков (но 57? хм...)

Проблема в том что с расширением функциональности приложения упираешься в принципиаьные ограничения мускула. Я помогал многим конторам переходить с мускула на Оракл или МС - и ни одной в обратном направлении.

Сообщение от nikulina

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

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

Сообщение от nikulina

а про блокировки - это только вопрос скорости работы нескольких приложений

Вообще-то блокировки - это самое ядро блокировочной базы. Мускуль тоже блокировочник - и заявлять что он умеет делать только табличную блокировку это как выставлять автомобиль с паровым двигателем на угле на гонки Ф-1.

Сообщение от Stingray

Ну и да, коммерческую базу пробовали.

Коммерческая база поддерживает ACID. Google search ACID не поддерживает, да и не нужен он там. О чем еще говорить?

[rojer]

YM> Роджер, я честно говоря не понял зачем вам вообще база данных если агрегатируют данные какие-то "еще пару тысяч серверов" и у вас нет апдейта и инсерта?

YM> Я так понимаю что эта приблуда работает следующим образом: Вы где-то отдельно, при помощи специального софта скорее всего в памяти серверов накапливаете данные по адвордс, потом агрегатируете там-же и потом в базу сливаете агрегатированные данные уже готовые для аналитики или биллинга.
YM> Если это так то я сейчас не буду говорить про релаибилити такого подхода ( это типа когда один из серверов сдох не успев слить аналитику в базу и часть данных оказались потеряны. Кстати люди жалуются на точность адвордс - может быть и из-за этого?).

это твои домыслы, на которые я уже не могу отвечать. но с reliability всё в порядке, будь уверен. если интересно как это устроено, приходи к нам поработать

YM> Я буду говорить про то что вы используете мускул просто как большое хранилище в которое 99.9999% времени заливается последовательные данные- это даже не OLTP и не OLP.
YM> Тогда я вас понимаю, да. Вам мускул подойдет, вы не используете и 5% всех возможностей современных RDBMS и ничего сложнее мускула вам и не надо в принципе.

ты забываешь про большое количество данных о собственно юзерах, кампаниях и т.п. они тоже постоянно меняются (юзерами, из интерфейса) и имеют сложную реляционную модель (МНОГО таблиц).

YM> Да и вполне может быть что для ваших объемов - это действительно единственный выход.

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

>>вот у меня к тебе встречный вопрос - а мог бы ты к своему варехаузу за 57 килобаксов прикрутить свой специальный storage engine, который делает то, что тебе надо?
YM> Да конеччно - в МС СКЛ это называется CLR, поддерживает .Net. У Оракла свой путь, там жаба.

CLR - это common language runtime, aka .Net? не, вот ты мне покажи аналог мускульного storage engine интерфейса. как сделать так, чтобы SELECT blah шёл на моё аппликуху, которая делает то что мне нужно.
просто прими как данность, что не все данные можно эффективно засунуть в саму бэду и в ней их апдейтить. а селектить и джоинить с другими интересными данными (о клиентах, кампаниях - вот что хранится и апдейтится в бэде) хочется.

[zdragon]

Сообщение от nikulina

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

a как например foreighn keys, constrаints..
это ведь не примочки а самое то необходимое чтоб заиметь consistent database..
так вот берите например zen carт, osComemrce, загляните во внутрь и увидите кучу потерянных связей, а потом берите и чините это все, чтоб босс имел правильный репорт.. и это без примочек как оптимайзер, SSIS, и репорт энджин..