Уникальное ограничение в Mnesia

Question

Я разрабатываю приложение Erlang, которое требует много записи DB. В моей схеме помимо первичного ключа есть еще один атрибут с принудительным соблюдением уникального ограничения.

Скажем, у меня есть идентификатор, уникальное_конфигурирование и другие поля. Мне нужно обновить строку в БД, соответствующую уникальному идентификатору, учитывая, что никакая другая строка уже не должна иметь значение значения unique_constraint_field, которое я собираюсь обновить.

Из-за большого объема обновлений (каждое обновление будет влиять только на 1 строку) Мне нужно выполнить (требуется низкая латентность). Я полагаюсь на первичный ключ и уникальное ограничение на этот атрибут, чтобы поймать дублирование, вместо этого оператора обновления с использованием подзапроса. Это позволяет мне выполнить обновление в одном запросе (что происходит в 95% случаев), а в оставшихся 5% я могу поймать исключение, чтобы предпринять необходимые действия в отношении первичного ключа или нарушения уникального атрибута.

В настоящее время я использую драйвер mysql ODBC. Однако драйвер возвращает очень общее сообщение об ошибке для ЛЮБОЙ ошибки. Хотя сейчас мой прототип работает хорошо, когда я предполагаю, что какая-либо ошибка является ключевым нарушением, эта модель, очевидно, в значительной степени ошибочна. Я не могу найти другого достойного драйвера/способа подключения к mysql от erlang.

Я думаю о переключении в Mnesia (режим только для памяти для моих требований скорости), так как Erlang и Mnesia сочетаются так легко. Тем не менее, я вижу, что у Mnesia нет каких-либо уникальных ключевых ограничений, которые я могу использовать для выполнения моего обновления БД в одном запросе.

Мне нужны предложения как наилучшим образом реализовать это требование изнутри Erlang. Есть ли способ выполнить условное обновление в Mnesia? Или, есть ли какая-либо другая высокоскоростная DB-альтернатива, на которую я должен смотреть? Любая помощь/понимание очень ценится.

Answer 1

Я не знаю, что является лучшим решением, но я попробую сделать две таблицы для записей и одну для индекса с unique_constraint_field и обрабатывать каждый CUD из операций CRUD в транзакции, которые проверяют и обновляют индекс. Причина в том, что в mnesia вы не можете установить тип индекса и всегда дублировать мешок. Я думаю, что, поскольку ваш индекс будет уникальным в любом случае, он не должен вводить никаких дополнительных штрафных санкций. Если вы используете функцию индекса mnesia, вам все равно придется писать свои собственные операции CUD, и результат кажется почти таким же, как с использованием двух таблиц. К счастью, mnesia обрабатывает вложенные транзакции с минимальными усилиями разработчиков, и эта вещь относительно проста по сравнению с классическими РСУБД.

Answer 2

Ulf Wiger выпустил библиотеку, которая позволяет использовать mnesia как реляционную базу данных. Это называется «rdbms», ему несколько лет и он не обновлялся в течение длительного времени, но вы, вероятно, можете использовать его как есть или, по крайней мере, основываться на своей работе, чтобы справиться с этим. Grab the source если хотите.

Его описание этого:

Я пыль мой стандартный ответ, что вно -х РСУБД "предложили решение для этого, за счет поддержки составных атрибутов и определяемых пользователем индексации, в том числе в опции укажите, что значение индекса должно быть уникальным.

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

http://ulf.wiger.net/rdbms/doc/rdbms.html (Документы оставляют желать много лучшего, я знаю, - см. Выше)

Дока mentionning на 'уникальное' ограничение можно найти here. Есть возможность получить производительность; mnesia предназначена для хранения ключей. Я не могу точно помнить, но можно определить, что «уникальные» индексы могут включать в себя проверку полного стола при их проверке.

В целом, поскольку это старый, вам, вероятно, не удастся его запустить. См. trapexit thread about it. Использование его для изучения того, как это было сделано, может быть лучшей идеей.

Answer 3

mnesiacrash с большим объемом записей, если вы не tune it. Но вы можете использовать сложные первичные ключи, которые выглядят как {ID, UniqueConstraint}, что упростит ваши обновления. Также есть новая библиотека erlang для звонков osmos для дисков на ordered_set таблицах, созданных специально для обработки записей большого объема.