эффективна ли такая структуризация SQL (в базе данных mysql) в реальной модели мира?

Question

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

пример ~

приложение управления образованием.80000 пользователей.каждый пользователь получает свою собственную базу данных , содержащую таблицы для -messages -uploads -grades -info

и другие таблицы для других функций

что мне интересно, и любыеИнформация была бы полезна в такой ситуации

- эффективна ли эта модель баз данных?(в основном, как 80 000 баз данных) или есть (и у меня это зуд ощущение, что есть) лучший способ сделать это?- какой выделенный сервер для этого потребуется?80 000 баз данных, каждая с 10-15 таблицами, содержащими TONS таблиц, при этом все 80 000 человек посещают сайт 20-30 раз в день в течение 10-20 сеансов

Answer 1

Начинай бегать.

сейчас!

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

Структура, которая вам нужна, та же самая, меняется только объем данных. Просто создайте одну базу данных, посмотрите, как она работает, а затем оптимизируйте / настройте.

Я ненавижу поднимать эту цитату, но в вашем случае она полностью применима:

Преждевременная оптимизация - корень всего зла (Дональд Кнут)

Не пытайтесь оптимизировать ваше решение до вы знаете, где будут ваши узкие места.

Просто смоделируйте свою базу данных как можно лучше. Беспокойся о своих ограничениях, PK, FKs, Indexes. Сделайте домашнее задание database-design . Тогда ваши данные и программное обеспечение идет. Только тогда вы увидите, где это работает и где болит. В этот момент вы оптимизируете.

Атакуйте врага только тогда, когда вы знаете, кто он.

Answer 2

И Адриан, и Люршер уже дали много подробностей.

Не зная, сколько данных и схемы сложно найти в дизайне.С самого начала при 80K активных пользователей нагрузка не кажется огромной, даже если они получают доступ к данным сотни раз в день.У меня такое чувство, что вы можете создать нормализованную схему для среды OLTP с таблицей пользователей и работать с другими таблицами.И снова это требование, которое будет управлять дизайном.Например, какое должно быть время ответа на пользовательский запрос - секунда, секунда?

Answer 3

это может быть эффективно с подходящим механизмом магазина для поддержки этой модели. Большинство современных хранилищ данных no-sql (hadoop, bigtable, mongodb и т. Д.) Отлично подходят для такого сценария.

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

По сути, я бы подумал, что no-sql не дает никаких преимуществ для отношений данных внутри самого острова пользовательских данных, поэтому различия в производительности в реляционных и нереляционных хранилищах должны не так важны

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