Покинул форум
Сообщений всего: 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 - нет, мы в курсе. Это не является проблемой в нашем случае )))
caballero
Отправлено: 17 Декабря, 2012 - 19:07:15
Активный участник
Покинул форум
Сообщений всего: 5998
Дата рег-ции: Сент. 2011 Откуда: Харьков
Помог: 126 раз(а)
как это ты собираешся заменить SQL базу на редис?
лучше найди нормального админа чтобы посгрес настроил
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
antobra пишет:
300 млн. записей
Это при корректной конфигурации будет очень быстро работать и на MySQL (скорее всего - не берусь утверждать 100%, не видя ни приложения ни бизнес-логики). Благо возможности позволяют.
Я бы рекомендовал использовать связку, а не заменять полностью.
----- Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
antobra
Отправлено: 18 Декабря, 2012 - 00:06:22
Посетитель
Покинул форум
Сообщений всего: 327
Дата рег-ции: Окт. 2010
Помог: 1 раз(а)
DeepVarvar пишет:
Берите редиску.
Что значит оператива кончится? Там же в конфиге лимит устанавливается, после которого он принудительно сливает на диск.
Да-да, устанавливается. Я о том, что 300 млн. записей в Postgre весят около 3 Tb, то не трудно посчитать, что серверов с оперативной памятью потребуется много)) и плюс база растет. (Добавление)
EuGen пишет:
antobra пишет:
300 млн. записей
Это при корректной конфигурации будет очень быстро работать и на MySQL (скорее всего - не берусь утверждать 100%, не видя ни приложения ни бизнес-логики). Благо возможности позволяют.
Я бы рекомендовал использовать связку, а не заменять полностью.
По сравнению с другими ресурсами - да, 300 млн - это маленькая цифра. Но никто ж не знает, сколько приходится обрабатывать SELECT запросов)) (оооч много) Кэширование есть на все результаты, но результаты редко повторяются и поэтому кэш не очень эффективен. Поэтому стоит вопрос о nosql, как о быстром выплевывании результатов.
vanicon
Отправлено: 18 Декабря, 2012 - 00:26:20
Частый посетитель
Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
antobra как можно ответить где хранить данные, если вы ничего о них не рассказали что за данные то?
И еще вопрос, чтение происходит рандомно? (то есть например данные выбираются за 1 месяц или это не зависит от времени)
Reids хорошая бд просто не нужно хранить там кучу не нужной информации, а хранить только то что действительно должно быстро читаться и выбираться...
Может быть в РСУБД у вас поступает различные сложные запросы, а с помощью redis можно добиться выборки только по первичному ключу...
----- Так было, так есть и так будет
antobra
Отправлено: 18 Декабря, 2012 - 00:36:43
Посетитель
Покинул форум
Сообщений всего: 327
Дата рег-ции: Окт. 2010
Помог: 1 раз(а)
vanicon
Хранимые данные в постгре - это id(serial), varchar и text. Текст.
Сейчас система такая:
Сфинкс ищет по индексу, составленному по постгре и выдает список ID. Потом делается запрос в постгре и цепляются все данные по этим айди. Так вот запросы по списку в постгре пробегают миллионы строк каждый раз. Уходит по 2-4 секунды. Возможно, вы скажете - нормально, но нет, у конкурентов быстрее работает.
vanicon
Отправлено: 18 Декабря, 2012 - 00:48:54
Частый посетитель
Покинул форум
Сообщений всего: 808
Дата рег-ции: Янв. 2010 Откуда: Самара
Помог: 17 раз(а)
Насколько я слышал postgresql нормально работает с таким кол-вом данных, может быть следует воспользоваться советом caballero, и настроить бд если не настроена, может быть разнести данные по нескольким серверам и тд...
Но можно хранить это дело и в redis, но тут нужно учитывать что оперативка не вечна, и нужно следить что бы ее всегда хватало. А скорость операций записи и чтения по ключу там оч быстрый, можете не сомневаться...
Насчет Hbase ничего сказать не могу, так как с ним не работал, но по отзывам вроде бы неплохая вещь...
Может быть есть возможность хранить данные в redis за определенный период времени, кеш другими словами...
Ps Если будите юзать hbase отпишитесь как оно
----- Так было, так есть и так будет
Мелкий
Отправлено: 18 Декабря, 2012 - 09:27:26
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
antobra пишет:
поэтому кэш не очень эффективен
И чем вам тогда поможет что угодно? Вы упираетесь в io. И туда же упрётся любая система хранения данных. А если вы поставите столько машин, что суммарного объёма ОЗУ хватит отказаться от постоянного чтения с дисков - то и постгрес будет работать изумительно.
А шардировать на тупом ключ-значение можно любую СУБД.
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.