Comments 37
Вы правда считаете, что это будет быстрее нормальной схемы работы СУБД?
UFO just landed and posted this here
Я считаю, что отказываться от СУБД рано. Хотелось пойти в другую сторону и посмотреть на альтернативные решения, которые могут иметь место
UFO just landed and posted this here
Правильно совмещать СУБД классическую (для хранения связей) и NoSQL базы для хранения объектов, реализация которых на SQL сильно добавляет нагрузки. Т.е. балансировать надо, тогда всё будет ОК.
Как бы не ругали (О)РСУБД, и не смотря на существующие альтернатив, например MongoDB, в реальности РСУБД еще долго будут править бал…
Чрезвычайно интересно и настолько же голословно без хотябы синтетических тестов.
Это легко и очень очевидно. У вас затык именно в списке статей, постраничном выводе и.т.д. Без этого ваша статья просто не имеет ценности. А ведь это те вещи, без которых любой сайт не построишь практически.
Зачем отказываться от удобства базы данных? Перестраивайте кэш при внесении изменений в базу, тогда при выводе данных вы будете работать только с ним непосредсвенно. Пункт 2 в ваших схемах будет исключён.
А чем ваше решение отличается от использования для генерирования динамики PHP+Apache+Mysql, а для отдачи кэша любой key-value базы (в которой уже есть все нужные возможности, и работает она также шустро) например Redis? Может стоит посмотреть в эту сторону…
В моем решении нет SQL.
Ок, кажись понял, вы делаете аналог txtSQL.
А как быть с ограничением количества операций ввода/вывода в секунду?
что за паника с джойнами? если вы по религиозным причинам не приемлите их — юзайте 2 запроса, ваш тест повеселил, у меня есть вопросы для соискателей на вакансию php-developer, там есть вопрос «опишите достоинства/недостатки кеширования в разделяемой памяти, memcache и файлах». нельзя говорить о серьезном хайлоаде и о превосходстве xcache над memcache.
UFO just landed and posted this here
UFO just landed and posted this here
Чтобы показать пользователю статью с комментариями, нужно:
1. Посмотреть есть ли статья (с комментариями) в кэше
2. Если нет, то сделать «дорогой» JOIN текста + комментариев
3. Положить все в кэш
4. Отдать контент пользователю
Большой минус в этом алгоритме — это мускульный JOIN (или любой другой СУБД).
Современная концепция noSQL появилась, как ответ нормализованным структурам данных.
Рассмотрим связку PHP+Memcached в предыдущем примере:
1. Посмотреть есть ли статья (с комментариями) в кэше
2. Если нет, то положить ее в кэш
3. Отдать контент пользователю
Правильнее:
Рассмотрим связку PHP+Memcached в предыдущем примере:
1. Посмотреть есть ли статья (с комментариями) в кэше
2. Если нет, то получить из файла
3. Положить все в кэш
4. Отдать контент пользователю
Сильно сомневаюсь, что будет быстрее, особенно на архитектурах, отличных от пост-комментарии. Добавьте оценки постов/комментариев и потестируйте…
1. Посмотреть есть ли статья (с комментариями) в кэше
2. Если нет, то сделать «дорогой» JOIN текста + комментариев
3. Положить все в кэш
4. Отдать контент пользователю
Большой минус в этом алгоритме — это мускульный JOIN (или любой другой СУБД).
Современная концепция noSQL появилась, как ответ нормализованным структурам данных.
Рассмотрим связку PHP+Memcached в предыдущем примере:
1. Посмотреть есть ли статья (с комментариями) в кэше
2. Если нет, то положить ее в кэш
3. Отдать контент пользователю
Правильнее:
Рассмотрим связку PHP+Memcached в предыдущем примере:
1. Посмотреть есть ли статья (с комментариями) в кэше
2. Если нет, то получить из файла
3. Положить все в кэш
4. Отдать контент пользователю
Сильно сомневаюсь, что будет быстрее, особенно на архитектурах, отличных от пост-комментарии. Добавьте оценки постов/комментариев и потестируйте…
Несомненно на есть архитектуры (наример. бухгалтерия), где без СУБД не обойтись никак.
Уточнение по поводу алгоритма — правильное. Только, чтобы сделать JOIN, эти данные тоже нужно откуда-то взять…
Уточнение по поводу алгоритма — правильное. Только, чтобы сделать JOIN, эти данные тоже нужно откуда-то взять…
>Несомненно на есть архитектуры (наример. бухгалтерия), где без СУБД не обойтись никак.
Вообще, СУБД — это система управления базой данных. То, что получается у вас — тоже СУБД, хоть и на другой основе.
>Только, чтобы сделать JOIN, эти данные тоже нужно откуда-то взять…
Верно. Разница только в том, что для этого, обычно, используются индексы, по которым легко найти нужные данные. И тут возникает вопрос: получится ли у вас сделать структуру практичнее и удобнее, чем в большинстве популярных СУБД? Время на поиск файла (в вашем случае) обычно больше, чем на чтение данных из одного файла (в случае использования индексного файла).
Вообще, СУБД — это система управления базой данных. То, что получается у вас — тоже СУБД, хоть и на другой основе.
>Только, чтобы сделать JOIN, эти данные тоже нужно откуда-то взять…
Верно. Разница только в том, что для этого, обычно, используются индексы, по которым легко найти нужные данные. И тут возникает вопрос: получится ли у вас сделать структуру практичнее и удобнее, чем в большинстве популярных СУБД? Время на поиск файла (в вашем случае) обычно больше, чем на чтение данных из одного файла (в случае использования индексного файла).
Когда только начинал кодить для веба, делал примерно то же самое. Вот только с СУБД куда удобнее и безопаснее.
UFO just landed and posted this here
Что мешает использовать 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)
Когда по сети ложить/доставать в/из кэша будете, тогда и порадуетесь.
А так, рано радуетесь
:-)
Когда по сети ложить/доставать в/из кэша будете, тогда и порадуетесь.
А так, рано радуетесь
:-)
Sign up to leave a comment.
Реализация noSQL на PHP