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

В подкасте StackOverflow нет. 19, Джо описывает решение Fogcreek иметь одну базу данных для каждого клиента вместо одной базы данных для ВСЕХ клиентов. Это вроде как заставляет меня задуматься о следующем.

  1. Предполагая, что у меня есть 1000 пользователей.
  2. У каждого пользователя 100 клиентов.
  3. У каждого клиента есть 1000 товаров.

Это означает, что у меня будет 1000 x 100 x 1000 = 100 000 000 продуктов, связанных с пользователями. Теперь, если я сделаю запрос к таблицам соединения для пользователя и всех продуктов его клиента, сколько времени должно быть разумным, если я использую для этой цели только одну базу данных?

ОБНОВЛЕНИЕ

Может быть, я недостаточно ясно ответил на свой вопрос. Предположим, мне нужно выполнять всевозможные напуганные запросы (min, max, group и т. Д.) С наборами данных, как описано выше, будет ли это медленным (или нет) до такой степени, что имеет смысл иметь стратегию с несколькими базами данных, например . 1 БД / клиент, сегментирование базы данных и т. Д.


database architecture multi-tenant query-optimization
person JasonOng    schedule 10.10.2008    source источник

Ответы (4)


arrow_upward
1
arrow_downward

Думаю, ответ зависит от вашего выбора СУБД. С Oracle, например, одна большая база данных определенно была бы предпочтительнее, фактически 1000 идентичных баз данных были бы сочтены абсурдными и неуправляемыми.

Кроме того, у вас никогда не возникнет необходимость запускать запросы среди пользователей? например найти пользователя с наибольшим количеством товаров. Или это действительно 1000 дискретных «частных» баз данных, и никто не имеет общего доступа к данным? Даже в этом случае Oracle, например, предлагает «виртуальную частную базу данных», чтобы обслуживать это в единой базе данных.

person Tony Andrews    schedule 10.10.2008

arrow_upward
1
arrow_downward

Основными причинами использования стратегии «одна база данных на клиента» являются безопасность и управляемость. Хотя концепция резервного копирования / восстановления для одной базы данных, а не для 100 клиентских баз данных действительно приносит вам победу, у нее есть некоторые недостатки. Некоторые из проблем с общей базой данных:

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

  • Все приложение должно быть осведомлено о модели безопасности, что добавляет некоторую степень сложности. Опять же, с конфиденциальными данными это имеет последствия для соблюдения.

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

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

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

person ConcernedOfTunbridgeWells    schedule 11.10.2008

arrow_upward
0
arrow_downward

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

person Cade Roux    schedule 10.10.2008

arrow_upward
0
arrow_downward

Если вы хотите получить все это, все столбцы и строки, без фильтрации или агрегирования, вам придется ждать очень долго. Я не думаю, что есть какое-то разумное количество времени, которое вы можете использовать здесь в качестве эталона. Вам просто нужно подождать :)

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

person jop    schedule 10.10.2008