- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всем привет! Вопрос таков: я создаю сейчас скрипт сокращателя ссылок(на подобии bit.ly) и я решил все записи(ссылки и пользователи) хранить в БД MySQL, скрипт предполагает размещение до 3.5 миллионов ссылок, а значит запихнуть их в одну таблицу в БД - просто безумие, я решил эту проблему так: распределение ссылок по таблицам, например - в каждой таблице по 100 000 записей или по 500 000 записей.
Структура таблиц такая:
id | link(до 5000 символов) | hash | gocount(кол-во переходов) | user | date
При каждом переходе по ссылке из БД выдирается link и gocount, потом к значению gocount прибавляется 1 и совершается редирект на линк указанный в поле link.
--------------
Итак вопрос: сколько оптимально можно запихнуть в таблицу записей, чтоб она не тормозила при запросах.
3.5M записей, это не много. Выборка по уникальному ключу, будет быстрой
Тормоза, зависят:
1. От правильности структуры таблицы и индексов
2. Запросов к таблице
3. Процессора сервера
4. Настройки mysql
5. Скорости HDD и его занятости другими делами
А записей холь 10 миллионов, бд пофигу.
Структура нормальная, проблема может быть в введении лога колва переходов - логи это самые нагруженные части проекта. Например в litepublisher для абсолютно такой же задачи я вначале пишу в текстовый файл (путем добавления) id переходов, потом (например раз в час) подсчитывается статистика переходов и одним запросом обновляется бд, тогда при таком алгоритме получается много читателей таблицы и редкие запросы по обновлению, если же каждый раз по клику обновлять бд, то при большом колве кликов могут быть проблемы с производительностью. Как видите, структура таблицы не имеет решающего значения для данной задачи
а точно есть большоый выигрыш между записью в файл или записью в БД?
понимаю если бы временный набор логов складывался в мемкеш, а с него уже отдельный процесс по крону сливал в БД, притом которая находится не на продакшн сервере :)
Мысль у меня есть по этому поводу.
Подумайте над созданием словаря, как в архиваторах. Возможно, ужмётся база.
а точно есть большоый выигрыш между записью в файл или записью в БД?
понимаю если бы временный набор логов складывался в мемкеш, а с него уже отдельный процесс по крону сливал в БД, притом которая находится не на продакшн сервере :)
До определенного момента - да, как определить момент - не знаю, ведь логи сервера апача пишутся в файл и тормозов из за этого нет или потерь данных. Если смущают файлы, то можно спецтаблицу для временных данных. Важно разделить писателей и читателей, тогда можно добитсяувеличения производительности
Ну... я уже думал над созданием временных файлов и их удалении по крону напр. раз в час... но это все похоже на "карточный домик" - что-то пойдет не как продумано и... все!
RoMaN444Ik добавил 19.07.2011 в 12:27
PS. У сервер процессор достаточно мощный: Intel XEON 14x2267MHz... думаю этот и 100 миллионов записей одолеет :)
3,5 миллионов записей, что тут такого безумного то а?!
Индекс вставили и будет бегать и прыгать, для этого БД и создавали. Учитывая, что база не будет весить ГБ 10, но тут уже от сервака зависит и от количество памяти его.
Индекс вставили и будет бегать и прыгать
создание индекса при вставке может тормозить запись, не обязательно в конкретно этом случае, но может.
Ну... я уже думал над созданием временных файлов и их удалении по крону напр. раз в час... но это все похоже на "карточный домик" - что-то пойдет не как продумано и... все!
А что плохо в такой модели? Что же там может рухнуть? Перестанет писаться лог файл?