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

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

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

Скорее всего, у меня будет БД для входа в систему и информации о сертификате. но как только пользователь вошел в систему, предположим, что у него есть UserID.

Используя этот идентификатор пользователя, я знаю, что могу отслеживать разрешения объекта (на стороне сервера). Но если у меня есть более 100 000 записей, я могу увидеть проблемы с производительностью при попытке получить все записи, к которым у конкретного пользователя есть доступ при входе в систему. Я, вероятно, буду использовать React с хранилищем Redux, так что, как только я получу все свои данные один раз, мне не нужно будет беспокоиться о последовательном извлечении данных (я также могу добавить флаг в базу данных, который позволяет пользователю знать, соответствуют ли его данные дата).

Это моя мысль:

  • 1 база данных для хранения логина пользователя и информации о сертификате
    • Это в целях безопасности
    • Уникальный сервер будет работать для всех запросов на вход
  • 1 база данных для хранения доступных данных
    • Эта база данных содержит:
      • 1 таблица для ресурсов (настраиваемая информация о пользователе, около 5000 записей)
        • Можно отсортировать таким образом, чтобы у каждого администратора был зарезервированный набор записей.
      • 1 таблица для инфоОбъекта (100 000+ записей)
      • дополнительные таблицы для других доступных данных, не связанных с информационным объектом (примерно 5000 записей в каждой)
    • Используйте UserId для получения своего конкретного ресурса
      • содержит все UserId, для которых этот пользователь имеет разрешение на просмотр информации
    • Извлекает все записи, связанные с их идентификатором, и все идентификаторы, к которым у них есть доступ.

ПРИМЕЧАНИЕ. У меня есть мысль использовать для этого базу данных SQL, если вы считаете иначе, пожалуйста, укажите это!

Спасибо!

«более 100 000 записей» на самом деле не «большие данные». Две базы данных могут быть плохой идеей, поскольку обеспечение ссылочной целостности между базами данных может быть сложным или невозможным. Но это очень расплывчатый вопрос или на него нельзя ответить кратко. Поэтому я считаю, что это не по теме здесь. Возможно, вы захотите провести небольшое исследование и разбить проблему на более мелкие фрагменты, о которых вы можете спросить. Или наймите консультанта, который проведет вас через это.

sticky bit 13.12.2020 03:44

Я проголосовал за закрытие на основе мнения. Тем не менее, с базой данных SQL все в порядке, и количество записей небольшое, а не большое.

Gordon Linoff 13.12.2020 13:48
ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
Понимание Python и переход к SQL
Понимание Python и переход к SQL
Перед нами лабораторная работа по BloodOath:
0
2
118
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Для больших наборов данных я бы предложил секционирование и индексирование таблиц. Проверьте секционированные таблицы и индексы для БД Oracle, то же самое можно сделать и для других БД SQL.

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

Gordon Linoff 13.12.2020 13:46

Другие вопросы по теме