Подготовлен (http://blogerator.ru/page/mysql-php-sql-ili-nosql-vot-v-chem...) подробный обзор особенностей реализации NoSQL-функциональности в MySQL. Рассматриваются два популярных NoSQL-плагина: HandlerSocket (http://www.opennet.me/opennews/art.shtml?num=28401) от японского разработчика Яшинори Мацунобу (Yoshinori Matsunobu), а также разработка от компании Oracle – плагин Memcached (https://blogs.oracle.com/mysql/entry/nosql_to_mysql_with_mem...), впервые появившийся в бета-версиях MySQL 5.6.x (http://www.opennet.me/opennews/art.shtml?num=31291). Также проведено сравнительное тестирование этих плагинов по скорости их работы.
Содержание серии статей:
- Введение и оглавление (http://blogerator.ru/page/mysql-php-sql-ili-nosql-vot-v-chem...);
- Общая теория и тренды развития: OldSQL -> NoSQL -> NewSQL (http://blogerator.ru/page/mysql-php-sql-ili-nosql-vot-v-chem...);
- Общее устройство и особенности плагина HandlerSocket (http://blogerator.ru/page/mysql-php-sql-ili-nosql-vot-v-chem...);
- Основные команды HandlerSocket (http://blogerator.ru/page/mysql-sql-ili-nosql-vot-v-chem-vop...);
- Общее устройство и особенности плагина Memcached (http://blogerator.ru/page/mysql-php-sql-ili-nosql-vot-v-chem...);
- Тестируем скорость NoSQL-плагинов. Общие выводы (http://blogerator.ru/page/mysql-sql-ili-nosql-vot-v-chem-vop...).URL: http://blogerator.ru/page/mysql-php-sql-ili-nosql-vot-v-chem...
Новость: http://www.opennet.me/opennews/art.shtml?num=33405
А есть ли что похожее ещё и для Postgre?
нет. мускуль как раз и задумывался как обособленная реализация субд от движков хранения.
в этом то как раз и преимущества мускуля - можно комбиноровать движки врамках одной разработки.
в частости сабж
>HandlerSocket. Этот интерфейсный плагин позволяет клиентскому приложению подключаться напрямую к движку данных MySQL для устранения избыточной нагрузки,http://blogerator.ru/page/mysql-php-sql-ili-nosql-vot-v-chem...
>>нет. мускуль как раз и задумывался как обособленная реализация субд от движков хранения.Только получилось не очень. Раз его SQL подсистема оказалось такой гигатормозной и практически не нужной :-)
В статье сказано что это нормальный процесс эволюции.
несколько лет назад был востребован именно полноценный sql движек.Сейчас, в условиях больших нагрузок, оказалось что выгоднее работать по другому.
Хм. Как минимум не медленнее, чем у других sql-серверов.
hstore
похоже, но... не то.
это всё тотже добрый сиквел.
Если не считать, что половина приложения может быть размещена прямо в базе на любимом языке программирования
доброго сиквела нет уже более двух десятков лет. не нужно уподобляться дебилам и называть вещи не своими именами
Например, есть Foreign Data Wrapper в 9.1.
эта ссылка лучше:
http://wiki.postgresql.org/wiki/Foreign_data_wrappers
Скопилированный хип-хопом php наверно быстрее, чем оптимизированный и проверенный годами C. Создается двоякое впечатление - происходит стагнация достаточно развитого языка и создание быстрых решений, подходящих только под решение конкретной задачи (соц.сети и им подобные), которые пытаются потом протолкнуть глупые менеджеры услышавшие новое слово в продакшн. Обычный сетевой диск теперь назвали облачным хранилищем запилив лишь фишку синхронизации.
Это к чему?