Много данных в одной БД или много БД

[AXP]

Много данных в одной БД или много БД

Приветствую всех.

Вот возник у меня вопрос. Планируется большой проект аля ucoz только узконаправленный.
Основное - будет множество пользователей, у каждого свой набор данных.
Один движок пхп.

Как правильно - хранить все данные в одной бд, указывая ид пользователя в каждой таблице или для каждого пользователя создавать отдельную БД?

Если бы пользователей было штук 10, то я бы сделал по первому варианту. А вот с большим кол-вом я немного теряюсь..

Заранее большое спасибо за ответ!

 

[Farsh]

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

 

[AXP]

в первом случае на всех пользователей одни и те же таблицы
Т е для новостей - таблица news, для форума - forum (это пример).
Соотв данных в таблицах много очень - таблицы большие.

Во втором случае у каждого пользователя своя БД со своим набором таблиц.

 

[pilot911]

а сколько пользователей предполагается ?

миллион, два ?

 

[clevel]

Я в своей цмс пошел по пути - в одной базе данных хранятся всех пользователи с их информацией. В каждой таблице - просто доп. поле - идентификатор сайта.

Плюс - есть несколько общих табличек нехилого объема (150 Мегабайт) - например, словарь первоформ и производных форм, для поиска - который для каждого сайта выносить в отдельную БД накладно. 100 сайтов Х150 Мб = 15 гигов.
А сайтов больше 100 И хотя под БД - отдельный сервак, место все равно не резиновое.

Минус - когда несколько пользователей обновляют записи одновременно - таблица тех же новостей лочится (MyIsam тип таблицы). Поэтому для наиболее популярных сайтов все таки приходится выносить их данные в отдельные БД.

Были мысли вообще сделать сводную БД для поиска, и там держать поисковый индекс всех сайтов, но опять же - упираемся в лок таблицы.
Переходить на InnoDB пока боюс - после highload конференции еще больше убедился - что InnoDB - зло.

 

[AXP]

pilot911
нет =)
Думаю, до тысячи.
Но представьте, что у каждого есть свой форум, свои новости, своя база клиентов, свои каталоги продукции, ... + логи, статистика
таблицы будут большими.
clevel
Мда... Там уж точно будут обновлять одновременно неск пользователей... Может мне не mysql использовать а posrgresql? Или он не лучше в этом плане?

 

[флоппик]

Пацан, бери Оракл, и не баись!

Переходить на InnoDB пока боюс - после highload конференции еще больше убедился - что InnoDB - зло.

Любое однобокое мнение - заведомо неверное. Реализация транзакционности для MyISAM средствами приложения - не меньшее зло. Каждому делу - свой инструмент.

Я в своей цмс пошел по пути - в одной базе данных хранятся всех пользователи с их информацией. В каждой таблице - просто доп. поле - идентификатор сайта.

А когда ты захочешь 2 сервера БД, что что будешь делать?
Дисковое пространство - _самый_дешевый_ тип ресурса, а главное, линейно маштабируемый. Не на нем надо искать узкие места.

 

[AXP]

флоппик
Попросил бы быть посдержаннее в выражениях.
Оракл не подходит в силу своей платности.

Так какое же все-таки решение лучше выбрать?

 

[флоппик]

Оракл не подходит в силу своей платности.

Oracle XE давно бесплатен.

Так какое же все-таки решение лучше выбрать?

Никто не знает особенностей твоего будущего проекта. Они все у тебя в голове.
Ни Мускул, ни Пострге, ни даже Оракл не помогут решить несформулированную задачу. Пока ты сформулировал только одно условие — пользователей больше 10 человек и меньше 1000. А посетителей? А чего у тебя будет больше, вставок, или чтений? Будет ли проект маштабироватся далее? Если да, то может стоит это учесть заранее?

 

[AXP]

Автор оригинала: флоппик
Oracle XE давно бесплатен.

В начале проект, по планам, должен быть размещен на платном хостинге (на 2 месяца) для того, чтобы заказчик решил, нравится ему или нет, только после этого поедет на отдельный сервер, соотв нужны публичные решения.

Автор оригинала: флоппик
Никто не знает особенностей твоего будущего проекта. Они все у тебя в голове.
Ни Мускул, ни Пострге, ни даже Оракл не помогут решить несформулированную задачу. Пока ты сформулировал только одно условие — пользователей больше 10 человек и меньше 1000. А посетителей? А чего у тебя будет больше, вставок, или чтений? Будет ли проект маштабироватся далее? Если да, то может стоит это учесть заранее?

Понял, распишу подробнее:
1000 пользователей = 1000 сайтов
у каждого сайта, в среднем, по 100 посетителе в день (и по 300 зарегистрированных клиентов)
В основном происходит чтение данных (статьи, новости, каталог, ...), но есть и большая активность записи (форум - предполагается, что это будет наболее популярный разздел), где, преджположим, каждый из 100 отписывается минимум по 1 разу в день.
Про чтение - страницы, в основном, динамические, генерящиеся пхп с выборкой из БД (типа новостей).

Итого, обращений записи, в среднем, 100000 в день. Наибольшая активность - 20-23 часа. Тогда будут активны 60% из этих пользователей.

Что то упустил? Вроде данных достаточно?

 

[флоппик]

Ну, я бы вообще вынес форумы на отдельную машину. Форумы будут на своем движке, или на каком то из стандартных?

В основном происходит чтение данных (статьи, новости, каталог, ...)

Это все будет отлично кешироватся в статику, не затрагивая БД.
итого, максимум 1000*100 = 100 000 пользователей.
В принципе, я не думаю, что тут выбор вообще не критичен.
Однако тут будет MyISAM, и стоит подумать вот о чем — в случае краша таблицы гораздо проще чинить маленькую табличку, чем огромную, да и другие клиенты будут работать. Кроме того, есть предел на размер файла таблицы, устанавливаемый ФС. Это тоже решаемо, можно это не решать, а избежать, разделив на разные таблицы.
Т.е. стоит понимать - обьединяя таблицы в одну, ты обьединяешь потенциальные проблемы одного из пользователей в общую проблему для всех. То же и с расширением твоего проекта. Все изменения надо будет применять ко всем пользователям сразу и одновременно.

А если тебе нужны сводные данные по всем пользователям — есть MERGE, который и нужен для таких задач.
Может быть и стоит разделить на несколько БД.

 

[AXP]

флоппик
Понял, спасибо.

Вот тогда другой вопрос:
Что лучше, Одна БД с множеством таблиц или много БД? =)

В первом варианте имею ввиду, что для каждого пользоателя будет создаваться свой набор таблиц, только с префиксом:
user1_news, user_members, ...

Ну а во вротом все ясно... Стоит ли думать о первом решении?

 

[флоппик]

Что лучше, Одна БД с множеством таблиц или много БД? =)

http://dev.mysql.com/doc/refman/5.0/en/creating-many-tables.html

-~{}~ 19.10.08 19:07:

А был бы оракл, таких бы вопросов не возникло. В нем нет раздельных баз в понимании MySQL.

 

[AXP]

Понял. спасибо огромное за ответы!
Значит, буду использовать множественные БД с 5-10 пользователями на каждой.
Спасибо!

-~{}~ 19.10.08 16:12:

Да, оракл был бы идеальным решением(

-~{}~ 19.10.08 16:13:

Возможно, на него потом все и переведу... Все равно я к бд давно обращаюсь через спец класс, который сам формирует запросы из массивов. так что на другую БД перейти бдет возможно, хоть от отладки никуда и не деться будет...

 

[С.]

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

 

[флоппик]

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

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

 

[AXP]

Поиск будет только в пределах сайта одного пользователя

 

[clevel]

А когда ты захочешь 2 сервера БД, что что будешь делать?

Все просто Для новых клиентов в конфиге пропишу второй сервер БД. И туда скопирую эти несоклько таблиц со словарем первоформ и производных.

В мой ситуации сайты никак не связаны - поэтому проблем нет.
Для топикстартера - есть смысл при разносе в перспективе по серверам - написать скрипт-прослойку, которая по опредленным критериям выбирает - на какой сервер БД отправлять запрос за данными. Ну это так, на перспективу.

Любое однобокое мнение - заведомо неверное. Реализация транзакционности для MyISAM средствами приложения - не меньшее зло. Каждому делу - свой инструмент.

А я не пытаюсь транзакционность реализовать.
Добавил чел пост в тот же форум - я через скрипт несколько запросов на инсерт/апрдейт отправил, все ок. У меня не банковские операции, чтобы париться насчет того - прошел первый запрос или нет. В крайнем случае - немного нарушится целостность данных, по просьбе клиента поправим.

 

[флоппик]

И туда скопирую эти несоклько таблиц со словарем первоформ и производных.

И через полгода получишь два набора данных. То бишь, получаешь избыточность данных, да еще и нарушающую целостность. То бишь, обратно их не соединить.

А я не пытаюсь транзакционность реализовать.
Добавил чел пост в тот же форум - я через скрипт несколько запросов на инсерт/апрдейт отправил, все ок.

Чего-то у тебя дебет с кредитом не сходится. Сначала - хайлоад, а теперь выясняется, что целостность не нарушается, потому как нагрузка небольшая.

 

[Фанат]

у них у всех не сходится. хайлоад в мечтах.