История изменений

Взяли да прикрутили, вам по сути надо просто сделать прокси данных из блобов в SQL, а затем прокси выборки вместо блобов из SQL. Можно прикрутить на живую прозрачно и оттестировать лишь на части.

А можно взять luajit через FFI замапить структуры (уже существующего решения) в таблицы, и делать выборку просто по ключам, так сами данные будут чистыми сишными блобами, а доступ к конкретным полям будет через хештабли луа прозрачно для вас, с помощью метатаблиц, а именно __index можно сделать так что при запросе в таблицу ключа t['где деньги?'] который не существует, но нужен, метаметод будет делать выборку из файловой системы и помещать данные в таблицу и всё это прозрачно без ручных телодвижений, так таблицы будут наполняться данными только теми которые действительно нужны. Конечно есть ограничения по памяти, с FFI придётся поработать.

Но прежде всего вопрос, если у вас и так всё работает и данные сейчас упакованы в памяти, а их распаковка заключается только в выборке sizeof(data_type) тем или иным способом типа сдвинул указатель вытащил N*X байт и выдал. То зачем городить огород внедряя ещё что-то? Если разве что ради ускорения сложной выборки, всё остальное внесёт тормоза по определению. К тому же сам сказал что вам надо под клиента менять структуру данных, как это ляжет на SQL у которого структура данных в табличках фиксирована? Под каждого клиента свою табличку? Или Горсть универсальных и сложный запрос по формированию из них для каждого конкретного случая. Но как это ляжет на вставить список в список вьяяпъросикъ :)

Очень тупо, да, зато надёжно как кусок кирпича.

Ну и нехай трогать, сами себе приключений на жопу ищите. Но никто не мешает вашему Петровичу сесть и параллельно реализовать то что он предложил, а потом испытать это и узнать чё как.

Может вообще взять Tarantool и переписать всё на него. Хер знает.

Ну хотел диванную аналитику, вот я принёс :3

Взяли да прикрутили, вам по сути надо просто сделать прокси данных из блобов в SQL, а затем прокси выборки вместо блобов из SQL. Можно прикрутить на живую прозрачно и оттестировать лишь на части.

А можно взять luajit через FFI замапить структуры (уже существующего решения) в таблицы, и делать выборку просто по ключам, так сами данные будут чистыми сишными блобами, а доступ к конкретным полям будет через хештабли луа прозрачно для вас, с помощью метатаблиц, а именно __index можно сделать так что при запросе в таблицу ключа t['где деньги?'] который не существует, но нужен, метаметод будет делать выборку из файловой системы и помещать данные в таблицу и всё это прозрачно без ручных телодвижений, так таблицы будут наполняться данными только теми которые действительно нужны. Конечно есть ограничения по памяти, с FFI придётся поработать.

Но прежде всего вопрос, если у вас и так всё работает и данные сейчас упакованы в памяти, а их распаковка заключается только в выборке sizeof(data_type) тем или иным способом типа сдвинул указатель вытащил N*X байт и выдал. То зачем городить огород внедряя ещё что-то? Если разве что ради ускорения сложной выборки, всё остальное внесёт тормоза по определению. К тому же сам сказал что вам надо под клиента менять структуру данных, как это ляжет на SQL у которого данные фиксированны?

Очень тупо, да, зато надёжно как кусок кирпича.

Ну и нехай трогать, сами себе приключений на жопу ищите. Но никто не мешает вашему Петровичу сесть и параллельно реализовать то что он предложил, а потом испытать это и узнать чё как.

Может вообще взять Tarantool и переписать всё на него. Хер знает.

Ну хотел диванную аналитику, вот я принёс :3