|
|
|
Хранение больших логов для каждого пользователя?
|
|||
|---|---|---|---|
|
#18+
Как лучше организовать хранение записей, логов(статистики) о пользователе? За 2 года среднего использования 1 юзер будет иметь около 2500 записей в базе(~3 записи в день на пользователя, и примерно 50тыс новых записей в день). Это реальные данные которые сейчас есть в аналогичном проекте. 1) Предполагается, что пользователей будет около 100 000 за 2 года. 2) Какой тип таблиц выбрать, myisam или innodb или же для каждого пользователя завести свою таблицу, делать ли дополнительные таблицы с предварительными расчетами и.т.д.? 3) Данные вставляются и считываются постоянно пользователями, запросов insert-replace значительно больше чем select. Данные всегда вставляются(замещают) в конец таблицы, то есть на сегодняшний день, записывать или менять данные предыдущих дней нельзя. Если идёт запись то только now() today. 4) Пользователь может делать выборку записей с группировкой и сортировкой по датам(по дням, месяцам, годам без группировки результата, выбирается последнее значение на дату), за всё время, только своих записей. 5) Генерация результата должна быть меньше секунды, пользователь не должен ждать пока там база рассчитывает данные несколько секунд. Данные такие, одни числовые типы и тип date. авторid_user(int(11)) -id пользователя id1(int(11)) - ключи на другие таблицы date(date) - дата когда была запись, уникальна в пределах дня id2(int(11)) - ключи на другие таблицы id3(int(11)) - ключи на другие таблицы id4(int(11)) - ключи на другие таблицы Уникальный индекс основан на 3 ключах id_user,id1,date(уникальность в пределах дня). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2016, 15:21:42 |
|
||
|
Хранение больших логов для каждого пользователя?
|
|||
|---|---|---|---|
|
#18+
mankingКакой тип таблиц выбрать, myisam или innodb InnoDB mankingили же для каждого пользователя завести свою таблицу Забудь как страшный сон. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2016, 16:13:48 |
|
||
|
Хранение больших логов для каждого пользователя?
|
|||
|---|---|---|---|
|
#18+
mankingили же для каждого пользователя завести свою таблицу Забудь как страшный сон.[/quot] А в чем именно недостаток этого? Работа с базой станет медленной, или размер станет огромным, или какое нибудь кэширование не будет нормально работать, внутренняя оптимизация запросов всё будет тормозить? Где нибудь есть статьи, где бы описывалось почему это плохо и ужасно заводить много таблиц? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2016, 16:32:21 |
|
||
|
Хранение больших логов для каждого пользователя?
|
|||
|---|---|---|---|
|
#18+
mankingГде нибудь есть статьи, где бы описывалось почему это плохо и ужасно заводить много таблиц?"Нормализация". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2016, 16:56:46 |
|
||
|
Хранение больших логов для каждого пользователя?
|
|||
|---|---|---|---|
|
#18+
За 2 года среднего использования 1 юзер будет иметь около 2500 записей в базе(~3 записи в день на пользователя, и примерно 50тыс новых записей в день). Не очень понятно, как так -- 2500 или 50 тыщ ? 1) Предполагается, что пользователей будет около 100 000 за 2 года. Дели на 10/100 сразу... Не будет. 2) Какой тип таблиц выбрать, myisam или innodb или же для каждого пользователя завести свою таблицу, делать ли дополнительные таблицы с предварительными расчетами и.т.д.? Inno. Но совсем не поэтому. 3) Данные вставляются и считываются постоянно пользователями, запросов insert-replace значительно больше чем select. Данные всегда вставляются(замещают) в конец таблицы, то есть на сегодняшний день, записывать или менять данные предыдущих дней нельзя. Если идёт запись то только now() today. У таблицы нет начала и конца... 4) Пользователь может делать выборку записей с группировкой и сортировкой по датам(по дням, месяцам, годам без группировки результата, выбирается последнее значение на дату), за всё время, только своих записей. индекс по (user, date) -- и вперёд... 5) Генерация результата должна быть меньше секунды, пользователь не должен ждать пока там база рассчитывает данные несколько секунд. Ну, это ты сначала таблицы сделай, данными наполни, запрос напиши, а потом уже будешь рассуждать, что он там тебе должен.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2016, 17:08:58 |
|
||
|
Хранение больших логов для каждого пользователя?
|
|||
|---|---|---|---|
|
#18+
AkinamankingГде нибудь есть статьи, где бы описывалось почему это плохо и ужасно заводить много таблиц?"Нормализация". По теме "нормализация" не нашел ничего что связано с проблемами множества таблиц. Можете дать ссылку на это? Почитал это. https://dev.mysql.com/doc/refman/5.5/en/creating-many-tables.html https://dev.mysql.com/doc/refman/5.5/en/table-cache.html Получается, что когда много таблиц, то запись и чтение очень медленными будут. Из-за кеша куда помещаются несколько таблиц, а так как уникальных таблиц много, то они постоянно удаляются и помещаются в кеш снижая производительность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2016, 17:09:49 |
|
||
|
Хранение больших логов для каждого пользователя?
|
|||
|---|---|---|---|
|
#18+
mankingmankingили же для каждого пользователя завести свою таблицу Забудь как страшный сон. А в чем именно недостаток этого? [/quot] Мне кажется, это очевидно. Попробуй напиши запрос, выдающий статистику по всем пользователям... mankingРабота с базой станет медленной, или размер станет огромным, или какое нибудь кэширование не будет нормально работать, внутренняя оптимизация запросов всё будет тормозить? Где нибудь есть статьи, где бы описывалось почему это плохо и ужасно заводить много таблиц? Что плохо почему? Почему плохо проектировать БД как посетитель детского сада ? Таких статей, боюсь, нет. Есть другие -- как проектировать БД правильно. И ты там нигде не найдёшь "для каждого пользователя завести свою таблицу". А если найдёшь -- покажи нам, мы тебе скажем обосновано, почему автор этой статьи -- глубокий безграмотный дундук. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2016, 17:12:03 |
|
||
|
Хранение больших логов для каждого пользователя?
|
|||
|---|---|---|---|
|
#18+
mankingПочитал это. Получается, что когда много таблиц, то запись и чтение очень медленными будут. Интересно ты статьи читаешь... Главное, выводы делаешь очень интересные. Почитай лучше другие статьи, по теме "партицирование таблиц" "table partitioning ( in MySQL)" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2016, 17:14:23 |
|
||
|
Хранение больших логов для каждого пользователя?
|
|||
|---|---|---|---|
|
#18+
mankingПо теме "нормализация" не нашел ничего что связано с проблемами множества таблиц. А то, что одна сущность - одна таблица, там не написано разве? mankingПолучается, что когда много таблиц, то запись и чтение очень медленными будут. Ну это особенности файловой системы прежде всего. И кэширования, само собой - причём как системного, так и MySQL-ного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2016, 17:21:35 |
|
||
|
Хранение больших логов для каждого пользователя?
|
|||
|---|---|---|---|
|
#18+
manking, погугли про какую-то модную лабуду навроде logstash, elasticsearch и mongodb, а мускуль оставь для задач рсубд, а не собирания логов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2016, 20:26:06 |
|
||
|
Хранение больших логов для каждого пользователя?
|
|||
|---|---|---|---|
|
#18+
мимопроходилтреднечиталmanking, погугли про какую-то модную лабуду навроде logstash, elasticsearch и mongodb, а мускуль оставь для задач рсубд, а не собирания логов Эт всё дерьмо собачье. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2016, 13:47:08 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39152997&tid=1832250]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
202ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 218ms |
| total: | 529ms |

| 0 / 0 |
