|
|
|
Структура БД для мультиаккаунтного сервиса
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток. Наставьте на путь истинный)) или ткните что почитать по следующему вопросу: Задуман мультиаккаунтный сервис. В некоторых таблицах сервиса потенциально может быть очень много записей, например в таблице учета посещений определеных веб-страниц. Что бы было понятно, приведу пример без подробностей. Таблица hits, поля таблицы: - id - user_id - page_id - account_id - hit_time Вопрос собственно вот в чем: оставить таблицу в таком виде или же при создании каждого аккаунта создавать для него отдельную структуру таблиц, естественно поле account_id в этом случае будет лишним. В этом случае, насколько я понимаю, быстрее будет выборка из таблицы, поскольку, нет поля account_id, которое нужно учитывать в выборке, т.е. можно обойтись без составного индекса, да и сами таблицы будут сильно меньше, чем одна общая таблица. Непонятен следующий момент, допустим на каждый аккаунт требуется 20 таблиц. 1000 аккаунтов, это уже 20 000 таблиц. Как это может отразится на работе Mysql? Не будет ли каких-то проблем из-за такого большого кол-ва таблиц? Возможно кто-то делал подобное, прошу поделиться опытом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2015, 21:43:32 |
|
||
|
Структура БД для мультиаккаунтного сервиса
|
|||
|---|---|---|---|
|
#18+
Разделение нецелсообразно. Единая таблица плюс грамотная индексация. А вся логика - искючительно на ХП и УДФ, исключающих доступ к "чужим" данным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2015, 22:25:01 |
|
||
|
Структура БД для мультиаккаунтного сервиса
|
|||
|---|---|---|---|
|
#18+
AkinaРазделение нецелсообразно. Единая таблица плюс грамотная индексация. А вся логика - искючительно на ХП и УДФ, исключающих доступ к "чужим" данным. Большое спасибо за ответ! Но хотелось бы услышать (кратко) аргументы против такого подхода. Насколько я знаю, технически ограничений нет (возможно плохо смотрел). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2015, 10:59:40 |
|
||
|
Структура БД для мультиаккаунтного сервиса
|
|||
|---|---|---|---|
|
#18+
otrubinНасколько я знаю, технически ограничений нет. Они есть, но их достичь малореально. Аргументов за единое хранилище предостаточно, они не раз озвучивались, поиск поможет. Вот некоторые: - DDL, работающий не с временными структурами уровня сеанса или соединения, в клиентском приложении - однозначное свидетельство плохой структуры, к тому же требует явно избыточных прав, что само по себе есть косяк и дыра в безопасности; - Большое количество таблиц приводит к быстрому вымыванию кэшей (данных, индексных, запросов), что снижает эффективность работы сервера; - Любые обработки, требующие доступа к данным более чем одного пользователя (сравнения, статистики и пр.), требуют динамического построения запросов (снова минус эффективность - тем более что становится проблемным использовать индексацию) и избыточного доступа к метаданным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2015, 11:13:50 |
|
||
|
Структура БД для мультиаккаунтного сервиса
|
|||
|---|---|---|---|
|
#18+
otrubinAkinaРазделение нецелсообразно. Единая таблица плюс грамотная индексация. А вся логика - искючительно на ХП и УДФ, исключающих доступ к "чужим" данным. Большое спасибо за ответ! Но хотелось бы услышать (кратко) аргументы против такого подхода. Насколько я знаю, технически ограничений нет (возможно плохо смотрел). походу не то что не смотрел, даже и не думал... а если пользователей милион? а если милиард... а трилиард таблиц....точно ограничения нету? а список таблиц ...на 30 милионов...как из этого списка найти нужную таблицу? индексацией...индексацией по чему ? если имена таблиц по принципу -имя-+-айди-юзера- а если по такому индексу. то чем это принципиально будет отличаться от поиска с индексацией по айдиюзера в одной таблице? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2015, 15:29:29 |
|
||
|
Структура БД для мультиаккаунтного сервиса
|
|||
|---|---|---|---|
|
#18+
если есчё глубже копнуть.... то при одной таблице при использовании составного индекса -айди-юзера- + -некое-поле будет идти поиск - сначала таблицы в огромном списке таблиц, в самом лучшем случае по индексу тогоже юзера, потом поиск этой таблицы на винчестере (если на каждую таблицу отдельный файл) + в самой таблице поиск по -некое-поле- с другой стороны...а если для статистики надо подсчёт сделать по всем юзерам- ... пооткрывать в цикле 30млн файлов...врядли дело быстрое таблица прав, в лудшем случае, все юзеры имеют глобальные права..... если же каждому юзеру есчё права на его таблицы прописывать, таблица прав разростаеться(самой субд) ... я к тому, что если помыслить... то это даже не идея...ибо не уменьшает, а наоборот добавляет вычислительной нагрузки. единственный выигрыш который может быть достигнут - это если заменить боллее медленый процесс, более быстрым, или разпаралелить. - одна таблица, один файл=один винчесте - чтение с него частое -разбили на два файла, = два разных винчестера...чтение тогоже обьёма произойдёт быстрее - но 30млн винчестеров...врядли... или таблица делиться на таблица все кроме сегодня(актуальные данные) и сегодня. и сегодня размещаеться в оперативке или на влешовой памяти... тут можно чтото сукорить. а подход....вместо 30 млн записей в одной таблице, 30 млн таблиц по одной записи... это в стиле мускл я учу, а то как мускл работает не мое дело...этож не мне 30млн ...у меня одна запись, а остальное проблема мускла...пусть как хочет так и работает... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2015, 15:37:22 |
|
||
|
|
start [/forum/topic.php?fid=47&msg=38979152&tid=1833085]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 345ms |
| 0 / 0 |
