Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 78
Алексей (если я не ошибаюсь, вполен возможно что и Александр), думаю такой вопрос был бы болье существенен на форуме клуба всетаки =)
Имхо харабахабр, не для вопросов а скорее для публикаций.
а вам потеме - PostgreSQL vs MySQL, знаю что можете обидется на коментрий, не стоит, мне бы самому посмотреть эти тесты.
Кстати вы недавно про трениг по Постгре писали у них можете тестом перформенса поинтресоватся?
Имхо харабахабр, не для вопросов а скорее для публикаций.
а вам потеме - PostgreSQL vs MySQL, знаю что можете обидется на коментрий, не стоит, мне бы самому посмотреть эти тесты.
Кстати вы недавно про трениг по Постгре писали у них можете тестом перформенса поинтресоватся?
ну почему же не простой? очень даже простой. я не задумуясь выберу MySQL (а кто то PostgreSQL) и каждый из нас будет будет настаивать на определенных плюсах продуктов. на практике показано что не только от самой базы зависит - грамотно спроектированые запросы, распределение нагрузок, кеширование результатов запросов, освобождение ресурсов, постоянная оптимизация, правильно выбраный енджин для базы - даже при больших нагрузках позволт скажем мускулу или постгре не просто дишыть, а еще покурить на перерывах перестраивая индексы.
как говрится - техника в руках индийца...
как говрится - техника в руках индийца...
[offtop]
Всётаки Александр :)
[/offtop]
Всётаки Александр :)
[/offtop]
ф
Ну реально работающих с большими БД не так много,
есть шанс что они найдутся здесь - ну или поможет НЛО.
Холивара не надо - для этого есть другие ресурсы :-)
Можете заминусовать меня, но тема думаю актуальна для
многих популярных ресурсов.
есть шанс что они найдутся здесь - ну или поможет НЛО.
Холивара не надо - для этого есть другие ресурсы :-)
Можете заминусовать меня, но тема думаю актуальна для
многих популярных ресурсов.
Хех. Не попадаю в вашу категорию у меня всего 13.5 миллионов :)
Ну при росте записей попадете ;-)
если не секрет работали ли с такими обьемами в MySQL
есть ли репликация и кластеризация в текущей схеме.
Просто есть идея поставить эксперимент, взять индентичное железо
и потестировать - я практик по натуре :-)
если не секрет работали ли с такими обьемами в MySQL
есть ли репликация и кластеризация в текущей схеме.
Просто есть идея поставить эксперимент, взять индентичное железо
и потестировать - я практик по натуре :-)
У меня был опыт хранения 3-х миллиардов в MySQL. :)
После этого хранение было переписано на BDB. =)
После этого хранение было переписано на BDB. =)
mysql> select count(*) from report_campaign_site_city;
+----------+
| count(*) |
+----------+
| 32524819 |
+----------+
:)
+----------+
| 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 на скази
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 поместите вместо * одно из полей таблицы без индекса :)
а, ну ясно, myisam общее число кеширует, а по структуре это похоже на лог, в который просто идут пачками инсерты и превед - кстати лишний раз блин всяким умникам наука думать башкой и мерять прежде чем теоретизировать, MyISAM ещё всех нас переживёт. я думаю сашу конкурентные апдейты интересовали но он так задал вопрос что сам себе злобный буратина :)
Vinny - с тобой и так все ясно :-)
меня интересуют независимые тесты - вроде все описал.. :-)
меня интересуют независимые тесты - вроде все описал.. :-)
Тут вопрос скорее не в количестве записей а в сложности структуры БД. PostgreSQL предоставляет инструментарий совершенно другого уровня нежели MySQL. Я на постгре уже 2 года, на мускул не тянет.
Ну не совсем показательный - где вы видели сервер бд с 256RAM ;-)
Идея такая берется железо из 1 партии, файловая система тюнится одинаково,
а скорее по дефолту.
1 тест - на дефолтных настройках(по умолчанию)
2 тест - на оптимизированных под память и обьем бд
Приложение и группы тестов одинаковое.
В свое время я так проводил тесты различных оберток Perl и PHP,
на достаточно сложной базе типа Dejanews (теперь жто GoogleGroups)
Идея такая берется железо из 1 партии, файловая система тюнится одинаково,
а скорее по дефолту.
1 тест - на дефолтных настройках(по умолчанию)
2 тест - на оптимизированных под память и обьем бд
Приложение и группы тестов одинаковое.
В свое время я так проводил тесты различных оберток Perl и PHP,
на достаточно сложной базе типа Dejanews (теперь жто GoogleGroups)
Кстати, на следующей неделе в Москву приезжает Петр Зайцев - специалист по mysql с мировым именем. Будет выступать на РИТ (понедельник-вторник) и на собственном семинаре (среда). Думаю, он может много рассказать по данному вопросу :)
6 миллионов записей могут вызывать проблему при использовании любой СУБД.
текущие версии (8.2.х) Постгреса очень сильно отличаются от 7.х, производительность несколько раз улучшалась существенно.
Кстати, на следующей неделе на том же РИТ-2007 будет несколько специалистов по Постгресу, в том числе PostgreSQL major developers (тоже мировые имена ;-) ) Олег Бартунов и Фёдор Сигаев. Они могут рассказать про опыт использования Постгреса на Очень Больших Базах (например, про астрономические — во всех смыслах этого слова :-) — объёмы данных).
текущие версии (8.2.х) Постгреса очень сильно отличаются от 7.х, производительность несколько раз улучшалась существенно.
Кстати, на следующей неделе на том же РИТ-2007 будет несколько специалистов по Постгресу, в том числе PostgreSQL major developers (тоже мировые имена ;-) ) Олег Бартунов и Фёдор Сигаев. Они могут рассказать про опыт использования Постгреса на Очень Больших Базах (например, про астрономические — во всех смыслах этого слова :-) — объёмы данных).
В тему (мнение Петра Зайцева по поводу очередного сравнения My & Pg): http://www.mysqlperformanceblog.com/2006…
Мускул отлично и быстро работает для веб-сайтов.
А кто не умеет писать запросы, тем и Оракл не поможет. Компьютер человеческую глупость никогда не победит.
А кто не умеет писать запросы, тем и Оракл не поможет. Компьютер человеческую глупость никогда не победит.
Для сайтов и файловой системы хватит ;)
Тут речь об оочень больших объёмах.
Тут речь об оочень больших объёмах.
> Тут речь об оочень больших объёмах.
Крута! Большие объёмы!!! Офигеть!
Ты, чувак, знаешь о чём говоришь, раз такие крутые слова знаешь!
Причём тут большие объёмы вообще? Мускул быстро работает и гигабайтовыми базами и каши не просит. Единственное ограничение - ограничение файлухи на размер файла. И всё. Остальное - твои фантазии.
Крута! Большие объёмы!!! Офигеть!
Ты, чувак, знаешь о чём говоришь, раз такие крутые слова знаешь!
Причём тут большие объёмы вообще? Мускул быстро работает и гигабайтовыми базами и каши не просит. Единственное ограничение - ограничение файлухи на размер файла. И всё. Остальное - твои фантазии.
Ну действительно, 1000 записей или 10 млн, разницы совсем никакой. Признаю, не прав)))
Большие объёмы данных подразумевают большое количество запросов. Масштабируемость MySQL фиговая по сравнению с PostgreSQL (ссылка была выше).
На маленьких базах InnoDB и PostgreSQL примерно равны.
Для совсем маленьких баз можно использовать что угодно и пофигу, работает MyISAM в 10 раз быстрее InnoDB/PostgreSQL или нет.
Я выбираю PostgreSQL по причине лучшей масштабируемости и нормальной поддержки SQL по умолчанию. Ну и всякие репликации/балансировки для Постгреса повеселее развиваются.
На маленьких базах 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 этого не происходит из-за поддержки транзакций.
http://www.mysql.com/news-and-events/pre…
А так же попробовать осуществить транзакцию на базе использующей MyISAM в качестве движка. MySQL скажет что данная фича не поддерживается. А так как при записи MyISAM лочит всю таблицу, то запросы чтения ждут пока закончится запись. Причем хочу отметить, что на InnoDB этого не происходит из-за поддержки транзакций.
Майисам не дохнет, если всё правильно делать.
Если вы много пишите и читаете в/из одной таблицы, то руки Вам надо поотрывать. Надо или много писать или много читать. Если не выходит, то применять кэширование. Тот же memcached отлично помогает при подобных задачах, сводя чтение из таблицы к минимуму.
Кроме того таблицы по многим причинам лучше разбивать на несколько таблиц.
Кроме того, если БД большая, то вам в любом случае САМОСТОЯТЕЛЬНО придётся писать разнесение данных на несколько серверов. Репликация вам не поможет.
У Фицпатрика и у Петра Зайцева есть хорошие презентации про большие БД на mysql.
Если вы много пишите и читаете в/из одной таблицы, то руки Вам надо поотрывать. Надо или много писать или много читать. Если не выходит, то применять кэширование. Тот же memcached отлично помогает при подобных задачах, сводя чтение из таблицы к минимуму.
Кроме того таблицы по многим причинам лучше разбивать на несколько таблиц.
Кроме того, если БД большая, то вам в любом случае САМОСТОЯТЕЛЬНО придётся писать разнесение данных на несколько серверов. Репликация вам не поможет.
У Фицпатрика и у Петра Зайцева есть хорошие презентации про большие БД на mysql.
Майисам не дохнет, если всё правильно делать.
Если вы много пишите и читаете в/из одной таблицы, то руки Вам надо поотрывать. Надо или много писать или много читать.
Как вы думаете зачем были придуманы СУБД и транзакции? А так же часто может возникать вопрос, зачем мне СУБД если я или много пишу или много читаю?
Если не выходит, то применять кэширование. Тот же memcached отлично помогает при подобных задачах, сводя чтение из таблицы к минимуму.
Если не выходит, то надо взять СУБД с поддержкой транзакций и версионности.
Кроме того, если БД большая, то вам в любом случае САМОСТОЯТЕЛЬНО придётся писать разнесение данных на несколько серверов.
Может стоит использовать СУБД с поддержкой GRID ? К примеру Oracle?
У Фицпатрика и у Петра Зайцева есть хорошие презентации про большие БД на mysql.
MySQL можно использовать до определенного предела. И этот предел определяется не объемом данных, а сложностью структуры самой базы и используемой внутри нее бизнес-логикой. У вы в этом плане MySQL хромает довольно сильно.
У Фицпатрика этот предел не наступил почему-то...
А СУБД придумали, чтобы ей пользовались умные люди, а не гуанописатели, вчера научившиеся писать селекты и мнящие себя архитекторами баз данных.
А СУБД придумали, чтобы ей пользовались умные люди, а не гуанописатели, вчера научившиеся писать селекты и мнящие себя архитекторами баз данных.
У Фицпатрика этот предел не наступил почему-то...
А он использует хранимые процедуры и триггеры в MySQL? И большая часть бизнес-логики обрабатывается в базе?
А СУБД придумали, чтобы ей пользовались умные люди, а не гуанописатели, вчера научившиеся писать селекты и мнящие себя архитекторами баз данных.
Судя по тому что вы начали переходить на личности, то по сути вопроса вам возразить нечего? А если же пройтись по моим и вашим коментариям, то как-то получается, что это вы научились только вчера писать селекты.
> А он использует хранимые процедуры и триггеры в MySQL? И большая часть бизнес-логики обрабатывается в базе?
Боже упаси. Ниодин посещаемый проект не использует всю эту ерунду.
Боже упаси. Ниодин посещаемый проект не использует всю эту ерунду.
Боже упаси. Ниодин посещаемый проект не использует всю эту ерунду.
Не вебом единым. А если у вас действительно посещаемый проект, то это повод подумать о других базах данных отличных от СУБД. Ни один нагруженный ресурс СУБД не использует.
"Истинно говорю вам" - Skype в качестве бизнес-логики использует ХП, но - на Postgres ^)
Вы меня настолько удивили своим хамством, что я просто в шоке. Ни одного слова по сути, все высказывания сводяться к тому, что вы крутой, а все тут ослы.
Может у вас дипресия или стрес какой, не надо тут злость свою срывать. Реакция людей незамедлительна - гляньте на свою карму :/
Может у вас дипресия или стрес какой, не надо тут злость свою срывать. Реакция людей незамедлительна - гляньте на свою карму :/
И транзакции совершенно не спасают от больших нагрузок, а скорее наоборот.
Да ? Если брать версионную СУБД и с поддержкой транзакций, то когда вы явно не объявляете транзакцию, то транзакция все равно выполняется. Т.е. если вы явно объявите транзнакцию и выполните в ней 10-20 действий и завершите ее, то сервер выполнит ее в виде одной атомарной операции. В случае же если вы не объявите транзакцию и выполните 10-20 операций, то каждая операция будет завернута в отдельную транзакцию. Именно из-за этого InnoDB с включенным ACID работает так не важно.
О, да ты точно специалист http://rt.avlab.ru/2006/10/24/tsearch2-i…
Ткните пальцем где я писал о том что я специалист и я не стану бить вас по морде.
Могу сделать вывод, вы просто тупица, пытающийся вставить свои пять копеек, не удосужевшись прочитать о чём идёт речь.
Могу сделать вывод, вы просто тупица, пытающийся вставить свои пять копеек, не удосужевшись прочитать о чём идёт речь.
Продолжая мериться письками,
http://michael.mindmix.ru/87-411-ovebdva…
Вы действительно считаете, что аякс (в том виде в котором вы его описали) снижает нагрузку на сервер? :) Типа заменив гостевую на чат вы сэкономили ресурсы...
Ну да ладно, я не собираюсь спорить.
http://michael.mindmix.ru/87-411-ovebdva…
Вы действительно считаете, что аякс (в том виде в котором вы его описали) снижает нагрузку на сервер? :) Типа заменив гостевую на чат вы сэкономили ресурсы...
Ну да ладно, я не собираюсь спорить.
На Хабре всё вышеперечисленное есть с незапамятных времён =) Правда, реализовано отвратительно.
При этом я считаю, что такая фича полная ерунда и рефреш страницы ничего страшного не делает.
При этом я считаю, что такая фича полная ерунда и рефреш страницы ничего страшного не делает.
А чего тут спорить? мне же видно как меняется нагрузка на моём сервере...
Откуда Вы берёте эту информацию о моём сервере, я не знаю...
Откуда Вы берёте эту информацию о моём сервере, я не знаю...
А выбор между MySQL и PostgreSQL - предопределён? А то ведь есть DB2 Express-C, которая бесплатна. Главное - вписаться в конфигурацию железа. А уж DB2 - это DB2.
угу и Sybase'овская линейка ASE от бесплатных до дорогих...
здесь есть: http://abava.blogspot.com/2006/06/mysql-…
Хотя и не последние версии.
Хотя и не последние версии.
Раньше работал в ISP ведущим сисадмином. Там вся база клиентов, их наработка, почтовик, логи раньше хранились в MySQL. По словам старожил это была сущая головная боль. Года 2 назад переехали на PostgreSQL и проблем стало существенно меньше.
Из личного опыта могу сказать, что в отличие от мускула в PostgreSQL очень удобный консольный клиент. Работать в нем одно удовольствие. После него на мускул не тянет аж никак - у мускула родной клиент убог.
Также, в PostgreSQL, в отличие от мускула, очень приятно работать с различными кодировками - "батону по#@й кого рвать".
А, чуть не забыл, консольный клиент PostgreSQL в достаточной степени документирован изнутри, что позволяет не отвлекаться на чтение документации и работать не отрываясь от консоли.
З.Ы: И в мыслях небыло навязывать кому-то свое мнение. Каждое средство должно быть вовремя и к месту.
Из личного опыта могу сказать, что в отличие от мускула в PostgreSQL очень удобный консольный клиент. Работать в нем одно удовольствие. После него на мускул не тянет аж никак - у мускула родной клиент убог.
Также, в PostgreSQL, в отличие от мускула, очень приятно работать с различными кодировками - "батону по#@й кого рвать".
А, чуть не забыл, консольный клиент PostgreSQL в достаточной степени документирован изнутри, что позволяет не отвлекаться на чтение документации и работать не отрываясь от консоли.
З.Ы: И в мыслях небыло навязывать кому-то свое мнение. Каждое средство должно быть вовремя и к месту.
а как с инструментами DBA? кто что пользует? это при работе с БД тоже большое значение играет
При больших объемах стоит посмотреть в сторону mysql cluster.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PostgreSQL vs MySQL: есть тесты на больших таблицах?