Как стать автором
Обновить

Комментарии 78

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

а вам потеме - PostgreSQL vs MySQL, знаю что можете обидется на коментрий, не стоит, мне бы самому посмотреть эти тесты.


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

как говрится - техника в руках индийца...
"как говрится - техника в руках индийца..."
Не знаю такой шутки. Как я понял стоит выбор между скоростью и возможностями. В прошлом году, имея под рукой Оракл, я частенько использовал Access и FoxPro.
[offtop]
Всётаки Александр :)
[/offtop]
ф
Ну реально работающих с большими БД не так много,
есть шанс что они найдутся здесь - ну или поможет НЛО.

Холивара не надо - для этого есть другие ресурсы :-)

Можете заминусовать меня, но тема думаю актуальна для
многих популярных ресурсов.
Согласен. Опыт знающих людей был бы очень к месту. А то хватает нынче холиварщиков, которые тупо долбят свой любимый продукт, будь то FF, Pg или iMac :).
замечу что зрительно PgSQL быстрее чем MySQL на сложных запросах (mediawiki). Данных у нас там пока не очень много, как будет дальше — будем смотреть.
Хех. Не попадаю в вашу категорию у меня всего 13.5 миллионов :)
НЛО прилетело и опубликовало эту надпись здесь
Ну при росте записей попадете ;-)
если не секрет работали ли с такими обьемами в MySQL
есть ли репликация и кластеризация в текущей схеме.

Просто есть идея поставить эксперимент, взять индентичное железо
и потестировать - я практик по натуре :-)
В текущей схеме репликации и кластеризации нет. Как-то пока не надо.

В MySQL у меня как-то была база в 100 гиг. У MyISAM иногда рушились индексы. InnoDB после некоторой настройки тащила. Но у MySQL с InnoDB была проблема с масштабируемостью ввода-вывода, но в новых версиях фиксы уже есть.
У меня был опыт хранения 3-х миллиардов в MySQL. :)
После этого хранение было переписано на BDB. =)
Следующий этап - ФС. Не шучу. Это опыт.
В той конкретной задаче — вряд ли, а вообще — да.
У нас уже есть своя БД.
сдается мне я вас знаю, молодой человек :)
mysql> select count(*) from report_campaign_site_city;
+----------+
| count(*) |
+----------+
| 32524819 |
+----------+

:)
было бы неплохо указать тип таблицы и общее время запроса ;)
поясняю... MyISAM...

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

запрос:

mysql> select campaign_id, site_id, city_id, sum(impressions), sum(clicks) from report_campaign_site_city where day='2007-02-01' group by campaign_id, site_id, city_id;

79141 rows in set (1.33 sec)

данные приводить не буду, ок? :)

машина — 2 проца Intel Xeon CPU 2.80GHz, 4 гига мозгов, RAID-5 на скази
А теперь тоже самое но в count поместите вместо * одно из полей таблицы без индекса :)
mysql> select count(impressions) from report_campaign_site_city;
+--------------------+
| count(impressions) |
+--------------------+
| 32647895 |
+--------------------+
1 row in set (0.00 sec)
ну да вообще-то MyISAM %) Это на InnoDB подругому.
а, ну ясно, myisam общее число кеширует, а по структуре это похоже на лог, в который просто идут пачками инсерты и превед - кстати лишний раз блин всяким умникам наука думать башкой и мерять прежде чем теоретизировать, MyISAM ещё всех нас переживёт. я думаю сашу конкурентные апдейты интересовали но он так задал вопрос что сам себе злобный буратина :)
да, там инсерты идут пачками... я вообще-то хотел показать размер таблицы, а не скорость ее работы :) но что мои 32 миллиона с миллиардами постом выше :)
Vinny - с тобой и так все ясно :-)
меня интересуют независимые тесты - вроде все описал.. :-)
Тут вопрос скорее не в количестве записей а в сложности структуры БД. PostgreSQL предоставляет инструментарий совершенно другого уровня нежели MySQL. Я на постгре уже 2 года, на мускул не тянет.
Ну не совсем показательный - где вы видели сервер бд с 256RAM ;-)
Идея такая берется железо из 1 партии, файловая система тюнится одинаково,
а скорее по дефолту.

1 тест - на дефолтных настройках(по умолчанию)
2 тест - на оптимизированных под память и обьем бд

Приложение и группы тестов одинаковое.
В свое время я так проводил тесты различных оберток Perl и PHP,
на достаточно сложной базе типа Dejanews (теперь жто GoogleGroups)
Ну в этом примере (я не знаю, почему такая слабая машинка для теста была взята), как мне кажется, надо смотреть не абсолютные показатели, а относительные: кто кого быстрее и т.п.

Ну а вообще вы правы.
видим чтобы разница была заметнее.
Я когда recource pools изучал для Oracle 10 — использовал ноут toshiba с 256 метров памяти. под WinXP SP2 этого хватало только на пуск instance-а, переключится с терминала на терминал я уже не мог :)
Кстати, на следующей неделе в Москву приезжает Петр Зайцев - специалист по mysql с мировым именем. Будет выступать на РИТ (понедельник-вторник) и на собственном семинаре (среда). Думаю, он может много рассказать по данному вопросу :)
6 миллионов записей могут вызывать проблему при использовании любой СУБД.
текущие версии (8.2.х) Постгреса очень сильно отличаются от 7.х, производительность несколько раз улучшалась существенно.

Кстати, на следующей неделе на том же РИТ-2007 будет несколько специалистов по Постгресу, в том числе PostgreSQL major developers (тоже мировые имена ;-) ) Олег Бартунов и Фёдор Сигаев. Они могут рассказать про опыт использования Постгреса на Очень Больших Базах (например, про астрономические — во всех смыслах этого слова :-) — объёмы данных).
Упс. Вроде как в корень писал, а вышло вылезло ответом.
Точно, будут! По моему, в секции Базы Данных вообще будет очень интересно.
Мускул отлично и быстро работает для веб-сайтов.

А кто не умеет писать запросы, тем и Оракл не поможет. Компьютер человеческую глупость никогда не победит.
Для сайтов и файловой системы хватит ;)

Тут речь об оочень больших объёмах.
> Тут речь об оочень больших объёмах.

Крута! Большие объёмы!!! Офигеть!
Ты, чувак, знаешь о чём говоришь, раз такие крутые слова знаешь!

Причём тут большие объёмы вообще? Мускул быстро работает и гигабайтовыми базами и каши не просит. Единственное ограничение - ограничение файлухи на размер файла. И всё. Остальное - твои фантазии.
Ну действительно, 1000 записей или 10 млн, разницы совсем никакой. Признаю, не прав)))
Большие объёмы данных подразумевают большое количество запросов. Масштабируемость MySQL фиговая по сравнению с PostgreSQL (ссылка была выше).
На маленьких базах InnoDB и PostgreSQL примерно равны.
Для совсем маленьких баз можно использовать что угодно и пофигу, работает MyISAM в 10 раз быстрее InnoDB/PostgreSQL или нет.
Я выбираю PostgreSQL по причине лучшей масштабируемости и нормальной поддержки SQL по умолчанию. Ну и всякие репликации/балансировки для Постгреса повеселее развиваются.
Дополню немного. MyISAM дохнет на множественных одновременных операциях записи/чтения так как поддержки транзакций нет, есть только поддержка блокировок. InnoDB с настройками по умолчанию полная ерунда без использования транзакий. А так как большая часть приложений работающая с MySQL о транзакциях не знают, то испольуется autocommit. В результате за счет использования ACID и записи каждой транзакции сначала в лог, а потом в базу, производительность падает ниже плинутса. Проблема лечится только отключением ACID.
> MyISAM дохнет на множественных одновременных операциях записи/чтения так как поддержки транзакций нет, есть только поддержка блокировок.

Большего бреда не читал...
Для тех кто считает, что это бред советую обратиться с документации MySQL к примеру вот этот документ
http://www.mysql.com/news-and-events/pre…

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

Если вы много пишите и читаете в/из одной таблицы, то руки Вам надо поотрывать. Надо или много писать или много читать. Если не выходит, то применять кэширование. Тот же memcached отлично помогает при подобных задачах, сводя чтение из таблицы к минимуму.

Кроме того таблицы по многим причинам лучше разбивать на несколько таблиц.

Кроме того, если БД большая, то вам в любом случае САМОСТОЯТЕЛЬНО придётся писать разнесение данных на несколько серверов. Репликация вам не поможет.

У Фицпатрика и у Петра Зайцева есть хорошие презентации про большие БД на mysql.

Майисам не дохнет, если всё правильно делать.

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

Как вы думаете зачем были придуманы СУБД и транзакции? А так же часто может возникать вопрос, зачем мне СУБД если я или много пишу или много читаю?


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

Если не выходит, то надо взять СУБД с поддержкой транзакций и версионности.


Кроме того, если БД большая, то вам в любом случае САМОСТОЯТЕЛЬНО придётся писать разнесение данных на несколько серверов.

Может стоит использовать СУБД с поддержкой GRID ? К примеру Oracle?


У Фицпатрика и у Петра Зайцева есть хорошие презентации про большие БД на mysql.

MySQL можно использовать до определенного предела. И этот предел определяется не объемом данных, а сложностью структуры самой базы и используемой внутри нее бизнес-логикой. У вы в этом плане MySQL хромает довольно сильно.
У Фицпатрика этот предел не наступил почему-то...

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

У Фицпатрика этот предел не наступил почему-то...

А он использует хранимые процедуры и триггеры в MySQL? И большая часть бизнес-логики обрабатывается в базе?


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

Судя по тому что вы начали переходить на личности, то по сути вопроса вам возразить нечего? А если же пройтись по моим и вашим коментариям, то как-то получается, что это вы научились только вчера писать селекты.
> А он использует хранимые процедуры и триггеры в MySQL? И большая часть бизнес-логики обрабатывается в базе?

Боже упаси. Ниодин посещаемый проект не использует всю эту ерунду.

Боже упаси. Ниодин посещаемый проект не использует всю эту ерунду.

Не вебом единым. А если у вас действительно посещаемый проект, то это повод подумать о других базах данных отличных от СУБД. Ни один нагруженный ресурс СУБД не использует.
> Ни один нагруженный ресурс СУБД не использует.

Давно на Вас это откровение снизошло?
Я вот думаю когда на вас сойдет откровение о том, что СУБД можно использовать не только в вебе.

PS Может вы придержите свою зашореность при себе? А то она прет изо всех щелей.
вы такой толстый тролль, месье.
"Истинно говорю вам" - Skype в качестве бизнес-логики использует ХП, но - на Postgres ^)
НЛО прилетело и опубликовало эту надпись здесь
Вы меня настолько удивили своим хамством, что я просто в шоке. Ни одного слова по сути, все высказывания сводяться к тому, что вы крутой, а все тут ослы.
Может у вас дипресия или стрес какой, не надо тут злость свою срывать. Реакция людей незамедлительна - гляньте на свою карму :/
> все тут ослы.

Так и есть. На хабре все ослы.
И транзакции совершенно не спасают от больших нагрузок, а скорее наоборот.
Да ? Если брать версионную СУБД и с поддержкой транзакций, то когда вы явно не объявляете транзакцию, то транзакция все равно выполняется. Т.е. если вы явно объявите транзнакцию и выполните в ней 10-20 действий и завершите ее, то сервер выполнит ее в виде одной атомарной операции. В случае же если вы не объявите транзакцию и выполните 10-20 операций, то каждая операция будет завернута в отдельную транзакцию. Именно из-за этого InnoDB с включенным ACID работает так не важно.
Забудьте про трранзакции - это фича для бухгалтерских БД. Для веба они вредны.
О дааа. У нас оказывается весь мир использует транзакции только в бухгалтерских БД. И в биллингах никто их не использует и в обработке данных никто не использует. Ню-ню.

Для нагруженных веб-проектов вредно использовать традиционные СУБД. Специфика не та.
Ткните пальцем где я писал о том что я специалист и я не стану бить вас по морде.

Могу сделать вывод, вы просто тупица, пытающийся вставить свои пять копеек, не удосужевшись прочитать о чём идёт речь.
Продолжая мериться письками,
http://michael.mindmix.ru/87-411-ovebdva…
Вы действительно считаете, что аякс (в том виде в котором вы его описали) снижает нагрузку на сервер? :) Типа заменив гостевую на чат вы сэкономили ресурсы...
Ну да ладно, я не собираюсь спорить.
На Хабре всё вышеперечисленное есть с незапамятных времён =) Правда, реализовано отвратительно.
При этом я считаю, что такая фича полная ерунда и рефреш страницы ничего страшного не делает.
Опять же, зачем что-то считать...

Юзерам нравится так общаться. И это главное. Новые комменты подгружаются почти сразу. Очень удобно. Общаешься как в аське.
А чего тут спорить? мне же видно как меняется нагрузка на моём сервере...

Откуда Вы берёте эту информацию о моём сервере, я не знаю...
А выбор между MySQL и PostgreSQL - предопределён? А то ведь есть DB2 Express-C, которая бесплатна. Главное - вписаться в конфигурацию железа. А уж DB2 - это DB2.
DB2 - тоже использовал - там поле с датой жгет :-)
С чего бы это вдруг? Завести как дату/время и пользовать корректно
угу и Sybase'овская линейка ASE от бесплатных до дорогих...
Раньше работал в ISP ведущим сисадмином. Там вся база клиентов, их наработка, почтовик, логи раньше хранились в MySQL. По словам старожил это была сущая головная боль. Года 2 назад переехали на PostgreSQL и проблем стало существенно меньше.

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

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

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

З.Ы: И в мыслях небыло навязывать кому-то свое мнение. Каждое средство должно быть вовремя и к месту.
а как с инструментами DBA? кто что пользует? это при работе с БД тоже большое значение играет
При больших объемах стоит посмотреть в сторону mysql cluster.
Вы хоть представляете как устроен кластер в MySQL?
Что уже есть терабайтные модули памяти? :-)
Я очень даже себе представляю, так как плотно работаю с ним около 2-х лет.
Планок конечно нет, зато 5.1 уже хранит неиндексируемые данные на диске, кроме того, что мешает "размазать" данные по нодам, тем самым уменьшив требования к RAM?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории