forum.lissyara.su

Что лучше: одна большая база или несколько маленьких для наилучшей производительности и быстродействия Посгриса?

лучше - MySQL.
Когда траффик танет большой и серьёзный - тоже к нему придёшь.
И к выносу муси а отдельный сервер

а по вопросу что можно сказать, какой вариант лучше?

тут всё от задачи будет зависеть..

просто несколько сайтов и форумов используют одну базу (всё находится в пределах одного сервера), мне хочется узнать что лучше

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

Anonymous писал(а):просто несколько сайтов и форумов используют одну базу (всё находится в пределах одного сервера), мне хочется узнать что лучше

А как понимать фразу "несколько маленьких"? Несколько схем или несколько инстансов? Несколько инстансов плохо, даже если это мускуль :-) А под один инстанс можно памяти выгрести под кэш буферов побольше, и вообще оптимизнуть. А еще, разумнее унести базу на отдельную машину, специально под БД заточенную
ЗЫ
Мускуль это конечно да, быстро и все такое. Однако область применения -- сайтики и логосборники, на суриозную задачу ставить его пока рано, по моему.

а что есть серьёзный проект?
hoster.ru - у них бакэнд на мусе - и к почте и к exim.
постгресс - не потянул.

Скорострельность СУБД штука всесторонне-ползучая и заковыристая. И в 90% случаев, зависит скорее от толковости и аккуратности разработчиков, чем от архитектуры. Впрочем видел и затыки по архитектуре -- это большая беда, когда на работающей системе приходится на лету базу менять. Но помимо скорострельности есть еще куча других вещей о которых мускуль не имеет понятия. Пример из жизни -- разграничение доступа к данным не на уровне таблиц или столбцов а на уровне записей. Грубо говоря продавец Сидров видит/редактирует только свои продажи в таблице продаж, продавец Петорв свои, а их начальник -- все. Причем, реализовать надо не на уровне приложения а на уровне БД. Мускуль такое не умеет, а постгрес пожалуйста

э... какой мускуль? 3.23 чтоль?
обратите внимание на пятый...

lissyara писал(а):э... какой мускуль? 3.23 чтоль?
обратите внимание на пятый...

Пятый, честно, не смотрел еще. 4.1 в продукции пока стоит. 5-ка, по моему, еще в стабле не перешла. Опять таки, про большие проекты, много данных != большой проект. Задачи хостинга, в общем случае, на большой ну никак не тянут. Ну и в довесок, могу сказать, что с прямыми руками можно что угодно и на berkeley db слепить, а с кривыми и на оракле ничего путного не выйдет. Дело, опять же, не в платформе, а в тех кто под нее пишет
PS
Ну раз уж пошла речь про пятерку, а можно в 5-ке сделать так чтоб разложить индексы на один диск, данные на другой чтоб при этом транзакции работали и чтоб лог транзакций на третем диске лежал?

можно.
симлинками ))
Тока при пересоздании индекса - сцуко его на парвом диске сделает.
===========
а вообще видеёл чё-то подобное... тока где - не помню

lissyara писал(а):можно.
симлинками ))
Тока при пересоздании индекса - сцуко его на парвом диске сделает.
===========
а вообще видеёл чё-то подобное... тока где - не помню

Ну да, симлинками, это еще в 3-й версии можно было (может и раньше, тока я с 3-шки начал). Еще где то в конфиге есть возможность указать чтоб индексы в другом месте создавались (если я не путаю), только это для myisam, а они транзакции не поддерживают. Короче, есть mysql ab над чем поработать еще. Однако по скорострельности у myisam конкурентов просто нет

К сожалению, муся ужесточила лицензию...

lissyara писал(а):К сожалению, муся ужесточила лицензию...

Мдя, все гады, все денег хотят Зато постгрес в этом смысле гуманнее некуда