Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
Вы правда считаете, что это будет быстрее нормальной схемы работы СУБД?
Я считаю, что отказываться от СУБД рано. Хотелось пойти в другую сторону и посмотреть на альтернативные решения, которые могут иметь место
Правильно совмещать СУБД классическую (для хранения связей) и NoSQL базы для хранения объектов, реализация которых на SQL сильно добавляет нагрузки. Т.е. балансировать надо, тогда всё будет ОК.
Как бы не ругали (О)РСУБД, и не смотря на существующие альтернатив, например MongoDB, в реальности РСУБД еще долго будут править бал…
Чрезвычайно интересно и настолько же голословно без хотябы синтетических тестов.
Это легко и очень очевидно. У вас затык именно в списке статей, постраничном выводе и.т.д. Без этого ваша статья просто не имеет ценности. А ведь это те вещи, без которых любой сайт не построишь практически.
Зачем отказываться от удобства базы данных? Перестраивайте кэш при внесении изменений в базу, тогда при выводе данных вы будете работать только с ним непосредсвенно. Пункт 2 в ваших схемах будет исключён.
А чем ваше решение отличается от использования для генерирования динамики PHP+Apache+Mysql, а для отдачи кэша любой key-value базы (в которой уже есть все нужные возможности, и работает она также шустро) например Redis? Может стоит посмотреть в эту сторону…
В моем решении нет SQL.
Ок, кажись понял, вы делаете аналог txtSQL.
А как быть с ограничением количества операций ввода/вывода в секунду?
что за паника с джойнами? если вы по религиозным причинам не приемлите их — юзайте 2 запроса, ваш тест повеселил, у меня есть вопросы для соискателей на вакансию php-developer, там есть вопрос «опишите достоинства/недостатки кеширования в разделяемой памяти, memcache и файлах». нельзя говорить о серьезном хайлоаде и о превосходстве xcache над memcache.
Когда только начинал кодить для веба, делал примерно то же самое. Вот только с СУБД куда удобнее и безопаснее.
Что мешает использовать NoSQL базы вместо того, чтобы городить такое извращение?
сказал А скажи Б
взялся за NoSQL для высоконагруженного проекта используй «не PHP»
взялся за NoSQL для высоконагруженного проекта используй «не PHP»
Вы, случаем, не родственник?
Разработал драйвер баз данных, что дальше???
Разработал драйвер баз данных, что дальше???
Такое впечатление, что люди от безделья подыхают. Лишь бы всё подряд везде закэшировать и непопсово похранить
Все файловые операции медленные, читать из \ писать в пайп базы намного легче и быстрее для системы.
Для высоко нагруженных проектов этот вариант вообще не подходит, все будет висеть т.к. винт один, и читать с него в несколько потоков синхронно нельзя, рейд незначительно исправляет ситуацию. ( к тому-же винты убиваются почти мгновенно). Необходим промежуточный кэш ( тот же memcached ) который будет собирать данные и выгружать \ подгружать блоки, что уже немного опасно, есть вероятность потерять кусок данных, которые помещены в кэш, но блок еще не выгружен на диск. Подобный механизм уже реализован в любой уважаемой СУБД. Вообще СУБД стараются помещать как можно больше данных в память ( индексы, таблицы, кеш результатов выборки) чтобы уменьшить нагрузку на диски, т.к. они являются узким местом в работе сервера. Тут вариант обратный :D
если join`ы не позволяет религия, местом хранения блоков лучше выбрать СУБД, а не файловую систему.
Изменение структуры хранения данных может помочь вообще отказаться от join в запросах.
«P.S. Скорость на чтение я не сравнивал, так как очевидно, что прямое обращение к кэшу будет работать всегда быстро. А вот скорость вставки (100 элементов) порадовала: связка MySQL+memcached отстала (0.5417142) от JIM2 (0.4791223)»
Память это самый быстрый источник данных. Может быть множество внешних факторов влияющих на результат, и 100 элементов это не нагруженная система. Сравнение надо делать используя хотя-бы 100 000 записей, информацию разного объема и структуры
Для высоко нагруженных проектов этот вариант вообще не подходит, все будет висеть т.к. винт один, и читать с него в несколько потоков синхронно нельзя, рейд незначительно исправляет ситуацию. ( к тому-же винты убиваются почти мгновенно). Необходим промежуточный кэш ( тот же memcached ) который будет собирать данные и выгружать \ подгружать блоки, что уже немного опасно, есть вероятность потерять кусок данных, которые помещены в кэш, но блок еще не выгружен на диск. Подобный механизм уже реализован в любой уважаемой СУБД. Вообще СУБД стараются помещать как можно больше данных в память ( индексы, таблицы, кеш результатов выборки) чтобы уменьшить нагрузку на диски, т.к. они являются узким местом в работе сервера. Тут вариант обратный :D
если join`ы не позволяет религия, местом хранения блоков лучше выбрать СУБД, а не файловую систему.
Изменение структуры хранения данных может помочь вообще отказаться от join в запросах.
«P.S. Скорость на чтение я не сравнивал, так как очевидно, что прямое обращение к кэшу будет работать всегда быстро. А вот скорость вставки (100 элементов) порадовала: связка MySQL+memcached отстала (0.5417142) от JIM2 (0.4791223)»
Память это самый быстрый источник данных. Может быть множество внешних факторов влияющих на результат, и 100 элементов это не нагруженная система. Сравнение надо делать используя хотя-бы 100 000 записей, информацию разного объема и структуры
>А вот скорость вставки (100 элементов) порадовала: связка MySQL+memcached отстала (0.5417142) от JIM2 (0.4791223)
Когда по сети ложить/доставать в/из кэша будете, тогда и порадуетесь.
А так, рано радуетесь
:-)
Когда по сети ложить/доставать в/из кэша будете, тогда и порадуетесь.
А так, рано радуетесь
:-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация noSQL на PHP