|
Задавайте вопросы, мы ответим
Вы не зашли.
Здравствуйте! Я программист и разработал (пока ещё не запустил) 1 сайтик. Он является автокаталогом (по-типу авто.ру). Смысл тот же: юзеры вбивают объявы о продаже авто. Ну и куча полезных ф-й ко всему этому. Состоит он из следующих частей:
1. www.site.ru - сам автокаталог (15 таблиц)
2. firms.site.ru - каталог фирм (салоны, сервисы, мойки и тд) (7 таблиц)
3. parts.site.ru - каталог запчастей (12 таблиц)
4. top.site.ru - рейтинг автосайтов (5 таблиц)
5. news.site.ru - автоновости (15 таблиц)
6. forum.site.ru - форум автомобилистов (ну а это ipb-форум, около 50 таблиц)
Как видите, 1 главный домен (автокаталог) и 5 поддоменов 3 уровня.
Вся эта байда у меня хранится в 1 базе, общее число таблиц ~100.
Есть маза раздобыть кругленькую сумму на раскрутку. Планирую года через 3 иметь не менее 50.000 уникальных посетителей в сутки. Сервак естественно, буду выделенный покупать. FreeBSD+NgInx+Apache+MySQL, все дела.
Основная нагрузка на mysql однозначно будет из-за постоянной долбёжки поиска. Ну, куча народу будут долбить поиск для поиска тачки, запчасти и тд.
И вот думаю как лучше сделать? Может для каждого поддоменя (форум, запчасти, новости) сделать отдельную базу данных? Но тогда проблема - авторизацию я хочу общую сделать для всех поддоменов. Типа, если чел зарегался в автокаталоге, то те же логин и пасс будут подходить и к форуму, и к запчастям и тд. Но базы-то разные будут! А если все 100 таблиц в 1 держать (как сейчас) - то проблем с общей вторизацией нет. Но вот боюсь мускул ляжет моментально...
Благодарен за любой адекватный совет!
PS: Ораклы и им подобные не предлагать - у меня уже всё под мускул заточено ;
Неактивен
В обной базе таблицы или в разных - для MySQL вообще нет никакой разницы. Можно 1000 таблиц поместить в одну базу, а можно каждую таблицу поместить в отдельную базу (это не запретит делать запросы с JOIN). Производительность будет одинаковой.
Может быть Вы хотите разные базы разнести на разные физические серверы. В этом смысле нужно помнить, что преждевременная оптимизация - корень всех зол. Еще неизвестно какой из сайтов будет создавать максимальную нагрузку. Если основные запросы - поиск, то лучше настроить репликацию востребованных таблиц на несколько серверов и запросы на чтение выполнять с них. Но это в будущем, когда а) сервер перестанет справляться б) проект будет приносить деньги, достаточные для аренды дополнительных серверов.
Неактивен
ммм... ну спасибо за помощь. Хотите сказать что мне пока дёргаться не стоит и запускать всё как есть? А потом разберёмся? А я вот слышал - что изначально неверно спроектированная базя - корень всех бед -)
Неактивен
Уважаемый админ! А по вашему опыту - на 50.000 уников/сутки сколько нужно серверов для репликации? Штуки 3 где-то?
Неактивен
Одно другому не противоречит. Проектировать нужно правильно, с учетом производительности. Но база сначала проектируется в нормальной форме, а только потом в нее вносится дублирующая информация, кэширование и.т.д. Безусловно запросы должны быть составлены правильно.
Относительно баз данных, это не имеет значения. Пусть у Вас есть таблицы users, posts и items в одной базе. Тогда запросы будут типа
Неактивен
Спасибо большое за хороший ответ! Проект через пару месяцев запускаю и начинаю крутить потихоньку. Много сил затратил - полтора года писал всё снуля. Думаю труды не пропадут даром. А придёт время - к Вам обращусь (с денюжкой); за более конкретными решениями. А то у нас в Рязани знания сисадмина заканчиваются на уровне настройки ipfw... Обратиться даже не к кому...
Неактивен
50000 уников, а сколько хитов? И что делают эти уники в основном? Если пришли с поиска по конкретной объяве, то будет 150к хитов, если разделить на 8 активных часов в сутках, то получается 5 хитов в секунду, что, в принципе, может обработать один сервер при правильной настройке кэширования.
Сейчас Вы не знаете сколько их них будут выполнять поиск (обычно это несколько процентов), поэтому какую-то реальную оценку дать сложно
Неактивен
rgbeast написал:
И что делают эти уники в основном?
Ну а что они могут делать на сайте типа автору? Не tv-трансляции online же смотреть -))) Тачки искать....
Неактивен
Я думаю, 50000 посетителей Вы сможете совершенно спокойно держать на обычном MySQL сервере безо всякой репликации и т.п.
Главное - не писать невменяемые запросы и не допускать тупости в структуре таблиц (и в проектировании вообще). Тогда всё будет нормально
Неактивен
mikki11 написал:
Ну а что они могут делать на сайте типа автору? Не tv-трансляции online же смотреть -))) Тачки искать....
Это по разному можно делать. Можно на форуме сидеть, тогда на одного уника будет 10 хитов. Можно придти с поиска, прочитать объяву, уйти, тогда будет 2 хита на уник. Можно читать статьи по сайту - будет 7 хитов. Можно попасть на главную, тогда у главной будет 50% всех хитов, Вы ее закэшируете и все (например, на сайте rbc.ru закэшированная главная и основные новости).
Неактивен
Я бы еще из вашей конфигурации выкинул FreeBSD, Apache и все дела.
Без этих трех компонентов будет работать быстрее 
Неактивен
Спасибо за помощь! Буду теперь осмыслевать ))
Неактивен
