Среднее между memcache и mysql

Например есть «таблица» messages. В неё кидаешь данные например {id: 1, title «test», «text»: «blah»}, а потом делаешь выборку из всех данных, с проверкой where и сортировкой

Посмотри на redis. Не совсем то, что надо, но поиск по ключам там всякий хитрый бывает.

Плюс сам MySQL с MEMORY engine.

MongoDB в tmpfs? Внезапно, MySQL в tmpfs?

Тебе сама по себе БД нужно из-за того что в память не влезает, availability, failover? Я просто к чему клоню, может просто взять и в память положить и фильтровать примитивами твоего ЯП?

Плюс сам MySQL с MEMORY engine

+1, а то я уже тут tmpfs насоветовал сдуру

Погоди, ты не понял :) Фишка не в том что в памяти, а в том чтобы таблицы не надо было создавать заранее, а прямо на ходу придумывать ключи (ака колонки таблиц в mysql), а потом по ним селектить/фильтровать.

Ну тогда да, MongoDB

MySQL с MEMORY engine

Потрёт данные после ребута, нельзя делать динамичную структуру таблицы (или можно?)

И вот еще Dynamic Columns в https://mariadb.com/kb/en/mariadb/documentation/nosql/dynamic-columns/

MongoDB

Вроде то что нужно, спасибо, потыкаю

https://blogs.oracle.com/mysqlinnodb/entry/mysql_5_7_3_deep

https://dev.mysql.com/doc/refman/5.7/en/innodb-memcached-tuning.html

на стороне php можно считывать и записывать данные в виде ключ-значение или делать нормальные sql запросы. Это innodb, данные сбрасываются на диск.

Т.е. биндинги уже все есть.

чтобы туда ассоциативные массивы скидывать, а оно мне могло делать селекты с сортировкой и выборкой

надо будет orm пилить, чтобы по имени класса создавались таблицы, индексы и была простая функция для записи объекта. Как будет записываться объект - через sql или через memcached интерфейс - дело производительности.

Кстати, в Google Dremel подошли к вопросу с другой стороны. Вместо того чтобы сделать СУБД с полностью динамической схемой, они совсем не делали СУБД, а просто реализовали параллельные запросы на SQL-based языке поверх изначально непредназначеных для этого разных хранилищ - файлов в распределенной ФС в JSON, XML, CSV, Protobuf в свободной форме, разных СУБД, логов. Индексирования я как понял нету, но есть сильный параллелизм и оптимизация агрегации.

Бывает такое?

Redis

PostgreSQL и JSON, это если не особо хочется от реляционных СУБД уходить. Не знаю какие селекты нужны, в общем смотри сам. А так MongoDB, CouchDB (почти сдох) или CouchBase, ну и попроще (ключ-значение): LevelDB, Redis.

Используй одну таблицу любой РСУБД такой структуры:

create table attr (
   n integer not null, -- номер объекта
   name varchar2(64) not null, -- имя атрибута объекта
   val varchar2(2000) not null -- значение атрибута объекта
);
create sequence sq$objn;

Для быстрого поиска таблицу надо проиндексировать:

create index attr$n$name on attr (n, name);
create index attr$name$val on attr (name, val);

Добавить новый объект в такую таблицу — это выделить один номер объекта из сиквенса, вставить по одной строке на каждый атрибут:

select into :n sq$objn.nextval from dual;
insert into attr (n, name, val) values (:n, "id", "1");
insert into attr (n, name, val) values (:n, "title", "test");
insert into attr (n, name, val) values (:n, "text", "blah");

Поиск объекта с сортировкой объектов по значению атрибута:

select a.* from attr a where a.n in (
select n from attr a1, attr a2
-- ищем объекты с title=test
where a1.name="title" and a1.val="test"
-- подтягиваем атрибут id
and a2.n=a1.n and a2.name="id"
-- сортируем по возрастанию id
order by to_number(a2.val)
)