- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть бд 3,1 гига, состоящая всего из одной таблицы 3 гига и двух по 50 мегабайт.
Таблица не делима, т.к. все записи в каждом поле уникальны.
ID товара имя товара страна цена код
т.е. страну могут написать как РФ или как Россия или как Раша и т.д.
на сервере еще крутится несколько небольших сайтов, из за этой БД сайты уже полумертвые.
Поскажите как разгрузить?
1.у меня только вариант выделить под базу отдельный комп.
2.Делить на таблицы по ID товара
но в этом случае непонятно будет ли
select * from table1
union
select * from table2
union
select * from table3
быстрее чем
select * from table1
также в таблице полнотекстовые индексы уже 2 гига.
Если у вас был подобный опыт подскажите плз.
сложно советовать не понимая какие именно запросы у вас создают нагрузку.
обновление или выборка или полнотекстовой поиск?
На первый взгляд решений вагон :
увеличить key_buffer до размера индексов. может он у вас там просто маленький, раз уж нет отдельного mysql-сервера.
полнотекстовый поиск от sphinxsearch.com .
таблицы типа merge.
raid0 ( легко, эффективно, но опасно)
кластеры.
в версиях 5.1 вроде уже partitioning появился ( что-то вроде тонкой группировки хранения данных)
Разбить по серверам, на одном таблица с Россией, на другом - с Рашей
Darksquall, А кеширование на диск придумать и реализовать что уже непосильная задача для современных программистов :)
Я на одном проекте решил эту проблему переездом на PostgreSQL. К огромным базам он относится совершенно спокойно.
Есть бд 3,1 гига, состоящая всего из одной таблицы 3 гига и двух по 50 мегабайт.
Таблица не делима, т.к. все записи в каждом поле уникальны.
ID товара имя товара страна цена код
т.е. страну могут написать как РФ или как Россия или как Раша и т.д.
на сервере еще крутится несколько небольших сайтов, из за этой БД сайты уже полумертвые.
Поскажите как разгрузить?
1.у меня только вариант выделить под базу отдельный комп.
2.Делить на таблицы по ID товара
но в этом случае непонятно будет ли
select * from table1
union
select * from table2
union
select * from table3
быстрее чем
select * from table1
также в таблице полнотекстовые индексы уже 2 гига.
Если у вас был подобный опыт подскажите плз.
Вобще то мускуль реляционная БД, так может стоит потратить денек и Объединить все РФ Россия Раша в один ID из другой таблички, и также другие значения
Поскажите как разгрузить?
Вы сначала действительно расскажите, чем собственно mysql-сервер загружен?
Какого рода запросы выполняются чаще всего? Что обычно видно по show processlist? В полной ли мере используются индексы?
Если проблема в запросам к full text index'ам, то их реально никак не оптимизируешь. Зато само собой напрашивается сделать репликацию на второй сервер и использовать два сервера параллельно.
Или же переходить на другой поиск, не full text.
я бы сначала посоветовал воспользоватся tunning-premier.sh или аналогичным скриптом, чтобы понять насколько вы исчерпали ресурсы своего сервера - возможно не все так плохо, и есть вариант оптимизировать настройки.
Если нет - нужно смотреть нагрузку на сервер и узкие места. Возможно, переезд базы на отдельные сервер Вам поможет
Если у вас был подобный опыт подскажите плз.
Ищите логические ошибки в запросах. Классический сценарий, когда пишутся кривые запросы, которые при маленькой базе летают, а при разросшейся базе начинают дико тормозить.
Я всегда начинаю оптимизацию созерцанием MyTOP. Только зная, какие запросы грузят, можно оптимизировать: http://jeremy.zawodny.com/mysql/mytop/
Если ваш случай допускает - кешируйте где можно результаты запросов. В нагруженных проектах, где запросы типичны но сложны, помогает.
запросы абсолютно не сложны обычный поиск по БД в полнотекстовых полях, но запросов много и как правило искать нужно по всей БД сразу.
Рашу выделять нет смысла, т.к. там все страны мира и по этому полю поиск не идет
например
12345 Утюг Италия 134 845435
Основное поле утюг в котором и ищем, но т.к. утюг может находится и в детских игрушках и в бытовых товарах и в названиях картин например то разделить по ID тоже мне кажется смысла нет.
Даст ли что кэширование если Утюг ищет некоторый процент пользователей а другой процент уже будет искать автомобиль или еще чтото.