Просмотр сообщений
1
Базы данных / Отсортированная таблица
« : 07 Октября 2004, 21:31:55 »
myisamchk -R {# index} {tablename}
Сортирит данные в таблице по указанному ключу :-)
Сортирит данные в таблице по указанному ключу :-)
Новости:
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
2
Базы данных / Отсортированная таблица
« : 07 Октября 2004, 20:31:05 »
Господа решение найдено...
Возможность сортировать данные в таблице по определённому полю ЕСТЬ...
Теперь таблица хранится в отсортированном виде по полю rating.
:-)
Спасибо всем, кто конструктивно пытался помочь...
Теперь требуемый запрос выполняется на более чем полумилионных массивах данных из максимальных 5 таблиц без единой инструкции типа ORDER сортируется и выводится на экран пользователю и всё это менее чем за 100 миллисекунд...
Forza, учите теорию БД :-) Таблица - далеко не бессмысленный набор строк, который упорядочивают столь "быстрые" инструкции как ORDER :-)))
Возможность сортировать данные в таблице по определённому полю ЕСТЬ...
Теперь таблица хранится в отсортированном виде по полю rating.
:-)
Спасибо всем, кто конструктивно пытался помочь...
Теперь требуемый запрос выполняется на более чем полумилионных массивах данных из максимальных 5 таблиц без единой инструкции типа ORDER сортируется и выводится на экран пользователю и всё это менее чем за 100 миллисекунд...
Forza, учите теорию БД :-) Таблица - далеко не бессмысленный набор строк, который упорядочивают столь "быстрые" инструкции как ORDER :-)))
3
Базы данных / Отсортированная таблица
« : 07 Октября 2004, 18:31:52 »
Хм, ок:
Существует некоторое количество таблиц такого типа.
Интерфейс пользователя определяет в зависимости от его запроса - какие из них надо склеивать...
Заранее определять - какие из них самые рейтинговые - не имеет смысла, поскольку при склейке - важна уже сумма рейтингов, а не рейтинг каждой отдельной таблицы!
Существует некоторое количество таблиц такого типа.
Интерфейс пользователя определяет в зависимости от его запроса - какие из них надо склеивать...
Заранее определять - какие из них самые рейтинговые - не имеет смысла, поскольку при склейке - важна уже сумма рейтингов, а не рейтинг каждой отдельной таблицы!
4
Базы данных / Отсортированная таблица
« : 07 Октября 2004, 18:12:47 »
Хм, ок:
Существует некоторое количество таблиц такого типа.
Интерфейс пользователя определяет в зависимости от его запроса - какие из них надо склеивать...
Заранее определять - какие из них самые рейтинговые - не имеет смысла, поскольку при склейке - важна уже сумма рейтингов, а не рейтинг каждой отдельной таблицы!
Существует некоторое количество таблиц такого типа.
Интерфейс пользователя определяет в зависимости от его запроса - какие из них надо склеивать...
Заранее определять - какие из них самые рейтинговые - не имеет смысла, поскольку при склейке - важна уже сумма рейтингов, а не рейтинг каждой отдельной таблицы!
5
Базы данных / Отсортированная таблица
« : 07 Октября 2004, 17:03:38 »
Хм, само суммирование занимает очень малое количество времени, как показали различные модификации запроса...
Но дело в том, что таких даблиц склеивается от 2 до 5 штук и таких таблиц много и какие конкретно из них будут склеены - заранее неизвестно.
Поэтому хранить где-либо сумму рейтингов для каждых сочетаний не представляется возможным...
Если таблицы будут отсортированы заранее, то их можно и программно склеить, это быстро...
Не в склейке дело!
Дело в медленной инструкции order by
Но дело в том, что таких даблиц склеивается от 2 до 5 штук и таких таблиц много и какие конкретно из них будут склеены - заранее неизвестно.
Поэтому хранить где-либо сумму рейтингов для каждых сочетаний не представляется возможным...
Если таблицы будут отсортированы заранее, то их можно и программно склеить, это быстро...
Не в склейке дело!
Дело в медленной инструкции order by
6
Базы данных / Отсортированная таблица
« : 07 Октября 2004, 12:49:05 »
Мы обсуждали подобную, но важно ли это...
Вопрос стоит так или иначе:
Есть ли такая возвожность?
Или нет?
И есть ли какие-либо предложения, способные хотя-бы навести на мысль к решению данной проблемы?
Вопрос стоит так или иначе:
Есть ли такая возвожность?
Или нет?
И есть ли какие-либо предложения, способные хотя-бы навести на мысль к решению данной проблемы?
7
Базы данных / Отсортированная таблица
« : 07 Октября 2004, 12:30:54 »
Ok, существует несколько таблиц типа:
id | rating
В каждой из них может быть до полумиллиона записей...
На id повешен индекс
Запрос на выборку - склеивающий и выглядит следующим образом:
select test.a.id,(test.a.rating+test.b.rating+
test.c.rating+test.d.rating+test.e.rating)
from test.a,test.b,test.c,test.d,test.e where
test.a.id=test.b.id and test.a.id=test.c.id
and test.a.id=test.d.id and test.a.id=test.e.id limit 1000
Таким образом, у нас склеиваются до 5 таблиц по ID с тем, чтобы получить 1000 тех ID, которые обладают наивысшим рейтингом и содержатся в каждой из таблиц
В данном запросе нет директив типа order, дающих возможность получить ID с НАИВЫСШИМ рейтингом, но если бы таблицы были отсортированы изначально - этот запрос давал бы желаемый результат.
Применение инструкции order by rating, даже с повешенным индексом на поле rating замедляет операцию простой выборки из одной из таблиц, уж не говоря о запросе такого типа, ведь от-ордерить надо будет все 5 таблиц...
А вот полное сканирование дало бы сразу быстро желаемый результат, если бы таблицы были сразу отсортированы по полю rating
id | rating
В каждой из них может быть до полумиллиона записей...
На id повешен индекс
Запрос на выборку - склеивающий и выглядит следующим образом:
select test.a.id,(test.a.rating+test.b.rating+
test.c.rating+test.d.rating+test.e.rating)
from test.a,test.b,test.c,test.d,test.e where
test.a.id=test.b.id and test.a.id=test.c.id
and test.a.id=test.d.id and test.a.id=test.e.id limit 1000
Таким образом, у нас склеиваются до 5 таблиц по ID с тем, чтобы получить 1000 тех ID, которые обладают наивысшим рейтингом и содержатся в каждой из таблиц
В данном запросе нет директив типа order, дающих возможность получить ID с НАИВЫСШИМ рейтингом, но если бы таблицы были отсортированы изначально - этот запрос давал бы желаемый результат.
Применение инструкции order by rating, даже с повешенным индексом на поле rating замедляет операцию простой выборки из одной из таблиц, уж не говоря о запросе такого типа, ведь от-ордерить надо будет все 5 таблиц...
А вот полное сканирование дало бы сразу быстро желаемый результат, если бы таблицы были сразу отсортированы по полю rating
8
Базы данных / Отсортированная таблица
« : 06 Октября 2004, 17:35:36 »
Даже используя индексы, получаются тормозявки в районе секунды 
Важна как можно более быстрая выборка, насколько тяжёл будет инсерт - в общем-то похрен...
Важна как можно более быстрая выборка, насколько тяжёл будет инсерт - в общем-то похрен...
9
Базы данных / Отсортированная таблица
« : 06 Октября 2004, 15:47:39 »
Дело в том, что при размере таблицы в 500000 записей order происходит несколько секунд, а для выдачи результат в клиентском приложении таких операций выполняется несколько.
Explain подобного запроса выдаёт Using Index, Using Filesort...
То есть получается, что при любом запросе на выборку такая таблица должна быть изначально отсортированной по полю rating
Explain подобного запроса выдаёт Using Index, Using Filesort...
То есть получается, что при любом запросе на выборку такая таблица должна быть изначально отсортированной по полю rating
10
Базы данных / Отсортированная таблица
« : 06 Октября 2004, 14:19:24 »
Есть ли возможность создать в MySQL изначально отсортированную таблицу по одному из полей..
Предположим, у нас есть два интовых поля...
id | rating
И при выборке следующим запросом :
select * from table limit 1;
результатом была бы запись с наибольшм рейтингом, то есть таблица должна сортироваться сразу при вставке...
Я понимаю, что инсерт в эту таблицу будет тяжёловатым, при большом количестве записей, но идея в том, чтобы не использовать в запросе на выборку директив типа order
Предположим, у нас есть два интовых поля...
id | rating
И при выборке следующим запросом :
select * from table limit 1;
результатом была бы запись с наибольшм рейтингом, то есть таблица должна сортироваться сразу при вставке...
Я понимаю, что инсерт в эту таблицу будет тяжёловатым, при большом количестве записей, но идея в том, чтобы не использовать в запросе на выборку директив типа order
11
Базы данных / Поиск в базе и результаты поиска
« : 28 Сентября 2004, 15:38:56 »
Совет: Храни всё в таблице в одной кодировке, например, в UTF-8...
То есть принимая данные для вноса, конвертируй их из той кодировки, в которой они находятся - в одну...
А потом, выполняя поисковый запрос - конвертируй поисковый термин в ту, в которой хранишь...
Почему советую UTF-8 - ей похрену на язык написания... всегда два байта на 1 символ...
Некоторая избыточность, зато полная уверенность в работоспособности...
То есть принимая данные для вноса, конвертируй их из той кодировки, в которой они находятся - в одну...
А потом, выполняя поисковый запрос - конвертируй поисковый термин в ту, в которой хранишь...
Почему советую UTF-8 - ей похрену на язык написания... всегда два байта на 1 символ...
Некоторая избыточность, зато полная уверенность в работоспособности...
12
Базы данных / Немеряная склейка...
« : 17 Сентября 2004, 16:43:15 »
Приложение на PHP.
Сорри, сразу не сказали - ведь это MySQL, а в ней слово key - это же индекс...
Ключей как таковых в этой таблице вообще нет...
Это само собой - но БД быстрее обработает 25000 чем приложение, на считывание 25000 результатов в PHP уйдет пара секунд минимум.
Цитировать
commander:
1.Ставить на varchar ключь это не правильно! (нарушение второй нормальной формы).
Сорри, сразу не сказали - ведь это MySQL, а в ней слово key - это же индекс...
Ключей как таковых в этой таблице вообще нет...
Цитировать
commander:
2.то что ты считываешь в приложение только 1500 строк не говорит о том что БД не обрабатывает 25000.
Это само собой - но БД быстрее обработает 25000 чем приложение, на считывание 25000 результатов в PHP уйдет пара секунд минимум.
13
Базы данных / Немеряная склейка...
« : 17 Сентября 2004, 15:58:17 »
Выборка ведь идет по полю word (это главный критерий поиска).
Почему ты считаешь что это неправильно?
Насчёт убрать order и sum - из полученных результатов - мы считываем в приложение только 1500 лучших результатов по рейтингу...
А сортиря это в приложении - нам придётся считать все 25000.
Почему ты считаешь что это неправильно?
Насчёт убрать order и sum - из полученных результатов - мы считываем в приложение только 1500 лучших результатов по рейтингу...
А сортиря это в приложении - нам придётся считать все 25000.
15
Базы данных / Немеряная склейка...
« : 16 Сентября 2004, 20:11:10 »
Народ, посоветуйте, как оптимальным образом добиться быстродействия следующего запроса:
Существуют 5 таблиц абсолютно одинаковой структуры:
word varchar(255) - key
id int(11) - key
rating int(11)
Как видите, индексы повешены на два поля - по которым проходится where...
Необходимо получить список тех id из всех 5 таблиц, которые соответствуют каждому из 5 слов
В каких таблицах содержатся искомые слова - известно заранее - это видно из запроса ниже...
В таблицах - в среднем более 50000 записей в каждой из них.
Выполняется следующий запрос:
select srch.53000.id,(srch.53000.rating+srch.52000.rating+srch.51000.rating+srch.50000.rating+srch.49000.rating) from srch.53000,srch.50000,srch.51000,srch.52000,srch.49000 where (srch.53000.word=\'5\' and srch.50000.word=\'2\' and srch.51000.word=\'3\' and srch.52000.word=\'4\' and srch.49000.word=\'1\') and (srch.53000.id=srch.50000.id and srch.53000.id=srch.51000.id and srch.53000.id=srch.52000.id and srch.53000.id=srch.49000.id and srch.50000.id=srch.51000.id and srch.50000.id=srch.52000.id and srch.50000.id=srch.49000.id and srch.51000.id=srch.52000.id and srch.51000.id=srch.49000.id and srch.52000.id=srch.49000.id) order by (srch.53000.rating+srch.52000.rating+srch.51000.rating+srch.50000.rating+srch.49000.rating) desc limit 1500
Результатом без лимита является 25000 рядов.
Быстродействие именно этого запроса - ажных 8 секунд, что абсолютно недопустимо...
EXPLAIN выдаёт минимум операций равный 26000 то есть выходит, что при таком подходе - быстрее уже некуда...
Может есть другой способ получить сей результат быстрее?
Существуют 5 таблиц абсолютно одинаковой структуры:
word varchar(255) - key
id int(11) - key
rating int(11)
Как видите, индексы повешены на два поля - по которым проходится where...
Необходимо получить список тех id из всех 5 таблиц, которые соответствуют каждому из 5 слов
В каких таблицах содержатся искомые слова - известно заранее - это видно из запроса ниже...
В таблицах - в среднем более 50000 записей в каждой из них.
Выполняется следующий запрос:
select srch.53000.id,(srch.53000.rating+srch.52000.rating+srch.51000.rating+srch.50000.rating+srch.49000.rating) from srch.53000,srch.50000,srch.51000,srch.52000,srch.49000 where (srch.53000.word=\'5\' and srch.50000.word=\'2\' and srch.51000.word=\'3\' and srch.52000.word=\'4\' and srch.49000.word=\'1\') and (srch.53000.id=srch.50000.id and srch.53000.id=srch.51000.id and srch.53000.id=srch.52000.id and srch.53000.id=srch.49000.id and srch.50000.id=srch.51000.id and srch.50000.id=srch.52000.id and srch.50000.id=srch.49000.id and srch.51000.id=srch.52000.id and srch.51000.id=srch.49000.id and srch.52000.id=srch.49000.id) order by (srch.53000.rating+srch.52000.rating+srch.51000.rating+srch.50000.rating+srch.49000.rating) desc limit 1500
Результатом без лимита является 25000 рядов.
Быстродействие именно этого запроса - ажных 8 секунд, что абсолютно недопустимо...
EXPLAIN выдаёт минимум операций равный 26000 то есть выходит, что при таком подходе - быстрее уже некуда...
Может есть другой способ получить сей результат быстрее?