Влияет ли на производительность БД большое количество представлений в MySQL?

Question

[malan]

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

Answer 1

[Дмитрий Энтелис]

Какое отношение views имеют к безопасности?

Comments

[malan]

Позволяет поставить ограничение на чтение не всей таблицы, а только её части.

[Дмитрий Энтелис]

@malan: вы не доверяете коду который ходит в бд? Мне кажется что views все таки для другого предназначены. Может быть Вам посмотреть в сторону хранимых функций?

[malan]

@DmitriyEntelis: Я не доверяю пользователям которые ходят в БД. Немного абстрактный пример: допустим есть общая таблица покупок всех пользователей. Нужно чтобы каждый пользователь имел доступ лишь к просмотру своих покупок. Такой доступ организуется через представление к этой таблице. Вопрос в том насколько это тормознёт работу БД если таких представлений будет десятки и сотни тысяч?

[Дмитрий Энтелис]

1. Как это влияет на быстродействия я навскидку не знаю, но это нетрудно протестировать самостоятельно.
2. Я категорически считаю что это неправильно. Вы реально собираетесь создавать по паре десятков Views для каждого пользователя? А потом следить за их корректностью? А потом у вас поменяется база и придется перегенерить все views? Зачем это все?
Вы же не пускаете пользователей напрямую в БД. Пользователи работают с каким то интерфейсом.
Логично в него зашить все проверки?
ОК, если вы не доверяете даже клиенту - сделайте хранимку которая возвращает данные по какому то не подбираемому идентификатору юзера (токену, userid+хеш пароля, еще как то)
Это в любом случае будет на порядки проще в пооддержке чем куча views.

[ugodrus]

@malan: это полный бред. В конце концов ваши запросы к VIEW выглядят так SELECT * FROM (SELECT ... ) ...
Только при рациональном использовании субселектов, в субселекте (вашем view) должно быть минимум данных а у вас их там сотни а может даже и тысячи. Вы заставите сервер выполнять лишнюю работу т.к. те же данные проще и быстрее перелопатить одним запросом. А если вы еще захотите выполнить JOIN на двух view? Бедный сервер.

View не решат никакой проблемы с безопасностью. Безопасность обеспечивают права пользователя бд. А он у вас один. И если кто-то найдёт возможность кидать запросы к базе он не будет смотреть ваши 10 000 view`х. Он полезет к таблицам.

[malan]

@ugodrus: С чего вы взяли что пользователь у меня один если я пишу что их много?

[ugodrus]

Даже если так. Что мешает пользователю посмотреть чужую View? Если вы знаете как поставить ограничение на конкретную view - поделитесь.

[malan]

@ugodrus: Ну вообще-то ставить надо ограничение на всё, а потом уже разрешать доступ к тому, что требуется, в том числе и к конкретному представлению.

[ugodrus]

Смысл остаётся тем же. Вы собираетесь собрать геморрой. Впринципе можно было бы собрать такое допустим до 100 пользователей. Но больше... чистой воды мазохизм.

[Дмитрий Энтелис]

@ugodrus: В принципе подход автора понятен. Использование view это конечно редкостный идиотизм, а вот использовать хранимки безопасно реализующие необходимую логику - вполне неплохое решение.
Подключение к базе идет от пользователя которому запрещен доступ к таблицам, он может работать только через хранимки, которые осуществляют в том числе и всю проверку безопасности.
Таким образом была когда то реализована внутренняя база qip.ru :)

[malan]

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

[ugodrus]

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

[Дмитрий Энтелис]

@malan: у меня почему то возникло ощущение что у Вас есть бекграунд на oracle и какие то злые люди заставляют делать проект на mysql. Я прав? :)

[Дмитрий Энтелис]

@malan: в mysql view это грубо говоря просто alias для какого то запроса.
т.е select * from user_123_goods where ...
эквивалентен

select * from 
(
  select * from goods where user_id = 123
) 
where ...

что НЕРЕАЛЬНО медленно, т.к Ваш where не будет использовать индексы + каждый раз будет строить целиком "select * from goods where user_id = 123"

[Дмитрий Энтелис]

@malan: кстати подумал - если у вас юзеры так изолированы друг от друга - может вам проще и дешевле будет каждому пользователю сделать набор своих таблиц? или даже свою database для каждого пользователя? Заодно и масштабировать потом это будет просто и легко.

[malan]

@DmitriyEntelis: шутите? :) Хотя вопрос тот же. Как 10 000 - 100 000 таблиц будут себя вести себя в одной базе?

[Дмитрий Энтелис]

@malan: Есть мнение что тупняки начинаются при количестве ~150 000+ таблиц в одной дб.
Никто не мешает сразу сделать несколько баз + маппинг пользователя на конкретную базу.
Это даст возможность потом дешево и просто раскидывать пользователей по разным базам/разным серверам.

[Дмитрий Энтелис]

@malan: ну и все таки еще раз подумайте стоит ли овчинка выделки. что у вас за система, что требуется такая изоляция и нет доверия к коду?

[malan]

@DmitriyEntelis: за 150 000 спасибо. Этого вполне достаточно.

[ugodrus]

@DmitriyEntelis: Об этом и говорил. Продуктивность сильно упадёт. В моем комменте статья с живым примером этого. Да и управление всей этой бедой будет просто кошмарное. Проще развернуть API к такой базе и пользоваться только им чем администрировать такую базу.

[Дмитрий Энтелис]

@ugodrus: +1

Answer 2

[ugodrus]

Это будет иметь отношение к производительности почитайте. Плюсов никаких. Обращение к view = субселект. А если обьем view большой, то это будет вообще смерь.

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

Comments

[malan]

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