если я хочу спроектировать что-то вроде GoogleSpreadsheets
Я так понимаю, структура будет примерно такой:
Ид_владельца
Код_листа
Номер_строки
Имя_столбца
Значение_ячейки_таблицы
У таблицы может быть до миллиона строк и ста столбцов. А это 100 000 000 записей.
100 пользователей - 10млрд записей (при условии полного заполнения таблицы, конечно)
Не лучше ли в данном случае создавать для каждого пользователя отдельную таблицу в базе данных, и уже на уровне приложения обращаться сразу к нужной, избавляясь о.т лишней фильтрации для каждого запроса?
апну этот вопросик) На сколько я понимаю, здесь можно стрельнуть себе в ногу на шардировании, при том, что особой скорости в обработке не получим. И если менять структуру таблицы - придется "перебирать" все. Но из плюсов - если придется блокировать таблицу - таблица другого пользователя не будет заблокирована. На сколько это адекватное решение? :)
Всем привет. Продолжаю продолжать задавать вопросы про производительность ключей) А что, если я хочу спроектировать что-то вроде GoogleSpreadsheets Я так понимаю, структура будет примерно такой: Ид_владельца Код_листа Номер_строки Имя_столбца Значение_ячейки_таблицы У таблицы может быть до миллиона строк и ста столбцов. А это 100 000 000 записей. 100 пользователей - 10млрд записей (при условии полного заполнения таблицы, конечно) Не лучше ли в данном случае создавать для каждого пользователя отдельную таблицу в базе данных, и уже на уровне приложения обращаться сразу к нужной, избавляясь о.т лишней фильтрации для каждого запроса?
Тут ещё применяется (анти)паттерн "Умная Эльза" - на практике конечно же не будет мильон документов по тысяче пользователей, будет лишь по 4-5 документов у каждого пользователя и разделять он каждый документ будет с 2-5 другими пользователями.
Обсуждают сегодня