Посоветуйте БД

Потестить самому? PgSQL ставится и настраивается за 10 минут. Oracle 11g XE за 15 минут.

Чтобы импортнуть данные в PgSQL тоже особого ума не нужно.

Постгрес, без вариантов

Ок,самед тут надо вначале сделать небольшой ресерч:
1.В каком месте у вас тормозит(очень даже может быть что у вас не все упирается в I/O)?
2.Каково у вас соотношение insert , select ,update в базе(это поможет с выбором движка[ к примеру в случаес mysql можно взять движок] ) ?

Советую обратить в вашем случае на drop-in replacement MariaDB.
Это будет легче чем переписывать приложения для работы с постгресом, учитывая что у тебя кода много довольно-таки.
По обточке посмотри в percona blog.
А так можешь взять postgresql, комьюнити там хорошое, неадекватов мало, решение очень взрослое.

P.S На Oracle задрачиваться не стоит, это кактус еще тот(сам его покусываю каждый день)
P.P.S Часть запросов можете здесь( или в admin/development разделе) показать, тут есть гуру этой СУБД.

Потестить самому? PgSQL ставится и настраивается за 10 минут. Oracle 11g XE за 15 минут.

+1 . Но я думаю ему сложно будет из-за железа построить имитиационную модель.

Это смена шила на мыло. Если нет опыта оптимизации Oracle/PG/MySQL под такие проекты, неважно с чем возиться. Сам по себе тот же постгресс не даст какого-то профита, его также нужно будет крутить.
По поводу монго - если основная чать нагрузки это не запросы на запись, смысла навскидку нет.

Материалов по оптимизации MySQL тьма, на крайний случай есть конторы типа percona lab

Вы что-то лишнее пишете. Откуда у вас стока данных? Если у вас их реально так много, то банальной установкой субд вы не отделаетесь. Придется партицированние делать или что-то еще.

лишнего нету. вся информация нужна. это статистика

Однозначно postgresql , он серьезно выигрывает у mysql при больших объемах.

железо помощнее купить :)

А noqsl движение из-за чего думаешь возникло, из-за таких вот тасков

Покажи какой запрос тормозит.

Исключительно Paritioning и возможно sharding вас спасёт. смена бд - нет. no sql - придётся переписать всё приложение.

+1 Первый дельный коммент в треде

Покажи запросы и структуру бд. 50 млн записей - это не так много, чтобы панику поднимать

И юзкейсы, желательно, тоже опиши.. Хотя бы в виде желаемого результата и частоты тормозящих запросов. Насколько я понимаю, статистика - это преимущественно запросы на запись и агрегирующие на чтение.

Может имеет смысл создавать дополнительные таблицы с уже агрегированными данными? Raw data, кстати, вообще не обязательно сразу в БД класть.

В общем, смена движка СУБД не даст ничего, надо оптимизировать бизнес-логику

Есть мнение, что когда говорят «статистика\10гб\50млн строк\тормозит», то это проблема проектировки. Не предназначены реляционные базы для того чтобы кидать туда 100500 однотипных данных в одну таблицу, а потом полнотекстовым поиском нагибать I\O. Вобщем запрос в студию.

SELECT `lp`.`id`, `lp`.`identity`, `lp`.`name`, `lp`.`description`, `lp`.`likes`, `lp`.`dislikes`, `lp`.`date`, `lp`.`data`, `lp`.`category_id`, `lp`.`country_id` , `country`.`country_name` as `country`, `cat`.`category_name` as `category`, (SELECT `pos`.`page_position` FROM `lsp_pages_history_positions` pos WHERE `pos`.`page_id` =`lp`.`id` ORDER by `pos`.`id` DESC LIMIT 1) as `page_position`, (SELECT `his`.`likes` FROM `lsp_pages_history` his WHERE `page_id` =`lp`.`id` and `his`.`date` > UNIX_TIMESTAMP() - 3600*24 ORDER BY `his`.`date` ASC LIMIT 0 , 1 ) as `likes2` FROM `lsp_pages` `lp` LEFT JOIN `lsp_countries_list` country on `lp`.`country_id`= `country`.`country_id` LEFT JOIN `lsp_categories_list` cat on `lp`.`category_id`= `cat`.`category_id` ORDER by `lp`.`likes` DESC LIMIT 0, 25;

незнаю запрос на сколько поможет не имея структуры всех таблиц но без варианто приходится обращатся к 5-ти таблицам. структура до меня уже была создана

таблица lsp_pages_history содержит 50 млн строк и растёт с каждым днём. так надо.

спасибо за совет . дельное решение

Может создать lsp_pages_history_arc и туда скидывать старые данные?
А в lsp_pages_history держать актуальные для запроса.

Как вот так лихо ничего вообще кроме магических цифр в 10Gb/50kk не зная советовать «однозначно postgresql»? Что вы, что товарищ выше по треду. А что там однозначного? Мускл держит такие циферки, вполне нормально. Есть огромная разница между простым инсертом который вставляет байт сто в таблицу без индексов и какой-нибудь многокилобайтной вставкой в таблицу обвешанной индексами. Смотреть надо запросы и структуру бд, чтобы вообще что-то говорить. На таких объёмах надо сидеть просвещаться про шардинг, партицирование, репликации, а не просто тупо менять бд.

Запрос тяжеловат скорее всего. Постгр ложился у меня кода в подзапросе было order by limit 1. Вылечил денормализацией.

SELECT `lp`.`id`, `lp`.`identity`, `lp`.`name`, `lp`.`description`, `lp`.`likes`, `lp`.`dislikes`, `lp`.`date`, `lp`.`data`, `lp`.`category_id`, `lp`.`country_id` , `country`.`country_name` as `country`, `cat`.`category_name` as `category`, (SELECT `pos`.`page_position` FROM `lsp_pages_history_positions` pos WHERE `pos`.`page_id` =`lp`.`id` ORDER by `pos`.`id` DESC LIMIT 1) as `page_position`, (SELECT `his`.`likes` FROM `lsp_pages_history` his WHERE `page_id` =`lp`.`id` and `his`.`date` > UNIX_TIMESTAMP() - 3600*24 ORDER BY `his`.`date` ASC LIMIT 0 , 1 ) as `likes2` FROM `lsp_pages` `lp` LEFT JOIN `lsp_countries_list` country on `lp`.`country_id`= `country`.`country_id` LEFT JOIN `lsp_categories_list` cat on `lp`.`category_id`= `cat`.`category_id` ORDER by `lp`.`likes` DESC LIMIT 0, 25;

а можно сюда EXPLAIN этого запроса?

partition помог . в 25 раз запрос сработал быстрее

partition помог . в 25 раз запрос сработал быстрее

Рамиль, еще можешь для будущего юзать mysqltuner.pl - это какбы удобный «фреймворчик» для определения узких мест .