Реализация атома в триплет-магазине - PullRequest
Новая
       0

Реализация атома в триплет-магазине

0 голосов
/ 20 октября 2011

Я пытаюсь реализовать собственное хранилище тройного хранилища поверх базы данных SQL (да, я знаю, что есть готовые проекты), и я пытаюсь выбрать лучший способ реализации символического «атома».

В простом дизайне мы могли бы реализовать триплетное хранилище в SQL, создав одну «тройную» таблицу с тремя столбцами varchar, которые называются субъект, предикат, объект. Чтобы сэкономить место, я собирался создать таблицу «атом», которая будет хранить уникальный текст, используемый в любом поле субъекта / предиката / объекта, и изменять эти поля на внешние ключи, ссылающиеся на атомы, которые содержат их текст.

Однако я вижу несколько способов реализации таблицы Atom.

  1. Сохранить текст как varchar.

    • Плюсы: простота индексирования и обеспечения уникальности текста.
    • Минусы: он не может хранить произвольно большой текст.

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

    • Плюсы: может хранить произвольно большой текст.
    • Минусы: немного сложнее. Возможно, хотя и редко, коллизии хешей в зависимости от алгоритма хеширования (md5, sha и т. Д.).

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

1 Ответ

1 голос
/ 20 октября 2011

Не тратьте время на оптимизацию, пока не сможете доказать , что это узкое место и самое важное, что нужно исправить.

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

Решение varchar будет работать и нормально масштабироваться.Идея «пула строк» ​​или «таблицы атомов» на самом деле хорошая, потому что у вас будет много ссылок на один и тот же базовый объект.Зачем повторять варчар?Почему бы просто не повторить номер индекса?

«Произвольно большой текст» - странное требование.Зачем?

Капля будет, как правило, медленнее.Столкновение с хешем - хотя и немного больше, чем теоретическая проблема - это то, с чем вы можете справиться двумя способами.Во-первых, используйте хэш с более чем 32 битами.Во-вторых, столкновение ничего не испортит, если только вы (по глупости) не сможете проверить настоящие капли, чтобы увидеть, действительно ли они одинаковые.Если вы хотите избежать сравнения всего большого двоичного объекта, чтобы убедиться в отсутствии коллизий, сохраняйте два хэша по разным алгоритмам.

...