Обновить
Комментарии 37
Вы правда считаете, что это будет быстрее нормальной схемы работы СУБД?
НЛО прилетело и опубликовало эту надпись здесь
Я считаю, что отказываться от СУБД рано. Хотелось пойти в другую сторону и посмотреть на альтернативные решения, которые могут иметь место
НЛО прилетело и опубликовало эту надпись здесь
Я время не трачу. Мне это интересно.
Правильно совмещать СУБД классическую (для хранения связей) и NoSQL базы для хранения объектов, реализация которых на SQL сильно добавляет нагрузки. Т.е. балансировать надо, тогда всё будет ОК.
Как бы не ругали (О)РСУБД, и не смотря на существующие альтернатив, например MongoDB, в реальности РСУБД еще долго будут править бал…
РСУБД — будет править миром. Но в мире сеть еще много непознанного…
Чрезвычайно интересно и настолько же голословно без хотябы синтетических тестов.
Это легко и очень очевидно. У вас затык именно в списке статей, постраничном выводе и.т.д. Без этого ваша статья просто не имеет ценности. А ведь это те вещи, без которых любой сайт не построишь практически.
Зачем отказываться от удобства базы данных? Перестраивайте кэш при внесении изменений в базу, тогда при выводе данных вы будете работать только с ним непосредсвенно. Пункт 2 в ваших схемах будет исключён.
А чем ваше решение отличается от использования для генерирования динамики PHP+Apache+Mysql, а для отдачи кэша любой key-value базы (в которой уже есть все нужные возможности, и работает она также шустро) например Redis? Может стоит посмотреть в эту сторону…
Ок, кажись понял, вы делаете аналог txtSQL.
А как быть с ограничением количества операций ввода/вывода в секунду?
Все-таки, такие вещи нужно хранить в ОЗУ. Быстрее вы ничего не найдете. И иногда просто FLUSH'ить данные.
пока хватает одной машины
Так в основном все в ОЗУ и хранится…
что за паника с джойнами? если вы по религиозным причинам не приемлите их — юзайте 2 запроса, ваш тест повеселил, у меня есть вопросы для соискателей на вакансию php-developer, там есть вопрос «опишите достоинства/недостатки кеширования в разделяемой памяти, memcache и файлах». нельзя говорить о серьезном хайлоаде и о превосходстве xcache над memcache.
имеется в виду одновременно говорить
В моем решении можно использовать любой cache backend
НЛО прилетело и опубликовало эту надпись здесь
Чтобы показать пользователю статью с комментариями, нужно:

1. Посмотреть есть ли статья (с комментариями) в кэше
2. Если нет, то сделать «дорогой» JOIN текста + комментариев
3. Положить все в кэш
4. Отдать контент пользователю

Большой минус в этом алгоритме — это мускульный JOIN (или любой другой СУБД).
Современная концепция noSQL появилась, как ответ нормализованным структурам данных.

Рассмотрим связку PHP+Memcached в предыдущем примере:

1. Посмотреть есть ли статья (с комментариями) в кэше
2. Если нет, то положить ее в кэш
3. Отдать контент пользователю

Правильнее:

Рассмотрим связку PHP+Memcached в предыдущем примере:

1. Посмотреть есть ли статья (с комментариями) в кэше
2. Если нет, то получить из файла
3. Положить все в кэш
4. Отдать контент пользователю

Сильно сомневаюсь, что будет быстрее, особенно на архитектурах, отличных от пост-комментарии. Добавьте оценки постов/комментариев и потестируйте…
Несомненно на есть архитектуры (наример. бухгалтерия), где без СУБД не обойтись никак.

Уточнение по поводу алгоритма — правильное. Только, чтобы сделать JOIN, эти данные тоже нужно откуда-то взять…
>Несомненно на есть архитектуры (наример. бухгалтерия), где без СУБД не обойтись никак.

Вообще, СУБД — это система управления базой данных. То, что получается у вас — тоже СУБД, хоть и на другой основе.

>Только, чтобы сделать JOIN, эти данные тоже нужно откуда-то взять…

Верно. Разница только в том, что для этого, обычно, используются индексы, по которым легко найти нужные данные. И тут возникает вопрос: получится ли у вас сделать структуру практичнее и удобнее, чем в большинстве популярных СУБД? Время на поиск файла (в вашем случае) обычно больше, чем на чтение данных из одного файла (в случае использования индексного файла).
Я имел в виду СУБД — как SQL СУБД.

Пока что мое решение — это лишь прототип. Поставить его наравне с уже изместными MySQL, PostgreSQL, Oracle и другими нельзя.

Файловые системы тоже бывают разные. А сами документы кэшируются и чтение идет уже из памяти.
Когда только начинал кодить для веба, делал примерно то же самое. Вот только с СУБД куда удобнее и безопаснее.
НЛО прилетело и опубликовало эту надпись здесь
Что мешает использовать NoSQL базы вместо того, чтобы городить такое извращение?
академический интерес к подобному роду извращений
сказал А скажи Б
взялся за NoSQL для высоконагруженного проекта используй «не PHP»
Постебаться я тоже умею, только ничего хорошего из этого не выйдет…
Такое впечатление, что люди от безделья подыхают. Лишь бы всё подряд везде закэшировать и непопсово похранить
Все файловые операции медленные, читать из \ писать в пайп базы намного легче и быстрее для системы.
Для высоко нагруженных проектов этот вариант вообще не подходит, все будет висеть т.к. винт один, и читать с него в несколько потоков синхронно нельзя, рейд незначительно исправляет ситуацию. ( к тому-же винты убиваются почти мгновенно). Необходим промежуточный кэш ( тот же 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)

Когда по сети ложить/доставать в/из кэша будете, тогда и порадуетесь.

А так, рано радуетесь
:-)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.