В последнее время все чаще слышу упоминания про 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.: прошу прощения за возможные неточности в вопросах, излишнюю или недосказанную информацию о нуждах и текущем положении дел, разработка структур БД — не мое основное достоинство…
Снова оффтопик:
Вообще я дорабатывал тизерную сеть одну… Там нет таргетинга но нормально отрабатывало около 90 млн показов тизеров в сутки (сейчас обороты спали примерно до 50 млн). Все это крутится на одном единственном довольно мощном сервере (и второй сервер — только картинки).
Там все данные о тизерах, забаненных айпишниках, ценой за показ/клик забираются из мемкеша. Если в мемкеше каких то данных почему-то нет (Eviction например или холодный старт), то только тогда забирается из БД и кладется сразу обратно в мемкеш. Статистика за последнюю минуту тоже кладется в мемкеш и раз в минуту данные из него собираются, обсчитываются и обобщенная статистика кладется в MySQL. Т.е. фактически для открутки тизеров БД вообще не трогается.
(До мемкеша вообще использовали файловую систему для этих данных — летало почти так же как на мемкеше)
Но вам может не подойти потому что не представляю толком как там можно таргетинг реализовать.
Метод его организации практически не изменяет полезности вашего комментария — просто локально хранятся данные диапазонов IP, а при выборке тизеров на показ добавляется +1 условие, чтобы IP клиента был в диапазоне кампании, из которой выбираются тизеры. Если интересно — могу в личке подробнее рассказать :)
По поводу идеи мемкеша — спасибо, планировалось перед запуском добавить работу с ним.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.