Параметры базы данных B-Tree

Question

Мне нужно реализовать два индекса b-tree из двух разных таблиц pgsql, желательно в памяти в том же поле, на котором запущен процесс веб-сервера python (запросы должны быть как можно быстрее). Мне было интересно, что лучший способ осуществить это:

1. индекс и поддерживать сбалансированные деревья в памяти в процессе (вручную с помощью библиотеки Python)
2. Реализовать индекс в отдельном, в памяти базы данных (Redis , mongo и т. д.)
3. Используйте базу данных графа, такую ​​как neo4j или flock (предлог для игры с новой жарой)
4. Тонкая настройка pgsql для самих индексов. (За счет снижения производительности для других данных, находящихся в базе данных?)

Мои потребности, в порядке важности:

• скорость запроса
• ближайшего соседа поиск *
• индекса размера
• с открытым исходным кодом
• Python привязки :)

Дополнительные примечания: Деревья могут доходить до нескольких тысяч узлов сразу, придется выдерживать высокие вставки/скорость удаления

* Так что, если я ищу 756.837, но только 755,928 и 757,113 существуют, возвращать либо один в зависимости от параметры

Чтобы быть ясным, эта база данных postgres будет обслуживать традиционные данные webapp crud, поверх обрабатываемых данных. Я готов добавить сложность для поддержания производительности для данных webapp.

Answer 1

Первым шагом было бы узнать, как далеко вы можете продвинуть индексы PostgreSQL, чтобы делать то, что вы хотите. Типичные индексы btree бывают быстрыми, но у них не так много функций. В частности, они не являются гонгами, чтобы очень хорошо выполнять поиск. В зависимости от того, что вам нужно, вы можете изменить свои индексы от Btree до GiST. GiST обеспечивает поиск KNN (при условии, что ваши типы данных поддерживают это!) И позволяет вам делать многое из того, что вы ищете. Недостатком является то, что в зависимости от ваших типов данных вам может потребоваться некоторое программирование, чтобы получить необходимую поддержку для некоторых типов данных.

GiST предоставляет большее количество вариантов поиска, чем стандартные индексы btree, но они также немного медленнее запросов. Однако главным преимуществом является то, что они поддерживают гораздо более высокие скорости вставки/обновления, чем индексы GIN, и они также поддерживают поиск в knn.

Если это не сработает для вас .... вы можете реализовать что-то еще в памяти, возможно, используя кеш в памяти (например, memcached) или даже простой старый Sys V IPC и отдельный процесс. Будьте осторожны при одновременном доступе к памяти!