SQL и куча пользователей.

← →
KilkennyCat © (2009-12-17 01:35) [40]

> GDI+ (17.12.09 01:33) [39]

как-то они быстро и мощно. это все-таки затратно.

← →
Игорь Шевченко © (2009-12-17 01:59) [41]

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

Да и вообще, 20 миилиардов файлов на сервере разместить, это как бы тоже не хрен собакин.

← →
Kerk © (2009-12-17 02:12) [42]

> Игорь Шевченко © (17.12.09 01:59) [41]

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

В простейшем случае такое легко работает все на одном сервере и при необходимости выносится на дополнительные сервера.

← →
Игорь Шевченко © (2009-12-17 02:17) [43]

Kerk © (17.12.09 02:12) [42]

Я к чему - файловая структура не проще ? NFS-ы там всякие

← →
KilkennyCat © (2009-12-17 02:20) [44]

> Игорь Шевченко © (17.12.09 02:17) [43]

я тоже так думал. но я куда не смотрел - везде бд, бд, бд... миллион леммингов не могут ошибаться.

← →
GDI+ (2009-12-17 02:26) [45]

> Игорь Шевченко © (17.12.09 02:17) [43]
>
> Kerk © (17.12.09 02:12) [42]
>
> Я к чему - файловая структура не проще ? NFS-ы там всякие

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

А по поводу чистых сетевых ФС. Есть DFS, но при серьезной нагрузке 500 одновременных коннектов к серверу она падает.
http://www.microsoft.com/windowsserver2003/technologies/storage/dfs/default.mspx

> Kerk © (17.12.09 02:12) [42]

Угу, это и есть распределенная система со справочником аккаунтов. Так и Skype работает и ICQ и Jabber.

← →
Anatoly Podgoretsky © (2009-12-17 09:14) [46]

> Игорь Шевченко (17.12.2009 01:59:41) [41]

На одном сервере, нужна хорошая сановская дисковая стойка и не одна.

← →
Игорь Шевченко © (2009-12-17 11:57) [47]

Anatoly Podgoretsky © (17.12.09 09:14) [46]

> На одном сервере, нужна хорошая сановская дисковая стойка
> и не одна.

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

← →
Anatoly Podgoretsky © (2009-12-17 12:09) [48]

> Игорь Шевченко (17.12.2009 11:57:47) [47]

Я же привел объемы для размера файлов 1 мб в среднем, это 2*10^16 степени байт, не считая базы данных

← →
ANB (2009-12-17 12:09) [49]

Вариант 1 : - 2 толстые таблицы - юзеры + файлы юзеров.
Достоинства :
1.1 очень просто. Чтобы таблицы не джойнить - определяем ИД юзера при входе и запоминаем его, потом обращаемся только ко 2-й таблице.
1.2 - легко писать запросы для поиска файлов по всей БД (если это нужно)
Минусы :
1.1 - на небольшом количестве юзеров запросы по индексам будут летать. При увеличении количества подключенных юзеров может возникнуть затор на чтении.
1.2 - толстые таблицы тяжело распределять по разным дискам / серверам. Придется использовать фичи СУБД типа партиционирования.
1.3. - если юзеров будет выгребать не все файлы, а только нужные и использовать всякие нестандартные приемы поиска - то поиск нужных файлов пойдет перебором (индекс рэнж скан + фильтер)
1.4 - индекс по второй табличке будет не маленький
Вариант 2 : таблица юзеров + куча таблиц для каждого юзера.
Минус :
2.1 явно большая сложность разработки и поддержки
2.2 запросы всегда придется строить на лету (динамически)
2.3 структура БД будет противоречить всем канонам построения баз
Достоинства :
2.1 - легко распределять БД по разным устройствам / серверам. Можно вообще по разным БД раскидывать.
2.2 - все нестандартные поиски будут шустрее работать (всяческие фичи фулл-скана, т.к. таблицы будут маленькими)

← →
GDI+ (2009-12-17 22:44) [50]

> Игорь Шевченко © (17.12.09 11:57) [47]
> Да и сервер наверное не очень тривиальный. Я как-то по собственному
> опыту сужу, для средних баз объемом несколько терабайт и
> количеством записей под миллиард в таблицах уже пользуется
> нетривиальное железо для одновременной работы тысячи пользователей.

Поэтому, так как по ТЗ пользователи не должны пересекается, то лучше 1 база - 1 пользователь. На каждый компьютер по 1000 пользователей. 1 база для справочника аккаунтов для учета нагрузки и распределения баз (активно используемые по 500 на сервер, пассивные по 5000 на сервер).

> KilkennyCat ©

<offtop>
Я вот чего нашел, а то ты свое писал подобное
http://docs.jquery.com/Plugins/Validation
</offtop>

> Kerk © (18.12.09 01:37) [51]

ага, я свое писал после того как это тоже нашел. бьюсь за размер. я и jquery уменьшу по окончании проекта.

> Минус :
> 2.1 явно большая сложность разработки и поддержки

почему? все там очень просто.

> 2.2 запросы всегда придется строить на лету (динамически)

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

> 2.3 структура БД будет противоречить всем канонам построения баз

ну... если жить по уставу - свихнешься.

Зато перечисленные плюсы очень плюсы. Особенно последний. Ибо и с большой таблицей перевод юзверя на другой сервер проблемы не создает, даже при подключенном юзвере.

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

Чем больше я сейчас читаю, тем больше прихожу к выводу, что на эти выходные я просто соберу север, и проведу эксперимент,ибо в теории запутался совсем.

← →
ANB (2009-12-18 13:18) [53]

> ну... если жить по уставу - свихнешься.

Ну, собственно, я второй вариант и рекламировал.
Потому как сейчас сидим на средненькой базке, где по разному все.
В тех местах, где все раскидано по разным таблицам - писать отчет дольше, зато потом нет проблем с оптимизацией.
А где в больших таблицах все в куче свалено - начинаем мучиться с оптимизацией. Иногда кода еще больше выходит.

> и проведу эксперимент,ибо в теории запутался совсем.

Не забудь сэмулировать тыщ 10 одновременных коннектов. Иначе разницы не заметишь.

> KilkennyCat © (18.12.09 09:42) [52]
>
> > Kerk © (18.12.09 01:37) [51]
>
> ага, я свое писал после того как это тоже нашел. бьюсь за
> размер. я и jquery уменьшу по окончании проекта.

А нафига?

SQL и куча пользователей. Найти похожие ветки