Приветствую.

Моему коллеге нужен совет. Подскажите кто имел опыт работы с такими базами. Существует проект с применением postgresql, база имеет размер 3 Tb и в ней около 300 млн. строк (в общем количестве).

Скорость работы постгре стала жуткая. Размер не маленький и все задачи сильно тормозят сервера (их несколько). В связи с этим есть идея по смене базы. Есть два варианта. Почему два? Redis - знаком и легкоиспользуемый, а hbase, т.к. его аналог использует гугл и вроде качество.

hbase - аналог используется у гугл с их объемами данных.
redis - знакомая система и вроде как говорят, что довольно шустрая на выдачу и запись.

Вопрос...
Что лучше использовать при таких размерах базы, если она может увеличиться в ближайшие годы до 10 Tb? В огромном приоритете - скорость выдачи. Запись не в приоритете, т.к. осуществляется в определенное время и вовсе не нагружает базу.

Читал, что hbase способен обрабатывать до 1 млн. запроса в сек., redis же до 100 тысяч запросов на запись и в половину от этого меньше на чтение.

Коллеге и мне симпатичен Redis, он проще, удобная и простая репликация, но есть главный минус - если закончится оперативная память, то значит пора добавлять сервер в кластер. В hbase нравится, что аналог применяет крупнейший сайт - гугл, т.е. говорит о качестве, но танцы с бубнами при установке и настройки кластера пугают и пишут, что скорость выдачи медленней, чем у Redis (что опровергает предыдущие данные об обработки в 1 млн. запросов).

Извиняюсь за сумбурный текст, но идея понятна. В вышеописанном случае, что лучше применить? Redis vs HBase
(Добавление)
Да и, то, что hbase распределенная, а Redis - нет, мы в курсе. Это не является проблемой в нашем случае )))

как это ты собираешся заменить SQL базу на редис?
лучше найди нормального админа чтобы посгрес настроил

"как это ты собираешся заменить SQL базу на редис? "
Это не проблема. Просто займет время.

"лучше найди нормального админа чтобы посгрес настроил"
300 млн. записей и настроить postgres? ахах) Оценил шутку.

это не только займет время на перепиливание половины проекта это еще и не даст выиграша по скорости - скорее наоборот.


шутка это про более быстрый редис.

caballero Вопрос был не в этом.

Берите редиску.
Что значит оператива кончится? Там же в конфиге лимит устанавливается, после которого он принудительно сливает на диск.

Это при корректной конфигурации будет очень быстро работать и на MySQL (скорее всего - не берусь утверждать 100%, не видя ни приложения ни бизнес-логики). Благо возможности позволяют.
Я бы рекомендовал использовать связку, а не заменять полностью.

Да-да, устанавливается. Я о том, что 300 млн. записей в Postgre весят около 3 Tb, то не трудно посчитать, что серверов с оперативной памятью потребуется много)) и плюс база растет.
(Добавление)


По сравнению с другими ресурсами - да, 300 млн - это маленькая цифра. Но никто ж не знает, сколько приходится обрабатывать SELECT запросов)) (оооч много) Кэширование есть на все результаты, но результаты редко повторяются и поэтому кэш не очень эффективен. Поэтому стоит вопрос о nosql, как о быстром выплевывании результатов.

antobra как можно ответить где хранить данные, если вы ничего о них не рассказали что за данные то?
И еще вопрос, чтение происходит рандомно? (то есть например данные выбираются за 1 месяц или это не зависит от времени)
Reids хорошая бд просто не нужно хранить там кучу не нужной информации, а хранить только то что действительно должно быстро читаться и выбираться...
Может быть в РСУБД у вас поступает различные сложные запросы, а с помощью redis можно добиться выборки только по первичному ключу...

vanicon

Хранимые данные в постгре - это id(serial), varchar и text. Текст.

Сейчас система такая:
Сфинкс ищет по индексу, составленному по постгре и выдает список ID. Потом делается запрос в постгре и цепляются все данные по этим айди. Так вот запросы по списку в постгре пробегают миллионы строк каждый раз. Уходит по 2-4 секунды. Возможно, вы скажете - нормально, но нет, у конкурентов быстрее работает.

Насколько я слышал postgresql нормально работает с таким кол-вом данных, может быть следует воспользоваться советом caballero, и настроить бд если не настроена, может быть разнести данные по нескольким серверам и тд...
Но можно хранить это дело и в redis, но тут нужно учитывать что оперативка не вечна, и нужно следить что бы ее всегда хватало. А скорость операций записи и чтения по ключу там оч быстрый, можете не сомневаться...
Насчет Hbase ничего сказать не могу, так как с ним не работал, но по отзывам вроде бы неплохая вещь...
Может быть есть возможность хранить данные в redis за определенный период времени, кеш другими словами...

Ps Если будите юзать hbase отпишитесь как оно

И чем вам тогда поможет что угодно? Вы упираетесь в io. И туда же упрётся любая система хранения данных. А если вы поставите столько машин, что суммарного объёма ОЗУ хватит отказаться от постоянного чтения с дисков - то и постгрес будет работать изумительно.
А шардировать на тупом ключ-значение можно любую СУБД.