- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Порекомендуйте в какую сторону смотреть?
Дано:
- количество записей - больше, чем много;
- структура - простая - id и пара целых чисел;
- активно используется сортировка по одному полю;
- на запись активность есть тоже, но это можно обойти - актуальность обновления низкая, можно и раз в сутки обновлять, накопив запросы;
- возможность бэкапа.
Кроме мускула ничем до этого не пользовался. Вот и не знаю куда смотреть :(
Конкретные цифры в студию.
Сколько в Гигабайтах это?
Так же не понятно в чём вопрос.
Конкретные цифры в студию.
Сколько в Гигабайтах это?
Много. За неделю работы 10гиг набралось на мускуле. Что будет дальше - боюсь даже думать.
Так же не понятно в чём вопрос.
Какую БД выбрать - вот вопрос.
10 гиг для mysql это ерунда.
Для очень больших баз подойдет PostgreSQL
Уточню, количество записей в теории должно выйти за 500 лямов, на практике, думаю, до этого не дойдет, сложно предположить окончательный размер. Сортировка на таком количестве, наверное, просто положит сервер - это уже сейчас происходит при нагрузке в час пик - БД пока не выносил на отдельный сервер, вместе с движком крутится.
Стоит смотреть в сторону NoSQL - MongoDB и тд.?
Вот тут наверное у вас у любой БД будут проблемы.
---------- Добавлено 15.02.2015 в 20:07 ----------
Так же я бы рекомендовал пересмотреть структуру и использование БД.
Возможно делить как-то по датам, для каждой даты своя таблица.
sidorka, Смотрите в сторону Enterprise решений вроде Percona sql и тп (лёгкий переход с mysql без изменения кода) + желательно уже начать задумываться о кластеринге sql сервера.
http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html
Оптимизайка, Вы предлагаете ТС весь сайт переписать с нуля?
---------- Добавлено 15.02.2015 в 20:56 ----------
sidorka, Сортировка по 1 полю, а что если sphinx search подключить, как интересно ваше приложение на это среагирует?
LEOnidUKG, даже не знаю что там пересмотреть можно.
Может, чтоб было проще понять чего нужно, попробую объяснить что делаю.
Вроде тизерки личной ваяю - под каждый ключевик наиболее кликабельный результат выбирается. Структура простая - пять полей - ид ключа, ид рекламы, просмотры, клики, цтр. Индексы присутствуют. Сортировка по цтр. Вроде все.
Порекомендуйте скрипты какие готовые посмотреть, может оттуда выдергну решение готовое. Смотрел скрипты сиджей - принципиальных прорывов там нету, та же проблема.
kxk, за перкону спс. Пойду поищу сравнительные тесты.
---------- Добавлено 15.02.2015 в 21:00 ----------
kxk, это не сайт даже - сервис-скриптик одностраничный небольшой, json выдающий. Переписать проблем нет, был бы результат
sidorka, К sphinx search присмотритесь :)