Чего я хочу для LiveStreet или HighLoad играет значение

Tips & tricks
Смысл этого топика не в том что бы изменить ход развития LiveStreet или отметить его недостатки — нет. LiveStreet была и будет системой ориентированной на широкие массы, поэтому требовать от нее большего я не в праве, но я могу изменять свои проекты, делать свои решения и предоставлять их на суд.

В данный момент мне бы хотелось поделится своими мыслями по поводу реализации части любимого движка работающей с данными и то как эту часть можно оптимизировать и привести к более производительному и логичному виду.

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

Redis(а может и Node.js)
Первое изменение которой я бы сделал в своем проекте — использовал Redis для хранения событий пользователей. Использование MySQL для таких вещей не самоубийсво, но все таки очень тормознутое решение нежели Redis, для которой шустрость второе имя. Ко всему прочему можно добавить возможность publish/subscribe, позволяющая в купе с node.js выводить уведомления такие же как в Вконтакте. Размышляя в этом направлении можно расширить границы использования этой БД. Для осуществления работы можно использовать библиотеку Rediska, разработанную с подачи нашего соотечественника.

Тем кто заинтересовался темой будет уютнее почитать подробности тут, чем читать обрывки вырезанных из текста абзацев — Redis.

MongoDB
Данных у нас много и все они хранятся в реляционной базе данных. Что если нам координально изменить парадигму хранения данных и использовать MongoDB. Выиграем мы и в скорости запросов и в скорости работы с данными продолжая использовать ORM, потому как в MongoDB оно организованно на уровне C++, а не эмулируются как сделанно в данный момент в LiveStreet. Но за это разработчикам стоит сказать отдельное спасибо, т.к это было действительно ценное решение ускоряющее разработку.

Подробности в виде презентации — Mongodb.

PS
Я просто показываю вам что вы можете сделать со своим LiveStreet и какой космос открыт перед вами :)

Если вы в этом шарите думаю все будут только рады перенять ваш опыт :)

36 комментариев

avatar
Присоединяюсь, работая с этими двумя БД, LS бы стал по настоящему HighLoad Ready. Части архитектуры можно было бы и перенести.
avatar
Насчет Редиса — согласен, т.к. его можно использовать не только, как кеш (с этим и Мемкешд неплохо справляется), но и как средство для логгирования. В общем случае это не особо нужно, но бывают ситуации, когда логов надо писать много.

А вот насчет координально изменить парадигму хранения данных и использовать MongoDB — это как-то чрезмерно кардинально и вряд ли оправдано
avatar
это просто мысли в слух или вы реально уперлись в проблемы с производительностью БД? я просто не знаю проектов на LS у которых БД на отдельном сервере. у меня в рамках одной виртуалки нормально все фурычит
avatar
веду к тому что если будет затык в рамках одного сервера, то можно будет вынести БД на отдельный сервер, а потом сделать кластер для БД, а потом…

вобщем не вижу пока проектов, которым это нужно.
avatar
У меня даже сфинкс с мемкешем на отдельных серверах, а бд ползёт по двум.
avatar
При этом нагрузки высокой как таковой нет.
avatar
кластер для БД — плохая, идея, ибо очень дорогое по стоимости владения решение. На самом деле, это очень редко действительно нужно. «Распаралелить» нагрузку на БД можно и более простыми способами. Но вообще самое разумное решение на данный момент — тупое наращивание железа единственного сервера до упора.

4-х процессорный сервер — это 16/24 ядра. 128Gb памяти. Многодисковые рейды. Это всё не особо дорого в наше время. А выжать из SQL сервера на такой машине можно чудовищно много.

мемкешем на отдельном сервере достаточно плохая идея, на самом деле. коммуникации по локальной сети — очень медленное дело. Чтобы было более понятно — вынимание объекта из локальной памяти процесса и вынимание того же объекта из memcached сервера на другой машине: производительность этих операций отличается на два порядка. Учитывая что SQL сервер тоже не дурак и дофига разного кэщирует в памяти (в том числе планы выполнения и результирующие множества) то есть много примеров когда вынесенный на отдельные сервера кэш вообще не приносил никакого эффекта. Вообщем кэгирование тонкая тема. memcached разрабатывался для LiveJournal чёрт знает когда, время много прошло с тех пор и эффективность этих подходов не столь однозначна сейчас.
avatar
Мы как-то уже осуждали в личке вроде-бы, что у меня нет привычки на каждый сервер для какой-то мелкой задачи делать новую инсталяцию софта, который можно промасштабировать и разделить по нескольким серверам.
В случае с мемкешем, сфинсом и т.д — у меня так-же. Есть более сложные вещи, за которые страшно. Например сетевые хранилища данных, подключенные к серверам виртуализации.
Бд разделено в первую очередь потому, что у нас отдельный сервер, с которого происходит резервное копирование и с минимальным расходом ресурсов и помехам в работе самих ресурсов. Ныне я даже представить боюсь, как-бы мне приходилось бэкапить дофига инсталяций отдельно. Всё что я накатываю на вебсервера — snmpd, nginx+php-fpm, bacula-fd. Всё. Больше и не надо зачастую. Насчёт кучи железа — его мало. Для простых вебсерверов, почты и т.д стоят по большей части виртуальные машины. Проигрыш в производительности — он выходит всё-же настолько мал, что просто пофигу, поверьте. :)
avatar
Зависит от задачи очень сильно. БД стоит выносить на отдельный сервер — это бесспорно. Но тут причина в в том что самым узким местом БД является скорость подсистемы ввода-вывода. Т.е. сервер предназначенный для БД физически должен иметь иную кофигурцию, чем скажем сервер на котором работает PHP (для которого самое узкое место — CPU). А вот выносить кэш… это вопрос сложный.
avatar
Так и есть. Кто спорит. :)
avatar
Кеширование — не панацея от всех бед. Если взять небольшой пример работы с высокой плотностью запросов постоянно изменяющихся данных (чтобы далеко не ходить — плагин TalkBell), то становится ясно, что MySQL тут катастрофически отстает.
avatar
Я вообще не люблю MySQL и считаю его довольно отстойным выбором. Но из бесплатного он лучший по совокупности достоинств. Но сравнительно с коммерческими решениями он сильно проигрывает. Люди не просто так 1000-и баксов платят за лицензии коммерческих SQL серверов. Есть там резоны, и в частности в гораздо более умелом использовании железа.
avatar
Ещё можно посмотреть на PostgreSQL, но он только для специфического вида задач годится.
avatar
Субъективно: PostgreSQL богаче функционально, а вот с точки зрения общей производительности хуже MySql. Но это очень трудно оценить объективно, конечно.
avatar
с точки зрения общей производительности хуже MySql
— Угум-с. Но на заточенных под хранение определённых специфических типов данных, таких, как полигоны и прочее, она зело люба и прельстива.
avatar
что за проект? какие нагрузки?
avatar
Смотря о чём говорить. Если об ЛС, то их несколько (проектов) и все разные.
avatar
а о чем вы тут говорили livestreet.ru/blog/tips_and_tricks/13181.html#comment243150?

конкретика интересует. или вы несколько сайтов на кластере держите?
avatar
Все сайты, почта, сфинкс, кеш на разных виртуальных машинах.
Разнесено так всё для уменьшения расхода ресурсов, сокращения лишних рабочих процессов на серверах и по соображениям безопасности. Плюс зачем для овер X ресурсов делать столько-же инсталяций дополнительного программного обеспечения. Ведь поддерживать всё это в актуальном виде не особо просто. А кроме поддержки самих инсталяций, ведь ещё надо выпилить мониторинг всех этих вещей. (Мы мониторим на доступность, нагрузку, и т.д всё, что наверно только возможно. Даже мониторинг мониторинга. :)
Благодаря этому практически о любой проблеме, даже мелкой узнаём в течении нескольких минут). На что тоже может уйти дофига времени. Для мускла настроена репликация. Первый сервер используется для работы всех ресурсов с бд, второй используется только для резервного копирования. Так-же мускл стоит не на виртуальных машинах, а на физ. тачках.
Тормоза из-за передачи кучи данных по сети — не особо проблематично, если грамотно спроектировать всю инфраструктуру.
Но у нас даже дошло до того, что сервера виртуализации используют удалённые хранилища данных. А это более серьёзная и тонкая штука.
Благо всё дело происходит в провайдинге, а не фиг знает где.

Ну как-то так. Надеюсь достаточно рассказал. Имхо, но в больших техподробностях не могу, по причине надеюсь сами понимаете, конфиденциальности инфраструктуры. :)
avatar
я понял. это известное решение в плане масштабирование, но плохое в плане отказоустойчивости
avatar
Опять-же, смотря как всё построено.
У нас вот в случае отказа например сервера виртуализации, система может перенести виртуальные машины на другой сервер виртуализации.
В случае падения одной виртуальной машины, может отвалится на время часть определённого сервиса, но не весь.
Вообще, в отказоустойчивости я мало разбирался. Да и сам не полностью отвечаю за всю эту инфраструктуру. Времени не хватает вникнуть…
avatar
я просто не знаю проектов на LS у которых БД на отдельном сервере
Я знаю такие. Но это не значит, конечно, что пора на Монго переходить :)
avatar
Немного офтопну, но по теме. Есть такой сервер с ихним апачем, пока все устраевает — работает быстро, но, почемуто, когда пишу siege -c 120 с работы на сервер и смотрю htop, то везде 100% нагрузка, сайт сразу гораздо медленнее работает, 1 раз даже было отвалился апач почему то. Стоит ли сменить апач на голый Nginx + PhpFPM?
avatar
# prefork MPM
…
<IfModule mpm_prefork_module>
StartServers 64
MinSpareServers 50
MaxSpareServers 50
MaxClients 256
MaxRequestsPerChild 4000
avatar
можно линки? здесь или в личку ;)
avatar
Что бы не отвечать конкретно одному, отвечу тут и поразмытие :)

NoSQL решения намного производительнее.
MongoDB позволяет для главной страницы вместо 10 запросов сделать 1-2, отсюда и слова о смене парадигмы.
При использовании ленты(feed) необходимо от 20-30 запросов к бд.

Обобщив все это можно уверенно сказать что лс к highload подготовлен не на 100% и даже не на 50%.
Но как я говорил в сабже это не самоцель лс.

Я не упирался в проблемы с производительностью если не считать что при постоянной работе с летной большого числа пользователей получается не очень шустро. Лс не совсем готова для оптимальной работы с активностью, лентой(а ля новостей вконтакте).

И это просто небольшие эксперименты и ориентация на то что столкнусь в будем с высокими нагрузками. Нужно же развиваться :)
avatar
Мой тормоз — это Smarty!
avatar
А что для вас высокие нагрузки, хотелось бы спросить? Просто если у вас такой трафик что один сервер со всем не справляется найти $60 в месяц на ещё один выделенный сервер для MySql не должно быть проблемой. Плюс, есть очень много сравнительно дешёвых приёмов чтобы снять нагрузку. те же nginx с memcached или скажем применение CDN.
avatar
Просто у меня отношение к livestreet не как к cms, а как к фреймворку и проекты я пишу с нуля используя по необходимости те или иные существующие наработки, а уж если разрабатывать с испльзованием ORM то тот же модуль топиков становится короче раз в 20, а то и больше. Поэтому смена парадигмы не такая уж трудно досягаемая цель — всего то переписать ModuleORM.

Ну и естественно когда речь идет об обычных блогах далеко идти не надо, в лс все есть из коробки и кроме шаринга ему ничего и не требуется.

Просто как я уже написал выше цели ставятся высокие и готовность к хайлоаду перспективнее закладывается на раннем этапе. Планы до 10кк просмотров и международный уровень. Поживем увидем, но мы в себя верим :)
avatar
Я просто имею дело с системой которая на пиках испытывает нагрузки где-то под 100 запросов сложных динамических страниц в секунду (т.е. без учета всякой статики) и всё это без проблем крутится в рамках 5-и серверов. один nginx со всей статикой(причем этот сервак не загружен фактически никак), одна база(сервер несколько дороже остальных из-за навороченной дисковой подсистемы) и три веб сервака между которыми nginx балансирует нагрузку. Железо совершенно рядовое (и уже ему больше трех лет железу этому). там не PHP и не MySQL но база тоже SQL. Исходя из моего опыта скажу вам что цена аренды сервака уже никакой роли не играет там. Там наибольшая проблема — траффик.
avatar
Спасибо, очень интересный опыт!
Но если есть возможности оптимизировать систему на уровне архитектуры это стоит делать, естественно когда это не обходится дороже оптимизации на физическом уровне.
avatar
Лет 15 назад всё что связано с серверами, трафиком и северным софтом стоило настолько дорого и было столь ограниченным, что имели смысл практически любые оптимизации кода.

Очень сильно изменили ситуацию массовые 64-bit, дешевая память и некоторые появившиеся бесплатные/дешёвые софтины и сервисы. Такие штуки как NGINX или Amazon CloudFront изменили мир.

Сейчас картина такая, что экстенсивная оптимизация (т.е. наращивание железа) очень часто наиболее дешёвый и эффективный путь. Оптимизация кода это очень дорогое удовольствие из-за стоимости разработчиков.
avatar
Идеи понравились.
avatar
«если Вы не знаете, как это использовать, то это Вам не надо»
Если Вы считаете, что использование редиса — это круто, то Вы явно ошибаетесь.
avatar
Вообще я не думал о крутости когда это писал. Redis держит бд в оперативке и имеет бесспорное преимущество для организации раздела Активности если говорить о livestreet. Лично я его использую для реализации рекомендаций, аналогично его использует и rabmler.ru для рекомендации новостей(работа по теме, не моя), где можно подчеркнуть все достоинства NoSQL и Redis в частности для реализации данного направления.
avatar
Полностью поддерживаю топикстартера.
Разве что от себя добавлю, что не обязательно «распыляться» на пару решений. А вот отход от традиционного MySQL и миграция в MongoDB была бы очень кстати.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.