|
|
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
Предположим, у нас имеется таблица Items(Id, varchar(250) Name, varchar(2000) Description). Требуется создать многопользовательскую систему, в который у каждый пользователь мог бы вводить свои данные в Items, невидимые для других. При этом число записей для одного пользователя может исчисляться миллионами (20-30 млн. записей). Как наиболее оптимальным способом организовать работу БД. У меня есть три варианта. 1. Самый очевидный: создаем таблицу Users(Id, Name) и добавляем в Items внешний ключ UserId. При таком подходе появляются опасения, что число записей в одной таблице будет слишком большим (допустим, если пользователей 1000, то получаем около 20-30 млрд. записей в табл. Items) и работа с такой таблицей, думается, будет очень медленной. Хотя, видимо, select будут выполняться довольно шустро, если индексы правильные построить, зато insert'ы и update'ы, видимо, с ростом количества пользователей будут довольно длительными. 2. Для каждого пользователя создавать свою таблицу Items в БД, например, с помощью префиксов: <userid>_Items. В таком случае, в каждой таблице будет относительно немного записей (20-30 млн.), зато количество таблиц будет огромным (для 1000 пользователей соотв. 1000 таблиц). Интересно, насколько хорошо в этом случае будет справляться СУБД с запросами. 3. Можно также для каждого пользователя создавать свою БД. Этот подход видится оправданным, если у нас не только одна таблица Items, а к примеру еще есть и Categories, Types, Types, Properties и т.д., около 10 таблиц. В пред. случае для 1000 пользователей в одной БД оказалось бы 10 тыс. табл. Хотелось бы послушать мнения: какой из этих способов вы считаете наиболее оптимальным. Возможно, вы предложите что-н принципиально иное. Для меня с точки зрения реализации наиболее простым видится первый вариант. Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2013, 21:57 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
OptPrime, Вариант 2. При наличии таблиц варианта 3, также вариант 2, только доп таблицы делать общими, или для каждой делать доп таблицу с id пользователя (если нада будет что б категории и пр. были для каждого отдельные). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2013, 22:18 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
OptPrimeДля меня с точки зрения реализации наиболее простым видится первый вариант.Вот первый вариант и делайте, поскольку проще. По имеющейся информации невозможно посоветовать что-то иное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2013, 22:21 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
А что, в MS SQL нет схем?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2013, 22:27 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
Все просто: делайте, как умеете. Если ваша софтинка доживет до описываемого объёма (во что мне лично верится с трудом), появится бабло, чтобы нанять людей, которые в состоянии ее переписать. Причем, посредством инструментов, исключающих использование слова "мелкомягкий". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2013, 23:00 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
OptPrimeкаждый пользователь мог бы вводить свои данные в Items Что значит "свои" ? Варианты: 1 То, что но сам лично завел 2 То, на что ему даны права (вопрос, каким образом) В реальности структура таблицы д.б. более сложной и решение соответственно то же ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2013, 09:23 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
Второй и третий вариант - это "закат солнца вручную". Если Вам позарез хочется хранить данные пользователей отдельно ( хотя это имхо странная идея, в то числе с точки зрения производительности) - включите на большой таблице секционирование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2013, 12:29 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, думаю, подходы могут быть разными. Мне кажется, что с точки зрения масштабирования более удобными будут как раз варианты 2-3. Что касается "заката Солнца", то вот, например, статья , в которой как раз рассматриваются три варианта (с некоторыми изменениями). На эту статья я наткнулся только сегодня. Кот МатроскинВторой и третий вариант - это "закат солнца вручную". Если Вам позарез хочется хранить данные пользователей отдельно ( хотя это имхо странная идея, в то числе с точки зрения производительности) - включите на большой таблице секционирование. Секционирование, или партицирование, как я успел прочесть, активно используется, но его возможности ограничены, когда, например, нужно размещать таблицы на разных серверах. Dimitry SibiryakovА что, в MS SQL нет схем?.. Спасибо, именно благодаря этому восклицанию-вопросу я набрел на упомянутую выше в этом посте статью. Есть, оказывается, в MSSQL эти схемы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2013, 22:50 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
OptPrimeКот Матроскин, думаю, подходы могут быть разными. Мне кажется, что с точки зрения масштабирования более удобными будут как раз варианты 2-3.Угу... Аккурат до момента, когда не надо будет вносить изменения структуры во все 100500 комплектов таблиц или баз данных... В случае с "одна база на пользователя" - это АДЪ в администрировании! На каждую базу написать и поддерживать план обслуживания?! И (не приведи чего) в случае аварии восстанавливать все базы?! Нет... Спасибо... Другая проблема - сервера БД имеют определеннные технические ограничения по максимальному количеству баз данных на одном экземпляре сервера и по количеству объектов в каждой отдельной базе - ограничение "в-принципе" достаточно большое, но очень быстро актуализируется в случая "дублирования" баз и таблиц под каждого пользователя. OptPrimeКот МатроскинВторой и третий вариант - это "закат солнца вручную". Если Вам позарез хочется хранить данные пользователей отдельно ( хотя это имхо странная идея, в то числе с точки зрения производительности) - включите на большой таблице секционирование. Секционирование, или партицирование, как я успел прочесть, активно используется, но его возможности ограничены, когда, например, нужно размещать таблицы на разных серверах. И что не так с размещением партиционированных данных на разных серверах? Практически все современные сервера баз данных поддерживают распределенные запросы к данным. Соответственно, распределенное горизонтальное партиционирование не составляет никаких особых проблем... Шардинг , однако... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2013, 00:17 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
OptPrime, Если у тебя: 1. действительно высоконагруженное решение 2. MS SQL то тогда посмотри на SQL Azure - http://msdn.microsoft.com/en-us/library/windowsazure/ee336256.aspx ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2013, 08:58 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
Infernal V. Raven, 1000, то получаем около 20-30 млрд. записей в табл. Items) Даже 10 миллиардов очень не просто получить, так что рекомендую сначала дойти до таких объемов, а потом уже думать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2013, 09:41 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
В таком случае, в каждой таблице будет относительно немного записей (20-30 млн.), зато количество таблиц будет огромным (для 1000 пользователей соотв. 1000 таблиц).Вам поручили создать такую мегасистему ??? Ужос....Начальников уволить ! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2013, 10:27 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
OptPrime, ТОЛЬКО вариант 1, всё остальное — вообще не варианты. и запомни на будущее — вставка в таблицу это O(1) или O(log N), update одной записи по ключу — O(log N). Т.е. практически не зависит от размера таблицы. Таблица у тебя очень уж простая, я не верю, что в таком серьезном по данным проекте, как ты заявляешь, будет такая глупая структура. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2013, 11:09 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
OptPrime, Я хочу подчеркнуть, что 2 и 3 — это не варианты , это просто ошибка проектирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2013, 11:11 |
|
||
|
Структура высоконагруженной БД
|
|||
|---|---|---|---|
|
#18+
MasterZivInfernal V. Raven, Даже 10 миллиардов очень не просто получить, так что рекомендую сначала дойти до таких объемов, а потом уже думать. Не понял, почему это мне адресовано? Но сомнения аналогичные, чаще всего из 1000 пользователей 10млрд записей не вытекает. Разве что за 10 лет. MasterZivЯ хочу подчеркнуть, что 2 и 3 — это не варианты , это просто ошибка проектирования. В общем смысле согласен. В Azure такие пируэты проектируются немного по-другому, т.е. есть 4-ый вариант, поэтому и порекомендовал посмотреть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2013, 11:43 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38321566&tid=1541183]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
151ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 487ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...