My<cod/>.net
Результаты поиска
Найдено результатов: 15
Шардинг MongoDB под нагрузкой?
Как ведет себя шардинг MongoDB под нагрузкой? Особенно как влияет на загрузку системы их Map/Reduce?
NoSQL — особенности применения
В каком случае оправдано использование таких баз данных как MongoDB, CouchDB, Redis и некоторых других?
Имеет ли смысл ставить их вместо классического mysql, на сайте со слабой нагрузкой?
Используются ли они в связке с mysql, или работают отдельно?
Репликация Redis
Занимаюсь одним стартапом в котором применяем редис, сейчас вплотную стал вопрос о построении отказоустойчивого кластера БД.
Как известно, редис пока поддерживает только master-slave репликацию. Необходимо, чтобы при падении мастера какой-нибудь из слэйвов взял бы функцию мастера. Для этой цели нашел следующее решение: github.com/fictorial/redis-cluster-monitor. При падении мастера, данная мониторилка выбирает нового мастера и посылает сигнал синхронизации с ним остальным серверам. Задача — уведомить фронтэнды о том, что мастер-сервер сменился. Собираюсь дописать мониторилку, чтобы она еще и слала уведомления и фронтэндам. Адрес мастер-сервера, вероятно будет храниться локально в файле.
На сколько правилен подобный подход? У кого был опыт постоения подобных систем, как обычно поступают, какие подводные камни?
Репликация Redis
Занимаюсь одним стартапом в котором применяем редис, сейчас вплотную стал вопрос о построении отказоустойчивого кластера БД.
Как известно, редис пока поддерживает только master-slave репликацию. Необходимо, чтобы при падении мастера какой-нибудь из слэйвов взял бы функцию мастера. Для этой цели нашел следующее решение: github.com/fictorial/redis-cluster-monitor. При падении мастера, данная мониторилка выбирает нового мастера и посылает сигнал синхронизации с ним остальным серверам. Задача — уведомить фронтэнды о том, что мастер-сервер сменился. Собираюсь дописать мониторилку, чтобы она еще и слала уведомления и фронтэндам. Адрес мастер-сервера, вероятно будет храниться локально в файле.
На сколько правилен подобный подход? У кого был опыт постоения подобных систем, как обычно поступают, какие подводные камни?
Как извлечь N случайных неповторяющихся элементов из SET в Redis?
Есть SET c 1000 id, надо выбрать 3 случайных и неповторяющихся.
Решение «в лоб» — 3 раза сделать SRANDMEMBER, но нет гарантии, что не будет повторов.
Можно — контролировать повторы на уровне клиента и крутить цикл SRANDMEMBER до тех пор, пока полученный набор не будет уникальным, но это тоже несколько коряво.
Сортировать по случайной величине (что-то в духе SORT… BY RAND LIMIT 3 INTO… ) Redis не умеет.
В результате SORT… INTO… результирующий список будет типа LIST и сделать несколько раз SPOP оттуда нельзя.
Вдруг кто-то знает элегантный способ?
Стоит ли использовать Mongo?
Приветствую!
В последнее время все чаще слышу упоминания про NoSQL и MongoDB в частности. Тема меня заинтересовала, но вот пока не могу найти интересующей меня информации, поэтому спрошу здесь — наверняка уже многие успели поэкспериментировать, а может и разработать серьезные высоконагруженные приложения в связке с MongoDB.
Заранее предупрежу, если где-то я ошибся в отношении MongoDB — я не специально. Просто я с ней еще даже не пытался работать, а лишь почитывал статьи на Хабре, да те примеры, что лежат на оф.сайте.
Сейчас я занимаюсь разработкой тизерной сети. Задача, на первый взгляд кажущаяся тривиальной, на деле выходит довольно хитровыделанной в плане организации структуры БД. Огромное кол-во связей, множество таблиц-посредников для связей М-М и т.д… Чем меня привлекла идея MongoDB, так это своим принципом построения связей. Вопрос №1:
действительно ли работа с МонгоБД при наличии кучи связей менее затратна в плане ресурсов? Ну, хотя бы на простейшем примере (буду писать на «псевдо SQL») — выборка из 2 таблиц, связанных отношением М-М через промежуточную таблицу:
table sites(
id int primary key auto_increment,
url varchar
)
table categories(
id int primary key auto_increment,
name varchar
)
table sites_categories(
site_id int,
category_id int
)
Задача вывести список сайтов и категорий, в которых он есть:
SELECT * FROM sites
while(SITE = mysql_result...)
{
//отображаем данные сайта
SELECT * FROM categories WHERE id IN (SELECT category_id FROM sites_categories WHERE site_id = SITE)
//в цикле отображаем категории
}
Также меня интересует, можно ли работать одновременно с MySQL и MongoDB? Вернее, насколько это будет правильно? Полностью переносить БД на Монго не хочется, лишь отдельные, особо-хитрые участки, нагрузка на которых выше, чем хочется.
Также читал, что в MongoDB можно беспроблемно хранить файлы — действительно ли это так и что же будет лучше — хранить по-старинке в специальной папке с подкаталогами по именам/ид пользователей, или использовать MongoDB? (допустим, при таком раскладе: пользователей около 1к, у каждого 40-50 небольших картинок. картинки отдаются в кол-ве примерно 100-150 в минуту.
P.S.: прошу прощения за возможные неточности в вопросах, излишнюю или недосказанную информацию о нуждах и текущем положении дел, разработка структур БД — не мое основное достоинство…
Opensource база данных ScalaxyDB
Здравствуйте!
Есть ли здесь с++ разработчик, которые хотели бы присоединиться к opensource проекту нереляционной самобалансирующейся p2p базе данных ScalaxyDB?
Исходники: github.com/miolini/scalaxydb
Google Group: groups.google.com/group/scalaxydb
Способ хранения файлов: MySQL, NoSql или что-нибудь еще?
Здравствуйте.
Продумываю систему и встали следующие задачи. Необходимо:
1. Хранить около миллиона html фалов
2. Столько же текстовых файлов
3. zip, pdf файлы
4. Необходим поиск по текстовым и html файлам
Если это имеет значение, то имею некоторый опыт по использованию связки mysql+sphinx.
Масштабируемость нужна примерно до 10 миллионов html и столько же текстовых файлов.
Какие решения можете посоветовать?
1. Где и как лучше хранить html и txt файлы?
2. Где и как лучше хранить архивы и pdf?
3. Как хранят данные, к примеру, поисковые системы? Где почитать?
Чат на PHP: узкое место БД — как решить?
Есть задача организовать простой чат с веб-интерфейсом и полной историей на действующем сайте на самописном движке (PHP5.3.3/MySQL5.1). Гугление по существующим решениям ничего хорошего не дало, либо избыточно, либо производит ощущение «наколенной поделки» и чаще всего давно не поддерживается, да и хотелось бы иметь одну архитектуру и стиль кодирования. В общем принято решение реализовать самостоятельно. С кодированием особых проблем нет, прототип реализовали, но нагрузочное тестирование с разными вариантами индексов и таблиц показало, что при уже ~20 хостах «читателей» и одним «писателем» в секунду MySQL затыкается (VDS c 1Гб RAM, мускулу половина отдана, и 2ГГц проц, nginx+php-frpm под Debian) даже на денормализованной таблице, т. к. кэшированию средствами БД запросы не поддаются (фильтры у каждого «читателя» свои, ибо приват, фильтрация в серверном приложении вряд ли будет эффективней чем в БД, как мне кажется, а у клиента недопустима). А хотелось бы на этом «железе» хотя бы 40-50 держать помимо основной нагрузки. Что может помочь? Опыта «хайлоад» нет, возникли такие идеи:
— написать демона для чата на субдомене, чтобы читал в основном потоке из БД только при старте (последние N сообщений) или редких специфичных запросах, хранил их у себя в памяти процесса (убивая старые), а писал в БД только «логи» для следующего старта (тогда фильтрация будет эффективна, имхо, плюс её можно будет осуществлять опережающе и инкрементно, храня сами сообщения в едином пуле, а для каждого читателя добавлять в список ссылок на «его» сообщения при поступлении сообщения от «писателя» лично для него или публичного, и удалять их оттуда при прочтении)
— аналогичным образом задействовать мемкэш (хотя пока с трудом представляю как обеспечить целостность, до того только с файловыми кэшами работал, которые сами не «испаряются») для обычного PHP-обработчика (то есть чтобы куча воркеров имела доступ к общему пулу сообщений и инкрементным личным спискам ссылок на них между запросами)
— перевести чат на NoSQL СУБД (какую? главная задача эффективная фильтрация по паре полей последних записей, типа WHERE timestamp > {last_time} (или id>{last_id}) AND (recipient_id IS NULL OR recipient_id={user_id}) ORDER BY timestamp (или id) DESC LIMIT {max_records} )
Что стоит попробовать или ещё какие могут быть варианты? Демона писать не хочется, так как усложнит администрирование и сервера, и собственно чата (аналог IRC команд делать?), опыта работы с кэшем и NoSQL практически нет.
Посоветуйте базу данных (pure Java, Schema less, embedded, in memory)
Посоветуйте пожалуйста: pure Java, Schema less, embedded, in memory базу данных.
Чтобы использовать как кэш с возможностью поиска по свойствам объектов.
Ну или иные варианты как организовать такой кэш :)
Спасибо!
Теория: структура высоконагруженного сервиса?
Хотелось бы от хабралюдей узнать в чем мои суждения неверны. Итак, приступим-с.
Задача: построить сервис, с возможностью горизонтального масштабирования, который в будущем теоретически будет высоконагруженным.
Каковы мои размышления на тему, вопросы по каждому пункту прямо в нем:
— имеется домен (имя взято с потолка) hls.com
— у регистратора у этого домена прописано максимальное количество DNS серверов (6?), которые собственные и разбросаны по миру (имеет ли это смысл?)
— DNS зона содержит в себе максимальное количество A и AAAA записей (32?) дабы получить DNS round-robin.
— На каждом адресе, указанном в DNS, висит load-balancer (аппаратный или же софтовый? как load-balancer определяет какой сервер выдать, как он определяет самый менее нагруженный сервер?)
— Каждый load-balancer заведует неким количеством ngnix-серверов (или какой-то другой софт, если да, то какой? как ngnix может выбрать сервер самый менее нагруженный?)
— ngnix-сервер заведует неким количеством web-серверов, которые собственно дают контент.
— Каждый web-сервер имеет на машине Apache HTTP, PHP или Ruby и локальный memcached (или локальный не стоит?)
— За web-серверами стоят 2 вида баз данных — там где хранятся связи между объектами и собственно сами объекты. Все из них по условию должны уметь масштабироваться горизонтально.
— В качестве распределенного хранилища объектов используем что-то вроде memcacheDB или BigTable (или какую-то другую? т.е. у каждого объекта есть уникальный ключ, несущий в себе не только ID объекта как таковой но и информацию о типе объекта)
— В качестве распределенного хранилища связей нужно использовать какую-то БД на основе графа (правильно? если да, то какую?)
— Имеется также 2 набора memcached серверов которые кешируют запросы к обоим видам БД.
Хабралюди, мыслю ли я в правильном направлении? Что я не учел? Где почитать? Кто уже делал? Помогите просветлиться в этом.
Можно ли обойтись без Entity-Attribute-Value?
Необходимо сделать нечто, похожее на интернет-магазин. Проблема в выборе способа хранения информации о товарах, так как типов товаров более сотни и каждый из них обладает собственным наобором атрибутов.
Тот же Magento Commerce для этих целей использует EAV структуру, из-за которой селект-запросы сильно усложняются и работают не очень быстро. Пока единственная мысль — периодически преобразовывать EAV в нормальную таблицу, из которой и будут идти выборки. Есть ли более эффективный способ в рамках MySQL или PostgreSQL?
Также в процессе поиска ответа на этот вопрос не раз встретил мнение, что в этом случае стоит отказаться от реляционной базы и перейти на noSQL. Насколько это соответствует истине и будет ли это быстрее работать?
NoSQL СУБД для веб-сервера на VDS
Навеяно ответами к этому вопросу. Оказывается для MongoDB крайне желательно выделять отдельный сервер, т. к. память он отдавать не желает., что может быть чревато для других приложений.
В связи с этим вопрос — какую СУБД лучше поставить, чтобы её аппетиты до памяти можно было ограничивать. Желательно максимально близкую к Mongo, то есть свободная схема объектов/документов, но с разделением их на коллекции.
Спасибо.
Upd.: OS — Debian 6.0, nginx+php-fpm+passenger+mysql
система тегов на MongoDB
Можно ли из документов вида
{...,
tags: ['php','nosql',...]
}
… выбирать все уникальные значения массива tags одним запросом?
tags: ['php','nosql',...]
}