Лучший способ использовать базу данных PostgreSQL в качестве простого хранилища значений ключей

Question

Мне необходимо использовать базу данных postgreSQL, и она заменит мое текущее использование berkeleyDB. Хотя; Я понимаю, что это не идеальная ситуация, это вне моего контроля.

Итак, вопрос в том ... Если бы вам потребовалось преобразовать postgreSQL в хранилище значений ключей, как бы вы поступили, сделав его максимально эффективным?

Мои значения - это байтовые массивы, а мой ключ - строки, я могу наложить некоторые ограничения на длину этих строк.

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

Answer 1

Расширение в Postgresql для правильного выполнения этого называется hstore. Он работает аналогично, как и другие системы хранения ключей. Просто загрузите расширение. Синтаксис уникален, но если вы когда-либо использовали Redis или Mongo, вы получите его быстро. Не делай это сложнее, чем есть. Я понимаю, что мы часто не выбираем наши инструменты и вынуждены делать.
Вот страница документа:

http://www.postgresql.org/docs/9.1/static/hstore.html

Answer 2

Если вы вынуждены использовать реляционную базу данных, я бы посоветовал попытаться найти структуру в ваших данных, чтобы воспользоваться этим фактом, поскольку вы отказываетесь от преимущества скорости, которую вы получили, благодаря неструктурированным данным и хранилищу значений ключей. Чем больше структуры вы найдете, тем больше преимуществ вы получите от своего затруднительного положения. Даже если вы найдете структуру только в ключах.

Также подумайте, нужен ли вам только последовательный или произвольный доступ к вашим данным, и в каком соотношении и структурируйте вашу базу данных в соответствии с этим требованием. Собираетесь ли вы делать запросы к вашим значениям по типу, например? Каждый из этих вопросов может повлиять на структуру вашей базы данных.

Одно конкретное соображение о каплях в postgresql, они внутренне представлены как pg_largetable (loid: oid, pageno: int4, data: bytea). Размер кусков определяется с помощью LOBBLKSIZE, но обычно составляет 2 КБ. Таким образом, если вы можете использовать байтовые массивы в своей таблице вместо BLOB-объектов и ограничивать размер пары «значение / ключ» для блоков, вы можете избежать этого косвенного обращения через вторую таблицу. Вы также можете увеличить размер блока, если у вас есть доступ к конфигурации базы данных.

Я бы предложил поискать структуру данных и шаблоны доступа к данным, а затем снова задать свой вопрос с более подробной информацией.

Answer 3

Это действительно должно зависеть от того, каким будет ключ. Если это всегда будет строка длиной менее 255 символов, тогда используйте Varchar в качестве ПК, а затем используйте BLOB-объект (при условии большого значения) для значения. если это всегда будет число, используйте int и т. д.

Другими словами, нужно больше информации, чтобы действительно дать вам хороший ответ:)

Answer 4

Что нужно хранить в качестве значения? Струны? Интс? Объекты (например, сериализованные объекты Java). Простая реализация будет работать с таблицей из 3 столбцов, которая выглядит следующим образом:

NAME(VARCHAR)   TYPE(VARCHAR)   VALUE(VARCHAR)

(возможно, ТИП - это какое-то перечисление). Вышеописанное не сработает для двоичных данных, таких как сериализованные объекты, хотя, возможно, вам понадобится большой двоичный объект.

В качестве альтернативы (и, вероятно, намного лучшей идеи), вы видели Конфигурация Apache Commons ? Вы можете сделать это с помощью базы данных (через JDBC) и сохранить свойства, которые вы получите таким образом:

// get a property called 'number'
Double double = config.getDouble("number");
Integer integer = config.getInteger("number");

Это может спасти вас от горя в плане реализации. Вы можете иметь проблему с сохранением двоичных данных, так как вам придется сериализовать их до вставки и последующего извлечения. Но в прошлом я использовал это для хранения целочисленных, двойных и сериализованных объектов Java через XStream, поэтому я могу подтвердить, что он работает хорошо.