sql-подобный интерфейс для высокопроизводительного python, но в том же процессе одноэлементный / объект вместо базы данных?

#python #sql #caching #redis #scientific-computing

#python #sql #кэширование #redis #научные вычисления

Вопрос:

Я знаю, что этот вопрос может показаться немного странным, но я делаю высокопроизводительный алгоритмический код на python. Он чрезвычайно привязан к процессору с большим количеством обходов графа и очень отслеживает состояние. Я хотел бы настроить какой-то интерфейс, подобный реляционной базе данных, для управления этим состоянием со всеми обычными гарантиями, которые поставляются с надлежащей схемой RDBMS, например, внешние ключи, ограничения и т. Д., Не говоря уже о sql-запросах.

Прямо сейчас состояние и логика алгоритма довольно разведены. На данный момент само состояние представляет собой более или менее реляционную базу данных, но вместо таблиц / строк это набор объектов с довольно сложной сетью отношений, которые являются почти реляционными (например, 1: 1, 1: N, N: M и т. Д.).

В идеале я мог бы использовать стандартную технологию ORM для записи множества схем, но вместо использования redis или sqlite все это будет обрабатываться в том же процессе python, что и синглтон или тому подобное, чтобы все это оставалось в локальной памяти

Комментарии:

1. если вы хотите переключиться на высокопроизводительный C , Rust, ….. Вопрос в том, что вам нужна объектно-ориентированная база данных в памяти? Используйте обычную базу данных и используйте RAM-диск

2. я хорошо знаю, но переписывание кодовой базы в cpp или rust — это не совсем хорошее использование времени eng. и меня беспокоит то, что работа в памяти все еще слишком медленная, поскольку она по-прежнему будет выполнять обратный переход в ОЗУ, не говоря уже о накладных расходах, для того, что в основном является простыми операциями получения / установки.

3. вы хотите сделать все это в кэше процессора?

4. я просто хочу лучший интерфейс, чем паутина объектов и одиночек, как сейчас. Введение базы данных в памяти кажется совершенно ненужным, если все, что я хочу, это просто что-то более эргономичное

5. например, представьте, что obj.do_something() должен выполнять obj_B.filter(A_id=obj.obj_A.id ) или сорт. Вот как это выглядит сейчас