Python-сообщество

Нужно написать что то типа веб-кеша (сохранения html-страниц в БД), в принципе в БД будет хранится единая таблица со столбцами урл и сам html-код; и одно с основных требований размер БД где то 1Тб в 32-битной ОСи.
Подскажите какая БД подошла бы для этих целей?

Вы кеш на одной машине собираетесь делать, что ли? :/
Если нет, то сколько нод можете себе позволить?
Кеш на диске хранить будете или только память?
Какой размер урлов и страниц?
Какое соотношение запись/чтение для хранимых данных?
Нужно ли обеспечить ACID, если да, то зачем (какая конкретная цель)?
ОС?

В начале (2-5Гб) на одной машине в переспективе нужна возможность переноса на несколько нодов (3-5).
Размер урл-ов не более 256-символов.
Запись 1-раз, чтение много раз, удаление будет производиться 1раз в сутки в выделенной промежуток времени.
Обеспечение ACID не обязательно.
ОС Ubuntu 12.XX (32бит) в будущем centos 5.X (64бит).

agryn
удаление будет производиться 1раз в сутки в выделенной промежуток времени.

Странный вариант, почему не стандартный expire в 1 сутки?

Redis.

fata1ex
Redis.

У него есть одна неприятная особенность - необходим рестарт кластера при изменениях в структуре кластера. В том числе, если добавляем ноду для расширения кластера или нода временно отвалилась.
Плюс ненужный в данном случае (исходя из требований) оверхед. К тому же у 32-битного Redis ограничение по памяти 4ГБ на инстанс (что очевидно), но опять же вспоминаем сложность управления всеми инстансами.

agryn
32 бита, кончено, та еще морока даже с PAE.
С вашими критериями все в память не поместится независимо от системы кеширования.
На 64-х можно и в памяти держать.

Сначала хотел было предложить безальтернативно Memcached, если страницы не больше 1Мб, но боюсь, что скорость на объемных значениях (html страница) просядет. Впрочем, как и у Redis.
Поэтому тесты на страницах вашего размера нужно провести обязательно.
Эта страница, например,- около 5кБ.

Я бы рекомендовал закешировать Memcached только мелкие наиболее часто используемые страницы, а все большие, если тесты покажут неудовлетворительный результат, разместить на диске и отдавать как статику через nginx. Вырастите, подумайте над установкой SSD. В сервера их уже ставят давно на Западе.

Плюс можно поиграться со значением MTU (увеличить до размера наиболее часто востребованных страниц), чтобы получить максимальную отдачу от сетевых соединений.
Обычно именно на них проседает скорость.

Lexander,

подскажите noSQL БД

:)

У редиса большой плюс как у базы данных - это гибкие структуры данных. Уже созданную инфраструктуру кэширования можно будет впоследствии использовать для других похожих целей. Более гибко можно будет реализовать работу с удалением ключей или каким-нибудь выборочным прогреванием ) По первоначальным запросам (2-5ГБ) в память всё замечательно помещается, и я плохо себе представляю рост в 300 раз (при 3-5 нодах). Нескольких нод по 16-32ГБ оперативки должно хватать надолго. Если всё-таки нужны 1ТБ, тут и правда можно посмотреть на SSD.

Минусы есть с кластеризацией, здесь memcached пока впереди, но, насколько я понял, рост по нодам будет небольшой и не сейчас.

Вообще, тут вариантов довольно мало. Посмотрите всякие запросы вроде ‘redis vs memcached’, там много полезного. Ну и как альтернатива - couchbase.

Отредактировано fata1ex (Сен. 5, 2012 08:51:30)

fata1ex
У редиса большой плюс как у базы данных - это гибкие структуры данных.

Это именно тот минус :D, который я назвал оверхедом.
Разве для кеша все это необходимо?
А использовать один и тот же инстанс для кеша и для чего-то еще неправильно с точки зрения архитектуры и обслуживания БД.