ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Тепловые потери в коробке передач
12 сообщений из 12, страница 1 из 1
Тепловые потери в коробке передач
    #39076109
Фотография Lumix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lumix
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
/** клиентская фейсовка */
create cust (custId int, custTit text, ...);

/** пространство потенциала аналитики */
create metamoz (metaId, metaMask char(4), ...);

/** сеточная трансмиссия */
create a (i int, m int);
create b (i int, m int);
create c (i int, m int);
create d (i int, m int);
create f (i int, m int);



Существует ли какое-нибудь эмпирическое правило, чтобы примерно знать какие потери мы несем с каждым звеном джоина, который лежит между полезной клиентской таблицей с одного конца и пространственно-аналитической таблицей по которой задаются критерии фильтрации с другой стороны, а между ними мы устанавливаем "редукторы", то есть что-то типа коробки передач (трансмисии)?

Для примера, два селекта взятых с потолка.

Код: sql
1.
2.
3.
4.
5.
select * from cust
    join a on a.m = custId
    join metamoz on a.i = metaId
        && metaMask = 'some'
;



vs

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
select * from cust
    join a on a.m = custId
    join b on b.m = a.i
    join c on c.m = b.i
    join d on d.m = c.i
    join f on f.m = d.i
    join metamoz on f.i = metaId
        && metaMask = 'some'
;



1) Можно ли пользуясь какими-то эмпирическими правилами и размышлениями оценить насколько во втором селекте из-за наличия большего количества каскадов с джоинами будут потери?

2) Насколько вообще допустимо вести речь о тезисах типа: каждый дополнительный джоин увеличивает нагрузку на сервер на 10% и увеличивает скорость на 25%?
В данном случае 10% и 25% взяты "с потолка", у меня нет реальных цифр, потому что не представляю что там внутри происходит и как. Я просто для примера взял эти цифры.

3) Или может быть в подобных ситуациях количество вложенных через инты джоинов при количестве записей менее 100 тыс. вообще никакой роли не играет ни по нагрузке на сервер ни по скорости выполнения?
...
Рейтинг: 0 / 0
14.10.2015, 01:15:21
| Ответить | Цитировать | Написать  
Тепловые потери в коробке передач
    #39076118
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
javajdbc
Участник
Lumix,

...зависит...

если таблички б-ф висят в мемори, то каждый поиск по
индексу займет 1-10 микросекунд на среднем железе.

затем надо смотреть кардиналити этих таблиц:
дополнительные таблицы могут размножить результат суммардно
в милионы раз....или обрезать результат до одной строчки.

...вообше вы задали ну настолько абстрактный вопрос...
...
Рейтинг: 0 / 0
14.10.2015, 02:51:06
| Ответить | Цитировать | Написать  
Тепловые потери в коробке передач
    #39076200
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akina
Участник
Поскольку речь идёт об INNER JOIN, то фактически нужно анализировать два аспекта.
Первый - соотношение размножения записей за счёт дубликатов по ключу связывания справа и отсеивания записей слева.
Второй - увеличение дисковых операций за счёт считывания дополнительных индексов, отсутствующих в кэше.
А дополнительными операциями в памяти в первом приближении можно смело пренебречь.
...
Рейтинг: 0 / 0
14.10.2015, 09:19:56
| Ответить | Цитировать | Написать  
Тепловые потери в коробке передач
    #39076202
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Lumix,

если ты всё делаешь правильно, join - довольно дешевая операция, а именно
n ✖ log m

где n количество записей во внешней (отфильтрованной) таблице, m - количество записей во внутренней таблице.

все делаешь правильно значит, что join по КНФ (без or), по равенству и по первичному ключу или по полю/полям с индексом.

кратко: join-на не нужно бояться.
...
Рейтинг: 0 / 0
14.10.2015, 09:22:54
| Ответить | Цитировать | Написать  
Тепловые потери в коробке передач
    #39076338
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
javajdbc
если таблички б-ф висят в мемори, то каждый поиск по
индексу займет 1-10 микросекунд на среднем железе.


Таблички в СУБД НИКОГДА не висят в памяти. Это СУБД, а не эксель. Часть данных в памяти (кэш), часть -- на диске.
Поиск по индексу занимает мало времени НЕЗАВИСИМО от того, в памяти таблица или не в памяти.
...
Рейтинг: 0 / 0
14.10.2015, 11:35:53
| Ответить | Цитировать | Написать  
Тепловые потери в коробке передач
    #39076364
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akina
Участник
MasterZivТаблички в СУБД НИКОГДА не висят в памяти. Это СУБД, а не эксель. Часть данных в памяти (кэш), часть -- на диске.
Слишком категорично.
На диске - всё. А в памяти - копия некоторой части данных. Возможно, 0%, а, возможно, и все 100%. Чем компактнее таблица и чем чаще она используется, тем больше вероятность, что все 100% данных кэшированы.
...
Рейтинг: 0 / 0
14.10.2015, 11:51:04
| Ответить | Цитировать | Написать  
Тепловые потери в коробке передач
    #39076518
Фотография Lumix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lumix
Участник
javajdbc...вообше вы задали ну настолько абстрактный вопрос...

Вопрос конечно абстрактный, но он больше на понимание принципов поведения.
А в целом задача при всей своей абстрактности достаточно изолированная.
Это не летели два крокодила, один зеленый, другой на север... :-)

MasterZivесли ты всё делаешь правильно, join - довольно дешевая операция, а именно
n ✖ log m

где n количество записей во внешней (отфильтрованной) таблице, m - количество записей во внутренней таблице.

все делаешь правильно значит, что join по КНФ (без or), по равенству и по первичному ключу или по полю/полям с индексом.


Немного не понял по поводу алгоритмической цены n * log m, потому что коли тут только два параметра, то возможно вы имели ввиду стоимость запроса без коробки передач вообще, то есть вот так

Код: sql
1.
2.
3.
select * from cust c
    join metamoz m on m.metaId = c.metaId
        && metaMask = 'some'



Значит ли это, что вы тем самым утверждаете, что если в таблицах коробки передач все поля i являются интовыми примарными ключами, а на все интовые поля m тоже кинуть индекс, то при объемах таблиц cust и metamoz до 100 тыс. записей коробка передач вообще не будет создавать никакого заметного "трения" на фоне стоимости запроса без коробки?

Примечания

1) В этой задаче select всегда меньше или равен select count(*) from cust .
Всегда.
Вне зависимости от "винегрета", хранящегося в таблицах коробки передач.

2) В этой задаче важно выяснить не стоимость самого селекта, а разницу в стоимости между селектом с "коробкой" и без "коробки".

- Если окажется, что "коробка" ничего не добавляет, то есть добавляет 10-20% или меньше на фоне основного запроса, ну тогда и хрен с ней (то есть это классная новость).

- Но если окажется, что "коробка" по сравнению с прямым запросом увеличивает стоимости в разы, тогда хотелось бы выяснить эмперические правила прироста стоимости при каждом последующем каскаде.
...
Рейтинг: 0 / 0
14.10.2015, 13:27:01
| Ответить | Цитировать | Написать  
Тепловые потери в коробке передач
    #39076584
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akina
Участник
Lumixесли окажется, что "коробка" по сравнению с прямым запросом увеличивает стоимости в разы
А так вполне может оказаться, и даже то, что
LumixВ этой задаче select всегда меньше или равен select count(*) from cust .
Всегда.
не поможет - потому что по мере прохождения по "коробке" количество записей с исходной сотни может запросто раздуться до миллиарда, а потом снова ужаться до полусотни выходных записей. Понятно, что в этом случае мы только на одних выделениях памяти и кэшированиях на диск потеряем на порядки больше. Опять же понятно, что если выпадает длинная промежуточная цепь джойнов, то и подобных казусов не приключится.

Но вопрос в любом случае не то что абстрактный, а даже где-то странноватый. Ну просто потому что трудно представить предметную область, где ОБЕ версии построения БД были бы одинаково правильными. Уж скорее всего они будут одинаково НЕправильными. И существует некая третья возможная структура, которая более оптимальна, чем обе рассматриваемые.
...
Рейтинг: 0 / 0
14.10.2015, 14:24:57
| Ответить | Цитировать | Написать  
Тепловые потери в коробке передач
    #39076598
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
AkinaMasterZivТаблички в СУБД НИКОГДА не висят в памяти. Это СУБД, а не эксель. Часть данных в памяти (кэш), часть -- на диске.
Слишком категорично.


Слишком категорично, потому что это -- модель вычислений СУБД, это не реальное положение дел.
...
Рейтинг: 0 / 0
14.10.2015, 14:33:43
| Ответить | Цитировать | Написать  
Тепловые потери в коробке передач
    #39076607
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Какая блин коробка передач, ты что, тракторист, что ли ?


[quot Lumix]
Немного не понял по поводу алгоритмической цены n * log m, потому что коли тут только два параметра, то возможно вы имели ввиду стоимость запроса без коробки передач вообще, то есть вот так




Это -- стоимость одной операции JOIN-а двух таблиц. Внешняя имеет на входе n записей, внутренняя имеет всего m записей.
цена всей операции n * log m, если это NLJ и таблица имеет индекс по условию JOIN-а.
n * m, если это NLJ и таблица НЕ имеет индекс по условию JOIN-а.


[quot Lumix]
Значит ли это, что вы тем самым утверждаете, что если в таблицах коробки передач все поля i являются интовыми примарными ключами, а на все интовые поля m тоже кинуть индекс, то при объемах таблиц cust и metamoz до 100 тыс. записей коробка передач вообще не будет создавать никакого заметного "трения" на фоне стоимости запроса без коробки?


Да. Ты понял!
...
Рейтинг: 0 / 0
14.10.2015, 14:38:48
| Ответить | Цитировать | Написать  
Тепловые потери в коробке передач
    #39076898
Фотография Lumix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lumix
Участник
MasterZiv, ok!
...
Рейтинг: 0 / 0
14.10.2015, 19:59:38
| Ответить | Цитировать | Написать  
Тепловые потери в коробке передач
    #39077045
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
javajdbc
Участник
>> MasterZiv]
>> Таблички в СУБД НИКОГДА не висят в памяти.

не бросайтесь кванторами понапрасну:
https://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html

...хотя конечно же я имел ввиду кеш...

>> Поиск по индексу занимает мало времени НЕЗАВИСИМО
>> от того, в памяти таблица или не в памяти.

...и опять не бросайтесь кванторами понапрасну...
...на одном и томже железе единичный поиск по индексу через диск будет
как минимум на порядок медленее чем из мемору (кеша).
Будет ли это "мало времени" или "много времени" --
зависит от обшего времени выполнения запроса...
...
Рейтинг: 0 / 0
14.10.2015, 23:26:10
| Ответить | Цитировать | Написать  
12 сообщений из 12, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Тепловые потери в коробке передач
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=47&msg=39076518&tid=1832613]:
 0ms
get settings:
 6ms
get forum list:
 10ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 40ms
get topic data:
 7ms
get forum data:
 1ms
get page messages:
 31ms
get tp. blocked users:
 1ms
others: 202ms
total:  302ms
созд. / загр.: 302ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]