Максимально оптимизировать вывод MySQL
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
Максимально оптимизировать вывод MySQL - 2011-02-12 16:43:01.650000
|
|
|
FriLL
Сообщений: 2539
Оценки: 335
Присоединился: 2007-08-11 17:14:26.703333
|
Какими способами можно добиться чтобы когда проект станет высоконагруженным
вывод из БД осуществлялся без всяких тупняков
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-12 17:53:56.166666
|
|
|
slipslop
Сообщений: 115
Оценки: 0
Присоединился: 2010-12-27 20:21:35.253333
|
Оптимизировать базу и запросы?
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-12 17:59:25.243333
|
|
|
Sрam
Сообщений: 2863
Оценки: 372
Присоединился: 2009-01-16 15:23:43.276666
|
Уменьшаешь кол-во обращений к мускулу…
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-12 18:20:26.993333
|
|
|
FriLL
Сообщений: 2539
Оценки: 335
Присоединился: 2007-08-11 17:14:26.703333
|
quote:
ORIGINAL: Sрam
Уменьшаешь кол-во обращений к мускулу…
Каким образом
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-12 18:40:30.980000
|
|
|
slipslop
Сообщений: 115
Оценки: 0
Присоединился: 2010-12-27 20:21:35.253333
|
quote:
ORIGINAL: FriLL
Каким образом
Ты понимаешь, что сейчас просишь показать тебе кнопку "сделать зашибись"?)
Нет универсального способа, всё зависит от ситуации. Где-то нужны одни техники, где-то другие. Где-то поможет кеширование результатов в программе и уменьшение обращений к БД, где-то prepared statements, где-то просто реструктуризация базы. Если количество обращений действительно очень сильно возрастает, то, возможно, имеет смысл вообще уйти от MySQL, перейти на какой-нибудь Oracle. А может для твоего приложения вообще не реляционная, а какая-нибудь распределённая документная БД лучше всего подходит, кто ж знает. Пока что речь идёт про оптимизацию сферического коня в вакууме.
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-12 18:42:01.490000
|
|
|
Agent Smith
Сообщений: 976
Оценки: 0
Присоединился: 2007-04-10 21:56:49.593333
|
Для этого нужны прямые руки. До того, как проект станет "высоконагруженным", нужно где-то скачать учебник по MySQL (либо другой БД, которую вы собираетесь использовать) и изучить его от начала до конца. Вот тогда вы сможете осуществить "вывод из БД без всяких тупняков".
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-12 21:12:48.760000
|
|
|
DEH
Сообщений: 195
Оценки: 0
Присоединился: 2007-01-13 22:27:31.370000
|
1. Меньше запросов.
2. Больше оптимальных запросов среди оставшихся.
3. Меньше джоинов.
4. Хранимки.
5. Еще куча всяких аспектов…
А зачем Вам вообще это нужно? Сначала сделайте высоконагруженный проект… Как-то так. Без обид.
P.S. Кто-то (программист/автор/профессор/кто-то другой, кто понимает в этом деле) говорил "Преждевременная оптимизация - оптимизация ради оптимизации". Цитата неточная, но суть ясна.
P.P.S. Простите за снобство, я просто буквально недавно начитался об этих всяких оптимизациях, хотел блеснуть. Сноб… :)
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-12 23:43:46.913333
|
|
|
slipslop
Сообщений: 115
Оценки: 0
Присоединился: 2010-12-27 20:21:35.253333
|
quote:
ORIGINAL: DEH
P.S. Кто-то (программист/автор/профессор/кто-то другой, кто понимает в этом деле) говорил "Преждевременная оптимизация - оптимизация ради оптимизации".
Преждевременная оптимизация - корень всех зол (premature optimization is the root of all evil). Говорил её Дональд Кнут, хотя по разным данным авторство приписывают также Хоару и Дейкстре.
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-13 10:57:22.696666
|
|
|
Sрam
Сообщений: 2863
Оценки: 372
Присоединился: 2009-01-16 15:23:43.276666
|
Если ты заранее знаешь что тебе придется обращаться к 100500 таблицам по одним и тем-же исходным параметрам поиска, зачем их дробить на 100500 запросов когда можно просто заюзать union http://www.mysql.ru/docs/gruber/mg14.html.
PS Это приметив, и на веру его брать не обязательно, просто логический вывод из заданного вопроса…
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-13 10:58:48.543333
|
|
|
Sрam
Сообщений: 2863
Оценки: 372
Присоединился: 2009-01-16 15:23:43.276666
|
Если ты заранее знаешь что тебе придется обращаться к 100500 таблицам по одним и тем-же исходным параметрам поиска, зачем их дробить на 100500 запросов когда можно просто заюзать union http://www.mysql.ru/docs/gruber/mg14.html.
PS Это приметив, и на веру его брать не обязательно, просто логический вывод из заданного вопроса…
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-13 17:44:20.283333
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: slipslop
quote:
ORIGINAL: DEH
P.S. Кто-то (программист/автор/профессор/кто-то другой, кто понимает в этом деле) говорил "Преждевременная оптимизация - оптимизация ради оптимизации".
Преждевременная оптимизация - корень всех зол (premature optimization is the root of all evil). Говорил её Дональд Кнут, хотя по разным данным авторство приписывают также Хоару и Дейкстре.
Это смотря какого уровня оптимизация. И смотря на какой задаче. Скажем если есть подозрение что в создаваемом проекте, впоследствии возникнут проблемы со скоростью доступа к СУБД, то стоит до того как будет написана первая строчка кода подумать о том, как эта СУБД будет использоваться, и как её надо использовать. Например, можно использовать не-sql базу данных, а что-нибудь типа, скажем berkeley db – если весь проект заточен на эту бд, то она будет быстрее любого sql. Если же взять готовый проект заточенный на sql и перетащить на bdb, то всё будет уже не столь однозначно. Мало того что это большой-большой геморрой, так ведь ещё и все запросы sql придётся реализовывать ручками, и не факт что ручная реализация будет быстрее реализации MySQL.
Можно, ещё (или вместо этого), использовать не "типа-cgi" подход к написанию веб приложения (я имею в виду подход, когда на каждый запрос запускается самостоятельный скрипт), а написать полноценное приложение, которое будет в себе содержать веб-сервер, и соответственно часть данных вполне можно хранить в оперативной памяти, и в ряде ситуаций, не только не запрашивать у бд эти данные, но даже и не складывать туда. В качестве примера, когда это может помочь, можно глянуть на форум ксакепа, который в моменты особо страшного ддоса переключается на статическую главную страницу форума – но если бы ксакеп хранил бы всю необходимую информацию для главной странице в адресном пространстве веб-приложения, то генерация этой страницы была бы не сильно дольше чем отдача статической, и при этом не порождала бы ни одного обращения к СУБД. Поддержку сессий пользователя, при таком подходе, вполне можно реализовать так, что опять же она не будет порождать ни одного обращения к субд. Точнее будет порождать ровно одно – при входе пользователя. Но если мы возьмём приложение "типа-cgi" и попытаемся сделать из него "типа-не-cgi", то будет проще написать с нуля, чем переделать существующее. Поэтому выбор между двумя подходами лучше сделать осмысленно и, главное, до начала работ по написанию кода.
Но даже если мы ограничим себя "типа-cgi" подходом и SQL, даже в этой ситуации стоит немного подумать о том, как бы так организовать таблицы, чтобы уменьшить количество запросов, их сложность и объём ненужных передаваемых данных между СУБД и приложением. Вообще, конечно же, это оптимизационная задача – подчастую уменьшение количества запросов приводит к увеличению объёма передаваемых данных и/или усложнению этих запросов. Но кое что можно сообразить даже не зная в точности, какое именно приложение получится в итоге и какую именно нагрузку оно будет испытывать.
Так что кто бы не говорил фразу про преждевременную оптимизацию, не надо эту фразу рассматривать как догму. Как ни крути, но всё же прежде чем делать что-то, стоит подумать. И лучше несколько раз подумать, и только потом делать.
ps. Правда я абсолютно согласен с тем, что исходная постановка вопроса ТС выглядит равноценной вопросу "где взять кнопку СделатьЗашибись".
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-13 17:49:34.376666
|
|
|
Sрam
Сообщений: 2863
Оценки: 372
Присоединился: 2009-01-16 15:23:43.276666
|
FriLL'у можно было-бы просто в заголовке написать: "rgo обрати внимание"…
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-13 20:24:05.246666
|
|
|
slipslop
Сообщений: 115
Оценки: 0
Присоединился: 2010-12-27 20:21:35.253333
|
quote:
ORIGINAL: rgo
Так что кто бы не говорил фразу про преждевременную оптимизацию, не надо эту фразу рассматривать как догму. Как ни крути, но всё же прежде чем делать что-то, стоит подумать. И лучше несколько раз подумать, и только потом делать.
А это уже смотря как интерпретировать словосочетание "преждевременная оптимизация" :) Не думаю, что автор подразумевал откладывание любой оптимизации до окончания написания основного кода. Скорее решение о конкретных методах оптимизации стоит откладывать до тех пор, пока оптимизируемая часть приложения не станет достаточно стабильной. Так, СУБД и тип приложения после начала написисания проекта уже вряд ли изменится и их лучше подбирать/оптимизировать сразу, а вот делать выбор между quick sort и merge sort где-то в глубинах util библиотеки, когда ещё не известно, какие структуры данных будут чаще использоваться - вот это уже преждевременно. JVM HotSpot вон вообще откладывает окончательную оптимизацию до момента, когда собрано достаточно статистической информации, чтобы знать как именно оптимизировать. То есть программа уже запущена, работает, а HotSpot всё ещё думает, как оптимизировать.
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-14 17:06:11.953333
|
|
|
FriLL
Сообщений: 2539
Оценки: 335
Присоединился: 2007-08-11 17:14:26.703333
|
Ясно вообщем, пошел контроллер писать
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-17 19:13:29.053333
|
|
|
DEH
Сообщений: 195
Оценки: 0
Присоединился: 2007-01-13 22:27:31.370000
|
В моем понимании, оптимизация это нечто, что делается по готовому коду, понимая, где узкие места, где тяжелые запросы.
Писать оптимально - не значит оптимизировать преждевременно.
Имхо.
|
|
|
|
|
RE: Максимально оптимизировать вывод MySQL - 2011-02-17 19:54:44.256666
|
|
|
MotoKiller
Сообщений: 1732
Оценки: 56
Присоединился: 2008-03-02 20:08:53.810000
|
В процессе написания проекта, будут появляться новые идеи по оптимизации. Заранее все продумать нельзя, особенно когда делаешь это впервые.
|
|
|
|
|
|
