Как работать с большими БД для web-проектов?

Question

[Goodver]

Вебсайт, имеются несколько больших БД по 10~20 миллионов записей. Использую связку php-mysql
В таком случае если нужно сделать выборку SELECT хотябы из одной базы то это занимает до нескольких минут.

Поставил Sphinx, с поиском все замечательно, вот только нет live update, а мне нужно чтобы когда вноситься новая информация или изменяется старая то это сразу было в работе. То есть как на хабре к прмеру, когда я создаю новый вопрос или топик я сразу могу перейти на его страницу, а у сфинса нужно обновлять индексы для этого.

Как имея миллионы записей скажем на хабре все так быстро индексируется?

Подскажите пожалуйста инструменты, способы работы с большими БД. То есть мне нужно сдлеать максимальную скорость выборки SELECT (INSERT, UPDATE тоже нужно, но второстепенно), причем чтобы ДБ был live, то есть если вноситься информация то она сразу может быть использована. Может быть другие БД использовать не mysql…

И еще, можно ли хотябы примерно сказать зависимость обработки подобных запросов от наличия ОЗУ. То есть грубо говоря 2ГБ RAM — 2 минуты, 4ГБ RAM — 1 минута. Интересует хотябы примерная зависимость.

Comments

[freeek]

Связку PHP-mysql вы менять не хотите?

[e_Jin]

каким это боком я могу уточнять этот чужой вопрос?? © e_jin

Answer 1

[Александр]

Стоят ли у вас индексы на таблицах?
Sphinx это поисковой движок, при коротком времени обновления индекса у вас будет свежая инфа в индексе.

Но мне кажется вы что-то делаете не так:
Зачем собственно выводить данные из индекс sphinx, а не напрямую из бд? Если проблема только в скорости значит у вас проблемы с запросами. Необходимо проанализировать запросы через EXPALIN и проверить наличие и использование индексов.

Comments

[Goodver]

Спасибо, индексов нет, полагаю в этом проблема

Answer 2

[edogs]

индексов нет

Поставьте индексы.
Ваш К.О.

Answer 3

[Дмитрий Сергеев]

В Sphinx есть real-time indexes
sphinxsearch.com/docs/2.0.4/rt-indexes.html

Так же в нём есть delta индекс
sphinxsearch.com/docs/2.0.4/delta-updates.html
это когда у вас есть основной(main) индекс + небольшой индекс delta, в котором хранится индекс по признаку, например id>99999. При изменении в бд вы обновляете только delta индекс а поиск осуществляется по индексу main+delta

Comments

[Goodver]

Я про это знаю, но это все «как бы» лайв индекс, то есть во первых делается просто вручную грубо говоря, всмысле обновляется через какой-то промежуток времени. А мне нужно чтобы как только внесено изменение оно сразу становилось рабочим.

[Aleks]

реал тайм индекс как раз то что вам нужно без этих там всяких намеков на «как-бы» и тру

[Goodver]

Реал тайм индексы, INSERT и REPLACE, в базу и основной идекс ничего не вносят, а вносят в свою таблицу. Тоесть если мне например нужно удалить чтото из sql, то в индексе сфинкса это останется. Кроме того UPDATE сфинкса не может обновлять строковые поля. Единственный способ использования реал тайм индексов я вижу как: создать 3 рейл там индекса: INSERT, DELETE, UPDATE. При создании внесении новой информации, делается инсерт в sql, а так же RT индекс INSERT, при удалении информации делается delete в sql, а так же вноситься запись об этом в RT индекс DELETE, c UPDATE соответсвенно. Так вот при SELECT у сфинса, нужно будет брать информацию у основного индекса и корректировать ее используя RT индексы. Я правильно понимаю или можно как то проще?

Answer 4

[strib]

Оптимизируйте запросы и БД.
Просто написать запрос — недостаточно, важно написать его так, чтобы операции выподнились в оптимальном порядке.
dev.mysql.com/doc/refman/5.5/en/execution-plan-information.html
Т.е. к примеру делать объединение данных а потом фильтрацию заведомо дольще чем сначала отфтльтровать, а потом объединить, исключить использование оператора IN, итд итп.

Партиции! Посмотрите в сторону секционирования.

Потом надо смотреть производительность сервера, узким местом может быть диск, посмотрите что показывает iostat в время выполнения запроса.

Нет, нельзя привязаться к объему ОЗУ. Зависит от индексов, типов операций, нагрузки на диск, а если движек InnoDB, то есть смысл тюнить параметры.

Короче. Несколько были такие таблицы в MySQL 4.xx — все работало нормально если аккуратно. В 5.x должно работать гораздо лучше, т.к. средств новых появилось больше. Указанные Вами объемы (10-20 млн строк) нормально обрабатывал на ноутбуке.

Comments

[Lev Lybin]

Почти полностью согласен) Чем больше ОЗУ тем лучше, сколько необходимо ОЗУ можно подсчитать ~ от объема БД + тюнинг мускула и запросов, уж больно медленные у вас запросы «до нескольких минут», вполне возможно, что вам не помешала бы реплика.

Answer 5

[freeek]

В принципе, работая с PHP + MySQL делал выборку не самую тривиальную из таблиц с количеством записей выше миллиона и это не занимало больше двух секунд, так что, думаю, что disc прав.

Конечно, можно посмотреть в сторону Oracle DB, а, смотря на Twitter, в сторону RoR. Но, для начала, нужно оптимизировать запросы, проверить индексы и т.д.

Comments

[larikov]

А как RoR поможет увеличить быстродействие БД?

[freeek]

Быстродействие БД — никак. Можно увеличить производительность приложения. Но я не настаиваю именно на RoR, и не говорю об этом, как о единственном решении.

[freeek]

Хоть расскажите, за что минус :)

Answer 6

[mithraen]

1. Утилита mysqltuner поможет настроить сам mysql
2. С помощью explain посмотрите используются ли индексы при выполнении запросов
3. Ваша проблема наверняка связана с тем, что не созданы нужные для ускорения конкретно ваших запросов индексы.

Подсказать что-то большее можно уже только увидев структуру БД и сам запрос.

Также рекомендую книгу Мартин Грабер «Понимание SQL». Там очень много ценного про оптимизацию запросов есть.

Answer 7

[hOtRush]

помоему mysql для таких обьемов данных не лучший выбор.
сколько весит ваша база, для интереса)

Comments

[Gesper]

Простите, но у меня MySQL с PHP нормально себя чувствовали и на 100Гб базе. Грамотно проставленные индексы, оптимизированные запросы, разумная структура таблиц и все нормально работает.

[vc4vc]

Gesper, А можете поподробнее о своей базе рассказать )?

Answer 8

[ToSHiC]

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

Comments

[Goodver]

Запросы простые типа SELECT aaa FROM bbb WHERE ccc=ddd, джоинов нет, индексов нет.

[ToSHiC]

Просто постройте обычный самый индекс, alter table bbb add index…

Answer 9

[Dmitry]

>То есть грубо говоря 2ГБ RAM — 2 минуты, 4ГБ RAM — 1 минута

меньше 200 мс обычно такие запросы выполняются

Answer 10

[dkurilenko]

Написать триггер на вставку, который будет добавлять данные сразу в оффлайн индекс (в данном случае Sphinx).

Пример вызова PHP кода из триггера: stackoverflow.com/questions/1467369/invoking-a-php-script-from-a-mysql-trigger