LS при работе с MySQL прожорлив на ресурсы и это можно исправить внедрив Mongo DB для увелечения скорости запросов и обработку данных.
Мне вот к примеру надо реализовать такую архитектуру для realtime.
Основное хранилище — это обычный стек РНР+NOSQL БД nginx+php-fpm это все стандартно.
Дополнительно:
— поиск реализуется отдельным сервером на базе elasticsearch (http://www.elasticsearch.org/).
— реалтайм реализуем на базе SockJS (серверная часть, для начала — github.com/sockjs/sockjs-node на базе NodeJS, если сильно упирается в производительность, что реально очень сложно — можно перенести эту часть потом на pypy — у сокжс серверные части независимы, например питоновская вот github.com/mrjoes/sockjs-tornado, основан выбор на статье habrahabr.ru/post/134822/). Клиентская часть вот — github.com/sockjs/sockjs-client
Это обеспечит поддержку стриминга и унифицированого протокола для всех браузеров.
— redis — используем как очень умный кеш, например, для хранения числа новых сообщений/общего количества, событий пользователя и т.д. тоесть таких данных которые постоянно запрашиваются чтобы не лазить в базу. Кроме этого, редис выполняет роль основного брокера для связи всех узлов — главный мастер сервер ставим рядом с основным приложением, слейвы стоят на комет-сервере и на поисковой ноде.
Теперь про связи: основное приложение принимает запросы, например, сравнительно редкие типа регистрации и т.п. через обычный ajax, далее записав и обработав, она разадет через PUBLISH/SUBSCRIBE механизм Redis-а эту информацию всем другим узлам. Все создания элементов (новые посты и т.п.) идут обычным аяксом в основное приложение. Оно обрабатывает и записывает в базу данных, потом раздает эту информацию другим.
Редис, установленный рядом с сокжс, получает пакет (json) от основного сервера, где, например, новое сообщение и список идентификаторов блогов, кому это сообщение отправить — и раздает это всем, кто подключен. Таким образом разделение логики — основное приложение только формирует указание кому раздать, но не знает кто онлайн и каким образом они подключены, а сокжс сервер реалтайма знает кто подключен но обезличено, только как транспорты и ид, он получает сразу сформированый список кому отправить и само сообщение, которое без обработки сразу раздает.
Вторым клиентом для сообщений будет поисковый сервер — возможно там надо будет написать небольшой скрипт клиента, пару строк на РНР или лучше ноде, хотя любой язык. Он также принимает сообщения через редис и ложит его, скармливая поисковому серверу еластиксерчу. Таким образом, по факту, в еластиксерче будет хранится документ-дубликат поста, со всеми данными, которых достаточно, чтобы когда идет поиск — все данные сразу брать из поискового индекса, без обращения к основной базе данных.
Структура БД немного изменена, но имеется конвертер с LS 1.0.2. И, кстати, о базе – библиотека DbSimple была обновлена, и теперь по умолчанию используется MySQLi с «ленивым» подключением, а также есть поддержка PDO, PostgreSQL, MS SQL и др.
В общем я за решение, как у гугл докс, trilldy, medium. Фокус на визуализацию контента, удобство редактирования/форматирования. Всё для людей, как говорится.
Есть две технологии: ContentEditable и написанное с нуля. Первое — поддерживаемое на уровне браузера решение, т.е. тегу устанавливается это свойство и пользователь может писать прямо в теги текст, форматировать его, все это браузер на лету преобразует в html и получается псевдо MS Word. Второе — это самописные решения, типо как у Google Docs к примеру т.е. эмулируется мигающий курсор, по нажатию кнопок влево-вправа, мигающая палочка перемещается на экране на сколько то пикселов влево-вправо, по нажатию на букву создается объект буква и вставляется в html дерево самим скриптом Гугла, а не браузером. Какие преимущества: 1) полный контроль над всем процессом. 2) есть вполне иерархическая модель объекты-представление, т.е. в памяти у них массив с текстами, ссылками на картинки, ссылками на видео, еще что-то, они сами на лету генерят нужный html, который они понимают и умеют обрабатывать и вставляют его в страницу. Вот про такой редактор я и толкую, чтобы можно было бы вставлять свои объекты, от опросов до файлов в любом месте, делать ресайз и кроп медиа контента в два щелчка, вот гляньте к примеру на этот редактор в «картинках» www.behance.net/gallery/Medium-Editor-Exploration/7281451 Предпросмотр в реальном времени, это когда я набираю текст/форматирую и вижу результат сразу, чтобы не нажимать сто раз предпросмотр, чтобы посмотреть, что я там на редактировал.
https://docs.google.com/file/d/1AXVcecq7N4ymZd2EndjPpX7MA7Zdx_2d7F_yisSPjQIVB9u22s_CmbKElHxk/edit?usp=sharing
Мне вот к примеру надо реализовать такую архитектуру для realtime.
Основное хранилище — это обычный стек РНР+NOSQL БД nginx+php-fpm это все стандартно.
Дополнительно:
— поиск реализуется отдельным сервером на базе elasticsearch (http://www.elasticsearch.org/).
— реалтайм реализуем на базе SockJS (серверная часть, для начала — github.com/sockjs/sockjs-node на базе NodeJS, если сильно упирается в производительность, что реально очень сложно — можно перенести эту часть потом на pypy — у сокжс серверные части независимы, например питоновская вот github.com/mrjoes/sockjs-tornado, основан выбор на статье habrahabr.ru/post/134822/). Клиентская часть вот — github.com/sockjs/sockjs-client
Это обеспечит поддержку стриминга и унифицированого протокола для всех браузеров.
— redis — используем как очень умный кеш, например, для хранения числа новых сообщений/общего количества, событий пользователя и т.д. тоесть таких данных которые постоянно запрашиваются чтобы не лазить в базу. Кроме этого, редис выполняет роль основного брокера для связи всех узлов — главный мастер сервер ставим рядом с основным приложением, слейвы стоят на комет-сервере и на поисковой ноде.
Теперь про связи: основное приложение принимает запросы, например, сравнительно редкие типа регистрации и т.п. через обычный ajax, далее записав и обработав, она разадет через PUBLISH/SUBSCRIBE механизм Redis-а эту информацию всем другим узлам. Все создания элементов (новые посты и т.п.) идут обычным аяксом в основное приложение. Оно обрабатывает и записывает в базу данных, потом раздает эту информацию другим.
Редис, установленный рядом с сокжс, получает пакет (json) от основного сервера, где, например, новое сообщение и список идентификаторов блогов, кому это сообщение отправить — и раздает это всем, кто подключен. Таким образом разделение логики — основное приложение только формирует указание кому раздать, но не знает кто онлайн и каким образом они подключены, а сокжс сервер реалтайма знает кто подключен но обезличено, только как транспорты и ид, он получает сразу сформированый список кому отправить и само сообщение, которое без обработки сразу раздает.
Вторым клиентом для сообщений будет поисковый сервер — возможно там надо будет написать небольшой скрипт клиента, пару строк на РНР или лучше ноде, хотя любой язык. Он также принимает сообщения через редис и ложит его, скармливая поисковому серверу еластиксерчу. Таким образом, по факту, в еластиксерче будет хранится документ-дубликат поста, со всеми данными, которых достаточно, чтобы когда идет поиск — все данные сразу брать из поискового индекса, без обращения к основной базе данных.
по мотивам этого топика
http://livestreet.ru/blog/tips_and_tricks/13181.html
Посмотрите, как классно работает этот редактор на сайте trilldy.com (не ленитесь зарегистрироваться)
И также хотелось бы, чтобы предпросмотр работал в реальном времени, это ведь не сложно? правда?