БД гигантского размера

Пересмотреть архитектуру приложения.

Выделять частые - в отдельную.

в разы больше памяти под кеш.

надо предметно ковырять, слишком нетиповая задача и мелочи могут повлиять не ответ

MySQL на innodb с правильным созданием индексов - нормально и 500 лямов потянет

sidorka, 500 млн. записей это много. Не уверен, что получится обрабатывать с приемлемой скоростью без кластера.

Судя по тому, что структура данных простая, не факт, что нужен SQL.

Можно посмотреть в сторону key=>value хранилищ и noSQL.

Посмотрите на Hbase, Cassandra. Можно elasticsearch прикрутить как noSQL database, заодно и поиск по данным и масштабирование реализуются "на ура".

По опыту поиска на более сложных данных (web) - 5-10 млн. документов на сервер - предел для разумной (менее 1 сек.) скорости поиска по кластеру.

siv1987, не пойму про какую избыточность речь.

<id1><id2><views><clicks><ctr>

Все числа целые. Поиск по составному ключу <id1><id2> и сортировкой по <ctr>. <views> и <click> - для вычисления <ctr>, используются только при апе.

---------- Добавлено 17.02.2015 в 21:27 ----------

TF-Studio, а примеры есть какие посмотреть-поковырять-почитать?

---------- Добавлено 17.02.2015 в 21:29 ----------

С перконы эффект есть, пошустрее бегает заметно. Боюсь ненадолго только.

Все про ту же. Все уже написали. Три человека про одно и то же твердят.

Ищите решение проблемы не в смене способа хранения и работы с данными, а в переосмыслении алгоритмов и структуры.

Ну вот поставите вы 3 сервера для nosql-хранилища и отдельный для memcache. Что-то там распределите. Но работу по поиску они примерно ту же будут выполнять. И сколько еще их вы сможете поставить, даже при линейном росте производительности ? Это при любом раскладе невыгодно.

У меня стата игровых серверов в базе примерно с той же проблемой была

Суть примерно в том что опрашиваются тысячи серверов, раз в несколько минут, ответ парсится и сохраняется. На основании этого строятся графики посещаемости. После первых пары месяцев я понял что сделал не так.

Теперь у меня данные за последний период (настраиваемо, сейчас неделя) хранятся в одной табличке, а крон среди ночи забирает их по мере необходимости, считает средние показатели аптайма, посещаемости и прочих дел за каждый час и за сутки, и пишет это в другую табличку, а из той удаляет. Данных в разы меньше. Ну и индексы никто не отменял. Статистика строится по второй таблице

Metal_Messiah, а чем этот способ отличается от обычного кэширования? Вроде то же самое - выборки на наиболее популярные запросы хранятся отдельно и не грузят БД, пока актуальность не истечет. К чему пляски с двумя таблицами?

siv1987, netwind, Вы бы как решили такую задачу?

---------- Добавлено 18.02.2015 в 01:06 ----------

kxk, дело не в том, что мне реалтайм надо, мне просто быстро из статичной большой таблицы выбрать надо с сортировкой. Активную часть закэширую, естесвенно, но что с НЧ запросами к БД делать?

---------- Добавлено 18.02.2015 в 01:09 ----------

Сразу поясню - образование - ПТУ.

1. сколько строк в среднем выдаётся по составному ключу?

2. сколько вообще запросов в секунду?

3. мне стыдно спрашивать, но: индексы на всех полях?

У Вас разве ключ <id1><id2> не уник? Судя по "сортировке" - нет.. Какой у вас ключ уникальный?

А лучше покажите структуру таблицы "CREATE TABLE... и т.д."

1. 30-40 за раз.

2. сложно сказать, как начинают набигать - так вроде и много. Не мерял. То где крутится щас - оценочно 100к в сутки, нужно больше. Сервер убогий, но нужно именно под такой и еще слабее.

3. Индексы есть вроде как.

admak, спс, что поправили. Запрос выглядит так

SELECT id2 FROM table WHERE id1 = ID ORDER BY ctr LIMIT limit

Структура точная:

CREATE TABLE IF NOT EXISTS `cj` (

  `keyword_id` int(11) NOT NULL,

  `item_id` int(11) NOT NULL,

  `views` int(11) NOT NULL DEFAULT '0',

  `clicks` int(11) NOT NULL DEFAULT '0',

  `ctr` int(11) NOT NULL DEFAULT '0',

  PRIMARY KEY (`keyword_id`,`item_id`),

  KEY `keyword_id` (`keyword_id`,`item_id`,`ctr`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;