Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737
Форумы портала PHP.SU :: hbase или redis

 PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (1): [1]   

> Описание: Посоветуйте, если использовали. Спасибо.
antobra
Отправлено: 17 Декабря, 2012 - 18:37:57
Post Id


Посетитель


Покинул форум
Сообщений всего: 327
Дата рег-ции: Окт. 2010  


Помог: 1 раз(а)




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

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

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

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

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

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

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

Извиняюсь за сумбурный текст, но идея понятна. В вышеописанном случае, что лучше применить? Redis vs HBase
(Добавление)
Да и, то, что hbase распределенная, а Redis - нет, мы в курсе. Это не является проблемой в нашем случае )))
 
 Top
caballero
Отправлено: 17 Декабря, 2012 - 19:07:15
Post Id


Активный участник


Покинул форум
Сообщений всего: 5998
Дата рег-ции: Сент. 2011  
Откуда: Харьков


Помог: 126 раз(а)




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


-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore
 
 Top
antobra
Отправлено: 17 Декабря, 2012 - 19:39:48
Post Id


Посетитель


Покинул форум
Сообщений всего: 327
Дата рег-ции: Окт. 2010  


Помог: 1 раз(а)




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


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

"лучше найди нормального админа чтобы посгрес настроил"
300 млн. записей и настроить postgres? ахах) Оценил шутку.
 
 Top
caballero
Отправлено: 17 Декабря, 2012 - 19:57:53
Post Id


Активный участник


Покинул форум
Сообщений всего: 5998
Дата рег-ции: Сент. 2011  
Откуда: Харьков


Помог: 126 раз(а)




Цитата:
Это не проблема. Просто займет время.

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

Цитата:
300 млн. записей и настроить postgres? ахах) Оценил шутку

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

(Отредактировано автором: 17 Декабря, 2012 - 19:58:10)



-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore
 
 Top
antobra
Отправлено: 17 Декабря, 2012 - 20:05:47
Post Id


Посетитель


Покинул форум
Сообщений всего: 327
Дата рег-ции: Окт. 2010  


Помог: 1 раз(а)




caballero Вопрос был не в этом.
 
 Top
DeepVarvar Супермодератор
Отправлено: 17 Декабря, 2012 - 21:10:22
Post Id



Активный участник


Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Берите редиску.
Что значит оператива кончится? Там же в конфиге лимит устанавливается, после которого он принудительно сливает на диск.
 
 Top
EuGen Администратор
Отправлено: 17 Декабря, 2012 - 22:33:57
Post Id


Профессионал


Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




antobra пишет:
300 млн. записей

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


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
antobra
Отправлено: 18 Декабря, 2012 - 00:06:22
Post Id


Посетитель


Покинул форум
Сообщений всего: 327
Дата рег-ции: Окт. 2010  


Помог: 1 раз(а)




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


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

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


По сравнению с другими ресурсами - да, 300 млн - это маленькая цифра. Но никто ж не знает, сколько приходится обрабатывать SELECT запросов)) (оооч много) Кэширование есть на все результаты, но результаты редко повторяются и поэтому кэш не очень эффективен. Поэтому стоит вопрос о nosql, как о быстром выплевывании результатов.
 
 Top
vanicon
Отправлено: 18 Декабря, 2012 - 00:26:20
Post Id



Частый посетитель


Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010  
Откуда: Самара


Помог: 17 раз(а)




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


-----
Так было, так есть и так будет
 
 Top
antobra
Отправлено: 18 Декабря, 2012 - 00:36:43
Post Id


Посетитель


Покинул форум
Сообщений всего: 327
Дата рег-ции: Окт. 2010  


Помог: 1 раз(а)




vanicon

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

Сейчас система такая:
Сфинкс ищет по индексу, составленному по постгре и выдает список ID. Потом делается запрос в постгре и цепляются все данные по этим айди. Так вот запросы по списку в постгре пробегают миллионы строк каждый раз. Уходит по 2-4 секунды. Возможно, вы скажете - нормально, но нет, у конкурентов быстрее работает.
 
 Top
vanicon
Отправлено: 18 Декабря, 2012 - 00:48:54
Post Id



Частый посетитель


Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010  
Откуда: Самара


Помог: 17 раз(а)




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

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


-----
Так было, так есть и так будет
 
 Top
Мелкий Супермодератор
Отправлено: 18 Декабря, 2012 - 09:27:26
Post Id



Активный участник


Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009  
Откуда: Россия, Санкт-Петербург


Помог: 618 раз(а)




antobra пишет:
поэтому кэш не очень эффективен

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


-----
PostgreSQL DBA
 
 Top
Страниц (1): [1]
Сейчас эту тему просматривают: 0 (гостей: 0, зарегистрированных: 0)
« Администрирование БД »


Все гости форума могут просматривать этот раздел.
Только зарегистрированные пользователи могут создавать новые темы в этом разделе.
Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
 



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB