Очень долго выполняется запрос

@WirusaNet · Регистрация: 26.11.2013

Студворк — интернет-сервис помощи студентам

Запрос выполняется минут десять. Разве так должно быть?

Обрисовываю ситуацию. Берутся две главные таблицы и одна связующая со связями многие ко многим. Главные таблицы состоят из двух колонок. Одна - ключ, а вторая - текст. Первая таблица 2000 строк. Вторая - 10000 строк. Связующая таблица состоит из ключей первой и второй. Но она гигантская по размерам - 500'000 строк. Сама задача проста. Связать первую и вторую таблицы если из первой таблицы запросу соответствуют 1000 строк, а из второй 5000 строк.

Последовательность примерно такая. Сначала запрос к каждой строке первой таблицы. Это 2000 операций. Из них останутся 1000 строк. Затем самое страшное. 1000 строк полученных сравниваются с 500'000 строк связующей таблицы. Это значит 1000 х 500'000 = 500'000'000 операций. В итоге останется 5000 строк в промежуточной таблице. Дальше попроще, выбираем из второй таблицы по полученному ключу. Это еще 5000 х 10'000 = 50'000'000 операций. В итоге сумма канечно устрашающая 550'002'000. Это только операции сравнения. Операций считывания посчитать проще. Разом все 2000 строк из первой, разом все 500'000 строк из связующей и разом все 10'000 строк из второй. Причем разом они должны намного быстрее делаться, чем по отдельности.

Вопрос знатокам, а сколько у вас ориентировочно будет выполняться такой запрос? И еще какие есть способы ускорить процесс не изменяя базы данных?

arni · 26.11.2013, 19:52

Firebird 2.5.
Таблица 1: ~6 тыс. записей
Таблица 2: ~13 тыс. записей
Таблица 3 (многие-ко-многим, но не просто соответствие, но и ~30 полей дополнительно): ~2.2 млн. записей

SQL
1
2
3
4
SELECT COUNT(*)
  FROM t1
  JOIN t3 ON t3.FK_ID=t1.ID
  JOIN t2 ON t3.FK_ID=t2.ID

19 сек.

если сделать не count(*), а выдать одно числовое поле (т.е. фетч 2+ млн.записей в грид), то уже 30 сек.

@WirusaNet · 27.11.2013, 00:59 **[ТС]**

Да это быстро. Спасибо. У меня база данных SQLite, может все из за нее. Хотя для работы программы 30 сек ожидания это тоже долго.

Для своей базы я придумал алгоритм как соединять эти таблицы, но я его программой реализовал. Долго бился над ним. Вот как бы заставить саму СУБД пользоваться моим алгоритмом. То есть мне нужно записать функцию в базу данных и что бы она вместо JOIN выполняла эту функцию. Это возможно?

arni · 27.11.2013, 08:28

Вы не приводите своих метрик.
Не понятно, построены ли у вас индексы по столбцам соединения.
Совершенно не понятно, кому нужны резалтсеты-миллионики. Если это грид, то считается плохо, если количество строк более сотни. Если это отчет, то речь может идти об тысячи записей. Но миллионами никто не ворочает на выходе - человек не может оперировать такими выборками. Т.е. нужно строить такие запросы, которые ужимают выборку до приемленых размеров (десятки, сотни, редко - тысяча строк). Соединение и фильрация по столбцам, покрытым индексами, должны выполняться буквально неск. сек., даже на таблицах миллиониках. Правда с SQLite я не работал, но в целом уважаемая компактная СУБД - врятли она ущербна. Скорее проблемы на стороне программиста/проектировщика.

@cygapb-007 · 27.11.2013, 12:28

Сообщение от WirusaNet

Запрос выполняется минут десять. Разве так должно быть?

Последовательность примерно такая. Сначала запрос к каждой строке первой таблицы. Это 2000 операций. Из них останутся 1000 строк. Затем самое страшное. 1000 строк полученных сравниваются с 500'000 строк связующей таблицы. Это значит 1000 х 500'000 = 500'000'000 операций. В итоге останется 5000 строк в промежуточной таблице. Дальше попроще, выбираем из второй таблицы по полученному ключу. Это еще 5000 х 10'000 = 50'000'000 операций. В итоге сумма канечно устрашающая 550'002'000. Это только операции сравнения. Операций считывания посчитать проще. Разом все 2000 строк из первой, разом все 500'000 строк из связующей и разом все 10'000 строк из второй. Причем разом они должны намного быстрее делаться, чем по отдельности.

WirusaNet, правильно ли я вас понял?

Вы считываете в клиенте всё содержимое трех таблиц в память, а потом в клиенте же начинаете искать нужные вам строки по всем таблицам?
После того, как программа в клиенте отлажена, вы хотите, чтобы сервер выполнял не какие-то свои запросы, а конкретно ваш отлаженный алгоритм

Так?

@WirusaNet · 28.11.2013, 12:40 **[ТС]**

Да. именно так. Таблицы загружаю из базы данных, а нужный результат получаю программой. Удобнее было бы, если заставить базу данных выполнять мой алгоритм.

А на счет вопроса - построены ли у вас индексы по столбцам соединения. Я сам ничего специально не делал. Создал две таблицы с данными и связующую. Про индексы даже не слышал ничего. Ключем сделал обычные числовые данные типа Integer.

@Grossmeister · 28.11.2013, 12:50

Сообщение от WirusaNet

Про индексы даже не слышал ничего

То есть ты работаешь с БД, даже ничего не прочитав (хотя бы общие вещи) по теории реляционных БД???

@cygapb-007 · 28.11.2013, 13:15

Сообщение от WirusaNet

Да. именно так. Таблицы загружаю из базы данных, а нужный результат получаю программой.

В таком случае вы обречены на мучительно долгое и непродуктивное императивное программирование баз данных: затраты по извлечению и передаче к клиенту гигантского объема не нужных данных, ковыряние в этих данных по жестко заданному (и не факт, что оптимальному) вашему сценарию обработки, очистка (если производится вашим клиентом) мусора, не удовлетворяющего требованиям к данным

Фактически, вы мучительно долго делаете на клиенте то, что умеет оптимально быстро делать сервер

ЗАЧЕМ?

Почитайте про декларативное программирование, забудьте про обработку массивов при работе с SQL (sic! в SQL НЕТ МАССИВОВ!!!), поищите информацию об оптимизации SQL-запросов - и ваши данные будут извлекаться практически моментально.

Удобнее было бы, если заставить базу данных выполнять мой алгоритм.

Согласен, если под своим алгоритмом вы понимаете правильно составленный SQL-запрос, а не программу на императивном языке программирования.

А на счет вопроса - построены ли у вас индексы по столбцам соединения. Я сам ничего специально не делал. Создал две таблицы с данными и связующую. Про индексы даже не слышал ничего. Ключем сделал обычные числовые данные типа Integer.

Наиболее часто (но не всегда) для оптимизации выполнения запроса достаточно построить правильные индексы в таблицах.

@WirusaNet · 28.11.2013, 13:21 **[ТС]**

Совсем не так. Я вообще то базы и не пишу. И очень много чего то не прочитал. Вот и индексы не читал. Но про связующую таблицу читал. Но связующие таблицы и есть теория реляционных БД. Объект должен быть один и не повторяться, а для звязей создаем спец таблицы. А индексы это уже дополнительные инструменты. Если у меня не возможно задать индексы, то что, виновата теория? Изначально я и спрашивал про дополнительные механизмы для ускорения процесса. Полагаю теперь нужно зяняться индексами. Но очень интересует вопрос, как заставить базу данных мой алгоритм делать?

@cygapb-007 · 28.11.2013, 13:32

Сообщение от WirusaNet

Но очень интересует вопрос, как заставить базу данных мой алгоритм делать?

1. Согласиться с тем, что любой SQL-сервер разрабатывался с целью максимально быстрого извлечения требуемых данных, и не задавать подобных вопросов.

2. Разобраться, что требуется сделать в вашей конкретной базе данных для того, чтобы сервер выполнял свою работу по извлечению данных максимально эффективно

@WirusaNet · 28.11.2013, 13:40 **[ТС]**

Сообщение от cygapb-007

В таком случае вы обречены на мучительно долгое и непродуктивное императивное программирование баз данных: затраты по извлечению и передаче к клиенту гигантского объема не нужных данных, ковыряние в этих данных по жестко заданному (и не факт, что оптимальному) вашему сценарию обработки, очистка (если производится вашим клиентом) мусора, не удовлетворяющего требованиям к данным

Я этого и хочу избежать. И тогда все будет без мусора, ковыряния и всего другого. Да и запрос тут элементарный, его никак не оптимизируешь. Он такой же как во втором посте.

Меня сам алгоритм заинтересовал. Ведь база данных выполняет свой алгоритм. Как я могу повлиять на него? Здесь тока про индексы весь разговор. Это я понял, буду думать. Но вот мне хотелось бы и свой алгоритм прямо в базе делать. И он не запрос, а именно алгоритм, который нужно будет записать на языке базы данных.

@cygapb-007 · 28.11.2013, 13:45

Сообщение от WirusaNet

Но вот мне хотелось бы и свой алгоритм прямо в базе делать. И он не запрос, а именно алгоритм, который нужно будет записать на языке базы данных.

В любом SQL закрыт непосредственный доступ к хранимым данным. В вашем распоряжении только SQL-запросы.

@Grossmeister · 28.11.2013, 13:47

Сообщение от WirusaNet

Но вот мне хотелось бы и свой алгоритм прямо в базе делать

Это все равно, что купить машину (пусть Ford), выкинуть двигатель и сделать свой. Можно ли после этого назвать такое авто Ford-ом?
Алгоритмы, применяемые в СУБД, являются таким мотором. Маловероятно, что ты придумаешь алгоритм, который переплюнет многолетний труд создателей СУБД. Но в любом случае ни один создатель СУБД таких возможностей по замене их собственных алгоритмов не предоставляет

@WirusaNet · 28.11.2013, 13:52 **[ТС]**

Сообщение от cygapb-007

Согласиться с тем, что любой SQL-сервер разрабатывался с целью максимально быстрого извлечения требуемых данных, и не задавать подобных вопросов.

Я бы посоветовал не отвечать на вопрос если он не нравится. Так будет правильней, чем советовать не задавать вопросов. И что значит согласиться с тем. Я бы и хотел взглянуть на этот алгоритм. Да и суть опять не в этом. Для разных ситуаций разный алгоритм. Этот хорош в этом месте, а другой в другом. Если это не возможно реализовать, это не значит что вопросы не нужно задавать. Нужно так и ответить, мол нельзя и все.

Добавлено через 1 минуту

Сообщение от Grossmeister

Это все равно, что купить машину (пусть Ford), выкинуть двигатель и сделать свой. Можно ли после этого назвать такое авто Ford-ом?
Алгоритмы, применяемые в СУБД, являются таким мотором. Маловероятно, что ты придумаешь алгоритм, который переплюнет многолетний труд создателей СУБД. Но в любом случае ни один создатель СУБД таких возможностей по замене их собственных алгоритмов не предоставляет

Так многие фирмы делают с машинами. А с фордом так и нужно делать. И что значит мало вероятно. Это нужно тока сравнивать.

@cygapb-007 · 28.11.2013, 13:59

Сообщение от WirusaNet

Я бы и хотел взглянуть на этот алгоритм.

Ну так и взгляние, кто мешает-то?

Называется - план выполнения запроса

Если бы не поленились поискать темы про оптимизацию - обязательно бы наткнулись на его упоминание.

Но нет, нравится вам головой об стенку... Что ж, продолжайте...

@WirusaNet · 28.11.2013, 14:06 **[ТС]**

Сообщение от cygapb-007

Ну так и взгляние, кто мешает-то?
Называется - план выполнения запроса

Посмотрю.

@Grossmeister · 28.11.2013, 14:21

Сообщение от WirusaNet

Это нужно тока сравнивать

ОК.
А почему бы не распространить этот принцип на любые готовые программы? Производитель предоставляет всем желающим исходники, любой желающий составляет свои алгоритмы вместо имеющихся и сранивает. Вот только есть подозрение, что после этого все будут заниматься только этим и никаких других программ писать уже не будут (просто не хватит времени). А техподдержка производителей будет завалена кучей претензий, почему та или иная программа плохо работает (а ведь не сразу разберешь, используется ли исходный движок или он уже сильно модифицирован).
А если распространить этот принцип не только на программы, но и на остальные товары, то...

@WirusaNet · 28.11.2013, 14:51 **[ТС]**

Может мои ответы немного неприятные, но я никого не пытаюсь задеть. Стараюсь по крайне мере. Но здесь вот проще простого. Этот алгоритм я буду использовать только сам и только для этого запроса. Всё остальное остается как было. А их алгоритм мне бы было даже интересно посмотреть и сравнить со своим. Если разберусь во всех дебрях, то посмотрю. И ещё добавлю. Я и не обвиняю БД. Мне сначала нужно понять, почему БД выполняет не оптимальный алгоритм? Может ли она вообще выполнить более оптимальный алгоритм? И что нужно сделать для того? Может быть окажется, что БД может выполнять и мой алгоритм.

@cygapb-007 · 28.11.2013, 15:02

Сообщение от WirusaNet

Мне сначала нужно понять, почему БД выполняет не оптимальный алгоритм?

Покажите уже наконец-то план выполнения запроса

@WirusaNet · 28.11.2013, 15:08 **[ТС]**

Ну я простой любитель, а не профи. Если за год разберусь, что это такое, то покажу. Но боюсь что и за год не уложусь.

Новые блоги и статьи Все статьи Все блоги /
Квантовые алгоритмы и обработка строк в Q# EggHead 07.06.2025 Квантовые вычисления перевернули наше представление о том, как работать с данными, а Q# стал одним из ключевых языков для разработки квантовых алгоритмов. В традиционых системах мы оперируем битами —. . .	NUnit и C# UnmanagedCoder 07.06.2025 В . NET существует несколько фреймворков для тестирования: MSTest (встроенный в Visual Studio), xUnit. net (более новый фреймворк) и, собственно, NUnit. Каждый имеет свои преимущества, но NUnit. . .	с++ Что нового? russiannick 06.06.2025 Продолжаю обзор dev-cpp5. 11. Посмотрев на проекты, предоставленные нам для обучения, становится видно, что они разные по содержащимся файлам где: . dev обязательно присутствует . cpp/ . c один из них. . .	WebAssembly в Kubernetes Mr. Docker 06.06.2025 WebAssembly изначально разрабатывался как бинарный формат инструкций для виртуальной машины, обеспечивающий высокую производительность в браузерах. Но потенциал технологии оказался гораздо шире - она. . .	Как создать первый микросервис на C# с ASP.NET Core, step by step stackOverflow 06.06.2025 Если говорить простыми словами, микросервисная архитектура — это подход к разработке, при котором приложение строится как набор небольших, слабо связанных сервисов, каждый из которых отвечает за. . .
Рисование коллайдеров Box2D v2 на Three.js с помощью порта @box2d/core 8Observer8 06.06.2025 Используется порт Box2D v2 под названием @box2d/ core - пакет NPM. Загрузил документацию Box2D v2 на Netlify: https:/ / box2d-v2-docs. netlify. app/ Документацию Box2D v2 можно скачать с официального. . .	Как создать стек в Python AI_Generated 05.06.2025 Как архитектор с более чем десятилетним опытом работы с Python, я неоднократно убеждался, что знание низкоуровневых механизмов работы стеков дает конкурентное преимущество при решении сложных задач. . . .	Server-Sent Events (SSE) в Node.js run.dev 05.06.2025 Потоковая передача данных с сервера прямо в браузер стала повседневной потребностью - от биржевых графиков и спортивных трансляций до чатов и умных дашбордов. Много лет разработчики полагались на. . .	Создаем RESTful API на Golang с Fiber golander 04.06.2025 Я перепробовал десятки фреймворков для создания RESTful API за последние годы, и когда впервые столкнулся с Fiber, понял, что это совсем другой уровень. Нет, я не собираюсь рассказывать сказки о. . .	Как работать с куки в ASP.NET Core UnmanagedCoder 04.06.2025 Когда я впервые начал работать с куки в ASP. NET Core, меня поразило, насколько отличается работа с ними от классического ASP. NET. В Core все стало более декомпозированным - больше нет удобного. . .

@WirusaNet 0 / 0 / 0 Регистрация: 26.11.2013 Сообщений: 11

	Очень долго выполняется запрос 26.11.2013, 18:41. Показов 9523. Ответов 26 Метки нет (Все метки) Запрос выполняется минут десять. Разве так должно быть? Обрисовываю ситуацию. Берутся две главные таблицы и одна связующая со связями многие ко многим. Главные таблицы состоят из двух колонок. Одна - ключ, а вторая - текст. Первая таблица 2000 строк. Вторая - 10000 строк. Связующая таблица состоит из ключей первой и второй. Но она гигантская по размерам - 500'000 строк. Сама задача проста. Связать первую и вторую таблицы если из первой таблицы запросу соответствуют 1000 строк, а из второй 5000 строк. Последовательность примерно такая. Сначала запрос к каждой строке первой таблицы. Это 2000 операций. Из них останутся 1000 строк. Затем самое страшное. 1000 строк полученных сравниваются с 500'000 строк связующей таблицы. Это значит 1000 х 500'000 = 500'000'000 операций. В итоге останется 5000 строк в промежуточной таблице. Дальше попроще, выбираем из второй таблицы по полученному ключу. Это еще 5000 х 10'000 = 50'000'000 операций. В итоге сумма канечно устрашающая 550'002'000. Это только операции сравнения. Операций считывания посчитать проще. Разом все 2000 строк из первой, разом все 500'000 строк из связующей и разом все 10'000 строк из второй. Причем разом они должны намного быстрее делаться, чем по отдельности. Вопрос знатокам, а сколько у вас ориентировочно будет выполняться такой запрос? И еще какие есть способы ускорить процесс не изменяя базы данных? 0

@WirusaNet 0 / 0 / 0 Регистрация: 26.11.2013 Сообщений: 11
	27.11.2013, 00:59 [ТС]
	Да это быстро. Спасибо. У меня база данных SQLite, может все из за нее. Хотя для работы программы 30 сек ожидания это тоже долго. Для своей базы я придумал алгоритм как соединять эти таблицы, но я его программой реализовал. Долго бился над ним. Вот как бы заставить саму СУБД пользоваться моим алгоритмом. То есть мне нужно записать функцию в базу данных и что бы она вместо JOIN выполняла эту функцию. Это возможно? 0

arni 913 / 878 / 62 Регистрация: 06.01.2010 Сообщений: 2,367 Записей в блоге: 6
	27.11.2013, 08:28
	Вы не приводите своих метрик. Не понятно, построены ли у вас индексы по столбцам соединения. Совершенно не понятно, кому нужны резалтсеты-миллионики. Если это грид, то считается плохо, если количество строк более сотни. Если это отчет, то речь может идти об тысячи записей. Но миллионами никто не ворочает на выходе - человек не может оперировать такими выборками. Т.е. нужно строить такие запросы, которые ужимают выборку до приемленых размеров (десятки, сотни, редко - тысяча строк). Соединение и фильрация по столбцам, покрытым индексами, должны выполняться буквально неск. сек., даже на таблицах миллиониках. Правда с SQLite я не работал, но в целом уважаемая компактная СУБД - врятли она ущербна. Скорее проблемы на стороне программиста/проектировщика. 0

@WirusaNet 0 / 0 / 0 Регистрация: 26.11.2013 Сообщений: 11
	28.11.2013, 12:40 [ТС]
	Да. именно так. Таблицы загружаю из базы данных, а нужный результат получаю программой. Удобнее было бы, если заставить базу данных выполнять мой алгоритм. А на счет вопроса - построены ли у вас индексы по столбцам соединения. Я сам ничего специально не делал. Создал две таблицы с данными и связующую. Про индексы даже не слышал ничего. Ключем сделал обычные числовые данные типа Integer. 0

@WirusaNet 0 / 0 / 0 Регистрация: 26.11.2013 Сообщений: 11
	28.11.2013, 13:21 [ТС]
	Совсем не так. Я вообще то базы и не пишу. И очень много чего то не прочитал. Вот и индексы не читал. Но про связующую таблицу читал. Но связующие таблицы и есть теория реляционных БД. Объект должен быть один и не повторяться, а для звязей создаем спец таблицы. А индексы это уже дополнительные инструменты. Если у меня не возможно задать индексы, то что, виновата теория? Изначально я и спрашивал про дополнительные механизмы для ускорения процесса. Полагаю теперь нужно зяняться индексами. Но очень интересует вопрос, как заставить базу данных мой алгоритм делать? 0

@WirusaNet 0 / 0 / 0 Регистрация: 26.11.2013 Сообщений: 11
	28.11.2013, 14:51 [ТС]
	Может мои ответы немного неприятные, но я никого не пытаюсь задеть. Стараюсь по крайне мере. Но здесь вот проще простого. Этот алгоритм я буду использовать только сам и только для этого запроса. Всё остальное остается как было. А их алгоритм мне бы было даже интересно посмотреть и сравнить со своим. Если разберусь во всех дебрях, то посмотрю. И ещё добавлю. Я и не обвиняю БД. Мне сначала нужно понять, почему БД выполняет не оптимальный алгоритм? Может ли она вообще выполнить более оптимальный алгоритм? И что нужно сделать для того? Может быть окажется, что БД может выполнять и мой алгоритм. 0

@WirusaNet 0 / 0 / 0 Регистрация: 26.11.2013 Сообщений: 11
	28.11.2013, 15:08 [ТС]
	Ну я простой любитель, а не профи. Если за год разберусь, что это такое, то покажу. Но боюсь что и за год не уложусь. 0