Просто по опыту скажу, что мемкешед более подходящее решение, так как сам написал пару оберток к существующим key/value (Sophia & Tokyo). Скажу больше, у нас в компании большинство демонов общаются с фронтэндом используя мемкешовый протокол. А недостаточную функциональность просто расширяем, добавляя префикс к ключам, или иным способом.
Например мультидел для ключей 123,456 и 789 можно реализовать так: delete 123,456,789
в клиент передаем строку «123,456,789» которая не противоречит концепции ключа.
Принципиально, можно поддерживать два и более протоколов, как реализовано, например, в TokyoTyrant или тот же мемкеш поддерживает текстовый и бинарный протокол.
Ну, как показывает практика, сама libmysql написана через Ж..., и для её использования в много-тредовом режиме приходится делать танцы с бубнами. Багрепорты не помогают…
>Сам пример
все хорошо, но я бы сперва перед описанием примера описал бы, как будет организована асинхронная обработка в целом,
для более понятного восприятия, а потом перешел бы уже к деталям. Когда я был студентом, нас учили писать научные работы (статья мало чем отличается от научной работы) по следующему плану, пригодится в будущем ;):
— введение в проблему,
— если есть то обзор существующих решений
— описание решения проблемы в целом
— частные описания и конкретные предложения, действия и т.д
— возможные выводы и заключение
Данный комментарий прошу не считать как критику, а как пожелание в дальнейшей работе
Если приглядеться, то большинство авторов статей с рейтингом придерживается такого плана.
Очень было бы хорошо выложить проект на гитхабе, а здесь дать ссылку
чтоб иметь полное представление о модуле.
А так… если что-то не учел, то ничего не получится и статья ушла в карзину.
>Я использовал для компиляции и настройки VS2010.
Не единым окном живет человечество, многие разработчики седят под линуксом или иной осью, по этому хорошо бы как минимум дать ссылку на компилирование под другие ОС
> Да, в наш век отказ от пищи — намного более лёгкий пост, чем отказ от технологий
легко… был в Турции, почти 100% отказ от технологий (роуминг дорогой, наличка, интернет нафиг не нужен...). и если бы была возможность 30 дней или 45-ть вместо 15-ти, я бы не задумываясь их продлил.
Очереди мы используем, но уже внутри процеса. Ну, во первых у нас нагрузка не такая, как у вас и масштабироваться не нужно. Одни поток принимает данные и распихивает его по очередям. Другие потоки читают свои очереди и делают соответствующие пуши на службы гугла и эпла. Один поток слушает (принимает) эпл нотификации, а еще один отвечает за статистику и данные (пишет в БД). Практически тоже, что и у вас… только масштабы меньше :)
В общем все очень интересно…
да, сам демон написан на сях…
исторически так сложилось, что у нас вся разработка преимущественно на си, есть питон и перл.
общение между бэкендом и демонами преимущественно осуществляется по мемкешовому протоколу. В этом свои плюсы — отладка, не нужно писать собственных клиентов…
написал один типовой демон и потом теражируй его, вписывая новый функционал
В нашем проекте ключевым сервисом является сервер обмена сообщениями. Рассылкой уведомлений о новом сообщении занимается отдельный демон. Демон хранит состояние клиента и некоторые данные. У нас есть следующие типы клиентов: Мобильный IOs, Android & WEB. Пуш уведомления на мобильные клиенты рассылаются через API Apple Push Notification Service & Google Cloud Messaging. Уведомление WEB клиентов происходит через флеш. Флеш открывает постоянное соединение с демоном на 80 порту, и при появлении нового события получает порцию JSON, который парсится и передаётся в кэллбэк JS, а тот в свою очередь изменяет HTML.
> Разве MyISAM не быстрее на чтение?
если его постоянно не лочить :)
>Да и вообще все это лирика и холивар без хорошей конкретизации задачи.
что верно, то верно
>Сами разработчики рекомендуют, как минимум, 3 сервера для создания кластера.
с Кассандрой не путаешь? которая разрабатывалось как чисто кластерное решение с дублированием информации.
и воввсе не обязательно отказоустойчивость… Монга интересна сама по себе и как кластеное, и как серверное решение.
Если вдруг такое случится и станет не хватать скорости или функциональности MongoDB — ничто не помешает использовать MySQL в качестве кэширующей прослойки / индекса для данных — один раз настроить и забыть.
Все более менее хорошо (есть пара дискуссионных мест, но нет времени на холливар), но последняя фраза бред какой-то… хотите использовать кеширующий индекс — используйте тогда сфинкс.
тут есть много разных предложений на дороботку по производительности. У Монги один недостаток — это общий лок на коллекцию.
Например мультидел для ключей 123,456 и 789 можно реализовать так:
delete 123,456,789в клиент передаем строку «123,456,789» которая не противоречит концепции ключа.
Принципиально, можно поддерживать два и более протоколов, как реализовано, например, в TokyoTyrant или тот же мемкеш поддерживает текстовый и бинарный протокол.
На мой взгляд, было бы очень логично использовать мемкешовый протокол. Есть куча готовых клиентов.
Хотя в проектах можно использовать и курл…
спаисбо за разработку…
как говорится «век живи — век учись»
а вообще-то ман в руки и с флагом по жизни!
спасибо за статью
интересно, а с каких пор в маил-ру есть РНР-ные проекты?
все хорошо, но я бы сперва перед описанием примера описал бы, как будет организована асинхронная обработка в целом,
для более понятного восприятия, а потом перешел бы уже к деталям. Когда я был студентом, нас учили писать научные работы (статья мало чем отличается от научной работы) по следующему плану, пригодится в будущем ;):
— введение в проблему,
— если есть то обзор существующих решений
— описание решения проблемы в целом
— частные описания и конкретные предложения, действия и т.д
— возможные выводы и заключение
Данный комментарий прошу не считать как критику, а как пожелание в дальнейшей работе
Если приглядеться, то большинство авторов статей с рейтингом придерживается такого плана.
В целом статья полезная, спасибо.
чтоб иметь полное представление о модуле.
А так… если что-то не учел, то ничего не получится и статья ушла в карзину.
>Я использовал для компиляции и настройки VS2010.
Не единым окном живет человечество, многие разработчики седят под линуксом или иной осью, по этому хорошо бы как минимум дать ссылку на компилирование под другие ОС
легко… был в Турции, почти 100% отказ от технологий (роуминг дорогой, наличка, интернет нафиг не нужен...). и если бы была возможность 30 дней или 45-ть вместо 15-ти, я бы не задумываясь их продлил.
В общем все очень интересно…
нагрузка 3 млн сообщ в день
исторически так сложилось, что у нас вся разработка преимущественно на си, есть питон и перл.
общение между бэкендом и демонами преимущественно осуществляется по мемкешовому протоколу. В этом свои плюсы — отладка, не нужно писать собственных клиентов…
написал один типовой демон и потом теражируй его, вписывая новый функционал
если его постоянно не лочить :)
>Да и вообще все это лирика и холивар без хорошей конкретизации задачи.
что верно, то верно
с Кассандрой не путаешь? которая разрабатывалось как чисто кластерное решение с дублированием информации.
и воввсе не обязательно отказоустойчивость… Монга интересна сама по себе и как кластеное, и как серверное решение.
blog.ulf-wendel.de/2013/mysql-5-7-sql-functions-for-json-udf/
жаль что не нативные, но и в этом тоже есть свой плюс.
хорошая новость… но мы ушли с версии где-то 2.3
>Могу ошибиться, но разве MyISAM не блокируется на таблицу (читай как коллекцию)?
а кто-то из тех, кому нужна производительность, пользуется MyISAM?
Все более менее хорошо (есть пара дискуссионных мест, но нет времени на холливар), но последняя фраза бред какой-то… хотите использовать кеширующий индекс — используйте тогда сфинкс.
тут есть много разных предложений на дороботку по производительности. У Монги один недостаток — это общий лок на коллекцию.