Спасибо,
интересно и полезно,
выложи проект на github
>P.S. так как я разработчик БД, и написание кода на C++ не является моей даже побочной специальностью
Разработчик БД — должен разрабатывать БД, т.е. писать Сишный код — это его прямая обязанность ;)
У меня брат прожил в Дании 2 года, так что не по наслышке знаю…
могу добавить, что в Австрии почти такой же человеческий климат, я там прожил около пол года (правда это было 15 лет назад).
На прошлом Хайлоаде (2011) один из докладчиков высказывал похожие тезисы,
одним из его тезисов был: «новомодные NoSQL системы еще не проверены временем и есть риск наткнуться на подводные камни, решение которых потребует не запланированных ресурсов»
я использовал и МонгоДв, редис и Тарантул в своих проектах. Да, с каждым из них каждым из них натыкался на какие-то нерешенные проблемы, которые со временем решались. Со старым добрым проверенным SQL, тоже бывают свои проблемы. Только они, в силу более развитого коммунити выевляются и решаются гораздо быстрее.
новые, альтернативные системы хранения информации нужны, и у них есть и будет своя ниша использования. SQL нужен там, где он нужен… одно не должно подменять другое. Биллинг я ни когда не буду писать на МонгоДБ, а для простой и быстрой отдачи контента, не буду использовать MySQL.
смотрел как-то передачу про увлечение споттингом, на западных аэродромах оборудованы даже специальные площадки для споттеров, а у нас их гоняют службы безопастности… хотя многих споттеров они уже знают в лицо и негласно им сказано — если что — мы знаем с кого спросить…
только сегодня в новостях объявили, что у следствия по делу гибели авиолайнера появилась любительская фотография при посадке самалета, бортовые номера совпадают… Следствие выесняет, сделана ли она в день аварии. Если да, то эта фотография сможет прояснить на некоторые делали причины аварии. На мой неопытный взгляд, по фотографии можно определить — высоту в данной точке, угол наклона, и возможно даже — скорость полета (если знаем выдержку? то по размытости пикселов можно определить скорость тела)
возможно, имея эти данные можно спроецировать траекторию полета до места столкновения…
так что, это увлечение возможно сможет раскрыть некоторые темные пятна
еще корутины могут быть нужны при распределение вычислений между несколькими серверами задач:
родили несколько коротин, которые отправили данные на разные сервера задач: например обработка машинный перевод или распределенный поиск… далее переключая контекст коротин мы смотрим статусы задач и отдаем уже результат
достоинство коротин (не в пхп) в том, что они позволяют распараллелить код, без накладных расходов в однопоточной модели. При этом всегда будет занято только одно ядро процессора, в отличие от тредовой модели. При реализации многотредовой модели появляются проблемы в синхронизации, затраты ресурсов на переключении контекста приложения между тредами и т.п…
считается что в ряде задач, решения на коротинах — эффективнее.
корутины применяются для псевдо-распараллеливания кода, так как пхп не поддерживает треды…
распараллеливание выгодно там, где есть операции в/в:
пока одна коротина занята приемом/отправлением данных — другая коротина может какие-то другие данные обработать.
один из вариантов использования — это мультиплексный асинхронный сервер
единственное, что хотелось бы увидеть от автора: это реализация двух серверов — один на libevent, воторй на коротинах и измерить их эффективность ( память, кол-во обработанных соединений за сек… )
я понимаю что это тема отдельной статьи, но све же может кто возмется???
мой комментарий к тому, что не Вы открыли Америку!
и очевидно, что большинство файловых хранилищ построенно по такому же принципу: хранят файл в единственном экз, а пользователю кидают линк
Яндекс.Диск точно не хранит одинаковых файлов :)
они их чекают по sha1 (верогятность сбоя одного бита оперативной памяти больше чем коллизия по sha1)
это так, к сравнению разных систем хранения файлов.
из РНР ни чего не осталось. свой шаблонизатор, свой конфигуратор, свой sharding_proxy
со скоростью разработки я уже давал пояснения, где-то на 15-25% медленнее чем на РНР (сравниваю по другим проектам, хотя сравнивать трудно так как похожего функционала практически нет, а тот который есть — был уже написан до меня), если это WEB часть, демоны пишутся медленее, но они требуют более детальной проработки. В них нужна дотошность с утечками.
Вообще, везде нужна практика, так в РНР, так и на Си. Сперва на РНР пишешь медленно, потом нарабатывается функционал, общие паттерны и начинаешь писать быстрее, правильнее и качественней.
Такакя же картина и на другом языке разработке. Очевидно, когда проект только переходил на Си, то возникало много подводных камней. Но это всё было до меня.
Я не занимаюсь фронтэндом, я разрабытываю внутренние сервисы. Например, вот на внедрение этого сервиса highloadblog.ru/articles/17.html у меня ушел всего месяц. Потом я его расширял и дорабатывал под расширенный функционал. В результате мы освободили два сервера с мускулем, правда один занят под этот сервис. Но все же одна железка освободилась, на очереди еще стоит пара железок (внедряем еще один сервис), но уже без включения новой…
интересно и полезно,
выложи проект на github
>P.S. так как я разработчик БД, и написание кода на C++ не является моей даже побочной специальностью
Разработчик БД — должен разрабатывать БД, т.е. писать Сишный код — это его прямая обязанность ;)
могу добавить, что в Австрии почти такой же человеческий климат, я там прожил около пол года (правда это было 15 лет назад).
одним из его тезисов был: «новомодные NoSQL системы еще не проверены временем и есть риск наткнуться на подводные камни, решение которых потребует не запланированных ресурсов»
я использовал и МонгоДв, редис и Тарантул в своих проектах. Да, с каждым из них каждым из них натыкался на какие-то нерешенные проблемы, которые со временем решались. Со старым добрым проверенным SQL, тоже бывают свои проблемы. Только они, в силу более развитого коммунити выевляются и решаются гораздо быстрее.
новые, альтернативные системы хранения информации нужны, и у них есть и будет своя ниша использования. SQL нужен там, где он нужен… одно не должно подменять другое. Биллинг я ни когда не буду писать на МонгоДБ, а для простой и быстрой отдачи контента, не буду использовать MySQL.
только сегодня в новостях объявили, что у следствия по делу гибели авиолайнера появилась любительская фотография при посадке самалета, бортовые номера совпадают… Следствие выесняет, сделана ли она в день аварии. Если да, то эта фотография сможет прояснить на некоторые делали причины аварии. На мой неопытный взгляд, по фотографии можно определить — высоту в данной точке, угол наклона, и возможно даже — скорость полета (если знаем выдержку? то по размытости пикселов можно определить скорость тела)
возможно, имея эти данные можно спроецировать траекторию полета до места столкновения…
так что, это увлечение возможно сможет раскрыть некоторые темные пятна
рад за многопоточность в РНР!
спасибо за подсказку использования этого расширения…
если в исходниках ни одной phtread функции.
родили несколько коротин, которые отправили данные на разные сервера задач: например обработка машинный перевод или распределенный поиск… далее переключая контекст коротин мы смотрим статусы задач и отдаем уже результат
считается что в ряде задач, решения на коротинах — эффективнее.
распараллеливание выгодно там, где есть операции в/в:
пока одна коротина занята приемом/отправлением данных — другая коротина может какие-то другие данные обработать.
один из вариантов использования — это мультиплексный асинхронный сервер
единственное, что хотелось бы увидеть от автора: это реализация двух серверов — один на libevent, воторй на коротинах и измерить их эффективность ( память, кол-во обработанных соединений за сек… )
я понимаю что это тема отдельной статьи, но све же может кто возмется???
спасибо, что показали нам эту возможность для РНР…
думаю пригодится
и очевидно, что большинство файловых хранилищ построенно по такому же принципу: хранят файл в единственном экз, а пользователю кидают линк
они их чекают по sha1 (верогятность сбоя одного бита оперативной памяти больше чем коллизия по sha1)
это так, к сравнению разных систем хранения файлов.
у меня трое детей, хочу больше, но квартира тесная…
в офисе мне нравиться больше, так как дома много отвлекающих факторов.
многим будет полезно о нём знать…
когда делал локальный поисковик по файлам, к сожалению, стандартных реализаций я не нашел, пришлось изобретать велосипед.
со скоростью разработки я уже давал пояснения, где-то на 15-25% медленнее чем на РНР (сравниваю по другим проектам, хотя сравнивать трудно так как похожего функционала практически нет, а тот который есть — был уже написан до меня), если это WEB часть, демоны пишутся медленее, но они требуют более детальной проработки. В них нужна дотошность с утечками.
Вообще, везде нужна практика, так в РНР, так и на Си. Сперва на РНР пишешь медленно, потом нарабатывается функционал, общие паттерны и начинаешь писать быстрее, правильнее и качественней.
Такакя же картина и на другом языке разработке. Очевидно, когда проект только переходил на Си, то возникало много подводных камней. Но это всё было до меня.
Я не занимаюсь фронтэндом, я разрабытываю внутренние сервисы. Например, вот на внедрение этого сервиса highloadblog.ru/articles/17.html у меня ушел всего месяц. Потом я его расширял и дорабатывал под расширенный функционал. В результате мы освободили два сервера с мускулем, правда один занят под этот сервис. Но все же одна железка освободилась, на очереди еще стоит пара железок (внедряем еще один сервис), но уже без включения новой…