- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Структура базы: около 50 столбцов и (в ближайшем будущем) около 3-5 млн строк.
К базе идет очень много чтений строк по уникальному id строки и немного меньше, но тоже часто - добавление и обновление строк. скрипт работающий с базой написан на php
В каком формате все это хранить?
1) Пробовал mysql (одна база), нагрузка на сервер ацкая, как не оптимизировал, да и скорость работы просто никакая, тормоза жуткие.
2) Сейчас работает на sqlite3 (множество баз по 10к строк) + кеширование запросов в memcached, костыльно както, да и косяки с постоянной блокировкой базы, когда один пишет, другой прочитать не может.
Сейчас начал играться с mongodb, что скажете?
Или может есть более интересный и удобный вариант?
Узкое место — диск? Если так, то изврат с tmpfs здорово повысит скорость.
Узкое место — диск? Если так, то изврат с tmpfs здорово повысит скорость.
ну диск он не зависимо от типа базы диск, ssd будет, хоть в рейде. не в этом дело, его не проблема поставить максимально быстрый.
Нужно выбрать оптимальный тип базы. монгодб вот сама вроде как в памяти кешируется, без дополнений типа tmpfs, memcached и т.п., но что-то у меня сомнения в надежности манги, если вдруг сервер ребутнется или еще какой нештатный глюк...
Просто я долго мучился в своё время, оптимизировал запросы, и всё равно скрипт работал непозволительно долго, несколько суток на задачу, при этом не мог спокойно смотреть на постоянно горящий индикатор работы диска и слушать его хруст. Закинул всё в ОЗУ, и за несколько часов скрипт отработал.
DenisVS, да в общемто я бы не сказал что диск становился узким местом (iotop во всяком случае не показывал ничего критичного, запас есть), но вот сами базы тупят изза конкурентных запросов.
1) Пробовал mysql (одна база), нагрузка на сервер ацкая, как не оптимизировал, да и скорость работы просто никакая, тормоза жуткие.
InnoDB, надеюсь? Что с кэшированием средствами базы.., с памятью под кэш, под временные таблицы? Explain-ы Индексы и прочее..
лог медленных запросов что говорит?
около 50 столбцов и (в ближайшем будущем) около 3-5 млн строк.
Есть текстовые столбцы? Все ли столбцы нужны постоянно? Я к тому, что иногда имеет часть данных (длинных строк.. всех TEXT-полей) вынести в другую таблицу (связь по PK/id)
Иногда имеет смысл вместо varchar использовать char - фиксированная длина строки -> расчёт позиции курсора.
Не использовать функции, препятствующие кэшированию (CURRENT_TIMESTAMP() и тд.. http://dev.mysql.com/doc/refman/5.0/en/query-cache-operation.html)
Можно "разгрузить" mysql, в мемкэш складывать.. если, конечно, смысл есть..
монгодб вот сама вроде как в памяти кешируется, без дополнений типа tmpfs, memcached и т.п., но что-то у меня сомнения в надежности манги, если вдруг сервер ребутнется или еще какой нештатный глюк...
mysql тоже в память лезет, если настройки позволяют.. =)
По поводу надёжности mongodb - в любом случае бэкапы не помешают.. но, если есть возможность - использовать репликацию.
---------- Post added 05-03-2013 at 21:43 ----------
Ещё.. для MySQL можно partitions посмотреть.
Да, а ведь кэш InnoDB нужно долго "греть", чтобы от него был эффект, не забывайте при тестах про это.
Имхо для Mysql - это детская база. Есть опыт работы и со значительно большими таблицами.
Думаю проблема в логике/запросах php скрипта.
Покажите
И какие параметры сервера на который "нагрузка ацкая"?
- postgresql
- попробовать разнести базу
?
Чтобы ответить, слишком много неизвестных, таких как:
Что значит медленно, сколько сек, мсек, мин на запрос?
Сколько запросов в единицу времени?
Размер базы данных в мб, гб?
Мощность сервера ( озу, процессор )
Ну и неплохо бы увидеть show create table TABLENAME для таблицы из которой дергаются данные.
И сам запрос, который формируется для mysql.
Имхо для Mysql - это детская база. Есть опыт работы и со значительно большими таблицами.
Думаю проблема в логике/запросах php скрипта.
Покажите если база на mysql еще сохранилась.
И какие параметры сервера на который "нагрузка ацкая"?
уже не сохранилась, на случай моей криворукости и не очень больших знаний mysql - помогал настраивать человек который в этом получше разбирается. в итоге mysql все равно не смогла приблизиться к sqlite3+memcached
- postgresql
- попробовать разнести базу
?
postgresql никогда не тестил, нужно попробовать.
база сейчас разнесена на мелкие базы (sqlite), по скорости устраивает, нагрузка на проц/оперативку не большая, но нередко случается что прочитать не получается из базы, т.к. туда ктото пишет, в итоге костыли с повторными запросами на чтение , да и не удобно искать сразу по куче баз.