LINUX.ORG.RU

Выбор БД


0

1

Дали мне на переписывание проект на PHP+MySQL с условием что могу делать всё что захочу лишь бы работало как раньше и не глючило. Проект, для примера, представляет из себя информационную базу - таблицу песен привязанных по album_id к таблице альбомов, ну и куча дополнительных полей - теги к каждой песне, текст слов и т. д.

Решил что раз уж переписывать такой хлам 10-летней давности, то лучше сразу на PHP 5.3 со всеми его плюшками. А вот с выбором базы данных затормозил. Дело вот в чём - в проекте за 10 лет его работы обнаружилось нарушение целостности связей между таблицами. Скажем, альбом удалён, а песни остались, так и висят в БД мёртвым грузом. Учитывая, что база проекта была в таблице типа MyISAM, о транзакциях речи не было. Пару лет назад кто-то кое-как выкрутился из ситуации используя вместо транзакций полные блокировки половины таблиц на время работы с ними. Но это костыльное решение. Тогда я посмотрел в сторону InnoDB. Сразу написал первый тест «в лоб»: выборка всех альбомов с песнями, связывая их по album_id:

SELECT * FROM albums AS a, songs AS s WHERE s.album_id = a.id

Перед каждым таким запросом сбрасывал кэши запросов. На 10000 песен получилось так: MyISAM - 0.07 сек, InnoDB - 0,17 сек., т. е. в 2 раза дольше, а это всего один запрос, в среднем же там запросов 10 на страницу. Ко всему прочему размер базы в InnoDB в 2 раза больше чем MyISAM, хотя обе уже в UTF-8.

Всё это на MySQL 5.1.51, MariaDB почему-то не захотела ставиться, а плагин XtraDB к MySQL не захотел активироваться, так что попробовать его не получилось.

В общем, MySQL'овский InnoDB не порадовал, да ещё среди его разработчиков разброд и шатание начался. Решил посмотреть на PostgreSQL, почитав отзывы о нём, что в определённых ситуациях он работает быстрее MySQL. А что можете сказать о нём вы? Сервер - VDS с 256 мб RAM, из которых максимум под БД могу выделить мегабайт 50-60. В основном юзаются сложные SELECT (по отзывам PostgreSQL их куда умнее обрабатывает, но и MyISAM на SELECT'ах быстр, т. к. писался специально для выборок), но и какой-либо механизм обеспечения целостности связей между таблицами обязателен.

>Решил посмотреть на PostgreSQL, почитав отзывы о нём, что в определённых ситуациях он работает быстрее MySQL. А что можете сказать о нём вы? Сервер - VDS с 256 мб RAM, из которых максимум под БД могу выделить мегабайт 50-60.

Постгрес крут, но его надо тюнить. Чтобы он стал быстрее, чем InnoDB, может 50 метров и не хватить.

anonymous ()

под БД могу выделить мегабайт 50-60
запросов 10 на страницу.

т.е на переписывание проекта бабла хватило, на поддержку хватило, а на то чтобы купить планку оперативки - нет. Делаа...

stevejobs ★★★★☆ ()
Ответ на: комментарий от stevejobs

> т.е на переписывание проекта бабла хватило, на поддержку хватило, а на то чтобы купить планку оперативки - нет. Делаа...

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

karbofos ()

>На 10000 песен получилось так: MyISAM - 0.07 сек, InnoDB - 0,17 сек., т. е. в 2 раза дольше

Это ты ещё не видел проблем, типа:
http://www.linux.org.ru/forum/development/4094810
http://www.linux.org.ru/forum/talks/4350880
http://www.linux.org.ru/forum/general/5574146
...

В общем, я InnoDB так и не осилил :) Транзакции мне не нужны, целостность не трудно проверять скриптом в ночном cron'е... Так что то, что напереводил в InnoDB начинаю понемногу откатывать на MyISAM :)

А что можете сказать о нём вы?


Пока потребность в нём не превысила затрат на переход на него.

KRoN73 ★★★★★ ()

мда.

Тебе Постгрес не нужен, более того, он скорее всего не поможет.

Проще всего остаться на MyISAM и обеспечивать целостность средствами приложения.

val-amart ★★★★★ ()
Ответ на: комментарий от KRoN73

> http://www.linux.org.ru/forum/development/4094810

Разница может быть из-за автоматического AUTOCOMMIT

http://www.linux.org.ru/forum/talks/4350880

InnoDB в каждый индекс автоматом добавляет PRIMARY KEY, отсюда получается хорошее увеличение размера таблицы (11 индексов все-таки).

http://www.linux.org.ru/forum/general/5574146

А какая версия MySQL? Вообще у InnoDB были проблемы с медленным автоинкрементом.

Вообще innodb_flush_log_at_trx_commit тоже может оказывать сильное влияние.

Вообще мы используем InnoDB для ведения логов PowerMTA (в среднем это 2 миллиона записей в день + post insert триггер). Тормозов вообще нет.

sjinks ★★★ ()

> Сервер - VDS с 256 мб RAM, из которых максимум под БД могу выделить мегабайт 50-60.

В конфиге пишут «You might want to disable InnoDB to shrink the mysqld process by circa 100MB». Нет смысла в InnoDB на 256 метрах памяти.

sjinks ★★★ ()
Ответ на: комментарий от sjinks

>А какая версия MySQL?

По последнему вопросу - 5.1.51
По предыдущим - понятно, уже не помню :)

KRoN73 ★★★★★ ()

PostgreSQL в твоем случае - это как из пушки по воробьям. Если так мало места под бд и данные наподобие «альбомы, песни, теги», то мускуль на муисаме - твой выбор. Чтоб очень быстро все работало - эксплейны, индексы, запросы попроще (меньше джойнов)

heisenberg ★★ ()

Между делом, поставилась MariaDB. Конвертнув таблицу в Aria, производительность осталась на уровне MyISAM, а с задействованием XtraDB скорость выполнения запроса составила в среднем 0,25-0,26 сек.

Всё это с дефолтными настройками на своём рабочем компе. В общем, пока решил остаться на Aria с блокировками. Чекать целостность ссылок по крону - как-то ещё более костыльно.

karbofos ()
Ответ на: комментарий от heisenberg

> Чтоб очень быстро все работало - эксплейны, индексы, запросы попроще (меньше джойнов)

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

karbofos ()

Ресурсы сервера

Безусловно слабые. Для InnoDB в особенности. Не уверен что и на MyISAM будет чтото толковое от такого сайта при невысокой нагрузке. Мы так просто отказались от хостинг-компаний, стянув все сервера к себе в офис, подключив их на каналы в 100Мбит, и ессно вылелив на каждый сервер по IP

Итог по деньгам: Электроэнергия на сервер - 350..550руб в месяц Инет канал на каждый сервер - 450 руб в месяц.

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

scard ()

Скажем, альбом удалён, а песни остались

SQL-СУБД умеет внешние ключи. СУБД, не умеющее внешние ключи, не СУБД и ненужна.

no-dashi ★★★★★ ()
Ответ на: Ресурсы сервера от scard

Re: Ресурсы сервера

> Может и Вам нечто такое придумать, если конечно есть более-менее конкурентные провайдеры.

Я о таком варианте думал, но сейчас всё упирается в жилищный вопрос. Мотаться с сервером по квартирам не самое радостное занятие, так что это будет, но позже.

karbofos ()
Ответ на: комментарий от stevejobs

>на переписывание проекта бабла хватило

За еду?

Deleted ()
Ответ на: комментарий от Deleted

> Обязательно именно СУБД? Приложением отделаться нельзя?

Каким приложением? Это веб-сайт.

karbofos ()
Ответ на: комментарий от wozap

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

shutty ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.