|
|
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
В филиале предприятия 1000 рабочих. Один работник в среднем изготавливает 100 изделий за смену. Все параметры по каждой детали записываются в базу. Контролер этого филиала выборочно проверяет качество детали по данным из базы. В компании 100 филиалов, в каждом свои рабочие и свой контролер. Для хранения параметров о детали используется своя таблица. Как рациональней сделать выборку данных для контролера каждого филиала? 1 вариант. Для всех филиалов создать одну общую таблицу, (тогда в день 100 филиалов, добавляет по 100 изделий от 1000 рабочих. Итого 10 000 000 строк в день, за месяц 310 000 000) Тогда в конце месяца для контролера каждого филиала производится выборка данных из таблицы, где ему нужны только записи о деталях его филиала. Всего 1% от общего числа но запросом будут просматриваться все записи. 2 вариант. Для каждого филиала создать свою таблицу, (тогда 100 таблиц по 100 000 записей в день, за месяц 3 100 000) Тогда в конце месяца для контролера каждого филиала производится выборка данных из его собственной таблицы. Следует учесть что все контролеры начинают работу с базой в одно и тоже время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 23:42:24 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
авторВ филиале предприятия 1000 рабочих. Один работник в среднем изготавливает 100 изделий за смену. задачу распиши подробней. на всякий случай - есть секционирование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 04:00:10 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
Второй - это вариант не для SQL, а для файловой БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 08:55:43 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
Вот этот: Aleksandrttt1 вариант. Для всех филиалов создать одну общую таблицу, (тогда в день 100 филиалов, добавляет по 100 изделий от 1000 рабочих. Итого 10 000 000 строк в день, за месяц 310 000 000) Тогда в конце месяца для контролера каждого филиала производится выборка данных из таблицы, где ему нужны только записи о деталях его филиала. Всего 1% от общего числа но запросом будут просматриваться все записи. вариант, и -- желательно -- другой сервер СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 15:42:51 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
AleksandrtttВ филиале предприятия 1000 рабочих. Один работник в среднем изготавливает 100 изделий за смену. Все параметры по каждой детали записываются в базу. Контролер этого филиала выборочно проверяет качество детали по данным из базы. В компании 100 филиалов, в каждом свои рабочие и свой контролер. А что это у тебя такие цифры все круглые ? не верю. Не может быть ровно 100 филиалов. AleksandrtttДля хранения параметров о детали используется своя таблица. И, наверное, не одна.... Как минимум master-detail должно же быть, наверное ? нет ? AleksandrtttСледует учесть что все контролеры начинают работу с базой в одно и тоже время. Это пофигу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 15:45:43 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
AleksandrtttВсего 1% от общего числа но запросом будут просматриваться все записи .покажите мне этого чудо-контролёра, способного проверить 3М записей (за пару дней) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 16:20:09 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
ну проверил контролер то что записываються данные по каждой детали, которые сделал рабочий за день, не означает что должно быть много записей в базе. 1000 гаек сделаных одним рабочим чем отличаються кроме порядкового номера? вот и хронить дата, ссылка на васю пупкина, список из 1000 номеров деталей. или у тебя выборки предвидяться - отобрать детали с номером больше 300 и меньше 333 ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 23:05:27 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
Я Вам очень благодарен за советы. Не знал о секционирование спасибо! То есть если создать одну таблицу для всех филиалов и использовать секционирование то каждый филиал работает со своим объемом данных. Тут еще рекомендовали использовать другую СУБД. Какую? И если все же остановится на mySQL то какой тип таблицы использовать? P.S. Цифры круглы потому что я студент и это часть задания контрольной. На лекциях разбираем в основном sql запросы, про оптимизацию ни слова. Хочется разобраться, поэтому обратился к Вам. Простите если кого то унизил разбором этого задания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 23:26:32 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
Прочитал про секционирование. Насколько я понял это посути второй вариант. Прирост в скорости будет сомнителен так как для каждой секции будет открываться свой файл и будет увеличена нагрузка на диск, или я не прав? И еще вопрос: увеличители скорость поиска индексирование, если выборка производится по первичному ключу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 23:57:44 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
AleksandrtttНе знал о секционирование спасибо! То есть если создать одну таблицу для всех филиалов и использовать секционирование то каждый филиал работает со своим объемом данных. Да. AleksandrtttТут еще рекомендовали использовать другую СУБД. Какую? Любую, кроме MySQL. Postgres например. AleksandrtttИ если все же остановится на mySQL то какой тип таблицы использовать? InnoDB AleksandrtttP.S. Цифры круглы потому что я студент и это часть задания контрольной. На лекциях разбираем в основном sql запросы, про оптимизацию ни слова. Хочется разобраться, поэтому обратился к Вам. Простите если кого то унизил разбором этого задания. Если это учебная задача, то её можно решать в лоб, без использования partitioning. Ты вряд ли наберёшь реальный объём данных для тестирования и демонстрации, при сдаче всё будет ОК и так. AleksandrtttПрочитал про секционирование. Насколько я понял это посути второй вариант. Прирост в скорости будет сомнителен так как для каждой секции будет открываться свой файл и будет увеличена нагрузка на диск, или я не прав? Это не совсем второй вариант, потому что это реализуется уровнем ниже, на уровне СУБД, а логически для тебя это -- одна таблица. Прирост скорости зависит не от кол-ва открытых файлов. Прирост скорости тут как раз должен быть (для каких-то запросов, естественно, в рамках одного филиала), поскольку размер данных для одного филиала упадёт на два порядка, это хорошо. Но проблема в том, что в реальности филиалов так много не бывает, их по кол-ву гораздо скромнее обычно, порядка 10. А это -- мало. AleksandrtttИ еще вопрос: увеличители скорость поиска индексирование, если выборка производится по первичному ключу? Не понял. По PK надо всегда создавать индекс. Ну и в InnoDB не создать индекс по PK не получится. Там он обязателен и он кластерный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2014, 17:16:08 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
Накачал кучу учебников по MySQL, правда очень старых версий. Помогите разобраться. В самой базе данных можно создавать: хранимые процедуры и триггеры, что они делают я понял. Но зачем это надо? Можно же и без них сделать все, к примеру скриптом и sql запросом! И еще при проектирование базы данных рекомендуют исключить дублирование записей в таблицах. Что лучше сделать продублировать запись (тип varchar) или оставить его в другой, при условии, что при каждом третьем запросе к этой таблицы нужно его значение. (приоритет на выборку). Так же подскажите про индексацию таблиц. Насколько я понял индексация это упорядочивание значений таблицы по которому проводят поиск. То есть если выборка происходит по первичному ключу то эту таблицу индексировать не нужно ПК и есть индекс или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2014, 00:32:48 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
AleksandrtttНакачал кучу учебников по MySQL, правда очень старых версий. Помогите разобраться. В самой базе данных можно создавать: хранимые процедуры и триггеры, что они делают я понял. Но зачем это надо? Можно же и без них сделать все, к примеру скриптом и sql запросом! Хранимые процедуры, в отличие от твоих запросов из приложения прекомпилируются и при их вызове непосредственном вызове их повторная компиляция и вычисления плана не требуется. К тому же, т.к. хранимые процедуры - это объекты БД, для них можно настраивать ограничения доступности на исполнение теми или иными пользователями независимо от того имеют ли пользователи права на объекты, используемые в данных процедурах. К примеру, вы можете настроить привилегии на базу таким образом, что прямая вставка в таблицу данных будет недоступна, а через вашу хранимую процедуру, которая выполняет пре-обработку данных - доступна. Что касается триггеров, то их достоинства в событийности срабатывания. К примеру, часто в триггерах делают custom-механизмы для логирования действий пользователей и более сложные проверки вставляемых/изменяемых данных, чем позволяет нам сделать обычный CHECK. AleksandrtttИ еще при проектирование базы данных рекомендуют исключить дублирование записей в таблицах. Что лучше сделать продублировать запись (тип varchar) или оставить его в другой, при условии, что при каждом третьем запросе к этой таблицы нужно его значение. (приоритет на выборку). Я смутно понял о чем вы. Но полагаю вопрос звучит "что лучше - нормализация или денормализация"? Зависит от ситуации. Излишняя нормализация может привести к снижению производительности при выборке. Денормализация может привести к неконсистентности данных. AleksandrtttТак же подскажите про индексацию таблиц. Насколько я понял индексация это упорядочивание значений таблицы по которому проводят поиск. То есть если выборка происходит по первичному ключу то эту таблицу индексировать не нужно ПК и есть индекс или нет? Только кластерный индекс физически упорядочивает строки в таблице. Некластерный индекс не упорядочивает строки в таблице и вообще никак на них не влияет. По первичному ключу автоматически строится кластерный индекс поэтому при выборке по первичному ключу дополнительные индексы не требуются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2014, 12:40:26 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
Какая-то у меня проблема с руская языка, окончания в словах ни к черту =\ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2014, 12:42:03 |
|
||
|
Оптимизация бд
|
|||
|---|---|---|---|
|
#18+
Я смутно понял о чем вы. Но полагаю вопрос звучит "что лучше - нормализация или денормализация"? Зависит от ситуации. Излишняя нормализация может привести к снижению производительности при выборке. Денормализация может привести к неконсистентности данных. [quot Aleksandrttt] не зависит это от ситуации. нормализация - всегда хорошо, ненормализация - всегда плохо. нет такого понятия "излишняя нормализация". и не надо путать ненормализованность данных с денормализацией. последнее предполагает сначала нормализацию, а потом сознательный контролируемый ввод аномалий с определенной целью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2014, 06:48:03 |
|
||
|
|
start [/forum/topic.php?fid=47&msg=38825046&tid=1833828]: |
0ms |
get settings: |
6ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
53ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 371ms |
| 0 / 0 |
