Кешируй в бд инфу по группам. Затем ты будешь запрашивать инфу по группам: бегаешь по айдишникам, ищешь данные из редиски или мемкешеда, чего нет - берёшь из бд, сортируешь в RAM и выдаёшь. Можешь прекешировать всю выборку. Выиграешь ощутимо, если БД будет толстая, но она не будет :)

Не парься, кешинг здесь справедлив и нужен, хоть и не на долгое время. Но не по нотификациям. Нотификации ты прочитал - удалил, а остальное - тяни из общей базы. Я всё-таки думаю что имеет смысл не разделять инфу в целом, а только нотификации.

Окей. Значит у тебя есть таблица с подписками и таблица с веб-оповещениями. Для сбора данных тебе нужен процесс в бекграунде - можешь хоть на сях написать, его задача - взять данные из подписок, запросить из АПИ и протолкнуть результат в оповещения. Такую фишку можно писать хоть на чём, но из соображений того, что ты юзаешь вызовы к АПИ, то встаёт мысль о том, что стоит применить асинхронщину - нода для такого была и создана. Посмотри в сторону Kue. Далее, если предположить что это две таблицы в БД, то дела плохи, узкое место - БД. Можно иметь по таблице на юзера, а можно - подумать использовать другие БД. Как вариант, взять монгу и пихать нотификации в один докемент, ассоциированный с юзером. Размер дока - 16мб, хватит за глаза, если будешь хранить ссылку, название, ещё что. Но тебе в любом случае нужно будет хранить всю это инфу долгое время, чтобы даже после получения уведомления, человек мог увидеть какие последние альбомы вышли, так? Тогда имеет смысл хранить большую бд аль

ТС, вообще не понятно что у тебя по сути должно быть и где именно боттлнек. Если ты не дашь инфы по тому, где у тебя слабые места, то и искать инструмент стрёмно - никто не даст тебе нужного результата. Как ты вообще работаешь с данными? Собираешь раз в час все события по рсс с других сайтов и рассылаешь письма пользователям? Или может ты просто имеешь веб-приложение, что по аяксу долбит и выдаёт свежую инфу? Или хранишь в бд все записи о выходах альбовом и по запросу просто выдаёшь все данные? Фреймворк ЛЮБОЙ подойдёт - главное чтобы ты в нём не утонул, пока будешь изучать. У ноды только плюс - вебсокеты "искаропки" и без особых шаманств. Опиши что там у тебя происходит на бекенде, может подскажу что.

Примерно такой вывод я и сделал. Изучу ещё на досуге, может и решимся, но, увы, не сейчас. Спасибо!

О, спасибо большое! Сейчас понимаю что объёмы и нагрузки будут не такие, так что пока хватит монги. Но про оракл надо будет всё изучить, тему эту я и правда совсем не знаю.

Я знаю много баз данных, но именно работал и правда не со многими: кассандра, мускуль, постгре, мариа, редис, мемкешед, монго. Монго я знаю хорошо, хотя шардонг и репикацию я и правда не использовал - а сейчас придётся. Вопросы я обычно задаю не от незнания, а от желания узнать мнение третьей стороны :) Да и по сути основным вопросом было "а будет ли толк сейчас думать о оракл?"

С БД мне самому мало придётся работать - есть жавакодер, что хочет заюзать оракл, вот только мне нужно всё-равно будет с этим работать и думать о предоставлении ресурсов, в т. ч. финансовых. Пока чувствуется что это слишком мощно. А вот монга - она в любом случае понадобится.

Пока нет, но и объёмы не сразу будут такие большие. Точнее, будут, но в будущем можно перейти на что-то другое. Сейчас всё в виде стартапа и в распоряжении есть разве что впски digitalocean.

Примеры привести сейчас не смогу уже, года 1.5 прошло с того момента, когда перевели на монгу. Там не в поиске по тексту были проблемы, а в селектах. Монга выиграла и до сих пор выдерживает(данных там миллионов 60 уже). Может быть тонко настроив постргре, мы бы смогли заставить его работать так же шустро(я почти уверен что могли бы сильно ускорить), но не хотелось с этим возиться сильно, ведь была монга - хорошая бд, которая очень хорошо подходила под наши нужды. А за ссылку спасибо огромное! Интересный подход, но вот только я не нашёл как там создаются н-граммы, как пополняется сам индекс. Он сам как-то умеет?

Ну да, это и есть вариант с "фантомом", который я рассматриваю. За ссылки отдельное спасибо!

Можешь чуть аргументировать ответ? Мне интересно понять логику выбора )

Поиск по тексту(до 255 символов), но и постгре с такими объёмами не справится(справится, но ресурсов нужно дофига), и сфинкс не сможет справляться, чую я.

Увы, постгре слишком слаба на больших, даже простых данных. Там, где он тянет простейшие выборки с 1млн записей, монга тянет раз в 20 больше. Это примерные цифры, запросы строились очень давно. Но разница реально большая. Если юзать отдельный поисковик, то может стоит задуматься о более оптимальном хранилище, вроде HBase? Но в любом случае в отдельном поисковике будет большая база и трудно будет справляться.

Да это правда, конечно, но пока нет необходимости для такого. Но почему оракл? Только ли из-за объёма данных и скорость агрегаций/выборок? Что же по полнотекстовому поиску?

Да, думаю в localstorage пихать всё нужное и не париться. Вариант, который сгладит неровность, хотя и не идеально - объекты придётся обновлять там часто, да и не факт что они не изменятся на сервере - придётся перезагружать их всё-равно. Короче, придётся потратить время на это, как и на phantomjs, если делать SPA. Вынести можно было бы, да вот только лендинг является слишком функциональным - по сути он и будет инструментом, так что никак, увы.

Мне может пригодиться это разве что если он умеет одну из двух вещей: 1) Быструю агрегацию(для ускорения суммирования статистических данных по объектам), тогда статистику можно запихнуть туда 2) Сортировку+фильтрацию+быструю запись без лока(для хранения кешированных данных по объектам или, может быть, даже самих объектов), ибо всё это крайне важно.

1) информация о объектах, постгре. Простые структуры, на самом деле. 2) статистика, монга (структуры, представленные выше). Число структур = число дней, за которое ведётся статистика * число объектов 3) Кешированная сумма статистических данных, монга/постгре(не определился делать ли коллекцию в монге, либо пихать в информацию о объекте(см п.1)). Равно числу объектов. Раз в 30 минут идёт просто сбор накопленных данных с другого сервера(имеется только API, данные можно собрать только за последние дни). Так что допускается даже если статистика будет отсутствовать за последние дня 4, её можно пересобрать. Для актуальности общей картины был выбран интервал в 30 минут. Что по обновлению, то нужно будет сравнивать изменилась ли статистика, а тогда нужно будет делать запрос на получение предыдущей статистики из монги. В теории, можно и правда минимизировать число объектов, для которых статистика обновилась, таким вот способом. Подумаю на этот счёт, огромное спасибо. А будет ли от C

У меня больше проблема в том, как сихронизировать кеширование суммы по статистике, как оптимизовать его. Но 200млн записей это круто... У меня простая виртуалка с 40млн дохла и постгре уже мог по минут 10-30 выполнять простые запросы. Хотя уже не помню, может налажал там много.

Можно предположить что влезет на одну машинку, шардировать - уже немного другой вопрос. Разница с влезет/не влезет только в том, как оно часто будет лезть в своп и хватит ли скорости SSD'шек, как я понимаю. А это всё можно регулировать. Дело в том, что сейчас интересует как бы именно в коде и бд сделать так, чтобы без лишних проблем можно было скалироваться. Предположим что пока только вертикально. Со статистикой всё просто: мы читаем только для того, чтобы суммировать данные за промежуток времени(одни и те же), а если кешировать, то обращение будет только к кешу. Раз в 30 минут идёт обращение на запись(апдейт с апсеротом(инсерт при отсутствии записи)) в монгу одной-двух записей статистики на каждый объект. На сколько я знаю, в Постгре каждый запрос лочит соединение, пока не будет выполнен(хотя вот в транзакциях слышал что инсерты и апдейты проходят без ожидания, но зато при коммите придётся ждать), когда монга просто съедает их и кидает в очередь, как я понимаю. Здесь получается

Структура примерно такая: AID: LongInt BID: LongInt Stat1: Int Stat2: Int Stat3: Int Day: DateTime(JS-объект, надо смотреть как хранится он в BSON). Собственно, вот такая вот статистика. Но окей, а что скажешь о постгре? Погуглю конечно, но не кажется мне что там можно хранить такие объёмы. Может тогда какую ещё БД посоветуешь?

Если я правильно понял, то это именно на случай, если данные в монгу и будут класться. Проблема то в том, что нужно класть в постгре. Конечно, как вариант, можно кешировать в монгу(будет две сущности для каждого объекта, при этом работа будет идти со второй, кешем, что мне не очень нравится).

При сортировке и фильтрации мы же будем обязаны иметь всю эту информацию, иначе никак. Думаешь что если статистику хранить в постгре, то всё будет быстрее? На триггерах можно, кстати, попробовать, но эффективно ли это всё будет? Пугает что если делать постгре, то с 3млн записями, за год, накопится 1 миллиард 95 миллионов записей. Ходят слухи что монга с таким справится, а вот постгре - нет. Правду ли молвят?

>в Rails - это соответствующие gems. Лол! Как ты можешь говорить на эту тему, если ты считаешь что Django Generics это тоже самое, что и Ruby Gems? Если же ты говоришь о том, что есть какой-то гем, который делает то, что делают дженерики в рельсах - давай его в студию. Только и это ничего не изменит, ведь все Rails-разработчики пишут с нуля. Да, я знаю достаточно Rails-разработчиков и понимаю что да как. «дженерики - фишка в Django которая откинула на несколько лет назад RoR» Нет, конечно. Это не так. Просто концепция была лучше и додумывала идею Rails, но сам Django не так и далеко ушёл от RoR. «Но это, не так.» Нельзя не признать что дженерики гениальны, что они сильно улучшают разработку и их отсутствие в Rails есть странная тенденция, говорящая только о застое в их развитии.

http://comments.gmane.org/gmane.comp.window-managers.awesome/6200 Похожая проблема, решённая костылём.